1.1 Dead Bytes

Published in

· 2 years ago

 _ .-') _     ('-.   ('-.     _ .-') _        .-. .-')               .-') _     ('-.    .-') 
( (  OO) )  _(  OO) ( OO ).-.( (  OO) )       \  ( OO )             (  OO) )  _(  OO)  ( OO ). 
 \     .'_ (,------./ . --. / \     .'_        ;-----.\  ,--.   ,--./     '._(,------.(_)---\_) 
 ,`'--..._) |  .---'| \-.  \  ,`'--..._)       | .-.  |   \  `.'  / |'--...__)|  .---'/    _ | 
 |  |  \  ' |  |  .-'-'  |  | |  |  \  '       | '-' /_).-')     /  '--.  .--'|  |    \  :` `. 
 |  |   ' |(|  '--.\| |_.'  | |  |   ' |       | .-. `.(OO  \   /      |  |  (|  '--.  '..`''.) 
 |  |   / : |  .--' |  .-.  | |  |   / :       | |  \  ||   /  /\_     |  |   |  .--' .-._)   \ 
 |  '--'  / |  `---.|  | |  | |  '--'  /       | '--'  /`-./  /.__)    |  |   |  `---.\       / 
 `-------'  `------'`--' `--' `-------'        `------'   `--'         `--'   `------' `-----' 
                                                                                  ~ xcellerator

Ahoy, fellow ELF devotees! In this article, I want to introduce a small library I've been working on called LibGolf. It started out as simply a vehicle for better understanding the ELF and program headers, but has since spun into something reasonably practical. It makes is very easy to generate a binary consisting of an ELF header, followed by a single program header, followed by a single loadable segment. By default, all the fields in the headers are set to sane values, but there's a simple way to play with these defaults - and that's what this article is all about! I'm going to demonstrate how I used LibGolf to enumerate precisely which bytes are necessary and which are ignored by the Linux loader. Fortunately, it turns out that the loader is one of the least picky parsers among the standard Linux toolkit. Before we're through, we'll see several popular static analysis tools crumble before our corrupted ELF, while the loader continues to merrily load and jump to our chosen bytes.

Introducing LibGolf

A while back, I'd been playing with writing ELFs by hand in NASM. While this was fun for a while (and certainly has it's benefits), I realised that I was missing out on all the fun that C structs have to offer. In particular, as I'm sure many readers will no doubt be aware, <linux/elf.h>, is packed full of fun things like `Elf64_Ehdr` and `Elf32_Phdr` ripe for declaring.

Not wanting such helpful headers to go to waste, I elected to take them, and put them to good use. From these efforts, came libgolf.h, a libary that makes it easy to throw shellcode into a functioning executable. I know what you're thinking - "this just sounds like a terrible linker!", and you might be right. However, what's nice here is that you can easily modify the headers *before* the binary is built.

Let's take a look at how this works. If you want to play along at home, you can find the source code for all of this at [0]. You can find the code in this article under 'examples/01_dead_bytes'. The basic setup needs two files; a C source file and a shellcode.h. As far as shellcode goes, I like to go with the old faithful 'b0 3c 48 31 ff 0f 05', which disassembles to:

mov al, 0x3c    @ b0 3c 
xor rdi, rdi    @ 48 31 ff 
syscall         @ 0f 05

(Yes - calling this "shellcode" is pushing things a bit!)

Essentially, it just calls exit(0). This is nice because we can easily check that these bytes successfully executed with the shell expansion $?.

Throw this or some other shellcode (but make sure it's PIC - there's no support for relocatable symbols yet!) into a buffer called buf[] in shellcode.h and jump back to the C file. If you just wanted to get a binary that executes your shellcode, then this is all you need:

#include "libgolf.h" 
#include "shellcode.h" 

int main(int argc, char **argv) 
{ 
    INIT_ELF(X86_64,64); 

    GEN_ELF(); 
    return 0; 
}

