In this installment I’m going to describe the Command-and-Control (or C&C) protocol of BLATSTING. This the protocol used in the network traffic between the malware and what is used by the person controlling it. I’m also going to see whether this traffic can be detected.

The one mystery module in the BLATSTING rootkit/malware/implant/… in the Equation Group dump is m12000000, or TADAQUEOUS. There is only one mention of it in the various documentation and scripts:

In the Equation Group dump many of the implants can announce themselves with beacons, especially the BIOS implants. These beacons are disguised as normal network packets, likely directed at fake hosts, to be intercepted by intermediate infrastructure. The list in BLATSTING beacon listening post module gives a possible list of disguises:

I’ve done a bit of reverse-engineering on the BLATSTING “modular rootkit” implant which was part of the recent Equation Group leak. I find it interesting as it injects into the Linux kernel, intercepts network traffic, and even injects packets as to redirect browser users to a site with pre-packaged exploits.

I was interested in using my brand new “gaming” card for parallel computation. Of course I want to do this by using using free software if possible, not by installing proprietary drivers.

I just created this new blog.

I’m happy with the job I’m doing, happy to work with a few very smart people on an extremely interesting project, involving various entirely new challenges, that could have enormous impact. But on the other hand Bitcoin infrastucture development must be one of the most hostile and crazy working environments in existence, at least in software development.

Thanks to austriancoder we now have something showing up on GC2000. There are still some visual corruption issues, but something is showing up!

Lately I've tried to get to the second (AUX) core of the Ingenic JZ4770 in the GCW Zero. This is part of the VPU (Video Processing Unit) and not really documented, so this was the result of quite some trial and error. But after clocking down the AHB1 bus to 166MHz I was suddenly able to reliably run code on the extra core. The interesting thing about the VPU in the JZ4770 is that it simply runs MIPS code like the main core (albeit at half clock rate) and not another "secret" ISA.

I've just pushed an update for the etna utilities. viv_gpu_top was extended with as much as two modes, one to watch occupancy (non-idle state) of the various modules, and one to watch the DMA hardware status. I also added an utility viv_throughput to benchmark the raw fillrate of the GPU.