Subject: Re: UPX'ed image and debugger note [was Re: gcc-3.01 ...]
From: Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
To: djgpp-workers AT delorie DOT com
In-Reply-To: <7263-Fri21Sep2001102144+0300-eliz@is.elta.co.il>
References:  <10109202219 DOT AA14923 AT clio DOT rice DOT edu> 
	<7263-Fri21Sep2001102144+0300-eliz AT is DOT elta DOT co DOT il>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/0.13.99+cvs.2001.09.11.22.18 (Preview Release)
Date: 21 Sep 2001 12:31:15 +0200
Message-Id: <1001068276.15801.15.camel@bender.falconsoft.be>
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
Precedence: bulk

On Fri, 2001-09-21 at 09:21, Eli Zaretskii wrote:
> > 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?
It is built with DJGPP.
UPX-compressed executables are stripped and basically useless for
debugging anyway; if UPX-compressing a program introduces crashes, we're
probably better off submitting a bug report to Markus, rather than
fixing it on our own.

> If it is built with DJGPP, doesn't its memory layout violate some of
> the assumptions in dbgcom.c and v2load.c?
It uses a custom stub for its output files, so that is quite possible.

> > 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?

There's a UPX copyright string embedded in the image of UPX-compressed
executables; if that's loaded into memory (and it seems to be), we can
detect UPX.