[HN Gopher] Carving ELF Files
       ___________________________________________________________________
        
       Carving ELF Files
        
       Author : joren485
       Score  : 37 points
       Date   : 2024-07-21 13:27 UTC (9 hours ago)
        
 (HTM) web link (blog.nietaanraken.nl)
 (TXT) w3m dump (blog.nietaanraken.nl)
        
       | Moneysac wrote:
       | Interesting article. Did you try unblob as an alternative? It is
       | capable of extracting multiple file formats including elf
       | binaries.
        
         | joren485 wrote:
         | 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...
        
       | hashishen wrote:
       | 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
        
         | Retr0id wrote:
         | The switch uses NSO, a custom format
         | https://switchbrew.org/wiki/NSO
        
       | eqvinox wrote:
       | 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.
        
         | BobbyTables2 wrote:
         | 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.
        
       | kissgyorgy wrote:
       | 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...
        
       ___________________________________________________________________
       (page generated 2024-07-21 23:05 UTC)