Reverse engineer a Go binary with Ghidra via MCP
Huli had Cursor drive GhidraMCP to identify a Golang binary, list its routes and find a path traversal, but it missed the SQL injection check.
What they did
Huli built a stripped Golang gin server with a deliberate SQL injection and path traversal, loaded it into Ghidra with the GolangAnalyzerExtension, then connected GhidraMCP to Cursor so the agent could call Ghidra's decompiler itself. Prompted only to identify the binary and its functions, it autonomously queried MCP, then was asked to reconstruct the Go source and check for vulnerabilities.
How it went
Using Cursor's composer 1.5, it correctly recovered routes, libraries, and file structure (with minor route-name errors) and found the path traversal bug but reconstructed the SQL injection code as already fixed, missing it. Switching to Opus 4.6 on the same prompt caught both vulnerabilities but still mislabeled some routes.
Worth knowing
Results varied heavily by model: a weaker model (composer 1.5) missed the SQL injection that a stronger model (Opus 4.6) caught with the same prompt.
Labels
then was asked to reconstruct the Go source and check for vulnerabilities.
Huli built a stripped Golang gin server with a deliberate SQL injection and path traversal, loaded it into Ghidra with the GolangAnalyzerExtension
then connected GhidraMCP to Cursor so the agent could call Ghidra's decompiler itself.
Huli built a stripped Golang gin server with a deliberate SQL injection and path traversal
The “Material” label failed its quality check and is not used for selection.
Details
- Agents
- Cursor
- Source
- other
- Source date
- Mar 1, 2026
- Accounts
- 1
- In registry since
- Oct 12, 2026