I'm digging myself a hole. I started out trying to reverse an older Intel AMI-based BIOS, which comes in 7 pieces. To create a complete ROM file that can be read by an AMI BIOS utility, you need to piece the 7 parts together with a 96k filler of FF's to make a 512k ROM file. Through a lot of trial and error, and comparing the ROM to AMI ROMs of it's era, I have been able to put together a complete ROM that can be read by one AMI utility of that era, However, another AMI utility complains of a CRC error, and to have a ROM I can flash, it needs to be error-free.

The older AMI utilities run in DOS/4G. I can't get them to start in a DOS box under Win XP but they will start fine under a DOS prompt if I boot from a boot floppy made in Win XP. I want to examine the ROM file using softice to see where the CRC error occurs but that opens several cans of worms.

If I go to the pure DOS environment, I have to use softice 2.8 or equivalent. If I get that running in a stable environment, I don't know if it will choke on DOS/4G. Does anyone have knowledge of such an interaction? Ideally, I'd like to run softice in an XP DOS box. I have done that to an extent but it was done with a 16 bit app loaded with DLDR.exe. Is there a way to get a DOS/4G app to run in an XP DOS VM (aka command window)?

An alternative is to run in a VM. I'm out of my depth there due to a lack of experience with that environment. Does anyone have suggestions they can offer, other than "forget DOS", "forget softice", or "get a life"?

why I dont have "alot" of expierence with VM's(I use them only daily..), they are a invaluable resource to developers. that being said, there are a few VM's out there: M$'s own VirtualPC, VirtualBox, VMWare,ect...the only thing you really need to setup a VM is a image of the media(.img,.bin,.iso...ect.) you want to setup(2k,NT,XP,2k3,2k8..#shudders#..vista..)..after you get the VM setup, during Boot of the VM and subsequently the OS u can hit f8 or w/e to get to a command prompt. But as to further answers to your questions, I don't think my expeirence doesnt covers those fields, sorry..

[sidenote:] if you run into "snags setting up the VM", contact me ill help

regards BanMe

Thanks for reply and offer of help. I'm not a complete novice with VM's. The questions I might have is whether to use a pure DOS VM or use XP under a VM and use a boot disk from that to run DOS from it.

The main benefit of a VM, as kayaker has pointed out, is the convenience of switching between systems using a mouse. As it stands, if I want to test something in DOS, I have to reboot. The difficulty I've had with VM's was getting files back and forth between the live XP system and the VM. I haven't quite mastered the concept of a shared directory or using a pipe to run windbg to debug a VM session.

In fact, kayaker mentioned that before...about using windbg to debug a session in a VM in which softice was running. Maybe that's my solution. If I had a DOS/4g session running in a VM and debugged it with windbg or softice, maybe I could watch the entire process unfold.

The learning curve for that seems immense, however, considering how thinly I am spread right now with this BIOS problem. I believe yates has an article on setting up a VM with softice and I know kayaker has talked about it. The main problem for me right now is visualizing the breakpoints to use with systems nested like that.

OK...here's a question. If I want to run one of my BIOS utilities, I use a boot disk made for DOS in XP. It's actually the modified Windows ME boot disk which becomes apparent when you type 'ver' at the DOS prompt it creates. It's tells you it's the Windows ME version of DOS.

How would I replicate that under a VM...say VMWare? Plain DOS doesn't seem to work for me, probably because it's a FAT 16 system and not used to seeing 100 gig hard drives. The XP-based DOS boot disk seems to get around that, however. Can you boot into a higher level of DOS than 6.22 using a VM?

Under Win98, you could press F8 at boot time and select a DOS prompt. I don't know if you could do that in ME but you can't in XP unless it's in safe mode, which I have never tried.

Are you making this harder than it has to be? You could just run the app through IDA, and see if you can locate the function that does the CRC, then, write a version that compiles under windows, and use that to test your mods.

That's how I would do it.

Whereas I specialize in that at times on this occasion I'm making it sound easier than it is.

The ROM file comes in pieces, for some reason. Most proper AMI ROM files are one-piece. Some parts of the ROM file are compressed while other parts are not, so it's not like loading an unpacked exe in IDA and running it. If I load it in IDA, it has to be loaded as a binary and IDA has no idea what to do with it, nor do I.

What I need to do is put the file into one piece so an AMI BIOS utility can read it. When I have the more than a dozen segments identified, then I can start on decompressing the segments that are compressed so I can use IDA.

What I'm aiming at in this post is extracting a segment using an AMI utility and seeing what I can do with it. If, as I suspect, the segment is the Silicon Image BIOS segment of the Intel BIOS, I may be able to substitute it with a more modern version, which is available from SI.

Reading the CRC in a compressed ROM file is almost impossible unless you know where to look. That's why I need to load it with a debugger to see where the CRC error is posted. I did try several CRC combinations using a hex editor but none of them showed up in the ROM file. BTW...I heard that the CRC in this ROM file should add up to 0, whatever that means. I don't know if that's 0 per segment or 0 overall.

