27 comments

[ 3.8 ms ] story [ 80.5 ms ] thread
I'm getting a Chromium security error because this website is presenting a certificate from *.github.com.
Me too.
Author here... Link was submitted using https which I had not set up yet. Just switched over to a CF nameserver so it should be working shortly...
It's my fault. I use HTTPS Everywhere in full HTTP blocking mode, so when a link isn't HTTPS I just try manually, and accept the error for common Akamai and Github Pages certs, which is still much better than HTTP (for random sites).

But then I ended up submitting that broken link. The interesting thing is that it reached the top (#4 right now) of HN anyway.

Go? Reversing? Say no more, have an upvote!
> 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"?
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...
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.
Just curious, is a Go string a C string inside (rune array + nil) or a proper class array?

In other words, in

a:="b"+"c"

IOW, does it implement the Slemiel's painting algorithm or not?

I'm not sure I 100% understand your question, but in Go a string is a two-word struct.

    type string struct {
        data unsafe.Pointer
        len int
    }
The C version would be

    typedef struct string {
        const *char data;
        int len;
    } string;
Edit: oh, ok. I Googled the "painting algorithm" reference. I swear I had read that before :-)
>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.

> I can't imagine how you would even implement a string as anything other than a rune array.

You can also implement strings using a tree data structure. We do this in an implementation of Ruby that I work on because it can make concatenation faster.

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.
Glad to see the code still looks like crap, beautiful assembly, so using any of that is not going to make sense. Which is good news for distributing a Go binary.