Compiling this and running the resulting executable will provide you with a .bin file - this is your shiny new ELF! Pretty simple, right? Simplicity is often accompanied by the dull, as is the case here, so let's do something more interesting!

Before going on, it's worth explaining what these two macros are doing behind the scenes. First off, INIT_ELF() takes two arguments, the ISA and the architecture. Currently, LibGolf supports X86_64, ARM32, and AARCH64 as valid ISAs and either 32 or 64 for the architecture. It first sets up some internal bookkeeping structs, and decides whether to use the Elf32_* or Elf64_* objects for the headers. It also automatically assigns pointers to the ELF and program headers, called ehdr and phdr respectively. It is these that we will use to easily modify the fields. Aside from that, it also copies the shellcode buffer over, and populates the ELF and program headers before calculating a sane entry point. Now comes GEN_ELF(), which just prints some nice stats to stdout and then writes the appropriate structs to the .bin file. The name of the .bin is determined by argv[0].

So, after we've used the INIT_ELF() macro, we have ehdr and phdr available to dereference. Suppose we wanted to modify the e_version field of the ELF header. All we need to do is add a single line:

#include "libgolf.h" 
#include "shellcode.h" 

int main(int argc, char **argv) 
{ 
    INIT_ELF(X86_64); 

    // Set e_version to 12345678 
    ehdr->e_version = 0x78563412; 

    GEN_ELF(); 
    return 0; 
}

Another quick compile and execute, and you'll have another .bin file waiting for you. Taking a look at this file in xxd, hexyl, or your favourite bin-manipulator of choice, you'll see a pretty little '12 34 56 78' peeking back at you starting at offset 0x14. Wasn't that easy?

To make things move a little faster, I like to use the following Makefile:

.PHONY golf clean 

CC=gcc 
CFLAGS=-I. 
PROG=golf 

golf: 
        @$(CC) -o $(PROG) $(PROG).c 
        @./$(PROG) 
        @chmod +x $(PROG).bin 

        @rm $(PROG) $(PROG).bin

(This is the Makefile you'll find in the repo [0])

Falling At The First Hurdle

As many will already know, file parsers are awful things. While specifications usually have earnest goals, they are rarely respected by those who should supposedly know better. Chief among such blasphemers is the Linux ELF loader itself. LibGolf makes it easy to investigate the extent of these crimes against elf.h.

A good place to begin is the beginning, which means the ELF header. At the start of any ELF file is ofcourse, the familar 0x7f followed by ELF, known to its friends as EI_MAG0 through EI_MAG3. Unsurprisingly, modifying any of these four bytes results in the Linux loader rejecting the file.
Thank goodness for that!

What about byte 0x5? Our trusty specification tells us that this is the EI_CLASS byte and denotes the target architecture. Acceptable values are 0x01 and 0x02, for 32- and 64-bit respectively. I'll say again: acceptable values are 0x01 and 0x02. What if we set it to 0x58 (or "X" for ASCII- adherents)? We can do that by adding:

(ehdr->e_ident)[EI_CLASS] = 0x58;

to our generating C file. (Why 0x58? It shows up clearly in xxd/hexyl output!)

Once we've got our .bin to play with, before trying to execute it, let's try a couple of other familar ELF parsing tools in the search for further culprits. First on the list is gdb. Go on, I'll wait. See what happens?

"not in executable format: file format not recognized"

Likewise, objdump will give you a similar answer. It seems these parsers are doing their job properly. Now, let's try to run the binary normally.

<spoiler>It works perfectly.</spoiler>

If you're using my example shellcode, then a consultation with $? will regretably inform you that the binary exited successfully. The same crimes are commited when setting EI_DATA and EI_VERSION to illegal values too.

Turning The Corruption Up To 11

So, how far can we go? Just how much of the ELF and program headers will the Linux loader ignore? We've already covered EI_CLASS, EI_DATA and EI_VERSION, but it turns out that EI_OSABI is also safely ignored. That takes us up to offset 0x8. According to the spec, next up is EI_ABIVERSION and EI_PAD which, together, take us all the way to byte 0xf. No one cares about them it seems, so we can set all of them to 0x58 without fear.

Marching ever further, we come across a field that appears to be resistant to being messed with: e_type. Understandably, the Linux loader doesn't like it if we don't tell it what kind of ELF file we're providing it with (it's nice to know that it does have *some* standards! - pun intended). We need these two bytes to remain 0x0002 (or ET_EXEC to elf.h acolytes). Next up is another picky byte, at the all-too-familiar 0x12 offset: e_machine, which designates the target ISA. As far as we're concerned, by specifying X86_64 as the first argument to INIT_ELF(), this byte has already been populated with 0x3e for us by LibGolf.

