I've developed an antirootkit tool called CodeWalker which can:
+ Detect hidden processes
+ Detect hidden drivers
+ Detect hidden files (support NTFS only)
+ Detect hooks in both kernel mode and usermode.
+ Works on Windows English 2000/XP/2003/Vista/2008.
The tool is currently in beta stage and im looking for people for testing it. I've already tested it with all rootkits samples I have and its detection rate seems optimistic. I think it's very great if you guys test it against your rootkit zoo and provide the result you got with the tool. If there's BSOD (of cos, you can never write a bug free proggie, rite? :P), it would be very appreciated of you to upload minidumps to help me correct the tool. Thanks in advance.
I will update this tool frequently for new detection methods, bug fixs etc. Welcome for your all suggestions, bugs and minidumps :P
In this beta version, the main improves to other ark is heavily put in hidden driver object (System Modules tab) and code hooking detection.
For hidden driver detection, you can test it with some pretty well hidden driver PoC such as phide_ex and many builds of Rustock.B variants. Although you have to use the "Hardcore Scan" method to detect them.
For code hooking detection, the engine walks all the branches of scanned module i.e any execution path of it to detect modification (btw, that's why i call it CodeWalker). IMHO, It can detect code hooking very well especially with rootkits that place abnormal hooks like Rustock.C (FF25 & FF15 - jmp/call dword ptr [abc]) tho there're still some problems with false-positive hooks/modifications.
good job! but I found some problems with your program
1. when I want to skip Scanning Hidden file. I pushed down on the "skip" Button, but It dose not work.
2. your code HOOK scan module is so weak that It can not detect my inline hook.
I think you just scan functions that are exported by ntoskrnl/ntkrnlpa...,but there are still many undocumneted APIs you had missed. here is the result:
3. "Hidden Module",is also not strong enough, My virus proc bypass it easily.
4. "Process Module", can't kill my protected EXE. DKOM+inline...
No, i scan all functions in ntoskrnl and other modules, not only exported symbols e.g it can regconize hooks in wanarp.sys placed by rustock. It's weird, maybe something wrong in results processing here. Ill upload a fixed version soon. Maybe because I've modified something to reduce false-positive results.
3. "Hidden Module",is also not strong enough, My virus proc bypass it easily.
At the moment, its limited to hidden standalone rootkit driver only, but not virus :) You can test it with any hidden driver too, with "Hardcore scan" method. By the way, can u give me your process which my tool cant delete ? Have you tried "Corrupt memory" kill method ?
PS: This is the same result i posted a long time ago:
http://reaonline.net/showthread.php?t=7455
inline code hook detection is the impossible task
full image check will produce so many unfathomed result ,and reduce resule will lost some out of way code hook method.
but my tophet donnot have any code hook ,even don't have any "HOOK"
No one can be sure that his tools can detect all inline hook,
then I will show some skills which bypass your CodeWalker soon.
but I don't deny that CodeWalker is a perfect Anti-Rootkit
@sudami: can you post the minidump so i can fix my tool ? Thanks in advance.
@qihoocom:
inline code hook detection is the impossible task full image check will produce so many unfathomed result ,and reduce resule will lost some out of way code hook method.
Yes, this is the reason. There's a feature in the tool which allow to see all other less suspectious hooks/modification.
As i said in 1st post, the tool doesnt care about the scanned function is exported or not, it just scans all the possible execution path of it, i.e all other undocumented function (sudami mentioned one) on its path, and all other lower level functions. This is why there's "In execution path of" column in kerenl hooks box, and why i call it CodeWalker.
For example:
If you call NtOpenFile, all function which NtOpenFile calls will be examined: IoCreateFile -> IopCreateFile -> IopUpdateOtherOperationCount, ObOpenObjectByName -> ObpCaptureObjectCreateInformation ... It will examine like a normal execution (calls, branches, conditional jumps..) so any hooked function on the execution path of the scanned function will be detected.
PS: This is just a BETA version, i hope you guys will help me point out as much bugs as possible :D
I tested your Program on VMWARE, and I forgot to set the Computer Model to "Minidump Module", so there isn't any dumps.
but, your hook for KiFastCallEntry cause the SYSTEM to crash...
Hi, what a pity, i really love minidumps, each minidump help me fix a bug :( CodeWalker doesnt hook anything, so KiFastCallEntry is not the reason. Could you please reproduce the bug and send me the minidump ?
And, for the hook u mention, CodeWalker can detect really fine here. For a quick test, i modify the hook like you post on-the-fly by WinDbg. You can retest the tool in the link in my 1st post:
The test:
Original:
1
2
3
4
5
6
7
8
9
kd> u nt!MmLoadSystemImage+0x22
nt!MmLoadSystemImage+0x22:
8059fb9b 8975b8 mov dword ptr [ebp-48h],esi
8059fb9e 89b564ffffff mov dword ptr [ebp-9Ch],esi
8059fba4 830d042d558001 or dword ptr [nt!MiFirstDriverLoadEver (80552d04)],1