Log in

View Full Version : New "tool" - S.I. int 3 / int 1 patcher


nikolatesla20
February 7th, 2003, 14:14
This is my first loader program and I must say I am very proud of it so far, it works pretty well I think. I finally figured out how to do the "loading"

OKee, the whole point of this program is for those of you with Win2K/ XP on their systems, and SoftICE. SoftICE likes to put a INT3 on UnhandledExceptionFilter , and some programs check for this. Also, SoftICE hoses int1 up in the IDT.

You ask: WHY DO I NEED THIS?
Well, no one really "needs" it, but if you have hidden softICE as best you can under win2k / XP and a program still detects a debugger, chances are it's using either int3 or int1 detection. And this program will fix both. (well, not int1 just yet, but soon). So you could give it a shot at least...

Rather than having to try and BPM on UnhandledExceptionFilter, and then step thru code, or not begin able to BPM at all anyway, because of SEH's, you can use this little utility I made up, and it should work. It heals UnhandledExceptionFilter for you.

By the way, you also will not need to have SuperBPM with this either.

ALSO I have a driver that I've written to patch INT1 as well and it works great, but I am still integrating it into this program yet, going thru all the service API's takes a while! So be patient I will have it working soon.

hxxp:\\webpages.charter.net\nikolatesla20\PatchUnhandledKernel.zip

-nt20

nikolatesla20
February 7th, 2003, 17:34
OKee People


I've gotten INT1 to work now , I think.

In other words, I know the driver works but I had to link the driver into the program with the service manager to load it.


hxxp:\\webpages.charter.net\nikolatesla20\PatchUnhandledKernel.zip

Let me know of any glaring bugs.


-nt20

nikolatesla20
February 12th, 2003, 14:26
Hello, I forgot to include a readme. Here are some notes:


INT 3 PATCH:

This really isn't a global patch. YOu must use the loader to patch this . Read on.

The method I used is very simple. I tried to use my device driver to patch Kernel32 itself at UnhandledExceptionFilter, but it would blue screen my machine. Apparently SI holds on to the memory..

So instead I created a program "loader" that starts an executable using createprocess, and holds it while it patches kernel32 UnhandledExceptionFilter directly in that processes's memory space using WriteProcessMemory. When I did it that way, it worked.

