Carving ELF Files | Hacker News Reader

Carving ELF Files

blog.nietaanraken.nl

73 pointsjoren4859 comments

The approach taken there is unfortunately not correct. The existence of sections (and section headers) is completely optional for ELF files; you can have valid executables and libraries without them. `sstrip` [https://github.com/aunali1/super-strip] can be used to generate such files.

The correct approach is to process the program headers and find the tail end of anything referenced in PT_LOAD as well as from DT_DYN items.

You can combine that with a section based approach; if the file has debug information it won't be covered by program headers and you'd end up cutting it off if going purely by program headers. However, this is technically optional while the program header based approach is really required.

I fully agree, and the approach of relying on the original ELF file headers of any kind seems very strange to me.

When a memory dump is taken, the program could have dynamically allocated memory, which will always be in segments of memory outside those described by the ELF file. (Even before main() executes)

The approach also ignores dynamic libraries loaded, and also won’t handle a relocatable ELF.

One really has to look at /proc/PID/maps to see the actual memory ranges used by the process.

Thank you for your feedback!

I improved my post (and my carver) by including parsing the program headers as well.

Also, thanks for the suggestion of super-strip. An interesting tool that I will play around with.

I think it's more complicated. If you are interested in a real-world implementation, check out our ELF parser: https://github.com/onekey-sec/unblob/blob/main/unblob/handle...

Interesting article. Did you try unblob as an alternative? It is capable of extracting multiple file formats including elf binaries.

Thanks!

I haven't really looked at alternative carvers (but I am aware that many great options exist). I didn't know unblob yet. Thanks for the suggestion!

Looking at the code, they use the same methodology as I describe in the post [0]. They do, however, also check for the end of the last segment, which is interesting.

[0] https://github.com/onekey-sec/unblob/blob/112da43587c80cc3a7...

I remember elf from wii homebrew. Not sure if they're being used in the current Nintendo ecosystem but I'm wondering if this would make deconstruction of older games easier for modding like they did with SM64

The switch uses NSO, a custom format https://switchbrew.org/wiki/NSO

What, they pivoted away from phone hacking?

Reply on news.ycombinator.com