I am trying to get at the BIOS in my optical drive as well as on my Intel mobo. I was looking at the BIOS file for my drive on Reshacker, and under RCData there is code that begins with PK. It looks like the drives BIOS code wrapped up in in a flashing program.

If that's the case, can anyone help me ID the packing from the PK file header entry? I copied several lines of the file:



I removed the file name just in case. I have consider pklite and pkzip. UNP doesn't indicate anything about the file and IDA wont disassemble it properly, inserting spaces (0x20) liberally through the data for some reason. It insists on identifying it as a dump file.

With regard to my Intel mobo, it comes with 6 different files with headers that can be apparently tacked together so the AMI bios app will read them. I don't know if they are packed. Can someone enlighten me? I came across one such BIOS file that was just packed with exepack. I'm trying to use softice to view the BIOS in memory between F0000 and FFFFF but can only recognize a few things in common with my Intel bios files. Besides, the BIOS files are about 512K and the BIOS area is only 64k. Where does the rest of it go?

I took a quick look at Pinczakko's Guide to Award BIOS Reverse Engineering

http://www.geocities.com/mamanzip/Articles/Award_Bios_RE/Award_Bios_RE_guide.html#The_compressed_components

and what he does with the compressed components is dump them into Hexworkshop, rename them with the appropriate zip extension and simply unzip them.

Why don't you try the same and apply the unzipping?

One way to confirm the validity might be to dump the file into 010 Editor and run its ZIP template (others are downloadable from the site). I did that for fun with the hex you posted, the template errored because of the incomplete file size, but otherwise seemed satisfied it was probably of correct zip syntax.

Have you renamed the file to something.zip, and tried to unzip it?

I've seen quite a few files that unzipped as a result of this.

I know from my readings on My Digital Life Forums that for many Intel MOBO's there are no good tools currently available for modification. This currently seems to be the case for those with the new ITK Bios. Better luck with Phoenix and Ami Bios on older Intel Boards. You can check there for tools which work with Ami Bios.

However, only a few have actually attempted to disassemble the bios and see how they actually work. Most are just looking were to insert an OEM manufacture identity to make them able to run versions of OEM MS software which did not actually come with their machines.

Regards,

Thanks for link Kayaker. I did come across it in my travels and it's too bad it's aimed mainly at Award bioses. Then again, the mobo chips constrain what the bios mfg can do and it seems much of what he says is pertinent to AMI.

I noted what you and Frank Rizzo said about renaming the file to a zip extension. I had already tried that, even going to the DOS version of pkzip and trying that. No go. Whereas you can use zip purely to compact a file, I think people who use that method do so internally. For example, in python and cygwin, they provide a zip utility that is called internally.

Speaking of Pinczakko, I did read through his sight for awhile after getting your link. I was following the bootloader sequence which begins at 800F0000 on an XP machine and I think that's equivalent to F000:0000 on a DOS machine. Anyway, you are supposed to be able to add the offset to the segment by adding a 0 to the seg addy then adding.

The boot code is found at F000:FFF0 and is EA 5B E0. I dumped my memory from 800F0000 to 80FFFFF and loaded it in IDA. When I use the 'C' for code at that address, IDA translates it in red to 'jmp far ptr F000h:E05Bh', which is correct according to the bytes at that address. Now comes the bad part.

Ilfak is a brilliant programmer, but sometimes he seems to go out of his way to obfuscate matters by sticking too close to theory. His treatment of segmentation is enough to drive me back to drinking. I have yet to figure out his reasoning. When loading the raw binary file, there is an option to select the beginning segment. You are presented with 0x00000000, not knowing if it's going to be analyzed in 16 bit ot 32 bit. I have placed an F in each position above and IDA interprets it the same way every time....and wrong.

If I leave the initial segment at 0x0000000, IDA sets the file up, under a 16 bit choice, as seg000:FFF0, where my boot code lies. When I convert that to code, it complains that it can't find F000:E05B. Of course it can't because the segment is 0:0. So I reload and tell it the initial segment will be 0x00F0000, which it would be in XP with an 8 in the msb. When I load the raw binary again, it is still listed as seg000:FFF0 and complains again that it can't find segment F.

Either I'm completely stupid or there is something wrong with IDA and it's implementation of segmentation.

Thanks for reply. See my reply to kayaker.

JMI...I did check your site out but I'm caught between about a dozen different ways of approaching the problem.

Intel's AMI-based BIOS is quite different. I have been living dangerously lately, using IFlash in DOS mode under softice ice to see what it does with the 6 BIOS files it has to load. Meantime, I came across a nifty DOS app called showhdr, which can be used on each file. It reads the headers and tells you which bios file comes next, while giving you the total file size expected and where each bios part resides in the overall picture. I have wondered about running iFlash in a VM, or a sandbox, to be a bit safer.

My bios is from an older Intel mobo which they no longer support. I came across an article on a Russian site which guesses at how the files should be put together so the AMI bios utility can read it. According to showhdr, they are put together in order with a total size of 425984 bytes. However, I have read that the bios file size should be 512k, which many bios people seem to refer to as 1 meg. Go figure. So, to pad the file out to 512k, they are adding long fills of FF, up to 96k of them.

The first Intel bios file, with a BIO extension, has a front end of 27k+ of FF's. All the files have headers on them as well, which showhdr can read and the headers have to be removed from each file, according to the Russians. When the Headers are removed, the file size is a neat 64k with one of them 32k. Each header tells the flash utility which file follows, how long the current file is, and where it is placed in either the file, or memory. I don't know which because the BIOS area from 800F0000 to 800FFFF doesn't correspond with much of it.

Another meantime, I was reading on the Intel firmware controller, which holds the flash memory. It is made of sectors which are 512k in length and that's why I think the Russians are onto something. To see what was going on, I loaded the AMI bios utility up in softice and followed the loading of the 512k file with FF-padding I had created using the Russian method. I watched the file being loaded and loosely followed the intial analysis. It checks for an AMI-specific signature near the end of the file and it checks at half the file size to see if there are FF's there.

So far, I haven't arrived at any conclusions. They may simply be checking for different types of bios. Whatever they were doing, they didn't like my attempt and rejected it. I have since d/l'd a 512k and a 1 meg AMI bios and I'm going to analyze what they are really looking for.

Meantime, again, if you have any 512k AMI bioses, circa 2002 to 2004, you can foward for analysis, it would be appreciated. I'd like to find one with a SATA controller in it but that's not essential. There is a file with the Intel bios parts called a SIG file. It may have extensive CRC checks, I don't know.

If you're loading the 64K chunk for F000:0000, you need to load it at segment F000 offset 0000, that will give you the correct addressing. If you're loading more, you will need to create extra segments manually after loading.
It's quite simple actually. Segment = paragraph address = linear address >> 4.

Thanks for tip, reverser. It seems to me I tried putting an F in each position of the 0x00000000 presented as a segment address but obviously I missed that one hence I am as stupid as I declared.

My dump is now unfolding as it should. Spotted a unique sequence at F000:0000 that is the sequence _32_ , turns out to be the signature of PCI code being present in BIOS. You learn something every day...sometimes.

thanks again.

Problem solved...case closed...my stupidity.

The 'PK' was from 7-zip. IDA identified it as a dump file because when you copy and paste from Reshacker, it copies addresses with the code. When I loaded the copied file in my hex editor, it loaded exactly what it got from Reshacker, so IDA was seeing an address like 00B6F00 mixed in with the code and got a bit confused.

I did not notice that at first in the IDA disassembly, until I saw data in front of the 'PK' header and couldn't figure out where it came from.