GoReSym v3.4: struct field tags and string addresses recovered from Go binaries

What happened on this date

On 2026-07-01 (20:29 UTC), Mandiant published GoReSym v3.4 on GitHub. The release notes list two items: recovery of struct field tags (PR #97), and a start address for recovered Go strings so their virtual address can be identified (PR #100), both contributed by @kami922. According to the project README, GoReSym is a Go symbol parser that extracts the CPU architecture, compiler version, function start and end addresses and names, source file and line information, and embedded types from Go programs across ELF, PE and Mach-O on ARM64 and x86/x64, and it extends the upstream runtime code to cope with stripped binaries. The release is incremental, but it fills in exactly the kind of detail developers tend to forget is there.

What it means for protecting app logic

The Go runtime itself needs function tables and type information for stack unwinding, reflection and garbage collection, so stripping the symbol table does not make that metadata disappear. Struct field tags are typically used for JSON, database or configuration mapping, and they often spell out API field names, internal config keys or even feature-flag names. Attaching addresses to strings also makes it easier to connect text to the code that uses it. For teams shipping Go desktop clients, CLIs or local agents, a reasonable threat model is that package paths, function names, types and field tags are visible to anyone holding the binary. The honest boundary is that such tools recover structure and names, not the business logic itself; understanding rules still requires reading code. But names lower that cost considerably, and AI-assisted analysis benefits directly from readable hints like these.

Checks to run on your own builds

First, inventory your own release artifact: go version -m shows the embedded module and build information, and a strings pass shows which package paths and field tags remain, so you know what is public the moment you ship. Second, build releases with -trimpath to drop local file paths and with -ldflags "-s -w" to drop the symbol table and DWARF, while remembering that runtime metadata stays and this is not protection. Third, review field tags and constant names; if the names themselves reveal unpublished endpoints or pricing rules, consider moving that logic and configuration server-side. Fourth, if you adopt a Go-specific obfuscation tool, rerun the full test suite on the transformed build, paying special attention to reflection and serialization paths, then re-sign and re-notarize.

Your checklist

• Inventory modules, paths and field tags left in the release binary with go version -m and strings
• Build with -trimpath and -s -w, but do not treat that as logic protection
• Move configuration whose names reveal unpublished endpoints or rules server-side
• After any obfuscation, retest reflection and serialization paths and re-sign/re-notarize