Scripts for recovering string definitions in Go binaries with P-Code analysis. Tested with x86, x86-64, ARM, and ARM64.
These can be found in the Golang category in the Script Manager.
GoDynamicStrings.java
GoFuncCallStrings.java
GoStaticStrings.java
GoKnownStrings.java
data/known_strings.json.GoStringFiller.java
go.string.* after initial analysis, based on ascending length order of string data.There are also a couple of special variations of the dynamic string analysis script:
GoDynamicStringsSingle.java
GoDynamicStrings.java, but uses a single decompiler process. Use this if analyzing a binary causes the parallel decompiler processes to exhaust system memory.GoDynamicStringsHigh.java
This can be found in the PCode category in the Script Manager.
PrintHighPCode.java
Here’s the general flow for using these scripts to recover string definitions in a Go binary:
.rodata, .rdata, or __rodata. Then right-click in the code listing and choose "Clear Code Bytes".GoKnownStrings.java to detect some standard strings.GoStaticStrings.java.GoFuncCallStrings.java (if the Golang binary version is supported by Ghidra's built-in Golang features).GoDynamicStrings.java.GoStringFiller.java.
go.string.* at the first one byte string.go.string.*, and define any strings with obvious start and end points.
GoStringFiller.java, identify where the string lengths are changing over in undefined string data and define the strings closest to that boundary. Then re-run GoStringFiller.java to automatically fill in spots where it can correctly determine the length of remaining undefined strings.In Ghidra:
For Eclipse with GhidraDev plugin:
Build with Eclipse:
Build directly with Gradle:
$ cd Ghostrings
$ gradle -PGHIDRA_INSTALL_DIR=<ghidra_install_dir>A well-known issue with reverse engineering Go programs is that the lack of null terminators in Go strings makes recovering string definitions from compiled binaries difficult. Many of a Go program's constant string values are stored together in one giant blob in the compiled build, without any terminator characters built into the string data to mark where one string ends and another begins. Even a simple program that just prints "Hello world!" has over 1,500 strings in it related to the Go runtime system and other standard libraries. This can cause typical ASCII string discovery implementations, such as the one provided by Ghidra, to create false positive string definitions that are tens of thousands of characters long.
Instead of null terminated strings, Go uses a string structure that consists of a pointer and length value. Many of these string structures are created on the program’s stack at runtime, so recovering individual string start locations and length values requires analyzing the compiled machine code. There are a few existing scripts that perform this analysis by checking for certain patterns of x86-64 instructions, but they miss structures created with unhandled variations of instructions that ultimately have the same effect on the stack, and they're also restricted to a specific ISA.
Ghostrings avoids both these problems by working with the simplified, architecture independent P-Code operations produced by Ghidra’s decompiler analysis.
Copyright 2022 NCC Group. Released under the GPLv3 license (see LICENSE).
Main project author: James Chambers [email protected]