field tag and method name is not parsed

[virusdefender]

now field tag and interface method name is not parsed, it can not be obfuscated in many cases ( such as is used in reflection)

reference: https://github.com/goretk/gore/blob/3009b3909f08fa910e5a93d893bb66117f3628f9/type2.go#L149

[Sumanthsec]

Hi, I’m interested in working on this issue as part of exploring the GoReSym project for GSoC 2025. I’m fairly new to reversing Go binaries, but I’ve been reversing C binaries and Windows malware for the past few months and really enjoyed it. This issue looks like a great way to start understanding how Go internals work and to get hands-on with the codebase. Looking forward to digging into it!

— Sumanth

[Sumanthsec]

Hey @stevemk14ebr , I’m currently digging into how the struct layout for typelinks and itablinks might have changed in Go 1.24.1. I’m comparing it with Go 1.20 to spot any differences that could explain why type/interface recovery is failing. Any pointers or advice on what parts of the runtime changed or what to focus on would be super helpful!

[stevemk14ebr]

I'm going to bet the rtype (runtime type) structures changed slightly. Generally I check the branches of the upstream Go code and inspect commits to the relevant internal type structures. They name their branches after the release versions so it's not too crazy to identify which files were changed across versions and inspect the individual commits that are relevant.

https://github.com/golang/go/blob/master/src/runtime/type.go is a decent starting point. First thought is probably related to the type changes mentioned in their blog here: https://go.dev/blog/coretypes

Figuring out where GoReSym goes off the rails under a debugger can help to identify which runtime code upstream needs inspected more closely.

[Sumanthsec]

Thanks for the guidance! You were spot on—rtype was indeed refactored in Go 1.24 to embed *abi.Type, and many fields like hash, str, and kind are now accessed through that. Structs like interfacetype and functype were also moved to internal/abi. I confirmed the breaking changes—will now update GoReSym to handle the new layout based on Go version. Appreciate the pointers!

Also, I just noticed the GSoC deadline is approaching and wanted to ask if there’s still any chance I could be considered. I’d really love the opportunity to work on this. I’ve been building malware in C/C++ and reversing C binaries for the past few months, and once I saw how tools like Sliver use Go, I realized how much harder Go binaries are to reverse—so this project really aligns with what I want to dive into this summer.

[stevemk14ebr]

You're welcome, good job finding the specifics out! Request to be considered heard, fine by me. For now keep poking around areas you'd like to work on and we can start submitting PRs whenever you have time and like. Thanks for considering GoReSym!

[Sumanthsec]

Thanks a lot for the support and encouragement! 🙏 I just submitted my GSoC application for GoReSym — really excited about the opportunity to keep contributing and help push this project forward. I’ll continue exploring more areas to work on and start submitting PRs soon.

[Sumanthsec]

Hey @stevemk14ebr ,

Over the past few weeks, @krishnay13 and I have been working through the codebase, focusing on understanding symtab and pclntab. We’ve documented our exploration of their layout, contents, and how GoReSym interacts and parses both tables.

We also tested the tool on Go versions 1.20 and 1.24, carefully noting and documenting the differences. We’re currently working on creating a PR to address the issue soon.

As a quick reminder — I was previously accepted as a GSoC contributor for GoReSym, and as suggested in our discussions, I’m now contributing as an OSS contributor instead. Really excited to continue collaborating and would appreciate any feedback on our progress!

Thanks!

[mrtaz77]

Hi @stevemk14ebr, I'm mrtaz. I've started exploring this issue as part of my
GSoC 2026 interest in GoReSym (see my discussion
here).

I've reviewed PR #38 and understand the correctness issues you flagged —
particularly around the Go 1.20 code path, rtype flag handling, and
name_len adjustments. Before I go deeper, I wanted to ask:

1. Is the approach from PR parse field tag and interface method name #38 still the right direction, or would you
   recommend a different starting point given the Go 1.24 rtype refactoring?
2. Are there specific files in objfile/ you'd point me to first?

Happy to start submitting draft PRs as I make progress!