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.

Go-Specific Security Review

If the job is finding bugs rather than understanding behaviour, the Go-specific classes worth targeting:

• Ignored errors. _ = on a function returning an error, especially around auth, crypto, and file operations.
• math/rand for security values. Token, session ID, or nonce generation using the non-crypto RNG.
• InsecureSkipVerify: true in a tls.Config.
• fmt.Sprintf building SQL, shell commands, or URLs.
• Data races on shared maps and structs — often the source of authorization bugs under load.
• os/exec with a shell, or with an argument built from input.

With source available, use auditing-code-for-vulnerabilities and govulncheck; the above is for when you only have the binary.

Go Malware Notes

Go is common in cross-platform implants, and it leaves useful artifacts:

• Module list from go version -m identifies the frameworks used — networking libraries, crypto, and sometimes the C2 project itself.
• Build paths in the symbol table leak developer usernames, project names, and directory structures.
• main. package function names frequently survive because stripping does not remove pclntab, giving you a capability list for free.
• Some samples strip pclntab deliberately or use tools that mangle moduledata. When GoReSym and redress both fail on a sample that is otherwise clearly Go, treat that as an evasion indicator worth reporting — and fall back to scanning for the type descriptors directly.

Hand IOC and detection output to analyzing-malware and engineering-detections.

Rationalizations to Reject

• "It's stripped, so there are no symbols." strip does not remove pclntab. Run GoReSym before concluding anything.
• "The decompiler output is garbage." It is using the wrong calling convention. Apply a Go-aware plugin.
• "Thousands of functions, this will take weeks." Almost all are runtime and stdlib. Filter to main.* and vendored modules.
• "The strings are all mashed together." Go strings are pointer+length. Slice by the length constant.
• "The tool failed, this binary is protected." Check the Go version against the tool's supported pclntab versions first.
• "I need to trace every goroutine." Find runtime.newproc call sites and read the function passed to them.

References

• analyzing-binaries — general triage and dynamic analysis around this
• analyzing-malware — containment and IOC extraction for Go samples
• auditing-code-for-vulnerabilities — the Go bug-class checklist when source exists
• GoReSym, redress, AlphaGolang, GolangAnalyzerExtension, go version -m