View Full Version : Debugger - Bypassing API hooking automatically - How?

August 13th, 2011, 02:17
I was trying my hang out at Lenny Zeltser's latest malware challenge. There was a question there about a file that got downloaded on to a system and then hid itself. The question was 'What API's did it use to do this?'.

I managed to get the exact location of these "hidden files and reg keys" using Procmon and CaptureBat and could even cd into the "hidden" directory. Next up was the API question. Googling showed that it was the API called ntquerydirectoryfile which was responsible for displaying files in a directory [Output of "dir"] and RegEnumValue was responsible for viewing values of registry keys. So that's what the malware/rootkit was probably hooking.

The point though was..How do I actually confirm this? Running cmd or regedit did not show me these files or registry keys. So I thought, lets open up cmd in a debugger and see what happens. I opened up 'cmd' - F9'd it in Olly and typed in 'dir'. To my surprise the "hidden" directory revealed itself. The same behavior was found with 'regedit' as well. That confused me..I'll explain why.

Both cmd and regedit are 'User mode' programs. Olly is also a 'User mode' program. Olly is the parent for both these processes. So when i type 'dir' in cmd... instead of the program itself telling the OS to run 'dir' - Olly tells the OS to run 'dir' instead. That's it..rt? It doesn't modify anything AFAIK [Could be wrong].

So yes.. I got the answer to my question for the Lenny challenge, but it was just a stroke of luck to be frank. I had started putting breakpoints on RegEnumValue and Ntquerydirectoryfile when this happened.

Any thoughts?


August 15th, 2011, 01:15
Hi Arvind

Well that's a useful effect, and observation. Following along with the writeups of the interesting challenge I was able to extract the exe file from the pcap dump using NetworkMiner. I then took a look at things under Softice. From all appearances, Ollydbg restores the original index values of the ntdll calls for itself.

Once the malware is activated, you can see the hook under Softice for any random process:


:wc // to be able to "Save SoftIce History As" in Symbol Loader for output (toggle code window Off)

:addr winlogon
:u 7c90df5e

0008:7C90DF5E JMP 0EA06009 // malware NtQueryDirectoryFile hook
0008:7C90DF63 MOV EDX,7FFE0300
0008:7C90DF68 CALL [EDX]
0008:7C90DF6A RET 002C

Fire up Olly (no debugee yet) and you can see that its copy of ntdll is "clean". Isn't that cool?


:addr ollydbg
:u 7c90df5e

0008:7C90DF5E MOV EAX,00000091
0008:7C90DF63 MOV EDX,7FFE0300
0008:7C90DF68 CALL [EDX]
0008:7C90DF6A RET 002C

So, do we know if this is something Olly actively does, purposely verifying the integrity of system calls in its image of ntdll from the original file, or is this some random act of serendipity?

Oh, here's a fun little corollary, pretend to open a file in Ollydbg and start in the C:\ directory. Notice how it automagically detects the "hidden" directory?


August 15th, 2011, 01:48
Any link for the challenge?

August 15th, 2011, 01:51

August 15th, 2011, 10:45
im interested new ppl like lifedontexits still have softice in their armory ?

August 15th, 2011, 11:15
Thanks a lot Kayaker! That's interesting. Do you think Olly would do that for any "API hooker"? Then we wont need Rootkit Revealer and other tools .

@Elenil: I've heard of Softice but you're right..as of now I'm just using Olly 1.10 , 2.01 and IDA's free version (mainly for graphs)


August 15th, 2011, 20:10
[Originally Posted by Kayaker;90888]
So, do we know if this is something Olly actively does, purposely verifying the integrity of system calls in its image of ntdll from the original file, or is this some random act of serendipity?

Just a guess, but isn't this purely a function of copy-on-write in Windoze?

August 16th, 2011, 00:57

Thanks for the insight. Following up on that, I decided to see what other differences one could find between the ntdll images that were hooked, and the 'clean' ntdll image used by Ollydbg. Perhaps if all else failed, something like this could be used to detect this type of memory hook or other alteration in system modules.

These are just observations, not fully tested under all conditions. Yeah, I know this is a bit 'dry', boring technical output and such, but that's the way it is