Suddenly, a wild e_version appeared! We're faced with another dissident, which supposedly should always be the bytes 0x00000001. However, in practice, no one seems to be interested, so let's fill it with 0x58585858 instead.

Following this string of heretics, we have a couple of important fields that appear to be resistant to abuse; e_entry and e_phoff. I'm sure I needn't go into too much detail about e_entry; it's the entry point of the binary, where execution is ultimately handed off to once the loadable sections are in memory. While one might expect that the loader could manage without knowing what the offset to the program header is, it appears that it isn't smart enough to figure it out without being spoon-fed. Better leave these two alone.

LibGolf is yet to support section headers (and given its focus on producing *small* binaries, it is probably unlikely to support them in the future). This means that, faced with any headers relating to them, we can fiddle to our heart's content. That includes e_shoff, e_shentsize, eh_shnum and even e_shstrndx. If we don't have any section headers, we can't be held accountable for corrupting them!

The remaining fields that are seemingly of some import to the Linux loader are e_ehsize, e_phentsize, and e_phnum. Again, this isn't too surprising, seeing as they are concerned with loading the only loadabale segment into memory before handing over control. If you need a refresher, e_ehsize is the size of the ELF header (which is either 0x34 or 0x40 for 32- and 64-bit respectively), eh_phentsize is the size of the upcoming program header (again, hardcoded to either 0x20 or 0x38 for 32- and 64-bit architectures). If the loader had been a little more picky about EI_CLASS, it wouldn't need these two fields. Lastly, e_phnum is just the number of entries in the program header - for us it is always 0x1. No doubt, this is used for some loop in the memory loading routines, but I haven't investigated any further yet.

There is still one field left in the ELF header I haven't touched on, which is e_flags. The reason is fairly simple, in that it's architecture dependent. For x86_64, it doesn't matter at all because it's undefined (although it *is* important for some ARM platforms! Take a look at the arm32 example at [0]).

That brings us to the end of the ELF header. For those not keeping count, just over 50% of the ELF header is ignored by the loader. But what about the program header? It turns out that program headers have a lot less wiggle room in them, but not for the reason one might expect. Indeed, *any* corruption of the program header will not actually affect the Linux loader. We could fill the whole thing with our trusty 0x58, and the loader won't care a jot. But beware, bold adventurer, fiddle with the wrong byte and you'll be plunged into the dungeon of faulty segmentation!

So, is there anything at all susceptible to coercion in the program header? It transpires that there are two fields that, by no fault of their own, simply aren't relevant anymore: p_paddr and p_align. The former was important back in the heady days before virtual memory, where 4GB of RAM was nothing more than a child's daydream and it was therefore important to inform the loader where in physical memory the segment should be loaded.

Memory alignment is a funny one. Supposedly, p_vaddr is meant to equal p_offset modulo p_align. "Proper" ELF files (at least those compiled with GCC) appear to just set p_offset equal to p_vaddr and move on. This is also what LibGolf does by default and renders p_align totally superfluous!

All in all, not as fun as the ELF header, but still some small gains. The binary generating C file now looks like this:

#include "libgolf.h" 
#include "shellcode.h" 

