From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10109202219.AA14923@clio.rice.edu>
Subject:	UPX'ed image and debugger note [was Re: gcc-3.01 ...]
To:	eliz AT is DOT elta DOT co DOT il
Date:	Thu, 20 Sep 2001 17:19:56 -0500 (CDT)
Cc:	djgpp-workers AT delorie DOT com
In-Reply-To:	<9743-Thu20Sep2001225317+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Sep 20, 2001 10:53:18 PM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
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

> > (Our debuggers
> > suppress reading the first 4K page, which must be re-enabled to debug
> > what's happening with UPX images).
> 
> Could you please elaborate on this?  I don't think I'm familiar with
> this issue.

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).

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.  It silently fails and doesn't set
the memory.  Try to run edebug32 on a UPXed image and observe :-)

If you want to see what's happening in the UPX decompressor before 
jumping to the initial starting address you must turn off the extra
read_child protection code.  Usually we assume UPX is bug free and
just decompress the image if we want to run it under a debugger.
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).

- Raw text -