Ultimate way to hide rootkit

Even if I'm not paticilary interested in rootkit developing
filed, I visit www.rootkit.com from time to time to check if there
is any new idea regarding rootkits, not because I need it to develop
them, but because I like to be informed about what is going on in
windows kernel.

So far I know only a few (actually 3) ways to hide driver.
One of them is unlinking driver from PsLoadedModuleList, second is
deleting driver entry from OBJECT_DIRECTORY, this structure is described
in Undocumented Win2k Secrets, but if you are lazy to understand how
it really works you may use some of codes from www.rootkit.com,
third way is to scan IoDriverObjectType.TypeList list in some unordinary
way as is presented in Unreal rootkit by RootkitUnhooker developers team,
I'm not sure how this trick works, nor is documented so I'll just believe
that it really works :0


But what will happen if I tell you that you don't have to hide
your driver at all? Even more, when you finish reading this article you
will figure that there is actually nothing to hide. I'm not talking about
sing ExAllocatePool to store hooks there and simply unload your driver.
No,no... we will have full working driver, operational, able to communicate
with r3 w/o a problem (I still didn't investigate how this will work with
filter drivers).

Does PE MEM EXECUTION concept ring any bells? If no, you will have
to read more about PE file format to understand what is neccessery for one
binary to become ready for execution. We will need to emulate ntloader,
which means :
- reallocate sections (RAW -> VA)
- fill import table
- apply relocs
- call driver entry point

- reallocate sections
This is very simple to perform and I think that many of you have done
such thing, but here is sample src just in case:


                        mov     new_driver_mem_base, eax
                        mov     esi, new_driver_raw_base
                        mov     edi, eax
                        mov     ecx, [ebx.pe_sizeofheaders]
                        rep     movsb
                         
                        lea     eax, [ebx+0f8h]
                        movzx   ecx, [ebx.pe_numberofsections]
                        
__copy_sections:        mov     esi, [eax.sh_pointertorawdata]
                        add     esi, new_driver_raw_base
                        mov     edi, [eax.sh_virtualaddress]
                        add     edi, new_driver_mem_base
                        push    ecx
                        mov     ecx, [eax.sh_sizeofrawdata]
                        rep     movsb
                        pop     ecx
                        add     eax, size image_section_header
                        loop    __copy_sections

- fill import table
We will walk trough IMAGE_IMPORT_DIRECTORY, each found API should be
converted to UNICODE -> UNICODE_STRING and we will call ntos export
MmGetSystemRoutineAddress to get address of API. Or if you prefer
to go manually you may use PsLoadedModuleList or ZwQuerySystemInformation
to get list of all modules and walk trough their export table.

- apply relocs
This is neccessery because we need to rebase our drvier and all data
references in it. It is simple to implement even if source in my code
doesn't look that much simple :)

- call driver entry point
Aha, you are wondering how do I get DRIVER_OBJECT and how do I
insert it into OBJECT_DIRECTORY, in PsLoadModuleList, etc. Well
I don't do anything of this. What I do here is a little dirty
hack which came to my mind:

Simple, we will get DRIVER_OBJECT of some already loaded driver, and pass
it to new driver, by making RegPath to be 0deadc0deh as signal to new
driver that it is loaded via loader and not ntoskrnl.exe.

In this DRIVER_OBJECT we will hook IRP_MJ_DEVICE_CONTROL and also we
might at the same time create symbolic link if we don't wanna use
the one that target driver is using or it doesn't create symbolic link at all.

After checking for a while, and looking what driver is the best to hook,
I have decided to use null.sys. Dummy driver loaded by widnows and I'm
going to hook it, aslo I will create symbolic link visible from r3 as:
//./rootkit because null.sys doesn't creat symbolic link.

So is there anything weird to check for? Don't think so.

Ofcourse driver loader will return error so it will be unloaded but
still your system is penetrated by "newly loaded driver".

If we want to make our driver more stealth my advice is to erase it's PE header, so nothing weird will be noticed and your driver will look like
some garbage in memory. That's what I do in this example.

I hope that you will find it usefull, I know I did.

S verom u Boga, deroko/ARTeam

You can download full source from http://deroko.phearless.org/ohmygod/ohmygod.rar

read comments (49) / write comment