greetz

i spent long hrs trying to figure out what was the problem with kernel32!unhandledexceptionfilter patch in driverstudio 2.7 as explained by spath.

the patch works with some exes (peshield for example) but other exes like sd2 just exit somewhere along the SEH chain if my guess is right.

i would request someone (SPLAJ!!!!!! ) to please explain what exactly this undhandledexception patch does to softice. the sd2 exes work fine without softice but with this patch they exit why ???

somone plz throw some light on what is going on ??

thnx in advance

best regards
pasha

greetz all

pffff..after long hrs of disassembly under IDA of NTICE.SYS, i finally managed to patch some more locations (problem was NTICE was feeding in improper codes during exceptions which could be detected) of course you can do a faults off inside sice to achieve the same results. well what do you say, i found that out after i spent almost 4 hrs on the disassembly

now, my problem has not been solved completely, after this i was able to get some other exes which were exiting to run, but still sd2 exes just exit some where at 0x7765ABCC which i suspect to be in the kernel32.dll exception rerouting area.

i also did some tinkering with KiUserExceptionDispatch to monitor what exceptions were caused and to my surprise found that there were none generated by the sd2 executable !!!!. yet it exits...

i request..splAjjjj...!!!!...nicolatexla20!!!!!...analyst!!! someone..plz do help me out with this wierd behaviour if someone knows the answer to this..

thnx in advance...

best regards
pasha

allo,


softice sets the first opcode of undhandledexceptionfilter
to 0CCh, so it has its own internal breakpoint on the api
to catch exceptions, safedisc scans for the 0CCh opcode,
(at the start of all kernel apis actually) so a quick fix is
to grab some space in the kernel a code a
jmp undhandledexceptionfilter, then set the export table
to this jmp, that way safedisc will check the jmp and not the
start of the real api.

on the subject of safedisc anti-softice, u'll also need to remove
DR7 bits softice sets, i'll never seen this covered anywhere but
the way i do it is, to disassemble NTICE, text search for DR7
you'll find about 4 refs with it, doing an OR with a 3xxh number,
subtract 300h and patch, i.e patch away 03.

also change the int 1 dpl, IDT to get base, then,
EB BASE+1*8+5 EE hm or was it 8B :-)

hope that helps,
yates.

Hmmm interesting stuff, yates is it possible u could expand
somemore on the last bit about int1 and the IDT

thanx

Darrren

Hi,

Sure, was you referring to the format of the IDT or more about
how its used, for the format take a look here,

http://www.yates2k.net/idt.htm

relevant bits, would be,

--------

To get the dpl we'll read the 5th byte, but this also contains the present and Interrupt
gate marker, so

mov byte ptr [ebx+5],dpl

1 00 01110
P DPL 32bit INT

The DPL is just 2 bits of this byte, so we have a max value of 3, simple set it
and replace the byte at +5

DPL 0 = 8Eh
DPL 1 = AEh
DPL 2 = CEh
DPL 3 = EEh

---------

yates.

thanx for the reply, insteresting and deep stuff

i do have another question if u dont mind regarding



i guess this would be a live patch into memory or could kernal32.dll
be edited directly on disk ?

as if the kernal32.dll exports where altered to point to this
new undhandledexceptionfilter wouldn't sice look this up through
the export table or does it use another method to grab the
function address ?

Thanx

Darren

greetz yates

thnx a ton for the reply. i have been trying my heart out for the past 3 weeks now, i have cut and pasted secdrv.sys disassembly code all around my room and look at it every time trying to figure out what is happening

now i am gonna try what u have said, but Dr7 is only set like that when i load the exe thru the symbol loader isnt it ??

coz when i coded a KMD and performed devio and checked Dr7 it was 400h which is the normal value with/without sice loaded.

owl told me that there is some check with Dr7 GE/LE bits in safedisc 2, but i found none in the disassembly uptil now. can u please confirm this ???

thanks again.

best regards
pasha

greetz yates

i tried ur method of dr7 patching in ntice.sys (am using DS 2.7)

these were the locations for me

.text:00047128 or ebx, edx
.text:0004712A or ebx, 30Ch
.text:00047130 mov dr1, esi
.text:00047133 mov dr7, ebx


text:00047143 or ebx, 303h
.text:00047149 mov dr0, esi
.text:0004714C mov dr7, ebx

.text:0004715C or ebx, 330h
.text:00047162 mov dr2, esi
.text:00047165 mov dr7, ebx

