您的位置:首页 > 其它

Rootkit Unhooker v3.8 It's Past, Present and Future of the NTx86 Rootkit Detection

2008-08-18 21:51 357 查看
By: DiabloNova
Rootkit Unhooker v3.8
It's Past, Present and
Future of the NTx86 Rootkit Detection

Contents:

1) RKU short
overview (Past)
2) New features of the 3.8 (Present)
3) Perspectives
(Future)

******RKU short overview******

Rootkit Unhooker is enough
known for specialists (and not only) rootkit detection and removal software
developed since 2006 by group of independent people who are NOT related or
affiliated with commercial security companies or malicious software coders
groups.

RKU main goal was always not simple reveal rootkits, but
effectively counteracts with them, resulting in rootkits removal with help of
RKU. Due to implementation specific, this rootkit detection software is able to
reveal most of well-known rootkit technologies implemented in both user and
kernel mode of the NT core based operation systems such as Windows 2000, XP,
2003, Vista, 2008. RKU main features are: detection of different type of hooks
(just as example: most common used splicing, Import table patching, Export table
patching, DKOH, (S)SSDT patching, IDT manipulation etc), successful removal most
of them (if they of course can be removed and doesn’t restoring), detection of
the other hidden stuff such as processes, drivers, files, alternate data streams
stealth code working in kernel mode, internal system mismatches and more and
more, where main goals of each part was and will be deeper technical realization
of each feature. You can read full list of features inside RKU help so let us do
not waste our time and continue to more interesting stuff.

Originally,
program development started in the end 2005 beginning of the 2006 as
proof-of-concept project. With time it has become more than just simple PoC as
many others antirootkits/rootkit detectors (for example klister, DarkSpy and
many many others). Its target was always wide sphere of activity, where each
part of detection implemented well-enough, in the beginning for the detection of
all-available proof-of-concepts rootkits and their technologies, further for the
detection and removal of the existent and dramatically quickly evolving
malicious software such as never-ending bots with rootkit components. Little
time after born this project was open source (until 2.0.40 version). The first
appearance of this software was on SysInternals forums, now they are part of the
Microsoft Technet. Well we will return to this part soon lately.

This
project was always fully FREEWARE and free from any kind of specially created
backdoors or “easter“ eggs. Since 2007 RKU divides on the two different parts,
LE and VX, where LE stands for Lite Edition and VX for Veritable eXtended
version. Their main difference initially was not only the level of features they
are provides, but also their future development. For example, it has claimed
that LE is the last public available Rootkit Unhooker version due to numerous
reasons and its development will be soon completely over. And this exactly is
happened, 4 October 2007 was released last version of public RKU labeled as 3.7.
The reasons of this were said many times before and we see no points in
repeating them again.

Unfortunately, instead of understanding few simple
(as we think) things many people related to crapware/security coding has started
creating numerous idiotic rumors about RKU itself and its authors. We have a
very good laugh on their hypothesis and their behavior during last year. We even
was unable to think, that few “respected” well-known security developers (like
Ilya Rabinovich for example in his postings at virusinfo.info Kaspersky
sponsored forums) will spread and actively defend full of idiocy theory about
relationship between disappearing of the RKU and pompous introducing of the
so-called first fourth generation rootkit detection software (in reality
bullshit). Stuff that is more interesting has taken place at the SysInternals
forums where several guys starts actively search for backdoors inside RKU and by
the way advertising of their commercial software (OnlineSolutions). Seems to be
these people just waited when we finally shut up to start their ridiculous
campaigns. After revealing of the well-known for specialists Rustock.C but fully
unknown for everybody else including most of the antivirus companies mister
Alexander Gostev from the KL accused us in malicious software coding and “long
advertising of nothing”, where mister Gostev used several interesting for his
physiatrist terms and analogues, moreover this so-called virus analyst from
so-called antivirus company even claimed that we can’t detect Rustock beastie.
Thank you, dear Kaspersky Lab, hope after this shit, your buggy and shitty
product will detect something more than just KL self-made Trojans and VBA
macro-viruses written by mister Gostev.

