PureBasic Forums - English

If it can be programmed, it can be cracked... eventually no matter how complex. Don't underestimate the crackers out there. I have yet to see an application that has not been cracked in some manner.

Off and on I have been working on a protection routine of my own, but nothing solid. I do it mostly for fun. You can put in a million safeguards but once the pattern is caught and things are traced a cracker can kill it.

yes, crackers can run through and debug the program and find the check system for the registration. however, if you embed the registration check inside a procedure that is critical to the program, i.e if you use a procedure to create the main window, if they "nop" it reg check out, the procedure if coded right should fail and the window wont open. just like when DNA is altered by a framshift mutation or deletion, the coding sequence can be horribly messed up, if the cracker alters anything about critical procedures, the procedure return should be altered as well. THEN, the entire sequence returned would be altered and could not correspond to the correct sequence to complete the reg check. remember, a single change in one codon of DNA can mean the difference between having sickle cell anemia or not. i think if you would play around enough, this could really work. if your procedure would have to run through X number of times for instance, and a cracker "nops" anything out, the value returned will be LESS than expected. if that value was how you defined your codon sequence, no matter what registration info was entered, the program would not recognize it. tandom repeats in DNA sequence are often critical to machinery, and deletion of one or more usually inactivates the gene. just apply these principles to here. Microsoft creates it protection based on NSA, DIA encryption algorithms, mathematically based. REMEMBER, new computer designs are trying to EMULATE the human brain, which is FAR more advanced than any network. microsoft and anyone else and digging deeper into mathematics to aviod cracking, instead of using principles that are billions of years old.

Hi
it seems that explaining complex programming issue for a genetic specialist is same as explaining complex genetics to a proggrammer!;)
what you need to note is that protecting a program ,that must execute on others computer, is not the same as encrypting a message.
you can use your method for encryption and can be sure that depending on your method it will be very very hard to decrypt it. but in programming world things go different way!
in this world a cracker has debugger, tracer,... and so many tools in addition his creativity and so he can follow you step by step to find the way.
you think your method (or any other method) will be crack proof, but there isn't because you will put your checking procedure INTO your program and distibute it by it!
in message encryption you will not put decryption in the message and because of this decryption will be very harder.
every mehod you use for encryption and decryption, every method you use for making a key, finnaly you have to check it yes?
so a cracker can follow your way and find the decryption method (hard way) or just bypass your checking procedure! (easy way)
if any one think that he can make a uncrackable protection method, he is totally wrong!
i offer a method to exam your method, i call it WORST CRACKER METHOD.
think that i amm the worst cracker in the world (by the way it is what i am!;)) then i try to crack your program. your program asks me for a registration code. so i close my eyes and start to press the keys! and after some key i press enter! open the eyes and see that the registeration code was okey! (LOL) sure the chance for this is less than 10^-132894727568754648648 depends on your method, but it is possible! so how you can call it unbeatable?!
i wish i could explain what i mean.
regards
Reza Behnood

@Benhood

I love your cracking method ... Codemonger has a simlar method in the world of possibilities and probabilities. It's called "Codemongers Realm of Possibilities"

There is no such thing as chance, luck, probabilities, percentages, ratios, predictions, statisticians, maybe's, nevers ... everything is split down the middle. Either it happens or it doesn't. Right ? (or Wrong ) I simply remove time from the equation. This is my Binary Method, and until their is a trinary method I stand firm.

> If it can be programmed, it can be cracked

Exactly. Don't forget that there are powerful debugging apps out there,
which makes cracking very easy. One example is SoftICE -- it starts up
before Windows itself starts, so the crackers can launch the exe to be
cracked and then step through it, one asm command at a time (like the
PureBasic debugger). How can you stop that? It's impossible, and that's
why using "genetic" encryption doesn't make any difference at all.

localmotion34, May I lent your brains

> There is no such thing as chance, luck

I've always said that "luck is just a mathematical formula that we simply
have yet to understand".

I think the best way is to not have a key at all. Instead release a scaled down version (demo) that can be patched via download. Then have the user key be unique for each user and have this entered onto a website. The web server could do the authenticating before permitting a download.

The downside is a hacker could copy this download to thier own site and make it available that way. But, if each user key is unique, the download could be encrypted based upon this key. Sure, a user could get the cracked one, but could also be blocked from the support forums if it was known that the key was hacked.

And, would also be blocked from future patches for the same reason.
Again, not crack proof, but very crack resistant.

also, this key could be tracked by the support guys by asking for the key before permitting access to the website or forums...

> Then have the user key be unique for each user and have this entered
> onto a website. The web server could do the authenticating before
> permitting a download.

I would never do this, simply because not everyone has net access.
For example, I will not have net access anymore from December 21,
so let's say I got an app off a magazine CD, and it required Internet
authentication? I wouldn't be able to use it.

There's nothing like a good old customer's full footprint, encrypted in a small data file, with a custom (extremely long) CRC algorithm.
This way, when the user runs his program, he will see his name, address, etc., in a popup window. He will think twice about sharing his file over the net

-kwag

i did not mean to require authentication via internet. I did mean to require it to access a website or to contact customer support via phone or internet.

Yes, customer footprint works too. But I have issues with requiring registration. I don't like releasing information. A key off a CD case OK, my address and phone number not OK.

waffle wrote:A key off a CD case OK, my address and phone number not OK.

That would be fine too, but I ( as the developer ), would put a disclosure that the key has the complete user information ( name, address ), so that even though it's not displayed, the key can be reversed ( by the developer, seller ), and know who it is. The software can decrypt only parts of the key for validation, so in case some cracker eventually figures out how to open the program, the customer's information would use another algorithm that is never embedded in the running software. So you can think of this as a double key, embedded in a single key. Only half is used for validation of the running software.
This way, the buyer is made very clear that if he distributes his key, he can be tracked down.
I've bought several commercial programs that use this principle, and not one of them has keys floating around the net. When keys are generic, or don't have embedded customer information, they are shared around quickly. Just one generic key floating around the net is enough to make a small company fold up, because of dropped sales, caused by piracy.
I'm all for embedded information in keys

-kwag