and

.text:00047175 or ebx, 3C0h
.text:0004717B mov dr3, esi
.text:0004717E mov dr7, ebx



but to no aval , the sd2 exe still abruptly exits without any message boxes (2.90.40, igi2) when i patch kernel32!unhandledExceptionFilter in ntice.sys to Zhandledsomecrap, if i leave it as it is, it gives me a "Debugger Detected" message as usual.

any ideas ??

best regards
pasha

just one little thing.



I believe it would be 8E, but i'm sure thats what u meant, since a couple lines after you mentionned

/me pokes yates and smiles ;p

Darren,

>as if the kernal32.dll exports where altered to point to this
>new undhandledexceptionfilter wouldn't sice look this up through
>the export table or does it use another method to grab the
>function address ?

yup exactly, as i said its just a quick fix, for on the fly fix, you can
make .sys to patch it if you like.

pasha,

Hmm exits silently eh, sounds you may of past the main checks
and being quit by something else, the main stuff is here,

10002F73 E8 15 E4 FF FF call antidebug
10004560 <- different checks for each call, all should return 0!

10004608 E8 83 4E 00 00 call BCHK
1000461B E8 50 4D 00 00 call UnhandleExceptionFilter_Check
10004654 E8 D7 4A 00 00 call INT_1_Check

couldnt find the dr7 one, maybe they (re)moved it ?

ur dr7 listings look ok too.
it could be exiting cos it detects daemon tools or acholo 120%
axvodka.sys or something, also any BPMs will make it exit

.txt2:1000D830 BAD_EXIT ; quit and screw stack
bpm here and backtrace ur exit if you like too :-p

Doug,
yup

yates.

SecDrv func 3c checks both DR1 and DR7. So don't use DR1 or patch your SecDrv. (which is probably better, as they also check the offsets between INT vectors <hint> )

oh yeh, i tried unloading my driver and doing, r eax 0 after the
unhandleexceptionfilter call and it just quit like you said,
seems you need at least int 1 or 3 hooked to alter the interrupt
displacement (:

yates.

greetz

ahh.....finally a hint...

---------------------------------------------------------------------------------
SecDrv func 3c checks both DR1 and DR7. So don't use DR1 or patch your SecDrv. (which is probably better, as they also check the offsets between INT vectors <hint> )
---------------------------------------------------------------------------------

but i thought the INT vectors offset check was only valid under win 9x/ME ????? is it valid under NT/2K too ?? hmm..time to check this out

okipoki, am off to try this one too..not leaving this sd2 crap till i get to the bottom of it..now my room is full of NTICE and SECDRV disassembly sources . man now i know why ppl call me a moron..

thnx a ton

best regards
pasha

Thanx for answering a couple of questions of mine yates
and also sorry pasha sort butted into your thread a little

always good to discover more methods sice might be
detected

Darren

ur welcome

greetz

i tried the last approach to reduce the distance between int1 and int 3 (1Eh) by just redirecting thru my KMD int1 and int3 handlers that are just 06 bytes apart

without sice

I1OFFSET: 0x80465A96
I3OFFSET: 0x80465D6E
DIFF: 0x000002D8

with sice
I1OFFSET: 0xBAE13729
I3OFFSET: 0xBAE13747
DIFF: 0x0000001E

with my kmd
I1OFFSET: 0xED5E14BA
I3OFFSET: 0xED5E14C0
DIFF: 0x00000006

but still sice simply exits without display of any message box when i patch that kernel32!unhandledexceptionfilter to kernel32!Zhandledexceptionfilter.

if i leave it alone, then it displays that "debugger detected" msgbox.

so in a nutshell, i have patched/done the following
1) int 1 DPL=0 using my kmd
2) meltice (by changing all the names as in splajs patch)
3) int1-int3 distance using my kmd
4) int 3 bchk by splaj patch
5) int 41 debugger check patch
6) CC at first byte of unhandledexceptionfilter
7) DR7 patch in ntice.sys
8) i dont use any of DR1-Dr3 for breakpoints
9) faults off in sice

