The Dark AllianceASM Knowledge, Game Hacking Info
   Home   Help Search Login Register  
Welcome, Guest. Please login or register.

Login with username, password and session length
Pages: [1]
  Send this topic  |  Print  
Author Topic: dump_wmimmc.sys calls (rev 822)  (Read 1327 times)
linosal
Administrator
Master Assembler
*****
Posts: 2067



WWW
« on: August 24, 2006, 12:54:54 PM »

Ok, looking at the dumpwmimmc in PE Explorer here are the System calls I see that are of interest.

ntoskrnl.exe!IoCreateNotificationEvent
info on it here http://www.osronline.com/ddkx/kmarch/k104_7bg2.htm
this creates an event used by KeWaitForSingleObject, or KeWaitForMultipleObjects

THIS IS THE ROUTINE THEY USE TO RUN THEIR SCANS....
If we bypass any of these,  GG will no longer monitor our events.

jmp_ntoskrnl.exe!PsSetCreateProcessNotifyRoutine -- Another check, jmp_ntoskrnl.exe, this may imply they have their own jumps for the ntoskrnl built into their sys file?  Not entirely sure about this tho.


There are several other calls to jmp_ntoskrnl.exe,  they are as follows
PsGetVersion                -- THIS IS USED BY ROOTKITS THAT CREATE KERNEL LEVEL HOOKS... TO IDENTIFY VERSION OF OS AND REQUIREMENTS.
PsGetCurrentProcessId
PsLookupProcessByProcessId
Ke386SetIoAccessMap
Ke386QueryIoAccessMap
PsSetCreateProcessNotifyRoutine
_except_handler3
Ke386IoSetAccessProcess




Other processes of intrest:
ntoskrnl.exe
KeStackAttachProcess
PsTerminateSystemThread
KeCanceltimer
KeWaitForMultipleObjects
KeSetTimerEx
KeServiceDescriptorTable
KeAttachProcess
« Last Edit: December 31, 1969, 07:00:00 PM by linosal » Report to moderator   Logged

--
AdBot
linden
Guest
« Reply #1 on: September 01, 2006, 12:27:08 PM »

Not sure what you mean by "jmp_ntoskrnl.exe".
Seems to me that it's just a notation used by your tool to imply an imported function from ntoskrnl.exe.
I think the most siginificant change after rev 809 is the addtion of PsCreateSystemThread.
They now start a system thread to monitor wether someone has uninstalled their hook.
So, one of the first thing to do in disabling GG, would be to hook PsCreateSystemThread.
If inline hooking appears to be too difficult, simple IAT hooking would work as well.

