Date: Fri, 21 Sep 2001 10:21:44 +0300 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: sandmann AT clio DOT rice DOT edu Message-Id: <7263-Fri21Sep2001102144+0300-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9 CC: djgpp-workers AT delorie DOT com In-reply-to: <10109202219.AA14923@clio.rice.edu> (sandmann@clio.rice.edu) Subject: Re: UPX'ed image and debugger note [was Re: gcc-3.01 ...] References: <10109202219 DOT AA14923 AT clio DOT rice DOT edu> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > 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.