Best and only non-crackable protection:

CRIPPLEWARE


Lol. I've seen crackers go to the length of adding code to programs, in order to crack them. And we're not talking small amounts, but functions that were removed from the program.

Crippleware is not a bad idea, but many typically use it badly (as in: function is still present in the file, just disabled)

Regards
Fake
Posted on 2002-06-10 05:57:52 by Fake51

And then sombody buys the full version and mass distributes it on Kazaa.

You can't win. :) :(


Well, I do :)
I've written a program wich compiles my application individual for each customer. This program generates a 256bit hash of the licence key, the full name, the full address and the e-mail address and stores it multiple times in the compiled exe (splitted up in several parts).

So I just need to load the exe I found on Kazaa (wich sucks! use edonkey, man! :) ) in my "ReadOut" app, get the checksum (they can't delete it. Even if they try to :) ) and compare it to the checksums stored in my customer database. Then I just send my lawyer the information and my Job is done.
BTW, my "auto-compile" program also move's the procs and declarations in the source code around. So even compiling two times with the same checksum to be inserted produces different files. That's my way to prevent two users from just comparing their registered exe files and override all differences with 00h :)

And please don't say "this is to much work". If I update the program, I just select the database, the source code and press the "Start Batch" button. Then I wait a couple of minutes and get the ready2send zip files.... unique for each customer.

Just a question of organization....


regards,
bAZiK
Posted on 2002-06-10 06:26:36 by bazik



Lol. I've seen crackers go to the length of adding code to programs, in order to crack them. And we're not talking small amounts, but functions that were removed from the program.

Crippleware is not a bad idea, but many typically use it badly (as in: function is still present in the file, just disabled)

Regards
Fake


My main Application is a managing system for bookstores. I sell it for ? 300 per licence (that's $ 283.47 :) ) and sold about 50 licences yet. I really don't think, it's worth reverse engineer this application ;)

And trust me... I am still young (huh!) and also have a "h4x0r" past... is AmoK a name you recognize? :)
Anyway, with the knowledge I gained there, it IS possible to write *uncrackable* Applications.

Hehe, I can tell you one nice trick I use in the program to prevent them from just copying it to another computer: I read out hardware information... including the Barcode reader they use for adding the books to the list... :grin: :grin: :grin:
Posted on 2002-06-10 06:36:25 by bazik
thats what most protectors do... reading informations
out off your computer and stuff, however, everythings
crackable. your little protection scheme isn't as strong
as ... say flexLM and it HAS been cracked succesfully.
sure, checksums and some unique info can't be wrong
but we're talking about mass-compatible distributed
software so you can't make it THAT strong like you do
when coding a reverse-me or something like that...
i never heard about a uncrackable protection scheme
and i don't thing this will change in future.
Posted on 2002-06-10 06:52:45 by mob

i never heard about a uncrackable protection scheme
and i don't thing this will change in future.


uncrackable doesnt exist as far as i'm concerned.

the trick is to make it so difficult to crack its just easier and cheaper to buy my original version :-)

and you can make something darn difficult to crack if you try. on one of my apps it got a bit out of hand, even with the source code I was struggling to get the thing to run after a small modification.....

imagine not having the commented source - aarrrgggghhhh just buy the thing :)
Posted on 2002-06-10 06:59:08 by Terab
There are ways to make a program harder to crack - but one has to realize that cracking can be done in many different ways.

Best protection I've heard of is still IDA's - noone broke it, but it still got around. Funny thing is, it too was watermarked, but people figured out how to remove the marks.

There's different ways to go about the job, one of which is to make sure only a limited amount of people are interested in your software ;)

Point to the story is: if it'll run, it'll crack right open. Just a matter of time. And this is where the programmer should consider how much time she/he wants to spend in protecting the program:
- the time spent on protections could perhaps be spent on further development of the program, adding extra functionality and stuff like that, thus perhaps attracting extra customers
- chances are what you're gonna do (in way of protection) has been done before, and is described somewhere on the net. Thus, you risk using much time on something that won't take long to crack.

I'm not saying that people shouldn't protect their stuff, just saying it'll always be a trade-off. Plus, there is ofcourse the odd chance, that if you come up with something really new, your program will be a hot target ;)