int main(int argc, char **argv) 
{ 
    INIT_ELF(X86_64,64); 

    /* 
     * Breaks common static analysis tools like gdb and objdump 
     */ 
    (ehdr->e_ident)[EI_CLASS] = 0x58;   // Architecture 
    (ehdr->e_ident)[EI_DATA] = 0x58;    // Endianness 
    (ehdr->e_ident)[EI_VERSION] = 0x58; // Supposedly, always 0x01 
    (ehdr->e_ident)[EI_OSABI] = 0x58;   // Target OS 

    // Loop over the rest of e_ident 
    int i; 
    for ( i = 0 ; i < 0x10 ; i++ ) 
        (ehdr->e_ident)[i] = 0x58; 

    ehdr->e_version = 0x58585858;       // Supposedly, always 0x00000001 

    // Section headers? We don't need no stinkin' section headers! 
    ehdr->e_shoff = 0x5858585858585858; 
    ehdr->e_shentsize = 0x5858; 
    ehdr->e_shnum = 0x5858; 
    ehdr->e_shstrndx = 0x5858; 

    ehdr->e_flags = 0x58585858;         // x86_64 has no defined flags 

    phdr->p_paddr = 0x5858585858585858; // Physical address is ignored 
    phdr->p_align = 0x5858585858585858; // p_vaddr = p_offset, so irrevelant 

    GEN_ELF(); 
    return 0; 
}

If you compile and run this program, you'll get the following binary:

00000000: 7f45 4c46 5858 5858 5858 5858 5858 5858  .ELFXXXXXXXXXXXX 
00000010: 0200 3e00 5858 5858 7800 4000 0000 0000  ..>.XXXXx.@..... 
00000020: 4000 0000 0000 0000 5858 5858 5858 5858  @.......XXXXXXXX 
00000030: 5858 5858 4000 3800 0100 5858 5858 5858  XXXX@.8...XXXXXX 
00000040: 0100 0000 0500 0000 0000 0000 0000 0000  ................ 
00000050: 0000 4000 0000 0000 5858 5858 5858 5858  ..@.....XXXXXXXX 
00000060: 0700 0000 0000 0000 0700 0000 0000 0000  ................ 
00000070: 5858 5858 5858 5858 b03c 4831 ff0f 05    XXXXXXXX.<H1...

This file is 127 bytes in size, but we were able to replace a total of 50 bytes with 'X', meaning just under 40% of this binary is ignored by the Linux ELF loader! Who knows what you could do with 50 bytes?

It turns out - quite a lot. Some amazing research from a couple of years ago by netspooky demonstrated how you can pile up portions of the program header into the ELF header. Combined with storing your shellcode inside one of these regions of dead bytes, and a few other neat tricks, it's possible to shrink an ELF down to just 84 bytes - a 34% reduction on top of LibGolf's current best efforts. I point you in the direction of his incredible "ELF Mangling" series at [1].

Another interesting aspect of these techniques is easily overlooked. Although the Linux loader seems to care very little about the structure of an ELF beyond what it needs to just get to the machine code, other tools are far more picky. We already looked at objdump and gdb, but a lot of AV solutions also crumble when faced with a malformed ELF. In my research, the only product that (sorta) gets it right is ClamAV, with a positive result for "Heuristics.Broken.Executable". Of course, dynamic analysis is still anyone's bet.

Going Forwards

x86_64 isn't the only ISA supported by LibGolf! You can also use it to build tiny executables for ARM32 and AARCH64 platforms too. In the repo on GitHub [0], you'll find some examples for both ARM platforms (including the dead bytes one from this article).

But examples be damned! Hopefully most of you that have made it this far want to take a look at libgolf.h itself. As I mentioned at the start, this whole thing started off as a learning exercise, so I paid special attention to commenting things in as much detail as I could.

A Note on Reproducibility

Throughout this research, I mainly tested on Ubuntu 20.04 with kernel 5.4.0-65-generic, but also verified that the same results could be obtained on 5.11.11-arch1-1. I've heard that strange things can sometimes happen on the WSL kernels, but I've not investigated them - maybe you can!