man, i still cant think how the hell sice is detected under NT/2k..(...

i would appreciate any pointers on this..i know i shouldnt be asking, but it has been a month almost since i set out to defeat sice checks by sd2 under NT/2k/XP

thnx again

best regards
pasha

Softice could still be detected using OpenService with "ServicesActive", which returns strings of the current services active.


For example, go into Device Manager on Win2K or XP. Now click "View->Show Hidden Devices", and you will see NTice is listed as a device. YOu have to somehow change that name.

I haven't gotten around to doing so, I don't know how to do that yet.

-Lunar_Dust

greetz lunar

i guess splajs patch takes care of that renames NTICE inside NTICE.SYS and SIWVID.SYS to ZTICE and also renames SIWVID to ZIWVID. so any of the createfilea, openservice, queryobjectdirectory, or any other meltice variants will not suceed coz NTICE is no longer the device name.

best regards
pasha

No, it does not - I am the one who created the patches based of Splaj's walkthru, and I have them applied on my systems, and NTice is still listed in the services. The patches simply rename "CreateFile" name (The symbolic link) but the device name seems to still come out at NTice if you look at hidden devices. Just try it, you will see it is there even with patches installed.


-nt20

Isn't this name (the one displayed in the "hidden devices" list) simply based on a value in the driver's registry key?

Might be... I know I patched the registry, but to be sure I also patched the "three files" and renamed NTice.sys... Now my sice is safe from openservice-trick... ;P

...and also DAEMONS NtQuerySystemInformation-trick.

Ofcourse I had first patched NTice.sys with NicolaTesla20's fine patchers, to get rid of the usual stuff.

/Manko

greetz all

thnx a ton for the replies, i patched the registry as well as the files against openserviceA detection scheme.

but still sd2 2.90.40 seems to fish out my softice somehow .. i really have no clue on what detection scheme they have used ????

hope someone who has done tells me what detection in the world does sd2 uses ...hehe..this has been my all time greatest experience with NTice/sd2..

thnx again

best regards
pasha

Just to be sure... Have you actually tried if your patching succeded?

htetep://daemon.anticrack.de/

sice_detection Explanation:
OS: NT/2000/XP by scanning the loaded drivers (simple but as always EFFECTIVE!)

There are more detecters, for usual stuff posted on THIS board too...

/Manko

greetz manko

yep, i tried the listing and it doesnt show up as ntice anymore in the services panel. also i coded a small proggy using OpenService to list all services and it wasnt shown there either with Ntice, i renamed it to something else.

but in any case i dont think sd2 uses this mechanism because the exe displays msgbox just after the first deviceiocontrol to secdrv.sys, i put my money mostly on some DrX stuff, but yet even after patching all the things, the msg still pops up

i have patched my NTICe against all of the daemons detections and other detections. securom, peshield, pelocknt, armadillo, etc..the only stuff which detects it is sd2

so am awaiting any pointers..

best regards
pasha

um,

all I have to say is sd2 is using a system driver for this? well then you could be in big trouble. ... You should try to disam the sys file and see what it's doing (of course I'm sure you've already done so) -- sys files can't be protected.

The problem is the sys file could be using undocumented crap for doing its thing. Which may make it kinda hard to track down.

Plus, it's a deviceiocontrol call, can't you just modify the return buffer....

-nt20

greetz nikola

yep, i have disassembled secdrv.sys and am looking thru it documenting it everyday .

also the first thing i tried was attack using the devio modify buffer, but sd2 uses some kinda complex buffer techniques, it passes an input buffer and the devio call modifies the buffer accordingly and that data is used somewhere else in the program. i have the pattern of the failed devio call but i cant just patch it coz i would not know what it was expecting in the output buffer meaning i have to crack that logic which seems pretty complex at first looks.

so am looking at places where checks are performed with Drx and other stuff.

hopefully i should be able to find someting soon.. or someone can help me on the way..but all in all this has been a tremendous learning experience for me with secdrv and ntice internals..

thnx again

best regards
pasha

Well I haven't seen the V2.90 Secdrv yet.. but the one I had a look at, wasn't all that 'special'

Which secdrv function are you having problems with?! The secdrv function is put in the input buffer at position 0x0C. (the positions before that are: dwVersionMajor (0x00), dwVersionMinor (0x04), dwVersionPatch (0x08)and then you have dwCommand at 0x0C)

TIP: ignore those 4 dwords that get xor'ed in the output buffer.. it's nothing interesting (it's the KeTick value, but xor'ed over 4 dwords to 'hide' it). It's checked in the main dll to see if the call didn't last TOO long (ie. to screw people using 'normal' debuggers that don't freeze time)

Just looked it up.. the secdrv I had a look at way back was:

dwVersionMajor= 0x03;
dwVersionMinor= 0x0D;
dwVersionPatch= 0;

greetz sintax

without ntice loaded the first 2 deviceio call as as follows ---

1)DeviceIOControlevice:00000070, Code:EF002407, IbufSize=00000514, OBufSize=00000C18
===Inbuf starts===
03|00|00|00|12|00|00|00|00|00|00|00|3E|00|00|00|52|A0|8C|DB|3A|0D|19|4F|FD|94|2
E|A8|84|7C|BB|3C|

as seen
dwVersionMajor=0x03
dwVersionMinor=0x12
dwVersionPatch=0x00
dwCommandCode=0x3E

and then you have 2 more detections ---

IsDebuggerPresent call
NTICE detection caught call.
CreateFileA: \\.\Global\SecDrv, -->00000078
CreateFileA: \\.\Global\SecDrv, -->00000078

and then

2) DeviceIOControlevice:00000078, Code:EF002407, IbufSize=00000514, OBufSize=00000C18
===Inbuf starts===
03|00|00|00|12|00|00|00|00|00|00|00|3C|00|00|00|52|A0|8C|DB|3A|0D|19|4F|FD|94|2
E|A8|84|7C|BB|3C|0

