Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reversing Go Binaries Like a Pro

rednaga.io

Post reply on HN
Print view View original

21–28 of 28 posts

Re: Reversing Go Binaries Like a Pro

#21

Post by jerf »

unwind wrote: post #20
razakel wrote: post #14

Earlier quoted context omitted.

>Just curious, is a Go string a C string inside (rune array + nil) or a proper class array? I can't imagine how you would even implement a string as anything other than a rune array. Even a Pascal string is just the string length followed by characters.

In Haskell strings are lists of characters ( https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-S... ). I hear not everyone is thrilled with the performance implications. :) Also not a Haskell programmer, and really not meaning to criticize. Haskell seems awesome and I should learn it some day.

Just so people know, there are arrays used for text manipulation in Haskell in the Data.Text library, and bytestrings in the ByteString library. The language as specified does indeed have strings in a linked list of numbers, but if you even remotely care about performance you don't use those, and most libraries don't either nowadays.

Re: Reversing Go Binaries Like a Pro

#22

Post by javathrowaway »

thwd wrote: post #16
razakel wrote: post #14

Earlier quoted context omitted.

>Just curious, is a Go string a C string inside (rune array + nil) or a proper class array? I can't imagine how you would even implement a string as anything other than a rune array. Even a Pascal string is just the string length followed by characters.

as C does: with a \00 end marker.

Yeah, and how do you store NUL chars in those C strings then?

The answer is you can't. Because prefix-length strings (Pascal) are far better than null-terminated (C) strings.

Re: Reversing Go Binaries Like a Pro

#23

Post by differentials »

mappu wrote: post #10

> You can quiet easily differentiate between custom code written for the binary, for example in the Linux malware “Rex” everything because with that name space! Really? It looks like only `runtime_` gets the prefix, so third-party libraries and code in go/src (e.g. `fmt`) would get mixed in here too, right?

Everything get prefixed by the package namespace, so things pulled from github.com/group_name/package ends up looking like `github_com_group_name_package_class_funcname. This why why "rebuilding" the function names was a good way to quickly filter out the "known" code from the malicious functionality.

Re: Reversing Go Binaries Like a Pro

#24

Post by ninov »

differentials wrote: post #23
mappu wrote: post #10

> You can quiet easily differentiate between custom code written for the binary, for example in the Linux malware “Rex” everything because with that name space! Really? It looks like only `runtime_` gets the prefix, so third-party libraries and code in go/src (e.g. `fmt`) would get mixed in here too, right?

Everything get prefixed by the package namespace, so things pulled from github.com/group_name/package ends up looking like `github_com_group_name_package_class_funcname. This why why "rebuilding" the function names was a good way to quickly filter out the "known" code from the malicious functionality.

Is this really how the names are represented internally? if so, how can it tell apart e.g. "github.com/group_name/package" and "github.com/group/name_package"?

Re: Reversing Go Binaries Like a Pro

#25

Post by mappu »

differentials wrote: post #23
mappu wrote: post #10

> You can quiet easily differentiate between custom code written for the binary, for example in the Linux malware “Rex” everything because with that name space! Really? It looks like only `runtime_` gets the prefix, so third-party libraries and code in go/src (e.g. `fmt`) would get mixed in here too, right?

Everything get prefixed by the package namespace, so things pulled from github.com/group_name/package ends up looking like `github_com_group_name_package_class_funcname. This why why "rebuilding" the function names was a good way to quickly filter out the "known" code from the malicious functionality.

So you can achieve smaller (/obfuscated) binaries by automatically renaming everything in $GOPATH to short unique strings? That would be a neat project.

Re: Reversing Go Binaries Like a Pro

#26

Post by differentials »

mappu wrote: post #25
differentials wrote: post #23

Earlier quoted context omitted.

Everything get prefixed by the package namespace, so things pulled from github.com/group_name/package ends up looking like `github_com_group_name_package_class_funcname. This why why "rebuilding" the function names was a good way to quickly filter out the "known" code from the malicious functionality.

So you can achieve smaller (/obfuscated) binaries by automatically renaming everything in $GOPATH to short unique strings? That would be a neat project.

Yes, you could in theory rename everything prior to compilation for obfuscation/space saving - similar to how (some) Java protections worked.

Re: Reversing Go Binaries Like a Pro

#27

Post by differentials »

ninov wrote: post #24
differentials wrote: post #23

Earlier quoted context omitted.

Everything get prefixed by the package namespace, so things pulled from github.com/group_name/package ends up looking like `github_com_group_name_package_class_funcname. This why why "rebuilding" the function names was a good way to quickly filter out the "known" code from the malicious functionality.

Is this really how the names are represented internally? if so, how can it tell apart e.g. "github.com/group_name/package" and "github.com/group/name_package"?

Good question, I assume there is some way the compiler/runtime would dedupe these for the coder at compile time. However I don't honestly know enough about the Go internals... Honestly, I wrote more Go code during this blog post than I ever had, even though I had been reversing it for a while...

Re: Reversing Go Binaries Like a Pro

#28

Post by unwind »

jerf wrote: post #21
unwind wrote: post #20

Earlier quoted context omitted.

In Haskell strings are lists of characters ( https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-S... ). I hear not everyone is thrilled with the performance implications. :) Also not a Haskell programmer, and really not meaning to criticize. Haskell seems awesome and I should learn it some day.

Just so people know, there are arrays used for text manipulation in Haskell in the Data.Text library, and bytestrings in the ByteString library. The language as specified does indeed have strings in a linked list of numbers, but if you even remotely care about performance you don't use those, and most libraries don't either nowadays.

Thanks! I guess I was kind of hoping for someone with actual knowledge to fill in the details.
Post reply on HN