8 ms·

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 investigati

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?

oguz-ismail2 9mo ago
Choke how? Both work fine here
- wasmperson 9mo ago
  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.
saidnooneever 9mo ago
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.
- weinzierl 9mo ago
  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.
  - saidnooneever 9mo ago
    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
weinzierl 9mo ago
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.html 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.

oguz-ismail2 9mo ago

Choke how? Both work fine here

wasmperson 9mo ago
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.

saidnooneever 9mo ago

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.

weinzierl 9mo ago
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.
- saidnooneever 9mo ago
  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

weinzierl 9mo ago

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.html 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.