to crack or not to crack?
-
If it were me, I'd buy something, unless it were prohibitively expensive or required paying royalties to the company. The companies selling protection software know way more about it than me, and anything I could write would, honestly, be pretty crappy compared to their product. :) That being said, you must also know how to properly hide your use of protection software. If you just make a call like:
if ( !CanIRunTheProgram() ) // call protection library
{
MessageBox("Sorry, dude!");
exit(0);
}
// else, continue on...you'll be cracked in 2 minutes. A cracker will just NOP-out the function call and bypass your security. Check out these pages written by crackers. They're not always the best-written pages, but they do have lots of advice on hiding your use of protection software to make it harder to crack. --Mike-- http://home.inreach.com/mdunn/ "Would it save you a lot of bother if I just gave up and went mad now?" -- Arthur Dent
> Check out these pages written by crackers. yes the fravia pages were the first I came across
-
Hi - all I've recently started to investigate the world of software protection, and I've become worried. The questions I ask myself are should I implement this myself or should I buy? Either way there are many pitfalls - if you buy then once the bought protection scheme has been broken then a whole range of products become broken. If you implement it yourself then the odds are on that your code will be broken quickly unless you really study the art of cracking (not I said cracking not hacking - there is a difference) and thus armed you can then write better code. I suppose the questions are this - what is the best tool to buy if we were to buy in the protection - or should I learn the art of cracking (there is a lot on info available on this subject) and this become by definition a cracker. 5h4uN (as I will now be known)
Go over to www.fravia.org and have a look there. There are lots of lessons there, and also some pages on protection against crackers. The thing to remember is, anything you put in in way of protection, can easily be removed, bypassed or ignored by cracking, simply because most crackers know ASM assembly very well, and therefore using dissasemberlers , can know exactly what your program is doing, almost like them having the source code. *DO NOT HARD CODE ANY KEY OR ANYTHING* in a program - if you're going to do this, at least encrypt it (not just XOR or character swapping). This will make it much harder. Adding threads and timers also annoys crackers and makes it much harder to crack, especially using debuggers like softice. The best protection I've found - but it's not a safe method, is to use code that does work, but shouldn't - e.g., code that works in Release, but not debug. This basically means that debugging it won't work. I put a shareware program out about 1 1/2 years ago, and fairly soon it got cracked, and keygens were made for it. I completely re-wrote the protection and encryption in the next version, but it was still cracked. Purely by mistake, the version after that would not run in Debug mode - it hasn't been cracked or keygened for almost a year, since I left that code in - it makes debugging hard - I have to remove protection code - but it seems to work. Berkut
-
Go over to www.fravia.org and have a look there. There are lots of lessons there, and also some pages on protection against crackers. The thing to remember is, anything you put in in way of protection, can easily be removed, bypassed or ignored by cracking, simply because most crackers know ASM assembly very well, and therefore using dissasemberlers , can know exactly what your program is doing, almost like them having the source code. *DO NOT HARD CODE ANY KEY OR ANYTHING* in a program - if you're going to do this, at least encrypt it (not just XOR or character swapping). This will make it much harder. Adding threads and timers also annoys crackers and makes it much harder to crack, especially using debuggers like softice. The best protection I've found - but it's not a safe method, is to use code that does work, but shouldn't - e.g., code that works in Release, but not debug. This basically means that debugging it won't work. I put a shareware program out about 1 1/2 years ago, and fairly soon it got cracked, and keygens were made for it. I completely re-wrote the protection and encryption in the next version, but it was still cracked. Purely by mistake, the version after that would not run in Debug mode - it hasn't been cracked or keygened for almost a year, since I left that code in - it makes debugging hard - I have to remove protection code - but it seems to work. Berkut
Now that, is the best idea for protection I've heard for a while !. Create code that'll run but can't be debugged. jikes I'm regularly creating that stuff, then spending ages fixing it. I'm guessing but it may pay to insert those cute oneline snippets at a variety of places, Regardz Colin Davies kool idea! Ed I look
-
Now that, is the best idea for protection I've heard for a while !. Create code that'll run but can't be debugged. jikes I'm regularly creating that stuff, then spending ages fixing it. I'm guessing but it may pay to insert those cute oneline snippets at a variety of places, Regardz Colin Davies kool idea! Ed I look
LOL! Yeah, I've been using those funny //, /*, */ combinations much more recently . I thought about submitting an article or demo about this, but on seconds thoughts, I don't want to give crackers instructions to crack my programs - I know - selfish ;p. Berkut
-
LOL! Yeah, I've been using those funny //, /*, */ combinations much more recently . I thought about submitting an article or demo about this, but on seconds thoughts, I don't want to give crackers instructions to crack my programs - I know - selfish ;p. Berkut
I have often wondered why I find it so necessary to ensure I have both Debug and Release versions functioning 100% and the Release to be debuggable. Now I realise it so some hoon can bust any protection I might have with a debugger. And to think I'd been wasting my time recently studying " Obfuscation ". This opens up a whole new aspect to protection. eg If a runtime self extraction exe or ocx were to use this, It'd really confuse things to another level,, Regardz Colin Davies Emit nurds, LSD runtime !
-
Hi - all I've recently started to investigate the world of software protection, and I've become worried. The questions I ask myself are should I implement this myself or should I buy? Either way there are many pitfalls - if you buy then once the bought protection scheme has been broken then a whole range of products become broken. If you implement it yourself then the odds are on that your code will be broken quickly unless you really study the art of cracking (not I said cracking not hacking - there is a difference) and thus armed you can then write better code. I suppose the questions are this - what is the best tool to buy if we were to buy in the protection - or should I learn the art of cracking (there is a lot on info available on this subject) and this become by definition a cracker. 5h4uN (as I will now be known)
Reading this thread I've noticed one thing. There are a lot of crackers around. (Just kidding...) If you are developing a software that is very vertical you have no reason to protect your software, just put inside (and show on screen in some way) the name and the company that buyed it. So, if someone gives its copy to another its name will stay around. But, if you are developing a large distribution software, again don't protect it but make it very very cheap (you will be balanced by the copies sold, just let's see WinZip). If you protect a cheap software it will be a must-to-be-cracked for every cracker around the world. Whatever copy protection you use it will always be cracked, key-generated or DLL-injected by the 1st (2nd or 10th) cracker that looks on it. There is nothing to do. Just look at the real world: does exist a car alarm that cannot be bypassed by the most experienced car-theft ? Bye! SoftechSoftware Davide Calabro' davide_calabro@yahoo.com http://members.tripod.com/~SoftechSoftware/index.html
-
Reading this thread I've noticed one thing. There are a lot of crackers around. (Just kidding...) If you are developing a software that is very vertical you have no reason to protect your software, just put inside (and show on screen in some way) the name and the company that buyed it. So, if someone gives its copy to another its name will stay around. But, if you are developing a large distribution software, again don't protect it but make it very very cheap (you will be balanced by the copies sold, just let's see WinZip). If you protect a cheap software it will be a must-to-be-cracked for every cracker around the world. Whatever copy protection you use it will always be cracked, key-generated or DLL-injected by the 1st (2nd or 10th) cracker that looks on it. There is nothing to do. Just look at the real world: does exist a car alarm that cannot be bypassed by the most experienced car-theft ? Bye! SoftechSoftware Davide Calabro' davide_calabro@yahoo.com http://members.tripod.com/~SoftechSoftware/index.html
> the name and the company that buyed it I wish it could be that easy - but strings are the easiest to replace - heck by the tutorials this is how most of the cracks suceed by looking where the strings are used.
-
Go over to www.fravia.org and have a look there. There are lots of lessons there, and also some pages on protection against crackers. The thing to remember is, anything you put in in way of protection, can easily be removed, bypassed or ignored by cracking, simply because most crackers know ASM assembly very well, and therefore using dissasemberlers , can know exactly what your program is doing, almost like them having the source code. *DO NOT HARD CODE ANY KEY OR ANYTHING* in a program - if you're going to do this, at least encrypt it (not just XOR or character swapping). This will make it much harder. Adding threads and timers also annoys crackers and makes it much harder to crack, especially using debuggers like softice. The best protection I've found - but it's not a safe method, is to use code that does work, but shouldn't - e.g., code that works in Release, but not debug. This basically means that debugging it won't work. I put a shareware program out about 1 1/2 years ago, and fairly soon it got cracked, and keygens were made for it. I completely re-wrote the protection and encryption in the next version, but it was still cracked. Purely by mistake, the version after that would not run in Debug mode - it hasn't been cracked or keygened for almost a year, since I left that code in - it makes debugging hard - I have to remove protection code - but it seems to work. Berkut
> Release, but not debug. do you mean builds ? I was under the impression that debug build gave more info out about how you code works then in release because each line is as you wrote it and not optimised. when I step into a release (with debug info) build the code sometimes jumps back and forth between the lines as the compiler has optimised the code when I look at the fravia pages - I laugh at the simple protection system we put in at the old company, but then the systems we were making were semi one-offs and heavily customised in a per customer basis (with 50-200 seats) so they may crack it but why bother when it is no use to anyone but themselves. > DO NOT HARD CODE ANY KEY OR ANYTHING* in a program yes I did laugh at the one which explained the hack were the coder had hard coded a table of valid keys - my ribs still ache when I think back to that one
-
> the name and the company that buyed it I wish it could be that easy - but strings are the easiest to replace - heck by the tutorials this is how most of the cracks suceed by looking where the strings are used.
It's so simple to hide a string... just use a bitmap and put on it the logo and the name of the company. Then draw the bitmap onto the application (the draw is a pretty hard way to bypass since everything in Windows is drawn). But be careful to embed your bitmap into the application, don't use an external file and don't use a bitmap resource but something like a custom resource (that includes your bitmap as a raw data). SoftechSoftware Davide Calabro' davide_calabro@yahoo.com http://members.tripod.com/~SoftechSoftware/index.html
-
> Release, but not debug. do you mean builds ? I was under the impression that debug build gave more info out about how you code works then in release because each line is as you wrote it and not optimised. when I step into a release (with debug info) build the code sometimes jumps back and forth between the lines as the compiler has optimised the code when I look at the fravia pages - I laugh at the simple protection system we put in at the old company, but then the systems we were making were semi one-offs and heavily customised in a per customer basis (with 50-200 seats) so they may crack it but why bother when it is no use to anyone but themselves. > DO NOT HARD CODE ANY KEY OR ANYTHING* in a program yes I did laugh at the one which explained the hack were the coder had hard coded a table of valid keys - my ribs still ache when I think back to that one
> do you mean builds ? I was under the impression that debug build gave more info out about how you code works > then in release because each line is as you wrote it and not optimised. when I step into a release (with debug info) > build the code sometimes jumps back and forth between the lines as the compiler has optimised the code Yes. Debug build encodes in extra information that allows the debugger to understand what's going on in C++ (or whatever language you're using), so you can trace and make breakpoints easily referencing the code. But debuggers like softice (and even debug.exe that comes with windows NT) can debug Release build .exes, because they do it by machine code (assembly), because this is the language the operating system and computer understand. It's not as easy to debug this way - you have to know ASM, but it's still just as possible to set a break point in the same place, and even trace and run step-by-step as long as you know what you're looking for. You can even set break points whenever the program calls an API call, or a C runtime function. Berkut
-
> do you mean builds ? I was under the impression that debug build gave more info out about how you code works > then in release because each line is as you wrote it and not optimised. when I step into a release (with debug info) > build the code sometimes jumps back and forth between the lines as the compiler has optimised the code Yes. Debug build encodes in extra information that allows the debugger to understand what's going on in C++ (or whatever language you're using), so you can trace and make breakpoints easily referencing the code. But debuggers like softice (and even debug.exe that comes with windows NT) can debug Release build .exes, because they do it by machine code (assembly), because this is the language the operating system and computer understand. It's not as easy to debug this way - you have to know ASM, but it's still just as possible to set a break point in the same place, and even trace and run step-by-step as long as you know what you're looking for. You can even set break points whenever the program calls an API call, or a C runtime function. Berkut
-
It's so simple to hide a string... just use a bitmap and put on it the logo and the name of the company. Then draw the bitmap onto the application (the draw is a pretty hard way to bypass since everything in Windows is drawn). But be careful to embed your bitmap into the application, don't use an external file and don't use a bitmap resource but something like a custom resource (that includes your bitmap as a raw data). SoftechSoftware Davide Calabro' davide_calabro@yahoo.com http://members.tripod.com/~SoftechSoftware/index.html
-
Hi - all I've recently started to investigate the world of software protection, and I've become worried. The questions I ask myself are should I implement this myself or should I buy? Either way there are many pitfalls - if you buy then once the bought protection scheme has been broken then a whole range of products become broken. If you implement it yourself then the odds are on that your code will be broken quickly unless you really study the art of cracking (not I said cracking not hacking - there is a difference) and thus armed you can then write better code. I suppose the questions are this - what is the best tool to buy if we were to buy in the protection - or should I learn the art of cracking (there is a lot on info available on this subject) and this become by definition a cracker. 5h4uN (as I will now be known)
I recommend learning how to crack. By learning how trivial it is to bypass most protection schemes, you can start to devise schemes of your own that are a) less fragile and b) non generic. There was a site (www.fravia.com) that had dozens and dozens of articles written by crackers describing how they cracked this or that app. Some of the techniques these people use are simply amazing! It even went beyond protection breaking, to the mind-blowing feat of adding new functionality to already-compiled EXEs. You are up against tough competition, once your app becomes popular. All of the popular protection tools were cracked, by people on that site, in the general case: one crack works for all apps using that tool. Unfortunately, that site has now changed its focus. But, i'm sure you could find similar info out there - here's one: http://www.soft4you.com/vitas/antihack.htm . Remember, changing one BYTE turns "if (good_key)" into "if (true)". In my opinion, the best thing you can do is release frequently. By releasing frequently, you make obsolete all current cracks. I also think that controlling your program's distribution is important. By controlling distribution, you make sure that each revision is only available for a limited time - keeping the crackers busy trying to keep up. Once a version of your app ends up on a magaizine CD, you can be guaranteed that version will be the one favored by pirates. -c