I am currently working on a file format used to pack (storage only, no compression) different file types together for transport. There is some sort of very simple "encryption" used and so far I have not had any luck. I do know the exact (partial) plain text though.

This is my first time reversing anything so it is very likely that I am missing something obvious!

I have worked out the complete structure of the format:

  • Header with some info
  • all "packed" files concatenated, filled to mod4 and "encrypted"
  • a file list with position, size and md5 for each file

Additionally each md5 is followed by a 32bit seperator(same on each block and every file, value = 2) and than follows a 32bit "key" at least this is my guess as these 32bit are the same on each block in the file list but every archive file has its own "key". I do know the exact contents of some of the files (all black .pngs) and can find them in the "cipher" text, each of the multiple pngs is "encrypted" exactly the same so I was thinking that it can not be anything overly complicated.

I can create multiple archives with the exact same content. If they are diffed the only thing that changes is the data block and the 32bit "key". The software used to create the archives does save a key value in one of its config files and changes it every time an archive is created but this key is 7 digit and the 32bit key (if read as LIT 32bit int) is a completely different 9 digit number. As the files are filled up so they are mod4=0 I tried to xor each 32bitblock with the "key" but this did not lead to the known plain text (e.g. png header data).

There is no additional data sent(or received prior to creation of the archive) to the receiving machine(s) of these files so I assume that the key for decryption must be part of the original file.

As the whole process of reversing the format was hugely difficult but progress also very rewarding I was just hoping for some pointers or obvious stuff I missed instead of an outright solution as this is the final piece of the puzzle :D

Thank you

  • Here is an encrypted and unencrypted png hex dump. There seem to be multiple 4 -28 byte long patterns in encrypted dump but I am not sure how to further analyse those... – UntrustworthyKey Nov 19 '17 at 19:39
  • Any chance of getting the key that is associated with the hex dumps? I have found some patterns but I need the key to verify. – David Dec 11 '17 at 16:48
  • @David thank you for trying! I have updated the question with the file list entry and reuped the data. – UntrustworthyKey Dec 12 '17 at 0:31
  • Could you post the same png encrypted with a different key, along with that new key? – booto Dec 21 '17 at 21:37
  • @booto Here you go png & "key" – UntrustworthyKey Dec 24 '17 at 15:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.