


Less so to have to fix the tooling they’re attempting to rely on. We can’t expect everyone to be an expert in Go in order to understand their way around a binary. With AlphaGolang, we wanted to tackle two disparate problems simultaneously– the brittleness of IDApython scripts for Go reversing and the need for clear steps to analyze these binaries. However, those projects were largely monolithic labors of love by their original authors and given the fickle nature of IDA’s APIs, once those authors got busy, the scripts fell into disrepair.

This isn’t the first time brave souls in the community have attempted to improve the Go reversing experience for IDA.
Ida hide debugger full#
For folks stuck on v7.5 or lower, we’ll also provide some help by way of scripts but the full functionality of AlphaGolang is unlocked with 7.6 due to some missing APIs (specifically the ida_dirtree API for the new folder tree view). With the advent of version 7.6, IDA’s native support of Go binaries is drastically better and we’ll be building features on top of this. BinaryNinja and Cerbero have improved their native support for Go and there are now standalone frameworks like GoRE that offer good functionality depending on the Go compiler version and can even help support other projects like radare2. Different disassemblers and decompilers have stepped up their Go support. However, the situation has changed in the past few years and we should reassess our collective abhorrence of Go malware. With all those inadvertent obstacles in mind, it’s perfectly understandable that reversers dreaded analyzing Go binaries. Good luck navigating that without symbols. For us it translates into a mess of runtime function prologues before any meaningful functionality. Go is peculiar in allocating a runtime stack owned by the caller function that will in turn handle arguments and allow for multiple return values. While a debugger certainly helps determine arguments at runtime, it’s important to understand how indirect that runtime is.
Ida hide debugger manual#
The issue of arguments should prove disturbing for our dynamic analyst friends who were hoping that a debugger would spare them the trouble of manual analysis. That’s without getting into the complexities of recovering structures, accurately portraying function types, interfaces, and channels, or properly tracing argument references. “Hello World!” string lost in a sea of unrelated strings.Įven the better disassemblers and decompilers tend to display these unparsed string blobs confusing their intended purpose. That’s a much safer implementation but it means that even a cursory glance at a Go binary means dealing with giant blobs of unrelated strings. The linker places strings in incremental order of length and functions load these strings with a reference to a fixed length.

To make things worse, Go doesn’t null-terminate strings.
Ida hide debugger code#
Hello World source code Mach-o binary = 2.0mb That bulky size entails a maze of standard code to confuse reverse engineers down long unproductive rabbit holes, steering them away from the sparse user-generated code that implements the actual functionality. The binaries are then easily stripped of debug symbols and can be UPX packed to mask their size quite effectively. Due to the approach of statically-linking dependencies, the simplest Go binary is multiple megabytes in size and one with proper functionality can figure in the 15-20mb range. Go binaries present multiple peculiarities that make our lives a little harder. Our hope is that members of the community will feel inspired to share additional resources to bolster our collective analysis powers.Ī Quick Intro to the Woes of Go Binary Analysis
Ida hide debugger pro#
In an attempt to further dispel that myth, we’ve set out to share a series of scripts that simplify the task of analyzing Go binaries using IDA Pro with a friendly methodology. While our tooling has generally improved, the perception that Go binaries are difficult to analyze remains. On the other hand, for analysts, it’s meant learning the inadequacies of our tooling and contending with a foreign programming paradigm. The language offers great benefits for malware developers: portability of statically-linked dependencies, speed of simple concurrency, and ease of cross-compilation. The increasing popularity of Go as a language for malware development is forcing more reverse engineers to come to terms with the perceived difficulties of analyzing these gargantuan binaries.