I know the address to patch because kernel32 (and all system dlls) are in the same virtual address space in every process (they are "shared". So even my loader can simply ask for GetProcAddress and the returned address would be correct for any process. This is the address I use to patch UnhandledExceptionFilter in the loaded program.

This is the only way I've found to do it for now - trying to patch kernel32 globally gave me blue screens.

it would also be possible to patch code into a new process (still using a loader) to replace IsDebuggerPresent. You simply have to VirtualAlloc(), and copy the new asm you want (mov eax,0 ret) into the virtual alloc mem space, and then patch IsDebuggerPresent to call this routine instead. It would actually be pretty easy I think, and I plan on experimenting with this idea in the future. (Sort of like a dynamic code injection)

INT 1 PATCH:

This is a global patch that is good once you run it after rebooting. If you reboot, you need to run it again. This patch is applied as soon as you start my program. It uses a device driver (IDTPatch.sys) to patch the Interrupt Descriptor Table to default settings at Int 1.

-nt20

Aquatic
February 15th, 2003, 03:40
It works great!


doug
February 18th, 2003, 21:05
Very interesting, however - why not include the source?

Several people have done work on this topic, and none of them have included the source... FP (FrogsIce), pulsar (NTALL), [...] so what happened with these two projects is they went dead/outdated as soon as their respective coder went busy.

Furthermore, If one decided to detect this tool by scanning for a driver name, for example, anyone could easily recompile using his own string/settings.

Aquatic
February 18th, 2003, 21:18
What about creating a program that combines it with this: http://www.woodmann.net/forum/showthread.php?threadid=1806#post8485 ?

Just an idea.

nikolatesla20
February 18th, 2003, 22:10
I will include the source -

It's mainly that I thought most people might not be able to compile the driver part.


It'll have to wait until morning when I get to work (Yes, hehe I wrote this at work)

To Aquatic:

I've already made a patch that does exactly what that post describes. Search for "Driverstudio 2.7 anti detect" and you will find it. However, I think that it could use some updating, mainly to make one nice little distribution that has everything in it. It's in my possible plans.

-nt20

[NtSC]
February 19th, 2003, 14:02
What about implementing all your DS 2.7 Anti-Detect Patches in a Device Driver?

nikolatesla20
February 19th, 2003, 14:13
The idea had crossed my mind, but one problem exists that I haven't studied up on yet: how to get where in memory softICE is installed, and also, making sure it's the right version. Both of which I'm sure are fairly "simple" but I haven't investigated it at all yet.


ALso, I'm not sure if that would still work 100%, since once the SI driver is loaded, you'd have to change the symbolic names somehow, and I'm not sure yet as well if it is possible to do it dynamically like that (to rename SIWVID, for example). If you mess up the renaming, SI 's window won't come up.

So for now, the patches will have to do There are many ways to do one thing....I've learned all of this on my own reading and by skimming the forum/net for information. So even tho it's nice to have a prepacked "tool" I think anyone can learn if they really want to know how to do their own thing.

Source Code:

hxxp://webpages.charter.net/nikolatesla20/SIPatchSource.zip


This uses the DriverWorks driver model, which you can install with SI 2.7. It also needs the 2K / XP DDK from microsoft to be installed. IF you don't kow what these are, you shouldn't be looking at the code :P

-nt20

Kayaker
February 19th, 2003, 20:44
Quote:
Originally posted by nikolatesla20
The idea had crossed my mind, but one problem exists that I haven't studied up on yet: how to get where in memory softICE is installed, and also, making sure it's the right version. Both of which I'm sure are fairly "simple" but I haven't investigated it at all yet.

-nt20


Hi nt20

I'm not sure what you're trying to patch in SoftIce, but you can get the base address of winice and a pointer to its Service Table this way. The DDB_Service_Table_Ptr gives you the exported functions of winice, few as they are, and on my system the first one seems to return the Version number:

mov eax, 00000405 ; ver 4.05(332)
clc
ret

You can get access this way

;-------------------------------------------
;VxD_PAGEABLE_DATA_SEG
; Device_Id DWORD 0202h ; Device Id for Softice
; Device_Name db "WINICE ",0 ; Device Name (only required if Device Id = 0)
; DDB DWORD ? ; returns a 'device descriptor block' (DDB) linear address
; WiniceBaseAddr DWORD ? ; winice base address
; pszName db 80 dup(?) ; receives object name of VxD
;VxD_PAGEABLE_DATA_ENDS
;===========================================

;----------------------------------------
; Get_DDB Determines whether or not a VxD is installed for the
; specified device and returns a DDB (Device Description Block)
; for that device if it is installed.
;----------------------------------------

mov eax, Device_ID
;mov edi, Device_Name
VMMCall Get_DDB
;mov [DDB], ecx ; (VxD_Desc_Block STRUC - see vmm.inc)

mov edx, [ecx+30h] ; [ecx+30h] = DDB_Service_Table_Ptr

; The DDB_Service_Table_Ptr will give you the exported functions of SI
; (I get 4 of them (type 'vxd winice' ; in SI) and the first looks like a version number)

;----------------------------------------
;_GetVxDName(DWORD laddr, DWORD pszName) - Returns base address of VxD in eax
; pszName buffer receives object name of VxD that contains the specified linear address.
;----------------------------------------

;mov ecx, [DDB]
xchg eax, ecx
VMMCall _GetVxDName, <eax, offset32 pszName>
mov WiniceBaseAddr, eax ; base winice address
; offset32 pszName returns SICE(01) + 0000FE6C

ret
;============================================================


If you need "extra space" to runtime patch some code... check in winice there are roughly 30 KILObytes of memory taken up with useless resource strings like AIRONET WIRELESS COMMUNICATIONS or ALPS ELECTRONIC CO LTD.

Have fun,
Kayaker

nikolatesla20
February 19th, 2003, 23:02
Thanx for the info Kayaker, but I am not working with VxD (*blech*) Only WDM and NT native drivers - so I need to use NT kernel API calls -

Don't know if they will map to anything similar..

But that's cool stuff there!

-nt20

doug
February 20th, 2003, 01:05
you can use NtQuerySystemInformation to find the image base of a driver, provided it is loaded & you know its name.


Basically you invoke the function with "SystemModuleInformation", then you cycle through the device name array until you find softice's, then you get the pImageBase (or is it lpImageBase) member on that module.

I hope what I've said makes sense to you. I am a little short on time, so i can't give you detailed info on it. I'm sure someone else can though.

i think ^daemon^ has used that API in one of his SoftICE detection trick.

As for the version ID, well either a crc32, a version string search, OR (better) get the version info from the .rsrc

Kayaker
February 20th, 2003, 01:05
Alas I don't haven't any experience with sys drivers and I may only be guessing, but I was under the assumption that the WDM model supported all earlier VMM calls in some fashion. The calls certainly exist in the WDM-based XP DDK. In general they can also be called via Kernel Ord001. This was sort of brought up in another thread and never really clarified, if and how all the truely low level system calls can be called in Win2K. If vxds don't run there must be a way to access the functions without hacking into ring0. Has the VM changed that much that it's no longer accessible, or have all the functions been replaced?

In any case, the DDB VxD_Desc_Block is a structure that is installed globally when any kind of driver (vxd based anyway) is loaded onto your system dynamically or statically, giving basic information about the driver. I'm curious, do the new sys drivers not use this basic structure? What does the Softice command VXD do in Win2K? If it gives you address and DDB information and if 'vxd winice' lists its ring0 services, then they're still using the DDB. If not, then things have changed dramatically.

Point being anyway was a way to "find" where winice was loaded in memory, perhaps you can find some similar NT kernel API calls that will return a specific structure or starting address.

Kayaker

doug
February 23rd, 2003, 23:05
You don't need to code a driver to get softice image base.

@nikolatesla20:
I included "GetNTICEBase.c", it shows how to do it using NtQuerySystemInformation.

Also, since that function returns a string to the path of the driver, you could feed that info to the functions provided by version.dll and parse the version info from the resource - and that returns what you want:
ex:
"FileVersion" : "4.2.7 (Build 562)"

nikolatesla20
February 24th, 2003, 10:33
Thanks! Cool stuff!

-nt20

neemous
March 5th, 2003, 23:10
If one wanted to patch softice 427_562 installed under 9x
similarly, would you just search for unicode "winice" instead "ntice" and
the other strings originally described by +splaj? Or is
completely different for winice and ntice?


n

NervGaz
March 6th, 2003, 02:27
If you're using a loader of sorts you could do something like this to hide the devicenames... saw it done by Elicz in one of his pntice.zip files.. dunno wich tho...

Code:

.data
szSiwvidSTART db 'SiwvidSTART',0
szXiwvidSTART db 'XiwvidSTART',0
szNTice db 'NTice',0
szXTice db 'XTice',0

.data?
buffer0 db 104h dup(?)
buffer1 db 104h dup(?)

.code
HideSiceDevices:
mov edi, offset buffer0

invoke QueryDosDeviceA,ADDR szSiwvidSTART,edi,SIZEOF buffer0

test eax,eax
jz DoIt

invoke DefineDosDeviceA,DDD_RAW_TARGET_PATH,ADDR szXiwvidSTART,edi

test eax,eax
jz DoIt

invoke DefineDosDeviceA,DDD_RAW_TARGET_PATH+\
DDD_REMOVE_DEFINITION,ADDR szSiwvidSTART,edi


DoIt:
mov edi, offset buffer1

invoke QueryDosDeviceA,ADDR szNTice,edi,SIZEOF buffer1

test eax, eax
jz Bail

invoke DefineDosDeviceA,DDD_RAW_TARGET_PATH,ADDR szXTice,edi

test eax, eax
jz Bail

invoke DefineDosDeviceA,DDD_RAW_TARGET_PATH+\
DDD_REMOVE_DEFINITION,ADDR szNTice,edi


Bail:
ret

;------------------------------------------------------------------------------------------------
UnHideSiceDevices:
mov edi, offset buffer0

invoke QueryDosDeviceA,ADDR szXiwvidSTART,edi,SIZEOF buffer0

test eax,eax
jz DoIt_

invoke DefineDosDeviceA,DDD_RAW_TARGET_PATH,ADDR szSiwvidSTART,edi

test eax,eax
jz DoIt_

invoke DefineDosDeviceA,DDD_RAW_TARGET_PATH+\
DDD_REMOVE_DEFINITION,ADDR szXiwvidSTART,edi


DoIt_:
mov edi, offset buffer1

invoke QueryDosDeviceA,ADDR szXTice,edi,SIZEOF buffer1

test eax, eax
jz Bail_

invoke DefineDosDeviceA,DDD_RAW_TARGET_PATH,ADDR szNTice,edi

test eax, eax
jz Bail_

invoke DefineDosDeviceA,DDD_RAW_TARGET_PATH+\
DDD_REMOVE_DEFINITION,ADDR szXTice,edi


Bail_:
ret



dunno if it works all the time but i tested it some on win2K a while back and i'm guesing it was originally written for NT so it should work i guess...

neemous
March 6th, 2003, 11:05
thanks nrevgaz
um my mistake, I wasn't very clear/posted
in the wrong thread
I was referring to the patch described by
+splaj that is mentioned by Aquatic earlier in
this thread, the one that tesla later wrote
an auto-patcher for....