here dwCommand=0x3c

now, with ntice loaded we have this ---

1st device io call -
1) DeviceIOControlevice:00000070, Code:EF002407, IbufSize=00000514, OBufSize=00000C18
===Inbuf starts===
03|00|00|00|12|00|00|00|00|00|00|00|3E|00|00|00|EC|C9|8C|DB|3A|0D|19|4F|FD|94|2
E|A8|84|7C|BB|3C|

as seen dwCommandCode=0x3E

and then you have 2 more detections ---

IsDebuggerPresent call
NTICE detection caught call.

BUT, the second device io call is never executed and i get the MessageBox saying debugger detected...

so i figure there is some problem with the device io call with dwCommandCode = 0x3E...any ideas what that function does ??

best regards
pasha

That isn't it..

3e = SETUP
3c = Check DR1 & DR7

The 3e call gives you the verification data you need to make the other calls to secdrv.
For example, if you wanna (ab)use the secdrv driver, you first make a SETUP call, using an input buffer that has:

pSi->dwVersionMajor= 0x03;
pSi->dwVersionMinor= 0x0D;
pSi->dwVersionPatch= 0;
pSi->dwCommand= 0x3e; // SETUP

(0x12 VersionMinor in your case), then on all subsequent calls you use the verification data returned by the setup:

pSi->bVerificationData[0] = pSo->bVerificationData[0];
pSi->bVerificationData[1] = pSo->bVerificationData[1];
pSi->bVerificationData[2] = pSo->bVerificationData[2];
pSi->bVerificationData[3] = pSo->bVerificationData[3];

(pSi = pointer to input buffer, pSo = pointer to output buffer)

With that information, you can try the 0x3c call.. it will give you 2 dwords back.. 1 with DR1 and 1 with DR7.


Have you done the following in SI:

> eb 8003f40d 8e

As mentioned before.. this changes the INT1 DPL.

greetz sintax

thnx for the amazing stuff, never knew so much about input/output buffers for sd2 devio. guess i will keep this thread going

yes, i have patched int1 DPL.

also, what i fail to understand is, if as u say 0x3E is for setup and then 0x3C is for getting Dr1 and Dr7. then why didnt the ~df409b.tmp (sd2 dll) issue a second devio call with 0x3c when ntice was loaded. it simply issued only the 0x3E call as i had posted in the previous message and then showed me the message box. any ideas on this ???

also, here is a snippet from secdrv.sys that i think is responsible for storing dr1 and dr7. can u confirm this plz --

loc_1093A: ; CODE XREF: sub_1092C+7j
.text:0001093A mov eax, dr1
.text:0001093D mov [ebp+arg_4], eax
.text:00010940 cmp [ebp+arg_4], 0BD331200h
.text:00010947 jnz short loc_10950
.text:00010949 mov eax, 3871DD10h
.text:0001094E jmp short loc_10959
.text:00010950 ; ---------------------------------------------------------
.text:00010950
.text:00010950 loc_10950: ; CODE XREF: sub_1092C+1Bj
.text:00010950 mov eax, dr7
.text:00010953 mov [ebp+arg_4], eax
.text:00010956 mov eax, [ebp+arg_4]
.text:00010959
.text:00010959 loc_10959: ; CODE XREF: sub_1092C+22j
.text:00010959 mov ecx, [ebp+arg_8]
.text:0001095C and eax, 500h
.text:00010961 mov [ecx], eax
.text:00010963 mov eax, [ebp+arg_C]
.text:00010966 mov dword ptr [eax], 4
.text:0001096C mov ax, 1
.text:00010970
.text:00010970 loc_10970: ; CODE XREF: sub_1092C+Cj
.text:00010970 pop ebp
.text:00010971 retn 10h
.text:00010971 sub_1092C endp
.text:00010971

