PureBasic Forums - English

What think of this protection?

a1$="789-HJ4-"
a2$="UP10251"
a3$="-CP985"

a$=a1$+a2$+a3$ ; the code of sofware

bon$ = MD5Fingerprint(a$,2)
Debug bon$

;SetClipboardText(bon$)

b$ = InputRequester("","", "")
code$=MD5Fingerprint(b$,2)

Debug code$



If code$=bon$ ; comparaison
Debug "Yes"
Else
Debug "No"
EndIf

If code$=bon$ ; comparaison<<< HERE
Debug "Yes"
Else
Debug "No"
EndIf

My suggestion:

Change at least one time a week the downloable executable with different key each time, if some one hack you app and he distribute his key it won't be usefull for new downloaders.

Try out ExeStealth (http://www.webtoolmaster.com) it can help

ADN wrote:What think of this protection?

what protection?
ok, no, sorry...

the problem is that whatever encryption you use inside your program,
there's still a comparison somewhere (good key / bad key).
this results in any of the following opcodes:

je (jump if equal i.e. "=" / 74h)
jne (jump if not equal i.e. "<>" / 75h)
.
.
.
greater than
.
.
etc.

this is (of course) still inside the disassembled listing, so people could
simply invert the jumps or do a ret instead or simply nop the code out or...

ah, and before i forget: the original key is still in the code too of course.
well, you defined a string with it...

i also wouldn't recommend tools like "ExeStealth". Whereas this tool on
its own might be a good program to protect your software, I'm pretty
sure there's already a 'general-crack' around, reversing all the protection
thus making it kind of useless.

That why changing you key often (and trying to difficult the reverse engineering) its the best way to avoid cracks in a practical way.

I mean, one thing is theory and another one is the practice. In the practice (with only mi own experience) combining both protection is the best way. Most the idea to change your register algorithm weekly (not always on the same day of the week).

Then any keygen will be outdated in a few days and unless your software are at the top of the list of the cracker targets, no cracker will repeat his job weekly trying to develope one more keygen that will only be usefull 2 or 3 days (if the cracked is speed enough).

A very nice (but very expensive) option could be Thinstall ($799 US!!).
http://thinstall.com/

I don't buy it because the price, but its a very very interesant thing.

No protection ever helps.

My program was cracked, and I had a very small program 25KB,
thanks to PB.

But they included my program , inc. crack on crack sites because it was so small.

You see, not all benefits of making small programs

another method would be to use encrypted images and imported text files. People could still hack the program itself, but it would be very hard to decrypt all the other files that are displayed within the main app. This would defeate the purpose of the compare line, you just show the file in whichever state its in.... decrypted or not. A hacked program would look very ugly with scrambled images on the buttons with scranbled images as a "form" background. And, i doubt if the sound effect would play right. Also, what use would an encrypted help file be?

> [...] use encrypted images and imported text files.

How is your app supposed to display them correctly then? It has to decrypt
them at some stage...

My 2 cents on criptography:

Well has PB programs are so small, the best way would be to have a key file and a dat file, both with the same size.

This way the cracker would not know what is the key and what is the exe.

Finally a 3rd program (i.e. installer) would merge key & dat into a correct executable,
using i.e. :dat xor key file xor password.

Has there is no checking a=b no one can ever tell if a password will work or not!

example:

Create Files:
myexe -> scramble with password -> 1 key file + 1 dat file both same size...

Merge Files:

Key file -->mergeDat File -->merge Password ---- > Create Something (Exe if password is correct)



Just make sure 2 key files or dats will be ever alike
And use the password has a salt element...

No one can crack this method in human reasonable time, has it is one way going....

Num3 wrote:No one can crack this method in human reasonable time,

They don't need to, just install your software, zip it up and put it onto a website.

PB posted an interesting link the last time this topic was discussed:

http://inner-smile.com/nocrack.phtml

tinman wrote:[They don't need to, just install your software, zip it up and put it onto a website.

8O Eheheheheh
Lol.... of course you can always write in registry... create a dummy file somewhere... anything countes...

> > No one can crack this method in human reasonable time
>
> They don't need to, just install your software, zip it up and
> put it onto a website.

Exactly. Many people seem to forget this. Maybe they've never seen a
full-app site? And also distributed via peer-to-peer methods.

You can try and protect your little PureBasic apps as much as possible,
but the fact is that your techniques will NEVER be as advanced as say
Microsoft/Adobe/etc, yet all their apps (Windows XP, Photoshop, etc)
are cracked within days of their release. Anyone who thinks their app
won't be cracked is in denial. And that's the very sad truth.

You probably shouldn't mention names of places to get, umm illegal copies of things, on this forum, I don't think people would like it much.

but your absolutely correct, if you think you won't be cracked your in denial.

> You probably shouldn't mention names of places to get, umm illegal
> copies of things, on this forum, I don't think people would like it much.

I have amended my post.

Very abmerable of you thanks

I guess Num3 has the best idea here. Write into the registry, create dummy
files etc. Make it sufficiently complex that it is not worth anyone's time
ripping all this stuff out.

Then again, crackers are likely to be sad individuals with a lot of time on their hands.

Perhaps a better plan is to create software that needs continual update,
for example like PureBasic, or maybe needs continual access to a database
that is kept up to date. In addition, change the download frequently
so that you know who owns each copy. It is then not in the crackers
interest to post a working program because it will contain evidence of
his identity and allow you to bar updates for his software and for the
version he has posted.

The part of the code which contains its identity can be subtle. It could be
a few bits in a bitmap or some extra values in a data file. Since the program
doesn't check this information, it will be impossible for the cracker to
know that it exists.