16bit code is obsolete today, it’s nearing the end of its exile, the rogue’s march is playing despite the fast that 16bit programs are alive and millions users continue using them, being scared by the fact that x86-64 does not support 16bit anymore and even 32bit NT/XP has a very feeble DPMI host.
ok, let’s get down to business. some people want to debug 16bit applications for different reasons. IDA-Pro supports 16bit MS-DOS/DPMI applications quite well, and states that BOCHSDBG Plug-in support them too. (NOTE: IDA 5.3 and lower supports only win32 Debugging Engine, thus, you can’t debug 16bit apps with it).
the problem is: BOCHSDBG Plug-in does not support neither 16-bit MS-DOS/EXE nor 16bit code snippets. whether it’s 32bit or 16bit segment, BOCHSDBG plug-in threats it as 32bit, executing code in 32bit mode. not wonder that we get an unexpected result. for example, PUSH 1234h decreases ESP by four(!) instead of two! the worst thing is: 16bit and 32bit modes are very different. 8Bh 00h is “mov eax, [eax]” in 32bit mode and “mov ax, [bx][si]” in 16bit!
in the mean time: BOCHSDBG supports 16bit code well by itself. just to prepare an image, load in into BOCHSDBG and you the integrated debugger (a simple console one, kind of gdb). don’t touch IDA-Pro! you don’t need at all for this particular operation (IDA-Pro team is going to support 16bit code snippets, but it’s going to take time, the next version will probably just check the segment size and refuse to debug it with BOCHSDBG Plug-in if it’s 16bit).
if you’re not familiar with GDB or want to know more about debugging 16-bit apps with BOCHSDBG just leave me a comment and I will write a special post about it, sharing my own BOCHS image with all necessary tools installed (free and legal).
closing remarks: 16bit code became a quite strong anti-debug trick by itself, because the modern hacker tools do not support it at all :(