Blackrota: obfuscated backdoor written in Go | Hacker News Reader

Blackrota: obfuscated backdoor written in Go

blog.netlab.360.com

162 pointslsllc25 comments

It looks like gobfuscator just modifies the source code by renaming package and file names to random strings, and adds string encryption. The resulting source code is compiled by the Go compiler as usual, and no further obfuscation is applied.

This is fairly weak: Go runtime functions are unobfuscated, and package names are consistently renamed (that is, if "geacon" is renamed to "ammopppfcdmmecpgbkkj" in one function, it's renamed that way consistently for all functions). This in turn should make it much easier to deobfuscate by gradually expanding the set of "known" package, class and function names.

XOR-encoding of strings is slightly annoying, but since gobfuscator replaces each string with an anonymous function, you could in principle write a simple Unicorn script to emulate each string decoder function, coupled with some heuristics to detect such functions (e.g. just look for functions which have an xor and a single call to runtime_slicebytetostring).

Having worked on really "heavily obfuscated" code (flattened control flow, functions implemented in obfuscated VMs, custom incompatible ABI, cryptographic encryption of code, etc.), this gobfuscator looks comparatively easy :)

What is your background? Your experience sounds very interesting.

They have their website [0] in their profile, which has some interesting background.

[0] https://robertxiao.ca

Man, that Dragon CTF was awesome.

Excellent analysis

Seems very reminiscent of early java bytecode obfuscators.

> 'Having worked on really "heavily obfuscated" code (flattened control flow, functions implemented in obfuscated VMs, custom incompatible ABI, cryptographic encryption of code, etc.), this gobfuscator looks comparatively easy :) '

For any HN readers who have not already encountered the MOVfuscator [1] I cannot recommend this Blackhat talk highly enough -- the x86 MOV instruction is turing complete, and it flattens arbitrary code to MOVs. It's also the only time I've ever seen brainfuck being used as a seriously sensible intermediate language ;-)

[1] https://www.youtube.com/watch?v=R7EEoWg6Ekk [I think this is the preferred link!]

It of course also runs doom. Sort of. https://github.com/xoreaxeaxeax/movfuscator/tree/master/vali...

The "sort of" part is fantastic:

The mov-only DOOM renders approximately one frame every 7 hours, so playing this version requires somewhat increased patience.

I might finally beat nightmare!

I cant really enjoy articles like this after seeing: https://z0mbie.dreamhosters.com/ (yes, site looks like crap by today standards, but author was an evil genius)

and

https://z0mbie.dreamhosters.com/autorev.txt https://z0mbie.dreamhosters.com/src/mistfall2/index.html

"The virus supports a unique new technique: code integration. The Mistfall engine contained in the virus is capable of decompiling Portable Executable files to its smallest elements, requiring 32MB of memory. Zmist will insert itself into the code: it moves code blocks out of the way, inserts itself, regenerates code and data references (including relocation information), and rebuilds the executable. This is something that has not been seen in any previous virus. Zmist occasionally inserts jump instructions after every single instruction of the code section, each ofwhich will point to the next instruction. Amazingly, these horribly modified applications will still run as before, just like the infected executables do, from generation to generation. In fact we have not seen a single crash during the test replications. Nobody expected this to work, not even its author Zombie.Although it is not foolproof it seems to be good enough for a virus. It takes time for an individual to find the virus in infected files, due to Zmist's extreme camouflage, making it the perfect anti-heuristics virus."

Search here for Zmist (Mistfall is the engine with sources in previous links) description: https://crypto.stanford.edu/cs155old/cs155-spring09/papers/v...

What I am seeing today as malware is a joke compared to those times. The knowledge is just lost.

That's pretty awesome indeed.

(And of course, the main source file is named hooy.cpp)

It's really not; it's just that malware of today does much more than that.

Reference please? I am not talking here about bright ideas... I am talking about something that is really bitch to implement (quite frankly I would rather take tinycc and mutate the c source (same goes for go source code) before compiling than going the LDE and Mistfall way but there might be something that I have missed in all those years) and I would love to see something that is beyond this. And imho, no, various payloads/drivers/rootkits/uefi/..., etc. doesnt come close in level of complexity. They are just bright ideas, but please I really would love to prove me wrong.

I would love to give some other example next time instead of 20+ years old piece of code. Please share the knowledge.

Today you’ll probably see the most obfuscation in DRM software.

The image in the website says in Russian "Knowledge is the reward for action".

It is interesting how in the modern computing, the whole “virus” (arbitrary-code-modifying, self-propagating) model s basically irrelevant. Sure, there is plenty of malware around, but it is all either “trojan” (distributing pre-modified binaries), or “worm” (entirely separate binaries).

The biggest contributing factor is likely internet - I don’t think I ever passed executables from one computer to another. The modern package management (think debsums), multi-user separation, digital signatures, open source and “cattle servers” helped a lot too.

It ia still interesting to read about old techniques, they were very ingenious, but it is approximately as relevent as steam train maintenance.

Wouldn't those sorts of modifications make the executable fail signature checks? I think most viruses don't use that sort of technique anymore because code signing prevents that sort of attack.

I've been experimenting with a technique for string vectorization: create a "basis space" of N random strings. The vector of string S is

`[edist(S, b) for b in basis]`

Where edist is some Levenshtein edit distance. You can build feature vectors from these by analyzing adjacency within logical blocks. Take other known Go software, obfuscate it, and vectorize it on the same basis. Even though the obfuscation is random, similar code chunks should project to a similar "shape" manifold.

The obfuscation appears to be Go being statically linked, so there's a large number of functions to comprehend, along with the humans running the source code through a Go-code obfuscator that renames all functions to randomly-chosen strings, and XOR-encoded any printable strings.

That type of obfuscation is pretty common for PHP malware. The only thing notable here is that the original, human-written source is Go.

> That type of obfuscation is pretty common for PHP malware. The only thing notable here is that the original, human-written source is Go.

Yes, I can attest that. I worked for a company with a team of malware researchers and this was a common obfuscation technique. I would not say the use of Go is novel either. I have reviewed several pieces of malicious code and exploits written in Go in the last five years or so.

If someone wants you to run code that's obfuscated, and it's not a game, it might be a good idea to ask "why"? It might be legitimate code... but it might not be. Yes, yes, some proprietary software is shipped that way... but a lot isn't.

So is it now blackrato.ga or blackrota? I need to block this domain

Use a block list, probably not worth the time to block domains you read about one by one.

Of course I'm already using an existing block list. But about 20% of those entries had to be added by myself, for various fishing and spam sites. Still worth my time.

Reply on news.ycombinator.com