rcg_vxd2.htm HOW TO PROTECT SOFTWARE BETTER

+HCU's special Project: 'Our protections'

HOW TO PROTECT SOFTWARE BETTER - Part II

by +RCG

(slightly edited by fravia+, 18 January 1998)

Courtesy of fravia's page of reverse engineering

The following essay by our +colleague and "Uberprotector" +RCG is VERY interesting for many aspects, it deals for instance with the "delayed" protection scheme, that we have already discussed in the "programmer corner" section, a "delayed" revenge which is already implemented in some very recent protection schemes, but I'm sure that the whole part about "How to take Softice on a boat ride" will indeed prove to be a very interesting reversing reading for all our protectors and crackers friends.
In fact the idea of COUPLING softice detection and self-patching promises to deliver us very ineteresting challenges in the future :-)


HOW TO PROTECT BETTER ~ Part II

Purpose of the "Our protection" section
The "delayed" protection scheme of the future
The Port 70/71 trick
How to take Softice on a boat ride
Softice breakpoint magic explained and defeated

by +RCG

18 January 1998

Hi all!!!! I see that my "heavy" protection has 
been severely criticised... I know that an 
encrpytion xoring values is pretty stupid... but 
in my opinion the idea behind this section
is to introduce and implement new ideas, and not 
really to create a whole uncrackable program, which 
as we all know is impossible anyway. 
I believe that we will very soon be confronted 
with much tougher protection schemes, because 
the programmers and the protectionists ARE learning 
assembly, notwithstanding the widespread belief 
of the countrary.

I have been thinking about all this and I have 
concluded that the best solution is to use the 
VxD to perform only critical actions.

That is, let the program, usually written in an 
"higher" language create the more or less complex
encription algorithms that you need in order to 
protect and THEN use the VxD to move the decripted 
function to its place. Do you agree with me that 
this would be a much better solution?

Yes, my previous protections have been quickly 
defeated, yet you must think that these programs 
of mine are only "probes": they are very very
short programs, and their protection schemes are 
not hidden at all, quite the contrary actually: they 
are in front of you.
Actually you should only examine the idea that
I have implemented and find solutions or problems for
the scheme. 

I'm sure that the perfect protection doesn't exist, 
it's like the final weapon... a very clever protection 
to-day will be very easy to defeat to-morrow. But we 
can do nevertheless our best: we can for instance use 
two or three protection schemes at the same time, for 
example, 1) encryption with 2) antiSoftice tricks, and 
3) some other things we have already seen on this page. 

Imagine all these schemes bundled together with a little 
intelligence into an ovebloated multimega huge program! 
That will cause an headache to most crackers, even if it 
will be -maybe- easily solved, by real "zen" +crackers.

Indeed, most of today "key" protection schemes are 
very easy to crack because the programmer thinks
that a simple check is more that enough, which is 
stupid to say the least.

Think for example that mostly we only have to patch
a conditional jne with a 'compelled' jmp, and the 
program thinks that it is registered. 

Moment: thinks that it is registered... or let us think
that he thinks that it is registered? :-)

Yes! Now suppose you are using your "cracked" program 
and suddenly it crashes, or does not let you make 
something... say a couple of days AFTER your supposedly 
easy crack...

It's very difficult follow this kind of "delayed" protection 
tracing or dead listing your target. Where, inside the 
whole program is this kind of protection implemented? 

