KiFastSystemCall wrongly detected as hook

[GoogleCodeExporter]

What steps will reproduce the problem?
1. python vol.py apihooks -f winxpsp3_fr_x86.mem apihooks

What is the expected output? What do you see instead?

It dumps KiFastSystemCall as a hook in ntdll.dll (happens for each exported 
function in each processes...)

What is exepected is filtering out KiFastSystemCall from ntdll.dll as it was 
meant in the first place.

What version of the product are you using? On what operating system?
svn r2826

Please provide any additional information below.

I fix it with this :
--- volatility/plugins/malware/apihooks.py      (révision 2830)
+++ volatility/plugins/malware/apihooks.py      (copie de travail)
@@ -450,6 +450,7 @@

         # Add the RVA to make it absolute 
         KiFastSystemCall += module.DllBase
+        KiFastSystemCall += 0x10

         # Check each exported function if its an NT syscall
         for _, f, n in module.exports():

Original issue reported on code.google.com by mathieu.geli on 3 Jan 2013 at 8:11

[GoogleCodeExporter]

Original comment by jamie.l...@gmail.com on 3 Jan 2013 at 9:51

[GoogleCodeExporter]

Hi Matthieu, 

I'm not sure I understand the issue, could you paste or attach the output of 
apihooks that contains the erroneous KiFastSystemCall hooks? Also could you 
attach the ntdll.dll file from your xpsp3 system (from disk if possible, but if 
you only have a memory dump, use dlldump to extract it). That would help 
investigate why 0x10 fixes it for you. 

Thanks!

Original comment by michael.hale@gmail.com on 3 Jan 2013 at 10:04

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Michael,

reading apihooks.py, I understand from here :
if syscall_address != KiFastSystemCall:
    [handle hook]
    yield hook

that we take care not to declare a hook on the KiFastSystemCall function.
When I run apihooks on my image I got the screen filled with :

Hook mode: Usermode
Hook type: NT Syscall
Process: 1096 (svchost.exe)
Victim module: ntdll.dll (0x7c900000 - 0x7c9af000)
Function: NtAcceptConnectPort
Hook address: 0x7c90e500
Hooking module: ntdll.dll

Disassembly(0):
0x7c90ce40 b800000000       MOV EAX, 0x0
0x7c90ce45 ba0003fe7f       MOV EDX, 0x7ffe0300
0x7c90ce4a ff12             CALL DWORD [EDX]
0x7c90ce4c c21800           RET 0x18
0x7c90ce4f 90               NOP
0x7c90ce50 b801000000       MOV EAX, 0x1
0x7c90ce55 ba               DB 0xba
0x7c90ce56 0003             ADD [EBX], AL

Disassembly(1):
0x7c90e500 8d542408         LEA EDX, [ESP+0x8]
0x7c90e504 cd2e             INT 0x2e
0x7c90e506 c3               RET
0x7c90e507 90               NOP
0x7c90e508 55               PUSH EBP
0x7c90e509 8bec             MOV EBP, ESP
0x7c90e50b 9c               PUSHF
0x7c90e50c 81ecd0020000     SUB ESP, 0x2d0
0x7c90e512 8985dcfdffff     MOV [EBP-0x224], EAX
[...]

When scrolling I understood it was listing every exports from ntdll.dll for 
each processes.
First when looking at the beginning of Disassembly(1) we se it starts at 
0x7c90e500.
Second it does look like some legit wrapper to the syscalls.

So I dumped the KiFastSystemCall address retrieved here :

KiFastSystemCall = module.getprocaddress("KiFastSystemCall")

and it showed as 0x7c90e4f0.

I extracted the ntdll.dll from the image and that section of the exports looks 
interesting :

│0029 │ 0000e4f0 │ KiFastSystemCall                                       

│002a │ 0000e4f4 │ KiFastSystemCallRet                                    

│002b │ 0000e500 │ KiIntSystemCall

I think I got it : my patch is wrong (even if the result is good). This Windows 
system is using the old dispatcher (INT 2E) which is KiIntSystemCall and not 
the new one (sysenter) which should be KiFastSystemCall and volatility seems to 
assume that the new one is always used.

I hope that clarifies it.

Original comment by mathieu.geli on 3 Jan 2013 at 10:27

[GoogleCodeExporter]

Yes, that clarifies it - thanks and nice catch. How about this patch, it should 
allow the plugin to work when either method is used. 

Thanks!

Original comment by michael.hale@gmail.com on 3 Jan 2013 at 10:42

Attachments:

• apihooks_kiintsystemcall.patch

[GoogleCodeExporter]

yep much better (and working fine).

Original comment by mathieu.geli on 3 Jan 2013 at 10:58

[GoogleCodeExporter]

This issue was closed by revision r2832.

Original comment by michael.hale@gmail.com on 3 Jan 2013 at 11:01

• Changed state: Fixed