Can't run binaries compressed with UPX

[nomisbeme]

Build 14332:

apt install upx-ucl
upx-ucl -8 /bin/ls -o ./lscompressed
./lscompressed
bash: ./lscompressed: cannot execute binary file: Exec format error

The call to execve fails, output from strace attached.

[Artoria2e5]

// typo in title: s=UPC=UPX=g

This is what upx'ed programs look like in objdump:

objdump -x -f -h -p ./bash

./bash:     file format elf64-x86-64
./bash
architecture: i386:x86-64, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x0000000000471eb0

Program Header:
    LOAD off    0x0000000000000000 vaddr 0x0000000000400000 paddr 0x0000000000400000 align 2**21
         filesz 0x00000000000726c4 memsz 0x00000000000726c4 flags r-x
    LOAD off    0x0000000000102878 vaddr 0x0000000000702878 paddr 0x0000000000702878 align 2**21
         filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw-

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
SYMBOL TABLE:
no symbols

[skochinsky]

why is this labeled "feature" and not "bug"? UPXed files are proper (if a little unusual) ELFs, they should at least start without issues. There are no errors in the file format.

[skochinsky]

@benhillis @ionescu007 (sorry Alex :)
Can someone confirm if this is caused by the absence of NT_GNU_ABI_TAG note (hinted by #2121)? And please retag it as a bug, not feature. Such files run fine on regular Linux.

[benhillis]

A fix for this issue has been checked in and will be available in a Windows Insider build soon.

@skochinsky - The bug versus feature tags are somewhat arbitrary, don't get too caught up on them.

[ionescu007]

Great @benhillis, now you're training people that by CC'ing me, bugs get fixed instantly.

[nomisbeme]

I can confirm that this was fixed in Build 17017. Is there a definitive source to check when the fix landed before that? I'm curious if it made the Creators Update.

[Herst]

@nomisbeme It didn't, see https://msdn.microsoft.com/en-us/commandline/wsl/release_notes.

[nomisbeme]

Thanks for the response Herst. I really appreciate the link to the detailed release notes.

[sunilmut]

This should be fixed in the Insider build 17017.

[essbedev]

I had issues installing PVRTexToolCLI on previous builds and it's actually been resolved from Insider build 17017. I still get the same error when I try to install the FBX SDK . I can't figure out if it's the same problem though.

[benhillis]

@essbedev - Might be hitting the same issue as #1884. The fix for that should be available soon.

[essbedev]

@benhillis amazing ! thanks for the quick answer

[benhillis]

@essbedev - Downloaded the binary you attached and unfortunately it's not the same thing. Your binary is 32 bit which is not currently supported by WSL (#2468).

root@BENHILL-VM2:~# readelf -h fbx20151_fbxsdk_linux
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x80480f0
  Start of program headers:          52 (bytes into file)
  Start of section headers:          466356 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         4
  Size of section headers:           40 (bytes)
  Number of section headers:         23
  Section header string table index: 20

[sayangel]

Was also just trying to set up the FBX SDK on WSL and hit this issue. @essbedev were you able to figure out an alternative?

[therealkenc]

@sayangel Try 17093 or better per #1884. If your scenario still fails it would be worthy of a new ticket following CONTRIBUTING.md.

[essbedev]

@sayangel, I created a topic on the Autodesk FBX forum but never got an answer... https://forums.autodesk.com/t5/fbx-forum/compatibility-with-wsl-x64/m-p/7739197/highlight/true#M9178

[therealkenc]

Ahh understood; if they only provide 32-bit binaries that's #2468 which is unrelated to "this issue" (which is about UPX). There is no work-around unfortunately (unless you work at Autodesk). There's a User Voice here for what it's worth.

[eflukx]

@sunilmut This issue was closed:

This should be fixed in the Insider build 17017.

But problem seems to persist; well into the newer Win10/WSL releases. Shouldn't this be reopened ?

Also tracked at: upx/upx#201

[bashscr]

I am having problems on WSL1 with this at the moment. upx/upx#201