3

I have some technical documentation which is supplied in the form of a generic Windows viewer and a database. The database contains different "books", which are represented by a bunch files:

  • book.bbi - book index i.e. what pages are in the book
  • a bunch of .bli's - text entries on the page, that's a guess
  • a bunch of .ilg's - media on the page, that's a guess too

All these files have a plaintext header and what's remaining is the data which is compressed or encrypted in some way:

upd: the data_header is actually the uncompressed length of the data enter image description here

I tried running binwalk and XorSearch, but with no success. I guess now I have to debug it, but I am very, very unfamiliar with it. I am using x32dbg with the xAnalyzer plugin. I tried setting a breakpoint on ReadFile and tracing from there, but it produces an enormously large log. However I can see that it uses crush32.dll - "old C/Win32 compression library" and runs some ors/xors and byte shifts(shr) which kinda reinforces my thought about compression/encryption usage. enter image description here

So my question is how do I approach it from here? How do I at least dump all strings with the correspoding instructions i.e. get to the point where this byte-mess becomes readable strings? I am absolutely stuck. Thanks in advance!

|improve this question
  • Not a real answer, but have you take look into the executable for cryptographic functions? (outside crush32.dll). I'm not familiar with crush32.dll, but you can also set a breakpoint on its exported functions and dump the input / output for each call. – wisk Mar 4 at 14:02
  • @wisk thanks! I remember crush32 had some functions like cxOpen, might be worth looking into it. And how do I determine that a particular function is cryptographic? Look for various shifts etc.? Also my executable doesn't contain function names, all are just sub.*** :( – James Potato Mar 4 at 14:25
1

I grabbed some crush32.dll from the Internet and it has some very interesting exports:

  • cxBufDecrypt
  • cxCompressFile
  • cxExpandFile
  • cxBuf2BufCompress
  • cxBuf2BufExpand

I'd set a breakpoint on all of them, let your program run, wait for a bp to hit, inspect the stack arguments to find input/output buffers, let the function run and then look for readable data.

|improve this answer
  • Thank you! I've placed breakpoints on crush32 functions and found out that it runs cxInit when the program starts and then runs cxBuf2BufInit and cxBuf2BufExpand after reading the data chunk of a file. Tracing execution of the cxBuf2BufExpand results in 324000 instructions being logged. I've also googled these instructions and found out that this thing is "Crusher! Data Compression Toolkit" created in the early 90s. Quite a few code implementations of how to unpack it can be found, but so far I am only getting memory allocation error from crush32.dll when trying to unpack. – James Potato Mar 6 at 22:50
  • 1
    Aight, I've managed to unpack .bbi and .bli. Will submit a detailed post once I also unpack .ilg. – James Potato Mar 7 at 2:18

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.