Mail Archives: djgpp-workers/2001/09/21/03:27:06
> From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> Date: Thu, 20 Sep 2001 17:19:56 -0500 (CDT)
>
> The way UPX works is it is a small decompressor - less than 4Kb. It is
> built to load itself in the 0-0x1000 address spaces, with the image data
> stored after it. So, if you load a UPX image in the debugger, you
> will see an EIP of less than 0x1000 (and typically a meaningless
> instruction stream if you disassemble).
Is UPX built with DJGPP? If not, what use is it to try to debug it
with DJGPP debuggers?
If it is built with DJGPP, doesn't its memory layout violate some of
the assumptions in dbgcom.c and v2load.c?
> dbgcom (in the read_child routine) has some "extra" code to prevent
> hitting the child's null page protection - it won't attempt to touch
> addresses less than 4096 bytes.
Right, and for a good reason. We could of course avoid doing that if
UPX is involved, but we need a way to detect this situation. Can you
suggest how to detect that?
> But if the EIP crash point is in UPX it would be interesting to debug
> the decompressor itself (thus the need to turn off the protection).
A user of a debugger might also want to turn off null page protection
if they want to put a watchpoint on it. This might come handy for
debugging on Windows, where we don't get a SIGSEGV in the debuggee
when it dereferences a NULL pointer.
- Raw text -