Reverse Engineering Stack Exchange is a question and answer site for researchers and developers who explore the principles of a system through analysis of its structure, function, and operation. It only takes a minute to sign up.
Sign up to join this community
OpenWatcom's debugger just executes the binary instead of single-stepping through it, when I attempt the following steps:
File->Open, select executableRun->Trace IntoThis attempt is on Windows XP.
How do I single step through a program using OpenWatcom's debugger?
Okay, Windows XP, OpenWatcom. I am using OpenWatcom 1.9. When trying to reproduce your problem, I used calc.exe from Windows XP for which there are no Watcom debug symbols available (only the PDB format from Microsoft, which Watcom doesn't support at all).
When dismissing the open dialog from your first step, we get the assembly view like this. I am returning from that call (Run -> Until Return) a few times and realize that the call stack shows I am still in the loader phase.
The most logical thing to do now would be to break at either kernel32!BaseThreadInitThunk which is basically the entry point for any Win32 thread, including the very first in a process, but isn't exported (and, remember, we have no symbols). For a writeup on the startup process, see here or the "Windows Internals" book. The next possible candidate would be ntdll!RtlUserThreadStart which also isn't exported and therefore unavailable.
So, assuming you really have no modern debugger (WinDbg, cdb, let alone IDA, Hopper and friends) available, and don't want to use livekd.exe from SysInternals (which however requires a recent dbghelp.dll) the only method that seems to be reasonable is to load your target executable into an editor (CFF Explorer comes to mind) and put an int3 (cc) instruction at the entry point or simply move the entry point elsewhere. In my case I chose to overwrite the push 70h (6A 70) with int3; nop (CC 90). That enabled me to break at the beginning of the program (not considering TLS callbacks or anything like that, though).
Another less intrusive method is to use the above mentioned CFF Explorer or really any suitable tool to give you the VA of the entry point. Since we're talking about Windows XP we need not worry about ASLR or anything like that.
The entry point in our case is at RVA 0x12475, which the Address Converter translates to:
VA 0x1012475. Sweet. Now we can try to let OpenWatcom stop at this address. Setting a bpx at this address (Break -> View All -> Rightclick -> New, enter address) and then pressing F5 (for "Go") to skip the startup phase for the process gets us straight to the entry point.
From there we can use F8 for further single-stepping. And I'm sure similar to the experience we shared during the startup phase, any little thing that changed since the debugger was last adjusted to a more recent OS will trip you (or rather the OW debugger) up. Short of switching debuggers, you might want to make heavy use of Break -> On Debug Message, but even that seemed of little use when I tried it.
It's possible, but heck it's tedious and it may fall short of your needs at any point.
Quite frankly, some debuggers are better left alone when no source is available (assembly debugging). Admittedly I am not as familiar with the Watcom debugger as with GDB or WinDbg, but I've used it in the past and found it pure horror with symbols. That impression will likely only get worse without symbols. I find myself confirmed in that sense from looking into the issue you were experiencing.
OpenWatcom, while still being "developed" is old. Its roots are in the old Sybase product Watcom, which had a broad following. Problem is, that this product existed even before Windows 2000. So I don't think you can expect a lot from it, as most people these days are using compilers and debuggers with better support. Be it WinDbg or be it GDB if you happen to use MinGW or something like that.