I began by using the PAGE command in Softice to display the page table information for the virtual address which contained the known NtQueryDirectoryFile hook. The Attributes flags indicated that this location was marked as "Dirty" and "Writeable" for all ntdll images, except of course for Ollydbg, where these bits were not set. The "Dirty" or Modified bit of a page table entry indicates it has been written to.


:addr notepad (or any random infected process)
age 7c90d000

Linear Physical Attributes
7C90D000 1344F000 P RW U A D

:addr ollydbg
age 7c90d000

Linear Physical Attributes
7C90D000 03ADE000 P R U A

Another way of looking at that is with Windbg/Livekd. Here is a comparable output for the (hooked ntdll) process notepad. The !pte command again indicates the Dirty Bit has been set, as well as the Writeable bit. The !pfn command on the page frame number obtained from !pte also tells us the page has been Modified. The significant output has been highlighted.


kd> !process 0 0 notepad.exe

kd> .process 81f47020 // set context
Implicit process is now 81f47020

kd> !pte 7c90d000 // page table entry for virtual address of NtQueryDirectoryFile

VA 7c90d000
PDE at C03007C8 PTE at C01F2434
contains 123AA067 contains 1344F067
pfn 123aa ---DA--UWEV pfn 1344f ---DA--UWEV

kd> !pfn 1344f
PFN 0001344F at address 81204768
flink 0000001B blink / share count 00000001 pteaddress C01F2434
reference count 0001 Cached color 0
restore pte 000000C0 containing page 0123AA Active M

For Ollydbg we get what is expected to be "clean" results.


kd> !process 0 0 ollydbg.exe

kd> .process 82136da0
Implicit process is now 82136da0

kd> !pte 7c90d000

VA 7c90d000
PDE at C03007C8 PTE at C01F2434
contains 13B52067 contains 03ADE025
pfn 13b52 ---DA--UWEV pfn 3ade ----A--UREV

kd> !pfn 3ade
PFN 00003ADE at address 8108E4D0
flink 0000001B blink / share count 00000003 pteaddress E1417D3C
reference count 0001 Cached color 0
restore pte 907C346A containing page 002C63 Active P

Another thing I noticed when using the Softice QUERY command was that the Flags result was different for ntdll.dll in a hooked image, vs the clean image of Ollydbg. The Flags result corresponds to the MMVAD_FLAGS structure, see this link for details if interested.

What is the Flags field in the output of a SoftICE Query command?

Specifically, the Vad->u.VadFlags.CommitCharge value was consistently 0x0A for any hooked ntdll, and half of that, 0x05, for Ollydbg. I believe CommitCharge relates to the physical memory usage of a process. I'm not sure of the significance of the difference that is shown - an indicator of copy-on-write?


:query notepad
Address Range Flags MMCI PTE Name
7C900000-7C9AF000 0710000A 823B32D8 E1417D08 ntdll.dll

:query ollydbg
Address Range Flags MMCI PTE Name
7C900000-7C9AF000 07100005 823B32D8 E1417D08 ntdll.dll

And using Windbg to get the same information:


kd> !process 0 1 notepad.exe
VadRoot 82296e50

kd> !vad 82296e50
VAD level start end commit
821ed760 ( 2) 7c900 7c9af 10 Mapped Exe EXECUTE_WRITECOPY

kd> !process 0 1 ollydbg.exe
VadRoot 8225c900

kd> !vad 8225c900
VAD level start end commit
821a1a58 ( 3) 7c900 7c9af 5 Mapped Exe EXECUTE_WRITECOPY

That's as far as I've dug. So what would be next, a Windbg script to scan system images for various page bits being set which might indicate the images had been modified?


August 16th, 2011, 22:59
Nice work! Windbg script would be interesting. Can think of several applications.

August 16th, 2011, 23:42
windbg script

here you got it just tell me if you want the copiuos data to be split with grep sed split uniq and catted to > blah.txt


c:\scripts>type vadmap.txt
.foreach ( place {.shell -ci "!for_each_process dt nt!_EPROCess @#Process Vadroot" sed -e s/.*:./""/ | sed s/.Void/""/ } ) {!vad place}


lkd> $$>a< c:\scripts\vadmap.txt

