Netspooky's Blog

BGGP6: REVIVING RDOFF PART 1

Tue, 25 Nov 2025 12:00:00 -0400

Motivations & Goals

This year’s BGGP challenge is “RECYCLE”. Players are encouraged to recycle old ideas, lost projects, and obscure file formats to complete any of the previous 5 BGGP challenges, or just create the smallest file that prints/returns/displays the number “6”. After looking through some old notes on file formats I wanted to play with, I remembered a format called RDOFF. Years ago I wrote to myself “what are rdoff tools?” after learning that nasm shipped with support for it. There was even a package called nasm-rdoff. I didn’t know much about this format, other than it was some sort of internal object file. This sounded like a perfect target for BGGP6 !

My main goal is to figure out how to generate and execute an RDOFF file using nasm’s rdx interpreter. Once this is complete, I want to golf the file to make it as small as possible.

This writeup focuses on understanding the RDOFF format, poking at nasm internals, and crafting files using a custom scapy library.

To follow along, you can clone and build the nasm 2.15 repo!

git clone --branch nasm-2.15 https://github.com/netwide-assembler/nasm

Everything in this writeup was built and tested on a x86_64 Ubuntu 24.04 system.

What is RDOFF?

RDOFF, or the Relocatable Dynamic Object File Format, is an object file format that was first released as a part of nasm 0.91 in November 1997. It was created to provide a reference 32 bit object file format for nasm developers to use to test the assembler’s object file generation, as the only other supported format at the time was the 16 bit DOS .OBJ format. Per the original release doc, the nasm devs realized that RDOFF could be useful to OS and assembler devs, and decided to standardize it.

The first version of RDOFF only supported 4 header record types: “Relocation”, “Symbol Import”, “Symbol Export”, and “Dynamic Link Library”. Over time, RDOFF was expanded to include other record types, turning it into a reference implementation that generalized many of the core structure types used in object files.

On December 3rd 2002, this commit added RDOFF2 support to nasm. The biggest changes to the format were adding length fields to most structures, to make it easier to support custom header records and sections, as well as skip over any unsupported types.

From v1-v2.txt:

This isn’t as pointless as it sounds; I’m using RDOFF in a microkernel operating system, and this is the ideal way of loading multiple driver modules at boot time.

RDOFF2 also deprecated Header Record Type 9 or RDFREC_MULTIBOOTHDR, which was never reused. From this point on, most of the changes to the core format involved internal nasm code, as many things used in RDOFF were mapped to core code in the nasmlib, but there weren’t any more major updates to the format or the toolchain.

20 years later, in 2022, all RDOFF code was removed from nasm 2.15.4 (and 2.16).

Per the release notes:

As of Version 2.16: Support for the rdf format has been discontinued and all the RDOFF utilities has been removed.

What happened?

The Death of RDOFF

Around the time that RDOFF2 was added to nasm, there were at least two known projects using the RDOFF format in some capacity. One of them was the MOSCOW operating system, written by nasm developer Julian Hall. It is referenced in the nasm source, in both comments and code (segment types between 0x20 and 0x1000 are reserved for MOSCOW). I wasn’t able to find any other references to this operating system online, so I assume it’s no longer in active development.

The other project was a clone of QNX Neutrino 6.1 called radiantOS or “radiOS”. radiOS was written mostly in nasm assembly, with some C for it’s boot time module linker “btl”. It actually uses RDOFF in btl and in other modules, and even has custom headers. The last update to the site had an announcement that “The fourth pre-release of RadiOS-0.0.1.7 is being prepared.” on Jun 11, 2004. The last available source is radios-0.0.1.7-pre4a which is what I reviewed.

Beyond these two projects, it doesn’t seem like RDOFF was ever used anywhere else, except for nasm compatibility. Through the years, the documentation and code reflected that.

From the nasm 2.15 docs:

RDOFF is not used by any well-known operating systems. Those writing their own systems, however, may well wish to use RDOFF as their object format, on the grounds that it is designed primarily for simplicity and contains very little file-header bureaucracy.

The documentation doesn’t describe what is required to write assembly that will generate an rdf file, only how to include an already built .rdf file. The spec itself is a texi file buried in the repo, and not referenced in the docs. The only hints about using nasm to create RDOFF files are the test programs in rdoff/test/, which have examples of some features like calling external functions. The other scattered bits of info moreso describe the tooling and notes about slight changes, than about the files themselves.

Online searches yielded little results. I tried to find any example RDF file, but none were available. There are tons of random links that weren’t helpful, with people asking similar questions about RDOFF back in 2004. I did see this random CVE for the nasm-rdoff package, but the bug was unrelated to the file format. I also saw that yasm supports generating RDOFF, but it seems to just be there for compatibility. The manpage says that nasm contains the toolchain and the loader for RDOFF. The only non-nasm tool I could find for analyzing the format was from a repo called objview. Written in TurboPascal, the RDF viewer shows information about existing RDOFF files, but doesn’t contain any files to test with.

Since there were no example files I could find, I decided to just try to use nasm to generate one.

Failing To Generate An RDF

I took the source of a small x86 assembly program and tried to output to the rdf format. I got this error when assembling:

2025-11-22 19:22:38 ~/projects/binarygolf/bggp6/nasm-nasm-2.15
▶ ./nasm -f rdf 6.asm
panic: 6.asm: rdf segment numbers not allocated as expected (2,4,6)

I spent some time trying to get it to build, looking around the docs for info on what I need to include in my assembly to make it work. Sometimes different formats have specific keywords to use, or need to include a special symbol, but there wasn’t much info to go off of.

I formatted my program in the same way as the example code in rdoff/test/. An RDF file seems to require 3 sections: .text, .data, and .bss. The only other real difference to regular code I write with nasm is that the code’s entrypoint is _main instead of _start.

From the manpage:

rdx loads an RDOFF object, and then calls ‘_main’, which it expects to be a C-style function, accepting two parameters, argc and argv in normal C style.

This is the RDF-friendly source I ended up with:

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


[SECTION .text] ; this is the text section
[BITS 64] ; using 64 bit
[GLOBAL _main] ; the _main function as a global

_main:
 mov rax,0x3c ; exit() syscall
 mov rdi, 6 ; return value for BGGP6
 syscall ; call the kernel and exit

[SECTION .data]
 db 0 ; 1 byte data section

[SECTION .bss]
 resb 1 ; resb is used to allocate in bss

When I tried to build it, I got the same error. Hrm…

For a sanity check, I tried to build the test cases, but none of those worked either!

2025-11-22 21:27:39 ~/projects/binarygolf/bggp6/nasm-nasm-2.15
▶ ./nasm -f rdf rdoff/test/testlib.asm
panic: rdoff/test/testlib.asm: rdf segment numbers not allocated as expected (2,4,6)
2025-11-22 21:27:42 ~/projects/binarygolf/bggp6/nasm-nasm-2.15
▶ ./nasm -f rdf rdoff/test/rdftest1.asm
panic: rdoff/test/rdftest1.asm: rdf segment numbers not allocated as expected (2,4,6)

At this point I was really confused. It should work right? The docs say that nasm has a full toolchain for RDOFF files. Even other tools say to use nasm to test the RDF files they generate.

It’s also still in the help file in nasm 2.15. rdf was created to test the very output engine that generates these other file formats, so it is strange that it doesn’t seem to work at all.

 -f format select output file format
 bin Flat raw binary (MS-DOS, embedded, ...) [default]
 ith Intel Hex encoded flat binary
 srec Motorola S-records encoded flat binary
 aout Linux a.out
 aoutb NetBSD/FreeBSD a.out
 coff COFF (i386) (DJGPP, some Unix variants)
 elf32 ELF32 (i386) (Linux, most Unix variants)
 elf64 ELF64 (x86-64) (Linux, most Unix variants)
 elfx32 ELFx32 (ELF32 for x86-64) (Linux)
 as86 as86 (bin86/dev86 toolchain)
 obj Intel/Microsoft OMF (MS-DOS, OS/2, Win16)
 win32 Microsoft extended COFF for Win32 (i386)
 win64 Microsoft extended COFF for Win64 (x86-64)
 --> rdf Relocatable Dynamic Object File Format v2.0 <--
 ieee IEEE-695 (LADsoft variant) object file format
 macho32 Mach-O i386 (Mach, including MacOS X and variants)
 macho64 Mach-O x86-64 (Mach, including MacOS X and variants)
 dbg Trace of all info passed to output stage
 elf Legacy alias for "elf32"
 macho Legacy alias for "macho32"
 win Legacy alias for "win32"

I decided to ask Copilot on Github, since you can ask it questions about a repo. I asked about the errors I was seeing within the context of the nasm 2.15 repo, because I wanted to know if there was either something missing in my assembly source, or if nasm itself was broken. Copilot told me to try a bunch of things that didn’t work, and wasn’t aware of any issues regarding the rdf format. I ended up asking if there were any known RDF files published on Github. It gave me this answer:

Instead of trying to figure out what version of nasm can emit an RDOFF, or waste more time trying to get an LLM to be useful, it seemed more fruitful to just look at the source.

Patching The nasm Loader

A quick grep for the error message leads to the outrdf2.c file. It contains the function rdf2_init().

This is where the error comes from:

140
141
142
143
144
145


 segtext = seg_alloc();
 segdata = seg_alloc();
 segbss = seg_alloc();
 if (segtext != 0 || segdata != 2 || segbss != 4)
 nasm_panic("rdf segment numbers not allocated as expected (%d,%d,%d)",
 segtext, segdata, segbss);

There are 3 calls to seg_alloc() that populate the segtext, segdata, and segbss variables. This lines up with the 3 required sections included in the assembly source. nasm seems to only be returning “2,4,6” instead of “0,2,4” as expected. What is seg_alloc() doing then? Let’s take a look at segalloc.c!

Wait what…

43
44
45
46
47
48
49
50
51


static int32_t next_seg = 2;

int32_t seg_alloc(void)
{
 int32_t this_seg = next_seg;

 next_seg += 2;
 return this_seg;
}

This isn’t allocating anything! It’s incrementing a global value starting at 2. Bizarre, but it lines up with what we saw, as next_seg is initialized to 2, not 0, so it will always start at 2. This is in the rdf2_init() function, so this hasn’t worked in while huh?

The fix seems obvious then, just change next_seg back to 0 in segalloc.c and see what happens.

static int32_t next_seg = 0; // 2;

The most recent commit from 2018-06-14 has some words about this:

Oof!

segalloc: DO NOT reset segment numbers

We are not supposed to reset the segment numbers; this was an
attempted fix for a convergence bug that didn't actually exist. The
backend is required to return the same segment number for the same
segment; if it does not, the front end will not converge, but that is
in fact the correct behavior.

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

None of the code in this commit relates to RDOFF at all. The changes just remove seg_alloc_setup_done and seg_alloc_reset from the segalloc.c file and the few refs to them.

The previous commit from 2018-06-01 is more consequential, but the reasoning is also unrelated to RDOFF:

Cleanup of label renaming infrastructure, add subsection support

In order to support Mach-O better, add support for subsections, as
used by Mach-O "subsections_via_symbols". We also want to add
infrastructure to support this by downcalling to the backend to
indicate if a new subsection is needed.

Currently this supports a maximum of 2^14 subsections per section for
Mach-O; this can be addressed by adding a level of indirection (or
cleaning up the handling of sections so we have an actual data
structure.)

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

In this commit, next_seg was bumped from 0 to 2 in asm/segalloc.c, shown here:

Several output formats were updated, but the RDOFF2 generator outrdf2.c was not. It appears that nasm hasn’t been able to produce an RDF since at least June 2018.

Let’s apply the patch, rebuild using make everything, and test!

(Tragic!): There was a PR to the nasm repo from 2021 by objview creator DosWorld, which suggested this same patch. It wasn’t accepted because the format was being deprecated!

Generating A Broken RDOFF

With a patched segalloc.c , I built testlib.asm as a starting point. Incredibly, nasm didn’t complain, and created an RDF file for the first time this decade!

2025-11-22 22:01:40 ~/projects/binarygolf/bggp6/nasm-nasm-2.15
▶ nasm -f rdf testlib.asm -o testlib.rdf
2025-11-22 22:01:47 ~/projects/binarygolf/bggp6/nasm-nasm-2.15
▶ xxd testlib.rdf
00000000: 5244 4f46 4632 7300 0000 3600 0000 020b RDOFF2s...6.....
00000010: 0003 005f 7374 7263 6d70 0002 0900 0400 ..._strcmp......
00000020: 5f6d 6169 6e00 0108 0001 0000 0004 0100 _main...........
00000030: 0108 0006 0000 0004 0100 0108 400b 0000 ............@...
00000040: 0004 0300 0100 0000 0000 1300 0000 6800 ..............h.
00000050: 0000 0068 0400 0000 e8f1 ffff ff83 c408 ...h............
00000060: c302 0001 0000 0008 0000 0061 6263 0061 ...........abc.a
00000070: 6264 0000 0000 0000 0000 0000 00 bd...........

This is the output from rdfdump, a tool included with nasm.

2025-11-22 22:01:56 ~/projects/binarygolf/bggp6/nasm-nasm-2.15
▶ rdoff/rdfdump rdoff/test/testlib.rdf
RDOFF dump utility, version 2.3
RDOFF2 revision 0.6.1
Copyright (c) 1996,99 Julian R Hall
Improvements and fixes (c) 2002-2004 RET & COM Research.
File rdoff/test/testlib.rdf: RDOFF version 2

Object content size: 115 bytes
Header (54 bytes):
 extern: segment 0003 = _strcmp
 extern: segment 0004 = _main
 relocation: location (0000:00000001), length 4, referred seg 0001
 relocation: location (0000:00000006), length 4, referred seg 0001
 relocation: location (0040:0000000b), length 4, referred seg 0003

Segment:
 Type = 0001 (text)
 Number = 0000
 Resrvd = 0000
 Length = 19 bytes

Segment:
 Type = 0002 (data)
 Number = 0001
 Resrvd = 0000
 Length = 8 bytes

NULL segment

Total number of segments: 2
Total segment content length: 27 bytes

Sick!!

Let’s try building 6.asm since the code is simpler and also targets x86_64.

./nasm -f rdf 6.asm -o 6.rdf

This also works! What happens when you run it?

2025-11-22 22:06:23 ~/projects/binarygolf/bggp6/nasm-nasm-2.15/rdoff
▶ ./rdx ../6.rdf
rdx: could not find symbol '_main' in '../6.rdf'

Uh oh, it says it can’t find the _main symbol. The same thing happens with testlib.rdf too… We DID just do the one thing they told us not to: reset the segment numbers.

It’s likely that nasm incorrectly generated the file, and any further modifications to the nasm source could create even more problems. Let’s analyze the file ourselves to see how the generated structures actually line up from a binary perspective.

RDOFF File Analysis

This is a hex dump of 6.rdf:

00000000: 5244 4f46 4632 4000 0000 1100 0000 0209 RDOFF2@.........
00000010: 0003 005f 6d61 696e 0005 0401 0000 0001 ..._main........
00000020: 0000 0000 000c 0000 00b8 3c00 0000 bf06 ..........<.....
00000030: 0000 000f 0502 0001 0000 0001 0000 0000 ................
00000040: 0000 0000 0000 0000 0000  ..........

There are two strings in the hex dump, the RDOFF2 file signature, and the global function _main. The code section starts at offset 0x29

The rdfdump utility uses the same file parsing functions as rdx. It shows information about the RDF file’s contents.

2025-11-22 22:06:39 ~/projects/binarygolf/bggp6/nasm-nasm-2.15
▶ ./rdoff/rdfdump 6.rdf
RDOFF dump utility, version 2.3
RDOFF2 revision 0.6.1
Copyright (c) 1996,99 Julian R Hall
Improvements and fixes (c) 2002-2004 RET & COM Research.
File 6.rdf: RDOFF version 2

Object content size: 64 bytes
Header (17 bytes):
 extern: segment 0003 = _main
 bss reservation: 00000001 bytes

Segment:
 Type = 0001 (text)
 Number = 0000
 Resrvd = 0000
 Length = 12 bytes

Segment:
 Type = 0002 (data)
 Number = 0001
 Resrvd = 0000
 Length = 1 bytes

NULL segment

Total number of segments: 2
Total segment content length: 13 bytes

Weird, the header appears to have _main listed as an extern, and in segment 3? I thought it was supposed to be GLOBAL? Also, where does the segment number come from? The .data and .bss look like what I would expect, and my .text is indeed 12 bytes long. If there are no errors, why doesn’t it run?

With a valid RDF that can be parsed by rdfdump, it felt like the right idea to start writing my own generator that implements the file format, and use rdfdump to validate it against the loader implementation shared with rdx.

RDOFF Scapy Implementation

scapy is a packet manipulation library written in Python, and is quite good at that! The cool part about scapy is that it has a lot of nice built in data types for you to use, from all the weirdo data types needed in all the protocols it supports. As a result, it makes a fantastic library for parsing and crafting files as well. Who says you have to send() the “packets” you construct anyways? What is a packet if not a file in motion?

Using scapy’s APIs, I wrote an RDOFF implementation here that consists of a header, and the two main record types:

Header Records - We need a GLOBAL and a BSS segment. Also included are definitions for the other segment types. Each one of these has a slightly different layout, so I turned them all into their own classes.
Segments - This is just a single class that contains the Segment data structure and the contents.

I won’t go into full details about writing in scapy, but I do plan to write a blog about using scapy for file format hax soon! I mainly just went through the RDOFF code and found the relevant structures, then translated them to scapy fields of the correct type. I did my best to keep most of the naming from the original source, but some structs and fields have different names that refer to the same thing. I also read through the loader code to verify how certain things were processed, if at all.

After some time (and a bit of rubber duckying in the binary golf discord voice chat), I got a full parser working for 6.rdf.

▶ python3 RDOFF.py
###[ RDOFF ]###
 magic = b'RDOFF2'
 obj_len = 64
 hdr_len = 17
 \hdr \
 |###[ Header ]###
 | \hdr_records\
 | |###[ RDFHDR_TLVs ]###
 | | type = IMPORT
 | | length = 9
 | | \value \
 | | |###[ RDFREC_IMPORT ]###
 | | | flags = 0
 | | | segment = 3
 | | | label = b'_main'
 | |###[ RDFHDR_TLVs ]###
 | | type = BSS
 | | length = 4
 | | \value \
 | | |###[ RDFREC_BSS ]###
 | | | bss_size = 1
 \segs \
 |###[ Header ]###
 | \rdf_segs \
 | |###[ RDFHDR_TLVs ]###
 | | type = TEXT
 | | number = 0
 | | resrvd = 0
 | | length = 12
 | | data = b83c000000bf060000000f05
 | |###[ RDFHDR_TLVs ]###
 | | type = DATA
 | | number = 1
 | | resrvd = 0
 | | length = 1
 | | data = 00
 | |###[ RDFHDR_TLVs ]###
 | | type = NULL
 | | number = 0
 | | resrvd = 0
 | | length = 0
 | | data =

It matches up pretty well with the output from rdfdump! I also used the library to also generate an exact copy of the original RDF that nasm made me :))

Satisfying The Loader: rdx Analysis

Previously, I noticed that the Header Record Type for the section pointing to _main was IMPORT (2) (or EXTERN in the rdfdump output) instead of what I would expect it to be, EXPORT (3) (also called GLOBAL in the nasm code). Header Record Type GLOBAL (3) has an extra field describing the offset of the text segment. I didn’t know where the offset field was supposed to point to. Is it relative to the start of the file, or the .text segment? Same with the segment field which was set to 3 before. To be safe, I just left both at 0.

Why did the nasm generator swap my global to an import and put it at segment 3 in the first place? This would be actually asking to the linker for the _main function instead of specifying it as a global symbol.

The more I thought about it, the more questions I had. Where would _main even come from if I didn’t specify any other modules? What linker is it using? Where is the program being loaded in the first place? How is the image set up in the process? I had to re-focus.

The core issue was that _main can’t be found:

rdx: could not find symbol '_main' in '../6.rdf'

Let’s take a look at rdx.c to see where the error coming from. rdx is a short program, really just meant to demonstrate the rdf loader capabilities. I adore the funny C shellcode loader style trick to execute the code. It only executes code after it is able to find _main in the symbol table and resolve it’s offset.

78
79
80
81
82
83
84
85
86
87
88
89
90


 s = symtabFind(m->symtab, "_main");
 if (!s) {
 fprintf(stderr, "rdx: could not find symbol '_main' in '%s'\n",
 argv[1]);
 exit(255);
 }

 code = (main_fn)(size_t) s->offset;

 argv++, argc--; /* remove 'rdx' from command line */

 return code(argc, argv); /* execute */
}

This is a diagram of the various calls that process the incoming .rdf file and set up the code to execute.

%%{init: {'theme':'dark'}}%%
flowchart LR
classDef success stroke:#0f0
classDef important stroke:#0ef
rdx("rdx")
rdfload("rdfload")
rdfopen("rdfopen")
rdfopenhere("rdfopenhere")
rdfrelocate("rdfrelocate")
rdfgetheaderrec("rdfgetheaderrec")
symtabInsert("symtabInsert")
symtabFind("symtabFind")
code("code()"):::success
rdx --> rdfload
rdfload --> rdfopen
rdfopen --> rdfopenhere:::important
rdx --> rdfrelocate:::important
rdfrelocate --> rdfgetheaderrec
rdfrelocate -->|if type 3| symtabInsert
rdx --> symtabFind:::important
rdx -->|if _main found| code

The initial parsing is done by rdfopenhere, which reads the file and sets up internal structures based on the first header. Notably, it rejects the RDOFF1 type altogether! If successful, rdx calls the rdfrelocate function, and iterates over the headers looking for two types: Relocate (1) and Export (3). If it finds an Export header record, it adds it’s name to the symbol table, which is where symtabFind looks for _main.

This means that our Import (2) Header Record Type never gets processed! In fact, load-time linkage is not supported at all. From rdfload.c

163
164


/* We currently do not support load-time linkage.
 This should be added some time soon... */

I created a test RDOFF with my scapy lib, using an GLOBAL type instead of an IMPORT type.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42


def test3_global():
 # This generates an RDF with an Global/Export/Public header type that can be loaded by rdx called global.rdf
 # It doesn't use any tricks to make it small
 # df5a07fb3400e95d4c68cb36a10451f15bd1ca536b50993709d7a534a3b3f4a6 global.rdf
 # (venv-2025) 2025-11-24 14:10:16 ~/projects/binarygolf/bggp6 
 # ▶ xxd global.rdf 
 # 00000000: 5244 4f46 4632 4300 0000 1400 0000 030c RDOFF2C.........
 # 00000010: 0000 0000 0000 5f6d 6169 6e00 0504 0100 ......_main.....
 # 00000020: 0000 0100 0000 0000 0c00 0000 b83c 0000 .............<..
 # 00000030: 00bf 0600 0000 0f05 0200 0100 0000 0100 ................
 # 00000040: 0000 6600 0000 0000 0000 0000 00 ..f..........

 # Setting up the header - a GLOBAL, which points to the code section
 hdr_global = RDFREC_GLOBAL(segment=0,label="_main")
 # This one BSS segment is also needed
 hdr_bss = RDFREC_BSS(bss_size=1)

 # Now we construct the header and add our records to the list
 rdf_hdr = RDFHDR()
 rdf_hdr.hdr_recs.append(RDFRECS(type=RDFREC.GLOBAL, length=len(hdr_global), value=hdr_global))
 rdf_hdr.hdr_recs.append(RDFRECS(type=RDFREC.BSS, length=len(hdr_bss), value=hdr_bss))

 # This is the code we want to run, here it just exits 6 using a syscall
 mycode = bytes.fromhex("b83c000000bf060000000f05")

 # construct the segments
 rdf_segs = RDFSEGS()
 rdf_segs.rdf_segs.append(RDFSEG_TLV(type=RDFSEG.TEXT, length=len(mycode), data=mycode))
 rdf_segs.rdf_segs.append(RDFSEG_TLV(type=RDFSEG.DATA, number=1, length=1, data=b"\x66"))

 # This padding was added by nasm, not sure if it was intentional but we account for it anyways
 padding = b"\x00" * 10 # unknown usage
 obj_len = len(rdf_hdr) + len(rdf_segs) + len(padding) + 4 # the +4 is for the hdr_len for now

 # Now to initialize the entire file buffer and add our segments, appending the padding
 rdoff = RDOFF(hdr_len=len(rdf_hdr),hdr=rdf_hdr, segs=rdf_segs, obj_len=obj_len) / padding

 rdoff.show2() # show the dissected fields

 with open("global.rdf","wb") as f:
 f.write(bytes(rdoff))
 f.close()

rdfdump doesn’t seem to have a problem with this, a good sign!

(venv-2025) 2025-11-23 18:43:46 ~/projects/binarygolf/bggp6
▶ ./nasm-nasm-2.15/rdoff/rdfdump global.rdf
RDOFF dump utility, version 2.3
RDOFF2 revision 0.6.1
Copyright (c) 1996,99 Julian R Hall
Improvements and fixes (c) 2002-2004 RET & COM Research.
File global.rdf: RDOFF version 2

Object content size: 67 bytes
Header (20 bytes):
 public: (0000:00000000) = _main
 bss reservation: 00000001 bytes

Segment:
 Type = 0001 (text)
 Number = 0000
 Resrvd = 0000
 Length = 12 bytes

Segment:
 Type = 0002 (data)
 Number = 0001
 Resrvd = 0000
 Length = 1 bytes

NULL segment

Total number of segments: 2
Total segment content length: 13 bytes

Oh neat, new way to refer to Header Record Type 3 (GLOBAL or EXPORT) just dropped: PUBLIC !!

Anyways, this file segfaulted rdx, but for a curious reason.

I re-ran rdx in gdb and noticed that the value in *s->offset looks correct-ish, but it was missing something. I added the top half of the base address to *s->offset and then did a hex dump on that address. The code was in the correct place, but the address was truncated to 32 bit!

Whoops, need a 32bit executable heap

I took at look at the code for the record types and found the definition for “Public/export record” (no love for “GLOBAL” here). The offset is indeed an int32_t…

include/rdoff.h

85
86
87
88
89
90
91
92
93
94
95


/*
 * Public/export record
 */
struct ExportRec {
 uint8_t type; /* must be 3 */
 uint8_t reclen; /* content length */
 uint8_t flags; /* SYM_* flags (see below) */
 uint8_t segment; /* segment referred to (0/1/2) */
 int32_t offset; /* offset within segment */
 char label[EXIM_LABEL_MAX]; /* zero terminated as in import */
};

If you recall rdx.c, the code is provided by s->offset, meaning that this is the actual address we control here.

85
86
87


 code = (main_fn)(size_t) s->offset;
 argv++, argc--; /* remove 'rdx' from command line */
 return code(argc, argv); /* execute */

With execution being tantalizingly close, I decided to try to make the code support 64 bit addresses.

These are all the places I changed from int32 to int64:

ExportRec->offset in rdoff/rdoff.h
textrel, datarel, bssrel in RDFModuleStruct in rdoff/rdfload.h
re-casting all the sizes in rdfload.c:L132-L134
symtabEnt->offset in rdoff/symtab.h

I re-ran the code, and rdx segfaulted again, but for a different reason.

It got to the entrypoint, but it can’t execute because it needs an executable heap…

This tells me that rdx hasn’t worked on a 64 bit system, probably ever. The way the process image is set up just calls nasm_malloc(), and doesn’t set up any sort of sandbox or tweak any permissions for the code tries to load and run. It just allocates a chunk in the existing nasm heap and lets it rip I guess. This is pretty cool, it’s basically just a little shellcode loader! All these nerds decided the heap needed to be protected and ruined the fun. :(

iximeow saves the day

While I was debugging this issue in voice chat, iximeow suggested I rewrite the nasm_malloc() calls in rdfload with mmap() instead, so that I can just reuse the existing 32 bit values by mapping the allocated memory to the 32 bit address space. This solves both problems and simplifies it greatly!!

While I was busy getting pwned by the nx bit, ixi actually wrote the patch for rdfload.c, which is here:

diff --git a/rdoff/rdfload.c b/rdoff/rdfload.c
index 1c24f2fc..1a1803cd 100644
--- a/rdoff/rdfload.c
+++ b/rdoff/rdfload.c
@@ -51,6 +51,8 @@
 #include "symtab.h"
 #include "collectn.h"

+#include <sys/mman.h>
+
 extern int rdf_errno;

 rdfmodule *rdfload(const char *filename)
@@ -81,17 +83,26 @@ rdfmodule *rdfload(const char *filename)

 /* read in text and data segments, and header */

+ /*
+ * (((ULONG_PTR)(x)) + PAGE_SIZE-1) & (~(PAGE_SIZE-1)) ) // useless comment
+ * want 32-bit offsets and permissions to work with, so mmap instead
 f->t = nasm_malloc(f->f.seg[0].length);
- f->d = nasm_malloc(f->f.seg[1].length); /* BSS seg allocated later */
+ f->d = nasm_malloc(f->f.seg[1].length); // BSS seg allocated later
+ */
+ #define PAGE_CEIL(x) ((x & !0xfff) + 0x1000)
+ f->t = mmap(0, PAGE_CEIL(f->f.seg[0].length), PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANON | MAP_32BIT, 0, 0);
+ f->d = mmap(0, PAGE_CEIL(f->f.seg[1].length), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON | MAP_32BIT, 0, 0);
 hdr = nasm_malloc(f->f.header_len);

 if (!f->t || !f->d || !hdr) {
 rdf_errno = RDF_ERR_NOMEM;
 rdfclose(&f->f);
 if (f->t)
- nasm_free(f->t);
+ munmap(f->t, PAGE_CEIL(f->f.seg[0].length));
+ // nasm_free(f->t);
 if (f->d)
- nasm_free(f->d);
+ munmap(f->d, PAGE_CEIL(f->f.seg[1].length));
+ // nasm_free(f->d);
 nasm_free(f);
 nasm_free(hdr);
 return NULL;

Executing RDOFF

After applying the path, global.rdf runs! It exits 6 as expected!!!

It even works outside of gdb (the real test)

Hell yeah!!!

Pouring One Out For RDOFF

What began life as an internal test case for nasm’s object file generator, ended as a forgotten file format. By the time it was removed from nasm, RDOFF was broken shell of it’s former self, it’s machinery unceremoniously optimized out.

The key (only?) benefit of RDOFF was it’s simplicity, but even with it’s barebones spec, the reference implementation was never fully fleshed out. Many features which were part of the original spec, such as dynamic linking, remained incomplete or undefined through it’s entire lifespan. The desire to keep the format flexible for “someone” to use, left key design decisions up to whoever dared to. RDOFF came out in 1997, 2 years before ELF was standardized as the default binary for Linux. By the time RDOFF2 came out in late 2002, many compilers and assemblers were already targeting ELF, PE, and their associated object files. It feels like RDOFF2 was more of an idea than a file format. A dream, yearning for a simple, flexible format, based on common features of existing formats. The only problem was that there was no one to build it. I can see why the nasm team would finally remove it and refactor all the surrounding library code.

To be honest, I am glad that they removed something that is no longer supported. Having a random file format that no one knows anything about that can be executed by a loader that most people don’t realize ships with nasm seems like the right thing to do. I can appreciate it’s quirkiness, it’s 90s style C, it’s undefined behavior. But for a general use format, I would def stick with object files targeting ELF or PE :) unless u a fweak !!

What’s Next?

I wanted to put out this writeup to see if anyone would come out of the woodwork in defense of RDOFF. I would love to see any other examples of custom usages, or formats that used RDOFF as a basis or inspiration. I hope this write up serves as a case study on how to preserve endangered file formats as well.

In Part 2, I am going to go over golfing RDOFF files. As of this writing, the smallest spec conforming RDF I could make (that still returns 6) is 62 bytes!

SHA256:

68554fbb087180353ab2ef6b10bf91613dc31206824c11baccea7b0705d3c449

Given the weirdness of the loader, it feels like it’s possible to go even smaller. I will also test other RDOFF loaders and generators mentioned in this writeup.

RDOFF alt defs

Really Dumb Object File Format (rqu)
Random Dudes Only File Format 2 (gilda)
RDOFF Development, Only For Freaks (me)

BGGP6 Wireshark Dissector Lua

Sun, 02 Nov 2025 12:00:00 -0400

I wanted to create the smallest Lua dissector for Wireshark for BGGP6! This year’s challenge theme is RECYCLE, which opens up all the previous challenges for this year, running until January 18th 2026. Another option is to create the smallest file of a given type that prints, returns, or otherwise displays “6”, which is what I am doing here.

I have previously written about using Wireshark as a lolbin and call os.execute() to run a program through Lua. Tiktok PoC Vid.

Lua dissectors are used to add additional protocol support without having to recompile Wireshark (as with C dissectors).

To install a new Lua dissector, place them in one of the following locations before opening Wireshark:

Linux: ~/.local/lib/wireshark/plugins
MacOS: ~/.local/lib/wireshark/plugins or ~ /.config/wireshark/plugins
Windows: C:\Program Files\Wireshark\plugins\

Lua Dissectors on the Wireshark Wiki: https://wiki.wireshark.org/Contrib

Some dissectors I’ve written: https://github.com/netspooky/dissectors

The pcap used in this writeup is telnet-cooked.pcap from here: https://wiki.wireshark.org/samplecaptures#telnet

DissectorTable.get

To start, I went with what I know, and used DissectorTable.get to create a dissector that would run on every packet sent to TCP port 23.

Here is a simple dissector to do that in 230 bytes (without comments): 6-vanilla.lua:

1
2
3
4
5
6
7
8
9


myProtocol=Proto("bggp6","bggp6") -- Create the protocol

function myProtocol.dissector(buffer, pinfo, tree) -- Declare the dissector
 pinfo.cols.protocol="BGGP6"
 z=tree:add(myProtocol,buffer(),"BGGP6")
end

local dtable=DissectorTable.get("tcp.port") -- Get the table of TCP ports
dtable:set(23,myProtocol) -- Register your dissector on this port, calling :set() overrides other dissectors

I did some experiments to see how little I could get away with during the basic dissector declaration. I shortened the protocol name to “b6”. Protocol names must be at least two characters, and they must start with a character from a-z. I also started putting a 6 in as many spots as I could instead of a string.

139 bytes: 6-139.lua

1
2
3
4
5
6
7
8
9


s=Proto("b6",6)

function s.dissector(b, p, t)
 p.cols.protocol=6
 z=t:add(s,b(),6)
end

local e=DissectorTable.get("tcp.port")
e:set(23,s)

Result:

Even though it’s already pretty small, I could still shrink it a bit more. I got rid of the statement that adds the packet buffer to dissector tree (highlighted in the above image) and kept it so that it only overwrote the protocol in the packet table in the GUI with 6 instead of “BGGP6”. This was 108 characters.

1
2
3


s=Proto("b6",6)
function s.dissector(b, p, t) p.cols.protocol=6 end
DissectorTable.get("tcp.port"):set(23,s)

I removed some more unneeded things like the 3rd argument to the dissector function, and reconfigured it to hijack every IPv4 eth.type using the ethertype DissectorTable (see 13.3.2. DissectorTable). These changes resulted in a packet that was also 108 bytes.

1
2
3


s=Proto("b6",6)
function s.dissector(b,p) p.cols.protocol=6 end
DissectorTable.get("ethertype"):set(0x800,s)

Later on, I realized that you can also overwrite pInfo.cols.info instead of protocol to save an additional 4 bytes, bringing this down to 104 bytes. See next section for info!

1
2
3


s=Proto("b6",6)
function s.dissector(b,p) p.cols.info=6 end
DissectorTable.get("ethertype"):set(0x800,s)

register_heuristic

I wanted to created a dissector that would override every Ethernet frame, and not just those with the IPv4 ethertype. A way to do this is to create a heuristic dissector using register_heuristic

This 112 byte dissector overwrites p.cols.protocol with 6, and returns 1. Returning 1 or True will tell the dissection engine that you claim the packet, and trigger only your dissector!

1
2
3


s=Proto("b6",6)
s.dissector=function(b,p) p.cols.protocol=6 return 1 end
s:register_heuristic("eth",s.dissector)

The dissector was still kind of long, so I turned it into a one liner at 86 bytes.

1

s=Proto("b6",6):register_heuristic("eth",function(b,p) p.cols.protocol=6 return 1 end)

It was here that I discovered you could overwrite p.cols.info to get down to 82 bytes.

1

s=Proto("b6",6):register_heuristic("eth",function(b,p) p.cols.info=6 return 1 end)

Searching for smaller functions to call

After getting to 82 bytes using register_heuristic, I started hunting for more global functions and builtins that could produce output. I started by looking for Wireshark builtins in the docs, since functions like print(6) are only available if you have debugging enabled. I wanted this to work on vanilla Wireshark, so I avoided that.

The first API I saw on the GUI function page was ProDlg.new, which would be 16 bytes, but it requires additional code to support it.

1

ProgDlg.new(6,6)

I found that new_dialog created a window, but needed a callback function as the 2nd argument which processes the data that is input into the window. Instead of declaring my own function, I just reused the print function as the callback.

21 bytes:

1

new_dialog(6,print,6)

I was hoping to find an even shorter standard Lua API to register as a callback, so I combed through all the standard Lua functions.

The only usable smaller functions are 4 characters, load, next and type. I used type since it seemed to be the safest, and got down to 20 bytes.

1

new_dialog(6,type,6)

Because of the argument requirement, I switched my focus to TextWindow.new() which despite being longer, can take just a single char argument.

Even though TextWindow.new is longer than new_dialog, the shorter amount of args makes it smaller. Even if i had a 1 char builtin or function, new_dialog would still only be 17 bytes due to the requirement of the arguments, so TextWindow.new() wins!

17 bytes:

1

TextWindow.new(6)

This is the smallest dissector I could manage that would output in Wireshark. It opens a single Text Window with the title “6”

Now that we know the limit, how can we make it more diabolical?

Listener.new

The register_heuristic approach only hooks Ethernet frames, but what if we wanted to hook every frame that came in?

We can use a Listener, which can get triggered prior to other dissectors being called. One caveat of Listeners is that they can’t modify any of the packet info, so we need to use the TextWindow.new(6) method to produce some output.

I took a similar approach to minifying a basic Listener, and got to 64 characters:

1

t=Listener.new(nil,"");t.packet=function() TextWindow.new(6) end

The last little trick is to turn this into a one liner by removing the last couple of spaces, bringing it down to 62 characters:

1

t=Listener.new(nil,"");t.packet=function()TextWindow.new(6)end

This oneliner opens up a new window on every new packet when sniffing, or every packet within a pcap when you open it directly like here :)

