using an uncompressed png file as attack target

[ghylander]

I have an un compressed (store) png file in a zip archive

Knowing the signature of a png file, how do i enter the plain text?

The first eight bytes of a PNG file always contain the following values:

(decimal) 137 80 78 71 13 10 26 10
(hexadecimal) 89 50 4e 47 0d 0a 1a 0a
(ASCII C notation) \211 P N G \r \n \032 \n

plus, scattered around the file there is more known text, like IHDR, IDAT or IEND

How to store this information on the plaintext file?
First, how to enter the signature?
Second, how to create (and use) a plain text file containing non-contigious text?

[kimci86]

Hello!
Having a quick look at the PNG file format specification, I see that a PNG file starts with a fixed signature and an IHDR chunk. Some parts of this IHDR chunk are always the same (namely the signature and the length of the chunk). That means that the first 16 bytes are fixed if I understand the specification correctly.

To pass this information to bkcrack, you can either:

• Pass it on the command line in hexadecimal.
  Example:

  bkcrack -C encrypted.zip -c entry.png -x 0 89504e470d0a1a0a0000000d49484452
  

  The 0 after -x means the given hexadecimal data corresponds to plaintext starting at offset 0 (i.e. is the beginning of the file)
• OR get data from an existing PNG file and load only the first 16 bytes.
  Example:

  bkcrack -C encrypted.zip -c entry.png -p some_image.png -t 16
  

Regarding additional non-contiguous plaintext such as the IEND chunk, giving it to bkcrack would not make a difference in this case.
Only contiguous plaintext can speed up the computation. Non-contiguous plaintext is required when there is less than 12 bytes of contiguous plaintext available to filter candidates, but here we already know 16 bytes.

I hope this helps. Let me know how it goes.

[ghylander]

Thank you very much for the help, I wasn't certain of how to input the signature. I didn't notice the offset cli option accepted hexadecimal input.
Both approaches worked flawlessly.

Not only they worked, they was the fastest approach as well.

Even with the knowledge of the full text contained in a txt file (29 bytes) in the zip, and using the full text as attack vector, it took so much longer than using the png signature. So much longer, in fact, that I couldn't be bothered with re-reunning the attack to show how long it took.

---

That being said, my question regarding the use of non-contigious text in a txt still stands (sorry but I couldn't find anything other than it's possible or necessary if there's less than 12 bytes of contigious text available, and how to do it from the CLI)

If I were to attack a txt from which i know a few words, but neither is at least 12 bytes long. How would I structure the plaintext txt to input it to bkcrack?
Is it a possibility? Or to use non-contigious text one has to use the CLI -x argument?

[kimci86]

I am glad it worked!

Even with the knowledge of the full text contained in a txt file (29 bytes) in the zip, and using the full text as attack vector, it took so much longer than using the png signature.

Yes, that can happen with some luck. Using more contiguous plaintext means that the number of candidates (Z values) can be further reduced, but then finding the solution among the candidates can take long or not depending on where the solution is in the list of candidates. If we are lucky and it is at the beginning of the list of candidates, it will be found quickly.

If I were to attack a txt from which i know a few words, but neither is at least 12 bytes long. How would I structure the plaintext txt to input it to bkcrack?
Is it a possibility? Or to use non-contigious text one has to use the CLI -x argument?

To carry out an attack, you need 12 bytes of known plaintext and at least 8 of them must be contiguous.
Note that one byte comes for free if you load ciphertext from an archive (which is likely). It is the check byte located just before actual encrypted data, i.e. the last byte of the encryption header. So the bare minimum is to give 7 contiguous bytes starting at offset 0 + 4 bytes or 8 contiguous bytes starting somewhere else + 3 bytes.

You can provide known plaintext either from a file, a zip entry, or as an hexadecimal string on the command line.
Several pieces of data can be given on the command line by using the -x option several times.
At the moment, this is how you would do it: use the -x option several times.

Note that you need to specify where each provided piece of data is (i.e. at which offset).
In theory, it is possible to have a more flexible filtering mechanism by searching for some string in deciphered data without knowing at which offset exactly, but it is not implemented at the moment. That could be a nice new feature.

I am open to suggestions. How would you expect of prefer to provide non-contiguous data?

[ghylander]

Note that you need to specify where each provided piece of data is (i.e. at which offset). In theory, it is possible to have a more flexible filtering mechanism by searching for some string in deciphered data without knowing at which offset exactly, but it is not implemented at the moment. That could be a nice new feature.

Indeed sounds nice. Would be useful in cases similar to this PNG attack, where there is some known text present in the file but unlike with the png it's not in known or fixed parts of the file. No idea on how to tackle this kind of issue though.

I am open to suggestions. How would you expect of prefer to provide non-contiguous data?

Heh, thats always the the gist isn't?
Perhaps a plan text with some special string in the 1st line, so that bkcrack can recognize it's a multi-index file
Then, each chunk of data can be placed in a newline, starting with its offset and folowed by a whitespace and the plain text. Off the top of my head, something like:

bkcrack-NONC-chunks-file
12 IHDR
56 IDAT
79 IEND

Or perhaps the chunks structured in an XML format? Then pass a special argument to the bkcrack that would indicate the file passed is to be used for non-contigious text instead of as plaintext. Could be a bit more complex to write, but is more powerful and could enable one to input known text in multiple formats (like plain text or hexadecimal):

<?xml version="1.0" encoding="UTF-8" ?>
<chunks>
	<chunk>
		<offset>14</offset>
		<plaintext>IHDR</plaintext>
	</chunk>
	<chunk>
		<offset>56</offset>
		<hexadecimal>89504e470d0a1a0a</hexadecimal>
	</chunk>
	<chunk>
		<offset>142</offset>
		<plaintext>IDAT</firstName>
	</chunk>
</chunks>

Indeed it's difficult to decide which approach would suit the tool best, and which approach users will find the most intuitive.
Personally I think the xml is a sound approach.

[kimci86]

Even though I think passing data on the command line is generally acceptable because there is not much, I agree having some kind of configuration file to specify known plaintext in various formats (string or hexadecimal) and other options would be nice to have. That might come handy in particular if bkcrack accepts more complex input in the future such as pieces of data without a known offset but within an interval or with ordering constraints between pieces of data.
I think as a user I would prefer YAML over XML for its lower verbosity. I will open a new issue to keep track of this task.

To my understanding, your questions have been answered so I close this issue. Feel free to reopen if I am mistaken.
Also, feel free to open other issues if you have any other questions or suggestions. Thank you for your feedback!