i think i might need to patch something in here :> ????

awaiting a response as usual and thnx a ton once more

best regards
pasha

Well it's because SD is doing another test that you haven't found yet. All tests that SD does are all put in 1 subroutine call, they are called sequentially.. so just dump the main dll after the IsDebuggerPresent call (return) and then you will be able to quickly find all the tests.


As for the code sequence:

.text:0001093A mov eax, dr1

--> change to XOR EAX,EAX

.text:0001095C and eax, 500h

--> change to AND EAX, 400h


And that's one test less to worry about

greetz sintax

thnx.. will now try what you said, and see waht the tests are.

best regards
pasha

Hi!

You HAVE to tell us what you find!

/Manko

greetz

i am lost , here is what i got from the dumped ~df394b.tmp

.txt2:100099D0 sub_100099D0 proc near
.txt2:100099D0
.txt2:100099D0 arg_0 = dword ptr 8
.txt2:100099D0
.txt2:100099D0 push esi
.txt2:100099D1 push offset unk_10064260
.txt2:100099D6 xor esi, esi
.txt2:100099D8 call sub_10011F1F
.txt2:100099DD push eax
.txt2:100099DE call sub_10011F43
.txt2:100099E3 add esp, 8
.txt2:100099E6 test eax, eax
.txt2:100099E8 jz short loc_10009A06
.txt2:100099EA call eax <== IsDebuggerPresent()
.txt2:100099EC mov esi, eax
.txt2:100099EE test si, si
.txt2:100099F1 jz short loc_10009A06
.txt2:100099F3 call sub_1000127A <== Meltice ???
.txt2:100099F8 mov si, ax
...
...

now this sub is called from

.txt2:10004560 sub_10004560 proc near
.txt2:10004560 push ebx
.txt2:10004561 mov ebx, [esp+arg_4]
.txt2:10004565 xor eax, eax
.txt2:10004567 push esi
.txt2:10004568 mov esi, [esp+4+arg_0]
.txt2:1000456C test ebx, 100h
.txt2:10004572 jbe short loc_10004586
.txt2:10004574 push esi
.txt2:10004575 call sub_100099D0 <== prev sub
.txt2:1000457A add esp, 4
.txt2:1000457D test ax, ax
.txt2:10004580 jnz loc_10004688
.txt2:10004586
.txt2:10004586 loc_10004586:
.txt2:10004586 test bl, 4
.txt2:10004589 jbe short loc_1000459D
.txt2:1000458B push esi
.txt2:1000458C call sub_100098D0
.txt2:10004591 add esp, 4
.txt2:10004594 test ax, ax
.txt2:10004597 jnz loc_10004688
.txt2:1000459D
.txt2:1000459D loc_1000459D:
.txt2:1000459D test bl, 8
.txt2:100045A0 jbe short loc_100045B4
.txt2:100045A2 push esi
.txt2:100045A3 call sub_10009800
.txt2:100045A8 add esp, 4
.txt2:100045AB test ax, ax
.txt2:100045AE jnz loc_10004688
.txt2:100045B4

is this the procedure you are talking about sintax ?? where all the checks are.. well i dont really seem to be getting anywhere do i..hmm....need to dwell on this more..

hehe, another night gone..

best regards
pasha

I gave you this already,

10004560 <- different checks for each call, all should return 0!

10004608 E8 83 4E 00 00 call BCHK
1000461B E8 50 4D 00 00 call UnhandleExceptionFilter_Check
10004654 E8 D7 4A 00 00 call INT_1_Check

start from 10004560 and make sure you get to the bottom
w/o returning 1 for anything,

yates.

greetz yates

holy cow, right you are..man this explains, i am now forgetting all the important details which ppl have told me ..thnx yates, now for more drilling and finding out what the hell is happening with those checks...

thnx again

best regards
pasha

greetz all

w000t...finally..finally..some good news and some bad news as well

good news is that i found out that the check was at the location

1000461B : Call UnhandledExceptionFilterCheck

