Seems there's a bit of confusuion here concerning the ADT of CopyLok.
Actually there're 3 little tricks:

1. Meltice (createfile SICE)
2. check dr7 (debugger check)
3. clear all drx regs (to disable possible BPs)

Meltice is only executed once.

While dr7 check and drx cleaning happens quite often (i.e. in between the decryption process.)

They gain ring0 to read/write drx regs by using div 0 exception handler pretty much like old SD1 did.
Needless to mention that all are useless in W2k or in W9x with icedump protection.

yes but some protections (asprotect) uses some seh_handlers that already clears the debug registers, just by calling some interrupts and I can swear you that it really works on nt, look at my essay concerning asprotect.

the best thing I know is to use icedump, enable the /protect command
that forbids any access to the idt table, concerning the debug registers there is TMHO not a lot of things to do instead tracing || searching for those instructions or watch sice go mad when you step above a call that contains such treatments.

erm, the clearing drx in ring0 doesnt wipe breakpoints ..

you can bpm copylok exe's ..

the dr7 check, isnt a check, it uses dr7 & 3ffh to morph decrypt keys (0 if no breakpoints set)

'Needless to mention that all are useless in W2k or in W9x with icedump protection.'

icedump wont help at all . /protect on catches read / write to idt for his illegal ring0, but since its called 3,000,000 times, you would have to /protect on /protect off 3,000,000 times to bypass it, and u cannot patch the code due to 'crc's also used to morph decrypt keys

where was the confusion?

bpr is my best friend

and tsehp,

you already know seh is pathetic for wiping debug breakpoints ! :-) there is only one way to debug aspr, and thats bpm's :d

>erm, the clearing drx in ring0 doesnt wipe breakpoints ..

So? What does it do? Huh? Go have a look at the fucking Debug support facillities of x86 IA32 cpus. And then tell me what clearing drx regs really does. Go ahead.

>you can bpm copylok exe's ..

Maybe ya should look at SICE's implementation of BPM which seem NOT to use dr0 - dr3 in all cases. (i.e you can't bpm on ranges > 4 byte with hardware bpm, well, using 4 bpms will make 16 bytes...)

>the dr7 check, isnt a check, it uses dr7 & 3ffh to morph decrypt >keys (0 if no breakpoints set)

Ok, maybe not too precise what i said before but actually the dr7 check changes behaviour of app when BPs are set, so i guess basically it's a debugger check, isn't it?

>'Needless to mention that all are useless in W2k or in W9x with >icedump protection.'

>icedump wont help at all . /protect on catches read / write to idt >for his illegal ring0, but since its called 3,000,000 times, you would >have to /protect on /protect off 3,000,000 times to bypass it, and >u cannot patch the code due to 'crc's also used to morph decrypt >keys

Ok, i agree on that.

BR.

>erm, the clearing drx in ring0 doesnt wipe breakpoints ..

-So? What does it do? Huh? Go have a look at the fucking Debug support facillities of x86 IA32 cpus. And then tell me what clearing drx regs really does. Go ahead.

ooh , your angry!

well, it clears them, basically, but doesnt stop softice's breakpoints for some reason ..

>you can bpm copylok exe's ..

-Maybe ya should look at SICE's implementation of BPM which seem NOT to use dr0 - dr3 in all cases. (i.e you can't bpm on ranges > 4 byte with hardware bpm, well, using 4 bpms will make 16 bytes...)

ok, so bpm loadlibrarya x and bpm sendaspi32command x break every time they are executed in copylok exe's, even though debug breakpoints have been cleared, well, it must be magic hey? unless setting dr0..3 to 0 in ring0 DOESNT wipe debug breakpoints .. (well, vwin32 manages to do a good job, but, everything else apears to fail)

take a look at new laserlock, he wipes dr0..3 a lot more times than copylok does, and still, debugbreakpoints work ..

>the dr7 check, isnt a check, it uses dr7 & 3ffh to morph decrypt >keys (0 if no breakpoints set)

-Ok, maybe not too precise what i said before but actually the dr7 check changes behaviour of app when BPs are set, so i guess basically it's a debugger check, isn't it?

erm, its anti-debugging (like u said in the topic to your post), not a debugger check..

like hooking int 1 or int 3, or crc'ing the code section of kernel32/user32 a couple of times, or crc'ing your own code, just anti debugging ..


hmmmm

>ok, so bpm loadlibrarya x and bpm sendaspi32command x break every time they are executed in copylok exe's, even though debug breakpoints have been cleared, well, it must be magic hey? unless setting dr0..3 to 0 in ring0 DOESNT wipe debug breakpoints .. (well, vwin32 manages to do a good job, but, everything else apears to fail)

hi r!sc, you remember the sd2 injector you sent me that I finally managed to reverse, remember this code :IFSMgr_Ring0_FileIO
0028:C01392D4 55 PUSH EBP
0028:C01392D5 57 PUSH EDI
0028:C01392D6 56 PUSH ESI
0028:C01392D7 83EC30 SUB ESP,30
0028:C01392DA 8BFC MOV EDI,ESP
0028:C01392DC 51 PUSH ECX
0028:C01392DD 50 PUSH EAX
0028:C01392DE B90C000000 MOV ECX,0000000C
0028:C01392E3 33C0 XOR EAX,EAX

following this code, the drx are voided, so it was rendering your injector cloaked against bpmb, but when you patch the vwin32 code ti jump above the drx voids, the bpmb works again.

so, I still don't why in some cases voiding the drx does nothing and in such vwin case, it really does. You were talking about some thread contexts, sure that if some drx are voided into another, sice will still be able to bpmb into the context where they are intact...vast problem, sorry the answer is not in mine.