You said "However, another AMI utility complains of a CRC error"

It is this that I'm addressing. Run THAT app (the one that's telling you about the CRC error), through IDA, and investigate how IT computes the CRC.

You're point is well taken, but they are not making anything easy. The text relating to the error message is not there. I would assume it's built when the message box is displayed and seeing this is a DOS/4G app, there is no message box function either. It's all done with INT's, which I don't excel at, nor much else, for that matter.

What do you suggest for finding a CRC check? It would be nice if I could find some code around a math function spelling out CRC, but that's not very likely if they haven't inserted the string from the error box.

This is an app that runs in DPMI and there are large chunks of 'unknown' code left by IDA. I have sifted through much of it, finding CD 31 a lot, which is a call to DPMI.

I think I'm seeing a bit of obfuscation as well. For example, in the middle of a good run of code, there is a data byte with an IDA reference to a data section. They are inserting a '66' from another part of the app into the code section. It may be legit but it bothers me when I see decent looking code with a data reference right in the middle of it.

There are a couple of instances of text with the first letter missing. I'm not leaping to conclusions but that suggests to me someone has a reason for it.

Frank....the current problem is solved. The CRC error was due to a misunderstanding in assembling my Intel BIOS file from the parts. I had 2 sources, one Chinese and one Russian, both interpreted by Google. Things got lost in the translation. In fact, the Russian site was wrong and the Chinese site was refering to an earlier BIOS.

Anyway, I assembled the parts, added padding to get the file size to 512k and both AMI utilities read the ROM file. Much to my delight, one of the segments, in its original size, is exactly the same size as the newest Silicon Image segment available for that purpose and it is marked with the SI signature of 3112. From what I have read, one of the utilities will compress it to the correct size and insert it in the ROM file. After that, it's a matter of either disassembling the file to its constituent parts for the Intel flasher, or finding a flasher that will insert it in one piece. After that, I may be looking for a new mobo.

I'm a happy camper...for now.

I know you're already done, but I figure this is good data for anyone who comes after. The 66 byte that you are seeing is there to signify that the next instruction works on the 32 bit version of the register (I.E. Eax instead of just ax). I dunno why IDA doesn't recognize it as such.

It's good information for me too, thanks for tip. Have you got any other tips regarding data bytes in an IDA disassembly? I often find myself 'interacting' with the IDA disassembly (go figure ) and that's one of the problems I encounter. I don't know what to do with data bytes in code.

One reason IDA may not have picked up on the data byte is that I was disassembling in 16-bit binary mode. ROMs are still written in 16-bit and they have little in the way of format. IDA is pretty intuitive all the same, if you find the initial jump instruction that ROMs often have. In the most recent disassembly I did, there was an EB with a byte right at the front of the ROM code. The minute I marked it as code, IDA did a lot of the rest.

I got that segment in the ROM I was looking for. One of the AMI utilities dumped it for me and it seems to be replaceable in my ROM with the newer SATA/RAID Silicon Image ROM from 2007. I compared it to the firmware module for the onboard mobo controller Flash RAM in IDA and they are identical for the most part. I don't know if the OS will use the newer code in BIOS in lieu of the older code in the controller BIOS or if I'll have to dump that somehow.

If you are using VMware or -better- the last VirtualBox xVM (open source and compatible with VMware!) you can shutdown it and mount the virtual disk (extension .vmkd) in Windows with VDK (http://chitchat.at.infoseek.co.jp/vmware/vdk.html). Just run the command "VDK OPEN 1 filename.vmkd" and then is just a matter of drag and drop!

Best regards, bilbo

Haven't seen you're name around for a while, Bilbo, then again, I haven't been around much. Good to hear from you.

I'll be sure to try out your tips....thanks. There's some good open-source material around. I remembered in the meantime, that with the VMWare toolkit installed, you can drag and drop directly between an XP file manager and a file manager in an XP install on VMWare. You just drag the highlighted files in XP proper to the VM tab at the bottom of the screen, and when it lights up, you can release the mouse button. VMWare will open up and you can finish your drag and drop by clicking in the desired directory in the VM file manager, which is presumably open to the right directory, then use a 'right-click' followed by a 'paste' to drop the files there.

I got stymied by another problem, however. I was asking how to boot from a floppy to come up at the XP DOS prompt. A bit of head scratching revealed the answer. In the VM, you set up the floppy to boot first at boot time, the same way you do in Windows...in the BIOS. I did that, rebooted XP, and behold...I was dropped at a DOS prompt after the VM booted from the floppy.

Unfortunately, I could get no further than the a:\ DOS prompt since no other drive is recognized. Mind you, I used a DOS floppy created in XP proper, not the version of XP in the VM. Maybe that's the problem.