I'm still working on deciphering an older, no longer supported, AMI Flash-ROM module. The ROM is broken into segments called 'devices' and the following data is an actual segment from the ROM:



I inserted breaks for clarity.

If you look at the last 8 bytes they are ASCII bytes that spell D845E10A, the name of my mobo and ROM. Preceding the ASCII name is a 0x14 byte header that precedes each ROM device in the ROM. They break down as follows:

0800 0000 = size of file
5396 E535 = CRC...apparently including the header with CRC bytes set to 0.
1400 AAD3 = offset to next segment
0800 = file size again, if over FFFF, it is apparently left as such
0C = device number
80 = indicates a non-compressed file, a 00 here would be a compressed file.
0000 0000 = EOF markers and padding.

How the heck do you get a CRC = 35E59653 out of that? I ran the file through a CRC 32 bit check and a CRC-32 check with no luck. I have tried the CRC checks on the ASCII name itself and on the combined name and header, with the CRC value set to zeros.

Update...apparently the CRC makes the entire segment with header add up to 0, when the CRC is included. Without the CRC bytes in the header, the CRC equals the value indicated by the CRC bytes. Is that a CRC-based algorithm of some kind, or just plain binary math?

A "CRC check", in common language, can practically be any kind of mathematical algorithm that results in a "number" inside a limited data space (say 32 bits) when processing a (normally) arbitrarily big amount of data with the algorithm.

In this case they seem to use a simple wrapping addition-algorithm, which is extremely simple to "reverse" (= calculate data for which would result in any given "checksum" you want), but none the less it will only fail in 1 out of 2^32 times given that the errors that they want to detect are random.

For cases where you want to detect deliberate modifications though, you normally use some kind of cryptographic CRC/hash algorithm, which will make it hard to control the content of the checksum once anything has been changed in the checked data to begin with.

If you have access to either trace or patch the CRC checking code itself though, you are always the winner, of course, no matter which algorithm is being used.

Thanks for response delta. A guy on the net has made a tool which does AMI CRC's. I was playing with it and it seems the crc on ROM segments adds up to 0 with the crc in place. There is another article that explains how to solve it but I'm caught up in another aspect of reversing the ROM right now and haven't gotten into it.

They use QWords in some parts of the app. For example, they add up the number of QWords from the FOF (front of file) and place that number as a type of error check. I ran into another one using the math coprocessor and I can't work it out yet. Maybe you can understand it.

FLD Real 4 [ebp-4] ....number 4.05 stored in ST0
FCOMP Real8 [dbl_45B758] ....compares it to 3.34
ADD ESP, C
FSTSW AX ....stores status word in AX flags = odIszApc (IA set)
TEST AH,41 .....AX was cleared in previous step
FLD Real4 [ESP-4] ....loads 4.08 in ST0 again
FCOMP Real8 [45b750] .....compares it to 4. (no zeros)
FSTSW AX ....AX remains at 0 flags = odIsZaPc (IZP=set)
TEST AX,5
JP 403F53


That's the first time I have encountered a jmp on parity. The 4.05 comes from a section of the ROM file and the 3.34 and 4. it is compared with comes from the utility that is loading the ROM for analysis.

I'm also curious about the ADD ESP, C. Is that to clear out the parameters used for the copro? Under an explanation for the FCOMP instruction there was mention of 2 POPS.

I was reading the latest Phrack article on Persistent BIOS Infection

http://www.phrack.org/issues.html?issue=66&id=7

They use a python script to 'Modify and recalculate Award BIOS checksum'. Makes no sense to me but maybe you can pick up an idea or none from the article.

Thanks kayaker...fascinating stuff. They are talking about a lot more than modifying checksums, they are talking about hooking the computer as it boots and injecting their own code. No anti-virus or anti-anything can do a thing about that. They are even talking about talking straight to the kernel.

I thought Linux was supposed to be totally secure with their superuser and everything. These guys are talking about reading the superuser password during boot and replacing it with their own.

There are a couple of references to VMWare in the article that may be of interest to you and others. They reveal a couple of undocumented settings for remote debugging, etc.

Anyway, the current BIOS on systems is definitely an Achilles heel. It's an archaic system that initializes the computer hardware long before the more secure OS can do anything. I have known for a long time, based on early work with microprocessors, that the most vital interrupt on a system, that gets priority over the rest, is the power on boot interrupt. That's how a processor knows what to do. When power is applied, a hardware interrupt is issued that starts an initialization process in the processor.

Right after that, the processor goes looking for instructions and it normally finds them at FFFF:FFF0 in the BIOS. There is code there that causes a jump to other code, and eventually the boot code is read on the hard disk or floppy. So, the intialization of hard disks and video is done through BIOS code. In the article, they talked about hooking the code right at FFFF:FFF0 but they quite smartly realized they'd have to do all the initialization so they looked for another constant in the BIOS code. They found it at the decompression code which is apparently in BIOS as well, at least on Phoenix and Award systems.

I found it fascinating that they tracked down the BIOS in VMWare, which is a Phoenix BIOS. They talked about replacing the entire BIOS, or modifying it to their liking. I thought it might be nice to add in softice as one of the modules.

On my system, Silicon Image has a hefty module aimed mainly at RAID setup, which is available during boot. The other PCI-based code is for Intel's onboard NIC and it features a boot utility for booting from networks. If that onboard code is not used, because the feature is turned off, that entire code area can be used for other purposes, and turned on and off in BIOS.