sabato 12 luglio 2014

I've started that work because i want to port AlcorMP utility to Linux and to be able to use custom flash chips with these UFD chips, this utility called AlcorMP allows to do a lot of stuff , from checking flash integrity to programming the usb flash drive into a CD-Rom emulator.

For who is new to that field, these flash drives store configuration data and badblocks on an hidden sector of the flash memowy which normally is not visible by the end user.

To program that sector you have to issue vendor specific SCSI commands, the ones that i've found are:
0x9a: Seems to return 0x200 bytes of data still not reverse engineered
0xfa00: Seems to return 0x200 bytes of data too, but this one returns the Flash Chip identification as the first 6 bytes , so it's something useful.
There's also 0xf5 that is still unknown

Now the hard part, first thing you will see when you try to figure out where the program takes the flash part.no and vendor, is that there's no plaintext list with that data, and there's no compressed data either.
Analyzing it with binwalk gives a very discouraging entropy graph as shown below

flashlist.afl entropy plot using binwalk -E

After some work on the UfdComLib.dll , it turns out that the file flashlist.afl has been encrypted with a block cipher on purpose.

Lucky the program itself ( except LLF.dll that is encrypted too ), is not obfuscated , so it has been relatively easy extracting the encryption algorithm from the program and use it to decode the flashlist.afl .

The function on UfdComLib.dll that gives an huge help locating the decryption code with IDA is the one at 0x100022F0

After studying on it some hours i've figured out that sub_10004760 is a function used to inizialize a vector of length 256 ( 0x100 ) with the encryption key that is later used on the caller function.

With HexRays decompiler it's fairly easy to generate proper C code of these functions and so re-use them.

The file is made of a first 256 byte block , that encrypted using the algorithm above and "ALCORFLASHCFG_SZ" as the key yields other 256 bytes that have to be used as the key for the next 256 byte block inside the file that is the header.

The header contains some useful info like the size of each record , the number of records and what i think to be the version ( 4 ) as follows:

The data after the header is organized in entry_size sized blocks and each one is decrypted using the same key obtained to decrypt the header, but , the first keybyte has to be the record number starting from 0 and the last keybyte has to be the bitwise negation of the record number

This gives us records on which i'm still working to figure out the exact format , but what i've defined so far: