ELF relocatable object exporter, part 2

[boricj]

Part 1: #4922

What is this?

ghidra-delinker-extension is a Ghidra extension that can turn parts of programs into working, relocatable object files.

It's an implementation of a technique called delinking*, whose goal is to undo the work of a linker. It allows one to take bits and pieces of programs and re-use them as part of new programs or libraries, without having to disassemble or decompile them.

Currently, the analyzers support the 32-bit i386 and MIPS architectures, additional architectures can be added by writing a relocation synthesizer. It can produce ELF object files and other formats can be implemented by writing an exporter.

What can one do with it?

I've publicly demonstrated several use-cases on my blog:

• Binary patching a program without having to fit the modifications within the original program's memory layout ;
• Converting a Linux program from a.out to ELF and rebasing it at a higher virtual address in the process, for execution on modern systems without requiring workarounds ;
• Swapping out C standard libraries, up to transforming a statically-linked program into a dynamically-linked program ;
• Porting a Linux program to Windows without having access to its source code or even decompiling it first.

More use-cases are possible (making libraries out of parts of a program, incremental decompilation projects...), but I haven't documented them yet for the time being.

How do I use it?

The README file has instructions, but after installing this extension it boils down to:

• Running the Relocation table synthesizer analyzer to generate relocation entries ;
• Invoking the ELF relocatable object exporter on a program selection.

The whole workflow is automated down to a couple of clicks and is fairly similar to performing a raw bytes exportation.

What's the catch?

Using this extension doesn't require any particular skill or knowledge, but the two main source of problems during delinking can be tricky to track down:

• Cutting across a variable during exportation, effectively truncating it ;
• Incorrect relocations due to inaccurate Ghidra database contents (especially bad references).

What's the plan?

I've created this tooling for a decompilation project of mine. Now that I have publicly documented multiple case studies which proves it actually works, I figured it's time to see if there's any interest in the community for this before I resume my initial project.

Hopefully I can also make this esoteric technique more widely known and accessible to the everyday reverse-engineer. It truly makes programs feel like they are made up of LEGO^® bricks.

*There are very few resources online about this topic. I do know I didn't invent it, but I haven't seen evidence suggesting it was industrialized to this point before.