Date: Fri, 21 Sep 2001 08:53:39 +0300 (WET) From: Andris Pavenis X-Sender: pavenis AT ieva06 To: djgpp-workers AT delorie DOT com Cc: eliz AT is DOT elta DOT co DOT il Subject: Re: UPX'ed image and debugger note [was Re: gcc-3.01 ...] In-Reply-To: <10109202219.AA14923@clio.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Thu, 20 Sep 2001, Charles Sandmann wrote: > > > (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). > One can simply test whether UPX is guilty in these problems under WinNT: Binaries can be unpacked with UPX-1.20 (I used this version), for example: upx -d cc1.exe If that fixes the problem, we should suspect UPX and I should avoid using UPX in nearest future However I checked that binaries of gcc-3.0 (ones from v2gnu/alphas) was also compressed with the same UPX version and I didn't get messages about similar instability. Perhaps one should test that once more Andris