[Question] Why does this ELF not work?

[NyanUwU]

I'm sorry if this has an obvious answer (I'm a reverse-engineering rookie).
I am currently participating in a CTF (capture the flag - reversing challenge).
I have a Linux binary (ELF) and tried to load it into Snowman.
All I get is an empty window tho. Any other binary worked fine.

The binary I tested it with:
fa467b0b-14c5-4e24-8107-a2252c0ab789.elf.zip
_{[ Completely harmless. qt application which asks for a serial number and username (ACSC), we're supposed to reverse the (probably hard-coded) serial key. ]}

I'm on Ubuntu 20.04 and built from source.
Disassembling with Ghidra, IDA and Cutter works just fine. The "Analyse" -> "Disassemble" option in Snowman yields:

Sorry, the file you are currently working on does not contain any information about sections. There is nothing I could disassemble.

---

[yegord]

The file indeed contains no sections, and the decompiler uses the information from the sections table to understand what to disassemble and subsequently to decompile.

I guess, it should look at PT_LOAD ELF program headers instead of or in addition to the list of sections.
Would you like to extend ElfParser to parse program headers?

[NyanUwU]

I don't know if I'm able to. I'm mostly coding in JS/NodeJS, Java and PHP (only did this CTF for fun). But I can try.
Also thanks for the clarification!

[yegord]

I have created a branch with a proof-of-concept implementation: https://github.com/yegord/snowman/tree/parse-elf-program-headers

However, there is an issue:

[yegor@yegor snowman]$ LANG=C objdump -x tests/hand-made/002_gcd 

tests/hand-made/002_gcd:     file format elf64-x86-64
tests/hand-made/002_gcd
architecture: i386:x86-64, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x00000000004000e8

Program Header:
    LOAD off    0x0000000000000000 vaddr 0x0000000000400000 paddr 0x0000000000400000 align 2**21
         filesz 0x0000000000000158 memsz 0x0000000000000158 flags r-x
    LOAD off    0x0000000000001000 vaddr 0x0000000000601000 paddr 0x0000000000601000 align 2**21
         filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw-
   STACK off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**3
         filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw-

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .rela.plt     00000000  00000000004000e8  00000000004000e8  000000e8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .plt          00000000  00000000004000e8  00000000004000e8  000000e8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .text         00000032  00000000004000e8  00000000004000e8  000000e8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .eh_frame     00000038  0000000000400120  0000000000400120  00000120  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .got.plt      00000000  0000000000601000  0000000000601000  00001000  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  5 .comment      0000001c  0000000000000000  0000000000000000  00001000  2**0
                  CONTENTS, READONLY

The problem is, it is not the .text section that is loaded by the PT_LOAD program header — it is something larger, which does not contain only code, but also, e.g., (like in the above example) the ELF headers themselves.

When Snowman tries to decompile everything that is loaded and marked as executable, it also disassembles all the garbage which is not code.

Does anybody have an idea of how to relatively easy avoid trying to decompile all the extra stuff?

[NyanUwU]

Just tested with the parse-elf-program-headers branch. Decompiled successfully! I don't think the decompiled header data isn't too much of an issue (in my case at least).
Thank you for your amazing work with this project. I wish I could be of more help in regards to the problem with the garbage data.