ElfPack: ELF Binary Section Docking for Stageless Payload Delivery

Highlights

• Overview of payload bundling mechanisms: compilation,linking and loading.
• Binary compatibility and creation of loosely coupled payloads to their delivery mechanism.
• Avoiding automatic memory loading of sections.
• Use of structured section types.
• In-field payload (re-) attachment to loaders via ELF sections. Bring your own payload.
• Signature evasion with detached precompiled ELF sections.
• Drive-by payload attachments to loaders with ayload generation pipeline.
• Creation of fat payload binaries and the case for avoidance of binary packers.
• Packing complex payloads.
• Payload obfuscation and key protection options.
• Static and dynamic paylaod loading tracing resistance. Binwalk and eBPF.

Embedding payloads

Hex-binary Inclusion with compilation and linking

1. Directly in default data section or text: Normally, the compiler places the objects it generates in sections like .data.

payload.h:

const data[3432] = {
    0x43, 0x28, 0x41, 0x11, 0xa3, 0xff,
    ...
    0x00, 0xff, 0x23 
};

Achieved manually or with tools like bin2c or xxd -i payload.bin > payload.h with further header inclusion.

Storing payloads in .text and .data in a generic fashion is also a bad idea due to ease of loading tracing,and introspection of behavioral semantics of loading data for execution.

2. In a separate section. You can place payload data in additional sections, or you need certain particular variables to appear in special sections. This is achieved with a compiler dependent mechanism. In gcc, it's done via __attribute__'s. This is a bit better but still well traceable due to how ELF is created and loaded.

char stack[10000] __attribute__ ((section ("binstack"))) = { 
    0x43, 0x28, 0x41, 0x11, 0xa3, 0xff,
    ...
    0x00, 0xff, 0x23 };
int init_data __attribute__ ((section ("bindata"))) = 0;

main()
{
    /* Initialize stack pointer */
    init_sp (stack + sizeof (stack));

    /* Initialize initialized data */
    memcpy (&init_data, &data, &edata - &data);
}

3. Linker binary inclusion

Assembler dependent .incbin-like directive can create a section and embed a payload. Ex: gcc -c payload.s or ld -r -b payload.bin -o payload.o

.section .bindata

.global payload_start
.type payload_start, @object

.section .binddata
.balign 64

payload_start:
    .incbin "payload.bin"
    .balign 1
payload_end:
    .byte 0

With further retrieval in loader as:

int main(void) {
    extern uint8_t payload_start;
    uint8_t *ptrPayload = &payload_start;
    ...
}

Note: We can include a fully functional ELF in the payload.bin which is important when it comes to creating "fat" binaries, containing elements of several toolkits.

Note:: More ergonomic tools exist to accomplish the task, like INCBIN from @graphitemaster [link]

A variation on the theme is inline ASM like so:

/* Raw image data for all embedded images */
 #undef EMBED
 #define EMBED( _index, _path, _name )                                   \
         extern char embedded_image_ ## _index ## _data[];               \
         extern char embedded_image_ ## _index ## _len[];                \
         __asm__ ( ".section \".rodata\", \"a\", " PROGBITS "\n\t"       \
                   "\nembedded_image_" #_index "_data:\n\t"              \
                   ".incbin \"" _path "\"\n\t"                           \
                   "\nembedded_image_" #_index "_end:\n\t"               \
                   ".equ embedded_image_" #_index "_len, "               \
                         "( embedded_image_" #_index "_end - "           \
                         "  embedded_image_" #_index "_data )\n\t"       \
                   ".previous\n\t" );
 EMBED_ALL
 
 /* Image structures for all embedded images */
 #undef EMBED
 #define EMBED( _index, _path, _name ) {                                 \
         .refcnt = REF_INIT ( ref_no_free ),                             \
         .name = _name,                                                  \
         .data = ( userptr_t ) ( embedded_image_ ## _index ## _data ),   \
         .len = ( size_t ) embedded_image_ ## _index ## _len,            \
 },
 static struct image embedded_images[] = {
         EMBED_ALL
 };
 

Note: Notice PROGBITS in definition of a section, it will be important.

Compiler/linker-based paylaod binary inclusion is not ideal

There are tradeoffs:

• The process of embedding is tightly coupled to the creation of payload loader.
• What about payload format changes
• By default data carrying section have PROGBITS flags set on it, and it will be PT_LOAD’ed into memeory by OS loader by default. We ma not want this.

ELF disk/memory representation of a section

Type of section and flags set on the new section containing determine whether OS loader loads it in the memory upon executable launch. Some sections are loaded automatically by default, others are not (e.g. .symtab, .strtab)

As offense, what effciencies can we get from that?

Embedding payloads: take 2

1. We can avoid setting flags on sections that assume default loading in memory.

2. We can use a different type of section that does not load in memory.

A vendor or system engineer might need to mark an object file with special information that other programs can check for conformance or compatibility. Sections of type SHT_NOTE and program header elements of type PT_NOTE can be used for this purpose.

In a latter case, we can see the use of this type of section in system binaries:

$ readelf --sections /bin/tar | grep NOTE
  [ 2] .note.gnu.bu[...] NOTE             00000000000002c4  000002c4
  [ 3] .note.ABI-tag     NOTE             00000000000002e8  000002e8

And can inspect their content:

$ readelf -p .note.ABI-tag /bin/tar

String dump of section '.note.ABI-tag':
  [     c]  GNU

The end result of creating a SHT_NOTE section will look like this in the ELF:

Bonus: SHT_NOTE gets us structure if we need to use it ( and we will use it further):

ELF Section Docking

So far we were able to create a section, avoid loading it in memory by the OS loader. The section is effectively dormant in the ELF image at the moment. We will discuss how we load it a bit later. However, a more pressing question is the fact that we are still operating at the compiler and linker level, and section is an object that gets woven into the structure of the final ELF, creating relationships and memory addresses from the loader code that references it's content.

What if we were able to create an ELF section with embedded payload outside of the loader compilation workflow, and attach that section at a later time to the loader binary.

This would break the relationship of the loader code with the section interaction. Then we teach the loader how to find and load it's foreign data section, effectively "docking" a payload to a loader in a loosely coupled manner.

Conceptually, our goals would be:

• Loader should not be entangled with payload semantics
• Loading and executing payload :
  • Without modifying loader code at all?
  • Without using OS loader ld.so (ELF loader) which is loading segments of payload in memory automatically.
• In-field payload (re-)attachment.