I found another funny thing that I will write up later. Like for Part 2!!!

about

Sat, 01 Nov 2025 12:00:00 -0400

Hello, I am netspooky!

Here are my links:

BGGP6 Announcement

Sat, 18 Oct 2025 10:00:00 -0400

https://binary.golf/6/

Phrack 72

Mon, 18 Aug 2025 12:00:00 -0400

This is the cover design I made for Phrack 72! It’s a physical collage made out of photocopied textures, letters, and cut outs from various sources. The paper I used was extremely bright, and it was quite difficult to scan haha. Next time I will just take a high res photo, because many scanners I tried made the colors look washed out. Shout out to ackmage for helping with color correction on the final image!

You will be able to order a copy of Phrack 72 with this cover by the end of 2025!

Read Phrack 72 here: https://phrack.org/issues/72/1

BGGP5 Wrapped

Fri, 21 Mar 2025 10:00:00 -0400

Full Writeup Here: https://tmpout.sh/4/17.html

Challenge: https://binary.golf/5

Repo: https://github.com/binarygolf/BGGP/tree/main/2024

tmp.0ut Volume 4

Fri, 21 Mar 2025 09:00:00 -0400

Link: https://tmpout.sh/4/

Phrack 72 CFP

Mon, 17 Mar 2025 09:00:00 -0400

See the full CFP here: https://phrack.org

impure89 Release

Fri, 28 Feb 2025 17:00:00 -0400

Some of my art was included in the latest ANSI art pack from impure! Check it out :)

https://16colo.rs/pack/impure89

impure produced one of my all time favorite demos, “all aboard the impure train!” (2017), which is an ASCII train that scrolls by with art pieces on the box cars that roll by. It reminded me of how graffiti artists who paint trains give each other tiny model trains all tagged up as gifts.

Demo Link: https://www.pouet.net/prod.php?which=72285
Video: https://www.youtube.com/watch?v=QmYJU5Qr8Jw

this was followed up with the impure express, which has a cityscape background.

Demo Link: https://www.pouet.net/prod.php?which=89791
Video: https://www.youtube.com/watch?v=X9wodTL9XVA

All their other art packs rule too, def go check out their archives on 16colo.rs!!

Phrack 71

Thu, 08 Aug 2024 12:00:00 -0400

I had the honor of creating the cover for Phrack 71 which was physically released at Defcon 2024!

Read the full issue here: https://phrack.org/issues/71/1

This is the original front cover image

The blue tones were added by ackmage for the final cover

They looked great printed! (link to grab a copy)

This was the back design I did, but it didn’t end up getting used…

…until the Phrack 72 CFP flyer!

Binary Golfing UEFI Applications (REcon 2024)

Sat, 29 Jun 2024 12:00:00 -0400

Slides: https://github.com/netspooky/golfclub/blob/master/uefi/bggp4/Binary-Golfing-UEFI-Applications.pdf

Video: Coming Soon!

BGGP5 Announcement

Fri, 21 Jun 2024 10:00:00 -0400

https://binary.golf/

Welcome To My Cool New On-Line Web Site

Fri, 14 Jun 2024 12:00:00 -0400

Hello! It’s been a while since I updated my website. I’m finally using a static site generator instead of the borked python script I used to use.

This is a major work in progress as I learn how to actually use this and make my old pages work in here. Apologies in advance if any paths change or things end up in unexpected spots. The result should be a much nicer experience for both you reading, and me publishing.

I realized I had a lot of stuff everywhere, but I didn’t know what to actually do with it. All the pages, repos, gists, twitter/mastodon threads, etc. really add up! Hopefully this new way of publishing will help me to organize a bit better.

The content of my site will be a more concise aggregation of all the stuff I’ve created previously. There is a notes section that contains less formal notes and writeups that I’ve done. There is also a cheatsheets page that is mainly for myself. Also the site’s content is reactive, yay! Lastly, I moved all the BGGP related pages to https://binary.golf ! Go check it out.

I am going to try to use this site more instead of social media for all my long form posts. I also am going to have a blog for non-tech stuff somewhere.

Thanks for visiting! If there are any issues with the site feel free to hit me up!!

About Me

Sat, 01 Jun 2024 12:00:00 -0400

wwwww

Contact

Sat, 01 Jun 2024 12:00:00 -0400

Github: https://github.com/netspooky
Twitter: https://twitter.com/netspooky
Mastodon: https://haunted.computer/@netspooky
Twitch: https://twitch.tv/netspooky
Youtube: https://youtube.com/c/netspooky
Electronic Mail: u AT n0 DOT lol

BGGP4: A 420 Byte Self-Replicating UEFI App For x64

Fri, 01 Mar 2024 12:00:00 -0400

Repo link with example code: https://github.com/netspooky/golfclub/tree/master/uefi/bggp4

Hello hello, this writeup serves as an extremely late entry to the fourth annual Binary Golf Grand Prix. The challenge was to create the smallest self-replicating file that prints, returns, or displays the number 4. My entry is a 420 byte self-replicating UEFI app.

In this writeup, I will cover UEFI, the UEFI x64 ABI, writing UEFI applications in x86_64 assembly, Tianocore EDK2 image loader internals, QEMU automation, and binary golf strategies for UEFI PEs.

Introduction
Why Is UEFI?
Getting Started
Basic UEFI Application
Understanding the x64 UEFI ABI
Printing 4 In Assembly
Quick Note On Debugging
Self Replicating
How Does UEFI Load Images?
Golfing The Binary
Conclusion

Introduction

I was already playing with UEFI when this challenge began, trying to understand services and explore interesting features built into the spec. UEFI is one of those things that I always “knew about” but never really dove into outside of reading write ups and books. I’ve written some x86 bootloaders and real mode programs in the past, such as MBR infectors and toy bootkits, but I had never tried to write anything for UEFI directly.

I actually didn’t even have a computer that used UEFI to play with until fairly recently. I used to use an old Dell laptop from the mid 00s, and I could load my disk images off a legit floppy and boot into them on real hardware. Now that pretty much every PC I have uses UEFI, I figured it was time to learn.

Let’s go over some of the stone cold facts about UEFI.

Why Is UEFI?

UEFI or (Unified Extensible Firmware Interface) is a type of firmware that creates a consistent interface to setup and manage devices (such as disks and hardware peripherals) that are needed for your operating system to boot.

It was developed as a replacement for traditional BIOS, to provide a unified set of APIs that abstract away a bunch of ancient constraints and programming requirements that are tedious to deal with manually.

BIOS King

What are these constraints and requirements you ask? They are things like needing to enable the A20 line to access all the memory for addressing in real mode (the mode your processor is in when it first turns on). This allowed you to store more things in memory like your bootloader or OS Image. You also had to do all the hardware initialization yourself, and simple things like disk reads (using Cylinder-head-sector) were very laborious.

…they have played us for absolute fools

The whole BIOS workflow was arduous, error prone, and problems were difficult to diagnose. On top of that you have to use the same BIOS interrupts the pioneers used to use. Peace be upon Ralf Brown’s INTERRUP.LST

Since old school BIOS was clunky and annoying, a bunch of manufacturers teamed up to make SMBIOS. This was originally known as DMIBIOS, because it interacted with a thing called Desktop Management Interface or DMI. SMBIOS provides a bunch of data structures (sometimes called “tables” or “records”) that contain information about the platform’s components or features.

Fun Fact: The original MS-DOS BIOS, known as IO.SYS, was named after famed Touhou Doujin circle IOSYS /s

If you want to play with a BIOS implementation, you can use SeaBIOS with QEMU:

git clone https://github.com/coreboot/seabios && cd seabios && make
qemu-system-x86_64 -bios out/bios.bin -nographic

Instead of booting a single bootloader like traditional BIOS, UEFI allows you to run Applications and Drivers. These applications can do various setup and verification tasks, as well as gather information about the state of the current hardware using well defined structures. After all this is set up, it passes to the boot code for your operating system, which boots the OS.

UEFI Spec 2.: Fig 2.1 Booting Sequence

UEFI abstracts the low level interface by taking all of the key BIOS features and turning them to APIs and a well defined environment that makes creating reliable firmware easier. UEFI exposes the core functionality as “Services” and “Protocols”, which are used to interact with the UEFI runtime and underlying hardware. UEFI is also useful from an operating system perspective, because you still need to interact with the hardware, and UEFI drivers can make it easier to do that.

UEFI is just a spec, and it’s not meant to be tied to any programming language or architecture. The most well known UEFI implementation is Tianocore EDK2, which contains a vast library of code and compatibility layers for a large number of targets.

EDK2 repo: https://github.com/tianocore/edk2

Getting Started

Before this challenge began, I was originally looking to write a small demonstration payload for the tiny Linux Kernel Module that rqu and I wrote for tmp.0ut Volume 3. We had been curious about UEFI from a Linux perspective, and were looking for a simple way to build and test small apps.

My go-to place for no-nonsense low level tutorials has been the OS Dev Wiki, and they had an article called UEFI App Bare Bones. This seemed like a good place to start, and it was using gnu-efi, which allows you to build UEFI apps using gcc on Linux.

gnu-efi repo: https://sourceforge.net/p/gnu-efi/code/ci/master/tree/

I won’t recommend gnu-efi for anyone getting started with UEFI programming, as it’s far more ropey than EDK2. It was helpful for reasons I will discuss in this writeup, but most tutorials and code examples you will see for UEFI will be from EDK2. This repo called UEFI-Lessons is a much better starting point for anyone who wants to use the EDK2 codebase.

Another good guide for getting started:

https://krinkinmu.github.io/2020/10/11/efi-getting-started.html

Basic UEFI Application

I built a basic application with gnu-efi based on the UEFI App Bare Bones tutorial on OS Dev. It displays a message and waits for a keypress, then it prints information about the keypress and exits. I used QEMU to run it.

1
2
3
4
5


/usr/bin/qemu-system-x86_64 \
 -drive if=pflash,format=raw,file=./OVMF.fd \
 -drive format=raw,file=fat:rw:./root \
 -net none \
 -nographic

This is what the code looks like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


#include <efi.h>
#include <efilib.h>

EFI_STATUS
efi_main (EFI_HANDLE image, EFI_SYSTEM_TABLE *systab)
{
 EFI_INPUT_KEY efi_input_key;
 EFI_STATUS efi_status;

 InitializeLib(image, systab);
 Print(L" (0w0)/ (^V^)/ (@.@)/ \n");
 Print(L" Your boys just want to \n");
 Print(L" dap you up before you boot.\n");
 Print(L"\n\n");
 Print(L" Press any key to dap.\n");
 WaitForSingleEvent(ST->ConIn->WaitForKey, 0);
 uefi_call_wrapper(ST->ConOut->OutputString, 2, ST->ConOut, L"\n\n");

 efi_status = uefi_call_wrapper(ST->ConIn->ReadKeyStroke, 2, ST->ConIn, &efi_input_key);

 Print(L"You dapped: ScanCode [%02xh] UnicodeChar [%02xh] CallRtStatus [%02xh]\n",
 efi_input_key.ScanCode, efi_input_key.UnicodeChar, efi_status);

 return EFI_SUCCESS;
}

Every UEFI application starts with efi_main. This is the main function of the program, with the EFI_HANDLE and the EFI_SYSTEM_TABLE passed as arguments.

The System Table (referred to as ST in this program) is an important structure that provides pointers to services you can call. The uefi_call_wrapper is just a way you can call these functions directly that is specific to this gnu-efi implementation. In EDK2, there are functions defined for these calls to make it a bit less clunky to use and provide some checks for the programmer.

To be honest, I liked how hacky this all was in gnu-efi, because it was easier to study than trying to look it all up in the EDK2 source.

Okay, let’s take a look at how OutputString is called via uefi_call_wrapper.

1

 uefi_call_wrapper(ST->ConOut->OutputString, 2, ST->ConOut, L"\n\n");

The first argument is a function pointer to the OutputString function of ConOut, which is stored in the System Table (ST).
The second argument is the number of arguments in this call.
The rest of the arguments are arguments to OutputString, which are ST->ConOut and two new lines.

This is the function prototype of OutputString, which has two arguments that match what we are seeing the in the code.

1
2
3
4


(EFIAPI *EFI_TEXT_STRING) (
 IN EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *This,
 IN CHAR16 *String
 );

Great! This shows us that if we want to golf this application, there are structures that can be traversed in order to find the functions we are looking for. This will help to avoid linking and symbols and everything that can make a binary extremely clunky.

Alright, so now we know how to build a basic app and call functions, how can we write it in assembly?

Understanding the x64 UEFI ABI

The UEFI firmware is the running program that we can interact with that can load our application. You can talk it using the UEFI shell. This shell provides a very basic set of tools to run applications, examine memory, query and set up peripherals and drivers, and other utilities.

The UEFI firmware I am using to test my applications is OVMF, which is the Open VM Firmware from EDK2 that is built to run in a virtual machine environment like QEMU.

At the Shell> prompt in OVMF, you can type fs0: to get to the first filesystem, which should be mapped to your root/ folder. Then you can see files using the dir command. The UEFI shell has a lot of interesting features and builtin commands. Type help to see a full list. They even have a cute lil hex editor built right in.

OVMF implements the UEFI ABI, which is a set of rules that are assumed to be followed by applications in a given environment. These rules dictate things like what registers are used as arguments to a function, which registers are considered volatile between function calls, how the stack should be aligned, and who takes care of cleanup. Normally this information is abstracted from developers by the compiler, but it’s required information for programming in assembly.

Even though the uefi_call_wrapper is a fairly low level call, it still doesn’t show us what the ABI is. It’s here that I started combing the docs for information, and comparing to what I saw when I opened my application in Ghidra. The glue code that supports uefi_call_wrapper is defined in inc/x86_64/efi_bind.h in the gnu-efi source.

Two important things to know are the Handoff State and Calling Conventions.

The x64 Handoff State is described in 2.3.4.1 in the spec. This describes the register state when an application first starts, AKA when control is passed to efi_main()

register	contents
rcx	EFI_HANDLE
rdx	EFI_SYSTEM_TABLE*
rsp	[return address]

The Calling Convention is defined in 2.3.4.2 in the spec. This is what registers represent arguments to a function.

Argument	Register	Note
1st	rcx
2nd	rdx
3rd	r8
4th	r9
5th	Stack
-	rax	Return value

If you want to know more about the UEFI programming environment, check out Section 2: Overview. All of the info for x64 platforms is in 2.3.4.

Armed with this information, we can start writing some assembly!

ic3qu33n found this repo that has UEFI programs built with nasm. I didn’t see these when I wrote this, but the examples may be useful if you’re trying to write UEFI programs in assembly: https://github.com/BrianOtto/nasm-uefi

Printing 4 In Assembly

One of the BGGP4 challenge requirements is that the application needs to return, print, or otherwise display the number 4. Since the example app prints something, I figured we could try to reimplement that functionality in assembly. I’ll explain the process of finding the smallest PE header that would work on UEFI later, but for now, know that I can generate small PEs to test.

This is a very basic implementation of calling OutputString() in UEFI. The way that this code is structured is similar to how a lot of the code in the final app will be. I’ll walk through this implementation as a way to introduce the ABI and how to use it to write code in assembly.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


EFI_SYSTEM_TABLE_ConOut equ 0x40
EFI_SYSTEM_TABLE_ConOut_OutputString equ 0x08
EFI_SYSTEM_TABLE_BootServices equ 0x60

cStart:
 mov rbp, rsp
 push rcx ; [rbp+0x08] ImageHandle
 push rdx ; [rbp+0x10] SystemTable

print4:
; https://uefi.org/specs/UEFI/2.10/12_Protocols_Console_Support.html#efi-simple-text-output-protocol-outputstring
; (EFIAPI *EFI_TEXT_STRING) (
; IN EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *This, // rcx
; IN CHAR16 *String // rdx
; );

 mov rax, rdx ; rax = SystemTable

 mov rdx, 0xa0034 ; rdx = String "4\n"
 push rdx ; [rbp+0x18] String "4\n"
 mov rdx, rsp ; rdx = *String

 mov rcx, [rax+EFI_SYSTEM_TABLE_ConOut] ; rcx = *This // The output file descriptor

 mov rax, rcx
 mov rax, [rax+EFI_SYSTEM_TABLE_ConOut_OutputString]
 call rax ; Call SystemTable->ConOut->OutputString()

bail:
 sub rsp, 0x18
 ret

The first three lines of this code are function offsets that are defined as constants to make the code a bit more readable. I got these offsets by examining the size of the structs we need to process, and comparing to what was in Ghidra when the call was actually made.

The cStart label is the start of the code. Since we know that the Handoff State puts useful data in rcx and rdx at the start of the program, we can push those on the stack because we will need them later on. The function we want to call is SystemTable->ConOut->OutputString(). This means we need to navigate the System Table to get the address OutputString so we can call it.

This is what the System Table looks like:

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


typedef struct {
 EFI_TABLE_HEADER Hdr;
 CHAR16 *FirmwareVendor;
 UINT32 FirmwareRevision;
 EFI_HANDLE ConsoleInHandle;
 EFI_SIMPLE_TEXT_INPUT_PROTOCOL *ConIn;
 EFI_HANDLE ConsoleOutHandle;
 EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *ConOut; // <-- We want this!
 EFI_HANDLE StandardErrorHandle;
 EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *StdErr;
 EFI_RUNTIME_SERVICES *RuntimeServices;
 EFI_BOOT_SERVICES *BootServices;
 UINTN NumberOfTableEntries;
 EFI_CONFIGURATION_TABLE *ConfigurationTable;
} EFI_SYSTEM_TABLE;

ConOut is a EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL type, which looks like this:

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


typedef struct _EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL {
 EFI_TEXT_RESET Reset;
 EFI_TEXT_STRING OutputString; // <-- We want this!
 EFI_TEXT_TEST_STRING TestString;
 EFI_TEXT_QUERY_MODE QueryMode;
 EFI_TEXT_SET_MODE SetMode;
 EFI_TEXT_SET_ATTRIBUTE SetAttribute;
 EFI_TEXT_CLEAR_SCREEN ClearScreen;
 EFI_TEXT_SET_CURSOR_POSITION SetCursorPosition;
 EFI_TEXT_ENABLE_CURSOR EnableCursor;
 SIMPLE_TEXT_OUTPUT_MODE *Mode;
} EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL;

This is the prototype for OutputString again, with the registers that these arguments are tied to.

1
2
3
4


 (EFIAPI *EFI_TEXT_STRING) (
 IN EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *This, // rcx
 IN CHAR16 *String // rdx
 );

ConOut is both the handle to the console’s text output, and contains functions for acting on it. I grabbed the SystemTable from rdx and put it in rax, then got the address of ConOut and put it in rcx. Then I copied it back to rax and got the address of OutputString(). Before calling, there needs to be a pointer to the string we want to print in rdx. I used the stack to push "4\n" and then move rsp into rdx to get the address of this string.

Note: UEFI uses UTF-16 for strings and filenames. In practice, this just means you need to add 00s between normal ASCII characters and end your string with two NULL bytes, instead of just 1.

Okay sick, does it work?

Yes! Sweet, now that we know how to set up and call functions, lets try to implement more of them in assembly!

Quick Note On Debugging

UEFI has various debugging features built in. The documentation can be a little confusing, because there are many different debugging situations described. If you are using EDK2, there is good documentation on how to use gdb for debugging.

The OS Dev wiki has some info on debugging with gdb as well.

To enable gdb debugging with QEMU, you need the -s flag in your command line arguments to QEMU:

1
2
3
4
5
6


/usr/bin/qemu-system-x86_64 \
 -drive if=pflash,format=raw,file=./OVMF.fd \
 -drive format=raw,file=fat:rw:./root \
 -net none \
 -nographic \
 -s

Then you can start debugging using gdb.

gdb root/example.efi
...
(gdb) target remote :1234

When I started working on my assembly UEFI app, I had trouble debugging it with gdb. I had originally been using the gdb extension gef, but support for UEFI, especially handcrafted apps, is not really all there yet. Only once I started using vanilla gdb was I able to remotely debug in QEMU.

One of the issues that made it even more frustrating to debug was that I kept getting weird crashes that I believe were the result of my original tests, which possibly corrupted my OVMF image. After restoring to a known good OVMF.fd file, things started working again. I included this OVMF.fd file in the repo.

You don’t have to do this, but I added this to my ~/.gdbinit file to enable running multiple commands on each line using gdb:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# multiple commands
python
from __future__ import print_function
import gdb


class Cmds(gdb.Command):
 """run multiple commands separated by ';'"""
 def __init__(self):
 gdb.Command.__init__(
 self,
 "cmds",
 gdb.COMMAND_DATA,
 gdb.COMPLETE_SYMBOL,
 True,
 )

 def invoke(self, arg, from_tty):
 for fragment in arg.split(';'):
 # from_tty is passed in from invoke.
 # These commands should be considered interactive if the command
 # that invoked them is interactive.
 # to_string is false. We just want to write the output of the commands, not capture it.
 gdb.execute(fragment, from_tty=from_tty, to_string=False)
 print()

Cmds()
end

This let me create oneliners of commands separated by semicolons that I could paste or use in scripts that was a bit easier to manage

Example:

cmds stepi; echo \[CODE\]\n ; x/3i $rip ; echo \[REGS\]\n ; i r rax rbx rcx rdx rsi rdi rbp rsp r8 r9 r10 r11 r12 r13 r14 r15 rip eflags; echo \[STACK\]\n ; x/20gx $sp

There are definitely other ways to do this, but this was a little workaround that was good enough for my purposes.

Self Replicating

Now that debugging was set up, it was time to understand how to do self-replication from a UEFI perspective.

When writing self replicating code for an operating system, there are usually system functions that can help you work with the filesystem to open and copy files. Since UEFI is operating below the OS level, there are some extra things that need to be done, but otherwise the filesystem functionality is similar to many others.

These are the things you generally need to do to copy a file on a given filesystem:

Open the original file
Open a new file
Write the contents of the original file to the new file
Close both files

The key difference for doing this on UEFI is that the filesystem needs to be located first, and then opened and accessed via an handle. It’s similar to needing to mount a disk before you start interacting with files on it.

To see how others did this, I started by looking at some examples I had found of people doing FileIO tests. This one in particular had the most examples: https://github.com/zhenghuadai/uefi-programming/blob/master/book/FileIo/TestFileIo.c

While examing this code, I took inventory of the UEFI calls it was doing. All I really needed at this point were the types and the function names, and then I could write with assembly from the spec directly.

I saw that their program had a function called GetFileIo() which passed a pointer to an EFI_FILE_PROTOCOL type variable named Root. This variable represents the filesystem root, and is opened by the call to OpenVolume().

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


EFI_STATUS
GetFileIo( EFI_FILE_PROTOCOL** Root)
{
 EFI_STATUS Status = 0;
 EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *SimpleFileSystem;
 Status = gBS->LocateProtocol(
 &gEfiSimpleFileSystemProtocolGuid,
 NULL,
 (VOID**)&SimpleFileSystem
 );
 if (EFI_ERROR(Status)) {
 //未找到EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
 return Status;
 }
 Status = SimpleFileSystem->OpenVolume(SimpleFileSystem, Root);
 return Status;
}

The code uses the SimpleFileSystem protocol to get a pointer to a structure that has the OpenVolume function we need. OpenVolume is then called on the Root pointer which populates this with the address of the Filesystem Root handle.

Wait WTH are protocols??

Protocols are basically just collections of services that a specific devices support. They are referenced with a GUID.

Each device has their own set of protocols. These can be accessed through a number of functions, and you can even install your own protocol handlers to a device if you want.

HandleProtocol takes argument of a GUID that represents the protocol. In return, it gives you a pointer to a list of functions related to that protocol that you can reference and use.

The technique that used in my code uses HandleProtocol() instead of LocateProtocol(). I saw HandleProtocol in other code I had already built, so I decided to use that instead of trying to set up a call to LocateProtocol.

The docs themselves state that you should use OpenProtocol instead of HandleProtocol, but it looked more complicated and I didn’t want to get off track implementing this behavior.

Interacting with the Filesystem

This is the prototype for HandleProtocol. Before the type in the arguments are either IN or OUT. IN is an input parameter, and OUT is a parameter that will be modified by the function you are calling.

1
2
3
4
5


(EFIAPI *EFI_HANDLE_PROTOCOL) (
 IN EFI_HANDLE Handle, // rcx
 IN EFI_GUID *Protocol, // rdx
 OUT VOID **Interface // r8
 );

I wrote an implementation that makes this call to HandleProtocol to get a file system interface based on the documentation and referencing some compiled code. This just sets up the SimpleFileSystem Protocol GUID and a pointer to the resulting interface, and then calls HandleProtocol.

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


handleSimpleFileSystemProtocol:
; Calling this to get a file system interface
 xor r8, r8 ; r8 = SimpleFileSystemProtocolInterface
 push r8 ; [rbp-0x50] SimpleFileSystemProtocolInterface
 mov r8, rsp ; r8 = *SimpleFileSystemProtocolInterface

 mov rdx, 0x3b7269c9a000398e
 push rdx ; [rbp-0x58] gEfiSimpleFileSystemProtocolGuid
 mov rdx, 0x11d26459964e5b22
 push rdx ; [rbp-0x60] gEfiSimpleFileSystemProtocolGuid
 mov rdx, rsp ; rdx = *gEfiSimpleFileSystemProtocolGuid

 ; Note that rcx is already set from earlier code

 mov rax, [rbp-EFI_SYSTEM_TABLE_BootServices_o]
 mov rax, [rax+EFI_BOOT_SERVICES_HandleProtocol]
 call rax ; Call EFI_BOOT_SERVICES::HandleProtocol()

Now that there is a file system interface in rdx, we can try to open the file we want to copy. Looking back at the TestFileIo.c file, the TestRead() function shows ways of reading files from the Root pointer.

This snippet looks like generally what I need. It has flags to specify what mode to open the file in like other operating systems, and the arguments seem easy to set up. The only thing I need to really change here is that I don’t need to create the file since it already exists. This code snippet comes from after a directory was opened, but the logic is the same on the file system root.

1
2
3
4
5
6
7
8
9


 EFI_FILE_PROTOCOL *ReadMe = 0;
 Status = EfiDirectory ->Open(
 EfiDirectory, // This (points to directory)
 &ReadMe, // file handle
 (CHAR16*)L"readme.txt", // filename
 EFI_FILE_MODE_CREATE | EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE, // mode
 0 // attributes
 );
 Status = ReadMe -> Close(ReadMe);

This is the Open function prototype:

1
2
3
4
5
6
7


(EFIAPI *EFI_FILE_OPEN) (
 IN EFI_FILE_PROTOCOL *This, // rcx
 OUT EFI_FILE_PROTOCOL **NewHandle, // rdx
 IN CHAR16 *FileName, // r8
 IN UINT64 OpenMode, // r9
 IN UINT64 Attributes // Stack
 );

The OpenMode and Attributes flags are defined here

The resulting implementation looks like this in assembly. Since we aren’t creating a file, it doesn’t need the Attributes argument.

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


OpenOriginalFile:
 mov r9, 1 ; rax = OpenMode

 mov r8, 0x61005c ; "\a" - Our file name
 push r8 ; [rbp-0x70] CurrentFileName
 mov r8, rsp ; R8 = *CurrentFileName

 xor rdx, rdx ; rdx = 0
 push rdx ; [rbp-0x78] OriginalFileHandle
 mov rdx, rsp ; rdx = **NewHandle

 mov rcx, [rbp-DeviceFSRoot_o] ; rcx = EFI_FILE_PROTOCOL::Root

 mov rax, rcx
 mov rax, [rax+EFI_FILE_PROTOCOL_Open] ; rax = EFI_FILE_PROTOCOL::Open
 call rax

I got both FileOpen and FileClose working for the original file. Now I need to read it somewhere into memory to copy to the new file.

Reading The File Into Memory

Before you can write the file, you need to read it into memory. To do that, you need to first allocate some memory.

The BootServices functions to allocate memory are fairly straightforward. AllocatePool allocates a chunk of memory, and FreePool frees it after use.

AllocatePool prototype

1
2
3
4
5


(EFIAPI *EFI_ALLOCATE_POOL) (
 IN EFI_MEMORY_TYPE PoolType, // rcx
 IN UINTN Size, // rdx
 OUT VOID **Buffer // r8
 );

My implementation:

1
2
3
4
5
6
7


AllocatePool:
 mov r8, rsp ; r8 = **Buffer
 mov rdx, [rbp-ImageSize_o]
 xor rcx, rcx ; EFI_MEMORY_TYPE PoolType = EfiReservedMemoryType
 mov rax, [rbp-EFI_SYSTEM_TABLE_BootServices_o]
 mov rax, [rax+EFI_BOOT_SERVICES_AllocatePool]
 call rax ; Call EFI_BOOT_SERVICES::AllocatePool()

FreePool prototype

1
2
3


(EFIAPI *EFI_FREE_POOL) (
 IN VOID *Buffer // rcx
 );

My implementation:

1
2
3
4
5


FreePool:
 mov rcx, [rbp-AllocatePoolBuffer_o]
 mov rax, [rbp-EFI_SYSTEM_TABLE_BootServices_o]
 mov rax, [rax-EFI_BOOT_SERVICES_FreePool]
 call rax ; Call EFI_BOOT_SERVICES::FreePool()

To actually read the file contents into this chunk, you need to use the EFI_FILE_READ function

Read prototype:

1
2
3
4
5


(EFIAPI *EFI_FILE_READ) (
 IN EFI_FILE_PROTOCOL *This, // rcx
 IN OUT UINTN *BufferSize, // rdx
 OUT VOID *Buffer // r8
 );

My implementation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


ReadOriginalFile:
 mov r8, [rbp-AllocatePoolBuffer_o] ; r8 = *Buffer

 ;mov rdx, [rbp-ImageSize_o] ; rdx = BufferSize ; This one didn't work!!
 lea rdx, [rbp-ImageSize_o] ; rdx = *BufferSize

 mov rcx, [rbp-OriginalFileHandle_o] ; rcx = *This

 mov rax, rcx
 mov rax, [rax+EFI_FILE_PROTOCOL_Read]
 call rax ; Call EFI_FILE_PROTOCOL::Read()

To get the BufferSize variable that represents how much data you want to read, you need to get the size of the whole loaded image. Rather than trying to type it manually as the size of the image changes, it was easier to resolve it using the LoadedImage Protocol. The way to access this protocol is the same as when we set up SimpleFileSystem Protocol, so I just reused the code and replaced it with the GUID for LoadedImage Protocol.

Something that I missed the first time around, is that the BufferSize is both an IN and an OUT in the prototype. From the docs:

On input, the size of the Buffer. On output, the amount of data returned in Buffer. In both cases, the size is measured in bytes.

I had mistakenly thought BufferSize was just a value to pass to the function in rdx, but it actually needs to be a pointer because it’s used as output. When you pass a value in rdx instead of a reference, the call to Read() still returns with a 0 in rax, indicating EFI_SUCCESS.

The docs say that this means that the data was read, but it doesn’t actually mean that. The call will silently fail, and your buffer will point to uninitialized data instead. When I was originally working on this part, I didn’t realize that my buffer was full of junk data. It was only when I tried to write it to a new image that I realized something was wrong, but it was hard to know where exactly my code had failed until I read the spec for every API I was calling and documented all the function prototypes for each.

Writing Data To A New File

Now that we have a buffer containing the original file’s data, we need to write it to the new file. The new file needs to be created using the Open() call, but with the EFI_FILE_MODE_CREATE flag set in the OpenMode.

Using Five Arguments In A Call

If you call Open() with EFI_FILE_MODE_CREATE, you need to pass a fifth argument to the function. When you are using five arguments, the Calling Conventions say that the fifth argument needs to be on the stack. I had tried a few things to set the stack up properly, but I kept getting a Bad Parameter error from the Open call. I was wondering if it was an alignment issue or something else, but I couldn’t find any references to how to arrange the stack for this.

I talked to ic3qu33n about this, and she told me that the stack needed to be 0x20 bytes. I implemented this and was excited to finally copy my file. It was here that I realized the the buffer was full of uninitialized memory, with the pattern 0xfa over and over.

My BufferSize was a value and not a reference, so the Buffer that I tried to write was full of junk data. This confusion drove me insane for a bit, thinking that I had messed my handle up somewhere. It was only when I looked at the spec again in depth and realized that the BufferSize needed to be a pointer that it worked.

File Write

Now that the new file is open, we can write the buffer containing the original file’s contents to the new file. You do that by doing calling EFI_FILE_WRITE

1
2
3
4
5


(EFIAPI *EFI_FILE_WRITE) (
 IN EFI_FILE_PROTOCOL *This, // rcx
 IN OUT UINTN *BufferSize, // rdx
 IN VOID *Buffer // r8
 );

This call was pretty straightforward to implement in assembly.

1
2
3
4
5
6
7


WriteNewFile:
 mov r8, [rbp-AllocatePoolBuffer_o] ; r8 = *Buffer
 lea rdx, [rbp-ImageSize_o] ; rdx = *BufferSize
 mov rcx, [rbp-NewFileHandle_o] ; rcx = *This
 mov rax, rcx
 mov rax, [rax+EFI_FILE_PROTOCOL_Write]
 call rax ; Call EFI_FILE_PROTOCOL::Write()

Now that we have the file written, all we have to do is call EFI_FILE_CLOSE

(EFIAPI *EFI_FILE_CLOSE) (
 IN EFI_FILE_PROTOCOL *This // rcx
 );

And that’s it! Now that we have the logic down, let’s start looking at the PE parser!

How Does UEFI Load Images?

When you run an application, the UEFI firmware calls a Boot Service known as LoadImage. This function loads an EFI image into memory and returns a handle to that image. There are actually two types of binaries you can load using LoadImage: Portable Executables (PE) and Terse Executables.

The Terse Executable is a stripped down version of the PE, which was made for UEFI. This seemed like an interesting avenue to explore, but I decided to focus on the PE loader for this challenge and writeup because I wanted cover a deeper dive into LoadImage and StartImage and experiments with TE in a later writeup. There are Kaitai structs for TE files if you’re interested in exploring more.

Lets take a look at how LoadImage eventually gets to the PE and TE parser.

Call Stack:
BootServices // MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c
CoreLoadImage // MdeModulePkg/Core/Dxe/Image/Image.c
CoreLoadImageCommon // MdeModulePkg/Core/Dxe/Image/Image.c
CoreLoadPeImage // MdeModulePkg/Core/Dxe/Image/Image.c
PeCoffLoaderGetImageInfo // MdePkg/Library/BasePeCoffLib/BasePeCoff.c
PeCoffLoaderGetPeHeader // MdePkg/Library/BasePeCoffLib/BasePeCoff.c
There is another BasePeCoff.c with similar functions in BaseTools/Source/C/Common/, but it's not referenced here.

The LoadImage boot service is referred to as CoreLoadImage in the codebase. It invokes a chain of functions that eventually lead to the parser logic, a function called PeCoffLoaderGetPeHeader.

I used ctags in vim to navigate this codebase. It made it a lot easier to find the real definitions of functions and structures than even vscode or github. Thanks to xcellerator for putting me on to it.

When PeCoffLoaderGetPeHeader is called, it checks the following things:

OptionalHeader.NumberOfRvaAndSizes - Needs to be correct
FileHeader.SizeOfOptionalHeader - Size needs to be correct
FileHeader.NumberOfSections - Number needs to match the number of section headers
OptionalHeader.SizeOfHeaders
1. Read last byte of Hdr.Pe32.OptionalHeader.SizeOfHeaders to confirm that the headers are the correct size
Check there are enough Image Directory Entries to contain EFI_IMAGE_DIRECTORY_ENTRY_SECURITY

Looking at the code for step 5., we can see that it’s checking if the NumberOfRvaAndSizes field is greater than EFI_IMAGE_DIRECTORY_ENTRY_SECURITY which means that we need at least 6 Image Directories because the SECURITY entry is the 5th entry in the table.

127
128
129
130
131
132


