Hi,
I recently got interested in software protection and I have one question
we know that when cra*ker wants to deprotect program it uses debugger such is softice, it sets breakpoints
and steps through the code instruction by instruction. Now is it somehow possible
to measure time between two instructions, and if that time is bigger than say 0.01 second then
we know that someone is debugging program and do somthing appropriate (err.. like crash system :grin: )
What are your thoughts about this
Posted on 2003-05-22 19:27:17 by Mikky
measuring the time needed to execute a piece of code is a bad idea, especially in multi-tasking environments, or when running your program on different processors ;)
you could try to use the RDTSC opcode, though. this method could also cause some false alarms if not implemented properly.
Posted on 2003-05-22 19:40:49 by Tola
In my opinion, a half-decent hacker will spot rapidly the presence of a timer and circumvent the whole thing by running the timed code at normal speed and then continue his hacking.

Good hackers can probably break any software protection you could ever think of.

Raymond
Posted on 2003-05-22 22:15:26 by Raymond
If you were to do something inappropriate like a deliberate system crash would you be prepared as well to pay out the lawsuits for lost data? Ofcourse in a multitasking environment yours is not the only software running and there will be data lost. If you deliberately initiated a sequence that would guarantee that data would be lost you are liable for that lost data and the cost to replace or recover it.
Posted on 2003-05-22 22:26:17 by donkey
Donkey, who cares about lost data? If someone is trying to crack the program it is already illegal and how do you supose someone to report the lost data, since he already committed crime and will suffer also....
The guy is just trying to find some way to protect his software, however I agree that the system crash would be inapropriate and evil solution.
Posted on 2003-05-22 22:43:05 by masnick[CCCP]
A better way is to put your program in a mode where it half-works when the protection is removed, so that some features work, but for the really important stuff gives some error that implies that the installation process was not done properly, like put some kind of 'Cannot find foobar.dll' message.

Like if it's a game, let him go halfway through a multi-player game or campaign, then suddenly abort with a 'Cannot find foobar.dll' message, that'll suck real bad for him...

That way, the hacker thinks he has finished cracking, then starts going around in circles looking for foobar.dll somewhere in the installation disk.
Posted on 2003-05-22 22:53:15 by AmkG
Your idea is just another little gimick that a cracker will easily find a way around.
Posted on 2003-05-22 22:56:34 by comrade
Yes, IF he knows that that form of protection is there. Keep it carefully, then it will spring in the middle of the campaign, most likely he will have sold copies of the thing already to pirates. Then when the end-users use it, they won't be able to get further than that and hopefully won't buy anything from the same pirate/hacker again.

Okay maybe it won't work as well for business software.

And yeah it's been done before, so maybe it won't work anymore.
Posted on 2003-05-22 23:03:18 by AmkG
develop your own exe protection. it would have to be in memory, not just on disk/file. and vxd, some thing system ring 0 to perhaps decode the instruction. it would have to be timed precice. an absolute PAIN to a cracker.
Posted on 2003-05-22 23:14:51 by Qages
"]
Donkey, who cares about lost data? If someone is trying to crack the program it is already illegal and how do you supose someone to report the lost data, since he already committed crime and will suffer also....
The guy is just trying to find some way to protect his software, however I agree that the system crash would be inapropriate and evil solution.

In alot of countries it is perfectly legal to dissasemble software. This route has been gone down before by other companies only to led to lawsuits. I am all in favour of software protection and anything to screw the pirates but I was just pointing out that there are reprecussions to crashing the machine. The law in most western countries would still hold him liable even if the crash was the result of tampering, after all it was the coder not the hacker who caused the crash.
Posted on 2003-05-22 23:49:35 by donkey
Try detecting SoftIce and make it crash by (all esp or call ebp or jmp 0, basically just screwing the eip. Maybe you even want to change the eip to your data section.
And do not call the api direct try getting edi be the base and you add the offset to get different api(I have seen code like that). All these add up to wading code in the dark.
And try avoiding cmp then jxx cause they can be easily patched. Instead try call eax (whereby you somehow make eax where you want to jump to). I have many ideas of protection scheme but seriously they just make the code more complicated and software still liable to being c**cked. You can try encryption too. It would be fun for the c**cker to jump to the correct place but find himself wading through encrypted code. :)
Posted on 2003-05-23 01:51:10 by roticv
You'll give the cracker a lot of 'fun' with encrypted run-time conditionally compiled code. That's many words, but basically you compile or assemble some code at run-time, then execute it. If the cracker spots the code it has to modify, he still has to figure out how it was generated. It's like having Java bytecodes without knowing the encoding rules.

Of course they're not dumb and they'll try to work around it. Instead of letting the code be generated, they'll just replace that directly with the code. Your way to detect this is check-summing. Place dozens of checks all around your code. And to make it even more 'fun', have a few run-time generated check-sums. :grin: And to make it all complete add some encryption to the code you're compiling...

This is going to stop most crackers, but we're not done yet. If they remove all the check-sums, they can again start replacing run-time generated code with static code. What you can do to make this harder is to generate different code for every situation. That's the "conditional" part. For example, if you're writing code to create different styles of window, don't check the style flags in the generated code, but in the generator. So for every style of window you have it's own run-time generated function. Now they have to figure out how to add these conditions to the generated code. It's a lot harder than placing a few cmp/jmp's. Now do this in a few places and they'll quickly get discouraged.

