Comment by wasmperson | Hacker News Reader

Comment by wasmperson | Hacker News Reader

I extracted the linux executable and was surprised to find that both readelf and objdump choke on it despite it loading and running correctly. Some investigation reveals that the name of the dynamic linker was shoved into the "unused" fields in the PT_DYNAMIC header entry to save space:

  Program Headers:
    Type           Offset             VirtAddr           PhysAddr
                   FileSiz            MemSiz              Flags  Align
    INTERP         0x0000000000000088 0x0000000000010088 0x0000000000010088
                   0x000000000000001c 0x000000000000001c         0x0
        [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
    DYNAMIC        0x00000000000000e0 0x00000000000100e0 0x6c2f343662696c2f  <-- "/lib64/ld-linux-x86-64.so.2"
                   0x2d78756e696c2d64 0x732e34362d363878         0x322e6f
  readelf: Error: the dynamic segment offset + size exceeds the size of the file
    LOAD           0x0000000000000000 0x0000000000010000 0x0000000000000000
                   0x0000000000001dc0 0x0000000000005660  RWE    0x1000

Two questions:

1. Was this done manually or is there a tool you're using which does this? I see other size-reduction tricks in here as well.

2. Does anybody know of a tool for examining executables which doesn't crap out on binaries like this?

The famous

"A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux"

tutorial has some good answers for you.

https://www.muppetlabs.com/~breadbox/software/tiny/teensy.ht...

In short: Compilers don't help l, but with a good macro assembler it is quite convenient. Maybe the author used custom tooling but the assembler route is the easiest if you only need this once or a couple of times.

To the second question, reverse engineering software like IDA Pro or Binary Ninja are not only made for strange and broken binaries but often used for binaries with deliberate anti-reversing measures. They are as good as it gets when it comes to not choking on unusual binaries.

EDIT: Forgot to mention Ghidra.

ndisasm can help read it and hex editor. no tools should mangle such format, its useless savings, worth nothing. it will cause problem with AV and other things potentially.

saw some comments about DEP on windows and this and honestly i wouldnt touch this thing with a 10ft stick. if the creator want ppl to play it they can provide a normal binary. not some obfuscated mess.

This is a slippery slope. I could agree if the OS would load it. Maybe the OS shouldn't load it.

But as long as it is good enough for the OS it should be good for the malware scanner as long as it is not real malware. If we start punishing everything that deviates just a little bit from the norm we will end in no good place.

tools output validly formatted files for a reason. there is not really a good reason to mess with headers etc. , the savings are so tiny its only fun for obfuscation or tiny binary contests...

imagine, this linker name string.. its few bytes from 13K bytes. does nothing useful.

a lot of parsers of file formats do ignore most fields as do linkers/loaders. AV engines look a little more at it and might trigger on anomalies simply because its indicative of tampering (not neccesarily malicious).

deviating from the norm is fine as long as its grounded in a good reason, and clearly explained. simply pushing some weirdly formatted binary without any explanation, thats not very strategical in today's landscape of messed up binaries and threats. - just my 2 cents ofc.. im not an authority on the matter :p

Choke how? Both work fine here

Since the program opens a window I wanted to see what the dependencies were, but neither readelf nor objdump can display the contents of the dynamic section despite ld.so correctly finding and parsing it. readelf spits out the error that you can see in my post above, while objdump complains about section alignment and otherwise doesn't say anything helpful at all.

Reply on news.ycombinator.com