add a 'strings' command

[0xdevalias]

It would be cool if GoReSym had a built-in command like strings that could be run on a compiled golang binary.

See Also

I did some quick googling and came across this tool written in python that wraps radare2:

• https://reverseengineering.stackexchange.com/questions/24999/extracting-strings-from-go-binaries
  • https://github.com/ivision-research/gostringsr2

    • gostringsr2
gostringsr2 extracts strings from a Go binary using radare2

• add a 'strings' command goretk/redress#33

[williballenthin]

agree this would be useful!

additional research and implementation here: https://github.com/mandiant/flare-floss/blob/master/floss/language/go/extract.py

[the-m3chanic]

Hi! I would like to look into this and try and see if I can work on it. What knowledge would I need in order to do so? I am familiar with python programming and have done Golang Reverse-Engineering in the past, and am also familiar with memory, would I be a good fit?

[stevemk14ebr]

hey @the-m3chanic if you're interested in working on this, I say absolutely take a shot at it! We are interested in a near direct port of the capa python string extraction logic (https://github.com/mandiant/flare-floss/blob/master/floss/language/go/extract.py) into GoReSym. That would mean take the existing python code and re-write it to GoLang for inclusion in GoReSym. Requirements:

• Add the new command as a -strings commandline flag. If the -strings flag is present GoReSym should execute the string extraction logic and output the strings as a new entry in GoReSym's JSON output. If it's not present, do not do any string parsing of any kind.
• Test the string extraction logic on all versions of Go. Extend the existing (basic) unit tests to verify that some strings are correctly extracted from each Go version we test again. I have a helper script that uses a dockerfile to build example binaries of each Go version easily, see https://github.com/mandiant/GoReSym/blob/master/build_test_files.sh and https://github.com/mandiant/GoReSym/blob/master/main_test.go which is executed by go test
• Do not introduce new dependencies into GoReSym. There should be the necessary file parsers built in already

There's no pressure for this work, if you make progress just submit a PR. I will merge the work after a few rounds of code review when the quality is up to par. Thanks for you interest!

[the-m3chanic]

Thank you so much for all the info and help! I will start working on this right away, however a little slow-paced as I have my end-semester exams coming up. I shall keep you posted on my progress. 👍
(Is there any way I can contact you to maintain communication? If you're okay with that)

[stevemk14ebr]

There is no rush at all @the-m3chanic any contributions you decide to submit are purely up to you. As far as contact I'd prefer to work via github, that is the easiest for me to keep track of. If you require more hands on mentoring later we can cross that bridge at that time. For now, just submit issues and/or pull requests as you see fit and I will get to responding to them as I'm available

[HelixY2J]

Hi, I would like to work on this issue. I went through above discussion and a little part of the codebase,from what I understand, we need to add a new --strings commandline flag in main.go. Its boolean pointer will be passed to main_impl(). I have a doubt about where the actual string extraction logic should go. Which existing file or layer should handle it ? I want to place the ported FLOSS logic in the right part of the codebase.

Second doubt - do go binaries use stack strings or are all strings stored in heap sections? If go doesnt use stack based string storage then stack string extraction logic from FLOSS might not be directly portable. Please give your suggestions on it and are any other concepts I should know with before jumping into the coding. Thanks

[stevemk14ebr]

Awesome @HelixY2J ! If possible I'd like as much of the code to be in a strings.go file or similar, but we'd likely need to leverage some of the existing file reading APIs such as read_memory which exist internally in GoReSym. If necessary I would have no issue with other changes more deep in the code base exposing the necessary file reading APIs, you could add new ones or slightly change existing APIs within the wider code base. If you'd like to review the problem and propose a design I think that would go well and then we can discuss specifics together.

If you haven't seen it the blog https://cloud.google.com/blog/topics/threat-intelligence/extracting-strings-go-rust-executables/ might be helpful. We can consider proper stack strings out of scope for this work. I'd expect a solution to be able to recover the normal Go string structures. Strings that are encrypted by a tool such as garble or goobfuscate would also be out of scope. The Go string structures (a pointer to the string data and string length) can exist on both the stack/assembly and within the data section(s) as a global. No matter where the structure fields themselves are the string pointer usually (always?) points into a large string internment table within the data section.

The solution would be responsible for recovering the string pointer and it's associated length. Once those are found it would need to read the data pointed at by the pointer up to length, validate the string is valid, and then continue on to find the next string. Output should be contained within the JSON blob GoReSym emits. When the -human flag is used it should output the strings verbatim with no JSON wrapper.