The possibilities are endless. Probably very interesting would be a run-time generated function that generates run-time generated code that generates run-time generated code that...
Posted on 2003-05-23 03:10:33 by C0D1F1ED
On the subject:

Why you all think timeout periods are by all means bad? If I set timeout period 100ms for code piece normally running for 100us (micro seconds), there is big probability that if timeout period elapses - there is something wrong with the program. and if I put some diferent checks again with timeout period, all will be OK. And to make things complex - we may use not system timers but TSC counter of the processor. AFAIK it's not forbidden in Windows.
Posted on 2003-05-23 03:33:34 by JohnFound
instead of loosing time making a protection it is much wiser to spend time on implementing new features and/or optimizing the code.

you must not forget their motto: "if it works, we cand break it". all protections, IMHO, are useless for a good cracker that wants to remove the protection.

remember the dongle protection, it was supposed to make the life harder or "be unhackable". it can be removed in no time :)

better make your program smaller/faster than spend time in a useless protection.

my 0.02?
Posted on 2003-05-23 04:08:45 by TBD
The protection is simple: code an app that people want to buy.

Why you all think timeout periods are by all means bad? If I set timeout period 100ms for code piece normally running for 100us (micro seconds), there is big probability that if timeout period elapses - there is something wrong with the program.
<yawn> Sounds good in theory, let's see you make it work for real. I will run your app, then i will start my AV software on deep scan, or i will start a compile of my .Net app, or i will start some other processor intensive activity, that will cause your timing check to fail every time. Did you forget that you were operating under a pre-emptive multi-tasking OS?? </yawn>
Posted on 2003-05-23 05:58:57 by sluggy
sluggy: your point is good, but I am not sure that starting few high-load programs will slow down say 20 instructions for about 100 times than I set.
Also when I said system crash, I dont really meant to implement that.

I think that developers have advantage in race with crackers. Crackers need to figure out what was going on in our head if they want to break our protection. Weirder thoughts we have - harder job for them :)

Main problem is to know where to protect. For example in a lot of "protect your software tutorials" I saw that they are suggesting API IsDebuggerPresnet


invoke IsDebuggerPresnet
cmp eax,0
jne debuger_present ; <--------- instruction to attack
jmp continue

debuger_present:
; process is debugged.... do somthing bad but not that bad as crashing system :)

continue:
; program codee



this is nice but there is no point in using it since cracker can always find cmp/test instructions and patch jmps after them.. Instead of IsDebuggerPresent can be the best uncrackable protection procedure in the world but it will fail since we are not protecting the right place in code - conditions
Posted on 2003-05-23 07:37:00 by Mikky
this is nice but there is no point in using it since cracker can always find cmp/test instructions and patch jmps after them.. Instead of IsDebuggerPresent can be the best uncrackable protection procedure in the world but it will fail since we are not protecting the right place in code - conditions

Like I say, hide calls to the api. Do something like


call @F
@@:
pop ebx ;ebx store theoffset
..
call [ebx+offset]; call Isdebuggerpresent
or eax,eax
cmovnz eax,ecx ; ecx = Isdebuggerpresent?
...
sub eax,ecx
jz @F
popad
popad
popad
ret ; crash code
@@:
...

For this I think they need a debugger and not a disassembler to find the api.

Try dumping anti-debug codes into some common routine. Encrypt the .code section. Decrypt it only if no presence of debugger. Anyway I still think the above code is weak. I will give it a thought and come back to you as soon as possible.
Posted on 2003-05-23 08:20:18 by roticv

Yes, IF he knows that that form of protection is there. Keep it carefully, then it will spring in the middle of the campaign, most likely he will have sold copies of the thing already to pirates. Then when the end-users use it, they won't be able to get further than that and hopefully won't buy anything from the same pirate/hacker again.

Okay maybe it won't work as well for business software.

And yeah it's been done before, so maybe it won't work anymore.

You really have little clue about cracking-scene I see... People don't crack software to sell it dofus, they do it for the challenge and race with other groups. The instant someone encounters a secondary check in a crack you can bet your ass that a fix is out the same day.
Posted on 2003-05-23 08:55:20 by SFP


Like I say, hide calls to the api. Do something like


call @F
@@:
pop ebx ;ebx store theoffset
..
call [ebx+offset]; call Isdebuggerpresent
or eax,eax
cmovnz eax,ecx ; ecx = Isdebuggerpresent?
...
sub eax,ecx
jz @F
popad
popad
popad
ret ; crash code
@@:
...

For this I think they need a debugger and not a disassembler to find the api.

Try dumping anti-debug codes into some common routine. Encrypt the .code section. Decrypt it only if no presence of debugger. Anyway I still think the above code is weak. I will give it a thought and come back to you as soon as possible.

Resolved by simple apihooking....?

Whatever API you hook you can use an MS intrinsic called _ReturnAddress() which if you place it in ie lets say a hooked API call will give you the address where it returns AFTER the call to your hook so you will know exactly from where it was called and how and with what info.
Posted on 2003-05-23 08:59:01 by SFP
Well you could always try


call delta
delta:
pop ebx
...
call finddebugger


finddebugger:
add ebx,offset;offset to Isdebuggerpresent
lea edi,callfunction
mov al,0ffh
stosb
mov al,0d3h
stosb
mov al,0C3h
stosb
callfunction:
nop
nop
nop
popad
popad
popad
ret
Posted on 2003-05-27 06:51:11 by roticv