VAD level start end commit
86deb080 ( 0) 10 33 0 Mapped READWRITE Pagefile-backed section
86d496c0 ( 2) 40 40 0 Mapped READWRITE Pagefile-backed section
861e78d0 ( 3) 50 14f 0 Mapped READWRITE Pagefile-backed section
86d7dac8 ( 1) 7c900 7c9b1 5 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\ntdll.dll

Total VADs: 4 average level: 2 maximum depth: 3
VAD level start end commit
86be0978 ( 1) 0 ff 0 Private READWRITE
86bd7038 ( 2) 100 100 1 Private READWRITE
86bd6458 ( 3) 110 110 1 Private READWRITE
86bd3860 ( 4) 120 15f 4 Private READWRITE
86d44e40 ( 5) 160 25f 7 Private READWRITE
86d442b0 ( 6) 260 26f 6 Private READWRITE
86bf2148 ( 7) 270 2af 4 Private READWRITE
86c84050 ( 8) 2b0 2ef 4 Private READWRITE
86bd0980 ( 9) 2f0 2f0 1 Private READWRITE
86a11178 ( 0) 48580 4858e 2 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\smss.exe
86b7a7f0 ( 1) 7c900 7c9b1 6 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\ntdll.dll
86baed48 ( 2) 7ffb0 7ffd3 0 Mapped READONLY Pagefile-backed section
86c68eb8 ( 3) 7ffd8 7ffd8 1 Private READWRITE
86d831a0 ( 6) 7ffdd 7ffdd 1 Private READWRITE
86c290a8 ( 5) 7ffde 7ffde 1 Private READWRITE
86b97098 ( 4) 7ffdf 7ffdf 1 Private READWRITE

Total VADs: 16 average level: 5 maximum depth: 9
VAD level start end commit
86cb93e8 ( 8) 0 9f 160 Private READWRITE
86cac0d0 (11) a0 bf 0 Mapped Phys READWRITE NOCACHE Pagefile-backed section
86cb1110 (12) c0 ce 0 Mapped Phys READWRITE Pagefile-backed section
86cb1558 (13) cf cf 0 Mapped Phys READWRITE Pagefile-backed section
86c864e0 (10) d0 df 16 Private READWRITE
86ca7008 (11) e0 ff 0 Mapped Phys READWRITE Pagefile-backed section
86cc6050 ( 9) 100 100 1 Private READWRITE
86ca0588 ( 7) 110 110 1 Private READWRITE
86c94500 ( 9) 120 15f 4 Private READWRITE

August 17th, 2011, 23:52
Thanks, I found a useful test bed was simply a regular system with Comodo (or similar) installed. Comodo does several inline hooks of a number of system dlls for selected processes. Rootkit Unhooker/Code Hooks will give the details of these hooks. Some processes such as winlogon/csrss/smss seem to *not* be hooked by Comodo, so they provide the "control", whereas processes such as services/lsass/svchost *are* hooked and provide the test subjects. A memory browser such as SmidgeonSofts TopToBottomNt can be used to view the modified bytes.

In preliminary testing it seems that the !pfn command will consistently report whether a page has been (M)Modified, where a hook occurs, or remain in a (P)Shared state in modules where there is no hook. The !pte command doesn't seem as reliable as it did when testing the malware situation as previously detailed, i.e. it didn't report that the Dirty/Writeable bits had been set on the modified page, by the Comodo hooks. However, continuing with the !pfn command on the suspect pages anyway did expose the modification, if you understand what I'm getting at.