In the middle of 2008 become real
vacuum of rootkit detection software from independent groups. Actually just ONE
active good freeware project – Root Repeal (http://rootrepeal.googlepages.com).
Anything else – only full trash, even GMER did not update for a long time. In
addition, where IceSword is almost dead. We are not speaking about numerous
so-called antirootkits from antivirus companies just because they are full trash
oriented mostly on rootkits of Hacker Defender long time ago finished era.
Rootkit activity however didn’t reduced and more rootkits in the past year
dramatically evolved in technologies they are using. Yes most of them are still
completely script-kiddies by their nature, but we saw malware bootkit, we saw
Acsesso, we saw Rustock series and we can imagine what will be in the near
future. And it was required to update old good RKU 3.7 to satisfy new time, new
threats, “new” rootkit technologies and we did this.

******New features
of the 3.8******

First, it was required to answer on the existing or just
revealed rootkit technologies implemented for example in Rustock.C. Kaspersky
Lab long time ago denies its existence and after revealing of this rootkit by
their concurrent DrWeb they of course started stupid and absolutely mediocre,
helpless campaign against everybody who are not with them or their passive
proactive position. Obviously we cannot copy-paste all methods of the detection
of this kind of rootkits from VX to LE, so we did another variant of detection,
based on revealing and removing rootkit hooks. It is known, that exactly
numerous Rustock.C hooks are protecting this rootkit from revealing/removal by
antivirus software. We do not want to speak anymore about Rustock because it is
obviously dead theme, where too much money of the *** is involved and too much
shit already told. However new 3.8 LE doesn’t detects all this rootkit hooks,
just because for revealing all of them it is required to copy-past too much code
from VX, which we do not want to publish at all. Our next target was bootkit.
Yes it is quite old and already very good known rootkit, but we would like to
add to its detection something new, not just did copy-paste like did some of
antivirus antirootkits (BlackLight, GMER (aswar) for example). The idea of the
bootkit detection is not new – it is crosschecking of the main boot record
sector (usually 0) for mismatch between two different scan. Where High Level API
make first scan and where next low-level disk reading make the second scan. Most
of antirootkits here using original ClassReadWrite handler located inside
classpnp.sys, however we found this solution good, but not very cool, since it
is obviously several easy ways to bypass it. We decided to do a little
experiment and since we cannot use anything from private VX series, it was
required to create new detection method for the bootkit, which not mentioned in
VX variant. We choose SCSI, actually SCSI_REQUEST_BLOCK. It is well documented
way, but very easy and not very hardware independent. However it works, at least
in our test, lol. The removal of bootkit, also was based on the same method. We
doubt in future of the bootkits, since it is always known for what and where you
should look for their detection, no matter even if bootkit will change boot
sequence in BIOS.
After dealing with these two bad guys we started attacking
rootkits with anti-antirootkits part. Yes, such kind of beasties exists, and it
is new flow in malicious rootkit development. While seems to be completely
unable to bypass antirootkits conceptually malware coders due to complete lack
of professionalism and their love for easy-money started attacking antirootkits
in their crappy products. Example given – special FSD filters preventing
antirootkits from operation with RAW disk data, hooking several non-meaningful
for rootkit, but meaningful for antirootkits functions and preventing
antirootkits from correct using them. As the last and very dangerous methods
here we saw rootkit named Siberia2 which specially did damage to Object
Directory to prevent antirootkits from work and detection. The funny part of all
of these rootkits – there are nothing else interesting in them except their
aggressive defense. Further rootkits with such “technologies” will come soon; we
have no doubt in this. Next, it was required to answer on several new
interesting proof-of-concept which were introduced during last year. However we
found nothing useful in some of them (such as raw filtering) simple because
these PoC incomplete, buggy and in real life will not survive few hours of work,
because when they are becoming unseen for the system, it can do with space they
allocate whatever operation system wants. There is no good realization of the
disk sectors hider, only BSOD-generator like dead concepts. Very likely that
this kind of technology exists elsewhere (since we have equal private demo
non-malicious rootkits), but in the private. Therefore, we cannot and do not
want fight with non-meaningful shadows.
We found very simple and efficient
way of the hidden processes detection for the 2003/Vista/2008 systems. It isn’t
really new, as you probably know klister introduced Scheduler lists analysis
long time ago. But since 2003 release no rootkit detectors with klister
functionality were made for the new NT core. Scheduler was changed in 2003 and
it is applies also for Vista/2008.
Little explanations here. Since 2003
scheduler lists are now doesn’t accessible from functions body where they were
located previously. Scheduler lists now accessible from Processor control region
data, where scheduler now operates them though special array of PCRB structures
per processor.

It is not a secret technology and we can even give a
sample of the code to the public, it is very simple and covers all available now
NT versions since 2003. We would like to share this code because it is easy way
to help antirootkits developers detect hidden stuff under new NT’s. We didn’t
see something like that in public before, maybe because we too little googled
for this?

void Win2k3VistaKiWaitListHeads()
{
    ULONG 
KiWaitInListHead_offset = 0;
    ULONG KiDispatcherReadyListHead_offset = 
0;
    PKPRCB p1 = NULL;
    KiWaitInListHead = 
NULL;
    KiDispatcherReadyListHead = NULL;

    p1 = 
KeGetCurrentPrcb();
    if (p1)
    {
        switch ( NtBuildNumber 
)
        {
        case 3790:
            {
                switch 
( wServicePackMajor )
                {
                case 
0:
                    {
                        KiWaitInListHead_offset = 
0x920;
                        KiDispatcherReadyListHead_offset = 
0x930;
                        break;
                    }
                case 
1:
                case 
2:
                default:
                    {
                        KiWaitInListHead 
= &p1->WaitListHead;
                        KiDispatcherReadyListHead 
= 
&p1->DispatcherReadyListHead[0];
                        return;
                    }            
                }
                break;
            }
        case 
6000:
            {
                KiWaitInListHead_offset = 
0x1A20;
                KiDispatcherReadyListHead_offset = 
0x1A60;
                break;
            }
        case 
6001:
            {
                KiWaitInListHead_offset = 
0x1AA0;
                KiDispatcherReadyListHead_offset = 
0x1AE0;
                break;
            }
        default:
            {
                KiWaitInListHead_offset 
= 0;
                KiDispatcherReadyListHead_offset = 
0;
                break;
            }
        }
        if 
(KiWaitInListHead_offset)    
            KiWaitInListHead = 
(PLIST_ENTRY)(PBYTE(p1) + KiWaitInListHead_offset);
        if 
(KiDispatcherReadyListHead_offset) 
            KiDispatcherReadyListHead = 
(PLIST_ENTRY)(PBYTE(p1) + 
KiDispatcherReadyListHead_offset);
    }
}


Where
KiDispatcherReadyListHead now is array of ListEnties for each priority. Parsing
of these lists also was changed since 2000/XP.

void 
ProcessKiWaitListHead(PLIST_ENTRY List, PEPROCESSINFO 
pinf)
{
    PLIST_ENTRY entry = List;
    PETHREAD et1;
    ULONG 
_offset;

    if (List == NULL) return;
    entry = 
entry->Flink;

    do
    {    
        //Thread.Tcb.WaitListEntry 
- OffsetWaitListEntry
        switch ( NtBuildNumber 
)
        {
        case 3790:
            {
                _offset 
= 0x60;
                break;
            }
        case 
6000:
        case 6001:
            {
                _offset = 
0x70;
                break;
            }
        default:
            {
                _offset 
= 0x60;
                break;
            }
        }
        et1 = 
(PETHREAD)((ULONG)entry - _offset);
        if 
(MmIsAddressValid(et1))
        {
            AddToProcessTable(et1, 
pinf);
        }
        entry = entry->Flink;
    } while (entry != 
List);
}

void ProcessKiDispatcherReadyLists(PLIST_ENTRY StartListHead, 
PEPROCESSINFO pinf, ULONG ListHeads)
{
    PLIST_ENTRY 
CurrentListHead;
    ULONG Counter = 0;
  
  for( CurrentListHead = 
StartListHead;
            Counter < 
ListHeads;
            CurrentListHead++, 
Counter++)
    {
  
      ProcessKiWaitListHead(CurrentListHead, 
pinf);
    }
}


We would like to thanks author of
RootRepeal because we have consultation with him while researching this
method.

Excluding these new features in the RKU 3.8 also fixed some old
terrible bugs, removed some obsolete detection methods, updated internal
structures etc. RKU 3.8 also features physical memory dumping which is based on
opensource win32dd project. However we found win32dd code, especially driver
part buggy and recoded most of it.

******Perspectives******

As
for now we continue LE as well as VX development even if sources of VX were sold
in last year the rights on this code is still ours. More things should be added
to improve their usability, stability and detection/removal methods. We are not
anymore interested in script-kiddies feedback as well as their continuing
idiotic rumoring of nonexistent things. However if you have questions, minidumps
etc we will be glad to hear you, feel free to contact. Development of freeware
tools heavy depends on feedback from users. We long time were on sysinternals
forums helping people in dealing not only with malware, but also in different
areas. This place long time have a lot of constructive and talented peoples.
However since acquiring by Microsoft in the July 2006 SysInternals become more
and more unfriendly, and finally now we can tell with 100% sure, Microsoft
provides at SysInternals (as part of TechNet) and especially forums politics of
the CENSORSHIP. You do not need to be very smart person to understand this.
Firstly Microsoft ordered to drop support of the old versions of Windows for SI
tools (it was made specially because the same new ProcMon can have compatibility
with old versions, no matter what somebody claims against, it may not use
Minifilters for NT4/2000 for example, and please do not make us too much laugh
telling that this is impossible). Stupid EULA was added in everything, most
interesting projects like Rootkitrevealer, Autoruns, FileMon, RegMon were ended,
because we cant say that non-meaningful updates of Autoruns is evolution.
However all this of course on programs authors decisions, but it is too
suspicious in relation to Microsoft isn’t? What about forums, which we cannot
anymore use, because Microsoft Administration in the face of Curtis Metz has
build blacklist of IP’s. Forums are under heavy censorship. And main role here
is playing mister Karl, aka Karlchen – very old moderator, who is responsible
for all censorship at forums, mockery in several topics, posting personal
moderators opinions in closed by the same moderator topics, silent graffiti in
several topics (which they now can’t delete – pure Drama, isn’t?). It is really
– “Power corrupts” and mister Karlchen now perfectly knows this. After
kicking/banning us this place was owned by gang of real idiots of any kind, they
all think that they are living in Matrix and evil rootkits everywhere including
their home toasters. This idiocy owned in the past very good and interesting
place. Owned with direct help of mister Karl and new
administration.
Drama.

Well enough about idiots, let’s go back to main
theme.
Below is the link to the latest Rootkit Unhooker v3.8. It is uploaded
to free file hoster service, simple because we doesn’t have a vault here and
can’t use any other ftp in security reasons. MD5 checksum included, help file
and localization packs also here. Perhaps if administration of rootkit.com won't
be against here also will be soon posted old source code of RKU, not only very
old 2.0 ;)

If you have questions/comments/suggestions please use Memo
system to reach us. Stupid output will be ignored, offensive output will be
ignored and reported to administration.

NOTE: YOU USE THIS SOFTWARE AT
YOUR OWN RISK
NOTE: REMOVE ALL PREVIOUS LE VERSIONS BEFORE USING THAT
VERSION!

http://rapidshare.com/files/136965760/RkU3.8.341.552.rar.html
df4536abcf25ec8f77c91f2b058e4c02
*RkU3.8.341.552.exe

Locals
http://rapidshare.com/files/134702156/2local.rar.html

This
software and article is posted at rootkit.com as exclusive. Any other links
elsewhere to this software without noticing original post location and MD5
checksum IS NOT GENUINE.
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: