This function starts out by reading a fixed size (4,104-byte) chunk of data
from the archive file. The interesting thing about this read operation is how the
starting address is calculated. The function receives a parameter that is multi-
plied by 4,104, adds 0x28, and is then used as the file offset from where to start
reading. This exposes an important detail about the internal organization of
Cryptex files: they appear to be divided into data blocks that are 4,104 bytes
long. Adding 0x28to the file offset is simply a way to skip the file header. The
second parameter that this function takes appears to be some kind of a block
number that the function must read.
After the data is read into memory, the function proceeds to decrypt it using
the CryptDecryptfunction. As expected, the data-length parameter (which is
the sixth parameter passed to this function) is again hard-coded to 4104. It is
interesting to look at the error message that is printed if this function fails. It
reveals that this function is attempting to read and decrypt a cluster, which is
probably just a fancy name for what I classified as those fixed-sized data blocks.
If CryptDecryptis successful, the function simply returns to the caller while
returning the address of the newly decrypted block.
Analyzing a File Entry
Since you’re working under the assumption that the block that was just read is
the archive’s file directory or some other part of its header, your next step is to
take the decrypted block and attempt to study it and establish how it’s struc-
tured. The following memory dump shows the contents of the decrypted block
I obtained while trying to list the files in the Test1.crxarchive created earlier.
00405050 00 00 00 00 02 00 00 00 .......
00405058 01 00 00 00 52 EB DD 0C ...Rë_.
00405060 D4 CB 55 D9 A4 CD E1 C6 ÔËUÙ¤ÍáÆ
00405068 96 6C 9C 3C 61 73 74 65 –lœ<aste
00405070 72 69 73 6B 73 2E 74 78 risks.tx
00405078 74 00 00 00 00 00 00 00 t.......As you can see, you’re in the right place; the memory block contains the file
name asterisks.txt, which you encrypted into this archive earlier. The
question now is: What is in those 28 bytes that precede the file name? One
thing to do right away is to try and view the data in a different way. In the pre-
ceding dump I used an ASCII view because I wanted to be able to see the file
name string, but it might be easier to make out other fields by using a 32-bit
view on this entry. The following are the first 28 bytes viewed as a sequence of
32-bit hexadecimal numbers:
00405050 00000000 00000002 00000001 0CDDEB52
00405060 D955CBD4 C6E1CDA4 3C9C6C96Deciphering File Formats 223