1

I have a file which has been encrypted with some unknown algorithm. Doing research on the file format, I stumbled across a website that claimed (without explaining why) that these files were encrypted with 32bit Blowfish. This website also speculates that the magic smoke is contained in a .iff file with a specific name.

It turns out that the .iff file is embedded in a plaintext portion of the encrypted file. I have clawed this out, and it hints at it being Blowfish.

The 4 byte header is "BLFS". The next int32 after that is 0x80. Then follows 16 bytes of random binary string (128 bits). Then, two more int32s... 0x75 and 0x01. Following that, 120 bytes of binary string (not 117?), and 4 nulls. The last bit I think is safe to assume as padding, as the parent file requires some weird byte-alignment scheme.

I have many examples of these encrypted files. The 128bit string changes, file to file. The 120byte string changes, file to file. BLFS, 0x80, 0x75, and 0x01 all remain constant.

I am a cryptography noob. The 120byte string is far too long to be a Blowfish key, which maxes out at 56 bytes. The 128bit string is a better bet (it has that nice round power-of-two number that the original implementor would have liked). I know that an algorithm like this would also require an iv, but aren't those short? In some cases, just a byte?

Is this iff file I've extracted the magic sauce, and is it the sort that I think it is? I'm not able to make sense of what I'm seeing, and I'm not sure what research I need to do next to accomplish that.

Apologies if this question isn't a fit for this SE, please comment and let me know that before closing.

  • 1
    My first guess, seeing the BLFS, is blowfish as well. However, as long as there are no obvious clues to the format within the file itself, it's a "everything is possible, nothing is certain" thing. Do you happen to have the application that reads or writes these files? Reversing that application is likely to be the only way to go any further. – Guntram Blohm supports Monica Oct 31 '16 at 20:07
  • I have access to two applications that read this. It was released for both Windows and Mac. The Windows version may actually have anti-debugger features, but I haven't tried. Not yet anyway. – John O Oct 31 '16 at 20:55
  • 1
    First thin I'd do is run the program with procmon active, check how it reads the file (does it seek to where the BLFS string is and read a fixed number of bytes before rewinding the file and reading the rest?) and check the stack when these calls happen. This alone might give you some clues about how the file "works", which could help in determining which parts to reverse. – Guntram Blohm supports Monica Oct 31 '16 at 22:44
  • 1
    run nm/strings on the Mac program and see if you see any mention of blowfish (or other cipher). Many Mac developers are lazy/careless and don't strip their binaries. – Igor Skochinsky Nov 1 '16 at 12:44
  • 1
    Since you have a program that can read the files, a useful test would be to try to modify the files (e.g. by flipping a single bit in either the 16-byte or the 120-byte string) and see what happens. If you're lucky, the resulting output is only partly garbled; the way it changes (e.g. just one bit in the decoded data flipped, a whole 8-byte block garbled, everything after the flipped bit garbled, etc.) should indicate what encryption mode is used. If you're less lucky, the decryption will simply fail, which suggests the presence of some kind of a checksum or a MAC, but even that's useful info. – Ilmari Karonen Nov 4 '16 at 3:50

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.