Re:Carving ELF Files
by joren485 on Sunday July 21, 2024 @04:19PM
(#41027790)
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.
Re:Carving ELF Files
by hashishen on Sunday July 21, 2024 @04:45PM
(#41027937)
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
Re:Carving ELF Files
by eqvinox on Sunday July 21, 2024 @04:50PM
(#41027980)
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.
Re:Carving ELF Files
by xgfh on Monday July 22, 2024 @08:35AM
(#41033671)
Really cool to see a deep dive into ELF file size optimization! For those who love getting into the nitty-gritty of binary formats, this post is a goldmine. It's fascinating how much you can trim down without sacrificing functionality. Has anyone here tried similar techniques for other binary formats or even for JavaScript minification? What were your results?
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...
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.
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.
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.