8

Is there an easy way to extract all of the strings from Go binaries that will work cross architecture?

The problem with Go is that strings are stored without a null terminator so you can't use the "strings" command plainly.

I found two solutions so far -
https://github.com/CarveSystems/gostringsr2 - Extracts strings using references to the string section (by using radare2). But this method doesn't work 100% and screws up some strings because there are indirect references, etc...

https://github.com/strazzere/golang_loader_assist/blob/master/golang_loader_assist.py - Extracts strings by searching for "lea"/"mov" instruction to the string section. But this method only works for x86 architectures.

Is there a more generic and correct way to extract the strings from Go compiled binaries?

  • What is Go's native text encoding? For 7-bit ASCII look for runs of bytes >= space and < DEL. For 8-bit extensions to ASCII look for runs of bytes >= space. For UTF-8 there are specific bit patterns to look for in the various bytes of each multibyte character. For UTF-16 you need heuristics. ASCII-compatible runs have interleaves 0 bytes and bytes >= space. Unpaired surrogates are a flag that it's unlikely to be UTF-16 after all. In all cases the fidelity is lower than finding null-terminated strings. – hippietrail May 26 '20 at 3:13
  • @hippietrail I think that the native encoding is ASCII, but the problem is that GO saves it strings without null terminator.. So you can find only one huge blob of strings and I want to extract those strings "as is" one by one – Drxxd May 26 '20 at 7:29
  • According to this, GO uses UTF-8 for strings. If you don't want to have to split up the blobs yourself and strings are not terminated then it seems there is no "easy way" until somebody knowing all the architectures writes a unified tool using principles like the tools you mention use. In the meantime you might be able to analyse your binary with Ghidra. Ada Pro can surely do something too. But those are more heavyweight than you seem to be looking for and won't always find every string. – hippietrail May 26 '20 at 8:28
  • 1
    You referenced the project golang_loader_assist and it only supporting x86. If you'd like to submit a PR for updating is_string_load() for non-x86 patterns used by golang I'll gladly accept and apply them. AFAIK, there is no "easy" way to do this, which is why I resorted to this method. The calls for strings are preempted by the length, which is important since there is no null byte afterwards. – diff Jun 24 '20 at 19:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.