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