ELF Statifier, self-contained dynamically linked executables
statifier.sourceforge.net
statifier.sourceforge.net
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).
Emacs ended up dropping that system because it was wildly incompatible with aspects of modern systems.
Sounds useful if you have to work with some limited/restricted systems where you cannot just install something.
However, the listed limitations sound like a blocker in every somewhat modern distro. No ASLR, no VDSO. ASLR can be disabled temporarily or for selected processes, but disabling VDSO is not easy without reboot I believe (have never tried)
Did not understand whether the limitations apply to source or target system or both.
Maybe there is a reason that this promising tool is not well-known? Or does anybody here use it?
Yet you can still compile a static executable that calls the dlopen function. And you can also select (by using some -B and -W magic options) exactly which libraries you want to link statically and dynamically on your executable. It is a bit painful but it works. The only thing that does not work is when you rely on GPU code, where your program needs to be linked directly to specific graphics drivers. I hope in a few years the kernel itself will allow a gpu abstraction for that to work.
Great point about musl. To distribute (your) program as a linux static binary, write it in standard C and compile it using musl.
That's an understatement... especially if you're using autotools with libtool. Which, coincidentally, seems to be unmaintained. I tried submitting a patch on their GNU Savannah[1], and it's soon celebrating its second birthday... last official release in 2015...
And yet this is the "GNU standard" which a huge part of the packages found on an average Linux install - especially the smaller and more foundational pieces - are built with. It's mindbogglingly sad.
Then you had it coming!
I do not understand why, in this day and age, the autotools shitfuckery is still necessary. You can write a portable makefile that will compile your program on all widespread unixes (linux distros, all the BSDs and macOS). Using CI tools you can verify in a few minutes whether it compiles correctly everywhere. The autotools and cmake systems are most often useless cruft (except if you want to compile on windows, in that case cmake is probably inevitable).
From a portability standpoint, the above could be done with zero OS-specific dependencies, and you could add features depending on the OS. By default you just run the executable with modified environment variables to try to automatically locate things like libraries and other binaries automatically. Then you add chroot, overlayfs, namespaces, control groups, etc as they are available to improve compatibility.
It's much, much easier to just download a binary and compare its cryptographic hash with the origin's before running it. That's how all Linux distributions ship apps, and Windows has a slightly more modern version of that.
Closed binaries tend to come from corporations and are often full of nasty things, wether the hash verifies or not isn’t the problem.