Think: imagine that somewhere in the middle of the normal 
execution code the target performs a check. You don't perceive 
it at all, because there is NO NEED to alert the user about 
this verifying. And then, imagine, the target patches some 
code on the fly or checks for code modifications... man, I 
understand now what +ORC always teached us with his "be 
careful not to nop with nops" doctrine... he foresaw the 
development of our protections TWO YEARS ago... but the 
protectionists probably never read his tutorial and I have 
until now still to see a target checking for our nops 
instead of having a simple CRC-type check :-(

But you get the idea, don't you? You will never understand 
what happened because that code, patched by the target can 
be itself encrypted.

I don't agree with colleagues that say that this
protection way is just like all the others. This kind of 
tricks, if implemented, would let us make much more other 
things, and at the very least would for sure prevent the 
"30 seconds" cracking.


OUR VXD. LETS BEGIN AGAIN

Basical Functions.

1. Blitter (block memory transfer)
2. Port IO
3. SoftIce remover
4. Device_Service_Hooker
5. Int_Hooker
6. Api_Hooker
7. GP_hooker (General Protection Exception)
and more...

Comments about the implementation of these functions.


1. Blitter (block memory transfer).

Not much to speak about. Very easy to program.

2. Port IO

Yes, no more GetLocalTime function, now we can 
use Ports 70h and 71h. Cinderella-type protections
will be not stupid and easy to defeat as they are now.
SoftIce bpio has no effect wjatsoever if we read 
directly the port.

3. SoftIce remover

I will show you a little trick to remove SoftIce
from memory or to let it 'out of the game' during the
execution of our program.

How does Ice pops up?
Either by a breakpoint or by Ctrl+D. (This is top secret info :-)

If you dead list  winice.exe, searching for the string 
"breakpoint" you will find the string 'No more breakpoint 
available'. 
Let's have a look at the surrounding code:

:2E258   push ebx
:2E259   push ecx
:2E25A   mov ecx, 000000FF	;256 breakps. max.
:2E25F   mov eax, 00000000
:2E264   cmp byte ptr [eax+4], 00
:2E26B   je 0002E277
:2E26D   add eax, 00000183	;Every bp block is 183h bytes.
:2E272   loop 0002E264	;try next
:2E274   stc		;Ret Error
:2E275   jmp 0002E29F	;'No more breakps. aval.'
:2E277   lea ebx, dword ptr [eax+0] 	;ebx = 1st byte of block			  		
:2E27D   call 0002E237	<== Is block corrupted?
:2E282   jb 0002E29F	<== Error return
:2E284   push eax	<== Next breakp. free pointer
:2E285   push edi	
:2E286   mov ecx, 00000183 <== Clear 183h bytes area
:2E28B   sub ecx, 00000004 <== But no the 'TDJF'
:2E28E   sub ecx, 00000004 <== But no the 'TDJF'
:2E291   lea edi, dword ptr [ebx+04]
:2E294   xor al, al
:2E296   repz
:2E297   stosb
:2E298   pop edi
:2E299   pop eax
:2E29A   mov [ebx+05], 01
:2E29E   clc	<== Ret Success
:2E29F   pop ecx
:2E2A0   pop ebx
:2E2A1   ret

Most rewarding and interesting!
Every breakpoint block has a "structure" in
order to check the conditions or the kind
of breakpoint.

Every block is a 183h byte structure like this:

0123456789ABCDEF
TDJF????????????
.
.
.??????????????T
DJF

The 4th byte is the breakpoint type:
0=>Free	(this is the trick)
1=>bpint
2=>bpio
3=>bpm
4=>bpr
5=>bpx
6=>bmsg

That's enough, as you'll see, to nuke the breakpoints,
and now, lets snap (and shut) the Ctrl+D entrance too

SoftIce sets its default Ctrl+D hotkey using
the keyboard service Define_Hot_Key

	mov     al, ScanCode
	mov     ah, type
	mov     ebx, ShiftState
	mov     cl, flag
	mov     esi, OFFSET32 HotKeyProc
	mov     edx, OFFSET32 refdata
	mov     edi, max_delay
	VxDcall VKD_Define_Hot_Key
	jc      errorhandler

BTW, if you try to define the same hotkey you will see 
that it has no effect (because softice prevents it).

And the HotKeyProc is:

                        
3392  mov     ds:byte_66CD, 0	;Active flag
3399  mov     esi, offset loc_66CF+1	;Offset of scancodes
339E  mov     eax, 400h
33A3  cmp     ds:byte_66CE, 1Dh		;keyboard type
33AA  jz      short loc_33B6	
33AC  mov     esi, offset loc_66D1+1	;Offset of scancodes
33B1  mov     eax, 800h
33B6  test    eax, ecx
33B8  mov     ecx, 1		;1 scancode
33BD  jz      short loc_33C3
33BF  inc     ecx		;2 scancodes
33C0  dec     esi
33C1  jmp     short $+2
33C3  VxDcall VKD_Force_Keys


VxDcall VKD_Force_Key
	mov     esi, OFFSET32 ScanCodes
	mov     ecx, num_ScanCodes
	VxDcall VKD_Force_Keys
	jc      errorhandler

If you write on the memory any value over "1D" and if you 
also remove all the breakpoints by putting zero on the
4th block byte (=free breakpoint), SoftIce will not pop up 
(unless a GPF happens).

1D identifies the keyboard type, and the scancodes needed
to pop up, you also can modify the code in order to force 
other scancodes that will left the stupid cracker without 
its Ctrl+D (most stupid crackers wont even understand why
softice doesn't snap any more.


Notice that if your program detects
1) the presence of a softice session
and
2) some modifications of its own code
you can be 99% sure that you are running inside 
a cracker's machine :-)

This may give some 'revenge' idea to the clever 
protectionists :-) 

4. Device_Service_Hooker

You can find the complete Service ID on the VxDMon
file. When programming at Hook_Service the following 
is pretty important:


;Data area

Real_Proc	dd 0

;Code Area

Public VXD_Device_Exit
BeginProc VXD_Device_Exit
        mov     eax,Service
        mov     esi,offset32 OurServiceFunct
        VMMcall Unhook_Device_Service
	clc
	ret
EndProc VXD_Device_Exit


BeginProc OurServiceFunct, Hook_Proc Real_Proc <== Don't forget that 
						this is necesary to
						remove the hook on
						exit.
	Do something
        jmp     dword ptr [Real_Proc]
EndProc OurServiceFunct


VXD_LOCKED_CODE_ENDS


VXD_ICODE_SEG
BeginProc VXD_Device_Init
        mov     eax,Service
        mov     esi,offset32 OurServiceFunct
        VMMcall Hook_Device_Service
        jc      not_installed
        mov     [Real_Proc],esi
        clc
	ret
not_installed:
        stc
        ret
EndProc VXD_Device_Init

5. Int_Hooker
6. Api_Hooker

For points 5 and 6, please see my other examples 

7. GP_hooker (General Protection Exception)

Another +Hcuker is working on it (Good Luck _m)

rcg__@latinmail.com

+rcg

You are deep inside fravia's searchlores org, choose your way out:

Our protections

Our own tools

Programmer's corner

links

+ORC

tools

mail_fravia

Is reverse engineering legal?