Fake
Posted on 2002-06-10 07:23:04 by Fake51
I agree with Terab, the best thing to do is make two versions of the code:
1) Fully comented for registerd user
2) Another coded in some kind of overbloated interpreter, using "spaguetti" logic, and bad-programming habits (it?s very difficult sometimes ;) though), for the share-ware version... that can be a nightmare to crack :)

And to AmoK, I mean bAZiK, is it some kind of watermarking that you use?
Posted on 2002-06-10 12:01:35 by slop


And to AmoK, I mean bAZiK, is it some kind of watermarking that you use?


LOL!

No, it isn't :)
Posted on 2002-06-10 13:05:53 by bazik
Hi;
Everything is crackable on this world or this cosmos. Maybe not in century or this life :) but just crackable.
If you want to make your softwares protection harder just make your CPU emulation and use your codes. :alright:
A cracker if he/she is not crazy :) doesn't try to write an emulator for your own CPU. And if he/she try and write one this not effect your trade. coz u ll be already earn enough money from this software and u can change your CPU code or architect easily :)
but just know if you write a simple code this is not protect nothing.
This is just my idea, i share it with you. Maybe it helped.

Regards
Posted on 2002-06-10 13:16:03 by RvaZero
bAZiK, may the source be with you too ;)

If it?s not watermarking, what, some kind of CRC?

RvaZero, yes, nice idea.
I was thinking of doing it with Knut?s pseudo-asm?
I'd be fun, and better: don?t have to translate the algos :)

:)
Posted on 2002-06-10 14:16:44 by slop
bitRAKE , will using your code like this do me any good. I am coming off of a .if button press statement. Than want to do your code and jump to a PROC call... If this do help can i NOT use the jmp ToNothing.... It working but i don't know if it really helping the way i am trying to do it..........also what are these values for... 0C201F083h...090900008h......

Thanks

pop eax
pop edx
pop ecx
push esp xchg ,eax
push 0
push DWORD PTR
push DWORD PTR
push ecx
push edx
push eax
mov DWORD PTR ,0C201F083h
mov DWORD PTR ,090900008h
jmp ToNothing

Nothing:

CALL MyProcedure


.endif
Posted on 2002-07-20 23:29:44 by cmax
cmax, those value are x86 instructions. They are put on the stack and the address for them is put on the stack so that ReadFile will return to the stack!
StreamInProc:

pop eax ; old return address
pop edx
pop ecx
push esp ; new return address!!
xchg [esp],eax
push 0
push DWORD PTR [eax+4]
push DWORD PTR [eax]
push ecx
push edx
push eax ; return to stack memory!!
; This is x86 code put on the stack:
; xor eax,1
; ret 8
; nop
; nop
mov DWORD PTR [esp+(4*7)],0C201F083h
mov DWORD PTR [esp+(4*8)],090900008h
jmp ReadFile
This code is to stream in data to a RichEdit control - it is just an example of what is possible when you want to make sections of code hard to trace. Using this code for something else doesn't help you much. You have to use the technique - like a metaphor - aply it to your own code, but not directly. I will do what I can to help you understand.
Posted on 2002-07-21 02:14:59 by bitRAKE
I think a good protection is what I described in two posts, that I report here:

---