and was positive all other tests (DR7, DR1, etc etc was negative with all the patches which all u ppl suggested)

the amazing part is i patched the unhandledexceptionfilter from 0xCC to 0x55 using a dll injection scheme. now, i know for sure that igi2.exe does not create any other process and hence the write will be permanent i thought..but NO....the crazy thing is when i checked the detection routine the check for 0xCC was positive even tho i patched..then i knew numega was upto something and keep reinserting their 0xCC in every KeSwapContext i guess....

anyways now i tried splajs approach and patched ntice to rename kernel32!UnhandledExceptionFilter to kernel32!ZnhandledExceptionFilter...the amazing thing now was, all tests passed but the sd2 exe simply exited without any messagebox..

what i thus figured was, this patch to ntice was of no good and maybe it was messing around with ntice functioning and hence the functioning of the SEH chain itself. (btw i could see a hell lot of debugging messages inside of ntice "kernel32!ZnhandledExceptionFilter" thats the line that was printed a lots of times inside ntice console)

now that i know its all with this unhandledexceptionfilter, i am gonna try writing my KMD to hook KESwapContext and remodify the 0xcc to 0x55 everytime. so i wont be interferein with numega i think ...and maybe...maybe..for once god might shine some light into my room and give me salvation...

awaiting any pointers..and thnx a ton once again to all

best regards
pasha

If you have found the cc cmp instruction, then you can pass it using a BPM with a DO statement that sets the test to false.

e.g.

xxx CMP AL, 0xCC


BPM xxx DO "r al 1;x"


Not as nice, but it does the trick.

...or read my thread on the UnHandledExceptionFilter issue... ;P

/Manko

greetz Manko

thnx a ton mate..this was what i needed ....btw u wont belive it..before i saw your thread, i was documenting the exact same in ntice.sys disassembly ...now i will be using ur hard work

thnx once again..and may the lord have mercy upon me and show me some light once i finish this and try again..

thnx again..

best regards
pasha

greetz manko

, i tried this one too, its a clean solution but the sd2 exe simply exits without any messagebox.

this is what i have --

1) all the checks in sd2 return 0 in ax and hence have no problems

2) secdrv.sys functions are properly executed without any problems.

3) i have the following patched and tested succesfully for my NTICE (DS 2.7)--

a) INT1-INT3 offset check via my KMD suggested by sintax
b) INT1 DPL check via my KMD
c) OpenServiceA check
d) CreateFileA/lcreat and other Meltice Variants
e) UnhandledExceptionFilter patch as suggested by Manko
f) DR7 patch as suggested by Yates
g) i dont make use of DR1-DR0 as suggested by Sintax and have faults off
h) INT 3 BCHK patched
j) INT 3 FJGM patched
i) Registry keys patched
j) NMTRANS.DLL patched
k) INT 41 debugger check patched

judging from no messagebox, all i can think of it is that sice checks have been thwarted successfully but there is something else going wrong which is causing the sd2 exe to exit abrubptly.

i really dont know what is happening here..why is the sd2 exe exiting abrubptly like this ?...any ideas ? (wonder what on earth sintax patched to make his working ....hmmm.. )

best regards
pasha

Check the secdrv.sys function calls.

Your int1 / int3 offset change is wrong. Sd2 checks to see if the distance between the entries is LESS THEN OR EQUAL to 1E, not greater. If it's less, is says there's a debugger. At least in the latest Sd2 I am looking at (Raven Shield).

I just simply patched the secdrv.sys file. I don't like messing with ntice.sys , I try to do as little as possible...

The way I did things is this: disasm the secdrv.sys with ida, and show the bytes. Find the routine that uses sidt. Search for the code bytes in memory in SI, they will always be there because the driver loads at boot. Put a bpx there and you can now modify this puppy on the fly to see how it works, when you go to run the game.



Now my raven shield asks for the CD rom, so I can work from here on out, appears debug detection is disabled..(I also already edited the DR7 check in secdrv.sys too)

Hope that helps...

-nt20

greetz nikola

never thought this thread would become active again but here it is

thnx a lot for the reply will try and get back

best regards
pasha

Hi Manko,

How do i patch the registry and rename ntice.sys as you said. ?

I already patched 3 file. I download DAEMON' s sice_detection.

NtQuerySystemInformation trick, Do I have to use bp on NtQuerySystemInformation in debug ?

Thanks Manko

Like I said.. check secdrv.sys function calls (function 3d in this case)