Nice question—hooking Go binaries is notoriously tricky due to how the compiler handles function inlining and the runtime stack.
Couple of things to consider:
1. **Function Inlining by Go Compiler**
If you're targeting internal functions (like crypto or syscall wrappers), Go aggressively inlines them—even in debug mode. This makes your hook target disappear or get embedded in multiple call sites.
Try rebuilding the binary with:
go build -gcflags=“all=-l -N”
markdown
`-N` disables optimizations, and `-l` disables inlining. That should preserve function boundaries and make Frida effective again.
2. **No Exported Symbols**
Unlike native C/C++ binaries, Go doesn’t expose symbol names in a standard way. You'll need to use Frida’s `Module.findExportByName()` with raw addresses or do manual offset calculation via `objdump` or `gopclntab` parsing.
3. **Use gofrida or a custom resolver**
Check out [gofrida](https://github.com/lasting-yang/frida-go-hook) – it’s tailored for hooking Go symbols in Frida. Alternatively, manually parse the `runtime.pclntab` to resolve function names to offsets and then attach your hook.
4. **Thread Hijack Prevention**
Go manages its own scheduler (GMP model), which can block your Frida thread hijack if you don’t sync with its runtime. In some cases, inline syscalls inside goroutines can’t be reliably intercepted due to Go’s stack splitting.
If you share the binary or function you're trying to hook (e.g., net/http, syscall, crypto), I can suggest exact offsets or patch targets.
Respect for diving into Frida + Go—this rabbit hole goes deep.