Reversing Go Binaries

Open a Go binary in Ghidra for the first time and you will be greeted by thousands of functions, megabytes of code, and almost none of it is the challenge author's logic. Go statically links its entire runtime, garbage collector, and standard library into every executable. A "hello world" is 1.5 MB+. Your job is to separate the handful of main.* functions you care about from the ocean of runtime.* noise.

The good news: Go binaries are far more recoverable than they look. Go embeds rich metadata about its own functions and types so the runtime can do reflection, panics, and stack traces. That metadata survives stripping, and the right tools turn it back into symbols.

Why Go Binaries Are Huge and Static

• Static linking by default. The Go toolchain links the runtime, scheduler, GC, and every imported package into one file. There is no libgo.so to leak from; ldd usually reports "not a dynamic executable".
• The runtime is always present. Goroutine scheduling, channel operations, and GC write barriers generate code in nearly every function. Expect calls to runtime.morestack_noctxt, runtime.newobject, runtime.mallocgc, and runtime.gcWriteBarrier everywhere.
• Reflection metadata is embedded. To support reflect, interfaces, and panics, the compiler emits type descriptors and a function table. This bloat is also your map back to symbols.

file ./chal
# ELF 64-bit LSB executable, x86-64, statically linked, stripped

# Quick "is this Go?" tells:
strings ./chal | grep -m1 "go1\."          # e.g. go1.24.3  → build version
strings ./chal | grep -m1 "Go build ID"
readelf -S ./chal | grep -E "gopclntab|go.buildinfo"

The .gopclntab section (or its in-memory equivalent located via moduledata) is the giveaway and the prize.

Symbol Recovery: The First Real Step

Never start reading a stripped Go binary cold. Recover symbols first.

# Download a prebuilt binary from the Releases tab, or:
go install github.com/mandiant/GoReSym@latest

# Dump everything (functions, types, build info) as JSON:
GoReSym -t -d -p ./chal > syms.json

# -t  recover type metadata
# -d  include default/standard packages (omit to see only user code)
# -p  include file path metadata

jq -r '.UserFunctions[] | "\(.Start)  \(.FullName)"' syms.json | head

The pclntab and moduledata

These two structures are the backbone of symbol recovery, so it is worth knowing what they are.

• pclntab maps every code address to a function name, source file, and line number — built so the runtime can produce stack traces and panic messages. Recovering it gives names like main.validateInput.
• moduledata is the root descriptor the runtime keeps per linked module. It points at the pclntab, the type table, the text segment bounds, and string/symbol tables. Tools locate moduledata (often via the runtime.moduledataverify / runtime.modulesinit signature) and walk outward from there.

The Go Calling Convention (This Trips Everyone Up)

The single most important thing to get right when reading Go disassembly is which calling convention the binary uses, because it changed.

RAX, RBX, RCX, RDI, RSI, R8, R9, R10, R11   (integer args, then results)
X0–X14                                       (float args/results)

Other convention quirks that hold across versions:

• Multiple return values are normal (e.g. (result, error)); they occupy successive registers/stack slots.
• The receiver of a method is just the first argument.
• Every non-leaf function begins with a stack-growth check (cmp rsp, [r14+0x10]; jbe runtime.morestack). Treat this prologue as boilerplate and skip past it.

Strings Are Not Null-Terminated

This is the second classic Go pitfall. A Go string is a two-word struct:

struct GoString {
    char *ptr;     // pointer to bytes — NOT null-terminated
    int64 len;     // explicit length
};

Consequences for reversing:

• Many "strings" are packed back-to-back in one giant .rodata blob with no separators. strings shows them concatenated, e.g. ...flagcorrectwrongusage.... The length lives in the code, not the data.
• A string load looks like loading a pointer and a length together (often lea/mov of an address plus an immediate length into the second register/slot).
• Tools like golang_loader_assist and the Ghidra extension specifically fix this: they read the length from the instruction and slice the correct substring.

# The naive way fails — everything runs together:
strings ./chal | grep -i flag

# Better: let a Go-aware tool extract length-correct strings
GoReSym -p ./chal | jq -r '.Files'      # source paths sometimes leak the flag context

Cutting Through Runtime Noise

Reproducible Workflow

file ./chal
strings ./chal | grep -m1 "go1\."        # build version drives the ABI
readelf -S ./chal | grep gopclntab

GoReSym -t -d -p ./chal > syms.json
jq -r '.UserFunctions[] | "\(.Start) \(.FullName)"' syms.json
redress pkg ./chal          # cross-check the package list

go tool objdump -s 'main\.' ./chal      # Go's own disassembler, symbol-aware
go tool objdump -S ./chal               # interleave source (if not stripped of it)

Checklist

• file / strings | grep go1. → confirm Go and read the build version
• Recover symbols with GoReSym before reading anything
• Cross-check packages/types with redress
• Load in Ghidra (GolangAnalyzer ext) or IDA (golang_loader_assist); re-analyze
• Pick the right calling convention: register-based (Go 1.17+) vs stack-based (older)
• Skip the morestack prologue and all runtime.* / reflect.* noise
• Treat strings as ptr+len — slice the exact length, never to a null byte
• Focus on main.*; follow runtime.newproc to find goroutine bodies
• Sanity-check with go tool objdump -s 'main\.'

See Also

• Static Analysis
• ELF Binaries
• Rust Binaries
• Obfuscation
• Ghidra

Last updated on Jun 15, 2026