Bochs x86 16bit and IDA dissasembly

Question

I have been trying a figure out how to get Bochs to run an x86 embeded firmware rom so I can disassemble while emulating. When I start the debug in ida bochs just says "wrong segmentation". Loading in the bin strait into IDA causes a lot of sement and register assumpsions that are wrong.

The issue is the first string of code pages in 512k of ram at 0x00 the sets sp. Then all segments are set to 0. From there it starts pointong to ds:offsets and calls but ida is not automatically joining the two and i have the manually write down the code pointed to and how the function interacts. After a few calls everything is so garbled i might as well be doing things on pen and paper.

Is there any tutorials on using IDA for embeded dissasembly? Can Bochs even run non-pc hardware embeded firmwares?

Answer 1

Default IDA setting for Bochs is “IDB mode” for emulating independent code snippets (32-bit or 64-bit). For emulating 16-bit code you need to use Disk Image mode, even if you don’t really have a disk image. By default Bochs uses its own BIOS ROM, but by making a custom .bochsrc file with a romimage statement pointing to your ROM you can force it to emulate that one instead. Just specify that file in Debugger -> Process Options -> Application and enable “Stop on debugging start” in Debugging options so that you can start debugging from the reset vector. One possible problem is that Bochs only maps 128K of the ROM (segments E000 and F000). The segment C000 is used to map the Video BIOS OPTION ROM. So what you can do is to cut out the area corresponding to that region and map it via the vgaromimage statement. Possibly you can also map the rest of the file by using the optromimage1 statement and a matching address.

Note that in general the Bochs emulated machine only works well with its own BIOS and you will likely run into all kinds of issues when using it with another ROM. QEMU or MAME with a customized machine definition could be another option, and QEMU can be connected to IDA via the built in GDB stub.

Answer 2

IDA needs to be aware of the binary format to accurately map things. Try and collect more information about the binary ( 16/32/64 bit, OS of device, file-format, alignment requirements , etc). You may have to rebase a few things and then have IDA re-analyze.

I haven't used Bochs, does it emulate user-mode binaries for different platforms? Also, it is strange that an embedded device is using x86. That doesn't occur often. Do you know that it is x86 for certain?

Answer 3

There are lots of embedded devices with x86. VIA used to clone Intel's architecture, got sued at some time and the CPUs produced landed on many embedded systems. They actually perform better at performance per watt.

About the disassemble of 16bit opcodes, I use to manually follow from the first instruction at FFFF:FFF0 until it gets switched to protected mode in 32bit.

There will be a fixed offset between the memory map of the CPU and your dump address for this 16 bit instructions. I use to boot MS-DOS first and use the debug tool to find this offset. For example: if i find a jump from FFFF:FFF0 to F000:5000 in memory map, i manually search the 10 bytes or more around F000:5000 in the firmware dump. (with a hex editor in a windows machine) Then i find this bytes at 35000, now i know that a jump in memory at F000:1234 will be at 31234 in the dump, and from now on i can trace the code in IDA 16bit disassembled code... "Undefine" the address and press "C", folow the next jump and calculate the next address. And i copy-paste all snippets of code, from jmp to jmp one under the other in a text file. Finally my txt file will reveal the entire code.. I know there is debugging, but it never works till the end.. IDA stops from single stepping and it lets the emulator run free.