Analyzing Go Binaries

Analyzing Go Binaries

Go binaries look hostile — statically linked, tens of megabytes, no imports you recognize, and "stripped" in a way that makes tools show thousands of sub_ functions. They are not. Go ships its own symbol table for runtime reflection and panic traces, and strip does not remove it. Recover it and the binary becomes one of the easiest targets there is.

When to Use

• strings shows runtime.main, go:buildid, go.buildinfo, or runtime.gopanic
• A "stripped" binary is 5–50 MB with almost no dynamic imports
• The disassembler shows thousands of unnamed functions and unreadable strings
• Analyzing Go malware, a Go CLI tool, or a compiled Go service

When NOT to Use

• Rust binaries — use analyzing-rust-binaries; the symbol recovery is entirely different
• .NET assemblies — use analyzing-dotnet-assemblies
• Suspected malware, before containment — use analyzing-malware for the environment, then come back here
• General native RE — use analyzing-binaries

Confirm It Is Go, and Which Version

strings -n 6 target | rg -m5 'go1\.[0-9]+|go:buildid|runtime\.main|GOROOT'
go version target                     # works on unstripped and many stripped builds
go version -m target                  # module list and build settings — free SBOM

go version -m is the highest-value first command. It prints the module dependency graph with versions, which gives you the third-party libraries in use before you disassemble anything — often answering the question outright (which HTTP library, which crypto, which C2 framework).

The Go version matters because pclntab layout changed at 1.2, 1.16, 1.18, and 1.20. Tooling that fails is usually version mismatch, not a hardened binary.

Recover Symbols

# GoReSym — extracts pclntab, moduledata, types, and build info
GoReSym -t -d -p target > syms.json
#   -t  user type metadata
#   -d  include standard library
#   -p  paths

# redress — Go-aware analysis, works well when GoReSym struggles
redress info target
redress symbols target
redress types target

# Load into the disassembler
#   IDA:    AlphaGolang, golang_loader_assist, or the GoReSym IDA script
#   Ghidra: GolangAnalyzerExtension, or gotools
#   Binja:  the Golang loader plugin

After applying symbols, functions carry their real names — main.processRequest, crypto/tls.(*Conn).Handshake, github.com/vendor/pkg.Function. Filter to main.* and to third-party module paths. Everything under runtime., internal/, and the standard library is stock and is 90%+ of the function count.

jq -r '.UserFunctions[].FunctionName' syms.json | rg -v '^(runtime|internal|reflect|sync)\.' | head -40

Reading Go Code in a Disassembler

Four things make Go listings confusing until you know them:

Strings have no terminator. Go strings are a pointer plus a length, so strings output runs adjacent literals together and the disassembler shows a pointer load followed by a length constant. Look for the pair — the constant next to the pointer is the length, and that is how you slice the correct substring out of the blob.

Calling convention. Before Go 1.17 all arguments and return values went on the stack, not in registers. From 1.17 a register ABI applies on amd64/arm64. A decompiler configured for the C convention will show wrong arguments; Go-aware plugins fix this, and it is the main reason decompiler output looks nonsensical.

Interface dispatch. Calls through an interface go via an itab — a table holding the concrete type and its method pointers. To resolve a call target, find the itab being loaded, then read the concrete type. Type recovery tools name these, which turns an indirect call into a readable one.

Goroutines and defers. go f() compiles to runtime.newproc with f as an argument, so concurrent logic does not appear as a direct call. defer becomes runtime.deferproc/deferreturn, which scatters cleanup code away from where it was written. When following control flow, check newproc call sites for work you would otherwise miss entirely.

Type Recovery

Go embeds full type descriptors for reflection. That means struct field names and layouts are recoverable — including the JSON tags that map straight to a wire protocol.

redress types target | rg -A10 'type main\.'
# Struct tags like `json:"api_key"` recover the exact protocol field names

This is the fastest route to a Go service's API surface or a Go implant's C2 message format: recover the request and response structs, and you have the protocol without reading a single instruction.