PsSetCreateProcessNotifyRoutine is easy to defeat.  In your driver, just call the function and iterate through all possible kernel address with the second parameter set to TRUE. (That also disables CE's process watcher, so for CE to work, you'd have to exclude CE's driver address range)
« Last Edit: December 31, 1969, 07:00:00 PM by linden » Report to moderator   Logged
linosal
Administrator
Master Assembler
*****
Posts: 2067



WWW
« Reply #2 on: September 01, 2006, 01:59:08 PM »

Quote from: "linden"
PsSetCreateProcessNotifyRoutine is easy to defeat.  In your driver, just call the function and iterate through all possible kernel address with the second parameter set to TRUE. (That also disables CE's process watcher, so for CE to work, you'd have to exclude CE's driver address range)


Ok, I'm curious how you would iterate throught the addresses, and know the range that is allocated?
« Last Edit: December 31, 1969, 07:00:00 PM by linosal » Report to moderator   Logged

--
linden
Guest
« Reply #3 on: September 01, 2006, 03:47:53 PM »

Kernel address usually range from 0x80000000 and above.  So, the basic code would be:

for(i = 0x80000000; i < 0xFFFFFFFF; i++){
    PsSetCreateProcessNotifyRoutine((PCREATE_PROCESS_NOTIFY_ROUTINE)i, TRUE);
}

That's the basic form.  It will remove ALL notify routines in the kernel.(execution takes a few minute...slow!)

To exclude CE:
for(i = 0x80000000; i < 0xFFFFFFFF; i++){
    if( i >= CE_DriverBase && i <= (CE_DriverBase + CE_DriverSize) ) continue;
    PsSetCreateProcessNotifyRoutine((PCREATE_PROCESS_NOTIFY_ROUTINE)i, TRUE);
}

Or, you can disable it only for GG like this:
for( i = Dump_wmimmc_Base; i < (Dump_wmimmc_Base + Dump_wmimmc_Size); i++){
    PsSetCreateProcessNotifyRoutine((PCREATE_PROCESS_NOTIFY_ROUTINE)i, TRUE);
}

To exclude or target specific driver, you must find their address range, but it's trivial.  (for CE, just peek into its DriverObject, for dump_wmimmc.sys, use PsSetLoadImageNotifyRoutine)

You can also render PsSetCreateProcessNotifyRoutine useless by filling up all 8 slots with dummy routines before GG loads dump_wmimmc.sys.

Well, it's easy, ....which means defeating PsSetCreateProcessNotifyRoutine won't disturb GG much :(
« Last Edit: December 31, 1969, 07:00:00 PM by linden » Report to moderator   Logged
AdBot
linosal
Administrator
Master Assembler
*****
Posts: 2067



WWW
« Reply #4 on: September 01, 2006, 04:57:13 PM »

We need to determine which routines it uses to search for strings in other apps, I'm sick of having to mess with strings to get CE undetected.. There has to be a better way, something to hook to block CE's mem scans.

Could we trap IOCTL requests between GG and the dump_wmimmc.sys
« Last Edit: December 31, 1969, 07:00:00 PM by linosal » Report to moderator   Logged

--
linden
Guest
« Reply #5 on: September 01, 2006, 05:33:04 PM »

You can definitely trap GG's IOCTL request, but that doesn't prevent GG from scanning other processes.

Two ways that I can think of to disable memory scanning...
1. hook NtOpenProcess (not from SDT, but by function entry point overwriting)
2. use DKOM method as in FUTo rootkit.  http://uninformed.org/?v=3&a=7&t=sumry
The latter method is better, but it's complicated.
« Last Edit: December 31, 1969, 07:00:00 PM by linden » Report to moderator   Logged
linosal
Administrator
Master Assembler
*****
Posts: 2067



WWW
« Reply #6 on: September 01, 2006, 08:28:24 PM »

Complicated is fine... My goal is to have a UCE for our group,  Dark Alliance Engine.  I am currently working on it, source and binary will be posted up here.

I will look at the DKOM,  see if I can understand it.  My ultimate goal of course will be using CE pretty much As-Is, except with our kernel modifications in the driver. :)

We also need to find a way to hide our UCE from GG for more than just a version. .. Any thoughts would be appreciated.

I'm sick of using semi-public fixes to this garbage,  I want a CE that will run through several GG updates. Better yet just bypass GG altogether ala moose style.
« Last Edit: December 31, 1969, 07:00:00 PM by linosal » Report to moderator   Logged

--
xumx
Guest
« Reply #7 on: September 02, 2006, 05:56:13 AM »

as long as we dont leak the UCE, it should be able to stay alive for quite a few GG versions
« Last Edit: December 31, 1969, 07:00:00 PM by xumx » Report to moderator   Logged
Idogears
Guest
« Reply #8 on: September 03, 2006, 03:50:32 AM »

So, what's our long-term goal?

Emulate GameMon.des?
« Last Edit: December 31, 1969, 07:00:00 PM by Idogears » Report to moderator   Logged
john0312
Guest
« Reply #9 on: September 04, 2006, 02:47:24 AM »

Probably, but we gotta find out how it communicate with maplestory.exe
« Last Edit: December 31, 1969, 07:00:00 PM by john0312 » Report to moderator   Logged
yoyoyip
Guest
« Reply #10 on: September 04, 2006, 11:54:46 PM »

I got the disassembly of dump_wmimmc.sys(Rev822) from IDA Pro.
« Last Edit: December 31, 1969, 07:00:00 PM by yoyoyip » Report to moderator   Logged
Pages: [1]
  Send this topic  |  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC
DB Theme: deruni
Valid XHTML 1.0! Valid CSS!