If I can give you a quite obvious advice (I do so because other people here, beginners, may read too, and I've seen a problem in this regard many times) the best thing to do would be to make many check routines.. not just one. Cracking 10 of them is harder than cracking 1 of them. What about 1000? You (cr?cker) have to find them anyway, and remove them all. 1000 take some serious time. But one must not use the same code for all 1000, otherwise a simple pattern matching will find and remove all of them in one shot. Here having your own compiler helps a lot, I reckon.
Also, crypting your EXE (with your own crypter, not a standard/known one) and making use of self-modifying code to generate these check routines sure helps..
CRC-32 has been cracked anyway, so one should find a more secure algorithm (what about making your own? unknown algorithms are harder to cr?ck.. ), otherwise storing the checksum in a single DWORD becomes then the weak point..

I can't disclose too many brainfarting ideas here.. but in my experience the above if applied correctly is enough for most situations. The hardest part is about EXE crypting and having your own protection_code generator (compiler) to avoid to write by hand 1000 original, sufficiently_different check routines.

Also, be careful about the extreme weakness of standard solutions like CRC-32.

---

There's an inherent problem, though, which will be difficult to solve with standard tools.

Even if you don't use a known CRC algo, the cracker can reverse engineer one single of your 1000 check routines, and thus deduce from the algorithm an "acceptable" checksum value and store it in the PE.. fooling the other 999 checkpoints.
So what will really work is to store the checksums 1000 times, i.e. in each of the check routines, as (obfuscated) immediate values. Then it will be *really* necessary (for any cr?cker) to cr?ck them all, one by one (assuming you don't make all of them identical, making them prone to a easy pattern matching attack).

It's clear that you'll have to insert these 1000 immediate values (making sure they aren't all the same, otherwise finding them will be very easy.. you can add to them their current address, for example, or use a more sophisticated method) after you've assembled your program, and this thing is not trivial, at least with the usual tools.

One thing you could make is to disseminate in your asm source code one-line statements like "PROTECT", possibly not in your hyperoptimized gfx innerloops. :D
Then write an utility that gets in input your source file + PROTECT statements, and "compiles" them.. giving in output a pure asm sourcecode (a compiler, ain't it ).
Then you assemble it, and produce a PE. The assembler outputs on a separate file the list of memory locations corresponding to the immediate value used by each protection statement. A final utility calculates the "CRC" and patches all of these immediate values I just mentioned.

Here the advantage of having your own assembler/compiler is clear: you can extend it with functionality like the above, i.e. output the precise memory location that will need to be patched.. and state which kind of patching will it need (i.e. how to crypt that value).

It's true that standard assemblers are uncapable of such flexibility, but short of writing your own assembler/compiler, you could modify FASM sourcecode, for example, to extend any special functionality you require.

This is just one example of what I meant every time I stressed that having your own development tools is extremely useful and important, let away productive.
Posted on 2002-07-21 02:52:49 by Maverick
Thanks alot bitRAKE and Maverick i guest i got to get more serious now. I might as well face it, learn this will take some time. One question about FASM.... Do it support Un-Initized Data... all i see is an .data section and in my project i do not want to use a .data section...I don't have one at all right now and i would like to have that with FASM if i was to start learning FASM or another assembler.

Posted on 2002-07-22 01:56:24 by cmax

One question about FASM.... Do it support Un-Initized Data...


Yes. :)
Posted on 2002-07-22 02:17:13 by bazik
a - OK

Cash me in
Posted on 2002-07-22 02:32:24 by cmax
not *everything* is crackable,

consider the encryption scheme, "one time pad" (http://searchsecurity.techtarget.com/gDefinition/0,294236,sid14_gci213673,00.html). it is *uncrackable*.

it could be used to encrypt the data on a per-client basis, such that
they can only decrypt "full-version" areas with their "license key".

if we assume that the client will not be aware of our random number generation
techniques, it is *impossible* for him to crack the code.
Posted on 2003-08-14 22:15:58 by abc123
Not sure i shoul'd post this since i have a litle experience

Long time ago I've coded some protection for old 8bit box.
It wasn't easy, but it stops *every* debugger and some hardware crackers
Because it has full access to hardware and all the memory was used

On current multitasking OS (windos) i have no good ideas of protecting ring3 code w/o using KMD.

As RvaZero said, "just make your CPU emulation and use your codes. "
Just let it be executed only with your KMD (no need for exe be really PE?)

But even such protection can fail, it just can give some problems for debugging/tracking for them
who don't now much about ring0 programing (like me :grin: )
(what about XP protection?)

And some protection mechanism (like encripting all the .exe) will slow down program since
NT maps files to memory instead of load them.

P.S. my protection nowadays is easely crackeable with current PC and emulator of that old box :o
Posted on 2003-08-15 00:15:36 by S.T.A.S.
It's interesting how a thread can resurrect a year after it dies.
Posted on 2003-08-15 00:31:24 by iblis

It's interesting how a thread can resurrect a year after it dies.

initial question will live forever :alright:
Posted on 2003-08-15 00:45:18 by S.T.A.S.