Hi Blabberer, I was hoping you'd drop in with one of your Windbg script magics
OK, so given what I just said about detecting the Comodo inline code hooks on system dlls such as ntdll/kernel32/advapi32/user32 - a hypothetical "ideal" script might check each PTE page frame (!pfn) where these code hooks occur (all in .text section) and report any pages listed by the !pfn command as "(M)Modified". (I'm just throwing around ideas...)

August 18th, 2011, 09:06
Hi kayaker show me by example what you want and i will find a way to script it

like !pte ?

!pfn what

if you want all pfn that is in modified state (not sure of the terminology try and post back if this is what you are looking at it is a very huge output so run it and come back after very long time i never allowed it to finish ever when i tried this will hit ctrl+break )


lkd> .shell -o **********\pfndatabase.txt -ci "!pfn 0 1" grep -i M
<.shell waiting 10 second(s) for process>
.shell: Process exited

lkd> .shell -i **********\pfndatabase.txt cat -

output of cat redirected to windbg command window using read stdin arg -

Page Flink Blk/Shr Ref V PTE Address SavedPTE Frame State
2 1ff3 1 1 c0021320 4264000 80 92e Active M
3 2135 1 1 c0021518 42a3000 80 92e Active M
8 b79 1 1 c000b238 1647000 80 aa9 Active M
9 d99 1 1 c000ada8 15b5000 40 3a4 Active M
b bb9 1 1 c0004e48 9c9000 80 c44 Active M
d 48e4 1 1 c0041c90 8392000 80 7f47 Active M
f 10c5 1 1 c00149e8 293d000 80 289 Active M
14 c42 1 1 c0004dc0 9b8000 80 c44 Active M
15 b04 1 1 c0004d18 9a3000 80 c44 Active M
17 f0f 1 1 c0014460 288c000 80 289 Active M
1b b45 1 1 c000b110 1622000 80 aa9 Active M
1d f55 1 1 c0014690 28d2000 80 289 Active M
21 b12 1 1 c000b000 1600000 80 aa9 Active M
22 89e5 1 1 c07203e8 e407d000 c0 3a028 Active M
33 a3d 1 1 c0004be8 97d000 80 c44 Active M
48 b36 1 1 c000b0b8 1617000 80 aa9 Active M
49 d28 1 1 c000edf0 1dbe000 80 7bf5 Active M
4d d48 1 1 c038d488 71a91000 60 3f3f1 Active M
4e 1002 1 1 c0010f68 21ed000 80 78cc Active M
60 759d 3 1 c070a318 e1463000 c0 73fd Active M
6a a34 1 1 c0004ba0 974000 80 c44 Active M
6d 75de 2 1 c070a278 e144f000 c0 73fd Active M

btw you were looking at ntdll in an ealier post so i modified the script that i posted in ealier thread to grep for modules that you can specify


.foreach (place { .shell -o c:\scriptresults\vadmapres.txt -ci "!process 0 1" grep -i vadroot | sed s/.*VadRoot.// | sed s/.Vads.*// } ) {}
.foreach /f ( foo "c:\scriptresults\vadmapres.txt" {.shell -ci "!vad foo" cat - >> c:\scriptresults\vadmaparg1.txt }
$$>a< c:\scripts\grepvadforarg.txt ${$arg1}
.shell -x del c:\scriptresults\*.txt & exit

the nested script file contains

.shell -i c:\scriptresults\vadmaparg1.txt cat - | grep -iE "${$arg1}" & echo **************************************************

and you can use it like

lkd> $$>a< c:\scripts\parsevad.txt ntdll|kernel32|user32|gdi32|advapi32

and the out put will be


86217f00 ( 3) 7c800 7c8f5 7 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\kernel32.dll
865d86b0 ( 4) 7c900 7c9b1 7 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\ntdll.dll
85e5ccb0 ( 7) 7e410 7e4a0 6 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\user32.dll
86164b70 ( 6) 77dd0 77e6a 8 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\advapi32.dll
86658b08 ( 9) 77f10 77f58 3 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\gdi32.dll
8602ea98 ( 3) 7c800 7c8f5 7 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\kernel32.dll
85e42ba0 ( 2) 7c900 7c9b1 7 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\ntdll.dll
86ca7838 ( 5) 7e410 7e4a0 6 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\user32.dll
869e7078 ( 6) 77dd0 77e6a 8 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\advapi32.dll
86000aa0 ( 9) 77f10 77f58 3 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\gdi32.dll
860301e0 ( 3) 7c800 7c8f5 7 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\kernel32.dll
86c15a28 ( 2) 7c900 7c9b1 7 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\ntdll.dll
85cf53d8 ( 5) 7e410 7e4a0 6 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\user32.dll
.shell: Process exited

August 18th, 2011, 22:28
Thanks Blabberer. I'll start working on my Windbg script chops, which are about a half step past 'Hello World', and try to figure out where to go from here. Appreciate the help

August 19th, 2011, 02:17
nice reading i would say

August 20th, 2011, 00:14
You bastards amaze me .


September 12th, 2011, 07:46
@ kayaker
did something or some pattern emerge out of the chaotic output


September 12th, 2011, 23:13
Hi blabberer,

Sort of. I was working on a script which would potentially detect code modifications of system modules by looking for dirty/modified pages via !pte, and/or !pfn. As a framework I was using a combination of two examples in the Windbg debugger.chm file under "Debugger Command Program Examples" - Walking the Process List and Walking the LDR_DATA_TABLE_ENTRY List. These examples can be used to parse through every loaded module for each loaded process, and from within that loop further testing of various sorts could be done.

For example, if it was found that memory pages were modified for a process that corresponded to the .text section of ntdll, one could use the file on disk to pinpoint the specific addresses that had been changed. Nothing particulary new with that idea, just a variation on a system virginity verifier.

It was about this point that I realized that the existing !chkimg command could be used to the same end, and I kind of put the original idea on the backburner for now.

Here are a couple of articles discussing the !chkimg command:


Here I used !chkimg to detect the ntdll hooks by the challenge malware.


kd> !process 0 0 explorer.exe

PROCESS 82156928 Image: explorer.exe

kd> .process 82156928
Implicit process is now 82156928

kd> !chkimg ntdll -d
7c90d976-7c90d97a 5 bytes - ntdll!ZwEnumerateValueKey
[ b8 49 00 00 00:e9 f5 7f 14 92 ]
7c90df5e-7c90df62 5 bytes - ntdll!NtQueryDirectoryFile (+0x5e8)
[ b8 91 00 00 00:e9 a6 80 14 92 ]
7c90e45f-7c90e463 5 bytes - ntdll!ZwResumeThread (+0x501)
[ b8 ce 00 00 00:e9 39 7d 14 92 ]
7c90e975-7c90e979 5 bytes - ntdll!NtVdmControl (+0x516)
[ b8 0c 01 00 00:e9 47 77 14 92 ]
7c9161ca-7c9161ce 5 bytes - ntdll!LdrLoadDll (+0x7855)
[ 68 6c 02 00 00:e9 7b bd 13 92 ]
25 errors : ntdll (7c90d976-7c9161ce)

I'm a little surprised however that the !chkimg -f (fix) command doesn't actually fix the modified bytes. It *says* it has, but on reloading kd or checking with some other memory viewer nothing has actually been changed. I don't *think* it's the malware preventing this, though that could be wrong, but for some reason I can't get "-f" to actually "-FIX".

As for the malware itself, it's fairly interesting and I was going to post a few things about it at some point, mainly strategies for its analysis. I don't know if anyone else has been looking at it, but I was going to recommend it if anyone is looking for a little malware ripping project.

September 13th, 2011, 13:24
uh oh JMI where are you

yes you can use !chkimg to check And WHEN I USED it it USED to FIX things i haven't used it lately

as for walking every module you can use the undocumented

create the folder temp in c:\ first for some weird reason if the folder didnt exist

this command fails

will send the output to windbg command window and will delete the file

0 errors : ntdll
279 errors : nt (804d8fcf-806243d2)
804d8fc0 02 00 00 0f ae 03 0f ae 08 89 15 c0 f5 df ff *90 ................
804d8fd0 0f 29 04 24 e8 *c3 *62 *c1 *00 0f 28 04 24 8b 4d fc .).$..b...(.$.M.
804d93b0 24 01 00 00 8b f8 *e9 *0e *8d *c0 *00 db eb 00 66 39 $.............f9
804de770 89 55 0c *e9 *3d *0b *c1 *00 *cc *cc 89 5d 00 89 7d 04 .U..=......]..}.
Error for MRxVPC: Could not find image file for the module. Make sure binaries are included in the symbol path.
0 errors : wdmaud
0 errors : mrxdav
0 errors : ndisuio
Error for dump_atapi: Could not find image file for the module. Make sure binaries are included in the symbol path.
Error for ipnat: Could not find image file for the module. Make sure binaries are included in the symbol path.

0 errors : mouclass
Error for fdc: Could not find module base
0 errors : TDI

if driver verifier is running

804f137b,1a37b, 804d7000
nt!CcSetActiveVacb+af, .text
804f137c,1a37c, 804d7000
nt!CcSetActiveVacb+b0, .text
806241d0,14d1d0, 804d7000
nt!MiVerifierThunks+0, PAGE
806241d1,14d1d1, 804d7000
nt!MiVerifierThunks+1, PAGE

September 13th, 2011, 17:16
I'm right here. But not sure what you wanted/expected me to do.

Was I supposed to mention searching??

I don't want to end up sleeping with Woodmann's fishes.


September 13th, 2011, 22:54
OK, so who called the Principal..?

Nice, undocumented Windbg. Actually, the deleted temp log file is more useful because it includes the symbol names for the modified bytes, whereas the command window output doesn't. I'm sure you noticed !chkallimg is simply a shortcut for the following command internally.

kd> !chkallimg
!for_each_module !chkimg -db -mmw c:\temp\chkimg_.log vrsSewl| @#ModuleName

So if called directly the logfile isn't deleted and you get yet another form of output:


7c90df5e|df5e|ntdll!NtQueryDirectoryFile+0| .text|b8|e9
7c90df5f|df5f|ntdll!ZwQueryDirectoryFile+1| .text|91|a6
7c90df60|df60|ntdll!ZwQueryDirectoryFile+2| .text|0|80
7c90df61|df61|ntdll!ZwQueryDirectoryFile+3| .text|0|14
7c90df62|df62|ntdll!ZwQueryDirectoryFile+4| .text|0|92

I was looking at the exports of ext.dll, there's actually quite a number of "undocumented" Windbg commands aren't there? Something like the first 30 or so by ordinal it seems.

The behaviour of !chkimg -f with this malware is odd. If you correct the hooked bytes with RKU or manually with Softice, all is OK. There is no reinfection or anything of that sort (even though the malware does monitor for new processes through a CreateToolhelp32Snapshot thread loop).

To test why Windbg failed where the other methods didn't, I put a Softice breakpoint on ext.dll!chkimg and did a lot of tracing. Thunking down to dbgeng.dll I could see the modifed bytes being repaired correctly in a _mapped_ image of the infected ntdll. I wasn't able to find where this mapped image is presumably used to replace the original infected ntdll image, but it seems likely that is where it fails, maybe.

It's a bit disconcerting that under some unknown circumstances, !chkimg -f doesn't seem to work, even though it reports success. On an otherwise clean system it will repair modified bytes OK though. I tried removing all the hooks from kd.exe, just in case that was affecting !chkimg behaviour, but it made no difference. Remains a mystery for now.

September 14th, 2011, 14:20

I'm sure you noticed !chkallimg is simply a shortcut for the following command internally.

kd> !chkallimg
!for_each_module !chkimg -db -mmw c:\temp\chkimg_.log vrsSewl| @#ModuleName

So if called directly the logfile isn't deleted and you get yet another form of output:

never occured to me to call it directly that proves if one is an idiot to start with one will be an idiot to the end

look at my idiocy


0:004> bl
0 e 7c90d0ae 0001 (0001) 0:**** ntdll!ZwCreateFile ".if ((poi(esp+8) & 0x00010000) > 0 ) {dt nt!_Object_attributes objectname poi(esp+0c)} .else {gc}"
1 e 7c90d59e 0001 (0001) 0:**** ntdll!NtOpenFile ".if ((poi(esp+8) & 0x00010000) > 0 ) {dt nt!_Object_attributes objectname poi(esp+0c)} .else {gc}"
0:004> g
+0x008 ObjectName : 0x011dde78 _UNICODE_STRING "\??\c:\temp\chkimg_.log"
eax=011dde90 ebx=00000000 ecx=7c9142af edx=7c980600 esi=7c90d59e edi=00204040
eip=7c90d59e esp=011dde24 ebp=011dde98 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
7c90d59e b874000000 mov eax,74h
0:004> dd esp+8 l1
011dde2c 00010080
0:004> ed esp+8 0
0:004> g

with this idiocy i get

0 errors : SHELL32
0 errors : USER32
7c868d8c,68d8c, 7c800000
kernel32!GetBinaryTypeW+80, .text
7c9171ca,171ca, 7c900000
ntdll!LdrpCheckForLoadedDll+408, .text
Could not delete file: c:\temp\chkimg_.log

0:000> .shell dir /b c:\temp
.shell: Process exited
Press ENTER to continue
<.shell waiting 1 second(s) for process>
<.shell process may need input>

0:000> .shell type c:\temp\chkimg_.log
7c868d8c|68d8c|kernel32!GetBinaryTypeW+80| .text|60|62
7c9171ca|171ca|ntdll!LdrpCheckForLoadedDll+408| .text|60|62
.shell: Process exited
Press ENTER to continue
<.shell waiting 1 second(s) for process>
<.shell process may need input>

iirc the output was same didnt notice anything much different in file and cmd window not sure if i looked right

September 14th, 2011, 23:22
You prevented the logfile from being deleted? Hardcore!

September 16th, 2011, 19:06
hehe yep actually .shell command also creates a temp file shX.tmp in %temp% which some times i need to grab for this or that reason

so i use that trick most of the time


+0x008 ObjectName : 0x00bae2a0 _UNICODE_STRING "\??\C:\DOCUME~1\Admin\LOCALS~1\Temp\shl42.tmp"
eax=00bae2c0 ebx=00000100 ecx=c0110080 edx=00200000 esi=7c90ff2d edi=00000000
eip=7c90d0ae esp=00bae224 ebp=00bae2b8 iopl=0 nv up ei ng nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000282
7c90d0ae b825000000 mov eax,25h
0:001> dd esp l4
00bae224 7c8109b6 00bae2c0 c0110080 00bae260

there are several other files that are deleted undocumented like dbg0.tmp in windbg folder
which iam yet to grab and take a look at

like below


0:001> g
ModLoad: 01d00000 01d48000 ********\symsrv.dll
+0x008 ObjectName : 0x00bab740 _UNICODE_STRING "\??\**********\DBG0.tmp"
eax=00bab758 ebx=00000000 ecx=7c9142af edx=7c980600 esi=7c90d59e edi=00204040
eip=7c90d59e esp=00bab6ec ebp=00bab760 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
7c90d59e b874000000 mov eax,74h
0:001> dd esp l4
00bab6ec 7c831fe4 00bab758 00010080 00bab714

as you can see
one is ZwCreateFile CreateFile Api
other is NtOpenFile (called via DeleteFileA api

September 26th, 2011, 02:50
Right..so a bump again on this coz I was looking at Honeynet challenge 8 and trying to work my way through it. This is already solved and has solutions too, so I thought it would be a nice learning exercise. That's over here - https://www.honeynet.org/node/668

So if you guys remember the start of this thread, I had seen that malware otherwise hidden in CMD and regedit was visible when I opened CMD in Olly.. thats coz Olly was 'somehow' whopping the hooks itself while other debuggers were not. That's where this stands now.

Now this malware in the Honeynet challenge also seems to do exactly the same... except it is hidden from Olly as well .. I tried the same things... like opening CMD and regedit in Olly but it didnt get displayed. So I'm assuming Olly does NOT rewrite the hooks every time... but did it only for that 1 piece of malware which was earlier discussed. Is that rt?

Just to show you guys some more stuff and save your time (hopefully ) I'll show you what all I got so far:

4 attachments:
registry - Run key blank.. hooked I think
cmd - Appears to cd into the directory 'algonic' but doesnt actually go in and remains in C:\. Look at the output if I try to cd into some other non existent directory
Explorer - some funny blank folder, which you cant go into it keeps coming back to c: recursively but opening multiple subdirectories in the subpane..like a broken softlink
CaptureBat logs - to show you what the malware is doing

The other problem is that after the initial run.. there is nothing to hook to and try and see where the hooks are like discussed at the start of the thread. I'm still working my way through and reading solutions (all are very complicated ) , but as usual I thought I would post here too as it seemed to be related


UPDATE: Updated the screenshot to include GMER detection. Gmer, a rootkit analyzer mentioned in a solution seemed to detect the hooks and I could copy files from the Gmer interface to my desktop. Is that the only way you generally retrieve files, otherwise not accessible? What if <ANY TOOL> does not detect these for whatever reason?