Menu

Security Blog

16-bit debugger goodness

It’s Saturday around Noon. A friend is building a new server and wants to add 8 gigs of RAM to his MSI mother board but needs to flash the motherboard. I’m bored and seems easy plus he hasn’t seen Afro Samurai so I figure we’ll upgrade his motherboard watch some anime and it will be a Saturday afternoon well spent.

Well, turns out the instructions say use a floppy…guess what? He has no floppy drives. He has ten computers counting the laptop I brought but no floppy drives. Ah ok, well this is for a Linux server but we supposedly need windows to install. He installed windows before I got there but no go. The software won’t run and without a floppy, and we can’t make a DOS floppy. Believe it our not I keep a small win98boot.img file on my server for just such a reason but without a floppy I’ve got nothing.

So I go back to my house where I have tons of computers, all with floppies. Now that I think about it I have no idea why I always add a floppy when I build a machine… but I do. Plus I have extra drives so I grab one and some blank disks. Hey I still have blanks from the days of Slackware boot floppies, and Novell server.exes… yeah, you remember😉

So get this, the mother board doesn’t boot with the floppy attached. Whatever. We figure it should be trivial to modify the installer to use another drive letter rather than A:. We divided our efforts. He goes to task making a USB DOS bootable thumbdrive and I go to modify the motherboard’s installer.

As you can probably guess from this post that it was a 16-bit installer. No problem, right? I do 32-bit in Olly and IDA so trivial eh? Nope, only IDA can open such a thing but it can’t run as a debugger. Which wouldn’t be a big deal but the binary is packed. Packed! Yeah for real, 16-bit and packed.

At this stage there is no turning back for me. Meanwhile he already has his thumbdrive in DOS mode. But I can’t debug 16-bits even in IDA. Huh, who knew? Well probably a lot of you but I didn’t. So I figure, well I start up debug.exe and do it from there…nope. No breakpoint support or anything useful. Hmmmm, well I stumble on GRDB. It stands for ‘Get Real’ Debugger and I have to say I was impressed. It can handle 16-bit apps as well as 32-bit functionality. It actually has a lot of cool functionality like PCI bus support but I didn’t need that. What it did have was breakpoints, single stepping and step over commands. Plus in comments it would show if a jump was taken or the contents of ES:[ax+dx]. GRDB, I love you! :) And just for icing on the cake they have ANSI colors. Now how can you not love that?

GRDB comes with source: All in ASM and it can be compiled with MASM. All code is licensed under the GPL as well! Woot! By now my friend has already updated his motherboard and is intalling Linux but I’m still in fascinated mode. I missed the RE scene from back in the 16-bit DOS days. Granted I used debug.exe to change binaries but it was based on offsets about which people had told me. I was not in the scene that set the precedent for debuggers today. Now to only modify the binary to support Ruby and a .gdbinit script…😉

But if you are stuck with a 16-bit app I recommend GRDB, or if you want to write a packer that modern debuggers choke on…go old school. (PS. I laughed when I unpacked it and fired up ImpRec just to see NTVDM.EXE was all that was running :P) I forget how spoiled I am nowadays but this Saturday afternoon I found a surprisingly useful gem.