Patching ELFs with Assembly C, or abusing the linker for fun and profit

Using a little bit of linkerscript magic and C to patch binaries the toolchain-intended way - instead of manually patching assembly instructions like a madman.

In this post, we’ll explore an intuitive way to patch program behaviour in ELF binaries - by using a method that involves NO assembly.

TL;DR#

Feel free to skip to Simple demonstration section if you are familiar with C compilation process and linkerscript.

Compiling C - a quick refresher#

Compiling C, in the most simplest form, is as simle as a single command like gcc main.c -o main.

But behind the scenes, there’s three main components involved in converting a C source file to an executable - the compiler, the assembler, the linker.

Abusing the linker for fun and patching binaries#

In the compilation process, the linker is used to resolve relocations in object files.

The GNU Linker (ld) provides two features that can be used for binary patching:

1. Defining the address of a symbol.
2. Placing a certain section of code at a certain memory offset.

Defining the address of a symbol#

In C, symbols may be referenced before they are defined. This allows code to refer to objects or functions whose final definition is provided later-either by another object file or by the linker itself.

Symbols defined in linkerscript can be referenced using the extern C keyword (It’s not necessary for functions).

The below example shows a linkerscript which defines the address of the symbol my_puts to be 0x42069. It can be verified by looking at corresponding disassembly.

1
2
3
4
5

extern void (*my_puts)(char *);

int main(void) {
  my_puts("Hello, world!");
}

INCLUDE default.ld

my_puts = 0x42069;

Feel free to download and compile the contents of example/defining_external_symbols/export.zip to verify.

Placing a certain section of code at a certain memory offset#

By modifying the location counter (the .) of a linkerscript, we can force certain sections to be placed in specific virtual addresses.

For example, the below code places the function foo at the virtual address 0xdeadbeefcafebabe.

1
2
3
4
5
6
7

#define SECTION(x) __attribute__((section(x)))

// this section should be placed at **virtual address** `0xdeadbeefcafebabe`
SECTION(".patch")
int foo(void) {
    return 42;
};

SECTIONS
{
    . = 0xdeadbeefcafebabe;
    .patch ALIGN(1) : SUBALIGN(1)
    {
        KEEP (*(.patch))
    }
}

The source for this example is provided at: example/placing_section_at_address/export.zip.

Simple demonstration#

For a practical example, we will patch a binary produced by the following source:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

#include <stdio.h>
#include <sys/cdefs.h>

volatile int i_do_nothing() {
  __asm__ volatile(".rept 500\n\t"
                   "nop\n\t"
                   ".endr\n\t");

  return 42;
}

int main(void) {
  puts("Hello! Go ahead and patch me!");
  volatile int ret = i_do_nothing();
  return ret;
}

The goal is to replace the code-cave i_do_nothing with a call to

1
2

puts("Hello, binary patching!");
puts("Hello, linkerscript magic!");

without recompiling the original source.

The binary has the following protections enabled:

The most notable one, for our concerns, is PIE (Position Independent Executable). Since it is enabled, we cannot call to absolute addresses - we have to make the compiler emit the rel32 counterparts of the call / jmp instructions by setting a flag.

Notation#

Moving on, the word “target” refers to the binary being patched.

Recon#

Before we start writing the patch, we need to identify code caves and enumerate the environment.

We need a safe-to-patch code cave.#

When patching a code cave, it should not cause un-wanted side-effects (like triggering improper memory access).

The i_do_nothing function provides a perfect code cave, with 500 nop instructions. It starts at physical address 0x01139 and has a length of 511 bytes.

We need to call external library functions#

Our goal is to call puts.

Since the target is dynamically linked, we can find a reference to puts in the .plt section, at the physical offset 0x1030.

Writing the patch#

From our recon, we have the following parameters:

1. should fit within the address range [0x1139, 0x1139+511].
2. must call puts, which can be achieved using puts@plt.
3. must also embed two null-terminated strings (the parameters to puts@plt).

With the above in mind, one can write a patch - something similar to this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

#include <stdio.h> // for declaration of puts

#define SECTION(x) __attribute__((section(x)))

SECTION(".patch.data.string1")
const char hello_binary_patching[] = "Hello, binary patching!";

SECTION(".patch.data.string2")
const char hello_linkerscript[] = "Hello, linkerscript magic!";

SECTION(".patch.code.i_do_something")
void i_do_something() {
  puts(hello_binary_patching);
  puts(hello_linkerscript);
}

patch_at = 0x01139;
patch_size = 511;

puts = 0x1030; /* plt entry of puts */

SECTIONS
{
    . = patch_at;
    .patch ALIGN(1) : SUBALIGN(1)
    {
        KEEP(*(.patch.code.*))
        KEEP(*(.patch.data.*))
    }
    ASSERT(SIZEOF(.patch) <= patch_size, "patch is too big")
}

Once the patch is compiled and extracted, it can be applied to the target using the dd command.

Caveats#

1. If the codecave is restricted by size, it is a better idea to directly write assembly.
2. If the target function’s calling convention differs from the C compiler’s ABI, it’s preferable to use a small assembly “stub” to adapt the arguments and invoke the C function correctly.

Conclusion#

The original goal of this method of binary patching was to increase productivity by working with a high level tool like the C compiler instead of an assembler. That said, it also comes with a few pretty useful side effects. I’ll revisit the points outlined below in more detail in future posts:

1. With enough compiler options, it should be possible to use languages other than C for generating object files. Example: Rust, Zig, Nim, etc.

2. The patch itself gains a degree of platform independence: as long as the target and the patching language share the same (or similar) ABI, the patch logic remains unchanged. The only platform-specific component is the linker script, which defines the required symbols, addresses, and offsets.

3. This method should work fairly unchanged for other binary formats, like PEs or Mach-O executables.

4. With a large enough code caves, it should be possible to embed a dynamic symbol-resolver, which uses platform dependent methods to load addresses of symbols from libraries (like dlsym() on linux, and GetProcAddress() on NT).

Overall, this method shifts binary patching away from instruction-level edits to a more structured, maintainable and versionable workflow. It mirrors how decompilers let us think in C while reverse-engineering: the low-level complexity of assembly still exists, but the compiler handles it for us, allowing us to focus on intent rather than instructions.