// Check the EFI_IMAGE_DIRECTORY_ENTRY_SECURITY data.
// Read the last byte to make sure the data is in the image region.
// The DataDirectory array begin with 1, not 0, so here use < to compare not <=.
//
if (EFI_IMAGE_DIRECTORY_ENTRY_SECURITY < Hdr.Pe32Plus->OptionalHeader.NumberOfRvaAndSizes) {
 if (Hdr.Pe32Plus->OptionalHeader.DataDirectory[EFI_IMAGE_DIRECTORY_ENTRY_SECURITY].Size != 0) {

Now that we know the logic to get the header past the parser checks, we can experiment. I wrote a goofy script pe_filz.py to instrument my entire existing app and generate configurations of file header elements that would result in a binary that I could use to test. It’s extremely hacky, but it worked. I was able to get the binary that just printed a string from 48KB down to 416 bytes.

The minimum viable PE header to load an application was

MZ Header
PE Header
Optional Header
6 data directories (All blank)
A section header describing the .text section
Code

Golfing The Binary

Realistic Golfing Action

Now for the fun part, reducing the total size of the binary, by any means necessary.

TinyPE

TinyPE is a technique for making a very small PE header, which reduces the size of the file and can also provide some obfuscation. I wrote about TinyPEs for x64 bit here, with info about why it works. I decided to test the TinyPE template I made for a Windows shellcode tool I wrote called kimagure. This template was useful for generating small, reliable Windows binary payloads.

The trick that TinyPE relies on is setting the MZ header field e_lfanew to 0x04, which tells the loader that the PE header starts 4 bytes into the file. This overlays the PE header on the DOS header, without interfering with important values in either. The DOS header’s e_lfanew overlaps with the PE header’s SectionAlignment, which is valid for both. This logic is performed in PeCoffLoaderGetPeHeader here

I had to change a few things about the existing TinyPE template I had, but since I already had the structure of the minimum viable UEFI app documented, it was easier than expected. I made sure to add the data directories and the section header I needed, and then my example code.

I built the code using nasm and put it in the root folder for OVMF.

nasm -f bin bggp4.uefi.asm -o root/a

I ran it, and it worked!

If you’re curious about more TinyPE explorations, check out:

This discussion on pouet.net
This repo about creating TinyPEs for Windows 10

Also, UEFI has the same size limitation as 64 bit windows, which is 268 bytes. This is dictated by some sanity checks that calculate the expected size of certain header elements.

Creating A Testing Script

Now in the phase of making rapid changes to test my binary, I needed a way to speed up the slow process of manually running and interacting with OVMF in QEMU. There is a 5 second countdown before you get to the shell, and you need to press enter to move past it.

During my early debugging adventures for UEFI, I explored the QEMU HMP and QMP protocols. HMP lets you run commands in the QEMU monitor that you can use to do things like start and stop the vm, inspect the state etc. The QMP protocol is similar, except it’s a json API.

I decided to instrument QEMU using a simple script that would build my code, do a hexdump using yxd, start qemu, and send commands over a TCP socket to the HMP monitor to execute the binary and then compare the original file with the newly created file. After running, the script would read the VM output from a log file and report to me. All told, this script took about 4.5 seconds to execute, which was good enough for me in practice. I had explored the idea of using or building a snapshot fuzzer, but it was ultimately overkill for what I was trying to do.

This script is called test_app_qemu.py in this repo.

PROTIP: nasm can create a list of symbols in your assembly code by adding this to the top of your source. This will generate a file called mybin.map. This is super useful for debugging!

[map all mybin.map]

Exploring The Caves

Knowing that there were only a few places that actually mattered in the loader, I could start confirming all the bytes in the header that were free to overwrite. I made a list of hot spots I wanted to explore based on what was already 0 in the header, and then started putting the pattern 0xAA55 wherever I could. Then I put the string “FREE” in all of those places to test with another value, and everything still worked as it should. This resulted in 116 bytes in the file header which were free for me to put code and data into.

This is a table of offsets that represents free areas in the header.

Start	End	Size	Note
0x0C	0x18	12	FREE
0x1E	0x2C	14	FREE
0x34	0x3C	8	ImageBase - Is touchy
0x44	0x54	16	FREE
0x5C	0x60	4	FREE
0x60	0x62	2	Needs to be 0x0A :((
0x62	0x88	38	FREE
0x8C	0xAC	32	FREE

The 8 byte ImageBase field in the header is actually used in the code, so you have to be careful about what you put in there if you decide to use it. There was also an annoying 2 byte field for the Subsystem that needed to be 0x0A.

This is what the binary looked like at this point.

To be able to jump back into the header, I had to make sure that the .text section containing the code was located directly after the header in memory. I adjusted the value of AddressOfEntrypoint in the PE header, and the virtual address in the section header to make this happen.

I also needed to confirm that the header didn’t change in memory. Sometimes the header can be modified or destroyed in memory by the loading process, so it’s not always a reliable place to store anything. In this case it was perfectly intact!

I dumped the header from memory to a file with this command in gdb:

(gdb) dump binary memory pe_header_in_memory.bin 0x6222000 0x62220E4

jmp’ing Around The Header

Now I knew it was all working as expected, I started moving code up into the header. To do this, you need to know the actual size of the bytes for each instruction in your code. I used ndisasm to print out the disassembly for my binary so I could see the bytes for the instructions.

ndisasm -b 64 root/a

Now I can look at the total size of instructions and make sure that my assembler is doing the things I want it to do. Here’s an example of the disassembly for the first 6 instructions of the code:

000000E4 89E5 mov ebp,esp
000000E6 51 push rcx
000000E7 52 push rdx
000000E8 89D3 mov ebx,edx
000000EA 89D0 mov eax,edx
000000EC 488B5B60 mov rbx,[rbx+0x60]

I started dividing my code up into little chunks that were the size of the header areas I could store code in. I had to account for the size of short jumps that will need to go at the end of each chunk. These are 2 byte instructions that can jump forward or backwards, but they can only jump a limited distance. The furthest number of bytes you can jump backwards is 125. It’s really 127 bytes, but because it jumps from the next instruction’s offset, you have to account for the two bytes of the instructions.

Since the start offset is 0xE4, the furthest back you could jump from there is 0x69, because it’s 127 bytes from offset 0xE6. This offset in the file falls in the range of a large block of free bytes toward the end of the header. I put a jump at a location that would allow me to jump further up into the header, without adding to the size of the code in the .text section due to larger instruction size for longer jump distances. I also put a jump before it while developing, so I could have a reliable path back into the main code.

For more info on Short Jumps I refer you to my fav reference, The Starman’s Realm Using SHORT (Two-byte) Relative Jump Instructions. I highly recommend you check that page out if you are interested in sizecoding on x86!!

Super Metroid Space Jump

Using this jump spot, I started carefully removing the header definitions and replacing them nop instructions. This gave me a canvas to start painting my code chunks on. I worked a few instructions at a time, making sure that the header code made it back to the main code.

On each major change I did, I tested the output with my script, and confirmed that it all worked. Sometimes I could just tell I messed something up due to how the bytes were structured in the PE, and the fixes would usually involve adding or removing nops to put everything back where it goes.

Once I was satisfied with stuffing the header, I worked on optimizing the rest of the code.

Types Of Optimizations I Did

Instead of going through everything, I wanted to just describe the different types of optimizations I applied to the code. Most of the code is just calling UEFI Services and Protocol functions, so many changes could be applied to each block of code.

Assuming Addresses Are 32 Bit

Although we are in 64 bit mode, the addresses used in OVMF are 32 bits. This means that doing register to register movs on the 32 bit form of each register was safe to do.

By using the 32 bit registers, 1 byte can be saved per instruction.

0: 48 89 d3 mov rbx,rdx ; 3 bytes
3: 89 d3 mov ebx,edx ; 2 bytes!

Doing a register to register mov instruction will clear the top 32 bits of the register. This is okay for OVMF, but in other environments, you typically don’t want to do this unless you’re sure that no addresses will used more than 32 bits. When doing a mov on the the smaller forms of registers, only the 32 bit form will clear the top bits. For the 16 bit and 8 bit versions, it leaves the upper bits as is.

Table of how different register sizes affect mov in 64 bit mode. I cover this more in i2ao

mov rbx, rdx ; Moves data to all 64 bits of rbx
mov ebx, edx ; Moves data to bottom 32 bits of rbx, clears top 32
mov bx, dx ; Moves data to bottom 16 bits of rbx, doesn't touch the rest.
mov bl, dl ; Moves data to bottom 8 bits of rbx, doesn't touch the rest.

I used my assembly REPL scare to emulate some instructions so I can confirm it does what I expect it to.

python3 -m pip install scare
scare -a x64

In the REPL, you can type not rdx to get a bunch of 0xFFs in rdx. Then play with the different sized movs to see how the registers are affected.

Storing Data In The Header

I tried to use the header as much as possible to store static values, but it wasn’t always the best option. The header is fairly far from where most of the code is, so loading data from a relative address can result in code that is larger than what you’re trying to optimize. This was the case for the large Attributes value in the call to Create on the new file. I ended up just doing an assembly optimization to make that smaller instead. (see the code)

I reused the PE headers BaseOfCode as the new file’s name, which was conveniently a 4 byte field that is the exact size of a utf-16 “4”.

Assuming RAX Is 0 After Calls

When you call a UEFI function, it usually returns the EFI_STATUS. The status EFI_SUCCESS is 0, which means the call succeeded. There were a lot of times where I needed a 0 on the stack, so I used rax as if it had a reliable 0. This allowed me to just push rax (1 byte) instead of having the xor another register (3 bytes) and then push.

Reusing Values In Registers

While debugging, I kept noticing that some registers already contained values I needed after calls. I put breakpoints after each UEFI call, and looked at what values were already there. I used this to remove relatively large stack references and replace them with smaller register to register movs.

Finishing Touches

At this point, I had beat my goal of getting under 512 bytes. I was at 469 bytes, looking at the end of the code to see where I could optimize. I wondered what would happen if I just didn’t close the original file, or free the memory chunk I allocated. I found that it would still run, which meant I could pull both of those code blocks out. I was able to get it down to 440 bytes, before the final adjustment.

The last bit involved me rearranging the header a bit more and trying to fit more things in there. I was really annoyed by the Subsystem PE header field that needed to be 0x000A, because it separated a 4 byte free zone from a large 38 byte free zone.

I started to look for any instruction in the start of the code that could possibly reuse this by assembling to 0A 00 in some way. I remembered that my output string "4\n" has a 0x0A in it, followed by a null terminator (0x00).

53 push rbx
BA34000A00 mov edx,0xa0034
52 push rdx
89E2 mov edx,esp

There were only three bytes before 0A 00 in this instruction, so I could add one more byte to line it up perfectly. This worked because the instruction right before it was the one byte push rbx. This allowed me to move a bunch more code up into the header and get it down to a svelte 420 bytes.

At this point, I had a 420 byte self-replicating UEFI app, and I was satisfied.

The final code is in bggp4.uefi.asm

Future Optimizations

There are some optimizations that I wanted to apply, but I didn’t because I thought a 420 byte self replicating UEFI app was funny enough. If you’re up to a challenge, there are some relative offsets that could be adjusted, the stack could be used a bit better, and some code chunks could be reworked entirely.

Conclusion

UEFI is a vast ecosystem, with many drivers and applications running on and endless number of devices. There is a lot of code in EDK2. It can be hard to find a good starting point, but once you find an approach that works you for, it starts to make sense. I hope that this writeup inspires you to play with the firmwares you rely on every day!

Special thanks go to ic3q33n, who was also working on UEFI, and who had already solved some of the annoying programming problems that I had faced. I also want to thank rqu and ackmage for looking at gnu-efi with me and doing the first babysteps towards understanding UEFI. Also big thanks to Ulf Frisk and ilove2pwn_ for listening to me ramble about this.

Shoutouts: The BGGP Community, Haunted Computer Club (slop), tmp.0ut

If you want to get involved in BGGP next year, or just hang out and share weird files you made, you’re invited to join the Discord!

Check out the other entries to BGGP4 here.

Here are some mixes on youtube that got me thru the tough times

If you want to see some more PEs I’ve done weird stuff with check out

Modern PE Mangling - Smallest possible PE that pops calc
BGGP2021 - PE/JS/PDF polyglot that triggers a pop up of the number 2 in every way it’s parsed.
BGGP2022 - LEMONADE.BIN - DOSing radare2 and rizin with SOPHIE lyrics. LE (related to PE) driver parser bug.

Lastly, here’s another cool writeup involving patching a UEFI app to unlock xDCI on a ThinkPad to allow it to act like a USB device.

Bad Will b2b DJ XLAT - XMAS MEGA MIX

Sun, 24 Dec 2023 12:00:00 -0400

Link: https://www.youtube.com/watch?v=YYbZ3PkiKt8

easylkb: Easy Linux Kernel Builder

Mon, 20 Nov 2023 12:00:00 -0400

Collab with ackmage for tmp.0ut Volume 3.

Link: https://github.com/deepseagirl/easylkb

Paper: https://tmpout.sh/3/20.html

LKM Golf

Mon, 20 Nov 2023 12:00:00 -0400

tmp.0ut Article: https://tmpout.sh/3/19.html

tmp.0ut Volume 3

Mon, 20 Nov 2023 12:00:00 -0400

Link: https://tmpout.sh/3/

BGGP4 Results

Mon, 30 Oct 2023 12:00:00 -0400

Link: https://github.com/binarygolf/BGGP/tree/main/2023

tmp.0ut Article: https://tmpout.sh/3/25.html

How To Get A CVE Revoked

Mon, 03 Jul 2023 12:00:00 -0400

TODO: Convert thread to markdown

Original Thread: https://twitter.com/netspooky/status/1676000391866068994

CVEs that were revoked

CVE-2023-36262
CVE-2023-34585

Bad Will x DJ XLAT - Live 7/1/23

Sat, 01 Jul 2023 12:00:00 -0400

Link: https://www.youtube.com/watch?v=9vDrgXkdNB0

BGGP4 Announcement

Fri, 23 Jun 2023 12:00:00 -0400

https://binary.golf/

netspooky/pdiff2

Thu, 11 May 2023 12:00:00 -0400

I refactored the original pdiff and added some features that I had been using in other scripts.

Link: https://github.com/netspooky/pdiff2

Protocol RE Talk

Thu, 11 May 2023 12:00:00 -0400

Repo: https://github.com/netspooky/protocols/tree/main/protocol_re

Video: https://www.youtube.com/watch?v=73KJQRqz_Ec

acble - Apple Continuity Dissector

Fri, 28 Apr 2023 12:00:00 -0400

This is a dissector I wrote for the Apple Continuity protocol. It is a protocol that is transmitted via BLE within the manufacturing data field.

Link: https://github.com/netspooky/dissectors/blob/main/acble.lua

This dissector was featured on the Wireshark Contrib page!

Wireshark Tips n Tricks

Tue, 25 Apr 2023 12:00:00 -0400

https://gitlab.com/wireshark/wireshark/-/wikis/home The wireshark wiki

Additional oneliners here: https://github.com/netspooky/notes/blob/main/linux/oneliners.md#tshark-and-wireshark

Install wireshark from source

This is how you do it on Linux at least

git clone https://gitlab.com/wireshark/wireshark.git
cd wireshark
sudo ./tools/debian-setup.sh
mkdir build
cd build
cmake ..
make

To create a debug build, run cmake .. -DCMAKE_BUILD_TYPE=Debug instead of cmake ..

Now you can run with:

run/wireshark

Dark Mode

Bootleg QT dark mode on Wireshark >= 3.4.4 on Windows.

"C:\\Program Files\\Wireshark\\Wireshark.exe" -platform windows:darkmode=2

Useful Oneliners

Convert a packet to binary from the command line

tshark -x -r file.pcap -Y “frame.number==[packet#]” | xxd -r > file.bin

tshark find byte patterns

tshark -r some.pcap -Y 'data.data contains "\x12\x34"' -T fields -e data

wireshark get first 500 frames

frame.number < 501

wireshark get frames 450-500

frame.number < 501 and frame.number > 450

tshark just grab some fields (in this case grabbing bgblink.sync1_dv with a filter (here it’s "bgblink.command == 104 and ip.src == 127.0.0.1")

tshark -r gameboy.pcapng -Y "bgblink.command == 104 and ip.src == 127.0.0.1" -T fields -e bgblink.sync1_dv

tshark list all protocols in a given pcap

tshark -r capture.pcap -T fields -e frame.protocols | sort -u

Dissector Notes

https://mika-s.github.io/wireshark/lua/dissector/2017/11/04/creating-a-wireshark-dissector-in-lua-1.html

https://www.wireshark.org/docs/wsdg_html_chunked/wslua_tap_example.html

This is really useful for reference

11.6. Functions For New Protocols And Dissectors

Calling another dissector

https://www.wireshark.org/docs/wsdg_html_chunked/lua_module_Proto.html

The buf(offset):tvb() arg is important. offset is where in the previous buffer to start, and :tvb() casts it from userdata to a tvb

function proto_lap5.dissector(buf, pinfo, tree)
 if buf:len() > HEADER_LEN then
 -- create a new buffer containing only the XLES data,
 -- and pass it to the XLES dissector
 Dissector.get("xles"):call(buf(HEADER_LEN):tvb(), pinfo, tree)
 end
end

Dealing with UTF16 strings

this is actually a really sick way to do this…it goes by the null terminated string…

msg_f = ProtoField.string("mydissector.msg", "msg")
local getMsg = buffer(13) -- starting on byte 13
local msg = getMsg:le_ustring()
subtree:add(msg_f, getMsg, msg)

Capturing Bluetooth with Wireshark

Tested on Ubuntu 22.04

Enable Bluetooth in settings
Use the bluetooth-monitor interface
Use this filter to get advertising reports bthci_evt.le_meta_subevent == 0x02
Filter for one device btcommon.eir_ad.entry.device_name == "My Device"
Filter on MAC addrs bthci_evt.bd_addr == 55:55:55:55:55:55
See messages with manufacturer data btcommon.eir_ad.entry.data

steel injection jungle mix

Sun, 09 Apr 2023 12:00:00 -0400

Junglist massive

https://www.youtube.com/watch?v=cZ4x7UqBzBU

scare - Simple Configurable Assembly REPL and Emulator

Wed, 22 Mar 2023 12:00:00 -0400

This is the repo for scare: https://github.com/netspooky/scare

list_protos.sh

Thu, 02 Mar 2023 12:00:00 -0400

This is a simple script that can be used to list all of the protocols in a pcap using tshark.

#!/bin/bash
# List all the protocols detected in every pcap in a directory
c1="\033[38;5;228m"
c2="\033[38;5;122m"
for file in $1/*
do
 if [ "$file" != $0 ] ; then
 echo -e "$c1$file$c2"
 tshark -r "$file" -T fields -e frame.protocols | sort -u
 echo -e "\033[0m"
 fi
done

PS1 Prompts

Thu, 01 Dec 2022 12:00:00 -0400

This is my minimal PS1 for Bash

PS1="\\[\\e]0;\\u@\\h: \\w\\a\\]\\[\\e[38;5;123m\\]\\t\\[\\e[0m\\] \\[\\e[38;5;219m\\]\\w \\[\\e[0m\\]\\n▶ "

This is the more full PS1 with time and the directory.

PS1="\\[\\e[38;5;141m\\][\\[\\e[m\\]\\[\\e[38;5;219m\\]\\u\\[\\e[m\\]\\[\\e[38;5;226m\\]@\\[\\e[m\\]\\[\\e[38;5;86m\\]\\h\\[\\e[m\\]\\[\\e[38;5;141m\\]]-[\\[\\e[m\\]\\[\\e[38;5;159m\\]\\t\\[\\e[m\\]\\[\\e[38;5;141m\\]]-[\\[\\e[m\\]\\[\\e[38;5;226m\\]\\w\\[\\e[m\\]\\[\\e[38;5;141m\\]]\\[\\e[m\\]\\n\\\\$ \\[$(tput sgr0)\\]"

A ZSH prompt that looks similar to 2

PROMPT="%{$reset_color%}%{$fg[cyan]%}%D{%Y-%m-%d %I:%M:%S}%b%{$reset_color%} %{$fg[magenta]%}%~%{$reset_color%}
$fg[yellow]%}～%{$reset_color%}"

208 byte aarch64 ELF reverse shell

Wed, 16 Nov 2022 12:00:00 -0400

Link: https://github.com/netspooky/golfclub/blob/master/linux/aarch64/reverse_shell.md

ANSI Tips n' Tricks

Thu, 03 Nov 2022 12:00:00 -0400

Oneliner to clear the screen

echo -ne "\x1b\x5b\x48\x1b\x5b\x32\x4a\x1b\x5b\x33\x4a"

As base64

base64 -d <<< G1tIG1syShtbM0o=

This can also clear the screen

echo -ne "\x1bc"

This clears the screen and puts the cursor at the top left

base64 -d <<< G2N1

This clears and puts U’s til the end of the console line

base64 -d <<< G2NVG1s5OTli

TODO: Add notes from other sources

The PCAP File Format

Thu, 03 Nov 2022 12:00:00 -0400

References

https://wiki.wireshark.org/Development/LibpcapFileFormat PCAP Format
https://gitlab.com/wireshark/wireshark/-/wikis/Development/LibpcapFileFormat Newer docs on PCAP format
https://pcapng.github.io/pcapng/draft-tuexen-opsawg-pcapng.html PCAPNG Format

Basic layout of a PCAP file

A pcapng file. Basically everything is a “block” and there’s all this extra metadata

netspooky/hexcalc

Sat, 01 Oct 2022 12:00:00 -0400

https://github.com/netspooky/hexcalc

xx File Format

Sat, 24 Sep 2022 12:00:00 -0400

This is the repo for the xx file format: https://github.com/netspooky/xx

ELF RELRO

Wed, 21 Sep 2022 12:00:00 -0400

Question

How do you verify if a binary is compiled with RELRO? What do all the flags mean?

Answer

The docs and online discussions about this are super confusing. The whole point of doing RELRO is to set RTLD_NOW when the linker calls dlopen in some way. This tells the linker to resolve everything before execution (this actually happens before dlopen returns) and map the area the GOT is in as read-only.

This can be done in a few ways:

DT_BIND_NOW - A .dynamic section tag that explicitly sets this flag.
DF_BIND_NOW - A flag within the DT_FLAGS tag in the .dynamic section.
DF_1_NOW - A flag within DT_FLAGS_1, another .dynamic tag.
LD_BIND_NOW - This environment variable being a non-empty string will also trigger this.

Since these are linker instructions, there’s nothing stopping a linker from either not supporting something, or ignoring the tag all together.

The best way to verify is to run the binary on the target system and check the memory permissions for the area that the GOT is in. If it’s marked read only, then it was a success.

Trusting tools like readelf or checksec can lead to a false sense of security, as they can be easily manipulated via malicious crafted ELFs, or with linker/compiler/runtime bugs that can lead to weird outcomes.

BGGP3 Results

Tue, 20 Sep 2022 12:00:00 -0400

Link: https://github.com/binarygolf/BGGP/tree/main/2022

BGGP3: LEMONADE.BIN

Thu, 01 Sep 2022 12:00:00 -0400

TODO Convert to markdown

https://n0.lol/lemonade/

In late 2020, the radare2 suite of tools was forked into a new project called rizin. Being a fork, they share much of the same codebase and are working with similar design paradigms for parsing and handling a wide variety of binary formats.

Since it’s been nearly 2 years of development for Rizin, there is enough of a difference between them that certain types of files are parsed better by one than the other. Other things like what information is output have changed.

For this year’s BGGP, I took a look at r2 and rizin in search of possible candidates for the smallest crash. My goal then became to find something that crashed both r2 and rizin in the fewest number of bytes. Several versions of r2 and rizin have come out since the start of the challenge, so I will focus on behaviors from [radare2 5.7.0](https://github.com/radareorg/radare2/releases/tag/5.7.0 and rizin 0.3.4, and note where things changed.

SIDE NOTE I found this 32 byte crash in the Xamarin LZ4 decompression part of radare2, but this bug was already reported and fixed in the version of r2 that came out shortly after BGGP3 began. This didn’t crash rizin when I tested.

POC (base64): WEFMWkYAAAAABCIA8gNNWpAAAwAAAAQAAAD//wAAuAA=

Tweet: https://twitter.com/netspooky/status/1552047700413235201

In the summer of 2021 I found a simple DOS for radare2 (CVE-2021-3673) by replacing the first byte of an ELF file with an L. I discuss this bug in tmp.0ut 2:3 https://tmpout.sh/2/3.html

When running my fuzzer I noticed this same thing came up again. This time, it seemed to crash both radare2 and rizin in the same way.

The base64 encoded PoC is as follows. You can grab a copy of rizin or radare2 and follow along.

TEVNT05BREUsIExVSCBMVUgsIExFTU9OQURFICAKTEVNT05BREUsIExVSCBMVUgsIExFTU9OQURFICAKDQBIRVkgQkdHUDMK

Hold up, what the heck even is LE/LX?

Before we got to enjoy the Portable Executables we know and love today, the format had somewhat of a long lineage, dating back as far as disk operating systems themselves.

In the DOS days, there were COM files, which were just pure machine code. No header, no sections, no relocations, just code.

Since everything happened in Real Mode, there wasn’t as much of a need for things like privilege levels, and memory was flat and entirely available to a given process. You could usually only execute one program at a time, so the operating system had to make sure that it set up each process consistently, and in an area that was known to contain process data. A COM file could reliably execute within this known environment, and registers would be set to default values given by the operating system. This environment was known as the Program Segment Prefix, and each OS had it’s own defaults.

For more info on Program Segment Prefix: https://en.wikipedia.org/wiki/Program_Segment_Prefix
For more info on defaults per DOS version: https://www.fysnet.net/yourhelp.htm

As operating systems evolved, more control was required over the binaries that ran on the system. This was for both security, and general usability purposes. The MZ-DOS EXE format came out with MS-DOS 2.0, and was designed to support things like relocations, which gives the OS the ability to place code wherever it needs it to be. This is useful for things like linking, which gives way to DLLs that can extend the functionality of the program by using shared libraries that contain code reusable by any program on a given system.

NOTE: There were things such as DOS Extenders that gave the ability to enforce protections and use more advanced features while still running in real mode.

NOTE: PC DOS 1.0 (1981) had LINK.EXE and other .exe existed in MS-DOS 1.25 ( thanks Ange ! )

When Windows 1.0 came out, the “New Executable” format came with it. This was a 16 bit .exe that had even more configurability and allowed for more advanced linking and resource handling. To maintain backwards compatibility with DOS, it was placed after the MZ header with a small stub that would run in DOS mode if applicable. This is identical to how PE files are structured today.

Fun Fact! .FON and .FNT files are NE files.

File Example From https://www.chiark.greenend.org.uk/~sgtatham/fonts/

▶ yxd -f terminal.fon -s 0x170
00000000│4d5a 8b00 0100 0000│0400 1000 ffff 0000│MZ..............
00000010│0001 0000 0000 0000│4000 0000 0000 0000│........@.......
00000020│0000 0000 0000 0000│0000 0000 0000 0000│................
00000030│0000 0000 0000 0000│0000 0000 9000 0000│................
00000040│ba0e 000e 1fb4 09cd│21b8 014c cd21 5468│........!..L.!Th
00000050│6973 2069 7320 6e6f│7420 6120 7072 6f67│is is not a prog
00000060│7261 6d21 0d0a 466f│6e74 206c 6962 7261│ram!..Font libra
00000070│7279 2063 7265 6174│6564 2062 7920 6d6b│ry created by mk
00000080│7769 6e66 6f6e 742e│0d0a 2400 0000 0000│winfont...$.....
/-- NE header at offset 0x90
00000090│4e45 050a 8c00 0200│0000 0000 0883 0000│NE..............
000000A0│0000 0000 0000 0000│0000 0000 0000 0000│................
000000B0│2000 4000 4000 8000│8c00 8c00 1e01 0000│ .@.@...........
000000C0│0000 0400 0000 0208│0000 0000 0000 0003│................
000000D0│0400 0780 0100 0000│0000 1400 1000 500c│..............P.
000000E0│3800 0000 0000 0880│0200 0000 0000 2400│8.............$.
000000F0│0c02 301c 0180 0000│0000 3002 4d02 301c│..0.......0.M.0.
00000100│0280 0000 0000 0000│0746 4f4e 5444 4952│.........FONTDIR
00000110│0854 6572 6d69 6e61│6c00 0000 0000 1c46│.Terminal......F
00000120│4f4e 5452 4553 2031│3030 2c39 362c 3936│ONTRES 100,96,96
00000130│203a 2054 6572 6d69│6e61 6c00 0000 0000│ : Terminal.....
00000140│0200 0100 0003 bd20│0000 5075 626c 6963│....... ..Public
00000150│2064 6f6d 6169 6e20│666f 6e74 2e20 2053│ domain font. S
00000160│6861 7265 2061 6e64│2065 6e6a 6f79 2e00│hare and enjoy..

Introducing LE/LX

In the mid-80s, Microsoft had a partnership with IBM, who created OS/2 as a successor to their own PC DOS. As a result, the Linear Executable file format was created between them.

As both OSes evolved, the New Executable format was replaced in favor of a more versatile 32 bit format. There’s not that much information about that that I can find, but sometime around 1987 with the release of OS/2, Linear Executables became more common. LX with an MZ header was the default binary format for OS/2, and LE with a MZ header was used for user binaries on DOS and Windows 3.x. LE files were also used for VxD drivers for Windows 3.x until Windows 9.x.

The [PE format](https://docs.microsoft.com/en-us/archive/msdn-magazine/2002/february/inside-windows-win32-portable-executable-file-format-in-detail came out around 1993 with the release of Windows NT 3.1, and eventually became the standard. PE32+ came out with the first 64 bit Windows versions some time around 2005.

This is an example of an LX file, the date command for OS/2

From: http://cd.textfiles.com/hobbesos29411/BIN/DATE.EXE

▶ yxd -f DATE.EXE -s 0x100
00000000│4d5a 0000 0200 0000│0400 0000 ffff 0800│MZ..............
00000010│0002 0000 0000 0000│4000 0000 0000 0000│........@.......
00000020│0000 0000 0000 0000│0000 0000 0000 0000│................
00000030│0000 0000 0000 0000│0000 0000 8000 0000│................
00000040│0e1f ba0e 00b4 09cd│21b8 014c cd21 5468│........!..L.!Th
00000050│6973 2070 726f 6772│616d 2063 616e 6e6f│is program canno
00000060│7420 6265 2072 756e│2069 6e20 6120 444f│t be run in a DO
00000070│5320 7365 7373 696f│6e2e 0d0d 0a24 0000│S session....$..
00000080│4c58 0000 0000 0000│0200 0100 0100 0200│LX..............
00000090│1002 0000 0400 0000│0100 0000 0000 0000│................
000000A0│0500 0000 0080 0000│0010 0000 0900 0000│................
000000B0│0901 0000 0000 0000│a100 0000 0000 0000│................
000000C0│c400 0000 0500 0000│3c01 0000 0000 0000│........<.......
000000D0│0000 0000 0000 0000│5c01 0000 6401 0000│........\...d...
000000E0│0000 0000 0000 0000│6501 0000 7901 0000│........e...y...
000000F0│5b02 0000 0300 0000│6e02 0000 0000 0000│[.......n.......

This is an example of a VxD driver in the LE format. From: http://cd.textfiles.com/silvercollection/disc4/DRIVERS/19GXE.ARJ

▶ yxd -f VDDS3.386 -s 0x100
00000000│4d5a 3d00 4f00 0000│0400 0000 ffff 0000│MZ=.O...........
00000010│b800 0000 0000 0000│4000 0000 0000 0000│........@.......
00000020│0000 0000 0000 0000│0000 0000 0000 0000│................
00000030│0000 0000 0000 0000│0000 0000 8000 0000│................
00000040│0e1f ba0e 00b4 09cd│21b8 014c cd21 5468│........!..L.!Th
00000050│6973 2070 726f 6772│616d 2063 616e 6e6f│is program canno
00000060│7420 6265 2072 756e│2069 6e20 444f 5320│t be run in DOS
00000070│6d6f 6465 2e0d 0a24│0000 0000 0000 0000│mode...$........
00000080│4c45 0000 0000 0000│0200 0400 0000 0000│LE..............
00000090│2080 0000 0a00 0000│0300 0000 0000 0000│ ...............
000000A0│0000 0000 0000 0000│0010 0000 0b00 0000│................
000000B0│080a 0000 0000 0000│8600 0000 0000 0000│................
000000C0│c400 0000 0300 0000│0c01 0000 0000 0000│................
000000D0│0000 0000 0000 0000│3401 0000 3f01 0000│........4...?...
000000E0│0000 0000 0000 0000│4a01 0000 7601 0000│........J...v...
000000F0│500b 0000 0000 0000│510b 0000 0000 0000│P.......Q.......

This is also an LE file! http://cd.textfiles.com/doomcompanion/DOOM/DOOM.EXE

Whew, who knew binaries would be so complicated?? Here’s a little chart showing the evolution of binary formats from COM to PE32+. Click on the names for more info. (You might have to zoom in!)

%%{init: {'theme':'dark'}}%%
flowchart TB
classDef o fill:#123
COM["COM (1974)
Originally for CP/M and
DEC VAX 16-bit, real-mode "]:::o
MZ-DOS["MZ-DOS (1983)
For DOS 2.0. Has 'MZ' 
header, metadata, relocations"]:::o
AOFF["AOFF (1977)
Absolute Object File Format
Intel internal format."]:::o
OMF["OMF (1981)
'Relocatable Object Module
Format' By Intel, AKA .obj "]:::o
CMD["CMD (1981)
For CP/M and other 
DOS-like OS "]:::o
NE["NE (1985)
'New Executable'. For 
Windows 1.0 and OS/2 "]:::o
LX["LX (1987)
'Linear Executable' 
OS/2 2.0, 32 bit"]:::o
LE["LE (1987)
'Linear Executable' 
Mixed 16/32 bit, 
Windows VxD Drivers 
from 3.x-9.x, OS/2, 
DOS extenders, user 
Windows binaries."]:::o
PE["PE (1993)
'Portable Executable'
32 bit, for Windows 
NT 3.1 and later, and 
many other platforms 
like UEFI :) "]:::o
PE32["PE32+ (2005)
64bit x86 PEs. 
NOTE: 64 bit 
architectures were 
supported with PE, 
but the format wasn't 
updated until the 
x86_64 version."]:::o
AOUT["a.out (1971)
'Assembler Output' 
First format for 
Unix, PDP-7 and 
PDP-11. Also used 
in early Linux."]:::o
COFF["COFF (1983)
'Common Object File Format'"]:::o
ECOFF["ECOFF (1984)
'Extended COFF' 
Designed for MIPS 
on DEC Ultrix, 
Tru64, SGI Irix, 
Linux/MIPS, and 
Net Yaroze"]:::o
XCOFF["XCOFF (1986)
'eXtended COFF' 
For AIX from IBM "]:::o
ELF["ELF (1988)
Replaced COFF
in Unix SVR4"]:::o
COM --> CMD
COM --> MZ-DOS
COM --> OMF
AOFF --> OMF
MZ-DOS --> NE
NE --> LE
NE --> LX
LE --> PE
PE --> PE32
AOUT --> COFF
COFF --> ECOFF
COFF --> XCOFF
COFF ---> ELF
COFF ---> PE

Understanding LE/LX Binaries

Now that we know some of the history, let’s get into the format.

It’s pretty typical of these early binary formats, with simple set up and pointers to different sections, as well as sizes and number of elements.

This layout can be thought of similarly to the PE format, with a pointer to it from inside the DOS header at offset 0x3C.

 +-----+-----+-----+-----+-----+-----+-----+-----+
00h | "L" "X" |B-ORD|W-ORD| FORMAT LEVEL |
+-----+-----+-----+-----+-----+-----+-----+-----+
08h | CPU TYPE | OS TYPE | MODULE VERSION |
+-----+-----+-----+-----+-----+-----+-----+-----+
10h | MODULE FLAGS | MODULE # OF PAGES |
+-----+-----+-----+-----+-----+-----+-----+-----+
18h | EIP OBJECT # | EIP |
+-----+-----+-----+-----+-----+-----+-----+-----+
20h | ESP OBJECT # | ESP |
+-----+-----+-----+-----+-----+-----+-----+-----+
28h | PAGE SIZE | PAGE OFFSET SHIFT |
+-----+-----+-----+-----+-----+-----+-----+-----+
30h | FIXUP SECTION SIZE | FIXUP SECTION CHECKSUM|
+-----+-----+-----+-----+-----+-----+-----+-----+
38h | LOADER SECTION SIZE |LOADER SECTION CHECKSUM|
+-----+-----+-----+-----+-----+-----+-----+-----+
40h | OBJECT TABLE OFF | # OBJECTS IN MODULE |
+-----+-----+-----+-----+-----+-----+-----+-----+
48h | OBJECT PAGE TABLE OFF | OBJECT ITER PAGES OFF |
+-----+-----+-----+-----+-----+-----+-----+-----+
50h | RESOURCE TABLE OFFSET |#RESOURCE TABLE ENTRIES|
+-----+-----+-----+-----+-----+-----+-----+-----+
58h | RESIDENT NAME TBL OFF | ENTRY TABLE OFFSET |
+-----+-----+-----+-----+-----+-----+-----+-----+
60h | MODULE DIRECTIVES OFF | # MODULE DIRECTIVES |
+-----+-----+-----+-----+-----+-----+-----+-----+
68h | FIXUP PAGE TABLE OFF |FIXUP RECORD TABLE OFF |
+-----+-----+-----+-----+-----+-----+-----+-----+
70h | IMPORT MODULE TBL OFF | # IMPORT MOD ENTRIES |
+-----+-----+-----+-----+-----+-----+-----+-----+
78h | IMPORT PROC TBL OFF | PER-PAGE CHECKSUM OFF |
+-----+-----+-----+-----+-----+-----+-----+-----+
80h | DATA PAGES OFFSET | #PRELOAD PAGES |
+-----+-----+-----+-----+-----+-----+-----+-----+
88h | NON-RES NAME TBL OFF | NON-RES NAME TBL LEN |
+-----+-----+-----+-----+-----+-----+-----+-----+
90h | NON-RES NAME TBL CKSM | AUTO DS OBJECT # |
+-----+-----+-----+-----+-----+-----+-----+-----+
98h | DEBUG INFO OFF | DEBUG INFO LEN |
+-----+-----+-----+-----+-----+-----+-----+-----+
A0h | #INSTANCE PRELOAD | #INSTANCE DEMAND |
+-----+-----+-----+-----+-----+-----+-----+-----+
A8h | HEAPSIZE |
+-----+-----+-----+-----+

Within here is the Object Table, which points to a number of objects the LE needs to have set up in order to run.

 +-----+-----+-----+-----+-----+-----+-----+-----+
00h | VIRTUAL SIZE | RELOC BASE ADDR |
+-----+-----+-----+-----+-----+-----+-----+-----+
08h | OBJECT FLAGS | PAGE TABLE INDEX |
+-----+-----+-----+-----+-----+-----+-----+-----+
10h | # PAGE TABLE ENTRIES | RESERVED |
+-----+-----+-----+-----+-----+-----+-----+-----+

The Object Page Table is the element of the Object Table which directly relate to objects to load and their associated sizes and flags.

 63 32 31 16 15 0
+-----+-----+-----+-----+-----+-----+-----+-----+
00h | PAGE DATA OFFSET | DATA SIZE | FLAGS |
+-----+-----+-----+-----+-----+-----+-----+-----+

These structures will be handy to know later on.

How LE files are parsed

So we know that LE files follow the typical parsing mechanism required for PEs and other similar binaries. We also know that they have relative offsets and are pointed to by the MZ header. This means that a good parser will be able to seek to this offset and parse LE independently of the header that came before it.

When a binary is loaded into rizin or radare 2, it is read by the program and processed as close to the spec as possible.

This is the path it takes in Rizin (per 0.3.4 source but the logic is roughly the same throughout) once the initial loading of the file and other environment checks are done.

rz_bin_open_buf

This opens the buffer and does some basic checks
Calls rz_bin_file_new_from_buffer

rz_bin_file_new_from_buffer

Calls get_plugin_from_buffer
- This check tries to figure out what plugin to use to parse the file, there are two types:
  1. rz_bin_get_binplugin_by_name
  - This check doesn’t pass in the PoC file, but if the plugin is already known (like if this is a sub-file in a container format), then this will grab it.
  1. rz_bin_get_binplugin_by_buffer
  - This goes through the list of available plugins and runs the check_buffer callback for each heuristic.
  - The LE format’s check_buffer function is called
  - To pass the LE check_buffer, only a few things have to be set:
    - Length must be greater than 2
    - There has to be some value at +0x3C (This is the pointer to the LE header)
    - This value (idx) + 26 must not be greater than the size of the file
    - The LE or LX magic value must be at the start of the buffer, or if MZ is at the start, then the idx is used to find the LE/LX header
If the buffer doesn’t match any of the plugin’s heuristics, then the dummy plugin is selected
After plugin is found, calls rz_bin_object_new

rz_bin_object_new

Creates a new RzBin object for parsing
Calls rz_bin_object_set_items

rz_bin_object_set_items

Each plugin has a set of callbacks that are used for parsing. Here, the callbacks are checked and ran on the buffer.
Eventually, it gets to the check for p->maps
.maps callback is rz_bin_maps_of_file_sections

rz_bin_maps_of_file_sections

This is a generic function that eventually calls the LE callback .sections
The .sections callback is a wrapper for rz_bin_le_get_sections

rz_bin_le_get_sections

This is the function that goes wild
It’s because at this point it trusts the input from the previous functions.

Let’s debug and see what happens!!

Debugging the parser

Our buffer is as follows:

00000000│4c45 4d4f 4e41 4445│2c20 4c55 4820 4c55│LEMONADE, LUH LU
00000010│482c 204c 454d 4f4e│4144 4520 200a 4c45│H, LEMONADE .LE
00000020│4d4f 4e41 4445 2c20│4c55 4820 4c55 482c│MONADE, LUH LUH,
00000030│204c 454d 4f4e 4144│4520 200a 0d00 4845│ LEMONADE ...HE
00000040│5920 4247 4750 330a│ │Y BGGP3.

Get set up with the debugger:

$ gdb --args /home/user/rizin/rizin-0.3.4/build/binrz/rz-bin/rz-bin -I lemonade.bin
...
gef➤ start
gef➤ break rz_bin_le_get_sections
gef➤ continue
gef➤ break 344

At this point, we are just after the check that the section was properly allocated. LEt’s examine the state of our object.

This is the header that rizin now has internally.

gef➤ p *h
$1 = {
magic = "LE",
border = 0x4d,
worder = 0x4f,
level = 0x4544414e,
cpu = 0x202c,
os = 0x554c,
ver = 0x554c2048,
mflags = 0x4c202c48,
mpages = 0x4e4f4d45,
startobj = 0x20454441,
eip = 0x454c0a20,
stackobj = 0x414e4f4d,
esp = 0x202c4544,
pagesize = 0x2048554c,
pageshift = 0x2c48554c,
fixupsize = 0x4d454c20,
fixupsum = 0x44414e4f,
ldrsize = 0xa202045,
ldrsum = 0x4548000d,
objtab = 0x47422059,
objcnt = 0xa335047,
objmap = 0x0,
itermap = 0x0,
rsrctab = 0x0,
rsrccnt = 0x0,
restab = 0x0,
enttab = 0x0,
dirtab = 0x0,
dircnt = 0x0,
fpagetab = 0x0,
frectab = 0x0,
impmod = 0x0,
impmodcnt = 0x0,
impproc = 0x0,
pagesum = 0x0,
datapage = 0x0,
preload = 0x0,
nrestab = 0x0,
cbnrestab = 0x0,
nressum = 0x0,
autodata = 0x0,
debuginfo = 0x0,
debuglen = 0x0,
instpreload = 0x0,
instdemand = 0x0,
heapsize = 0x0,
stacksize = 0x0
}

The very last member h->objcnt has 0xa335047 entries. This coincides with the “GP3\n” at the end of the PoC file.

Rizin will now try to allocate 0xa335047 new objects to copy data from the file into memory. This is of course, not ideal.

I originally found a bug in the same part of the code, but using the Object Page Table entries to cause a large number of object allocations rivaling that of modern applications such as Slack. This bug was further into the loop and required a larger file size, so I experimented with using a huge value in the objcnt header field to reduce the file size. This resulted in triggering the bug earlier in the loop, and the program didn’t reject it based on it’s size being smaller than the allocated header object.

Sadly this won’t result in code execution, but it does have the same effect on other versions of Radare2 and Rizin, which achieves my initial goal.

The script I used to generate and test the PoC file is as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


import struct
import sys
import hashlib

def writeBin(b,h):
 outfile = h + ".bin"
 f = open(outfile,'wb')
 f.write(b)
 f.close()
 print(outfile)

b = b""
b += b"LE" # 00h -- Signature
b += b"MO" # 02h -- B-ORD/W-ORD
b += b"NADE" # 04h -- Format Level
b += b", " # 08h -- CPU Type
b += b"LU" # 0Ah -- OS Type
b += b"H LU" # 0Ch -- Module Version
b += b"H, L" # 10h -- Module Flags
b += b"EMON" # 14h -- Module # of pages
b += b"ADE " # 18h -- EIP Object
b += b" \nLE" # 1Ch -- EIP
b += b"MONA" # 20h -- ESP Object #
b += b"DE, " # 24h -- ESP
b += b"LUH " # 28h -- Page Size
b += b"LUH," # 2Ch -- Page Offset Shift
b += b" LEM" # 30h -- Fixup Section Size
b += b"ONAD" # 34h -- Fixup Section Checksum
b += b"E \n" # 38h -- Loader Section Size
b += b"\r\x00HE" # 3Ch -- Loader Section Checksum
b += b"Y BG" # 40h --Object Table Offset
b += b"GP3\n" # 44h --Object Count

m = hashlib.sha256()
m.update(b)
shorthash = m.digest().hex()[0:8]
writeBin(b,shorthash)

Scoring

File Size: 72
4096 - 72 = 4024
+ 1024 = 5048 (Additional points for writeup)

Final Score: 5048

This is currently being patched: https://github.com/rizinorg/rizin/issues/2993

End

My BGGP3 entry was a lot different than what I originally planned. I found two other really cool things that I want to explore more in depth, so this was my backup. I am really happy to see how many people did their own projects this year. The goal was to challenge you to explore things that you might not normally look into, and give people a reason to go deep with things that most people would just consider an annoyance.

Shoutout: gren, xcellerator, hermit, dnz, Ange Albertini and qkumba for the ancient wisdom, tmp.0ut, and everyone who did BGGP

tmpout/elfs

Thu, 25 Aug 2022 12:00:00 -0400

Repo: https://github.com/tmpout/elfs

yxd - Yuu's heX Dumper

Tue, 23 Aug 2022 12:00:00 -0400

Repo: https://github.com/netspooky/yxd

Updates:

Added an API so you can use yxd from Python scripts

Using Vim as a hex editor

Fri, 29 Jul 2022 12:00:00 -0400

Vim Hex Editor Tutorial

Open file, type :%!xxd to enter hex mode

Optional - Turn on hex syntax highlighting with :set ft=xxd

Make changes to the hex bytes

Leave hex mode with :%!xxd -r

Exit vim with :call libcallnr("libc.so.6","exit",0)

TODO: Download pictures instead of linking

Python3.7+ Multi-arch .pyc dropper

Mon, 25 Jul 2022 12:00:00 -0400

https://forum.spacehey.com/topic?id=89320

BGGP3 Announcement

Fri, 17 Jun 2022 12:00:00 -0400

https://tmpout.sh/bggp/3/

kompaktblk Figlet Font

Wed, 25 May 2022 12:00:00 -0400

https://github.com/netspooky/uJunk/blob/main/art/asciifonts/kompaktblk.flf

uBLK Figlet Font

Wed, 25 May 2022 12:00:00 -0400

https://github.com/netspooky/uJunk/blob/main/art/asciifonts/ublk.flf

Wireshark is a lolbin

Thu, 19 May 2022 12:00:00 -0400

https://forum.spacehey.com/topic?id=84164

RE Tips: Common String Representations

Mon, 09 May 2022 12:00:00 -0400

RE Tips: Common String Representations

Originally posted 2022-05-09

Strings are a good way of determining the layout of an unknown binary blob. If you can figure out how the strings are stored, you can use it as an anchor to map out other structures around them.

Image Description:

A text file explaining the common string representations.

Length First, where the length of the string is stored before the string.
Null Terminated, where each string ends in a null byte.
Fixed Width, where each field is a fixed size. These can also have padding if they need to be aligned to a certain amount of bytes, AKA they must be divisible by a certain number.

Packets Remystified: Broadcast Brujería

Fri, 15 Apr 2022 12:00:00 -0400

https://github.com/netspooky/protocols/tree/main/broadcast_brujeria

84 byte aarch64 ELF

Tue, 22 Feb 2022 12:00:00 -0400

tmp.0ut Article: https://tmpout.sh/2/14.html

BGGP2 Wrap Up

Tue, 22 Feb 2022 12:00:00 -0400

https://tmpout.sh/2/13.html

Elf Binary Mangling Pt. 4: Limit Break

Tue, 22 Feb 2022 12:00:00 -0400

This is the version I did for tmp.0ut Volume 2.

For the full series see /ebm/

https://tmpout.sh/2/11.html

Some ELF Parser Bugs

Tue, 22 Feb 2022 12:00:00 -0400

tmp.0ut Article: https://tmpout.sh/2/3.html

An ELF Palindrome for AMD64

Tue, 15 Feb 2022 12:00:00 -0400

https://www.alchemistowl.org/pocorgtfo/pocorgtfo21.pdf

netspooky/importsort

Sun, 10 Oct 2021 12:00:00 -0400

https://github.com/netspooky/importsort

BGB Emulator Link Cable Protocol Dissector

Sat, 09 Oct 2021 12:00:00 -0400

https://github.com/netspooky/dissectors/blob/main/bgblink.lua

koholint Figlet Font

Wed, 06 Oct 2021 12:00:00 -0400

https://github.com/netspooky/uJunk/blob/main/art/asciifonts/koholint.flf

six-fo Figlet Font

Wed, 06 Oct 2021 12:00:00 -0400

https://github.com/netspooky/uJunk/blob/main/art/asciifonts/six-fo.flf

BGGP2 Results

Fri, 24 Sep 2021 12:00:00 -0400

Link: https://github.com/binarygolf/BGGP/tree/main/2021

ns.bggp2021.asm

Thu, 16 Sep 2021 12:00:00 -0400

Source Code: https://github.com/netspooky/golfclub/blob/master/windows/ns.bggp2021.asm

RE Tips: Timestamps

Fri, 10 Sep 2021 12:00:00 -0400

RE Tips: Timestamps

Originally Posted: 2021-09-10

If you’re analyzing an unknown protocol or binary format, know your time stamps!

Let’s say you know the pcap (or file) was created in the last 24 hours.

Right now it’s 1631293496 in Unix time.

In hex: 613B9038
In ASCII: “a;\x908”

https://unixtimestamp.com

If we go back exactly 24 hrs, the time is 1631221496.

In hex: 613A76F8
In ASCII: “a:v\xF8”

Now you can look in the hex dump for “a” and either “:” or “;” beside it. If you don’t know the endianness, this can be a good way to figure that out. Can also align fields around it.

Not all protocols or file formats will have timestamps included, but it’s common enough that it’s a good thing to search for, especially if there are few strings.

There are lots of other timestamp formats that are helpful to know. Familiarize yourself for gr8 victory.

Example: Given this, if found a timestamp, you can probably assume that there’s some of boundary at 0xC1. It’s lil endian, and now you can trace other values.

Is 0xA5 a virtual address?
Is 0xB9 a boolean?
Is 0xCB a bit pattern?

These are the questions you wanna ask.

PGStats Dissector

Thu, 02 Sep 2021 12:00:00 -0400

https://github.com/netspooky/dissectors/blob/main/pgstats.lua

Elf Binary Mangling Pt. 4: Limit Break

Wed, 07 Jul 2021 12:00:00 -0400

https://tmpout.sh/2/11.html

TODO Convert to markdown

x86 Shellcode Tricks

Fri, 02 Jul 2021 12:00:00 -0400

Shellcode Tricks

I originally wrote this to send to a friend who had some questions about crafting x86 payloads. It is by no means exhaustive.

Solid reference https://www.felixcloutier.com/x86/index.html
Hex Calculator https://n0.lol/hc/
WinREPL for x86 Assembly https://github.com/zerosum0x0/WinREPL/releases/
Online Assembler https://defuse.ca/online-x86-assembler.htm

Avoiding bad chars

Shifting left to avoid bad chars

Let’s say you want to put 0x400 in EAX

Doing it like this yields null bytes

b8 00 04 00 00 mov eax, 0x400
66 b8 00 04 mov ax, 0x400

So you could do it like:

xor eax, eax
inc eax
shl eax, 0x0A

But this yields a potential bad char: 0xA

Shift past the bounds of EAX and end up on the same spot by adding 32 (0x20) to your shift parameter. This works because we know that EAX is 32 bits, so adding 32 will land you in the same location.

If you have a 0x1 in EAX

xor eax, eax
inc eax

Any of these will give you the 0x400 you are looking for

shl eax, 0x2a
shl eax, 0x4a
shl eax, 0x6a
etc..

SHR shifts things out of the register, so it won’t work for this
There’s other ways to do this with ROR/ROL
Shift Reference: https://www.felixcloutier.com/x86/sal:sar:shl:shr
Similar effects can be done with multiplication instructions if needed

Chaining SHL

You can also chain shifts and increment operations together too, this can be used to build a complex values.

Let’s say we want 0x0A0D in EAX, to use shifts, we need to look at these values in binary

0x0A 0x0D
00001010 00001101

We can then take the distance between the 1’s and calculate how many shifts we need to do

 0x0A────0x0D────
0000101000001101
2 ─────┴─┘ ││ │
6 ───────┴─────┘│ │
1 ─────────────┴┘ │
2 ──────────────┴─┘

Apply this by repeatedly incrementing and shifting left:

;-------------; OPCODE ; EAX Value --------------------------; Description ------
xor eax, eax ; 31c0 ; 00000000 00000000 00000000 00000000 ; Clear EAX
inc eax ; 40 ; 00000000 00000000 00000000 00000001 ; Increment
shl eax, 0x2 ; c1e002 ; 00000000 00000000 00000000 00000100 ; Shifting by 2 bits
inc eax ; 40 ; 00000000 00000000 00000000 00000101 ; Increment
shl eax, 0x6 ; c1e006 ; 00000000 00000000 00000001 01000000 ; Shifting by 6 bits
inc eax ; 40 ; 00000000 00000000 00000001 01000001 ; Increment
shl eax, 0x1 ; d1e0 ; 00000000 00000000 00000010 10000010 ; Shifting by 1 bit
inc eax ; 40 ; 00000000 00000000 00000010 10000011 ; Increment
shl eax, 0x2 ; c1e002 ; 00000000 00000000 00001010 00001100 ; Shifting by 2 bits
inc eax ; 40 ; 00000000 00000000 00001010 00001101 ; Increment

We can use the previous trick of adding 32 (0x20) to our shift value to avoid bad chars

;-------------; OPCODE ; EAX Value --------------------------; Description ------
xor eax, eax ; 31c0 ; 00000000 00000000 00000000 00000000 ; Clear EAX
inc eax ; 40 ; 00000000 00000000 00000000 00000001 ; Increment
shl eax, 0x42 ; c1e042 ; 00000000 00000000 00000000 00000100 ; Shifting by 2 bits
inc eax ; 40 ; 00000000 00000000 00000000 00000101 ; Increment
shl eax, 0x26 ; c1e026 ; 00000000 00000000 00000001 01000000 ; Shifting by 6 bits
inc eax ; 40 ; 00000000 00000000 00000001 01000001 ; Increment
shl eax, 0x41 ; c1e041 ; 00000000 00000000 00000010 10000010 ; Shifting by 1 bit
inc eax ; 40 ; 00000000 00000000 00000010 10000011 ; Increment
shl eax, 0x62 ; c1e062 ; 00000000 00000000 00001010 00001100 ; Shifting by 2 bits
inc eax ; 40 ; 00000000 00000000 00001010 00001101 ; Increment

Add and Sub

Let’s say you want 0x0A0D in EAX, but these are both bad chars, use the constant 0x1111 to armor it, then subtract the same value to restore.

mov ax, 0x1B1E
sub ax, 0x1111

Logical Operations

You can avoid bad chars by using bitmasks and logical instructions too

In all of the examples, we want to put 0x0A0D in EAX

XOR (A good online XOR calculator http://xor.pw/)

mov ax, 0x3037
xor ax, 0x3a3a

NOT

mov ax, 0xf5f2
not ax

00001000 00001000 [0x0808]
00000010 00000101 [0x0205]
-------------------------- ORing keeps 1 if either or both bits is set to 1
00001010 00001101 [0x0A0D]
mov ax, 0x0808
or ax, 0x0205

AND

01011010 01001111 [0x5A4F]
00101011 00111101 [0x2B3D]
-------------------------- ANDing only keeps 1 if both bits are set to 1
00001010 00001101 [0x0A0D]
mov ax, 0x5A4F
and ax, 0x2B3D

Optimizing for Size

Clearing Registers

cdq - Sign extends EAX to EDX:EAX, so xor eax, eax and then cdq will make EDX and EAX both 0 in only 3 bytes.

mul - With only one operand specified, mul assumes that the destination is EAX, so it stores the result in EDX:EAX.

xor ecx, ecx ; 0
mul ecx ; Effectively edx_eax = ecx * eax, now all equal 0

Filling Multiple registers

pusha
popa

netspooky/kimagure

Tue, 22 Jun 2021 12:00:00 -0400

https://github.com/netspooky/kimagure

BGGP2 Announcement

Fri, 18 Jun 2021 12:00:00 -0400

https://n0.lol/bggp/2021/

TODO: Link to binary.golf site with the proper pages.

sendframe.py

Wed, 09 Jun 2021 12:00:00 -0400

Code:

# 2021-06-09
# Use this to send raw packets with python
# $ printf "somebytes" | sudo python3 sendframe.py
# https://twitter.com/netspooky/status/1402647501090459653

from socket import *
import sys

interface = "ens33" # Change

data = sys.stdin.buffer.read()
s = socket(AF_PACKET, SOCK_RAW)
s.bind((interface, 0))
s.send(data)

Original: https://twitter.com/netspooky/status/1402647501090459653

In-Memory Kernel Module Loading

Tue, 20 Apr 2021 12:00:00 -0400

tmp.0ut Article: https://tmpout.sh/1/9.html

Encoding Mutations: A Base64 Case Study

Fri, 12 Feb 2021 12:00:00 -0400

This writeup will be a quick rundown of how Base64 works, and how ambiguity in the decoding process can be used to an attacker or defender’s advantage.

This writeup can apply to most of the popular encoding schemes (base32, ASCII85 and others), but the focus is on base64.

Base64 Overview

Here is a base64 chart based on the most popular spec.

┌────┬────────┬───┐ ┌────┬────────┬───┐ ┌────┬────────┬───┐ ┌────┬────────┬───┐
│ ## │ Binary │Chr│ │ ## │ Binary │Chr│ │ ## │ Binary │Chr│ │ ## │ Binary │Chr│
├────┼────────┼───┤ ├────┼────────┼───┤ ├────┼────────┼───┤ ├────┼────────┼───┤
│ 00 │ 000000 │ A │ │ 16 │ 010000 │ Q │ │ 32 │ 100000 │ g │ │ 48 │ 110000 │ w │
│ 01 │ 000001 │ B │ │ 17 │ 010001 │ R │ │ 33 │ 100001 │ h │ │ 49 │ 110001 │ x │
│ 02 │ 000010 │ C │ │ 18 │ 010010 │ S │ │ 34 │ 100010 │ i │ │ 50 │ 110010 │ y │
│ 03 │ 000011 │ D │ │ 19 │ 010011 │ T │ │ 35 │ 100011 │ j │ │ 51 │ 110011 │ z │
│ 04 │ 000100 │ E │ │ 20 │ 010100 │ U │ │ 36 │ 100100 │ k │ │ 52 │ 110100 │ 0 │
│ 05 │ 000101 │ F │ │ 21 │ 010101 │ V │ │ 37 │ 100101 │ l │ │ 53 │ 110101 │ 1 │
│ 06 │ 000110 │ G │ │ 22 │ 010110 │ W │ │ 38 │ 100110 │ m │ │ 54 │ 110110 │ 2 │
│ 07 │ 000111 │ H │ │ 23 │ 010111 │ X │ │ 39 │ 100111 │ n │ │ 55 │ 110111 │ 3 │
│ 08 │ 001000 │ I │ │ 24 │ 011000 │ Y │ │ 40 │ 101000 │ o │ │ 56 │ 111000 │ 4 │
│ 09 │ 001001 │ J │ │ 25 │ 011001 │ Z │ │ 41 │ 101001 │ p │ │ 57 │ 111001 │ 5 │
│ 10 │ 001010 │ K │ │ 26 │ 011010 │ a │ │ 42 │ 101010 │ q │ │ 58 │ 111010 │ 6 │
│ 11 │ 001011 │ L │ │ 27 │ 011011 │ b │ │ 43 │ 101011 │ r │ │ 59 │ 111011 │ 7 │
│ 12 │ 001100 │ M │ │ 28 │ 011100 │ c │ │ 44 │ 101100 │ s │ │ 60 │ 111100 │ 8 │
│ 13 │ 001101 │ N │ │ 29 │ 011101 │ d │ │ 45 │ 101101 │ t │ │ 61 │ 111101 │ 9 │
│ 14 │ 001110 │ O │ │ 30 │ 011110 │ e │ │ 46 │ 101110 │ u │ │ 62 │ 111110 │ + │
│ 15 │ 001111 │ P │ │ 31 │ 011111 │ f │ │ 47 │ 101111 │ v │ │ 63 │ 111111 │ / │
└────┴────────┴───┘ └────┴────────┴───┘ └────┴────────┴───┘ └────┴────────┴───┘

There are only a few rules you need to know to understand base64:

When data is encoded, it is split up into 6 bit chunks.
Each chunk is mapped to one of 64 ASCII characters (Chr), shown above.
Four 6 bit chunks make up a block, representing 3 bytes of data (24 bits).
If there aren’t enough bits in the data being encoded to fit into a 6 bit chunk, the remaining bits are set to 0.
If there aren’t enough 6 bit chunks to make up a 24 bit block, a special padding character is used as a placeholder for remaining chunks.

The padding character is ‘=’. You will often see this at the end of a base64 encoded string, signifying that the data isn’t aligned to (AKA a multiple of) 24 bits. Padding characters have no value, and can be thought of like a NULL.

To illustrate the encoding process, let’s look at how the string ’netspooky’ would be encoded. We can use the Linux base64 program to generate our encoded string. Note that the -n flag is used to prevent echo from printing a newline, which would add a byte to the end of the string!

$ echo -n "netspooky" │ base64
bmV0c3Bvb2t5

The base64 program followed the above rules to generate this string. We can understand how these rules were followed if we consider this from a binary perspective.

First, let’s divide the string into 3 chunks. It’s divisible by 3 and therefore needs no padding.

net spo oky
bmV0 c3Bv b2t5

Here is the first chunk ’net’, encoded as ‘bmV0’

 ┌─────────┬─────────┬─────────┐
data: │n │e │t │
binary: │011011│10│0110│0101│01│110100│
base64: │b │m │V │0 │
└──────┴───────┴───────┴──────┘

The second chunk ‘spo’, encoded as ‘c3Bv’

 ┌─────────┬─────────┬─────────┐
data: │s │p │o │
binary: │011100│11│0111│0000│01│101111│
base64: │c │3 │B │v │
└──────┴───────┴───────┴──────┘

The third chunk ‘oky’, encoded as ‘b2t5’

 ┌─────────┬─────────┬─────────┐
data: │o │k │y │
binary: │011011│11│0110│1011│01│111001│
base64: │b │2 │t │5 │
└──────┴───────┴───────┴──────┘

Since our string was divisible by 3, it fit perfectly, and requires no padding.

Now, what if we were encoding the word ’nets’?

$ echo -n "nets" │ base64
bmV0cw==

We already know how ’net’ is encoded (‘bmV0’), but what happens when our string isn’t divisible by 3? We use the same process, except now we add padding.

The first char representing the first 6 bit chunk is ‘c’, the same as in the encoding of ‘spo’. This makes sense because the first byte ’s’ hasn’t changed.

Now we have these two extra bits. If we remember rule 4 from above, base64 will take any bits not defined within a 6 bit chunk, and turn them into 0s. If they are all undefined, then the null value padding character = is used to represent that they aren’t needed.

Example:

 ┌─────────┬──────────────────┐
data: │s │ │
binary: │011100│11│----│------│------│
base64: │c │w │= │= │
└──────┴───────┴──────┴──────┘
\
w maps to 110000, so the 4 undefined bits convert to 0's

Implementation Differences

Nearly every base64 implementation will produce the same encoded string output. Not every implementation will decode the same way, which is where things get interesting. Some less strict implementations of base64 will decode base64 strings with incomplete padding just fine. For example, Javascript:

console.log(atob("bmV0"));
net
console.log(atob("cw"));
s

If we use python in the same way:

$ python3 -c "import base64;print(base64.b64decode('bmV0'.encode('ascii')))"
b'net'
$ python3 -c "import base64;print(base64.b64decode('cw'.encode('ascii')))"
binascii.Error: Incorrect padding

Trying to decode ‘cw’, you get an “Incorrect padding” error.

The Linux base64 binary gets through the decoding of the ’s’ string, but it reports “invalid input” immediately after:

$ base64 -d <<< "cw"
sbase64: invalid input

There are far too many base64 implementations to discuss here, including some bespoke instances within very important systems.

Obfuscation

Now we know that there are differences in how base64 data is interpreted by different tools and libraries, we can explore some ways to use this to our advantage.

Some implementations use =’s effectively as a delimiter of base64 data. In these cases, two chunks of base64 encoded data, one after another, may or may not be written to a single buffer for processing. This means that splitting on arbitrary chunks of data may possibly be used to generate valid base64.

Examples

'netspooky' │ bmV0c3Bvb2t5
'nets','poo','ky' │ bmV0cw==cG9va3k=
'ne','ts','po','ok','y' │ bmU=dHM=cG8=b2s=eQ==
'n','e','t','s','p','o','o','k','y' │ bg==ZQ==dA==cw==cA==bw==bw==aw==eQ==

Try it out!

base64 -d <<< "bmV0c3Bvb2t5"
base64 -d <<< "bmV0cw==cG9va3k="
base64 -d <<< "bmU=dHM=cG8=b2s=eQ=="
base64 -d <<< "bg==ZQ==dA==cw==cA==bw==bw==aw==eQ=="

Another neat trick that can throw off certain tools is using whitespace within base64 text. Check out this pyramid of base64 data and what it decodes to. Some tools and libraries will decode it just fine, but others (such as Linux base64), will consider it invalid input. Software that can decode this may be using a regex used to filter out whitespace, or isolate valid base64 characters only.

Keep in mind that these simple techniques can also be used to ensure that your encoded data isn’t processed, or readable only by your tools.

PROTIP: Combine this with a custom base64 charset to frustrate most analysts.

When approaching a web application that may accept Base64 encoded data, you may run into filters that look for certain Base64 patterns without actually decoding the data itself. Using obfuscation, you may be able to sneak some data past these pesky filters and decode at the heart of the app. The same can be said for yara rules or other detection software. Decoding can be more expensive than just applying a simple regex ;}

See how your favorite base64 implementation handles encoded data like this! Try to not put padding at the end, decode at arbitrary chunk points, include whitespace and symbols with mixed encoding, etc.

I wrote a quick and dirty script to generate some mutations based on the uneven chunk obfuscation technique outlined above. Feel free to use it for both attack and defense!

Use Cases:

Filter Bypass
Signature Evasion
Make encoded weak credentials less easy to find
- admin -> YWRtaW4=
- admin -> YQ==ZG1pbg==
- admin -> YWQ=bWlu
Base64 decoder fuzzing

Thanks to dnz for telling me to actually write this stuff down and turn it into a proper tool. Thanks to remy and gren for feedback. Shoutout tchq, vxug, tcpd.

Python 3.7+ .pyc file format

Tue, 15 Dec 2020 12:00:00 -0400

Fun Fact: A Py3.7+ .pyc code object contains a header for various things like the number of local variables, stack size, flags etc, as well as the bytecode for the code block. All header values are big endian, except for the size of the bytecode, which is a 4 byte little endian field (at 0x64).

Original: https://twitter.com/netspooky/status/1338997963910225922

TODO: Get original ansi

Linux.Precinct3.asm

Tue, 24 Nov 2020 12:00:00 -0400

https://tmpout.sh/1/Linux.Precinct3.asm

Linux Oneliners

Sun, 01 Nov 2020 12:00:00 -0400

Misc Useful

Find duplicate files

find . ! -empty -type f -exec md5sum {} + | sort | uniq -w32 -dD

Extract all zip files in current directory

find . -name "*.zip" -exec mkdir {}_ \; -exec mv {} {}_/ \; -exec 7z x {}_/{} -o{}_/ \;

generate uuid

cat /proc/sys/kernel/random/uuid

How to use USBPCAP on Ubuntu

sudo modprobe usbmon
sudo setfacl -m u:$USER:r /dev/usbmon*

Disable system beep

rmmod pcspkr ; echo "blacklist pcspkr" >>/etc/modprobe.d/blacklist.conf

Vim, Regex, Grep

remove trailing whitespace regex

[^\S\r\n]+$

How to remove all lines containing value REMOVEME

^.*REMOVEME.*\n

Vim: Remove all blank lines in a file

:g/^$/d

Find all memcpy instances in a dir (with line numbers)

grep --color -rin memcpy .

Hex Stuff

Here’s a tutorial I made about using Vim as a hex editor: https://twitter.com/netspooky/status/1553047692678414337

copy intel hex format to bin

objcopy -I ihex file.hex -O binary file.bin

reverse hex dump

cat asciihex.txt | xxd -r -p > file.bin

base64 to bin

base64 -d <<< someb64here > file.bin

perl hexdump

perl -e 'local $/; print unpack "H*", <>' file.bin

convert hex value to decimal

printf "%d\n" $((16#6132387a))

Python Hello World

Thu, 24 Sep 2020 12:00:00 -0400

Original post: https://twitter.com/netspooky/status/1309158304426479616

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


import base64
x ='\x2b\x0d\x06\x3c\x2d\x39\x1e\x3d'
x+='\x2f\x77\x1a\x3c\x07\x0f\x05\x38'
x+='\x15\x05\x34\x37\x17\x31\x0c\x39'
x+='\x28' '\x17\x15\x38\x08' '\x14'
x+='\x0d\x27\x0e\x1f\x79\x3c\x35\x7c'
x+='\x36\x20\x27\x1c\x2f\x35\x07\x1f'
x+='\x37\x2d\x2b' '\x1a\x05\x2b'
x+='\x01\x29' '\x34\x78' '\x01\x2d'
x+='\x2b' '\x31\x29\x00\x2f' '\x25'
x+='\x1d\x04\x2b\x7c\x1a\x23\x2a\x78'
x+='\x0a\x25\x0b\x2f\x29\x0b\x0e\x7f'
x+= '\x1b\x25'
x+='\x2f\x05'
h='HELLOWORLD';k=(((h*2)+'u')*4);t=''
for i in x: t+=chr(ord(i)^ord(k[len(t)]))
eval(base64.b64decode(t))

pcapscroller.py

Sun, 20 Sep 2020 12:00:00 -0400

Code:

# 2020-09-20
# Used to generate this 
import time
import urllib.request

l0 = '8b........d8...............................................................................................................88..88....................................................................................................88.....................................................................................88..88.................................................................................................................................88..88..................................................................................................................................88......................................................................................'
l1 = '.Y8,....,8P................................................................................................................88..""....................................................................................................88.....................................................................................88.."".................................................................................................................................""..88...............................................................................................................,d..........,d.....88......................................................................................'
l2 = '..Y8,..,8P.................................................................................................................88........................................................................................................88.....................................................................................88.........................................................................................................................................88...............................................................................................................88..........88.....88......................................................................................'
l3 = '..."8aa8"..,adPPYba,...88.......88.....,adPPYYba,..8b,dPPYba,...,adPPYba,.....8b,dPPYba,...,adPPYba,..,adPPYYba,...,adPPYb,88..88..8b,dPPYba,....,adPPYb,d8.....8b,dPPYba,....,adPPYba,..,adPPYYba,..8b,dPPYba,...,adPPYba,..........88.....,adPPYYba,..88,dPYba,,adPYba,......8b,dPPYba,...,adPPYba,..,adPPYYba,...,adPPYb,88..88..8b,dPPYba,....,adPPYb,d8.....8b.......d8...,adPPYba,...88.......88..8b,dPPYba,......,adPPYba,..88,dPYba,,adPYba,...,adPPYYba,..88..88..........8b......db......d8...,adPPYba,.....,adPPYYba,..8b,dPPYba,...,adPPYba,.....8b,dPPYba,....,adPPYba,..MM88MMM.....MM88MMM..88,dPPYba,....,adPPYba,.....,adPPYba,..,adPPYYba,..88,dPYba,,adPYba,....,adPPYba,.......'
l4 = '....`88"..a8"....."8a..88.......88....."".....`Y8..88P"..."Y8..a8P,,,,,88.....88P"..."Y8..a8P,,,,,88.."".....`Y8..a8"....`Y88..88..88P"...`"8a..a8"....`Y88.....88P"...."8a..a8"....."".."".....`Y8..88P"...."8a..I8[....""..........88....."".....`Y8..88P"..."88"...."8a.....88P"..."Y8..a8P,,,,,88.."".....`Y8..a8"....`Y88..88..88P"...`"8a..a8"....`Y88.....`8b.....d8"..a8"....."8a..88.......88..88P"..."Y8.....a8P,,,,,88..88P"..."88"...."8a.."".....`Y8..88..88..........`8b....d88b....d8"..a8P,,,,,88....."".....`Y8..88P"..."Y8..a8P,,,,,88.....88P"...`"8a..a8"....."8a...88..........88.....88P"...."8a..a8P,,,,,88.....I8[...."".."".....`Y8..88P"..."88"...."8a..a8P,,,,,88.......'
l5 = '.....88...8b.......d8..88.......88.....,adPPPPP88..88..........8PP""""""".....88..........8PP"""""""..,adPPPPP88..8b.......88..88..88.......88..8b.......88.....88.......d8..8b..........,adPPPPP88..88.......d8...`"Y8ba,...aaa.....88.....,adPPPPP88..88......88......88.....88..........8PP"""""""..,adPPPPP88..8b.......88..88..88.......88..8b.......88......`8b...d8"...8b.......d8..88.......88..88.............8PP"""""""..88......88......88..,adPPPPP88..88..88..aaa......`8b..d8"`8b..d8"...8PP""""""".....,adPPPPP88..88..........8PP""""""".....88.......88..8b.......d8...88..........88.....88.......88..8PP"""""""......`"Y8ba,...,adPPPPP88..88......88......88..8PP""""""".......'
l6 = '.....88..."8a,...,a8".."8a,...,a88.....88,....,88..88.........."8b,...,aa.....88.........."8b,...,aa..88,....,88.."8a,...,d88..88..88.......88.."8a,...,d88.....88b,...,a8".."8a,...,aa..88,....,88..88b,...,a8"..aa....]8I.."88.....88.....88,....,88..88......88......88.....88.........."8b,...,aa..88,....,88.."8a,...,d88..88..88.......88.."8a,...,d88.......`8b,d8"...."8a,...,a8".."8a,...,a88..88............."8b,...,aa..88......88......88..88,....,88..88..88.."88.......`8bd8"..`8bd8"...."8b,...,aa.....88,....,88..88.........."8b,...,aa.....88.......88.."8a,...,a8"...88,.........88,....88.......88.."8b,...,aa.....aa....]8I..88,....,88..88......88......88.."8b,...,aa..888..'
l7 = '.....88....`"YbbdP""....`"YbbdP"Y8.....`"8bbdP"Y8..88...........`"Ybbd8"".....88...........`"Ybbd8""..`"8bbdP"Y8...`"8bbdP"Y8..88..88.......88...`"YbbdP"Y8.....88`YbbdP""....`"Ybbd8""..`"8bbdP"Y8..88`YbbdP""...`"YbbdP""..d8".....88.....`"8bbdP"Y8..88......88......88.....88...........`"Ybbd8""..`"8bbdP"Y8...`"8bbdP"Y8..88..88.......88...`"YbbdP"Y8.........Y88"......`"YbbdP""....`"YbbdP"Y8..88..............`"Ybbd8""..88......88......88..`"8bbdP"Y8..88..88..d8".........YP......YP.......`"Ybbd8"".....`"8bbdP"Y8..88...........`"Ybbd8"".....88.......88...`"YbbdP""...."Y888......."Y888..88.......88...`"Ybbd8"".....`"YbbdP""..`"8bbdP"Y8..88......88......88...`"Ybbd8""..888..'
l8 = '.................................................................................................................................................aa,....,88.....88...................................88.....................8"....................................................................................................................aa,....,88.........d8"..................................................................................................8".......................................................................................................................................................................................................................'
l9 = '.................................................................................................................................................."Y8bbdP"......88...................................88............................................................................................................................................"Y8bbdP".........d8"............................................................................................................................................................................................................................................................................................................................'

x = 0 # The starting point in the scroll
y = 16 # End of screen

url = 'http://127.0.0.1:8080/index.php?page='
print("\033[2J")
for i in range(len(l0)):
 o0 = l0[x:y]
 o1 = l1[x:y]
 o2 = l2[x:y]
 o3 = l3[x:y]
 o4 = l4[x:y]
 o5 = l5[x:y]
 o6 = l6[x:y]
 o7 = l7[x:y]
 o8 = l8[x:y]
 o9 = l9[x:y]
 out = o0 + o1 + o2 + o3 + o4 + o5 + o6 + o7 + o8 + o9
 print(out)
 f = urllib.request.urlopen(url+out)
 x = x+1 # Increment start
 y = y+1 # Increment end
 if y == len(l0):
 break

Youtube Link: https://www.youtube.com/watch?v=QwSudydjRXc

Original: https://twitter.com/netspooky/status/1307038708907081728

BGGP1 Results Stream

Mon, 31 Aug 2020 12:00:00 -0400

https://www.youtube.com/watch?v=s0TS2kZtcGk

Palindromic 64 bit ELF binaries

Sun, 23 Aug 2020 12:00:00 -0400

This is my entry for the first annual Binary Golf Grand Prix.

Like all good things, the Binary Golf Grand Prix challenge started life as a tweet from 0xdade, and further conversation with some fine folks on Matrix. The goal of this challenge was to create a binary that executed the same forwards as it did backwards.

We established some ground rules, and I made the [announcement(https://twitter.com/netspooky/status/1275256864314470402) on Twitter calling other people to participate. The results of the first BGGP will be posted here when the challenge officially ends. Watch my Twitter for updates.

Developing An Approach

This challenge lends itself towards binary formats without headers, such as COM, bootloaders, firmware images, and most binary programs for 8 bit computers. It would make sense due to the short widths of instructions and data, leading to a smaller number of possible combinations of machine instructions.

Since I’ve done quite a bit of work with golfing ELF files, I figured it was worth a shot to see the feasibility of doing palindromic binaries that will run on modern systems.

I began my work with a baseline of a barebones binary golf’d 64 bit ELF file ( see ELF Binary Mangling 2 ), for the foundation of this binary. The first task was to flip the entirety of the data structures and code backwards, so that I could still use nasm to build the binary.

The original idea I had involved alphanumeric shellcode, to use and spell out a palindromic sentence, such as this from Scottish poet Alastair Reid:

T. Eliot, top bard, notes putrid tang emanating, is sad; I’d assign it a name: gnat dirt upset on drab pot toilet.

Palindromes rely on the ambiguity of punctuation to work in a majority of cases, so something shorter would be needed, and preferably in all lowercase or upper case. I had decided to go with the phrase “PULLUP IF I PULLUP”, because it made more sense when presented as a string without punctuation.

The next problem quickly arose: the alphanumeric shellcode article was written in 2001. These techniques work for 32 bit instructions, but a lot of encoding was changed in 64 bit x86. This means we need to determine what still works, if anything.

Testing led me to understand that only letters P-Z are the only viable single byte instructions in the A-Z space. This means that I actually can’t do the original phrase “PULLUPIFIPULLUP” due to letters appearing outside this range.

50 push rax ; 'P'
51 push rcx ; 'Q'
52 push rdx ; 'R'
53 push rbx ; 'S'
54 push rsp ; 'T'
55 push rbp ; 'U'
56 push rsi ; 'V'
57 push rdi ; 'W'
58 pop rax ; 'X'
59 pop rcx ; 'Y'
5a pop rdx ; 'Z'

Luckily, there are vowel sounds that can be used to find some words. An online Scrabble word finder came in handy to generate some possible words for this. The palindromic phrase I decided to go with used only letters in our established range. I ended up with “PUPPY SPY, PSY P. PUP”, mainly because it’s absurd, but also it could be expressed with just the letters in the P-Z range.

The nice thing about these particular instructions is that they are really only just push & pop instructions, so you don’t have to worry too much about messing up data that might be in these registers, and just have to track where values might end up if I used them at all.

Now that we have all of this established, let’s start thinking in mirror mode.

Mirroring

The template binary only really executes 7 bytes:

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

What happens when if you flip these bytes backwards? Quite shockingly, this:

0: 05 0f ff 31 48 add eax,0x4831ff0f
5: 3c b0 cmp al,0xb0

There are several disassemblers that might interpret data differently, so when using nasm, it’s helpful to confirm that these instructions actually assemble the way you expect them to. Lucky for us, this works just fine.

Padding the header (and various other places) with nops is helpful when you are measuring the space available when constructing a binary like this. The code began at offset 0x04, so padding with 5 nops filled the rest of the header.

The next thing to plan out was the jumps.

I figured that jmp instructions could be accounted for in one of two ways:

A pairing of jmp’s that jmp over each other, or
jmps that executed as code when percieved backwards.

I wrote a small script to generate all of the possible opcode combinations for short jumps and what they disassemble to when interpreted backwards. Even though it’s only two bytes, there are a lot of incompatible instructions, such as references to EBP and other registers that aren’t easily referenceable in x64.

import sys
import subprocess

# python3 opiter.py opcode
# Will iter through one byte in front of the opcode you put in there.
# It's hella bespoke, feel free to change heh

exp = sys.argv[1]

for i in range(0,255):
 opp = format(i, '02x')
 inf = '"'+opp+' '+exp+'"'
 print(opp+" "+exp+" |",end=" ")
 process = subprocess.run(['/usr/bin/rasm2 -a x86 -b 64 -d '+inf],
 shell=True, check=True, stdout=subprocess.PIPE,
 universal_newlines=True)
 output = process.stdout
 if 'invalid' in output:
 print("--")
 else:
 print(output,end="")

This is the output from the jmp brute table with invalid opcodes ignored:

OPCODE|INSTRUCTIONS
------+---------------
00 eb | add bl, ch
01 eb | add ebx, ebp
02 eb | add ch, bl
03 eb | add ebp, ebx
04 eb | add al, 0xeb
08 eb | or bl, ch
09 eb | or ebx, ebp
0a eb | or ch, bl
0b eb | or ebp, ebx
0c eb | or al, 0xeb
10 eb | adc bl, ch
11 eb | adc ebx, ebp
12 eb | adc ch, bl
13 eb | adc ebp, ebx
14 eb | adc al, 0xeb
18 eb | sbb bl, ch
19 eb | sbb ebx, ebp
1a eb | sbb ch, bl
1b eb | sbb ebp, ebx
1c eb | sbb al, 0xeb
20 eb | and bl, ch
21 eb | and ebx, ebp
22 eb | and ch, bl
23 eb | and ebp, ebx
24 eb | and al, 0xeb
28 eb | sub bl, ch
29 eb | sub ebx, ebp
2a eb | sub ch, bl
2b eb | sub ebp, ebx
2c eb | sub al, 0xeb
30 eb | xor bl, ch
31 eb | xor ebx, ebp
32 eb | xor ch, bl
33 eb | xor ebp, ebx
34 eb | xor al, 0xeb
38 eb | cmp bl, ch
39 eb | cmp ebx, ebp
3a eb | cmp ch, bl
3b eb | cmp ebp, ebx
3c eb | cmp al, 0xeb
63 eb | movsxd rbp, ebx
6a eb | push 0xffffffffffffffeb
70 eb | jo 0xffffffffffffffed
71 eb | jno 0xffffffffffffffed
72 eb | jb 0xffffffffffffffed
73 eb | jae 0xffffffffffffffed
74 eb | je 0xffffffffffffffed
75 eb | jne 0xffffffffffffffed
76 eb | jbe 0xffffffffffffffed
77 eb | ja 0xffffffffffffffed
78 eb | js 0xffffffffffffffed
79 eb | jns 0xffffffffffffffed
7a eb | jp 0xffffffffffffffed
7b eb | jnp 0xffffffffffffffed
7c eb | jl 0xffffffffffffffed
7d eb | jge 0xffffffffffffffed
7e eb | jle 0xffffffffffffffed
7f eb | jg 0xffffffffffffffed

I needed some code to execute, something very small, yet produce some sort of output to prove that it worked. The code I decided to adapt for this was based on the tiny ELF binary I had explained in a stream on assembly optimization called i2ao, and it was simple enough that I could port for this application. All it really does is print out a string.

Since we have a palindrome string that could be executed as well, it seemed fitting to print that string out, as well as execute it. This would save space on data and make the overall mirrored layout look more even.

Fitting The Pieces Together

Now that all the pieces to build this are in place, we can start to put them together. The full assembly listing is at the bottom of this section if you want to play along at home!

The primary concern is to make sure that the registers we need are cleared prior to making a syscall. In this case, we are making two syscalls: write and exit.

The registers required for a write syscall are: RAX, RDX, RDI, and RSI. Since the first instructions executed add values to RAX, an explicit mov rax, 1 is needed, rather than any clever tricks to populate RAX. If we wanted to use something like xor rax, rax; inc rax, it would add an extra byte. Some other space saving measures are also used in the write syscall code, which you can refer to in the i2ao writeups / video.

The next step is to reference the string within the code that is right after the write syscall. There are a few ways of making references to the current offset, but none of them made much sense other than simply using the offsets in the binary and moving that value into the sil register.

In times like these, it’s useful to build, but not execute, and open your binary in a debugger. Mind you, it does start to get frustrating when your debugger gets confused about what the heck you’re actually doing, but it’s trying it’s best! Sometimes seeking directly to the offset you’re interested in and disassembling there is the only real way to understand what’s happening.

After the write syscall code was sorted, it was time to start mirroring the entire executable section. Since the bounds of the headers have already been established, you can safely do this without messing up your binary too much.

The write syscall code doesn’t really have too many instructions that you can safely execute backwards without entirely rewriting it. So instead of that, another approach is to simply jump over whatever you can’t execute. The alphanumeric machine code bit is executable and won’t interfere with the flow of the program, so a jmp can be placed between that and the junk code.

The size of the write code, along with the short jmp, produces ‘jmp 0x17’, which turns into ’eb 15’ in machine code. This unfortunately doesn’t translate to anything usable backwards. Referring to the jmp table, there is a possibly usable instruction ‘sbb bl, ch’, that can be achieved by padding with 3 nops to bring the opcode to ‘18eb’ when backwards, ’eb18’ forwards.

So what’s the point of this? Mainly to prevent generating even more junk bytes to account for. Another solution would be to just encode a backwards jmp ‘02eb’ after the jmp to the write syscall, which would do a small hop over the jmp that we can’t execute backwards. This way felt more clean in the end.

Now all we have to do is just execute our string, clear RAX, and jump back into the headers. This just adds a small (5 byte) block that we have to account for when we jump out of the headers the first time and into the main code section.

A space saving trick used here was to completely overwrite the p_align section, which saves 16 bytes in total (8 on each side) within the code section.

It was frustrating to have junk code within the space of 0x4-0x10, where the binary begins and ends execution, so a final idea was tried to utilize all the space here.

There is writable space at both 0x3C and 0x44 in the program header. They must be exactly the same or the binary will not execute. Each part has 4 bytes of space to work with, which is perfect to do something simple like a short jmp.

Doing a short jmp from the top of the ELF header to 0x44, produces a some bytes that are usable backwards! This is ’eb34’, which backwards, ‘34eb’ is decoded to ‘xor al, 0xeb’. Since it’s only messing with AL, the lowest byte of RAX, this doesn’t matter because the value is explicitly assigned afterwards. chefs kiss

This is the final code:

BITS 64
org 0x100000000 ; Where to load this into memory
;----------------------+------+-------------+----------+------------------------
; ELF Header struct | OFFS | ELFHDR | PHDR | ASSEMBLY OUTPUT
;----------------------+------+-------------+----------+------------------------
db 0x7F, "ELF" ; 0x00 | e_ident | | 7f 45 4c 46
_start:
add eax,0x4831ff0f ; The reverse of
cmp al,0xb0 ; the exit syscall
nop ; 90
nop ; 90
nop ; 90
jmp hjmp ; eb 34
;----------------------+------+-------------+----------+------------------------
; ELF Header struct ct.| OFFS | ELFHDR | PHDR | ASSEMBLY OUTPUT
;----------------------+------+-------------+----------+------------------------
dw 2 ; 0x10 | e_type | | 02 00
dw 0x3e ; 0x12 | e_machine | | 3e 00
dd 1 ; 0x14 | e_version | | 01 00 00 00
dd _start - $$ ; 0x18 | e_entry | | 04 00 00 00
;----------------------+------+-------------+----------+------------------------
; Program Header Begin | OFFS | ELFHDR | PHDR | ASSEMBLY OUTPUT
;----------------------+------+-------------+----------+------------------------
phdr:
dd 1 ; 0x1C | ... | p_type | 01 00 00 00
dd phdr - $$ ; 0x20 | e_phoff | p_flags | 1c 00 00 00
dd 0 ; 0x24 | ... | p_offset | 00 00 00 00
dd 0 ; 0x28 | e_shoff | ... | 00 00 00 00
dq $$ ; 0x2C | ... | p_vaddr | 00 00 00 00
; 0x30 | e_flags | ... | 01 00 00 00
dw 0x40 ; 0x34 | e_shsize | p_addr | 40 00
dw 0x38 ; 0x36 | e_phentsize | ... | 38 00
dw 1 ; 0x38 | e_phnum | ... | 01 00
dw 2 ; 0x3A | e_shentsize | ... | 02 00
;dq 2 ; 0x3C | e_shnum | p_filesz | 02 00 00 00 00 00 00 00
dw 0x0beb ; eb 0b ; Overwrites e_shnum and p_filesz
dw 0
dd 0
hjmp:
;dq 2 ; 0x44 | | p_memsz | 02 00 00 00 00 00 00 00
jmp sec0 ; eb 0b ; Overwrites p_memsz
dw 0
dd 0
;dq 2 ; 0x4C | | p_align | 02 00 00 00 00 00 00 00
;--- Outer bounds of executable portion
cmp al, 0xeb ; 3c eb ; Overwrites p_align
db 0xc0 ; c0
db 0x31 ; 31
db 0x48 ; 48
sec0:
push rax ; 50
push rbp ; 55
push rax ; 50
push rax ; 50
pop rcx ; 59
push rbx ; 53
push rax ; 50
pop rcx ; 59
push rax ; 50
push rbx ; 53
pop rcx ; 59
push rax ; 50
push rax ; 50
push rbp ; 55
push rax ; 50
jmp sec1 ; eb 18
nop ; 90
nop ; 90
nop ; 90
nop ; 90
nop ; 90
add eax,0x40b6950f ; 05 0f 95 b6 40 ; Third byte is str offset
and dh,ah ; 20 e6
ror DWORD [rax-0x3a],0x89 ; c1 48 c6 89
dd 0x89c7b20f ; 0f b2 c7 89
add BYTE [rax],al ; 00 00
add BYTE [rcx],al ; 00 01
;--- split - the first byte is shared with the mov rax,1
sec1:
mov rax, 1 ; b8 01 00 00 00
mov edi, eax ; 89 c7
mov dl, 15 ; b2 0f
mov esi, eax ; 89 c6
shl rsi, 0x20 ; 48 c1 e6 20
mov sil, 0x95 ; 40 b6 95
syscall ; 0f 05
nop ; 90
nop ; 90
nop ; 90
nop ; 90
nop ; 90
sbb bl, ch ; 18 eb
sec2:
push rax ; 50
push rbp ; 55
push rax ; 50
push rax ; 50
pop rcx ; 59
push rbx ; 53
push rax ; 50
pop rcx ; 59
push rax ; 50
push rbx ; 53
pop rcx ; 59
push rax ; 50
push rax ; 50
push rbp ; 55
push rax ; 50
xor rax, rax ; 48 31 c0
jmp rstart ; eb 3c
;--- Header Mirror
dd 0
dw 0
dw 0xeb0b ; 0x44 | | p_memsz | 02 00 00 00 00 00 00 00
dd 0 ;
dw 0 ;
dw 0xeb0b ; 0x3C | e_shnum | p_filesz | 02 00 00 00 00 00 00 00
db 0 ;
db 2 ; 0x3A | e_shentsize | ... | 02 00
db 0 ;
db 1 ; 0x38 | e_phnum | ... | 01 00
db 0 ;
db 0x38 ; 0x36 | e_phentsize | ... | 38 00
db 0 ;
db 0x40 ; 0x34 | e_shsize | p_addr | 40 00
dw 0 ;
db 0 ;
db 1 ; 0x30 | e_flags | ... | 01 00 00 00
dd 0 ; 0x2C | ... | p_vaddr | 00 00 00 00
dd 0 ; 0x28 | e_shoff | ... | 00 00 00 00
dd 0 ; 0x24 | ... | p_offset | 00 00 00 00
dw 0 ;
db 0 ;
db 0x1c ; 0x20 | e_phoff | p_flags | 1c 00 00 00
dw 0 ;
db 0 ;
db 1 ; 0x1C | ... | p_type | 01 00 00 00
dw 0 ;
db 0 ;
db 4 ; 0x18 | e_entry | | 04 00 00 00
dw 0 ;
db 0 ;
db 1 ; 0x14 | e_version | | 01 00 00 00
db 0 ;
db 0x3e ; 0x12 | e_machine | | 3e 00
db 0 ;
db 2 ; 0x10 | e_type | | 02 00
rstart:
xor al, 0xeb ; 34 EB ; Jmp in reverse
nop ; 90
nop ; 90
nop ; 90
mov al, 0x3c ; b0 3c
xor rdi, rdi ; 48 31 ff
syscall ; 0f 05
db "F"
db "L"
db "E"
db 0x7F ; 0x00 | e_ident | | 7f 45 4c 46

Confirming It Works

This was tested and built on Ubuntu 20.04 with kernel 5.4.0-42-generic.

Here is a small script you can use to build and test the ASM file:

#!/bin/bash

nasm -f bin ns.bggp.asm -o ns.bggp
chmod +x ns.bggp
echo "Executing initial binary..."
./ns.bggp
echo ""
xxd ns.bggp
echo ""
echo "Reversing..."
perl -0777pe '$_=reverse $_' ns.bggp > ns.bggp.R
chmod +x ns.bggp.R
echo "Executing binary in reverse..."
./ns.bggp.R
echo ""
xxd ns.bggp.R
echo ""
echo "Comparing hashes..."
sha1sum ns.bggp
sha1sum ns.bggp.R

Output:

$ ./build.sh
Executing initial binary...
PUPPYSPYPSYPPUP
00000000: 7f45 4c46 050f ff31 483c b090 9090 eb34 .ELF...1H&lt;.....4
00000010: 0200 3e00 0100 0000 0400 0000 0100 0000 ..>.............
00000020: 1c00 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0100 0000 4000 3800 0100 0200 eb0b 0000 ....@.8.........
00000040: 0000 0000 eb0b 0000 0000 0000 3ceb c031 ............&lt;..1
00000050: 4850 5550 5059 5350 5950 5359 5050 5550 HPUPPYSPYPSYPPUP
00000060: eb18 9090 9090 9005 0f95 b640 20e6 c148 ...........@ ..H
00000070: c689 0fb2 c789 0000 0001 b801 0000 0089 ................
00000080: c7b2 0f89 c648 c1e6 2040 b695 0f05 9090 .....H.. @......
00000090: 9090 9018 eb50 5550 5059 5350 5950 5359 .....PUPPYSPYPSY
000000a0: 5050 5550 4831 c0eb 3c00 0000 0000 000b PPUPH1..&lt;.......
000000b0: eb00 0000 0000 000b eb00 0200 0100 3800 ..............8.
000000c0: 4000 0000 0100 0000 0000 0000 0000 0000 @...............
000000d0: 0000 0000 1c00 0000 0100 0000 0400 0000 ................
000000e0: 0100 3e00 0234 eb90 9090 b03c 4831 ff0f ..>..4.....&lt;H1..
000000f0: 0546 4c45 7f .FLE.
Reversing...
Executing binary in reverse...
PUPPYSPYPSYPPUP
00000000: 7f45 4c46 050f ff31 483c b090 9090 eb34 .ELF...1H&lt;.....4
00000010: 0200 3e00 0100 0000 0400 0000 0100 0000 ..>.............
00000020: 1c00 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0100 0000 4000 3800 0100 0200 eb0b 0000 ....@.8.........
00000040: 0000 0000 eb0b 0000 0000 0000 3ceb c031 ............&lt;..1
00000050: 4850 5550 5059 5350 5950 5359 5050 5550 HPUPPYSPYPSYPPUP
00000060: eb18 9090 9090 9005 0f95 b640 20e6 c148 ...........@ ..H
00000070: c689 0fb2 c789 0000 0001 b801 0000 0089 ................
00000080: c7b2 0f89 c648 c1e6 2040 b695 0f05 9090 .....H.. @......
00000090: 9090 9018 eb50 5550 5059 5350 5950 5359 .....PUPPYSPYPSY
000000a0: 5050 5550 4831 c0eb 3c00 0000 0000 000b PPUPH1..&lt;.......
000000b0: eb00 0000 0000 000b eb00 0200 0100 3800 ..............8.
000000c0: 4000 0000 0100 0000 0000 0000 0000 0000 @...............
000000d0: 0000 0000 1c00 0000 0100 0000 0400 0000 ................
000000e0: 0100 3e00 0234 eb90 9090 b03c 4831 ff0f ..>..4.....&lt;H1..
000000f0: 0546 4c45 7f .FLE.
Comparing hashes...
c082d226c96b7251649c48526dd9766071fa5e59 ns.bggp
c082d226c96b7251649c48526dd9766071fa5e59 ns.bggp.R

Here is the base64 encoded binary if you don’t want to do all that:

base64 -d <<< \
f0VMRgUP/zFIPLCQkJDrNAIAPgABAAAABAAAAAEAAAAcAAAAAAAAAAAAAAAAAAAAAQAAAEAAOAAB\
AAIA6wsAAAAAAADrCwAAAAAAADzrwDFIUFVQUFlTUFlQU1lQUFVQ6xiQkJCQkAUPlbZAIObBSMaJ\
D7LHiQAAAAG4AQAAAInHsg+JxkjB5iBAtpUPBZCQkJCQGOtQVVBQWVNQWVBTWVBQVVBIMcDrPAAA\
AAAAAAvrAAAAAAAAC+sAAgABADgAQAAAAAEAAAAAAAAAAAAAAAAAAAAcAAAAAQAAAAQAAAABAD4A\
AjTrkJCQsDxIMf8PBUZMRX8= > ns.bggp

Going Further

I could’ve possibly shrunk the write syscall code down even more to try and save 1 byte to produce a short jmp of 0xeb12->0x12eb (adc ch, bl). Since I was coding not just for size, but for % of bytes executed as well, it made more sense just to leave it.

There are a few different approaches to this, and I just wanted to cover a few of them. This write up was just a brain dump of my notes as I worked on this. I will have a more in depth write up on this that I will submit to PoC||GTFO, so keep an eye out for that!

If you have any questions / comments, my dms are open on Twitter @netspooky.

Check out my main site if you want to see more binary golf examples!

Check out binary.golf for all Binary Golf Grand Prix related content!!

Hella Booters Talk (Defcon 28 IoT Village)

Sat, 08 Aug 2020 12:00:00 -0400

Slides: hellabooters.pdf

Video: https://www.youtube.com/watch?v=gDZoHorF42E

netspooky/pdiff

Thu, 25 Jun 2020 12:00:00 -0400

A script I made for diffing packets from a pcap.

Link: https://github.com/netspooky/pdiff

BGGP1 Announcement

Mon, 22 Jun 2020 12:00:00 -0400

https://n0.lol/bggp/

TODO: Link to binary.golf site with the proper pages.

ASCII Table

Mon, 01 Jun 2020 12:00:00 -0400

Dec Hex Char Dec Hex Char Dec Hex Char Dec Hex Char
-------------- -------------- -------------- --------------
0 00h NUL (null) 32 20h SP 64 40h @ 96 60h `
1 01h SOH (start of heading) 33 21h ! 65 41h A 97 61h a
2 02h STX (start of text) 34 22h " 66 42h B 98 62h b
3 03h ETX (end of text) 35 23h # 67 43h C 99 63h c
4 04h EOT (end of transmission) 36 24h $ 68 44h D 100 64h d
5 05h ENQ (enquiry) 37 25h % 69 45h E 101 65h e
6 06h ACK (acknowledge) 38 26h & 70 46h F 102 66h f
7 07h BEL (bell) 39 27h ' 71 47h G 103 67h g
8 08h BS (backspace) 40 28h ( 72 48h H 104 68h h
9 09h TAB (horizontal tab) 41 29h ) 73 49h I 105 69h i
10 0Ah LF (NL line feed, new line) 42 2Ah * 74 4Ah J 106 6Ah j
11 0Bh VT (vertical tab) 43 2Bh + 75 4Bh K 107 6Bh k
12 0Ch FF (NP form feed, new page) 44 2Ch , 76 4Ch L 108 6Ch l
13 0Dh CR (carriage return) 45 2Dh - 77 4Dh M 109 6Dh m
14 0Eh SO (shift out) 46 2Eh . 78 4Eh N 110 6Eh n
15 0Fh SI (shift in) 47 2Fh / 79 4Fh O 111 6Fh o
16 10h DLE (data link escape) 48 30h 0 80 50h P 112 70h p
17 11h DC1 (device control 1) 49 31h 1 81 51h Q 113 71h q
18 12h DC2 (device control 2) 50 32h 2 82 52h R 114 72h r
19 13h DC3 (device control 3) 51 33h 3 83 53h S 115 73h s
20 14h DC4 (device control 4) 52 34h 4 84 54h T 116 74h t
21 15h NAK (negative acknowledge) 53 35h 5 85 55h U 117 75h u
22 16h SYN (synchronous idle) 54 36h 6 86 56h V 118 76h v
23 17h ETB (end of trans. block) 55 37h 7 87 57h W 119 77h w
24 18h CAN (cancel) 56 38h 8 88 58h X 120 78h x
25 19h EM (end of medium) 57 39h 9 89 59h Y 121 79h y
26 1Ah SUB (substitute) 58 3Ah : 90 5Ah Z 122 7Ah z
27 1Bh ESC (escape) 59 3Bh ; 91 5Bh [ 123 7Bh {
28 1Ch FS (file separator) 60 3Ch < 92 5Ch \ 124 7Ch |
29 1Dh GS (group separator) 61 3Dh = 93 5Dh ] 125 7Dh }
30 1Eh RS (record separator) 62 3Eh > 94 5Eh ^ 126 7Eh ~
31 1Fh US (unit separator) 63 3Fh ? 95 5Fh _ 127 7Fh DEL

Adventures in Binary Golf (AirGap2020)

Sat, 02 May 2020 12:00:00 -0400

Video: https://www.youtube.com/watch?v=VLmrsfSE-tA

Slides: Adventures_in_Binary_Golf.pdf

Exotic Mirai Targets

Wed, 15 Apr 2020 12:00:00 -0400

Here’s a quick note on some malware targeting exotic processor architectures. I hope to do more investigation of this, but wanted to put out some info in case others have been looking for the same thing, or have more info.

JayTHL posted about some IOT malware they saw earlier today, and I finally found something I’d been looking for for a while now. In late 2018/early 2019, I had seen someone post a screenshot of some Mirai binaries, one of which had the extension .nios2.

Nios II is a processor architecture made by Intel designed to run on FPGAs. Devices that run this are pretty rare and would be used for highly custom or experimental applications, so they would be running a version of Linux made for that architecture. Nios II Linux is a fairly common project for Nios II based devices, but there are many variant OSes that have been created for it.

In the binaries JayTHL was talking about, there were not only Nios II bins, but binaries targeting other FPGAs as well, Xtensa, and Microblaze. There were also other architectures I’d never seen targeted before. ARC, OpenRISC, RISCV64, and AARCH64. I was super excited to finally answer some questions about these binaries, and what specific devices they would actually be run on.

Analysis

The files I gathered were:

SHA256	File Name
6b7fbe2823a38b186d63c8d22514a6a55d01d1694048c6b1a4318e8815a975a4	malware.aarch64
1627c3a82d3847ef82869be0ab773bae0e1f75e285d7747d2c9e45a0d6cc6101	malware.aarch64be
cd5fd0a3613e1d89603f71cde89aff0c13081827136a7758823bb394f27daaf4	malware.arc
67381a5f586e457785b7c0960cc78e87a36fb76b41e6fdbfb342ec73a38abd1f	malware.arcle-750d
a75df2bb4227b5b119e91f9892ff60a92436454d24f10f81b003c0206a293096	malware.arcle-hs38
d133cade798f6327d1221cab9b5b414ebcbadccbda041a33846bf86aa4080a5b	malware.arm7
a1b5d42e3828dc32859c6df7575f7e6ddfd3ecb13d6bda3551dee31b9a1b70a1	malware.m68k-68xxx
17ad4483d28345ec86d2f73b346daa0515d0bfbbb8aba3415fb57105f75516a5	malware.microblazebe
b17f7771197365405256ce557c6455871b2b0519dd0c7a2d5897f97d5b0e86d3	malware.microblazeel
4cbbc7ccfbc4eea461ba373dac71a5f6f49ea36bf28400dbc372b75f850b49be	malware.nios2
89506d19b31ed1dc1fc829a4b99229fcbb68acb8e007c3c10d36351e5c6bf642	malware.openrisc
980c9eced00bb38e1bd8110c191ab0f90f8b8bfb3f6f20f88bc5b11de48b195a	malware.riscv64
e871a6c1153cb8cb994a8c2ec1efca409bce9bc8579c928112d5f3586bc4b035	malware.x86
96076f8295e82f1f0613a3126a35a4647d2ad40d237bcf5da99f3a95d32da7da	malware.xtensa

malware.nios2

Let’s start by looking at malware.nios2:

$ file malware.nios2
malware.nios2: ELF 32-bit LSB executable, Altera Nios II, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux-nios2.so.1, for GNU/Linux 4.1.0,
not stripped

So we can confirm this is a Nios II binary, let’s see what rabin2 has to say:

$ rabin2 -I malware.nios2
Unsupported relocs type 38 for arch 113
Unsupported relocs type 38 for arch 113
arch x86
baddr 0x2000
binsz 51440
bintype elf
bits 32
canary false
class ELF32
compiler GCC: (Buildroot 2018.08.1-00003-g576b333) 7.3.0
crypto false
endian little
havecode true
intrp /lib/ld-linux-nios2.so.1
laddr 0x0
lang c
linenum true
lsyms true
machine &lt;unknown&gt;: 0x71
maxopsz 16
minopsz 1
nx false
os linux
pcalign 0
pic false
relocs true
relro partial
rpath NONE
sanitiz false
static false
stripped false
subsys linux
va true

Radare2 supports Nios II, but rabin2 has trouble understanding what the machine type is. We now know:

The compiler is GCC: (Buildroot 2018.08.1-00003-g576b333) 7.3.0
The interpreter is /lib/ld-linux-nios2.so.1
The binary is not statically linked
It is not stripped

Let’s examine some symbols to see if there’s anything we can learn from that.

$ rabin2 -s malware.nios2
[Symbols]
nth paddr vaddr bind type size name
―――――――――――――――――――――――――――――――――――――――――――――――――――
...snip...
65 ---------- 0x00000000 LOCAL FILE 0 scanner.c
66 0x00006a78 0x00008a78 LOCAL FUNC 296 add_auth_entry
67 0x00005ef8 0x00007ef8 LOCAL FUNC 540 get_random_ip
68 0x00005dbc 0x00007dbc LOCAL FUNC 316 setup_connection
69 0x00006ba0 0x00008ba0 LOCAL FUNC 192 random_auth_entry
70 0x00006114 0x00008114 LOCAL FUNC 724 consume_iacs
71 0x00006528 0x00008528 LOCAL FUNC 616 consume_user_prompt
72 0x00006790 0x00008790 LOCAL FUNC 444 consume_pass_prompt
73 0x000063e8 0x000083e8 LOCAL FUNC 320 consume_any_prompt
74 0x0000694c 0x0000894c LOCAL FUNC 300 consume_resp_prompt
75 0x00006c60 0x00008c60 LOCAL FUNC 332 report_working
76 0x00006ee0 0x00008ee0 LOCAL FUNC 84 can_consume
77 0x00006dac 0x00008dac LOCAL FUNC 308 deobf
78 ---------- 0x00000000 LOCAL FILE 0 util.c
...snip...
95 0x00002440 0x00004440 GLOBAL FUNC 584 killer_kill_by_group
96 0x00003d1c 0x00005d1c GLOBAL FUNC 320 ackattack
98 0x00003010 0x00005010 GLOBAL FUNC 256 connection
99 ---------- 0x0000c190 GLOBAL OBJ 4 RavaugeCumSock
100 0x00001b94 0x00003b94 GLOBAL FUNC 172 decrypt_for_recv
101 0x0000169c 0x0000369c GLOBAL FUNC 424 encrypt_array
102 0x00009000 0x0000c000 WEAK NOTYPE 0 data_start
103 0x000019b4 0x000039b4 GLOBAL FUNC 336 encrypt_by_name
104 0x00007518 0x00009518 GLOBAL FUNC 384 util_itoa
107 0x00005d7c 0x00007d7c GLOBAL FUNC 64 scanner_kill
...snip...
221 ---------- 0x0000c174 GLOBAL OBJ 4 TotalKilled
223 ---------- 0x0000c1b8 GLOBAL OBJ 4 auth_table
224 ---------- 0x0000c19c GLOBAL OBJ 4 rand_str
225 0x00001d1c 0x00003d1c GLOBAL FUNC 444 killer_kill_by_deleted
227 0x00002b5c 0x00004b5c GLOBAL FUNC 1204 cmd_parse
228 0x00003e5c 0x00005e5c GLOBAL FUNC 320 urgattack
229 ---------- 0x00010e04 GLOBAL OBJ 40 savesysproc
230 0x00003bdc 0x00005bdc GLOBAL FUNC 320 synattack
231 ---------- 0x0000c1d0 GLOBAL OBJ 4 scanner_pid
...snip...

All of these symbols point to this being a Mirai variant. Particularly the use of auth_table and deobf, which are related to decrypting values from a 4 byte xor obfuscated table in Mirai variants.

So now we know that, let’s check out the other FPGA targets.

malware.xtensa

malware.xtensa uses the same compiler as malware.nios2, but targets the /lib/ld-uClibc.so.0 interpreter.

malware.microblaze*

malware.microblazebe seems to use microblaze-buildroot-linux-uclibc 7.3.0 as it’s compiler, and also appears to target uClibc. rabin2 wasn’t able to pick that up though, so I confirmed with rabin2 -s malware.microblazebe. The little endian version malware.microblazele has the same characteristics, except that it uses little endian format.

This symbol popped out at me that didn’t appear in the others:

165 ---------- 0x1002d310 LOCAL OBJ 4 been_there_done_that

malware.openrisc & malware.riscv64

malware.openrisc uses the following compiler and interpreter:

compiler GCC: (Buildroot 2018.08.1-00003-g576b333) 5.4.0
intrp /lib/ld-uClibc.so.0

While malware.riscv64 uses these:

compiler GCC: (Buildroot 2018.11-rc2-00003-ga0787e9) 8.2.0
intrp /lib/ld-linux-riscv64-lp64.so.1

malware.arc*

The malware.arc* line uses the following:

malware.arc

compiler ??
intrp /lib/ld-uClibc.so.0
machine ARC Cores Tangent-A5
static false
stripped true

malware.arcle-750d

compiler GCC: (Buildroot 2018.08.1-00003-g576b333) 7.3.1 20180319
intrp ??
machine ARC Cores Tangent-A5
static true
stripped false

malware.arcle-hs38

compiler GCC: (Buildroot 2018.08.1-00003-g576b333) 7.3.1 20180319
machine Synopsys ARCompact V2
static true
stripped false

Thoughts

The most telling symbol of all is “RavaugeCumSock”, which was found in most of the binaries. I wasn’t able to find this string in any of the collected malware sources that I have, so if anyone has any info please let me know!

So what have we learned?

None of the exotic devices use the uclibc.org compilers that most of the classic Mirai variants use. Instead they use buildroot.
Not all of these binaries are statically compiled as previous versions of Mirai are. This means that they could possibly be even LESS portable than other Mirai binaries.
Not all of the binaries are packed or stripped.

My main questions are:

What devices are they targeting, if anything? There are very few devices I know of that run say, Linux on Nios II, and of those devices, they are all SCADA devices.
Has there ever been any success with them? Has a bot ever come back and reported the CPU arch as any of the FPGA/RISC/ARC architectures? I am not doubting that devices with these arches exist online, but has anyone been able to infect with these bins?
What is the infection mechanism? Are there any exploits used? With all of these rare systems, are there any specific public exploits? It could just be SSH / Telnet bruteforcing too.

I’ll have to take a closer look later this week to do some dynamic analysis. The x86 and ARM bins are packed with some packer that isn’t UPX (shocker), and I haven’t had a chance to emulate some of these devices before, so I might just set up Linux on Nios II with my Altera DE0-Nano.

If you want to see more of the Mirai sources I’ve compiled, check out TL-BOTS

Shoutouts

Shoutout to JayTHL for making me fly off my couch to pull these apart. Also hermit for always sharing botnet binaries with me, grenlith for looking out for these binaries for me, and aneilan for doing that as well. <3

Modern PE Mangling

Sun, 29 Mar 2020 12:00:00 -0400

I’ve been wanting to learn more about Windows exploits and shellcode techniques for a bit, but a lot of resources out there (similarly to Linux), are based on 32 bit version of Windows, are very version specific, and simply don’t work on modern systems.

I decided to get started by learning more about 64 bit PEs. I really don’t know much about proper Windows API programming, so I wanted to see the bare minimum required to load and run code on Windows.

WARNING: I am not a Windows expert, I am barely a Windows user, so please excuse my noobishness and feel free to hit me up on twitter if you have any corrections or extra info for this.

Prior Work

Early attempts to create the smallest PE possible were based on 32 bit Windows versions. Prior to this, you could create beautifuly tiny COM files on DOS using 16 bit assembly.

The first writeup I read was this one, which determined the following limits on 32 bit Windows versions.

Smallest possible PE file: 97 bytes
Smallest possible PE file on Windows 2000: 133 bytes
Smallest PE file that downloads a file over WebDAV and executes it: 133 bytes

Unfortunately, the links to the files on this page are dead, so I could only see what was listed on the page.

The binary included here won’t run on modern Windows versions, so if we want to create a tiny binary to run on Windows 10, we’ll have to do some more research.

The consensus I found was that the limit for binary size in 64 bit Windows versions was 268 bytes. Thanks to the excellent Corkami docs (PE101 and PE102), I was able to explore the format a bit more in depth.

I located a few POCs, and examined how the binaries that were generated were structured.

The header overlay technique that was established in the first writeup seem to be employed by these POCs, but they don’t overlay section headers. The section headers define the .text segment as well as others, but it appears that they aren’t required for whatever reason.

First Attempts

I decided to keep the tradition of using NASM to write binaries by hand, because it’s easier to keep track of each byte individually and debug. My POC was based on the rcx/TinyPE repo’s smallest-pe.exe file. I created a list of all of the headers and their sizes / locations to keep track of what was already there.

TODO Insert Header Table

Anything marked with a * means that it is unused. Some of these might have some expected value ranges to respect, so keep that in mind when playing with them!

DOS Header

Index	Size	Free?	Description
MA	2		e_magic
MB	2	y	e_cblp
MC	2	y	e_cp
MD	2	y	e_crlc
ME	2	y	e_cparhdr
MF	2	y	e_minalloc
MG	2	y	e_maxalloc
MH	2	y	e_ss
MI	2	y	e_sp
MJ	2	y	e_csum
MK	2	y	e_ip
ML	2	y	e_cs
MM	2	y	e_lsarlc
MN	2	y	e_ovno
MO	8	y	e_res
MP	2	y	e_oemid
MQ	2	y	e_oeminfo
MR	20	y	e_res2
MS	4		e_lfanew PE Sig Addr

PE Header

Index	Size	Free?	Description
PA	4		PE Signature
PB	2		Machine (Intel 386)
PC	2		NumberOfSections
PD	4	y	TimeDateStamp
PE	4	y	PointerToSymbolTable
PF	4	y	NumberOfSymbols
PG	2		SizeOfOptionalHeader
PH	2		Characteristics (no relocs, executable, 32 bit)

Optional Header

Index	Size	Free?	Description
OA	2		Magic (PE32)
OB	1	y	MajorLinkerVersion
OC	1	y	MinorLinkerVersion
OD	4	y	SizeOfCode
OE	4	y	SizeOfInitializedData
OF	4	y	SizeOfUninitializedData
OG	4		AddressOfEntryPoint
OH	4	y	BaseOfCode
OI	4	y	BaseOfData
OJ	4		ImageBase
OK	4		SectionAlignment
OL	4		FileAlignment
OM	2	y	MajorOperatingSystemVersion
ON	2	y	MinorOperatingSystemVersion
OO	2	y	MajorImageVersion
OP	2	y	MinorImageVersion
OQ	2		MajorSubsystemVersion
OR	2	y	MinorSubsystemVersion
OS	4	y	Win32VersionValue
OT	4		SizeOfImage
OU	4		SizeOfHeaders
OV	4	y	CheckSum
OW	2		Subsystem (Win32 GUI)
OX	2	y	DllCharacteristics
OY	4	y	SizeOfStackReserve
OZ	4		SizeOfStackCommit
O1	4		SizeOfHeapReserve
O2	4	y	SizeOfHeapCommit
O3	4	y	LoaderFlags
O4	4	y	NumberOfRvaAndSizes

After I got it working, I needed a payload. I remembered the wonderful writeup by Iliya Dafchev, “Writing Windows Shellcode”, which details a more modern approach to Windows shellcode. It uses the technique of parsing the PEB structure to find the base address of kernel32.dll, and then calling WinExec using arguments on the stack and execute calc.exe.

As much as I love shellstorm, many of the payloads listed for Windows are based on much older versions. Some of them use hardcoded addresses which aren’t as portable, so I figured it’d be a lot nicer to take an existing payload and pack it into the binary.

The first step was loading payload into the binary and seeing if it worked as is. Fortunately, it did! I was able to just put the payload after the headers at 0x7C and execute. Here is what that binary looks like.

$ xxd tiny304.exe
MC-- MD-- ME-- MF-- MG-- MH--
MA-- MB-- PA------- PB-- PC-- PD-------
00000000: 4d5a 0000 5045 0000 4c01 0000 0000 0000 MZ..PE..L.......
MI-- MJ-- MK-- ML-- MM-- MN-- MO-------
PE------- PF------- PG-- PH-- OA-- OBOC
00000010: 0000 0000 0000 0000 6000 0301 0b01 0000 ........`.......
MO------- MP-- MQ-- MR-----------------
OD------- OE------- OF------- OG-------
00000020: 0300 0000 0000 0000 0000 0000 7c00 0000 ............|...
MR--------------------------- MS-------
OH------- OI------- OJ------- OK-------
00000030: 0000 0000 0000 0000 0000 4000 0400 0000 ..........@.....
OL------- OM-- ON-- OO-- OP-- OQ-- OR--
00000040: 0400 0000 0000 0000 0000 0000 0500 0000 ................
OS------- OT------- OU------- OV-------
00000050: 0000 0000 8000 0000 7c00 0000 0000 0000 ........|.......
OW-- OX-- OY------- OZ------- O1-------
00000060: 0200 0004 0000 1000 0010 0000 0000 1000 ................
O2------- O3------- O4------- CK-------
00000070: 0010 0000 0000 0000 0000 0000 31f6 83ec ............1...
00000080: 1856 6a63 6668 7865 6857 696e 4589 65fc .VjcfhxehWinE.e.
00000090: 648b 5e30 8b5b 0c8b 5b14 8b1b 8b1b 8b5b d.^0.[..[......[
000000a0: 1089 5df8 8b43 3c01 d88b 4078 01d8 8b48 ..]..C<...@x...H
000000b0: 2401 d989 4df4 8b78 2001 df89 7df0 8b50 $...M..x ...}..P
000000c0: 1c01 da89 55ec 8b58 1431 c08b 55f8 8b7d ....U..X.1..U..}
000000d0: f08b 75fc 31c9 fc8b 3c87 01d7 6683 c108 ..u.1...<...f...
000000e0: f3a6 740a 4039 d872 e583 c426 eb41 8b4d ..t.@9.r...&.A.M
000000f0: f489 d38b 55ec 668b 0441 8b04 8201 d831 ....U.f..A.....1
00000100: d252 682e 6578 6568 6361 6c63 686d 3332 .Rh.exehcalchm32
00000110: 5c68 7973 7465 6877 735c 5368 696e 646f \hystehws\Shindo
00000120: 6843 3a5c 5789 e66a 0a56 ffd0 83c4 46c3 hC:\W..j.V....F.

Being shellcode, the payload has some extra instructions to preserve and restore registers, which help to clean up the execution if it was to be injected. We can safely take out those instructions and continue.

I did some other small optimizations to reduce the code size, but other than that it’s a pretty tight payload.

(Ab)using the Headers

I had looked through some of the previous documentation on aspects of the header that aren’t used. The headers are already overlayed, but within the overlay, there are still some portions of the headers that are unused. These areas can be used to store data or execute code without interfering with the binary’s execution.

The areas that I used are listed on the side here

Start	End	Len
0x0C	0x18	12
0x1E	0x2C	14
0x44	0x4C	8
0x4E	0x54	6
0x5C	0x60	4
0x70	0x78	8

When you jump around a header like this, you’ll have to remember a couple of things. First, for each cave
in the header, unless you are ending the code there, you must make sure you have enough room for your jumps to other areas.

I tend to allocate 2 bytes, because short jumps are generally the easiest to work with, but you can use whatever you like as long as you keep the space they take up in mind!

The other thing is, if you are jumping past the bounds of 127 bytes forward or 128 bytes back with a short jump, the size of the instruction increases.

Something else I noticed was that NumberOfRvaAndSizes is touchy, and it possibly prevents the binary from loading if you put something there. This and other header areas are certainly open for experimentation!

Another trick of mine for ELF binary mangling was to put the code entrypoint in the header itself. This is not as straightforward with 64 bit PEs.

Windows 8 established a restriction that the AddressOfEntryPoint can’t be smaller than SizeOfHeaders. The way around this is to set SizeOfHeaders to AddressOfEntryPoint. More info here.

I didn’t end up doing this trick, because the size of the binary was already very small, and I wanted to fill up each part of it until the very end.

Final Binary

So, armed with all of this information, this is the binary I ended up with.

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229


BITS 32
;--- Smallest possible Win10 binary that execs calc.exe --------------------\\--
;
; Compile:
; nasm -f bin -o tiny268_64.exe tiny268_64.asm
; Notice: You might get an error like "Cannot be started 0xc000000005",
; this is fine, just run it again.
; Versions:
; Bypass TinyPE detections Date: 20200330
; Size: 268 bytes (SHA1) c935b155c6cdeacc495d7b695e71f0229e9ce5fc
; First version at 268 bytes Date: 20200329
; Size: 268 bytes (SHA1) 60e2c89d391052cc00145d277883e7feb6b67dd0 
; Original Version without optimization Date: 20200328
; Size: 304 bytes (SHA1) bb59448a94acee171ea574e3a50dd6a2b75f4965 
;
; Breakdown of Sections - Listed in comments of the header 0x00:0x7C
;
; MC-- MD-- ME-- MF-- MG-- MH--
; MA-- MB-- PA------- PB-- PC-- PD-------
; 00000000: 4d5a 0001 5045 0000 4c01 0000 31f6 83ec MZ..PE..L...1...
; MI-- MJ-- MK-- ML-- MM-- MN-- MO-------
; PE------- PF------- PG-- PH-- OA-- OBOC
; 00000010: 1856 6a63 9090 eb06 6000 0301 0b01 6668 .Vjc....`.....fh
; MO------- MP-- MQ-- MR-----------------
; OD------- OE------- OF------- OG-------
; 00000020: 7865 6857 696e 4589 65fc eb22 7c00 0000 xehWinE.e.."|...
; MR--------------------------- MS-------
; OH------- OI------- OJ------- OK-------
; 00000030: 0000 0000 0000 0000 0000 4000 0400 0000 ..........@.....
; OL------- OM-- ON-- OO-- OP-- OQ-- OR--
; 00000040: 0400 0000 8b5b 0c8b 5b14 eb10 0500 648b .....[..[.....d.
; OS------- OT------- OU------- OV-------
; 00000050: 5e30 ebf0 8000 0000 7c00 0000 8b1b eb10 ^0......|.......
; OW-- OX-- OY------- OZ------- O1-------
; 00000060: 0200 0004 0000 1000 0010 0000 0000 1000 ................
; O2------- O3------- O4------- CK-------
; 00000070: 8b1b 8b5b 10eb 07c3 0000 0000 eb8e 895d ...[...........]
; 00000080: f88b 433c 01d8 8b40 7801 d88b 4824 01d9 ..C<...@x...H$..
; 00000090: 894d f48b 7820 01df 897d f08b 501c 01da .M..x ...}..P...
; 000000a0: 8955 ec8b 5814 31c0 8b55 f88b 7df0 8b75 .U..X.1..U..}..u
; 000000b0: fc31 c9fc 8b3c 8701 d766 83c1 08f3 a674 .1...<...f.....t
; 000000c0: 0a40 39d8 72e5 83c4 26eb ac8b 4df4 89d3 .@9.r...&...M...
; 000000d0: 8b55 ec66 8b04 418b 0482 01d8 31d2 5268 .U.f..A.....1.Rh
; 000000e0: 2e65 7865 6863 616c 6368 6d33 325c 6879 .exehcalchm32\hy
; 000000f0: 7374 6568 7773 5c53 6869 6e64 6f68 433a stehws\ShindohC:
; 00000100: 5c57 89e6 6a0a 56ff d083 c446 \W..j.V....F
; 
; Places code could be executed ------------------------------------------------
; Range Len Note
; 0x0C:0x18 12 jump0
; 0x1E:0x2C 14 jump1
; 0x44:0x4C 8 jump3
; 0x4E:0x54 6 jump2
; 0x5C:0x60 4 jump4 
; 0x70:0x78 8 jump5 + endy
;--- Start of MZ Header --------------------------------------------------------
mzhdr:
 dw "MZ" ; 0x00 ; [MA] e_magic
 dw 0x100 ; 0x02 ; [MB] e_cblp This value will bypass TinyPE detections!
;--- Start of PE Header --------------------------------------------------------
pesig:
 dd "PE" ; 0x04 ; [MC] e_cp [MD] e_crlc [PA] PE Signature
pehdr:
 dw 0x014C ; 0x08 ; [ME] e_cparhdr [PB] Machine (Intel 386)
 dw 0 ; 0x0A ; [MF] e_minalloc [PC] NumberOfSections (0 haha)
jump0: ; WinExec Setup Part 1 --------------------------------------------------
 xor esi,esi ; 0x0C ; 31f6 ; Clear ESI [MG] e_maxalloc [PD] TimeDateStamp 
 sub esp,0x18 ; 0x0E ; 83ec18 ; Make room for our bullshit [MH] e_ss [MI] e_sp
 push esi ; 0x11 ; 56 ; Null [PE] PointerToSymbolTable
 push 0x63 ; 0x12 ; 6a63 ; "c" [MJ] e_csum 
 nop ; 0x14 ; 90 ; spacer [MK] e_ip [PF] NumberOfSymbols 
 nop ; 0x15 ; 90 ; spacer 
 jmp jump1 ; 0x16 ; eb06 ; [ML] e_cs
 dw 0x60 ; 0x18 ; [MM] e_lsarlc [PG] SizeOfOptionalHeader
 dw 0x103 ; 0x1A ; [MN] e_ovno [PH] Characteristics
;--- Start of Optional Header --------------------------------------------------
 dw 0x10B ; 0x1C ; [MO] e_res [OA] Magic (PE32)
jump1: ; WinExec Setup Part 2 --------------------------------------------------
 push word 0x6578 ;0x1E; 66687865 ; "ex" [OB] MajorLinkerVersion 
 ; [OC] MinorLinkerVersion [OD] SizeOfCode
 push 0x456e6957 ;0x22; 6857696e45 ; "EniW"
 ; [MP] e_oemid [MQ] e_oeminfo [OE] SizeOfInitializedData
 mov dword [ebp-4], esp ;0x27; 8965fc; Save our stack pointer addr for later 
 ; [MR] e_res2 [OF] SizeOfUninitializedData
 jmp jump2 ; 0x2A ; eb22 
 dd 0x7C ; 0x2C ; [OG] AddressOfEntryPoint (Could make a label pointer)
 dd 0 ; 0x30 ; [OH] BaseOfCode
 dd 0 ; 0x34 ; [OI] BaseOfData
 dd 0x400000 ; 0x38 ; [OJ] ImageBase
 dd 4 ; 0x3C ; [MS] e_lfanew [OK] SectionAlignment
 dd 4 ; 0x40 ; [OL] FileAlignment
jump3: ; PEB Parse Part 2 ------------------------------------------------------
 mov ebx, [ebx+0xc] ; 0x44 ; 8b5b0c ; Get addr of PEB_LDR_DATA
 ; [OM] MajorOperatingSystemVersion
 ; [ON] MinorOperatingSystemVersion
 mov ebx, [ebx+0x14] ; 0x47 ; 8b5b14 ; InMemoryOrderModuleList first entry
 ; [OO] MajorImageVersion
 jmp jump4 ; 0x4A ; eb10
 ; [OP] MinorImageVersion
 dw 5 ; 0x4C ; [OQ] MajorSubsystemVersion
jump2: ; PEB Parser Part 1 -----------------------------------------------------
 mov ebx, [fs:0x30+esi] ; 0x4E ; 648b5e30 ; Get PEB addr, FS holds TEB address
 ; [OR] MinorSubsystemVersion
 ; [OS] Win32VersionValue
 jmp jump3 ; 0x52 ; ebf0
 dd 0x80 ; 0x54 ; [OT] SizeOfImage
 dd 0x7C ; 0x58 ; [OU] SizeOfHeaders
jump4: ; PEB Parser Part 3 -----------------------------------------------------
 mov ebx, [ebx] ; 0x5C ; 8b1b ; Get address of ntdll.dll entry [OV] CheckSum
 jmp jump5 ; 0x5E ; eb10 
 dw 2 ; 0x60 ; [OW] Subsystem (Win32 GUI)
 dw 0x400 ; 0x62 ; [OX] DllCharacteristics 
 dd 0x100000 ; 0x64 ; [OY] SizeOfStackReserve 
 dd 0x1000 ; 0x68 ; [OZ] SizeOfStackCommit 
 dd 0x100000 ; 0x6C ; [O1] SizeOfHeapReserve 
jump5: ; PEB Parser Part 4 -----------------------------------------------------
 mov ebx, [ebx] ; 0x70 ; 8b1b ; Get address of kernel32.dll list entry
 ; [O2] SizeOfHeapCommit 
 mov ebx, [ebx+0x10] ; 0x72 ; 8b5b10 ; Get kernel32.dll base address 
 ; [O3] LoaderFlags 
 jmp jump6 ; 0x75 ; eb07
endy:
 ret ; 0x77 ; c3 ; Used to end the program 
 dd 0 ; 0x78 ; [O4] NumberOfRvaAndSizes ; Note - this is touchy 
codesec: ; 0x7C - Start of code -----------------------------------------
 ; MachineCode ; Description 
 jmp jump0 ; eb8e ; Jump back to header to begin execution
jump6:
;--- Grab kernel32.dll base addr -----------------------------------------------
; This piece of code grabs the Thread Environment Block structure's address from
; the FS segment register to locate the Process Environment Block structure 
; stored inside.
; Then it grabs the pointer to the PEB_LDR_DATA structure so it can grab the 
; InMemoryOrderModuleList, which tells us about DLLs in memory.
; Then it grabs the ntdll.dll entry in this list which helps us find the next
; entry, kernel32.dll. The base address of kernel32.dll is stored at 0x10 in 
; the entry.
; 
; [WORKFLOW]
; TEB
; @0x30 PEB
; --> 0x0C PEB_LDR_DATA
; --> 0x14 InMemoryOrderModuleList
; --> 0x00 ntdll.dll entry address
; --> 0x00 kernel32.dll list entry address
; --> 0x10 kernel32.dll base address !!
; Note that most of this is done in the header, see jump2 - jump5
; PEB Parser Part 5 ------------------------------------------------------------
 mov [ebp-0x8], ebx ; 895df8 ; kernel32.dll base address
;--- Finding WinExec address
; This section weaves it's way through the headers of kernel32.dll. 
; Based on a non-fucky PE like this one, we can sort of rely on certain things
; being where we expect them.
; First, the Relative Virtual address of the PE signature is loaded from ebx.
; EAX then becomes the address that we're calculating from.
; 
; The addresses of our structures are calculated using the base address of the 
; PE signature in EAX + it's offset within that structure, and then added to the
; base address stored in EBX. These are then moved to the stack.
; 
 mov eax,dword [ebx+0x3c] ; 8b433c ; RVA of PE signature
 add eax,ebx ; 01d8 ; PE sig addr = base addr + RVA of PE sig
 mov eax,dword [eax+0x78] ; 8b4078 ; RVA of Export Table
 add eax,ebx ; 01d8 ; Address of Export Table

 mov ecx,dword [eax+0x24] ; 8b4824 ; RVA of Ordinal Table
 add ecx,ebx ; 01d9 ; Address of Ordinal Table
 mov dword [ebp-0xc],ecx ; 894df4 ; Put on the stack

 mov edi,dword [eax+0x20] ; 8b7820 ; RVA of Name Pointer Table
 add edi,ebx ; 01df ; Address of Name Pointer Table
 mov dword [ebp-0x10],edi ; 897df0 ; Put on the stack

 mov edx,dword [eax+0x1c] ; 8b501c ; RVA of Address Table
 add edx,ebx ; 01da ; Address of Address Table
 mov dword [ebp-0x14],edx ; 8955ec ; Put on the stack

 mov ebx,dword [eax+0x14] ; 8b5814 ; Number of exported functions
;--- Using the Name Pointer Table
; This part loops through the Name Pointer Table and compares entries to what
; we're looking for: "WinExec".
; The number of entries is counted using EAX, and once the WinExec entry is 
; found, the entry in the ordinal table is found using the count. See 'locate'
 xor eax,eax ; 31c0 ; EAX will be our entry counter
 mov edx, dword [ebp - 8] ; 8b55f8 ; EDX = kernel32.dll base address
loopy:
 mov edi,dword [ebp-0x10] ; 8b7df0 ; edi = Address of Name Pointer Table
 mov esi,dword [ebp-4] ; 8b75fc ; esi = "WinExec\x00"
 xor ecx,ecx ; 31c9 ; ECX = 0
 cld ; fc ; Clear direction flag 
 ; Strings now go left->right
 mov edi,dword [edi+eax*4] ; 8b3c87 ; Name Pointer Table entries are 4 bytes,
 ; edi (NPT addr) + eax (num entries) * 4
 add edi,edx ; 01d7 ; EDI = NPT addr + kernel32.ddl base addr
 add cx,0x8 ; 6683c108 ; Length of "WinExec"
 repe cmpsb ; f3a6 ; Compare the first 8 bytes in esi and edi
 jz locate ; 740a ; Jump if there's a match.

 inc eax ; 40 ; Increment entry counter
 cmp eax,ebx ; 39d8 ; Check if the last function was reached
 jb loopy ; 72e5 ; If not the last one, continue
 add esp,0x26 ; 83c426 ; Move stack away from our mess
 jmp endy ; eb41 ; If nothing found, return
;--- Executing our function
; Once we're here, we know the position of WinExec within the ordinal table
; of kernel32.dll, so now all that's left is to call the function.
; We use all of our saved addresses on the stack for this.
locate:
 mov ecx, [ebp-0xc] ; 8b4df4 ; ECX = Address of Ordinal Table
 mov ebx, edx ; 89d3 ; EBX = kernel32.dll base address
 mov edx, [ebp-0x14] ; 8b55ec ; EDX = Address of Address Table
 mov ax, [ecx+eax*2] ; 668b0441; AX = ordinal addr + (ordinal num * 2)
 mov eax, [edx+eax*4] ; 8b0482 ; EAX = Addr table addr + (ordinal * 4)
 add eax,ebx ; 01d8 ; EAX = WinExec Addr = 
 ; = kernel32.dll base address + RVA of WinExec
 xor edx,edx ; 31d2 ; We need a 0...
 push edx ; 52 ; ...for the end of our string
 push 0x6578652e ; 682e657865 ;
 push 0x636c6163 ; 6863616c63 ;
 push 0x5c32336d ; 686d33325c ;
 push 0x65747379 ; 6879737465 ;
 push 0x535c7377 ; 6877735c53 ;
 push 0x6f646e69 ; 68696e646f ;
 push 0x575c3a43 ; 68433a5c57 ;
 mov esi,esp ; 89e6 ; ESI="C:\Windows\System32\calc.exe"
 push 0xa ; 6a0a ; window state SW_SHOWDEFAULT
 push esi ; 56 ; "C:\Windows\System32\calc.exe"
 call eax ; ffd0 ; WinExec
 add esp,0x46 ; 83c446 ; Clear the stack

The binary starts with a short jump back into the headers, and then leaps around to set up WinExec on the stack and begin to parse the PEB, before jumping back to the main code section and continuing execution there.

If WinExec isn’t found, it returns back into the headers to execute the final ret instruction.

The payload ends kind of abruptly. You could simply just not include the last instruction after call eax, but I didn’t have anything else to put there so I just left it to keep the size.

What do I use this for?

You can modify the last portion of code in the locate label to push whatever program you want to execute, in this case "C:\Windows\System32\calc.exe", onto the stack, and execute something else. You’ll have to make sure you allocate enough stack space for yourself and place arguments in the right place if they are required.

You can use powershell or some lolbins or whatever elite FUD 100% battle tested “plz don’t upload to VT or ur ded!!” binary loader to execute a base64 encoded version of this binary.

Check out my other small binaries on Github!

Download the POC binary here.

Payload generator for WinExec method

Shoutouts

Thanks to dnz, readme, xehle, secfarmer, remy, Ange Albertini, Iliya Dafchev, and everyone in the Binary Analysis and Exploit Dev chans I dump crap into.

Intro to Firmware Analysis (PancakesCon2020)

Sun, 22 Mar 2020 12:00:00 -0400

Establishing the goals for doing firmware analysis is important, ask yourself the following:

Are you looking for modify functionality?
Are you looking for vulns?
Are you looking for sensitive info?
Are you looking for protocols?
Do you just want to understand how it works?

Here is a good set of basic questions to try and answer throughout analysis.

Basic Questions

What is the target device used for?
What is the underlying processor arch
What features does it support?
What type of operating system runs on the device?
- Is it embedded Linux/Windows?
- Is it an RTOS?
- Is it some bare bones application code?
What other chips are onboard?
What type of programs run on it?

Getting a hold of firmware

Vendor Websites
OSINT
Analyzing fw updater apps
PCAPS
Directly interfacing with hardware
- Talk: Hardware Hacking for the Masses (and you!)

Firmware File

How is firmware updated?
What is the file format of the firmware?
Is it encrypted?
Is the firmware a full image, or just a sort of patch?

Interaction

How do you interact with the device as a user?
How would you interact with the device as a developer?
What inputs and outputs might this device have?
How does the device firmware interact with hardware devices and non-volatile memory?

Vulns and Prior Research

Are there known vulnerabilities for this device or any of technologies used?
Are there any write ups / blog posts / data sheets about this device?

Techniques

Binary Information and RE

radare2 / rabin2 / all the radare2 suite

File Carving

binwalk + all the filesystem unpackers

Emulation

Binary Diffing

Firmware used in this talk:

WNAP320 Firmware Version 2.0.3

Further Resources

Inspiration

30C3: Even More Tamagotchis Were Harmed in the Making of this Presentation

GDB Cheatsheet

Sat, 01 Feb 2020 12:00:00 -0400

Here are some notes and things I’ve referenced for gdb.

I highly recommend using the gef extension for gdb: https://github.com/hugsy/gef

Unsorted

https://klatz.co/ctf-blog/stdin-to-gdb

Basics

Here are some of the most basic gdb commands.

Start the program with arguments

gdb --args ./myprogram -f myfile

Command	Description
starti	Start at the first instruction
stepi	Step 1 assembly instruction
break *0x400000	Set a breakpoint on address 0x400000
continue	Continue execution, will stop at breakpoints
vmmap	(gef only) Show process memory map
hexdump byte –size 256 0x400000	(gef only) See a hex dump of bytes at a address 0x400000
p *object	Show details of object
search-pattern 0x41414141	(gef only) Search for bytes \x41\x41\x41\x41 (“AAAA”) in memory

More Info:

https://azeria-labs.com/debugging-with-gdb-introduction/

Remote GDB

You can connect to programs on different machines using remote GDB. You can also use it to connect to local programs that support remote GDB like QEMU.

https://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.html

Commands

Adapted this guide from a cheatsheet I found but lost the link to Related cheat sheet: gef

More important commands have !

Startup

Command	Description
gdb -help	print startup help, show switches
gdb object	! normal debug
gdb object core	! core debug (must specify core file)
gdb object pid	attach to running process
gdb	use file command to load object

Help

Command	Description
help	! list command classes
help running	list commands in one command class
help run	bottom-level help for a command “run”
help info	list info commands (running program state)
help info line	help for a particular info command
help show	list show commands (gdb state)
help show commands	specific help for a show command

Breakpoints

Command	Description
break main	! set a breakpoint on a function
break 101	! set a breakpoint on a line number
break basic.c:101	! set breakpoint at file and line (or function)
break *0xaddress	! Break on an address
info breakpoints	! show breakpoints
delete 1	! delete a breakpoint by number
delete	delete all breakpoints (prompted)
clear	delete breakpoints at current line
clear function	delete breakpoints at function
clear line	delete breakpoints at line
disable 2	turn a breakpoint off, but don’t remove it
enable 2	turn disabled breakpoint back on
tbreak function	line
commands break-no … end	set gdb commands with breakpoint
ignore break-no count	ignore bpt N-1 times before activation
condition break-no expr	break only if condition (expr/expression) is true
condition 2 i == 20	example: break on breakpoint 2 if i equals 20
watch expression	set software watchpoint on variable
info watchpoints	show current watchpoints

Running the program

Command	Description
set step-mode on	! This stops at the first instruction of a function
starti	! Go to the first instruction to execute
run	! run the program with current arguments
run args redirection	! run with args and redirection
set args args…	set arguments for run
show args	show current arguments to run
cont	! continue the program
step	! single step the program; step into functions
stepi	! step to next instruction
step count	single step \fIcount\fR times
next	! step but step over functions
next count	next \fIcount\fR times
CTRL-C	! actually SIGINT, stop execution of current program
attach process-id	! attach to running program
detach	! detach from running program
finish	! finish current function’s execution
kill	kill current executing program

Stack backtrace

Command	Description
x/100x $sp	! print 100 bytes from the stack pointer
bt	! print stack backtrace
frame	show current execution position
up	move up stack trace (towards main)
down	move down stack trace (away from main)
info locals	! print automatic variables in frame
info args	print function parameters

Browsing source

Command	Description
list 101	! list 10 lines around line 101
list 1,10	! list lines 1 to 10
list main	! list lines around function
list basic.c:main	! list from another file basic.c
list -	! list previous 10 lines
list *0x22e4	list source at address
cd dir	change current directory to \fIdir\fR
pwd	print working directory
search regexpr	forward current for regular expression
reverse-search regexpr	backward search for regular expression
dir dirname	add directory to source path
dir	reset source path to nothing
show directories	show source path

Browsing Data

Command	Description
print expression	! print expression, added to value history
print/x expressionR	! print in hex
print array[i]@count	artificial array - print array range
print $	print last value
print *$->next	print thru list
print $1	print value 1 from value history
print ::gx	force scope to be global
print ‘basic.c’::gx	global scope in named file (>=4.6)
print/x &main	print address of function
x/countFormatSize address	low-level examine command
x/x &gx	print gx in hex
x/4wx &main	print 4 longs at start of \fImain\fR in hex
x/gf &gd1	print double
help x	show formats for x
info locals	! print local automatics only
info functions regexp	print function names
info variables regexp	print global variable names
ptype name	! print type definition
whatis expression	print type of expression
set variable = expression	! assign value
display expression	display expression result at stop
undisplay	delete displays
info display	show displays
show values	print value history (>= gdb 4.0)
info history	print value history (gdb 3.5)

Object File Manipulation

Command	Description
file object	load new file for debug (sym+exec)
file	discard sym+exec file info
symbol-file object	load only symbol table
exec-file object	specify object to run (not sym-file)
core-file core	post-mortem debugging

Signal Control

Command	Description
info signals	print signal setup
handle signo actions	set debugger actions for signal
handle INT print	print message when signal occurs
handle INT noprint	don’t print message
handle INT stop	stop program when signal occurs
handle INT nostop	don’t stop program
handle INT pass	allow program to receive signal
handle INT nopass	debugger catches signal; program doesn’t
signal signo	continue and send signal to program
signal 0	continue and send no signal to program

Machine-level Debug

Command	Description
info registers	print registers sans floats
info all-registers	print all registers
print/x $pc	print one register
stepi	single step at machine level
si	single step at machine level
nexti	single step (over functions) at machine level
ni	single step (over functions) at machine level
display/i $pc	print current instruction in display
x/x &gx	print variable gx in hex
info line 22	print addresses for object code for line 22
info line *0x2c4e	print line number of object code at address
x/10i main	disassemble first 10 instructions in \fImain\fR
disassemble addr	dissassemble code for function around addr

History Display

Command	Description
show commands	print command history (>= gdb 4.0)
info editing	print command history (gdb 3.5)
ESC-CTRL-J	switch to vi edit mode from emacs edit mode
set history expansion on	turn on c-shell like history
break class::member	set breakpoint on class member. may get menu
list class::member	list member in class
ptype class	print class members
print *this	print contents of this pointer
rbreak regexpr	useful for breakpoint on overloaded member name

Miscellaneous

Command	Description
define command … end	define user command
*(gdb) RETURN	repeat last command
*(gdb) shell command args	execute shell command
*(gdb) source file	load gdb commands from file
*(gdb) quit	quit gdb

GDB Scripting

The following example is from https://stackoverflow.com/questions/4060565/how-to-script-gdb-with-python-example-add-breakpoints-run-what-breakpoint-d

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


class DebugPrintingBreakpoint(gdb.Breakpoint):
 debugging_IDs = frozenset({37, 153, 420})
 def stop(self):
 top = gdb.newest_frame()
 someVector = top.read_var('aVectorVar')
 # Access the begin() & end() pointer of std::vector in GNU Standard C++ lib
 first = someVector['_M_impl']['_M_start']
 last = someVector['_M_impl']['_M_finish']
 values = []
 while first != last:
 values.append(int(first.dereference()['intID']))
 first = first + 1
 if not set(values) & debugging_IDs:
 return False # skip: none of the items we're looking for can be found by ID in the vector on the stack
 print("Found other accompanying IDs: {}".format(values))
 return True # drop to gdb's prompt
# Ensure shared libraries are loaded already
gdb.execute("start")
# Set our breakpoint, which happens to reside in some shared lib, hence the "start" previously
DebugPrintingBreakpoint("source.cpp:42")
gdb.execute("continue")

You can execute this script from gdb’s prompt like this:

(gdb) source script.py

Or from the command-line:

$ gdb --command script.py ./executable.elf

Events

According to the Events doc, this is an event handler:

1
2
3
4
5
6
7
8


def exit_handler (event):
 print ("event type: exit")
 if hasattr (event, 'exit_code'):
 print ("exit code: %d" % (event.exit_code))
 else:
 print ("exit code not available")

gdb.events.exited.connect (exit_handler)

The types of events are

events.cont
events.exited
events.stop
events.new_objfile
events.free_objfile
events.clear_objfile
events.inferior_call
events.memory_changed - This one looks cool, any memory writes
events.register_changed - nice!
events.breakpoint_created
events.breakpoint_modified
events.breakpoint_deleted
events.before_prompt
events.new_inferior
events.inferior_deleted
events.new_thread
events.thread_exited
events.gdb_exiting
events.connection_removed
events.new_progspace
events.free_progspace There are a bunch!

The stop_signal and exit_code Event attributes may have changed. They don’t seem to work anymore.

I got the stop hook writing to a file, as well as other hooks that update “gdb_status.txt”. The gdb.SignalEvent thing doesn’t seem to fire though…

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


def signal_stop_handler (event):
 if (isinstance (event, gdb.StopEvent)):
 print ("event type: stop")
 with open("gdb_status.txt", "w") as f:
 f.write("Stopped\n")
 f.close()
 if (isinstance (event, gdb.SignalEvent)):
 print ("stop reason: signal")
 print ("stop signal: %s" % (event.stop_signal))
 if ( event.inferior_thread is not None) :
 print ("thread num: %s" % (event.inferior_thread.num))

gdb.events.stop.connect(signal_stop_handler)

TODO: Update this with real info hahah

WinDbg Cheatsheet

Sat, 01 Feb 2020 12:00:00 -0400

References

Display Bytes

Command	Description
db esp	Display bytes from address in ESP as bytes with ASCII chars on the side (hex dump)
db kernel32!WriteFile	Display bytes in a function
dw esp	Display bytes from address in ESP as words (2 bytes)
dW esp	Display bytes from address in ESP as words with ASCII chars on the side like in db
dd esp	Display bytes from address in ESP as double words (4 bytes)
dd 771bab89	Display bytes from address 0x771bab89 as double words (4 bytes)
dc esp	Display bytes from address in ESP as dobule words with ASCII chars on the side like in db
dq 00faf974	Display bytes from address in ESP as quad words (8 bytes)
da esp	Display bytes from address in ESP as ASCII (This is ASCII with no hex dump)
dd poi(esp)	Display dwords from the pointer that the address ESP points to.
dW KERNELBASE+0x40	Display dwords with ASCII chars at KERNELBASE + 0x40
dd esp L4	Display 4 double words from address in ESP
dW KERNELBASE L2	Display 2 words with ASCII chars from KERNELBASE
db KERNELBASE L2	Display 2 bytes with ASCII chars from KERNELBASE

Program Control

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/controlling-the-target

Command	Description
g	Go. Continues execution
gu	Execute until function is complete.
p	Step. Step Over. If a function call it just keeps going. F10
pa	Step to Address.
pc	Step to Next Call.
pct	Step to Next Call or Return.
ph	Step to Next Branching Instruction. Any branches, calls, rets, or syscalls
pt	Step to Next Return. Go to the end of the function
t	Trace. Step Into. If a function call it steps into it. F8, F11
ta	Trace to address. See docs for full info on this.

Breakpoints

Command	Description
bl	List breakpoints
bd 1	Disable breakpoint 1
bc 2	Clear breakpoint 2
bp wsock32!recv	Break on wsock32!recv
bp WS2_32!recv	Break on WS2_32!recv
br 0xbaf000	Break on reading address 0xbaf000
bw 0xbaf000	Break on writing to address 0xbaf000
be 0xbaf000	Break on executing address 0xbaf000

Hardware Breakpoints

There are only 4 available
Syntax: ba <type of acces r|w|e> <size of memory access> <memory address or symbol>

ba e 1 kernel32!WriteFile – Set a hardware breakpoint when kernel32!WriteFile executes

Symbols

Command	Description
.reload /f	Reload symbols
x WS2_32!recv	Search for symbol. Displays address.
x WS2_32!rec*	Search for symbol with wildcard. Will show recv and recvfrom.
!drvobj name	Find driver
!devobj name	Find device object
!devhandles handle	Find app using driver

Examine Code

Command	Description
u 761ae7b2	Unassemble at address 0x761ae7b2
u kernel32!GetCurrentThread	Unassemble kernel32!GetCurrentThread
u kernel32!GetCurrentThread+0x2	Unassemble kernel32!GetCurrentThread+0x2
u kernel32!GetCurrentThread+0x2 L2	Unassemble kernel32!GetCurrentThread+0x2 and display 2 lines

Dump Structures

Command	Description
k	Dump Call Stack
lm	Show loaded modules
lm m kernel*	Show loaded modules beginning with “kernel”
lmDva 0x724a0000	Get info on the module at address 0x724a0000
ln 77c94d10	Show the closest symbol to the address 0x77C94D10
r	Dump all registers
r ecx	Dump value in ECX
r ecx=41414141	Write 0x41414141 to ECX
!teb	Dump Thread Environment Block
!peb	Dump Process Environment Block
!vadump	Dump memory pages/info
!heap	Dump heap info

Display Type (dt)

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/dt--display-type-

Command	Description
dt ntdll!_TEB	dump the Thread Env Block
dt -r ntdll!_TEB @$teb	-r is recursively dumping structs, @$teb is a pseudo register that represents $teb
?? sizeof(ntdll!_TEB)	Get the size of a structure

Display specific fields:

dt ntdll!_TEB @$teb ThreadLocalStoragePointer

Writing to Memory

Write ascii with ea, write unicode with eu

Command	Description
dd esp L1	Show dword at esp
ed esp 41414141	Write 0x41414141 to pointer in ESP
dd esp L1	Show dword at esp
ea esp “Haha”	Write “Haha” to the pointer at ESP
da esp	Show ASCII from bytes at ESP
eu esp “Ha”	Write “Ha” UTF-16, which is also 4 bytes
da esp	Show ASCII from bytes at ESP

Searching Memory Space

See reference for way more info https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/s--search-memory-

Four parameters

Memory type (if none then it defaults to bytes) -d DWORD -a ASCII -u Unicode
Starting Point
Length of Memory
Pattern

Command	Description
ed esp 41414141	Write 0x41414141 to pointer in ESP
s -d 0 L?80000000 41414141	Search process image for dword 0x41414141
s -d 77a40000 77d00000 41414141	Search address range for dword 0x41414141
s 77a40000 77a60000 41 41 41 41	Search address range for 0x41414141 as bytes

Examples:

Search for DOS header:

s -a 0 L?80000000 "This program cannot be run in DOS mode"

Search for the string “SCADA” as unicode:

s -u 0 L?80000000 "SCADA"
- Example Output: 53 00 43 00 41 00 44 00 41 00 00 00

Expressions

The default representation of numbers in Windbg is hex.

See all the formats of a hex number with .formats

0:000> .formats 41414141
Evaluate expression:
Hex: 41414141
Decimal: 1094795585
Octal: 10120240501
Binary: 01000001 01000001 01000001 01000001
Chars: AAAA
Time: Fri Sep 10 01:53:05 2004
Float: low 12.0784 high 0
Double: 5.40901e-315

? evaluates an expression.

0:000> ? 77269bc0 - 77231430
Evaluate expression: 231312 = 00038790
0:000> ? 77269bc0 >> 18
Evaluate expression: 119 = 00000077

Doing the same thing in decimal needs 0n as the prefix.

0:007> ? 0n1000 - 0n250
Evaluate expression: 750 = 000002ee

Binary needs 0y prefix. This is 0x41 + 0x41

0:007> ? 0y01000001 + 0y01000001
Evaluate expression: 130 = 00000082

User defined psuedo registers $t0 to $t19. Useful in scripts.

r@$t0 = 41414141 -- Assign value to $t0
r $t0 -- Examine value in $t0

threatland/TL-BOTS

Wed, 02 Oct 2019 12:00:00 -0400

https://github.com/threatland/TL-BOTS

netspooky/inhale

Sat, 14 Sep 2019 12:00:00 -0400

https://github.com/netspooky/inhale

threatland/TL-TROJAN

Sat, 24 Aug 2019 12:00:00 -0400

https://github.com/threatland/TL-TROJAN

Cisco SMI: Still Tippin'

Sat, 10 Aug 2019 12:00:00 -0400

Intro

Configuration management is hard, expecially at scale. Cisco IOS and IOS XE software has a feature which allows for simpler deployment of a new switch, allowing for easy plug-and-play configuration. The feature is known as Cisco Smart Install (SMI), and makes it less painful to configure new switches.

The core of Cisco SMI is a network of Smart Install devices, a director, and any number of clients. The director acts as the manager for images and device configurations for clients. When a switch is brought online, the director will detect it, and begin configuring the device according to specifications. The key feature of this is that this network of SMI device is ad hoc, and as a result, there is no authentication, and implicit trust given by clients.

Back in 2017, there had been a number of vulnerabilities disclosed regarding Cisco Smart Install, leading to several CVEs and PoCs for exploiting an exposed SMI service. These allowed for DoS, configuration changes, and even a full rewrite of the firmware image on the device.

In 2018, a buffer overflow vulnerability was disclosed in Cisco SMI, leading to remote code execution on a given router. Cisco came out with an advisory about the vulnerability, and it was given a CVE. This upgraded the severity from “protocol misuse” to full blown vulnerability.

In April 2018, a US-CERT advisory was released regarding the discovery of Russian State-Sponsored actors targeting this specific vulnerability, and using it to attack critical infrastructure.

This vulnerability is easily exploitable, is being actively exploited, and can have devastating effects on networks for organizations, governments, and entire countries.

What’s out there?

Given all of this information, how many vulnerable devices do you think are still out there in the wild?

To put it simply…a lot. The shodan search “Cisco Smart Install Client active” yields over 50,000 results as of this writing.

Some of these results come and go, as devices are configured and quickly locked down. Many of them stay online for a while without the knowledge of the admins of the network.

What have I found?

I have found and disclosed a number of vulnerable Cisco switches to various organizations. These include government, defense, and tier-1 network targets, all of whom have had vulnerable devices sitting on their networks. This ultimately led me to writing about the lasting effects of this vulnerability for organizations who may be unaware, and researchers who are interested in network infrastructure.

What are the implications?

The routers with vulnerabilities that I have reported have typically been ones that are connected to things that appear to be on the sensitive side in terms of overall impact. If a malicious actor wanted to exploit these, there are a few approaches they could take.

The first stage would involve identifying the target. Connecting to port 4786 will inform an attacker if the SMI banner is visible. From there, the SIET tool can be used to determine if the target is vulnerable.

The following is a list of possible attack vectors for a Cisco SMI device once it is determined to be vulnerable.

DoS

The simplest thing an attacker can do is a Denial of Service. This can be done in a number of ways, including tampering with device configurations, and issuing commands to shut down the device.

The impact of this is immediate, anything that the router is responsible for routing will no longer have access to the internet.

Change Configuration

Changing the device configuration is also another trivial attack vector. The configuration files contain a lot of information. You can find network mappings, acls, passwords, certificates, and other parameters relevant to the network in a given config file.

Changes to this can be used for all sorts of nefarious purposes. Compromising certificates and keys, hijacking routing, and locking the administrators out of the switch.

GRE Tunnel

GRE tunnels can easily be configured by modifying the device configuration. GRE tunnels in hijacked SMI routers have been used to reroute DNS queries to an attackers infrastructure. Router level DNS hijacking on sensitive networks can have devastating effects that are not easy to detect.

Malicious Firmware

A feature of SMI is the ability for a SMI director to load a new firmware image onto a client device. There are many implications for loading a new image. While this might be the most challenging thing to pull off, it could be the most costly in terms of a persistence.

Remote Code Execution

An RCE is possible through a stack overflow when sending a discovery message to a given client. The size of the message is not properly checked by the device, leading to remote code execution. More information on the technical details and a PoC can be found here.

Why should I care?

This vulnerability has been known for over two years, and it is still quite common. Even in the wake of US-CERT advisories, vendor patches, and tools built to exploit this, many large organizations in all sectors continue to deploy vulnerable switches.

Taking a look at the Greynoise visualizer tool, we can get a better look at how many people are scanning for these devices as well.

There is still quite a lot of activity for this service, and some of my own honeypots have picked up activity on this port. Since there is widespread tooling for exploiting SMI, it’s likely that most attackers are simply scaling these tools.

What does an attack look like?

Depending on the tooling used, your typical attack will look something like this:

The first message is the command configure tftp-server nvram:startup-config, which attempts to start up the tftp server on the router with the system’s configuration file.

The second message is attempting to copy the running configuration file into flash memory, and then transfer it to a remote server over tftp. This command sequence is straight out of the SIET tool’s get-config option.

What can we do about it?

Disable SMI if a switch is on a public network.
Upgrade your switch.
Report vulnerable devices on sensitive networks if you find them.

greetz

As always, thanks to my buddies at ThugCrowd for letting me rant and confirm my suspicions. Shoutout hermit, dnz, notdan, readme, sshell, protoxin, phreck, hexadecim8, casey @ bugcrowd, hackerone, Level3, and all the orgs who didn’t threaten me when I came to them with this information.

Special shoutout goes to Andrew Morris of GreyNoise for letting me use their sweet visualizer while it was still in development while researching this.

threatland/TL-FRAUD

Mon, 05 Aug 2019 12:00:00 -0400

https://github.com/threatland/TL-FRAUD

netspooky/jloot

Sun, 14 Jul 2019 12:00:00 -0400

This script iterates over endpoints on a self-hosted Jira instance and downloads them. Uses yara to find interesting files.

Based on a WONTFIX issue with Atlassian.

https://github.com/netspooky/jLoot

ELF Binary Mangling Pt. 3: Weaponization

Sun, 16 Dec 2018 12:00:00 -0400

Hey y’all, thanks for all the support ! I didn’t realize so many people would think this sort of coding was as cool as I do.

In the previous write up, the concept of binary golf was established, executing a binary in as few bytes as possible. There’s quite a lot of history in the realm of “size coding”, and extreme assembly optimization. The people who pioneered and later weaponized these approaches did some amazing work to really map out what the limitations of the processor actually are, and some wild ways of making things happen.

There are many resources regarding size coding, shellcode development, and other assembly tricks. In this write up, we are going to explore coding within the size boundary we established for ELF64, and actually make those 84 bytes actually do something.

Establishing Boundaries

Like everything in life, boundaries need to be established in order to understand processes and their effects. Within the boundaries of the ELF64 binary template, there are some key areas where code can safely exist. These are sections where the loader that processes your binary doesn’t seem to mind a bunch of junk data. Due to us already overlaying ELF and program headers, there is a significant challenge to identifying these locations, and reusable structures that we can leverage.

Our main areas of focus today are:

0x04–0x0F: 12 bytes
0x3C-0x39: 4 bytes
0x44–0x47: 4 bytes
0x4C-0x53: 8 bytes

bye.asm

This is the code that we want to execute:

1
2
3
4
5


mov edx, 0x4321fedc ; badcfe2143 
mov esi, 0x28121969 ; be69191228 
mov edi, 0xfee1dead ; bfaddee1fe 
mov al, 0xa9 ; b0a9 
syscall ; 0f05 

In a nutshell, this program executes the reboot syscall with the argument LINUX_REBOOT_CMD_POWER_OFF. This essentially executes the same syscall that your OS calls when you hold down the power off button, but without any of sync or other routines that will allow your system to shutdown gracefully. The syscall is executed by placing magic values and an argument for the specific type of reboot you want to do in the specified registers, and then calling the kernel.

The Process

So how do we load all of this into our 84 byte ELF binary? Let’s take a look at our code, and our binary, and see what we can do.

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117


; 84 byte LINUX_REBOOT_CMD_POWER_OFF Binary Golf
BITS 64
 org 0x100000000
;---------------------+------+------------+------------------------------------------+-----------------------------+----------+
; CODE LISTING | OFFS | ASSEMBLY | CODE COMMENT | ELF HEADER STRUCT | PHDR | 
;---------------------+------+------------+------------------------------------------+-----------------------------+----------+
 db 0x7F, "ELF" ; 0x0 | 7f454c46 | PROTIP: Can use magic as a constant ;) | ELF Magic | |
_start: ;------|------------|------------------------------------------|-----------------------------|----------|
 mov edx, 0x4321fedc ; 0x04 | badcfe2143 | Moving magic values... | ei_class,ei_data,ei_version | |
 mov esi, 0x28121969 ; 0x09 | be69191228 | into their respective places | unused | |
 jmp short reeb ; 0x0E | eb3c | Short jump down to @x4c | unused | |
 dw 2 ; 0x10 | 0200 | | e_type | |
 dw 0x3e ; 0x12 | 3e00 | | e_machine | |
 dd 1 ; 0x14 | 01000000 | | e_version | |
 dd _start - $$ ; 0x18 | 04000000 | | e_entry | |
phdr: ;------|------------|------------------------------------------|-----------------------------|----------|
 dd 1 ; 0x1C | 01000000 | | e_entry | p_type |
 dd phdr - $$ ; 0x20 | 1c000000 | | e_phoff | p_flags |
 dd 0 ; 0x24 | 00000000 | | e_phoff | p_offset |
 dd 0 ; 0x28 | 00000000 | | e_shoff | p_offset |
 dq $$ ; 0x2C | 00000000 | | e_shoff | p_vaddr |
 ; 0x30 | 01000000 | | e_flags | p_vaddr |
 dw 0x40 ; 0x34 | 4000 | | e_shsize | p_addr |
 dw 0x38 ; 0x36 | 3800 | | e_phentsize | p_addr |
 dw 1 ; 0x38 | 0100 | | e_phnum | p_addr |
 dw 2 ; 0x3A | 0200 | | e_shentsize | p_addr |
cya: ;------|------------|------------------------------------------|-----------------------------|----------|
 mov al, 0xa9 ; 0x3C | b0a9 | Load syscall | e_shnum | p_filesz |
 syscall ; 0x3E | 0f05 | Execute syscall | e_shstrndx | p_filesz |
 dd 0 ; 0x40 | 00000000 | Filler, should try to keep as all 0's | | p_filesz |
 mov al, 0xa9 ; 0x44 | b0a9 | Load syscall | | p_memsz |
 syscall ; 0x46 | 0f05 | Execute syscall | | p_memsz |
 dd 0 ; 0x48 | 00000000 | Filler, should try to keep as all 0's | | p_memsz |
reeb: ;------|------------|------------------------------------------|-----------------------------|----------|
 mov edi, 0xfee1dead ; 0x4C | bfaddee1fe | Load magic "LINUX_REBOOT_CMD_POWER_OFF" | | p_align |
 jmp short cya ; 0x51 | ebe9 | Short jmp back to e_shnum/p_filesz @0x3C | | p_align |
 nop ; 0x53 | 90 | Filler, could use this byte for code. | | p_align |
;---------------------+------+------------+------------------------------------------+-----------------------------+----------+
; Note that we are overlaying the ELF Header with the program headers.
; You have 12 bytes minus your short jump from 0x4-0x10 to store code
; Then you have 8 bytes within the program headers at 0x4c for more 
; code, plus e_shentsize and the lower bytes of p_filesz + p_memsz for
; storage and code if you stay within the bounds - still testing.
;
; LINUX_REBOOT_CMD_POWER_OFF
; (RB_POWER_OFF, 0x4321fedc; since Linux 2.1.30). The message
; "Power down." is printed, the system is stopped, and all power
; is removed from the system, if possible. If not preceded by a
; sync(2), data will be lost.
; [ Compile ]
; nasm -f bin -o bye bye.nasm
;
; One Liner 
; base64 -d <<< f0VMRrrc/iFDvmkZEijrPAIAPgABAAAABAAAAAEAAAAcAAAAAAAAAAAAAAAAAAAAAQAAAEAAOAABAAIAsKkPBQAAAACwqQ8FAAAAAL+t3uH+6+mQ > bye;chmod +x bye;sudo ./bye
;
; Syscall reference: http://man7.org/linux/man-pages/man2/reboot.2.html

; [ Full breakdown ]
; --- Elf Header 
; Offset # Value Purpose
; 0-3 A 7f454c46 Magic number - 0x7F, then 'ELF' in ASCII
; 4 B ba 1 = 32 bit, 2 = 64 bit
; 5 C dc 1 = little endian, 2 = big endian
; 6 D fe ELF Version
; 7 E 21 OS ABI - usually 0 for System V
; 8-F F 43be69191228eb3c Unused/padding 
; 10-11 G 0200 1 = relocatable, 2 = executable, 3 = shared, 4 = core
; 12-13 H 3e00 Instruction set
; 14-17 I 01000000 ELF Version
; 18-1F J 0400000001000000 Program entry position
; 20-27 K 1c00000000000000 Program header table position - This is actually in the middle of J.
; 28-2f L 0000000000000000 Section header table position (Don't have one here so whatev)
; 30-33 M 01000000 Flags - architecture dependent
; 34-35 N 4000 Header size
; 36-37 O 3800 Size of an entry in the program header table
; 38-39 P 0100 Number of entries in the program header table
; 3A-3B Q 0200 Size of an entry in the section header table
; 3C-3D R b0a9 Number of entries in the section header table [holds mov al, 0xa9 load syscall]
; 3E-3F S 0f05 Index in section header table with the section name [holds syscall opcodes]
;
; --- Program Header
; OFFSET # Value Purpose 
; 1C-1F PA 01000000 Type of segment
; 0 = null - ignore the entry
; 1 = load - clear p_memsz bytes at p_vaddr to 0, then copy p_filesz bytes from p_offset to p_vaddr 
; 2 = dynamic - requires dynamic linking
; 3 = interp - contains a file path to an executable to use as an interpreter for the following segment
; 4 = note section
; 20-23 PB 1c000000 Flags 
; 1 = PROT_READ readable
; 2 = PROT_WRITE writable
; 4 = PROT_EXEC executable
; In this case the flags are 1c which is 00011100
; The ABI only pays attention to the lowest three bits, meaning this is marked "PROT_EXEC"
; 24-2B PC 0000000000000000 The offset in the file that the data for this segment can be found (p_offset)
; 2C-33 PD 0000000001000000 Where you should start to put this segment in virtual memory (p_vaddr)
; 34-3B PE 4000380001000200 Physical Address 
; 3C-43 PF b0a90f0500000000 Size of the segment in the file (p_filesz) | NOTE: Can store string here and p_memsz as long as they
; 44-4B PG b0a90f0500000000 Size of the segment in memory (p_memsz) | are equal and not over 0xffff - holds mov al, 0xa9 and syscall 
; 4C-43 PH bfaddee1feebe990 The required alignment for this section (must be a power of 2) Well... supposedly, because you can write code here.
; 
; Breakdown of the hex dump according to the above data
; A---------- B- C- D- E- F----------------------
; 00000000 7f 45 4c 46 ba dc fe 21 43 be 69 19 12 28 eb 3c |.ELF...!C.i..(.<|
; PA---------
; G---- H---- I---------- J----------------------
; 00000010 02 00 3e 00 01 00 00 00 04 00 00 00 01 00 00 00 |..>.............|
; PB--------- PC---------------------- PD---------
; K---------------------- L----------------------
; 00000020 1c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
; PD--------- PE---------------------- PF---------
; M---------- N---- O---- P---- Q---- R---- S----
; 00000030 01 00 00 00 40 00 38 00 01 00 02 00 b0 a9 0f 05 |....@.8.........|
; PF--------- PG---------------------- PH---------
; 00000040 00 00 00 00 b0 a9 0f 05 00 00 00 00 bf ad de e1 |................|
; PH---------
; 00000050 fe eb e9 90 |....|

0x04–0x0F

The first two instructions move the constant values into two registers. These values are LINUX_REBOOT_MAGIC2 (0x28121969) into ESI, and LINUX_REBOOT_CMD_POWER_OFF (0x4321fedc) into EDX. Here, we are using the 32 bit forms of the registers. Moving a 32 bit value into the lower 32 bits of a given 64 bit register will zero out the top 32 bits, meaning we don’t need to xor or do anything else to ensure that the top 32 bits are 0. This is not true for moving to lower bits though, such as say, mov al, 8. This would keep the top values in RAX, and only change the bottom 8 bits to 00001000.

These two instructions are 5 bytes each, meaning that in our 12 byte boundary, we have two bytes left to use up here. This is the perfect amount of space to fit a short jump to the rest of the code!

0x4C-0x53

Now we jump down to the label reeb within the p_align section of the program header, which has 8 bytes for us to use. Here, we are moving another constant, LINUX_REBOOT_MAGIC1, necessary for our syscall into EDI, and jumping to the last location to execute. The mov and jmp instructions together are only 7 bytes, so I included a nop at the very end to keep the binary at a svelte 84 bytes. Without this, the binary wouldn’t execute. It also shows how much space you have to work with in this location.

When I initially released this binary, I didn’t put the mov al, 0xa9 and syscall instructions up in the program header, leading to 1 extra byte. To solve this, we do something that requires a bit of care to do properly.

0x3C-0x39 and 0x44–0x47

The final step is our jump to the label cya, starting at 0x3C. There are a few structures in this area that need to be addressed.

The p_filesz and p_memsz structures appear to need to be the same value in order to execute properly on most kernels. The other tricky aspect is that these are file sizes that have a size limit within the program header that needs to be investigated more. Since this is little endian when we write in nasm, it stays in the lower 4 bytes of the addresses. If you touch the first byte, it might put you over the available memory on the system, which will render the binary unusable. In my experience, using only 4 bytes in these locations is playing it safe, but you should definitely play around with these!

Knowing these limitations, we have enough space to do our final moves, loading RAX with our syscall value 0xa9, and executing a REBOOT.

A very interesting thing to note about the bytes at 0x3C-0x39 is that they are processed a total of three times by the kernel when this executes. First as the e_shnum and e_shstrndx structures in the ELF header, second as the p_filesz structure in the Program Header, and lastly as the code that finishes the execution of the binary.

Here is a handy one liner that will do this.

base64 -d <<< f0VMRrrc/iFDvmkZEijrPAIAPgABAAAABAAAAAEAAAAcAAAAAAAAAAAAAAAAAAA \
AAQAAAEAAOAABAAIAsKkPBQAAAACwqQ8FAAAAAL+t3uH+6+mQ > bye;chmod +x bye;sudo ./bye

Please read the next section before running this on any system.

Effects

On a desktop system, this binary will shut down your computer abruptly. There are some potential side effects from a shutdown like this, but personally I haven’t experienced any issues with it.

However, on a VPS, this specific syscall proves to be a bit of a problem. Since the virtual machine doesn’t actually have any of it’s own physical hardware (it’s either virtualized or shared with the host), the power button on a VPS isn’t really a thing. By executing a syscall the effectively “shuts off the power” to the operating system, this can put the VM in an unknown state.

So far, whenever this is run on a VPS, it seemingly wipes out the entire instance. A thread about this one liner (the 85 byte version) is here:

https://twitter.com/netspooky/status/1061010829666017280

This is a far more destructive piece of code than rm -rf –no-preserve-root / or a fork bomb, because even in those situations, a VM could be recovered via snapshots or mitigated with access / resource controls.

.fini

So there is still quite a lot to explore in this space, and not enough people doing it! I encourage you to play around with these concepts, and see what you can do with it! The next write up in this series will have to do with some assembly optimization concepts, and some space saving tricks like reusing constants of the header (hint: 0x00–0x04), and their practical usage.

greetz: hermit, blackout, jinn, dnz, phaith, readme, notpike, decoded and many others for encouraging me, nt for challenging me frequently (and publicly), and everyone who nuked their own VPS and VMs to test with me.

bye2: everyone who flashcards others with assembly, you really make chatting a joy and totally not toxic.

ELF Binary Mangling Pt. 2: Golfin

Sun, 09 Dec 2018 12:00:00 -0400

Greetings everyone, and welcome to part two of the Binary Mangling series. In our last installment, we took a look at the basics of what an ELF binary is, how it’s laid out, and the bare minimum needed to execute some raw machine code. We also did a little bit of mangling, by hand optimizing our binary in a hex editor to put things where they aren’t supposed to go.

In this installment, we are going much, much deeper, to challenge the kernel with a clown car of barely valid bytes to test the limits of the ELF format itself.

The third part should be coming out at around the same time as this, with a practical example of binary golf, the art of executing a binary in as few moves as possible.

That Shrinking Feeling

Personally, I have wanted to figure out what the absolute smallest ELF64 binary I could manage to create was for a while now.

By normal means, using the GNU assembler and linker, you can create pretty small binaries that have the basic data structures needed to dictate how the executable is parsed by the OS.

In the previous write up, we showed the two necessary structures required to execute your code: The ELF header and the program header. For more info on these, please refer to [part one].

In my initial investigation, I created a 120 byte ELF64 that included the exit syscall in part of the ELF header, meaning the binary was exactly the size of the ELF and Program Headers. After playing around a bit more, I discovered that you can actually end the ELF header early, at 0x3A instead of 0x40, meaning you could save a whole 6 bytes by moving the program header up into the ELF header.

I explored the possibility of overlaying the program and ELF headers, but due to the 8 byte addresses of ELF64, I couldn’t figure out a proper way to do it. I tried again months later and was almost there, but still no dice. After a bunch of messed up nasm files, and some botched hex editing sessions, @_veekun came through and found the proper alignment (big big shoutout).

Here is a breakdown of how we are going about this.

Overlay

So the basic principles of overlaying these two header structures relies on some very precise pieces to be in place.

It’s probably best explained with this nasm file that you can pop into your fav text editor.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42


; exit.asm
;────────────────────────────────────────────────────────────────────────────────
BITS 64

 org 0x100000000 ; Where to load this into memory

;----------------------+------+-------------+----------+--------------------
; ELF Header struct | OFFS | ELFHDR | PHDR | ASSEMBLY OUTPUT
;----------------------+------+-------------+----------+--------------------
 db 0x7F, "ELF" ; 0x00 | e_ident | | 7f45 4c46
_start: mov al,0x3c ; 0x04 | ei_class | | b0
 ; 0x05 | ei_data | | 3c
 xor rdi,rdi ; 0x06 | ei_version | | 4831 ff
 syscall ; 0x09 | u | | 0f05 
 nop ; 0x0b | n | | 90
 nop ; 0x0c | u | | 90
 nop ; 0x0d | s | | 90
 nop ; 0x0e | e | | 90
 nop ; 0x0f | d | | 90
;----------------------+------+-------------+----------+--------------------
; ELF Header struct ct.| OFFS | ELFHDR | PHDR | ASSEMBLY OUTPUT
;----------------------+------+-------------+----------+--------------------
 dw 2 ; 0x10 | e_type | | 0200
 dw 0x3e ; 0x12 | e_machine | | 3e00
 dd 1 ; 0x14 | e_version | | 0100 0000
 dd _start - $$ ; 0x18 | e_entry | | 0400 0000 
;----------------------+------+-------------+----------+--------------------
; Program Header Begin | OFFS | ELFHDR | PHDR | ASSEMBLY OUTPUT
;----------------------+------+-------------+----------+--------------------
phdr: dd 1 ; 0x1C | ... | p_type | 0100 0000 
 dd phdr - $$ ; 0x20 | e_phoff | p_flags | 1c00 0000
 dd 0 ; 0x24 | ... | p_offset | 0000 0000
 dd 0 ; 0x28 | e_shoff | ... | 0000 0000
 dq $$ ; 0x2C | ... | p_vaddr | 0000 0000 
 ; 0x30 | e_flags | ... | 0100 0000 
 dw 0x40 ; 0x34 | e_shsize | p_addr | 4000
 dw 0x38 ; 0x36 | e_phentsize | ... | 3800
 dw 1 ; 0x38 | e_phnum | ... | 0100
 dw 2 ; 0x3A | e_shentsize | ... | 0200
 dq 2 ; 0x3C | e_shnum | p_filesz | 0200 0000 0000 0000
 dq 2 ; 0x44 | | p_memsz | 0200 0000 0000 0000
 dq 2 ; 0x4C | | p_align | 0200 0000 0000 0000

Let’s go through this line by line

Line 1 says BITS64, which tells nasm that this is 64 bit.
Line 3 tells NASM where the binary should be loaded into memory. Usually this is at 0x40000, but this specific address will be useful later on.
Line 8 is the first 4 bytes of the ELF Header that are required to identify the file as an ELF binary.
Line 9 contains the _start label, which is the entry point of our program. It is located at offset 0x4 within the binary. From here until line 12 is our actual program. Note the 5 nops at the end, these are just place holders to show the amount of code we can actually fit in this location.
Line 21 is where the ELF header continues until…
Line 28 where the program header begins in the middle of the e_entry data of the ELF header.

This is where things get interesting.

The p_type data structure denotes the type of segment, here a 1, which is a LOAD segment, meaning it will be loaded into memory for further usage (the ORG address on line 3 plays a key role in where we want to be loaded.)

This structure, containing a value of 1, actually completes the second half of the e_entry data structure, making the full value 04 00 00 00 01 00 00 00. This gives the proper entry address of 0x100000004, which is 4 bytes after the location that the binary is loaded into memory, or 0x4. This is precisely where our _start label is.

The next structures that overlap are e_phoff (which is where the program headers are located), and p_flags, which are the flags that determine the sections permissions. In this case the flags are 0x1C which is 00011100 in binary. The ABI only pays attention to the lowest three bits, meaning this is marked as “executable”, and it’s value can be shared with the ELF header to designate that 0x1C is the address where the program headers start (which is in the middle of the ELF header.)

The rest of the structure continues and overlaps each other with largely dummy values until the end.

Keeping these data sizes in mind and how they overlap will be useful in the next write up. For now, here’s a small annotated part of elf.h that shows how this is eventually laid out.

TODO: Where did this link to before?

Putt Putt

So now we have our basic structure set up, let’s go through what happens when you run this.

First, let’s compile and run exit.asm like so:

1
2
3
4


nasm -f bin -o exit exit.asm
chmod +x exit
./exit
echo $?

If all goes according to plan, you should see a 0 as the output from the last command.

When we run our ELF file, the kernel looks for the data structures we just went over in order to determine what to do with this particular binary. We want to load it into memory (at our specific address defined in p_vaddr) and execute at the entry point we defined at e_entry. Since the ELF and program headers overlap, the kernel jumps around our header and eventually loads our binary and figures out how to execute our code.

Our program is quite simple:

1
2
3


mov al,0x3c
xor rdi,rdi
syscall

All we are doing here is moving value of 0x3C into the lowest 8 bits of the RAX register, putting a value of zero in the RDI register, and calling the kernel. 0x3C is the syscall number for exit, which just exits a process. XORing RDI with itself creates a 0, which is our EXIT STATUS code, 0 meaning SUCCESS.

So it’s running just fine, despite being completely mangled, but what happens when we try and analyze this code?

It appears that objdump has no idea what to do with it, and readelf gives some very bizarre values as well. Other debuggers display some interesting results. You should play around !

What’s next?

So now we’ve successfully created an 84 byte ELF binary, the next step is seeing what else we can pack in this header, and do some more binary golfing. The next write up will describe applying these same techniques to create a VPS nuking one liner containing an 84 byte binary. It will also provide a more in depth look at specific data structures that can be reused to hold code, and how to jump around between them. Thanks for reading!

Greetz to: hermit, +Eevee, dnz, readme, rqu, decoded, notpike, skelsec, jinn, notdan, MG, phaith, nux, zuph, sshell, def_hand, cedric, protoxin, xero and the rest of the Thugcrowd crew.

ELF Binary Mangling Pt. 1: Concepts

Tue, 07 Aug 2018 12:00:00 -0400

Okay, so you want to see how small you can make a 64 bit binary. In the age of giant bloated applications full of impossibly convoluted machine instructions, eating up your memory and disk space, it’s nice sometimes to get down to the lowest of low levels and create something so tiny, that you know what every single bit is doing and it’s purpose. To do so, we need to employ some standard tricks and a little creativity to get us down there.

Building Your Binary

Let’s start with a really simple program that prints a string in the terminal! I chose these smaller opcodes to save a bit more space, but we can get into assembly optimization in another post.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


; smile.asm
;────────────────────────────────────────────────────────────────────────────────
.global _start
.text
_start:
 mov $1, %al # RAX holds syscall 1 (write), I chose to use
 # %al, which is the lower 8 bits of the %rax
 # register. From a binary standpoint, there
 # is less space used to represent this than
 # mov $1, %rax
 mov %rax, %rdi # RDI holds File Handle 1, STDOUT. This means
 # that we are writing to the screen. Again,
 # moving RAX to RDI is shorter than
 # using mov $1, %rdi
 mov $msg, %rsi # RSI holds the address of our string buffer.
 mov $11, %dl # RDX holds the size our of string buffer.
 # Moving into %dl to save space.
 syscall # Invoke a syscall with these arguments.
 mov $60, %al # Now we are invoking syscall 60.
 xor %rdi, %rdi # Zero out RDI, which holds the return value.
 syscall # Call the system again to exit.
msg:
 .ascii "[^0^] u!!\n"

This program uses the most primitive form of writing to STDOUT. It invokes a raw Unix system call to the kernel, with the registers containing the arguments.

Save this into a file called asm_smile.s

vim asm_smile.s
as asm_smile.s -o asm_smile.o

Now we’ve created an object file that can be used to create an executable. We can link it with ld, then run.

$ ld asm_smile.o -o asm_smile
$ ./asm_smile
[^0^] u!!

Okay what have we done here? Let’s take a look at the raw data we generated. A good place to start is objdump.

$ objdump -d asm_smile
asm_smile: file format elf64-x86-64
Disassembly of section .text:
0000000000400078 &lt;_start>:
400078: b0 01 mov $0x1,%al
40007a: 48 89 c7 mov %rax,%rdi
40007d: 48 c7 c6 8f 00 40 00 mov $0x40008f,%rsi
400084: b2 0b mov $0xb,%dl
400086: 0f 05 syscall
400088: b0 3c mov $0x3c,%al
40008a: 48 31 ff xor %rdi,%rdi
40008d: 0f 05 syscall
000000000040008f &lt;msg>:
40008f: 5b pop %rbx
400090: 5e pop %rsi
400091: 30 5e 5d xor %bl,0x5d(%rsi)
400094: 20 75 21 and %dh,0x21(%rbp)
400097: 21 0a and %ecx,(%rdx)

Our program + string is only 33 bytes, so why is our binary 752 bytes? Let’s take a look at a quick hex dump.

Hrm… There’s quite a bit of extra data in there! We can see our program begins at 0x78 and ends at 0x98. How can you make a binary smaller right off the bat? We can use strip!

$ strip asm_smile

Strip reads a binary file, and removes a lot of the extra debug and compiler info that isn’t needed. So what does our binary look like now?

After using strip, we are down to 368 bytes! That’s a pretty small binary. But remember, our machine instructions were just 33 bytes, so what’s up with all this overhead?

To understand this, we need to break down the sections of an ELF binary real quick. If you’re not used to looking at hex dumps and hand modifying data, this is a great place to start. It’s not that scary!

Under the Hood

All ELF binaries need to have a few things in place in order for them to be interpreted by the Linux kernel properly. As with Windows EXEs, there’s a structure to the header that defines the overall layout of the binary.

This example is using x86_64 assembly, so the ELF binaries I am describing here are the 64 bit version. The 32 bit version is slightly different.

Let’s take a look at what other information is in this binary. We can use a program called readelf to help us follow along!

What does this all mean? We will start by first understanding the ELF header.

ELF Header

The ELF header section defines the file as an ELF binary. In the hex dump it looks like this:

Each one of these bytes has a specific purpose.

Offset	# │ Description
00-03	A │ Magic number - 0x7F, then ‘ELF’ in ASCII
04	B │ 1 = 32 bit, 2 = 64 bit
05	C │ 1 = little endian, 2 = big endian
06	D │ ELF header version
07	E │ OS ABI - usually 0 for System V
08-0F	F │ Unused/padding
10-11	G │ 1 = relocatable, 2 = executable, 3 = shared, 4 = core
12-13	H │ Instruction set - see table below
14-17	I │ ELF Version
18-1F	J │ Program entry position
20-27	K │ Program header table position
28-2F	L │ Section header table position
30-33	M │ Flags - architecture dependent; see note below
34-35	N │ Header size
36-37	O │ Size of an entry in the program header table
38-39	P │ Number of entries in the program header table
3A-3B	Q │ Size of an entry in the section header table
3C-3D	R │ Number of entries in the section header table
3E-3F	S │ Index in section header table with the section names

This is the ELF Header with index values to show exactly where these values line up in our binary.

These values are mainly metadata that tells the operating system what to do with this file. I won’t get too deep into what these things mean, but they are necessary to be aware of as we move along. You can find more info here! https://wiki.osdev.org/ELF

Program Headers

Next up is the program header. This area describes a segment and other info that the operating system needs to know how to run the program. This is how it appears in our hex dump:

Here is a quick listing of the components that make up the program header. Note: The offsets are relative to the start of the program header (at 0x40).

Here’s a layout of our the program header in our binary, with indexes for reference.

From the output of readelf, we can see that it matches up with the hex dump.

[ .text Section ]───────────────────────────────────────────────────────────────

Next up is the machine instructions themselves. We saw these earlier when we used objdump, but in their raw form they look like this.

You can see that they contain the 33 bytes of our program.

[ Section Headers ]─────────────────────────────────────────────────────────────

These next chunks of information are known as the section headers. They are used to describe the layout of the sections in the binary.

You can see in the section header output of readelf that we have descriptions of the .text and .shstrtab sections. The .text section is what we just saw above, at offset 0x00000078, containing the machine instructions.

The section after that is .shstrtab, which is the table of addresses where strings are located in the binary.

In a binary this small, with no labels or anything else, .shstrtab only exists to say that it exists, by describing the location of the .shstrtab label.

In any case, these sections are totally unnecessary unless you are actively debugging the program. All we need are the machine instructions, so we can get rid of this big bulk of bytes taken up by the .shstrtab and the section headers by hand with your hex editor of choice.

Delete everything from 0x99 on!

Our binary now looks like this

We keep the 0a byte at the end just so the terminal knows that the string is over and we need a new line.

[ Mangling ]────────────────────────────────────────────────────────────────────

Well, we are now down to 0x99 (153) bytes. This is pretty small, but we can do more to get this thing even smaller.

We can see in the objdump from before that we MOV 0x40008f into %rsi, which is the virtual address pointing to our string 0x5b5e305e5d207521210a. or “[^0^] u!!\n”

If the program is pointing to the address of the string at 0x40008f, then that means that it maps out to 0x00008f in our binary. What if we save even more space (10 whole bytes!) by moving our string somewhere else?

But where else, and how? Well, we can try and find some unused space elsewhere to store our string. At first glance it looks like all the bytes in our binary are accounted for. Admittedly, x86_64’s structure is a bit more rigid than x86, because of the amount of space needed to hold addresses in such a large memory space. But, there are still some spots that we can hide some data.

The ELF Header from above contains a bit of padding at 0x08–0x015. It also contains some bytes that are pretty much always going to be a specific value at this point in ELF’s history.

Two of these values are the ELF version (which is 1 for version 1) at 0x06, and the OS Application Binary Interface at 0x07. These can be overwritten and still run on most Unix based systems, and are a perfect location to begin our code insertion.

We now have 10 bytes free that we can use to move our string up into the header like this:

Now before we run this, we have to make sure our machine code is pointing to where our new string is. Previously we were at 0x40008f, which is referenced in the binary at 0x00000080

48 c7 c6 8f 00 40 00 mov $0x40008f,%rsi

Since our string is now at 0x00000006 in our binary, we change the address at 0x00000080 as such. Simply swap out 8f for 06. Note: Addresses are little endian, so 0x0040008f is represented as 0x8f004000.

And there you have it. We have successfully rearranged this binary by hand to hide code in the header, and have removed debugging capabilities. Our binary should do the same thing as it did when we first compiled it, but now at a lean 143 bytes.

Final Output:

ARM32 Binary Mangling

Fri, 01 Dec 2017 12:00:00 -0400

Here are some notes on experimenting with small ARM32 binaries. I edited binaries directly instead of assembling them on each modification to the binary.

Creating The Initial Binary

This is the source

$ cat hello.s
.data
msg: .ascii "[^-^] [^0^]\n"
len = . - msg
.text
.global _start
_start:
mov r0, #1 /* fd 1 = stdout */
ldr r1, =msg /* message */
ldr r2, =len /* length of message */
mov r7, $4 /* write */
swi #0 /* syscall */
mov r0, $0 /* status */
mov r7, $1 /* exit */
swi #0 /* syscall */

Output in raw hex - You can use objdump or this handy converter!

0100a0e3 MOV R0, #1
14109fe5 LDR R1, [PC, #0x14]
0c20a0e3 MOV R2, #0xC
0470a0e3 MOV R7, #4
000000ef SVC #0
0000a0e3 MOV R0, #0
0170a0e3 MOV R7, #1
000000ef SVC #0
90000200 MULEQ R2, R0, R0

Analyzing The Sections

Objdump

pi@pai:~/asm $ objdump -d hello
hello: file format elf32-littlearm
Disassembly of section .text:
00010074 <_start>:
10074: e3a00001 mov r0, #1
10078: e59f1014 ldr r1, [pc, #20] ; 10094 <_start+0x20>
1007c: e3a0200c mov r2, #12
10080: e3a07004 mov r7, #4
10084: ef000000 svc 0x00000000
10088: e3a00000 mov r0, #0
1008c: e3a07001 mov r7, #1
10090: ef000000 svc 0x00000000
10094: 00020098 .word 0x00020098

Hexdump

pi@pai:~/asm $ hd hello
headers ----------------------------------------------------------------------
00000000 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 02 00 28 00 01 00 00 00 74 00 01 00 34 00 00 00 |..(.....t...4...|
00000020 60 02 00 00 00 02 00 05 34 00 20 00 02 00 28 00 |`.......4. ...(.|
00000030 07 00 06 00 01 00 00 00 00 00 00 00 00 00 01 00 |................|
00000040 00 00 01 00 98 00 00 00 98 00 00 00 05 00 00 00 |................|
00000050 00 00 01 00 01 00 00 00 98 00 00 00 98 00 02 00 |................|
00000060 98 00 02 00 0c 00 00 00 0c 00 00 00 06 00 00 00 |................|
00000070 00 00 01 00
.text 0x74 | 0x24 ------------------------------------------------------------
00000074 01 00 a0 e3 14 10 9f e5 0c 20 a0 e3 |............. ..|
00000080 04 70 a0 e3 00 00 00 ef 00 00 a0 e3 01 70 a0 e3 |.p...........p..|
00000090 00 00 00 ef 98 00 02 00
.data 0x98 | 0xc -------------------------------------------------------------
00000098 5b 5e 2d 5e 5d 20 5b 5e |........[^-^] [^|
000000a0 30 5e 5d 0a |0^].
.ARM_attributes 0xa4 | 0x14 --------------------------------------------------
000000a4 41 13 00 00 00 61 65 61 62 69 00 01 A....aeabi..|
000000b0 09 00 00 00 06 01 08 01
.symtab 0xb8 | 0x120 ---------------------------------------------------------
000000b8 00 00 00 00 00 00 00 00 |................|
000000c0 00 00 00 00 00 00 00 00 00 00 00 00 74 00 01 00 |............t...|
000000d0 00 00 00 00 03 00 01 00 00 00 00 00 98 00 02 00 |................|
000000e0 00 00 00 00 03 00 02 00 00 00 00 00 00 00 00 00 |................|
000000f0 00 00 00 00 03 00 03 00 01 00 00 00 00 00 00 00 |................|
00000100 00 00 00 00 04 00 f1 ff 09 00 00 00 98 00 02 00 |................|
00000110 00 00 00 00 00 00 02 00 0d 00 00 00 0c 00 00 00 |................|
00000120 00 00 00 00 00 00 f1 ff 11 00 00 00 74 00 01 00 |............t...|
00000130 00 00 00 00 00 00 01 00 14 00 00 00 94 00 01 00 |................|
00000140 00 00 00 00 00 00 01 00 14 00 00 00 98 00 02 00 |................|
00000150 00 00 00 00 00 00 02 00 26 00 00 00 a4 00 02 00 |........&.......|
00000160 00 00 00 00 10 00 02 00 17 00 00 00 a4 00 02 00 |................|
00000170 00 00 00 00 10 00 02 00 25 00 00 00 a4 00 02 00 |........%.......|
00000180 00 00 00 00 10 00 02 00 36 00 00 00 74 00 01 00 |........6...t...|
00000190 00 00 00 00 10 00 01 00 31 00 00 00 a4 00 02 00 |........1.......|
000001a0 00 00 00 00 10 00 02 00 3d 00 00 00 a4 00 02 00 |........=.......|
000001b0 00 00 00 00 10 00 02 00 45 00 00 00 a4 00 02 00 |........E.......|
000001c0 00 00 00 00 10 00 02 00 4c 00 00 00 a4 00 02 00 |........L.......|
000001d0 00 00 00 00 10 00 02 00
.strtab 0x1d8 | 0x51 ---------------------------------------------------------
000001d8 00 68 65 6c 6c 6f 2e 6f |.........hello.o|
000001e0 00 6d 73 67 00 6c 65 6e 00 24 61 00 24 64 00 5f |.msg.len.$a.$d._|
000001f0 5f 62 73 73 5f 73 74 61 72 74 5f 5f 00 5f 5f 62 |_bss_start__.__b|
00000200 73 73 5f 65 6e 64 5f 5f 00 5f 5f 62 73 73 5f 73 |ss_end__.__bss_s|
00000210 74 61 72 74 00 5f 5f 65 6e 64 5f 5f 00 5f 65 64 |tart.__end__._ed|
00000220 61 74 61 00 5f 65 6e 64 00 |ata._end.
.shstrtab 0x229 | 0x37 -------------------------------------------------------
00000229 00 2e 73 79 6d 74 61 ..symta|
00000230 62 00 2e 73 74 72 74 61 62 00 2e 73 68 73 74 72 |b..strtab..shstr|
00000240 74 61 62 00 2e 74 65 78 74 00 2e 64 61 74 61 00 |tab..text..data.|
00000250 2e 41 52 4d 2e 61 74 74 72 69 62 75 74 65 73 00 |.ARM.attributes.|
Then a bunch of other stuff
00000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000280 00 00 00 00 00 00 00 00 1b 00 00 00 01 00 00 00 |................|
00000290 06 00 00 00 74 00 01 00 74 00 00 00 24 00 00 00 |....t...t...$...|
000002a0 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 |................|
000002b0 21 00 00 00 01 00 00 00 03 00 00 00 98 00 02 00 |!...............|
000002c0 98 00 00 00 0c 00 00 00 00 00 00 00 00 00 00 00 |................|
000002d0 01 00 00 00 00 00 00 00 27 00 00 00 03 00 00 70 |........'......p|
000002e0 00 00 00 00 00 00 00 00 a4 00 00 00 14 00 00 00 |................|
000002f0 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 |................|
00000300 01 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 |................|
00000310 b8 00 00 00 20 01 00 00 05 00 00 00 0a 00 00 00 |.... ...........|
00000320 04 00 00 00 10 00 00 00 09 00 00 00 03 00 00 00 |................|
00000330 00 00 00 00 00 00 00 00 d8 01 00 00 51 00 00 00 |............Q...|
00000340 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 |................|
00000350 11 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 |................|
00000360 29 02 00 00 37 00 00 00 00 00 00 00 00 00 00 00 |)...7...........|
00000370 01 00 00 00 00 00 00 00 |........|
00000378

Stripped Hexdump

pi@pai:~/asm $ strip hello
pi@pai:~/asm $ hd hello
00000000 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 02 00 28 00 01 00 00 00 74 00 01 00 34 00 00 00 |..(.....t...4...|
00000020 e0 00 00 00 00 02 00 05 34 00 20 00 02 00 28 00 |........4. ...(.|
00000030 05 00 04 00 01 00 00 00 00 00 00 00 00 00 01 00 |................|
00000040 00 00 01 00 98 00 00 00 98 00 00 00 05 00 00 00 |................|
00000050 00 00 01 00 01 00 00 00 98 00 00 00 98 00 02 00 |................|
00000060 98 00 02 00 0c 00 00 00 0c 00 00 00 06 00 00 00 |................|
00000070 00 00 01 00 01 00 a0 e3 14 10 9f e5 0c 20 a0 e3 |............. ..|
00000080 04 70 a0 e3 00 00 00 ef 00 00 a0 e3 01 70 a0 e3 |.p...........p..|
00000090 00 00 00 ef 98 00 02 00 5b 5e 2d 5e 5d 20 5b 5e |........[^-^] [^|
000000a0 30 5e 5d 0a 41 13 00 00 00 61 65 61 62 69 00 01 |0^].A....aeabi..|
000000b0 09 00 00 00 06 01 08 01 00 2e 73 68 73 74 72 74 |..........shstrt|
000000c0 61 62 00 2e 74 65 78 74 00 2e 64 61 74 61 00 2e |ab..text..data..|
000000d0 41 52 4d 2e 61 74 74 72 69 62 75 74 65 73 00 00 |ARM.attributes..|
000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100 00 00 00 00 00 00 00 00 0b 00 00 00 01 00 00 00 |................|
00000110 06 00 00 00 74 00 01 00 74 00 00 00 24 00 00 00 |....t...t...$...|
00000120 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 |................|
00000130 11 00 00 00 01 00 00 00 03 00 00 00 98 00 02 00 |................|
00000140 98 00 00 00 0c 00 00 00 00 00 00 00 00 00 00 00 |................|
00000150 01 00 00 00 00 00 00 00 17 00 00 00 03 00 00 70 |...............p|
00000160 00 00 00 00 00 00 00 00 a4 00 00 00 14 00 00 00 |................|
00000170 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 |................|
00000180 01 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 |................|
00000190 b8 00 00 00 27 00 00 00 00 00 00 00 00 00 00 00 |....'...........|
000001a0 01 00 00 00 00 00 00 00 |........|
000001a8

Readelf

pi@pai:~/asm $ readelf -a hello
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x10074
Start of program headers: 52 (bytes into file)
Start of section headers: 608 (bytes into file)
Flags: 0x5000200, Version5 EABI, soft-float ABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 2
Size of section headers: 40 (bytes)
Number of section headers: 7
Section header string table index: 6
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00010074 000074 000024 00 AX 0 0 4
[ 2] .data PROGBITS 00020098 000098 00000c 00 WA 0 0 1
[ 3] .ARM.attributes ARM_ATTRIBUTES 00000000 0000a4 000014 00 0 0 1
[ 4] .symtab SYMTAB 00000000 0000b8 000120 10 5 10 4
[ 5] .strtab STRTAB 00000000 0001d8 000051 00 0 0 1
[ 6] .shstrtab STRTAB 00000000 000229 000037 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
y (purecode), p (processor specific)
There are no section groups in this file.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x00010000 0x00010000 0x00098 0x00098 R E 0x10000
LOAD 0x000098 0x00020098 0x00020098 0x0000c 0x0000c RW 0x10000
Section to Segment mapping:
Segment Sections...
00 .text
01 .data
There is no dynamic section in this file.
There are no relocations in this file.
There are no unwind sections in this file.
Symbol table '.symtab' contains 18 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00010074 0 SECTION LOCAL DEFAULT 1
2: 00020098 0 SECTION LOCAL DEFAULT 2
3: 00000000 0 SECTION LOCAL DEFAULT 3
4: 00000000 0 FILE LOCAL DEFAULT ABS hello.o
5: 00020098 0 NOTYPE LOCAL DEFAULT 2 msg
6: 0000000c 0 NOTYPE LOCAL DEFAULT ABS len
7: 00010074 0 NOTYPE LOCAL DEFAULT 1 $a
8: 00010094 0 NOTYPE LOCAL DEFAULT 1 $d
9: 00020098 0 NOTYPE LOCAL DEFAULT 2 $d
10: 000200a4 0 NOTYPE GLOBAL DEFAULT 2 _bss_end__
11: 000200a4 0 NOTYPE GLOBAL DEFAULT 2 __bss_start__
12: 000200a4 0 NOTYPE GLOBAL DEFAULT 2 __bss_end__
13: 00010074 0 NOTYPE GLOBAL DEFAULT 1 _start
14: 000200a4 0 NOTYPE GLOBAL DEFAULT 2 __bss_start
15: 000200a4 0 NOTYPE GLOBAL DEFAULT 2 __end__
16: 000200a4 0 NOTYPE GLOBAL DEFAULT 2 _edata
17: 000200a4 0 NOTYPE GLOBAL DEFAULT 2 _end
No version information found in this file.
Attribute Section: aeabi
File Attributes
Tag_CPU_arch: v4
Tag_ARM_ISA_use: Yes
ARM ABI is version 5

Can Delete up to .text and .data !

 pi@pai:~ $ hd hello_pi_no_armattr
00000000 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 02 00 28 00 01 00 00 00 74 00 01 00 34 00 00 00 |..(.....t...4...|
00000020 e0 00 00 00 00 02 00 05 34 00 20 00 02 00 28 00 |........4. ...(.|
00000030 05 00 04 00 01 00 00 00 00 00 00 00 00 00 01 00 |................|
00000040 00 00 01 00 98 00 00 00 98 00 00 00 05 00 00 00 |................|
00000050 00 00 01 00 01 00 00 00 98 00 00 00 98 00 02 00 |................|
00000060 98 00 02 00 0c 00 00 00 0c 00 00 00 06 00 00 00 |................|
00000070 00 00 01 00 01 00 a0 e3 14 10 9f e5 0c 20 a0 e3 |............. ..|
00000080 04 70 a0 e3 00 00 00 ef 00 00 a0 e3 01 70 a0 e3 |.p...........p..|
00000090 00 00 00 ef 98 00 02 00 5b 5e 2d 5e 5d 20 5b 5e |........[^-^] [^|
000000a0 30 5e 5d 0a |0^].|

Read elf again

pi@pai:~ $ readelf -a hello_pi_no_armattr
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x10074
Start of program headers: 52 (bytes into file)
Start of section headers: 224 (bytes into file)
Flags: 0x5000200, Version5 EABI, soft-float ABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 2
Size of section headers: 40 (bytes)
Number of section headers: 5
Section header string table index: 4
readelf: Error: Reading 0xc8 bytes extends past end of file for section header
readelf: Error: Section headers are not available!
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x00010000 0x00010000 0x00098 0x00098 R E 0x10000
LOAD 0x000098 0x00020098 0x00020098 0x0000c 0x0000c RW 0x10000
There is no dynamic section in this file.

ELF Header

Here’s another look at the ELF Header with Index Letters to help see where stuff actually is:

Position I Value
----------------------------------------------------------------------
0-3 A Magic number - 0x7F, then 'ELF' in ASCII
4 B 1 = 32 bit, 2 = 64 bit
5 C 1 = little endian, 2 = big endian
6 D ELF Version
7 E OS ABI - usually 0 for System V
8-15 F Unused/padding
16-17 G 1 = relocatable, 2 = executable, 3 = shared, 4 = core
18-19 H Instruction set
20-23 I ELF Version
24-27 J Program entry position
28-31 K Program header table position
32-35 L Section header table position
36-39 M Flags - architecture dependent; see note below
40-41 N Header size
42-43 O Size of an entry in the program header table
44-45 P Number of entries in the program header table
46-47 Q Size of an entry in the section header table
48-49 R Number of entries in the section header table
50-51 S Index in section header table with the section name

NOTE: 0x28 is the instruction set flag number for ARM.

Take a look at how these values are actually laid out in an ARM binary.

 A---------- B- C- D- E- F----------------------
00000000 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
G---- H---- I---------- J---------- K----------
00000010 02 00 28 00 01 00 00 00 74 00 01 00 34 00 00 00 |..(.....t...4...|
L---------- M---------- N---- O---- P---- Q----
00000020 e0 00 00 00 00 02 00 05 34 00 20 00 02 00 28 00 |........4. ...(.|
R---- S----
00000030 05 00 04 00

Program Headers [32 bit]

Position I Value
----------------------------------------------------------------------
0-3 A Type of segment
4-7 B The offset in the file that the data for this segment can
be found (p_offset)
8-11 C Where you should start to put this segment in virtual
memory (p_vaddr)
12-15 D Undefined for the System V ABI
16-19 E Size of the segment in the file (p_filesz)
20-23 F Size of the segment in memory (p_memsz)
24-27 G Flags
1 = x
2 = w
3 = wx
4 = r
5 = rx - code segment
6 = rw - data segment
7 = rwx
28-31 H The required alignment for this section (must be a power of 2)

Why are there two program headers?

 A---------- B---------- C----------
00000034 01 00 00 00 00 00 00 00 00 00 01 00 |................|
D---------- E---------- F---------- G----------
00000040 00 00 01 00 98 00 00 00 98 00 00 00 05 00 00 00 |................|
H----------
00000050 00 00 01 00
A---------- B---------- C----------
00000054 01 00 00 00 98 00 00 00 98 00 02 00 |................|
D---------- E---------- F---------- G----------
00000060 98 00 02 00 0c 00 00 00 0c 00 00 00 06 00 00 00 |................|
H----------
00000070 00 00 01 00

Our actual code is still here:

 .text-------------------------------------------------------------------------
01 00 a0 e3 14 10 9f e5 0c 20 a0 e3 |............. ..|
00000080 04 70 a0 e3 00 00 00 ef 00 00 a0 e3 01 70 a0 e3 |.p...........p..|
00000090 00 00 00 ef 98 00 02 00 5b 5e 2d 5e 5d 20 5b 5e |........[^-^] [^|
000000a0 30 5e 5d 0a |0^].|

Deleting the second program header causes it to return zero but no output to terminal. It keeps loading at 0x00000074. Removing the first causes a segfault

The first program header describes the headers and .text, the second describes the data for ‘[^-^] [^0^]\n’. If bin mangling then the second isn’t needed as long as relative address is grabbing the data from the code segment.

Mangling

Now we have an idea of the layout for a barebones ARM binary and can add our code as needed.

So if I add the shellcode for /bin/sh and just append to that binary template with just one program header, what happens? Turns out that’s all you need. Just change the entry point to 54, change the amount of program headers elf.P.

The size at pgm.E and pgm.F don’t even really matter as long as its bigger than the length of the file.

7F 45 4C 46 01 01 01 00 00 00 00 00 00 00 00 00
02 00 28 00 01 00 00 00 54 00 01 00 34 00 00 00
E0 00 00 00 00 02 00 05 34 00 20 00 01 00 28 00
05 00 04 00 01 00 00 00 00 00 00 00 00 00 01 00
00 00 01 00 98 00 00 00 98 00 00 00 05 00 00 00
00 00 01 00 01 60 8F E2 16 FF 2F E1 40 40 78 44
0C 30 49 40 52 40 0B 27 01 DF 01 27 01 DF 2F 2F
62 69 6E 2F 2F 73 68
00000000 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 02 00 28 00 01 00 00 00 54 00 01 00 34 00 00 00 |..(.....T...4...|
00000020 e0 00 00 00 00 02 00 05 34 00 20 00 01 00 28 00 |........4. ...(.|
00000030 05 00 04 00 01 00 00 00 00 00 00 00 00 00 01 00 |................|
00000040 00 00 01 00 98 00 00 00 98 00 00 00 05 00 00 00 |................|
00000050 00 00 01 00 01 60 8f e2 16 ff 2f e1 40 40 78 44 |.....`..../.@@xD|
00000060 0c 30 49 40 52 40 0b 27 01 df 01 27 01 df 2f 2f |.0I@R@.'...'..//|
00000070 62 69 6e 2f 2f 73 68 |bin//sh|
00000077

119 bytes, smaller than the 147 bytes in shldr of bin/sh in elf64

7F 45 4C 46 01 01 01 00 00 00 00 00 00 00 00 00
02 00 28 00 01 00 00 00 54 00 01 00 34 00 00 00
E0 00 00 00 00 02 00 05 34 00 20 00 01 00 28 00
05 00 04 00 01 00 00 00 00 00 00 00 00 00 01 00
00 00 01 00

Change the two 98s to the length of the shellcode + 0x54

Generic AT Commands

Mon, 20 Nov 2017 12:00:00 -0400

Listing some generic GSM / GPRS Modem AT commands. There are always going to be manufacturer specific ones. This list was created with the SIM800 module in mind.

Info

All commands start with “AT” (case insensitive)
All responses are ResponseData
Chain commands together with semicolons. You only need to set AT once.

General Info

Command	Description
AT&V	View current configuration
AT&W	Store current configuration

Network

Command	Description
AT+COPS?	Query Network Operators in cell area
AT+COPS=X	X = Params for registering to specified network. Test SIM
AT+CPAS	Get activity status of module (0=ready,2=Unknown)
AT+CREG	Network Registration. Use to determine registration state and enable registration with operators.

SMS

Command	Description
AT+CMGR	Read SMS Message
AT+CMGS	Send SMS Message

SIM Toolkit

Command	Description
AT+STKTRS	STK Terminal Response (Basically return value on command.)
AT+SGPIO	Control GPIO. Can select pins and set high or low.
AT+CGPIO	Control GPIO by Pin Index. Same but easier to pick pins.
AT+GSMBUSY	Reject Incoming Call
AT+CWHITELIST	Set the Whitelist
AT+SJDR	Set Jamming Detection Function
AT+SKPD	Keypad Detecting Function

GPRS

Command	Description
AT+CGATT	Attach or Detach from GPRS Service
AT+CGREG	Network Registration Status

TCP/IP

Command	Description
AT+CIPSTART	Start TCP or UDP Connection
AT+CIPSEND	Send Data through TCP or UDP Connection
AT+CIPQSEND	Select data transmission mode
AT+CIPACK	Query Previous Connection Data Transmitting State
AT+CIPCLOSE	Close connection.
AT+CLPORT	Set Local Port
AT+CIFSR	Get Local IP
AT+CIPSTATUS	Get Current Connection Status
AT+CDNSCFG	Set DNS
AT+CDNSGIP	DNS Query
AT+CIPSRIP	Show remote addr and port when recieving

HTTP

Command	Description
AT+HTTPINIT	Start HTTP Service
AT+HTTPTERM	Stop HTTP Service
AT+HTTPDATA	Input HTTP Data
AT+HTTPACTION	HTTP Method
AT+HTTPREAD	Read server response
AT+HTTPSTATUS	Read HTTP Status

References

https://www.elecrow.com/download/SIM800%20Series_AT%20Command%20Manual_V1.09.pdf

x86 Bootloaders

Sat, 11 Jun 2016 12:00:00 -0400

Bootloaders at their core are very simple pieces of code. Their responsibility is to give the BIOS a way to load the operating system you want to load into memory and do all of the proper initialization it needs to actually boot.

This can become a very complicated process, and because BIOS based systems are fairly old, newer technology like UEFI has been created to replace them.

Here’s some very basic examples of bootloader code

Initialization

When the BIOS initializes, it self tests the hardware then loads the first 512 bytes of memory from the media device.

When your computer turns on, the BIOS starts up by checking what hardware is attached to the machine. It detects a disk and loads the first 512 bytes into memory and executes it as a bootloader.

From here, the bootloader is operating in 16 bit real mode, the most primitive operating mode an x86 processor can operate in. During this phase, it is up to the bootloader to start it’s initialization and checks to create an environment that it can load the OS into. At this point though, we can do whatever we want.

In this example, we can write a super basic program that will just serve as a hello world type program as a bootloader.

bits 16 ; NASM directive for 16 bit mode
org 0x7c00 ; This tells NASM to load the code at 0x7c00
boot:
 mov si,ayy ; point SI register to hello label's loc
 mov ah,0x0e ; 0x0e means "Write Character in TTY mode"
loop:
 lodsb ; Loads bytes pointed at by ds:si into al.
 or al,al ; Checks if al == 0
 jz halt ; if (al == 0) jump to halt label
 int 0x10 ; runs BIOS interrupt 0x10 - video services
 jmp loop
halt:
 cli ; Clear interrupt flag
 hlt ; Halt execution
ayy: db "[^_^] [.~.] ",0 ; Our null terminated string

times 510 - ($-$$) db 0 ; Pad the rest of the bytes with 00s
dw 0xaa55 ; This is the magic byte for the bootloader

As you can see, this is a very basic assembly program (think DOS) that just loads a string into memory and uses interrupts to write it to the screen.

The last line dw 0xaa55 is used as a magic byte for the bootloader, which traditionally acts as a checksum for the BIOS to tell it that it should jump to 0x7C000 and let the bootloader take care of the rest. I have found that this isn’t always the case. In Virtualbox, you can totally make these whatever bytes you want and it will boot just fine. This varies from vendor to vendor.

Speaking of booting as a VM, you can do this by compiling and naming the file something.img.

Here is how you compile:

nasm -f bin bootloadertest.asm -o boot1.bin

If we do a hex dump, we can take a look at what this actually looks like:

00000000: be10 7cb4 0eac 08c0 7404 cd10 ebf7 faf4 ..|.....t.......
00000010: 5b5e 5f5e 5d20 5b2e 7e2e 5d20 0000 0000 [^_^] [.~.] ....
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000150: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000170: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000180: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000190: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa ..............U.

You can disassemble with nasm as well to get a proper look

x@n0:~$ ndisasm -o 0x7c00 bl
00007C00 BE107C mov si,0x7c10
00007C03 B40E mov ah,0xe
00007C05 AC lodsb
00007C06 08C0 or al,al
00007C08 7404 jz 0x7c0e
00007C0A CD10 int 0x10
00007C0C EBF7 jmp short 0x7c05
00007C0E FA cli
00007C0F F4 hlt
00007C10 5B pop bx
00007C11 5E pop si
00007C12 5F pop di
00007C13 5E pop si
00007C14 5D pop bp
00007C15 205B2E and [bp+di+0x2e],bl
00007C18 7E2E jng 0x7c48
00007C1A 5D pop bp
00007C1B 2000 and [bx+si],al
00007C1D 0000 add [bx+si],al
... truncated bc lots of the same ...
00007DFD 0055AA add [di-0x56],dl

Now that this is done, it’s time we do something more useful. Let’s move to 32 bit mode, and actually set up where we’d plop more advanced code.

Global Descriptor Table

The Global Descriptor Table is a table of entries that keeps track of memory segments. When we are on this level, we need to establish the boundaries where our code / data / task queue / user / malware will operate.

You load the GDT with the lgdt instruction.

Segment Types

Type	Description
Null Segment	We keep a null segment because certain emulators will complain about limit exceptions if you don’t have a null segment. You can store a pointer to the GDT itself in here. The null descriptor is 8 bytes and the pointer is 6 bytes, so it works.
Code Segment	This describes the code we are loading. Could be a kernel, second stage bootloader, bootkit etc.
Data Segment	This will contain our writable memory space.

Also you can load a TSS Segment to store the Task State, but it’s not necessary for a super basic example.

GDT Descriptors

The GDTR register is where the GDT descriptor is held. A descriptor is 6 bytes long and looks like this:

BYTE	SIZE	DESC
0-2	2	LIMIT - Size of the table subtracted by 1. This means the GDT has a max size of 65536 bytes or 8192 entries
2-6	4	BASE - The linear address of the GDT table.

GDT Entries

Once we’ve established where we’re going, we need to put some data there!

What kind of data do we actually need?

base is a 32 bit value that describes where the segement begins. It’s split up into a bunch of parts because of the original limitations of the processor

limit is a 20 bit value describing where the segment ends. If the granularity bit in flags is set to 1, then this value is multiplied by 4096 to signify that we are working with pages. The default is 1 byte.

The rest of the data is stored in access and flag sections here, and are given definitions. The layout is whacky as hell, so maybe just look up some GDT diagrams if you don’t quite get it because this might not be a good description.

Table entries are 8 bytes total, and they look like this.

 +-------+-------------------+
 | Bits | Entry Part |
 +-------+-------------------+
 | 00-15 | limit_low 0:15 |
 | 16-31 | base_low 0:15 |
 | 32-39 | base_middle 16:23 |
 | 40-47 | access byte |>---+
 | 48-51 | limit_high 16:19 | |
+----------------------<| 52-55 | flags | |
| | 56-63 | base_high 24:31 | |
| +-------+-------------------+ |
| +---------------------------------------------------+
| |
| | The flags within the access byte (bits 40-47) are:
| v
| +-----+----------------------------------------------------------------------+
| | BIT | DESC |
| +-----+----------------------------------------------------------------------+
| | 0 | Accessed bit - Set 0, the CPU sets to 1 if the segment is accessed |
| | 1 | Read / Write flag - If a code segment, 1 means that read is allowed. |
| | | If a data segment, 1 means that writing is allowed. |
| | 2 | Direction bit. 0 = Segement Grows up 1 = Segment grows down |
| | 3 | Executable - If 1, code in this segment can be executed. If 0, this |
| | | is a data segment |
| | 4 | Descriptor Type - Should be set if it's a code or data segment. Else |
| | | it's a system segment (eg TSS) |
| | 5-6 | Privilege level, contains the ring level. 0-3 |
| | 7 | Present bit. Must but 1 for all valid sectors. |
| +-----+----------------------------------------------------------------------+
|
| The flags in the flag nibble (bits 52-55) are:
|
| +-----+----------------------------------------------------------------------+
| | BIT | DESC |
| +-----+----------------------------------------------------------------------+
+>| 0 | Leave at zero |
 | 1 | L bit - Only used in x64. Used to mark a 64 bit data segment |
 | 2 | Size bit. 0=16 bit,1=32 bit. If L (and 64 bit), this must be 0 |
 | 3 | Granularity. 0=limit is in 1B blocks(byte) or 1=4KiB blocks(page) |
 +-----+----------------------------------------------------------------------+

Enabling the A20 Line

Here is some example code of doing a bit of what we’ve just described.

The A20 line is the actual pin on the Address Bus that is the 21st bit of memory access. Because this is x86, anything beyond 20 bits of address space was originally disabled by default, due to some systems that couldn’t count that high. So because of this, we have to enable this each time we use our processor, unless we want to be bound to < 16 megabytes of address space.

Fun fact: This used to literally be an option on older keyboards, specifically those with a 8042 PS/2 controller, where you could manually toggle the A20 gate to enable more memory access. I’m not sure if I want to laugh or find some way to directly toggle pins on my i7 with my keyboard.

This method uses the BIOS INT 15h method to enable the A20 line

; Enabling the A20 line, aka address more than 1MB of Memory

bits 16
org 0x7c00

boot:
 mov ax, 0x2401 ; AH=24;AL=01 is the enable A20 gate INT 15 function
 int 0x15 ; You can also use AH24;AL=3 to query support and
 ; AH=24;AL=02 to get the status. AL=00 disables ;)
 mov ax, 0x3 ; Use INT 10h to set video mode to VGA Text. There's
 int 0x10 ; quite a number of other screen modes to play with
 cli ; Clear the interrupt flag
 lgdt [gdt_pointer] ; Load the gdt table
 mov eax, cr0 ; get cr0 into eax
 or eax, 0x1 ; Set the protected mode bit on cr0 register
 mov cr0, eax ; Put this value back in cr0
 jmp CODE_SEG:boot2 ; long jump to code segment
;-- This is the beginning of the GDT struct
gdt_start:
 dq 0x0 ; This is our null segment, just 8 bytes of 00
gdt_code:
 dw 0xFFFF
 dw 0x0
 db 0x0
 db 10011010b
 db 11001111b
 db 0x0
gdt_data:
 dw 0xFFFF
 dw 0x0
 db 0x0
 db 10010010b
 db 11001111b
 db 0x0
gdt_end:

; need a gdt pointer structure to load this.
; A 16 bit field containing the GDT size followed by a 32 bit pointer 
; to the GDT

gdt_pointer:
 dw gdt_end - gdt_start
 dd gdt_start

CODE_SEG equ gdt_code - gdt_start
DATA_SEG equ gdt_data - gdt_start

bits 32
boot2:
 mov ax, DATA_SEG
 mov ds, ax
 mov es, ax
 mov fs, ax
 mov gs, ax
 mov ss, ax
 mov esi,hello
 mov ebx,0xb8000 ; memory location of text buffer
.loop:
 lodsb
 or al,al
 jz halt
 or eax,0x0100 ; 0x0200 = green. Use 16 bit color here
 mov word [ebx], ax
 add ebx,2 ; changing this to add ebx,3 makes it get all weird.
 jmp .loop
halt:
 cli
 hlt
hello: db "Finally made it to 32 bit mode!!",0

times 510 - ($-$$) db 0
dw 0xaa55

If you are wondering where a lot of these seemingly arbitrary values are coming from, I would highly recommend checking out the interrupt list, as well as numerous aging websites that desperately need you to archive them. Seriously, there is a ton of incredible info that is increasingly hard to find on very low level computing.

Grabbing your own MBR

If you are on linux, you can do this to get the MBR of your machine

First, look at your mounted disks, and find which one you boot from (example /dev/sda), then

sudo dd if=/dev/sda of=mbr.bin bs=512 count=1

Netspooky's Blog

BGGP6: REVIVING RDOFF PART 1

Motivations & Goals

What is RDOFF?

The Death of RDOFF

Failing To Generate An RDF

Patching The nasm Loader

Generating A Broken RDOFF

RDOFF File Analysis

RDOFF Scapy Implementation

Satisfying The Loader: rdx Analysis

Whoops, need a 32bit executable heap

iximeow saves the day

Executing RDOFF

Pouring One Out For RDOFF

What’s Next?

BGGP6 Wireshark Dissector Lua

DissectorTable.get

register_heuristic

Searching for smaller functions to call

Listener.new

about

BGGP6 Announcement

Phrack 72

BGGP5 Wrapped

tmp.0ut Volume 4

Phrack 72 CFP

impure89 Release

Phrack 71

Binary Golfing UEFI Applications (REcon 2024)

BGGP5 Announcement

Welcome To My Cool New On-Line Web Site

About Me

Contact

BGGP4: A 420 Byte Self-Replicating UEFI App For x64

Contents

Introduction

Why Is UEFI?

Getting Started

Basic UEFI Application

Understanding the x64 UEFI ABI

Printing 4 In Assembly

Quick Note On Debugging

Self Replicating

Wait WTH are protocols??

Interacting with the Filesystem

Reading The File Into Memory

Writing Data To A New File

Using Five Arguments In A Call

File Write

How Does UEFI Load Images?

Golfing The Binary

TinyPE

Creating A Testing Script

Exploring The Caves

jmp’ing Around The Header

Types Of Optimizations I Did

Assuming Addresses Are 32 Bit

Storing Data In The Header

Assuming RAX Is 0 After Calls

Reusing Values In Registers

Finishing Touches

Future Optimizations

Conclusion

Bad Will b2b DJ XLAT - XMAS MEGA MIX

easylkb: Easy Linux Kernel Builder

LKM Golf

tmp.0ut Volume 3

BGGP4 Results

How To Get A CVE Revoked

Bad Will x DJ XLAT - Live 7/1/23

BGGP4 Announcement

netspooky/pdiff2

Protocol RE Talk

acble - Apple Continuity Dissector

Wireshark Tips n Tricks

Install wireshark from source

Dark Mode

Useful Oneliners

Dissector Notes