WaxfordSqueers
June 4th, 2009, 01:43
I have a file that seems to be packed, but it's not malware and the aim may not be to divert reversers. Then maybe it is. It's a BIOS file that I want to load in a specific utility from a specific BIOS vendor. I have a known good file of similar size and format that the utility accepts.
The file is 512k long (0x80000) and it has an ASCII signature word located 10 bytes in from a paragraph boundary. So, if the word is foofoo, and it's found in the paragraph at F4000, foofoo will begin at F400A. The app knows that but has to find it.
foofoo is followed by about 10 bytes. First, the app searches the file for foofoo, looking for it always at 0xA bytes into a line (from the 0 position) and it searches every other line by incrementing the inital base of file address by 0x20, until it finds it. Then it compares it to bytes at EOF-20. There is never a match with the signature word but the good file loads anyway.
After that, the app takes the last two bytes at the end of the string after foofoo and puts them in EAX. It puts the two bytes before those bytes in ECX. Then it does an SHL 4 on the EAX to multiply the bytes by 10 and it adds the bytes in the ECX to EAX. That gives a value larger than the file size but not by much. The filesize, 0x80000 is subtracted from that value.
The derived value is added to the file base address to get an offset into the file which is always on a boundary. Then, the bytes located 7 bytes into that offset are checked against a magic number. They never seem to match. After that, bytes are taken from the new offset code and operated on exactly as before, with two specified bytes loaded into the EAX, a SHL 4, and an addition of ECX. The process is repeated, with the new magic being always added to the file base. The offset it produces is compared against magic numbers and the app works through the code looking for something.
I'm wondering if anyone recognizes this algorithm? I'm not looking for a specific answer, just a bit of feedback. Any ideas are welcome. The values being checked don't seem to be hard values programmed into the file, so I've considered the algorithm may be a CRC check of some kind. The values in the string following foofoo may be the result of a CRC algorithm run on the app initially. I have also considered the algorithm may be part of an unpacking scheme. The file is moved around in memory a lot.
I'm asking because the loop for testing and creating the magic numbers (for new offsets) is long and it would help if I had an idea with regard to what is going on.
The file is 512k long (0x80000) and it has an ASCII signature word located 10 bytes in from a paragraph boundary. So, if the word is foofoo, and it's found in the paragraph at F4000, foofoo will begin at F400A. The app knows that but has to find it.
foofoo is followed by about 10 bytes. First, the app searches the file for foofoo, looking for it always at 0xA bytes into a line (from the 0 position) and it searches every other line by incrementing the inital base of file address by 0x20, until it finds it. Then it compares it to bytes at EOF-20. There is never a match with the signature word but the good file loads anyway.
After that, the app takes the last two bytes at the end of the string after foofoo and puts them in EAX. It puts the two bytes before those bytes in ECX. Then it does an SHL 4 on the EAX to multiply the bytes by 10 and it adds the bytes in the ECX to EAX. That gives a value larger than the file size but not by much. The filesize, 0x80000 is subtracted from that value.
The derived value is added to the file base address to get an offset into the file which is always on a boundary. Then, the bytes located 7 bytes into that offset are checked against a magic number. They never seem to match. After that, bytes are taken from the new offset code and operated on exactly as before, with two specified bytes loaded into the EAX, a SHL 4, and an addition of ECX. The process is repeated, with the new magic being always added to the file base. The offset it produces is compared against magic numbers and the app works through the code looking for something.
I'm wondering if anyone recognizes this algorithm? I'm not looking for a specific answer, just a bit of feedback. Any ideas are welcome. The values being checked don't seem to be hard values programmed into the file, so I've considered the algorithm may be a CRC check of some kind. The values in the string following foofoo may be the result of a CRC algorithm run on the app initially. I have also considered the algorithm may be part of an unpacking scheme. The file is moved around in memory a lot.
I'm asking because the loop for testing and creating the magic numbers (for new offsets) is long and it would help if I had an idea with regard to what is going on.