From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10109211323.AA16761@clio.rice.edu>
Subject: Re: UPX'ed image and debugger note [was Re: gcc-3.01 ...]
To: djgpp-workers AT delorie DOT com
Date: Fri, 21 Sep 2001 08:23:46 -0500 (CDT)
Cc: laszlo DOT molnar AT eth DOT ericsson DOT se
In-Reply-To: <20010921125243.K4845@libra.eth.ericsson.se> from "Laszlo Molnar" at Sep 21, 2001 12:52:43 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

> No, UPX does use the original djgpp stub. Just like newer versions of
> DJP. The memory layout should not be a problem, page zero gets
> protected after the uncompression is finished.

And after the decompression runs the memory image looks just like it
would after a normal stub execution, but we jump to it from the first 4Kb
page instead of the stub. 

The point of the original (too terse) note was to point out that 
the CS:EIP plus SS:ESP signature looked possibly like UPX decompressor 
and we needed to hack the debugger if you wanted to look at it.

Since the same images seem to work on other machines (?) I would have
to suspect hardware failure or uninitialized variable.

> I'll look at the problem, if the problem is really caused by UPX. Can
> anybody confirm this?

This is currently a Wild Assed Guess based on a 30 second examination of
an unexplained crash.

I would like to see if the crash goes away by decompressing the image,
and if it is reproducible before pointing the finger only at UPX. 

After all, I did recommend that we start using it for distributions ...