Proof-of-concept shared object injector that will eventually be integrated with PINCE.
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
examples
hypodermic
tests
wrapper
.gitignore
LICENSE
README.md
setup.cfg
setup.py

README.md

Hypodermic

The ability to inject a shared library into a program is generally very desirable, allowing a researcher to execute code from the address space of another process. The preferred method of performing this on Linux, specifying environment variables such as LD_PRELOAD, requires that the dynamic linker is present and supports it. In a majority of cases, this will work perfectly fine. In fact, this method is extremely powerful and any calls a binary makes to a library will be directed to the injected shared object. However, there are cases in which one would want to merely inject code to be run from a debugger, not caring about whether or not library calls made by the binary are redirected. There have been a few attempts at this in the past, such as linux-inject, which makes use of the __libc_dlopen_mode routine in glibc. This is oftentimes unsuccessful, being very dependent upon how glibc was compiled.

The purpose of Hypodermic is to find a means of injecting a dynamic library into any Linux executable, even ones that are statically-linked, and transferring this code into PINCE when it becomes stable enough. The current goal is the ability to inject an internal cheat into Counter-Strike: Global Offensive, such as AimTux. This will signal that the method has reached a point of viability.

Hypodermic is free software, licensed under the GNU General Public License.

Current Attempts

The initial, honestly quite naïve, attempt at implementing this was to inject code that would map the entire shared object into the address space of the inferior process, and only parsing the ELF data to get the offsets of library routines. This did not work, as the process of loading an ELF library into memory is far more complicated than calling mmap(2) on the file.

The second iteration also involves injecting code into the inferior process, but it instead maps the Linux runtime linker into memory, if it is not already there, and utilizes the internal _dl_open routine. This is difficult, as it requires mapping it the way the kernel would to ensure proper initialization.

Important Resources