Hi, TitaniumT, if you can, register a good professional protector and use that instead of relying on doing it yourself.
If there's one thing the cracker's warns against, it's homemade protection. You may be able to fight off stupid newbie
script kids, but nothing else.
EXE compliled by PureBASIC and its Security
All strings or keys whatever will be reveiled when used!blueznl wrote:....
- now if a hacker runs your code, he will have to do a few additional checks, to figure out why a refular for / next loop is using the result of a dehash of part of the key
best would be to call that dehash the moment you need it, so there's little indication of it being a constant, ie.
the idea here is not to make cracking impossible, just to make it very time consuming
But for checking if a thingy is registered its probably okay to annoy the cracker. Unless he just bypasses the check where it says "if registered" etc.
And do not listen to utopimania, he has absolutely no experience here...
Everything can be cracked. You cannot stop crackers! If your app is good, sure its worth paying hundreds of dollars to stop the crackers, even though you know you cant stop them.. Or is it??
However, i would recommend a mix. Do YOUR best to secure it from being cracked, AND use a commercial tool. What tool you choose, i dont mind. But be ware of ASProtect. Too many have used it, and there are tons of tutorials and even general unpackers for it. However im not sure how they support the newest versions.
edit: I didnt mean to write that you shouldnt listen to utopimania, i just meant you shouldnt take his words for granted. Trust me, its better to mix it than just leave it to the commercial protectors. Think about how confused a cracker would be when he reads that the app is protected by that and this protector, but the usual methods dont work.
Hm but thats known, anyone who worked on securing an application knows this (I hope). You should make your own brew of security system, and change it on every single release you make. Make it hard to be jumped as well. But after all, if you have some spaghetti that goes to here then there and then X.. if you know where X is, you will be able to jump from A to X.. no matter how many spaghetti a la bolognesa you've got

So the basic idea is to add some cheese to the recipe, so its always different on each release.

So the basic idea is to add some cheese to the recipe, so its always different on each release.
yepdagcrack wrote:Hm but thats known, anyone who worked on securing an application knows this (I hope). You should make your own brew of security system, and change it on every single release you make. Make it hard to be jumped as well. But after all, if you have some spaghetti that goes to here then there and then X.. if you know where X is, you will be able to jump from A to X.. no matter how many spaghetti a la bolognesa you've got
So the basic idea is to add some cheese to the recipe, so its always different on each release.

As well as some other stuff. Use your imagination!
olives? tomatoes?
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
Another option could be to use various pieces of strings already in the program (if you have any). Something like if you have certain strings used in window titles, you can run an in string search against the various strings at the time the password is needed. *shrugs*, it's just another hurdle for the criminal/hacker.
Actually, the only two ways I know, to stop a particular criminal/cracker, is to either make sure they have life in prison, or make sure they get the death sentance. But unfortunately, the justice system in this country is virtually nonexistant.
Actually, the only two ways I know, to stop a particular criminal/cracker, is to either make sure they have life in prison, or make sure they get the death sentance. But unfortunately, the justice system in this country is virtually nonexistant.
blueznl wrote:olives? tomatoes?

Code: Select all
Another option could be to use various pieces of strings already in the program (if you have any). Something like if you have certain strings used in window titles, you can run an in string search against the various strings at the time the password is needed. *shrugs*, it's just another hurdle for the criminal/hacker.
Actually, the only two ways I know, to stop a particular criminal/cracker, is to either make sure they have life in prison, or make sure they get the death sentance. But unfortunately, the justice system in this country is virtually nonexistant.

http://www.lockless.com/
check that statement for example.
Re: EXE compliled by PureBASIC and its Security
> PB, reason of why I didnt suggest this little tip is because it doesnt protect
> anything. You just wont be able to notice the strings by reading the exe in
> notepad (doh).. But dissasemble it, for example, using PE Explorer, and
> you'll notice the strings are still totally visible, just as before applying
> MrMat's tip. I'm pretty sure of this.
Well, I decided to test this with PE Explorer v1.98 R5 and nope, it didn't show
any hidden strings using MrMat's tip, after my exe was disassembled.
> anything. You just wont be able to notice the strings by reading the exe in
> notepad (doh).. But dissasemble it, for example, using PE Explorer, and
> you'll notice the strings are still totally visible, just as before applying
> MrMat's tip. I'm pretty sure of this.
Well, I decided to test this with PE Explorer v1.98 R5 and nope, it didn't show
any hidden strings using MrMat's tip, after my exe was disassembled.

I compile using 5.31 (x86) on Win 7 Ultimate (64-bit).
"PureBasic won't be object oriented, period" - Fred.
"PureBasic won't be object oriented, period" - Fred.