Show HN: ELF Injector • Hacker News Board

Re: Show HN: ELF Injector

#11

Post by dillstead » Tue, Jul 29, 2025, 9:23 PM UTC

nekitamo wrote: post #9

Interesting, I also had to solve this problem about a decade ago when writing a binary packer for Android .so libraries. I ended up moving the first few Pheaders around to make space for a new entry in the Elf32_Phdr table, and then used that to inject a new code segment at the end of the file. Due to padding constraints this could sometimes add a significant amount of null bytes to the binary just for padding. I als…

You're right, you definitely can strip away the section headers. Notice that there's always a dynamic segment? If there wasn't, stripping away the section headers would make it very difficult to locate this very important piece of an ELF binary.

I had to make sure that I always inserted a page size multiple of bytes into the executable which can add up to a page of unused padding in addition to the thunk and chunk.

Re: Show HN: ELF Injector

#12

Post by wahern » Wed, Jul 30, 2025, 12:05 AM UTC

matheusmoreira wrote: post #8

Always cool to see people hacking ELF! I see you're using argv[0] to find the executable file. This is fragile because argument vector contents are arbitrary and controlled entirely by the parent process. In other words, argv[0] could contain anything, even an empty string. If you're targeting Linux specifically, there's a better way: /proc/self/exe. I created something similar to your tool: an ELF embedder. It's for…

IME it's far more likely for a program to run in an environment lacking /proc (e.g. some containers) than for argv[0] to be NULL, empty, or lying. Even /proc/self/exe can been used in an exploit chain (https://lwn.net/Articles/920384/). And there have been many other /proc-related exploits, which is why it's often a good idea to not even mount /proc at all rather than just mask /proc subtrees.

But even if /proc/self/exe is visible, it might not be possible to open it. For example, you can execute a binary residing in anonymous memory (memfd) using fexecve(2), or the executable file could have been deleted immediately after execution. AFAIU, /proc/self/exec is generated as a symlink rather than exposing the file object directly (cf. BSD /dev/fd), so opening it can fail.

The easy fix is to just simply fail if argv[0] is NULL or empty, but if one is a glutton for punishment and wants to be "robust", /proc/self/exe support could be added as a (preferred) alternative rather than a substitute mechanism.

Re: Show HN: ELF Injector

#13

Post by wahern » Wed, Jul 30, 2025, 2:11 AM UTC

wahern wrote: post #12

matheusmoreira wrote: post #8

Always cool to see people hacking ELF! I see you're using argv[0] to find the executable file. This is fragile because argument vector contents are arbitrary and controlled entirely by the parent process. In other words, argv[0] could contain anything, even an empty string. If you're targeting Linux specifically, there's a better way: /proc/self/exe. I created something similar to your tool: an ELF embedder. It's for…

IME it's far more likely for a program to run in an environment lacking /proc (e.g. some containers) than for argv[0] to be NULL, empty, or lying. Even /proc/self/exe can been used in an exploit chain ( https://lwn.net/Articles/920384/ ). And there have been many other /proc-related exploits, which is why it's often a good idea to not even mount /proc at all rather than just mask /proc subtrees. But even if /proc/sel…

EDIT: I was wrong, /proc/self/exe is directly openable, even if the path returned by readlink doesn't exist.

Re: Show HN: ELF Injector

#14

Post by dillstead » Wed, Jul 30, 2025, 2:43 PM UTC

viccis wrote: post #6

How does it fare on Virustotal? Most of the these projects (often intended as packers or similar obfuscation techniques for malware) that I've seen are cool but get flagged aggressively.

I wouldn't be surprised if this gets flagged but I haven't tried it.