#72 Problems with executables generated by Excelsior-JET
Hello,
I tried to process some executables generated by Excelsior-JET (a java->x86 compiler), however windows-executables crash at startup with a segfault and on Linux upx stops with "UnknownExecutableFormatException".
The segfault occurs at the same adress as with PECompact2, and even happens when running on wine (the uncompressed executable works to some degree).
I attached the original file, one compressed with PECompact, one compressed with upx/windows and a linux-version (not compressable with upx).
The linux-version won't work of course out-of-the-box because the runtime-files are for windows.
The files need to be copied to the directory to work (find runtime files, dlls, ...).
If you need further help or information, please don't hestitate to contact me. Thanks a lot for UPX :-)
lg Clemens
PS: These are the messages emited when running the compressed executable under wine:
[ce@localhost Jode]$ wine Jode_compressed.exe
libGL warning: 3D driver claims to not support visual 0x5b
wine: Unhandled page fault on read access to 0x00000008 at address 0x71d279 (thread 0009), starting debugger...
Unhandled exception: page fault on read access to 0x00000008 in 32-bit code (0x0071d279).
Register dump:
CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b
EIP:0071d279 ESP:0033fea0 EBP:0033fea0 EFLAGS:00010203( - 00 - RI1C)
EAX:00b82cb8 EBX:7eec3884 ECX:00000000 EDX:004001c9
ESI:00b82cb8 EDI:00b82cb8
Stack dump:
0x0033fea0: 0033fed0 0071e320 00b82cb8 0033febc
0x0033feb0: 0033fec0 0033fec4 0033fec8 00b82cf8
0x0033fec0: 00b82cfc 0033feec 009b639b 00400000
0x0033fed0: 0033feec 009b63a1 00b82cb8 00000000
0x0033fee0: 0033fef8 7ffdf000 00401000 0033ffe8
0x0033fef0: 007ad2c5 00400000 00b82cb8 007ad270
Backtrace:
=>1 0x0071d279 in jode_compressed (+0x31d279) (0x0033fea0)
2 0x0071e320 in jode_compressed (+0x31e320) (0x0033fed0)
3 0x009b63a1 in jode_compressed (+0x5b63a1) (0x0033feec)
4 0x007ad2c5 in jode_compressed (+0x3ad2c5) (0x0033ffe8)
5 0xb7e5f547 (0x00000000)
0x0071d279: movl 0x8(%ecx),%edx
Modules:
Module Address Debug info Name (53 modules)
ELF 1a1000- 1e7000 Deferred libsepol.so.1
PE 400000- 115e000 Export jode_compressed
PE 400000- 115e000 Export jode_compressed
PE 400000- 115e000 Export jode_compressed
PE 400000- 115e000 Export jode_compressed
PE 400000- 115e000 Export jode_compressed
PE 400000- 115e000 Export jode_compressed
PE 400000- 115e000 Export jode_compressed
PE 400000- 115e000 Export jode_compressed
PE 400000- 115e000 Export jode_compressed
PE 400000- 115e000 Export jode_compressed
PE 400000- 115e000 Export jode_compressed
PE 400000- 115e000 Export jode_compressed
PE 400000- 115e000 Export jode_compressed
ELF 4a1a2000-4a2a4000 Deferred libx11.so.6
ELF 4a2a6000-4a2b6000 Deferred libxext.so.6
ELF 4a2b8000-4a2bb000 Deferred libxinerama.so.1
ELF 4a2bd000-4a2c6000 Deferred libxrender.so.1
ELF 4a2c8000-4a2cd000 Deferred libxfixes.so.3
ELF 4a2cf000-4a2d9000 Deferred libxcursor.so.1
ELF 4a2db000-4a2df000 Deferred libxrandr.so.2
ELF 4ae7d000-4af8f000 Deferred libwine.so.1
ELF 4b732000-4b737000 Deferred libxxf86vm.so.1
ELF 4b745000-4b7b3000 Deferred libgl.so.1
ELF 4d4d1000-4d500000 Deferred libfontconfig.so.1
ELF 4d76a000-4d78b000 Deferred libexpat.so.0
ELF 7bf00000-7bf03000 Deferred <wine-loader>
ELF 7c94e000-7c963000 Deferred midimap<elf>
\-PE 7c950000-7c963000 \ midimap
ELF 7c963000-7c98b000 Deferred msacm32<elf>
\-PE 7c970000-7c98b000 \ msacm32
ELF 7c98b000-7c9a3000 Deferred msacm32<elf>
\-PE 7c990000-7c9a3000 \ msacm32
ELF 7c9a3000-7c9e0000 Deferred wineoss<elf>
\-PE 7c9b0000-7c9e0000 \ wineoss
ELF 7c9e0000-7ca73000 Deferred winmm<elf>
\-PE 7c9f0000-7ca73000 \ winmm
ELF 7ca82000-7ca9f000 Deferred imm32<elf>
\-PE 7ca90000-7ca9f000 \ imm32
ELF 7e412000-7e672000 Deferred i915_dri.so
ELF 7e83e000-7e8d1000 Deferred winex11<elf>
\-PE 7e850000-7e8d1000 \ winex11
ELF 7e9af000-7e9f8000 Deferred advapi32<elf>
\-PE 7e9c0000-7e9f8000 \ advapi32
ELF 7e9f8000-7ea97000 Deferred gdi32<elf>
\-PE 7ea10000-7ea97000 \ gdi32
ELF 7ea97000-7ebe3000 Deferred user32<elf>
\-PE 7eab0000-7ebe3000 \ user32
ELF 7ee09000-7ef3c000 Deferred kernel32<elf>
\-PE 7ee20000-7ef3c000 \ kernel32
ELF 7ef63000-7f000000 Deferred ntdll<elf>
\-PE 7ef80000-7f000000 \ ntdll
ELF b7cf3000-b7cfe000 Deferred libnss_files.so.2
Threads:
process tid prio (all id:s are in hex)
00000008 (D) Z:\home\ce\jode\Jode\Jode_compressed.exe
00000009 0 <==
Logged In: YES
user_id=431708
Originator: YES
because of the size-constraints I uploaded the runtime+executable files to my university home.
Simply download, extract and the uncompressed windows executable should work fine.
http://stud4.tuwien.ac.at/~e0625701/excelsior_test.zip
Logged In: YES
user_id=431708
Originator: YES
I tried a few differed packers for windows, and only aspack works. (PECompact, upx, petite, ww32pack, aspack, ...)
However as it seems it does not suppport in-place decompression and therefor wastes RAM :-/
Logged In: YES
user_id=11898
Originator: NO
This program seems to be trying to locate one its section (.jidata) by looking at its PE header in the memory. Unfortunately it can only see the UPX modified PE header, which results in the crash. There is nothing I can do about this, sorry.
UPX fails with the linux/elf file because the file has more than 14 program headers. So I pass this bug to John, he must know why this magic constant is there.
Laszlo
Logged In: YES
user_id=431708
Originator: YES
is there no possibility of working arround this problem - maybe by specifying that this section should be not compressed or maybe some hooking tricks?
Why does it work with ASPack? I guess its not nearly as cool as upx, as it seems it does not support in-location-decompression :-/
lg Clemens
Logged In: YES
user_id=11898
Originator: NO
I guess aspack keeps the original PE header, that's why it works with this file and that's why it can not do inplace decompression. Currently there is no support for keeping the original PE header in UPX compressed files, and it looks quite a bit of work with not too much gain. Sorry.
L
Logged In: YES
user_id=33687
Originator: NO
The file jode_linux from excelsior_test.zip has 23 Elf32_Phdr structures; see the output from "readelf --segments jode_linux" below. This means that they occupy more than (512 - sizeof(Elf32_Ehdr)) bytes. It is a long-standing tradition, more than thirty years old, that the program headers should fit into one disk block of 512 bytes. Why? Because software which processes the ELF32_Phdr must scan them all, and it can be very inconvenient to allocate the space dynamically. The upx runtime stub decompressor would have to go through more tricks, which is cumbersome and takes instructions which occupy space.
Inspecting the headers for jode_linux reveals that they are wasteful. For instance, there are separate PT_LOAD with the same attributes "R " for each page in the range 0x08fb2000 upto 0x08fb9000, which wastes 6 PT_LOAD. There are also four other (non-contiguous) read-only one-page PT_LOAD, and two other multiple-page PT_LOAD that are also read-only. Combine these appropriately; then jode_linux will fit into 14 Phdr. You will also get better compression, because each PT_LOAD is compressed separately. Of course the compressor could combine adjacent PT_LOAD whose address ranges are contiguous. But then the decompressor would have to do the same thing, and that is complexity that takes bytes of code in the stub. It is much simpler to treat each PT_LOAD separately. That is their purpose!
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x002e0 0x002e0 R 0x4
INTERP 0x000314 0x08048314 0x08048314 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
LOAD 0x000000 0x08048000 0x08048000 0x01000 0x01000 R 0x1000
LOAD 0x001000 0x08049000 0x08049000 0x732000 0x732000 R E 0x1000
LOAD 0x733000 0x0877b000 0x0877b000 0x27f000 0x27f000 RW 0x1000
LOAD 0x9b2000 0x089fa000 0x089fa000 0x01000 0x1d0000 RW 0x1000
LOAD 0x9b3000 0x08bca000 0x08bca000 0x37f000 0x37f000 R 0x1000
LOAD 0xd32000 0x08f49000 0x08f49000 0x01000 0x01000 RW 0x1000
LOAD 0xd33000 0x08f4a000 0x08f4a000 0x66000 0x66000 R 0x1000
LOAD 0xd99000 0x08fb0000 0x08fb0000 0x01000 0x01000 RW 0x1000
LOAD 0xd9a000 0x08fb1000 0x08fb1000 0x01000 0x01000 R E 0x1000
LOAD 0xd9b000 0x08fb2000 0x08fb2000 0x01000 0x01000 R 0x1000
LOAD 0xd9c000 0x08fb3000 0x08fb3000 0x01000 0x01000 R 0x1000
LOAD 0xd9d000 0x08fb4000 0x08fb4000 0x01000 0x01000 R 0x1000
LOAD 0xd9e000 0x08fb5000 0x08fb5000 0x01000 0x01000 R 0x1000
LOAD 0xd9f000 0x08fb6000 0x08fb6000 0x01000 0x01000 R 0x1000
LOAD 0xda0000 0x08fb7000 0x08fb7000 0x01000 0x01000 R 0x1000
LOAD 0xda1000 0x08fb8000 0x08fb8000 0x01000 0x01000 R 0x1000
LOAD 0xda2000 0x08fb9000 0x08fb9000 0x01000 0x01000 RW 0x1000
LOAD 0xda3000 0x08fba000 0x08fba000 0x01000 0x01000 R 0x1000
LOAD 0xda4000 0x08fbb000 0x08fbb000 0x01000 0x01000 R 0x1000
DYNAMIC 0xda2000 0x08fb9000 0x08fb9000 0x000a8 0x000a8 RW 0x4
LOAD 0xda5000 0x08fbc000 0x08fbc000 0x01000 0x01000 R 0x1000
Logged In: YES
user_id=431708
Originator: YES
Ok, thanks a lot for your patience with finding the problem.
I'll compress all "default"-dlls (not made with excelsior) with upx and the executable with aspack.
In a test-run I came down from ~22mb to 8mb redistributable :-)
Thanks a lot for UPX, its a great project :-)
lg Clemens
Logged In: YES
user_id=431708
Originator: YES
well sad that it has been closed - in fact both executables are perfectly valid.
Yes maybe they do unusual things and some thing not quite right, but they load and work - both under Win98/NT/2000/XP/Vista and not with UPX.
The linux version does not even do crazy things and still does not compile.
Well and both cases are closed - although at least the problems on linux shouln't cause too much trouble, roght?
Well, sad :-/
Thanks for upx, lg Clemens