You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: cryptography/hashing/README.md
+18-20Lines changed: 18 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -69,20 +69,19 @@ To create such a file you can use the [poc\_no.sh](https://github.com/cr-marcste
69
69
In the example above I used a file containing `"A"*64 + "B"*64 + "C"*64 + "test"` as the prefix. This will make sure the identical prefix starts with AAA...CCC and the collision blocks start with "test". \
70
70
Then after this, I added `"D"*64 + "E"*64 + "F"*64` to the generated collisions because any data after will only change the hash, but the collision will remain. 
@@ -95,7 +94,7 @@ To create a collision like this, you could use the [cpc.sh](https://github.com/c
95
94
I've let a VPS with 24 cores run for 1.5 days to find a chosen-prefix collision like this. I chose one prefix of a simple 256x256 png image, and the other prefix to be an XSS and PHP shell payload. So I could leave the terminal and look back at it later I used the `screen` command to start a session, and used `screen -r` every once in a while to check back into it. Another way would be to redirect the output to some log file to check. 
96
95
97
96
```shell-session
98
-
$ # From hashclash clone (and build)
97
+
# # From hashclash clone (and build)
99
98
$ mkdir workdir && cd workdir
100
99
$ ../scripts/cpc.sh 256.png prefix.php # Takes a long time
101
100
```
@@ -169,15 +168,14 @@ In HTML, this can be done by looking at the `innerHTML` with `charCodeAt(102)` i
Sometimes you also need to **extract** a hash from a password-protected ZIP file for example. This is where John has a lot of useful tools. In the [`john/run`](https://github.com/openwall/john/tree/bleeding-jumbo/run) directory of your John the Ripper installation, there should be a lot of scripts and programs that allow you to convert certain files to the john format. For `.zip` archives there is the `zip2john` utility:
There are a lot of files that can be converted to john like this, just find one for the file format you need and convert it using the script. 
62
61
63
62
You can also use John to convert the hashes from a file, and then actually crack them with **Hashcat**. As stated above hashcat has a slightly different hash format, but from what I've found it's almost always just splitting the john hash by `:` colons and then taking the second part. That way you're only getting the hash without any other information. 
## [John the Ripper](https://github.com/openwall/john)
180
178
@@ -188,19 +186,16 @@ A list of example hashes with their name and john mode
188
186
189
187
John is pretty specific with its arguments. For a custom wordlist, make sure to use `-wordlist=` with the `=` sign. If you do not include the `=` sign it will give a weird "invalid UTF-8" error. Here is an example of how you should run john:
190
188
191
-
{% code title="Cracking an MD5 hash" %}
192
-
```shell-session
193
-
$ cat hash.txt
194
-
5ebe2294ecd0e0f08eab7690d2a6ee69
195
-
$ john --wordlist=/list/rockyou.txt --format=raw-md5 hash.txt
Use the "--show --format=Raw-MD5" options to display all of the cracked passwords reliably
201
197
Session completed.
202
-
```
203
-
{% endcode %}
198
+
</code></pre>
204
199
205
200
### Cracking shadow hashes
206
201
@@ -242,25 +237,23 @@ $ make install
242
237
243
238
Then after it's installed, you can use the `hcxpcapngtool` command to extract the handshakes from the capture. Then use hashcat with mode 22000 or 22001 to crack the password:
After you find the password, you can use Wireshark to decrypt the packets (see [#decrypting](../../forensics/wireshark.md#decrypting"mention"))
255
249
256
250
### WEP
257
251
258
252
WEP is an old Wifi encryption standard where every device uses the same key. It also happens to be easily crackable with enough traffic. It requires lots of IVs (Initialization Vectors), which can come from lots of normal traffic, or you can manually send specific packets that would trigger IVs to be generated if you have access to the network (see [this tutorial](https://www.aircrack-ng.org/doku.php?id=simple\_wep\_crack)). When you have a packet capture with enough information, you can use [`aircrack-ng`](https://www.aircrack-ng.org/) to quickly find the key:
After it completes, you can use the key it found (hex format) to decrypt all the traffic (see [#decrypting](../../forensics/wireshark.md#decrypting"mention"))
Copy file name to clipboardExpand all lines: cryptography/z3-solver.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,8 +8,8 @@ description: The Z3 Theorem Prover can automatically solve puzzles in Python
8
8
9
9
The Z3 Theorem Prover is a Python library that can automatically solve puzzles you give it in code. 
10
10
11
-
```shell
12
-
pip install z3-solver
11
+
```shell-session
12
+
$ pip install z3-solver
13
13
```
14
14
15
15
The idea is that you define Z3 variables and perform certain operations on them. Then you can add constraints to the solver and lets it fulfill those constraints. To learn using Z3 I highly suggest looking up some random puzzles and trying to solve them with Z3. There are lots of useful functions in Z3 to try out. 
Copy file name to clipboardExpand all lines: forensics/archives.md
+3-4Lines changed: 3 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,15 +24,14 @@ Doing it manually would require you to first get a hash using a tool like `zip2j
24
24
25
25
An interesting little thing about most archive file formats is the fact that when they are encrypted, you can still read the filenames and structure, only the content is encrypted. This can already give a good idea of what kind of files the archive contains. 
As you can see, even the size and a CRC32 are present. This CRC is a checksum of the **unencrypted** file content, so if you can guess the content you can confirm it by taking the CRC. This allows for brute-forcing content of very small files as well. See this tool for an implementation of that:
Copy file name to clipboardExpand all lines: forensics/file-formats.md
+9-11Lines changed: 9 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,9 +19,8 @@ A big collection of drawings of file formats to understand them quickly
19
19
Sometimes when data tries to be hidden inside another file, it is just pasted right into the host file. Meaning that the bytes of the secret file are just somewhere in the other file. Using [binwalk](https://github.com/ReFirmLabs/binwalk) you can check for known file signatures in a file to see if it embeds something. \
20
20
Using the following command you can also recursively extract all of these into a `.extracted` folder:
3145756 0x30001C UBI erase count header, version: 1, EC: 0x0, VID header offset: 0x800, data offset: 0x1000
34
33
35
-
$ binwalk --dd='.*' file.bin # Another way to extract all file signatures
36
-
```
34
+
<strong>$ binwalk --dd='.*' file.bin # Another way to extract all file signatures
35
+
</strong></code></pre>
37
36
38
37
{% hint style="warning" %}
39
38
A common false positive with PNGs is `Zlib compressed data`. This is because PNG uses Zlib for compression in its own file format, so it is recognized by binwalk. But very often this compressed data just covers the entire file
@@ -55,9 +54,8 @@ Image files like PNG can have a lot of hidden info. It's a relatively complex fi
55
54
56
55
A quick check you can do to see if it is a completely valid PNG file is using [pngcheck](http://www.libpng.org/pub/png/apps/pngcheck.html):
57
56
58
-
```shell-session
59
-
$ pngcheck -h
60
-
Test PNG, JNG or MNG image files for corruption, and print size/type info.
PNG files consist of **chunks** of bytes that tell something about the image. The most common one is `IDAT` which contains the pixel data of the image. An image always ends with `IEND` and 4 checksum bytes (every chunk has the checksum). 
*`PATTERNS` are a string containing one or more patterns to search for, separated by newline characters (`\n`). To put a newline character in an argument you can use the `$'first\nsecond'` syntax
17
17
*`FILES` are the files to search through for the `PATTERNS`. If not specified, it will read from standard input (piping into grep). If in recursive mode with -r, it will default to the current directory but can be any directory
0 commit comments