Trend Micro's Rootkit Buster - Blast From The Past? Nope.

Pic 1. TrendMicro abandonware.

 

Recently I came across an article "How to use Trend Micro’s Rootkit Remover to Install a Rootkit" by Bill Demirkapi. It covers TrendMicro out of date antirootkit called "RootkitBuster". TL;DR it is dangerous software full of hacks and potential kernel level vulnerabilities. My interest was attracted by the part about some pieces of code author of blogpost found weird. After reading it I thought that I can actually answer on questions made in this blogpost. A little introduction and small excursion into history are required before we can move on to answering questions.

Long time ago in a galaxy far away

I'm familiar with this software since... hmm decades? It just so happened that I probably know one of the guys who worked on this software and in general familiar with this software class, it design and reasons why it looks so terrible from this year perspective.

Rootkit Buster is a classic 3rd generation antirootkit created in the second half of the 200x in response to dominance of kernel mode rootkits on MS Windows. Almost every ISV created this kind of software in that times, some made standalone tools like TrendMicro, Kaspersky, Avast, BitDefender, Sophos, F-Secure (with their infamous by it uselessness BlackLight). Some ISV incorporated their functionality directly into their mainstream products like for example Dr.Web or later Avast (when they acquired author of freeware GMER). Almost all of them were useless and never bothered rootkit developers to address their detection's in rootkit updates. There is a few exceptions of course like Dr.Web antirootkit engine and Kaspersky TDSSKiller. Aside of this anything else were merely a jokes. Entire battlefront with rootkits of that era was up to freeware tools made by enthusiasts. Starting from Rutkowska PoC's (like system virginity verifier, klister) and following 2nd generation with IceSword from pjf, Darkspy from CardMagic and wowocock and ending up 3rd generation with various tools like KDetective, RootRepeal, GMER many many of them (I have complete museum collection of them, including various versions, which is about 200 mb archive).

While notorious malware families of that time largely utilized kernel mode rootkit components it were developed by a really small group of original authors. It was obvious for everyone who were familiar with their design and implementation (winking for those I know). Later in the beginning of 201x they left and market was flooded with copy-pasted, "renewed" junk copies. It quickly degenerated completely and moved into limited usage in the APT, like for example Turla rootkit which is heavily inspired by 200x solutions for antidetection.

Really, really bad code?

Both rootkits/antirootkits were using completely undocumented stuff, internal Windows structures, doing with kernel basically all what they want in a completely unsafe manner. Was it bad code? Obviously, for reference you can look on KSBinSword - a Chinese IceSword copy-paste clone with source code available. Solutions it used were widely used in any other antirootkits of that times. Or look on more recent Kernel Detective with also now available source code. Unfortunately there was no way to successfully counteract malware rootkits without going on their or deeper level. Which required going deeper into undocumented thing and unsafe solutions. So was it really "bad" code? BSOD-generators for sure. Have you ever saw Kaspersky AV 6.0-7.0 source code? It is a ridiculous mess and their drivers are dangerous bugfest by design. Does it mean Kaspesrky 6/7 were failures? Nope, they both were highly successful and actually delivered a lot of problems for malware authors of that time. It was bad but it was adequate solution to that time. Simple because everything else was ineffective. This mess required operation system vendor response at first place. And MS did the job so now we can look into the past and be horrified.

Rootkit Buster is a direct successor of those times (it both design and code) and has been really polished compared to most of other ISV tools of this kind. This does not mean it is highly effective against dedicated malware it only mean that others are can be worse.

Bruteforcing Processes

What is the point of it and why not use documented API here, as blogpost author stated? It is a simple answer if you somewhat familiar with rootkit/antirootkit development. 

Usually we use the ZwQuerySystemInformation function in the kernel to traverse the process module and obtain the process information. This is through the normal process traversal method. Therefore, multiple rootkits will intercept the ZwQuerySystemInformation function to filter the specified process to realize the hidden process. At the time, you couldn't trust in regular API call result because they can be easily faked through DKOM or manipulations with API hooks on various levels. Trust no one except yourself - is a main slogan for antirootkits of that era. One of the first tools implemented PID bruteforce for detecting hidden processes was, suprise-surprise, F-Secure Blacklight. There is nothing wrong with this method, it quickly became outdated as rootkits managed to go deeper and started modifying kernel objects structures, however it still has right to exist. Of course all this apply to 200x era.

Bruteforcing Offsets

Why not use ZwQueryInformatonProcess with ProcessImageFileName here?

Again if you familiar with things answer is simple. Using API in that case will ultimately lead into malicious hook where returned data will be faked. Aside from this it is not an Rootkit Buster innovation - in fact they simple used same code snipped with known for ages Russinovich RegMon source code (or maybe even earlier). In an effort to remain version-independent, rather than using a hard-coded offsets, it scan the process object structure memory looking for the name, which should match that of the GUI process, see RegMon source code.

EPROCESS PEB Offset

Same as above. You can't trust API here unless you want to jump into rootkit trap. Notorious hardcore rootkits of that era always played at the edge of system collapse, modifying anything until the limit where they can't keep system alive anymore. Besides, offset are required to direct access to the kernel structures (thus avoiding all API hooks). Process Environment Block location is one of the key things for every antirootkit.

ETHREAD StartAddress Offset

Same as above. This offset needed for direct access to the object structure field. Additionally such scans are somewhat version independent code thus you don't need to hardcode 10-15 versions of ETHREAD offsets for single structure member if you have to support multiple Windows versions. None of API calls here (ZwQueryInformationThread) does makes any sense.

Pretty much all of the questions author made can be answered by just taking a look in any of "Rootkits blah blah blah" books dated back to 200x.

So Why?

RootkitBuster is a combination of out-dated techniques, methods from Windows XP era, that (it is my guess) are just blatantly copied from x86-32 and compiled for x64 without any actual refactoring (except part for making it compilable and verifier friendly ROFL). Obviously parts of code highlighted by author has a little sense (if any) on 64 bit Windows version with PatchGuard and other fancy security features built-in. In general this software has no sense on x64 and looks completely abandoned. It version 5 was released in 2011, do you see any hints here?

Just reversing of drivers for exploits is not enough for their code complete understanding. You have to be familiar with what they actually do and how this is implemented, not to say about baggage of experience in that field.

From a malicious usage perspective RootkitBuster also has nothing to offer. Take it as a sort of unusual museum exponent. If you want to look at really dangerous software actively developed and distributed under multiple "best security" crapware brands - take Zemana (or any of it pseudonyms) driver as example of complete hack-o-rama, right here, right now on x64.