Message-ID:	<005c01c2743f$2c714e60$0a02a8c0@p4>
From:	"Andrew Cottrell" <acottrel AT ihug DOT com DOT au>
To:	<djgpp-workers AT delorie DOT com>
References:	<10210141330 DOT AA25068 AT clio DOT rice DOT edu>
Subject:	Re: CLIO 2.04 exe to use UPX in the next update
Date:	Tue, 15 Oct 2002 21:36:28 +1000
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE:	Produced By Microsoft MimeOLE V6.00.2800.1106
Reply-To:	djgpp-workers AT delorie DOT com

> > UPX compressed DJGPP executables (built with last GCC versions) fails to
run
> > if uncompressed.
>
> Ouch.  But I think it's more likely that the problem is the new binutils?
I think you may be correct here. See below for what I found.

> A very interesting test would be:
>  1) create a DJGPP image
>  2) copy it away
>  3) UPX it
>  4) UPX decompress it
>  5) compare
>  6) What's changed?  Why different than previous?

I did this and it looks like the bytes betwen 800 hex and 1210 hex go
missing in action when I compared the original file and the uncompressed UPX
file.  The offset may not be exactly 800 as I didn't have time to
investigate it more. The bytes are 00 in the original file between 892 and
120F (inclusive)

ORIGINAL RM.EXE FILE
===================
0007D0  20 73 65 6C 65 63 74 6F 72 73 24 6E 6F 20 44 50   selectors$no DP
0007E0  4D 49 20 6D 65 6D 6F 72 79 24 90 90 90 90 90 90  MI memory$ÉÉÉÉÉÉ
0007F0  90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90  ÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉ
000800  4C 01 03 00 00 00 00 00 00 00 00 00 00 00 00 00  L??
000810  1C 00 0F 01 0B 01 00 00 F0 DD 01 00 00 22 00 00  ? ????  ­¦?  "
000820  00 58 00 00 10 12 00 00 10 12 00 00 00 F0 01 00   X  ??  ??   ­?
000830  2E 74 65 78 74 00 00 00 10 12 00 00 10 12 00 00  .text   ??  ??
000840  F0 DD 01 00 10 0A 00 00 00 00 00 00 00 00 00 00  ­¦? ??
000850  00 00 00 00 20 00 00 00 2E 64 61 74 61 00 00 00          .data
000860  00 F0 01 00 00 F0 01 00 00 22 00 00 00 E8 01 00   ­?  ­?  "   Þ?
000870  00 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00              @
000880  2E 62 73 73 00 00 00 00 00 12 02 00 00 12 02 00  .bss     ??  ??
000890  00 58 00 00 00 00 00 00 00 00 00 00 00 00 00 00   X
0008A0  00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00      Ç
0008B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...SNIP...
001200  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
001210  1E 07 F6 05 F1 F0 01 00 01 75 25 B8 10 12 00 00  ?.÷?±­? ?u%©??
001220  3D 00 10 00 00 7C 19 66 B8 07 05 64 8B 35 18 00  = ?  |?f©.?dï5?
001230  00 00 31 DB B9 01 00 00 00 BA 86 F0 01 00 CD 31    1???   ?å­? ?1
001240  66 8C DB 66 B8 0A 00 CD 31 73 04 B4 4C CD 21 66  fî?f©? ?1s??L?!f

DJGPP_204 C:\dj204\gnu\filutil4.0\src>objdump -h rm.exe
rm.exe:     file format coff-go32-exe
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0001ddf0  00001210  00001210  00001210  2**4
                  CONTENTS, ALLOC, LOAD, CODE
  1 .data         00002200  0001f000  0001f000  0001f000  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00005800  00021200  00021200  00000000  2**2
                  ALLOC

It looks like the data diplayed by the objdump -h is the data in the file
that goes missing.

UNCOMPRESSES UPX'D RM.EXE
==========================
0007C0  74 63 68 20 6D 6F 64 65 24 6E 6F 20 44 50 4D 49  tch mode$no DPMI
0007D0  20 73 65 6C 65 63 74 6F 72 73 24 6E 6F 20 44 50   selectors$no DP
0007E0  4D 49 20 6D 65 6D 6F 72 79 24 90 90 90 90 90 90  MI memory$ÉÉÉÉÉÉ
0007F0  90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90  ÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉÉ
000800  4C 01 03 00 00 00 00 00 00 00 00 00 00 00 00 00  L??
000810  1E 07 F6 05 F1 F0 01 00 01 75 25 B8 10 12 00 00  ?.÷?±­? ?u%©??
000820  3D 00 10 00 00 7C 19 66 B8 07 05 64 8B 35 18 00  = ?  |?f©.?dï5?
000830  00 00 31 DB B9 01 00 00 00 BA 86 F0 01 00 CD 31    1???   ?å­? ?1
000840  66 8C DB 66 B8 00 00 00 31 73 04 B4 4C CD 21 66  fî?f©   1s??L?!f

DJGPP_204 C:\dj204\gnu\filutil4.0\src>objdump -h rmupx.exe
c:/dj204/bin/objdump.exe: rmupx.exe: File format not recognized

Andrew

- Raw text -