Go pclntab Parser for Stripped Binaries

[martclau]

What is the feature you'd like to have? I would like Binary Ninja to automatically detect, parse, and utilize the pclntab (PC line table) structure in Go binaries, especially when the binary has been stripped of debug symbols. The feature should:

• Automatically locate the pclntab structure within Go binaries (both stripped and unstripped)
• Parse the pclntab to extract function names, source file paths, and line number mappings
• Restore function symbols and naming in the disassembly view
• Provide source code line number information where available
• Handle different Go compiler versions and their varying pclntab formats
• Integrate seamlessly with Binary Ninja's existing Go binary analysis capabilities

Is your feature request related to a problem? Yes, this addresses a significant challenge when analyzing stripped Go binaries. Without pclntab parsing, analysts must:

• Manually identify and name functions
• Lose valuable context about the original source structure
• Spend significantly more time understanding the binary's functionality
• Miss connections between related functions that would be obvious with proper naming

Are any alternative solutions acceptable? External tool integration: The GoReSym plugin can be used manually, but this fails to resolve all symbols and creates an additional manual step.

Additional Information:

• The pclntab structure varies between Go versions, with significant changes around Go 1.2, 1.16, and 1.18+
• Tools like IDA parses the pclntab out of the box
• The pclntab typically begins with a magic number (0xFFFFFFFB or 0xFFFFFFFA) making it relatively straightforward to locate
• Go binaries also contain a moduledata structure that can provide additional metadata
• This feature would complement Binary Ninja's existing Go string recovery and type analysis
• Reference implementations exist in open-source tools like redress and GoReSym

Sample Go binary characteristics that could benefit from this feature:

• Stripped binaries compiled with go build -ldflags="-s -w"
• Production Go applications where symbol information is crucial for security analysis
• Malware written in Go where function identification significantly aids analysis

[martclau]

The relevant Go source files would be:

https://go.dev/src/debug/gosym/pclntab.go https://go.dev/src/debug/gosym/symtab.go

[martclau]

Any update on when this will be implemented? It’s really difficult to reverse Go binaries without having the internal available. See also https://hex-rays.com/blog/stop-guessing-and-start-going.

[fuzyll]

Better support for Go binaries is on our roadmap, but we're busy finishing up changes and beginning release testing on our upcoming 5.2 stable version. After that, I would expect a lot of people to be taking time off for various end-of-year holidays. So, while I would say this is something we're likely to be looking at soon, I would not expect significant movement on this issue until early next year.

[martclau]

I see that you’ve labeled this request as specific to ELF files, but just to clarify: the Go data structures needed to recover function and type information are actually the same across ELF, PE, Mach-O, and other binary formats. The container format changes, but the Go metadata layout does not.