artemis21/ptrace-inject

Shared library injection for *nix using ptrace, in Rust.

ptrace-inject

ptrace-inject is a tool for injecting code into a running process using ptrace. It is a tool for *nix systems - for Windows, see dll-syringe. Currently, only x64 is supported, but support for other architectures is planned as soon as I can test them.

ptrace-inject is both a Rust library and a command line tool. Here's an example of using the library:

use std::{process::Command, path::PathBuf};
use ptrace_inject::{Injector, Process};

let library = PathBuf::from("path/to/library.so");

// Spawn a new process and inject the library into it.
let target = Command::new("target-process");
Injector::spawn(target)?.inject(&library)?;

// Or attach to an existing process.
let proc = Process::by_name("target-process")?.expect("to find target process");
Injector::attach(proc)?.inject(&library)?;

See the documentation for more information.

The usage of the command line tool is as follows:

Usage: ptrace-inject [OPTIONS] <--name <NAME>|--pid <PID>> <LIBRARY>

Arguments:
  <LIBRARY>  Path to the library to inject

Options:
  -v, --verbose...   More output per occurrence
  -q, --quiet...     Less output per occurrence
  -n, --name <NAME>  Name of a process to attach to
  -p, --pid <PID>    PID of a process to attach to
  -h, --help         Print help
  -V, --version      Print version

You can install it with cargo install ptrace-inject --features cli.

ptrace-inject's Issues

search libc.so.6 in /proc/<pid>/maps failed

hi,
I am trying to use this crate to inject a share library into process. But it failed with this error:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: failed to inject shellcode
Caused by:
   0: couldn't get libc function addresses for tracee
   1: getting the local libc offset failed
   2: could not find libc in the target process

This means searching libc.so.6 failed. Here is what i found on my machine:

$ls /usr/lib64/ -l | grep libc.so.6
lrwxrwxrwx  1 root root       12 Dec 19  2019 libc.so.6 -> libc-2.30.so

And when the process is running, what we can find in /proc//maps is "libc-2.30.so" rather than "libc.so.6":

7f29dbd55000-7f29dbd7a000 r--p 00000000 08:03 661688                     /usr/lib64/libc-2.30.so
7f29dbd7a000-7f29dbec7000 r-xp 00025000 08:03 661688                     /usr/lib64/libc-2.30.so
7f29dbec7000-7f29dbf11000 r--p 00172000 08:03 661688                     /usr/lib64/libc-2.30.so
7f29dbf11000-7f29dbf12000 ---p 001bc000 08:03 661688                     /usr/lib64/libc-2.30.so
7f29dbf12000-7f29dbf15000 r--p 001bc000 08:03 661688                     /usr/lib64/libc-2.30.so
7f29dbf15000-7f29dbf18000 rw-p 001bf000 08:03 661688                     /usr/lib64/libc-2.30.so

Maybe we can have a check if it is a symbolic link and get the correct file name?
Thanks.