[HN Gopher] ELF Statifier, self-contained dynamically linked exe...
       ___________________________________________________________________
        
       ELF Statifier, self-contained dynamically linked executables
        
       Author : turrini
       Score  : 23 points
       Date   : 2020-07-12 21:13 UTC (1 hours ago)
        
 (HTM) web link (statifier.sourceforge.net)
 (TXT) w3m dump (statifier.sourceforge.net)
        
       | enriquto wrote:
       | What about the -static compiler option? Why it's not good enough?
       | Is it possible to fix its shortcomings?
        
       | glandium wrote:
       | _" Statifier take "memory snapshot" of the process, created by
       | loader when loader ALREADY finish relocation and BEFORE loader
       | invoke any INIT function.
       | 
       | What now ? Now this "memory snapshot" should be somehow loaded
       | and run from the point were loader was stopped.
       | 
       | Who will be so kind to do it for us ? Kernel !
       | 
       | Let's save "memory snapshot", i.e. all segments from executable
       | and libraries loaded by loader as ELF file with program's header
       | of type 'LOAD' for each segment, and entry point set to the
       | address, where execution was stopped to take sharpshoot.
       | 
       | In this case, kernel will think, it's a statically linked
       | executable. (Because there is no 'INTERP' segment) As we already
       | know kernel load statically linked executable as following: -
       | load all 'LOAD' segment - jump to the executable's entry point.
       | 
       | That's it !"_
       | 
       | So the way it works kills ASLR. But it should be possible to do
       | something similar, keeping all relocations, and that still works
       | with ASLR (but that would need an INTERP).
        
       | user555555555 wrote:
       | How does this compare with the flatpak/snap strategy of mounting
       | a filesystem?
        
         | fao_ wrote:
         | flatpak/snap still rely on libraries. This only relies on
         | filesystem features and kernel functions which are static. As
         | such, the resulting binaries (stripped of GNU_* symbols) can
         | run on a musl system. I've had a lot of trouble getting flatpak
         | programs to run on my musl system.
        
       | JoshTriplett wrote:
       | This sounds a lot like emacs' old "undump" system, which ran the
       | program, loaded a pile of elisp code, made itself dump core, then
       | tried to massage the core dump into a runnable program.
       | 
       | Emacs ended up dropping that system because it was wildly
       | incompatible with aspects of modern systems.
        
         | leotaku wrote:
         | Modern Emacs (27 and up I think) has a new so-called "portable
         | dumper"[^1]. I've only played a little bit with it, but it does
         | ridiculously speed speed up some things. Don't really need it,
         | but it's cool anyways.
         | 
         | [^1]: https://dancol.org/pdumperpres.pdf
        
         | app4soft wrote:
         | For modern systems there is AppImage.
        
       ___________________________________________________________________
       (page generated 2020-07-12 23:00 UTC)