Sign in to follow this  
tonymontana

Book about anti-cracking / preventing cracking

Recommended Posts

i wonder if there is a Book about anti-cracking / preventing cracking of .exe files.I want to learn more about protecting .exe files from crackers(i know it is not always possible..but at least i want to make my programs hard to crack).All i need is a book (with example source codes ).I have already read a lot of websites about this.All of them are just describing what you should do..but there is no actual implementation of system ( no code). is tehre a tutorial which is about protecting a program using serial-keys or something ("key-file method ...)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by tonymontana
i wonder if there is a Book about anti-cracking / preventing cracking of .exe files.I want to learn more about protecting .exe files from crackers(i know it is not always possible..but at least i want to make my programs hard to crack).All i need is a book (with example source codes ).I have already read a lot of websites about this.All of them are just describing what you should do..but there is no actual implementation of system ( no code).
is tehre a tutorial which is about protecting a program using serial-keys or something ("key-file method ...)


there are plenty of webpages about exactly this topic, however the best thing you can really do, is to simply check out the various cracking related websites, in fact these feature often forums, too. And the folks there are usually pretty willing to provide creative ideas to make cracking your app harder.

Share this post


Link to post
Share on other sites
I'd actually suggest looking up on the literature about how to crack software, which is a little more plentiful. It's my personal belief that you can't expect to effectively defend against an attack unless you understand the attack to begin with, and that includes knowing how to pull it off.

Share this post


Link to post
Share on other sites
So you say...firstly you must be at least a novice cracker to defend your program ..ok i don't think it will be much difficult to be a novice cracker(or having a knowledge about it).But there must be a book with codes/examples about defending an exe file..Isn't there such a book?(it there is say it plz)

Would u Say me a website that has tutorials for newbies(a website that has implementation too..not only ideas..i already know/read such sites).

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by tonymontana
So you say...firstly you must be at least a novice cracker to defend your program ..ok i don't think it will be much difficult to be a novice cracker(or having a knowledge about it).But there must be a book with codes/examples about defending an exe file..Isn't there such a book?(it there is say it plz)

I don't think such a book exists, at least not dedicated to executable protection schemes in particular. However, if it did exist it would certainly be outdated rather quickly. The cracking scene is a very dynamic movement.
However, if you know what tools and techniques are used to crack binaries, you'll also get to know the problems and limitations of the various existing approaches.
In fact, there are some applications that make it very complicated to crack them. So, if you follow the corresponding discussions you'll also learn what's suitable to make a cracker's life harder.

So, if you know how cracking works, you also learn what makes cracking more complicated and sometimes even unfeasible in the end. Nevertheless, there isn't the one general solution to the cracking problem, rather you'll always have to combine various approaches in order to make them interact with each other, so that all protection schemes depend on each other and render an executable unusable when being targetted.
In the end, knowing assembly language and having a basic knowledge about hardware architectures can be very useful. In particular, if you actually take the time and try to crack your own stuff, so that you see how your abstract sources are converted to low level stuff and what this looks like.


Quote:
Original post by tonymontanaWould u Say me a website that has tutorials for newbies(a website that has implementation too..not only ideas..i already know/read such sites).

Check the various wikipedia articles about cracking, reverse engineering, decompilation, debugging etc. and you will come up with plenty of references, even a single webpage with a community forum will do, as these folks will happily share their knowledge with you.
If you want to check out one of the sites that used to be extremely popular, do a google for "fravia's".
http://en.wikipedia.org/wiki/Software_cracking

Share this post


Link to post
Share on other sites
For protection, there are two options that are worth exploring. The first is big expensive protection packages like StarForce that do some unknown magic and can protect your program for a short while. The other options is machine-code obfuscation and virtualization, which can be done using products such as EXECryptor. It's pointless to spend time becomming a decent cracker and then trying to invent your own protection [1] because protection doesn't protect very well no matter what it does. Thus, if you value your time, you should simply buy an existing product and use it to protect your program as well as can be done.

[1] UNLESS your intent is to spend a _very_ long time to come up with a complete solution, which you could then sell to others in order to make the time worthwhile. In that case, a good book to teach you basic reverse engineering is Reversing: Secrets of Reverse Engineering. A book that I don't own but have looked at, and seems to be a very bad book on exactly the topic you asked for, is Crackproof Your Software: Protect Your Software Against Crackers .

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Extrarius
For protection, there are two options that are worth exploring. The first is big expensive protection packages like StarForce that do some unknown magic and can protect your program for a short while. The other options is machine-code obfuscation and virtualization

Yes, but there are also many other methods to make cracking your binaries significantly harder, and that's the overall point of doing all this: making the task as difficult as possible.

Quote:
Original post by Extrarius
It's pointless to spend time becomming a decent cracker and then trying to invent your own protection [1] because protection doesn't protect very well no matter what it does. Thus, if you value your time, you should simply buy an existing product and use it to protect your program as well as can be done.

again, you don't need to become a "decent cracker" in order to apply the tricks and techniques recommended by professional crackers. If you check out the aforementioned webpage you'll find numerous excellent tips that in fact make cracking a LOT harder-without necessarily being too complex to apply for a high level programmer, likewise there's usually hardly any need for commercial products if you know what you're doing.
Also, it is crucial to keep in mind that a commercial protection scheme is a much more interesting target for a cracker than a normal application in itself, simply because there's the possibility to crack multiple apps at once by cracking the underlying scheme.


Share this post


Link to post
Share on other sites
I've read the site, and basically none of the methods mentioned on that page are worth spending time on if you're developing for a modern operating system running on a modern platform.
Also, SoftIce isn't really used by anybody anymore and hasn't been in a LONG time. Yes, it's a good kernel mode debugger, but kernel mode code is difficult to do correct and SoftIce has never been stable on the NT platform.

A far more effective thing to do would be to modify the default calling convention to 'fastcall' in your C++ compiler settings and turning optimizations on maximum settings (NOT the generic 'maximum', but set each individual setting to the highest value - in VS2002 and 2003 at least, they're not the same), because disassemblers have difficulty tracking parameters that aren't passed via stdcall/cdecl and the optimizer will mangle fastcall so that parameters are sometimes passed using nonstandard conventions (not even fastcall). Turning on link-time code generation ('global optimization') helps make sure things are optimized as much as possible.

Inlining is good also, because it makes it more difficult to track each place a function is called, which can be very important to find when decyphering complicated logic (or trying to modify a function). Also, using virtual functions makes it at least take manual effort to track function calls, and if used excessively can make it somewhat difficult to figure out which functions are called when.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
There's also a wiki book about Reverse Engineering:
http://en.wikibooks.org/wiki/Reverse_Engineering

While its sections about cracking in general aren't yet populated, you are probably encouraged to do so if you'd like ;-)

Share this post


Link to post
Share on other sites
At one time I was interested in how to protect my executables. So I developed a PE file encryption utility using assembly I found these sites helpful.
http://www.reverse-engineering.net/
http://www.reteam.org/

I would post more, including those with source, but this is a fine line area. Therefore some of the sites would probably not make the mods very happy. If the mods find one of those two sites unacceptable please remove them. [smile]

Share this post


Link to post
Share on other sites
Personally I believe you are wasting your time since after reading all the suggested links/books you will come to conclude that any exe can be cracked so your time would be better spent writing a game/app so good that people would be more than happy to pay for it instead of cracking!

Share this post


Link to post
Share on other sites
thnks...i started to read the articles/resources i found..some of them requires assembly knowledge i am now on that part.Do you know EASY-assembly teaching tutorials(i saw some but i am a java C/C++ programmer ,off this assembly languagee is very irritating.):) they are not hard to understand but JE MOV etc..it is very hard to program this way)

Share this post


Link to post
Share on other sites
hım..i dont think so i think at least i have to add some anti-cracking to my programs.i have an idea about multithreading checks..tutorials says that it will be hard for a cracker.I will make my checking routine inline.and put some places in actual threads( rendering ,calculation(ai.pyhsics..)).And sometimes(randomly) in my program i will create a thread that is checking the correct reg# .And i am also thinking about making the reg# dependent on a feature of game concepts (such as framerate..velocity..number of collisions).Maybe.. maybe not ..i don't know yet

Share this post


Link to post
Share on other sites
"assembly languagee is very irritating"
Well it's like water to fish for those that like cracking programs so my original point that you'll be wasting your time.
Those that crack programs love to waste time using assembly to easily crack any program you might write.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by DevLiquidKnight
At one time I was interested in how to protect my executables. So I developed a PE file encryption utility using assembly I found these sites helpful.
http://www.reverse-engineering.net/
http://www.reteam.org/

I would post more, including those with source, but this is a fine line area. Therefore some of the sites would probably not make the mods very happy. If the mods find one of those two sites unacceptable please remove them. [smile]


I wouldn't know why mentioning even hardcore hacking/cracking sites should be unacceptable if it's for the purpose of learning techniques to improve software protection?
After all, such links can be incredibly useful resources for people who aren't familiar with that stuff.

Quote:
Original post by daviangel
Personally I believe you are wasting your time since after reading all the suggested links/books you will come to conclude that any exe can be cracked so your time would be better spent writing a game/app so good that people would be more than happy to pay for it instead of cracking!


Sure, any binary can be cracked. It's only a matter of the resources you throw at the problem.
So, if you have the manpower, motivation and time you can crack anything.
Nevertheless, there are still various applications out there that haven't been successfully cracked until today.
It's not because they would be "uncrackable", rather it's because they are using multiple layers of incredibly clever (COMPLICATED!) schemes that make a cracker's life very hard, so that it's simply not worth it.

After all, that's the point of protection schemes: make cracking your app unfeasible!
There are plenty of people out there who can crack simple stuff, however the more complicated your protection scheme, the less people are likely to be able to successfully target your app. Of course this is a double-edged sword, as having a great protection scheme will also attract certain people, be it for the possible reputation that could be gained, or for the intellectual challenge involed.

And the latter is another very important point: understanding a cracker's motives-many elite crackers don't do "it" because of the illegality, the software's price, the reputation or because they like your software so much, rather it's exactly the challenging, mentally and intelluctally stimulating nature of cracking which can also be extremely satisfying.

It's very much like chess, where you have to keep track of a huge number of connections, inter-dependencies and possibilities at once but also need to have a huge knowledge base and set of personal skills and tools to "win the game" ;-)


Quote:
Original post by tonymontana
Do you know EASY-assembly teaching tutorials

google: assembly x86
http://www.google.com/search?hl=en&lr=&c2coff=1&q=assembly++x86&btnG=Search

Quote:
Original post by tonymontana(i saw some but i am a java C/C++ programmer ,off this assembly languagee is very irritating.):) they are not hard to understand but JE MOV etc..it is very hard to program this way)


it's one of the lowest possible abstraction levels, and it's good to get used to it.
After all, this is exactly how all your sources will eventually look.
By seeing your source code at the same level as possible crackers might see it, you'll also see potential problems. For example, it is very important to keep in mind that some sort of extremely cool high level- and complicated protection scheme may in fact look totally stupid, simple and ridiculous on the lower (asm) level (JNZ [EAX+004].
Likewise, simple HLL stuff may in fact become very complex in assembly and "mess up" the low level code significantly.

So, if your sources look bloated and complicated on the lower level, they'll also require more effort to be properly understood by a potential "cracker".

If you throw in some SMC, i.e. in order to dynamically obtain the CRC of a function or class instace, you can use it to decrypt/decompress hidden code that may look like data in assembly otherwise.

Quote:
Original post by tonymontana
hım..i dont think so i think at least i have to add some anti-cracking to my programs.i have an idea about multithreading checks..tutorials says that it will be hard for a cracker.I will make my checking routine inline.and put some places in actual threads( rendering ,calculation(ai.pyhsics..)).And sometimes(randomly) in my program i will create a thread that is checking the correct reg# .And i am also thinking about making the reg# dependent on a feature of game concepts (such as framerate..velocity..number of collisions).Maybe.. maybe not ..i don't know yet


There are many interesting possibilities, however it is crucial to keep in mind that not a single solution will work alone, you should always be endeavoured to tightly integrate any techniques you use, so that they literally depend on each other. That way, you can dynamically permutate your code at runtime, so that its program flow isn't consistent between runs (debugger sessions!), rather it should always take some new path (i.e. by making it dependent on runtime variables like date,time, mouse input, timers, random numbers etc.). Throw in some random code integrity checks at runtime, as well as delayed responses and you can surely make a cracker's life bloody hard.

Ultimately this is an approach that can make it truly hard to track your program's code flow properly, simply because it will behave differently each time it is run. Resulting in asm dumps that will look different every time the program is run.

This is another important thing: as a cracker, you usually don't have access to the HLL sources of the stuff you are cracking, nevertheless you need a HLL understanding of the overall code flow and what's happening behind the scenes. While this is generally really not a big deal, because you literally "think" asm, you can nevertheless make this very complicated by doing stuff that doesn't properly translate between HLL/ASM. So that a potential cracker doesn't immediatley know/see what you are trying to do because it's very hard to keep track of what's happening on the lower level.

So, if you make it extremely hard for the cracker to obtain this very knowledge, you make it also very time-consuming to come up with a crack.


Quote:
Original post by daviangel
"assembly languagee is very irritating"
Well it's like water to fish for those that like cracking programs so my original point that you'll be wasting your time.


that's not true at all: as a cracker, you come to appreciate and respect those people that truly manage to come up with something that's hard to crack, and sometimes you'll even respect them as much as not to give away any cracks for those apps ;-)
Also, it's really not complicated to get in touch with crackers or even cracker groups in order to discuss what works best and what doesn't. These folks LIKE TO SHARE their knowledge and expertise. USE IT!!

Quote:
Original post by daviangel
Those that crack programs love to waste time using assembly to easily crack any program you might write.


again, wrong-it's not about "wasting time", it's creative problem-solving that makes cracking appeal to many people. As much as you may enjoy programming in C/C++, crackers may enjoy solving problems backwards, on a lower levels.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
[...]Sure, any binary can be cracked. It's only a matter of the resources you throw at the problem.
So, if you have the manpower, motivation and time you can crack anything.
Nevertheless, there are still various applications out there that haven't been successfully cracked until today.
It's not because they would be "uncrackable", rather it's because they are using multiple layers of incredibly clever (COMPLICATED!) schemes that make a cracker's life very hard, so that it's simply not worth it.

After all, that's the point of protection schemes: make cracking your app unfeasible!
There are plenty of people out there who can crack simple stuff, however the more complicated your protection scheme, the less people are likely to be able to successfully target your app. Of course this is a double-edged sword, as having a great protection scheme will also attract certain people, be it for the possible reputation that could be gained, or for the intellectual challenge involed.[...]
Any method you develop yourself (starting with virtually no knowledge of reverse engineering) will require more time to develop than it will take to crack.
Thus, unless you're planning on developing a commercial solution, it's better to buy somebody else's commercial solution. Anti-cracking these days is *not* easy, because there are very impressive tools available that can tear appart an executable with ease. If anything is encoded, it must be decoded before the executable can use it, and all a cracker has to do is use your own decoding routine (or, if it's spread all over the place, just run the program and break after it's decoded the data, then save the buffer the data is in). Thus, obfuscation is the best method, because it's one of the very, very few techniques that doesn't "undo itself" for the cracker and it takes virtually no time to implement if you use an existing tool.

One of the other methods is very complicated to implement, but the idea is to design your code so that it all runs from the same page of memory and treats any code it jumps to as in the next segment, then have a "guard page exception" handler that will adjust the instruction pointer back to the original segment and decrypt the new code to go there. You definitely want to make sure that if you do this, loops don't ever cross the page except when absolutely neccessary. This option would be difficult to crack, but it invovles writing a code generator for a compiler at the very least (or buying one somebody else made, if there is one for sell). The protected code will run very slowly (basically it'll be like TONS of page faults), but it will be difficult to crack since the reverse has to basically rewrite your code to work in a normal way (or make a fancy tool to detect which page is loaded and apply a custom patch each time a new page is loaded). Obfuscating the code would be a good idea too, but you need to be careful to ensure it doesn't expand the code too much since that would slow down execution considerably.

Share this post


Link to post
Share on other sites
Discussions like these happen often in the reversing community. The first thing to realize is that complete binary protection is impossible. Therefore, the objective is to trip up the would be cracker as much as possible, by making them work. There are a number of ways to do this, but the best strategy I've ever seen is based on the idea virtual machines.

Create your encryptor/packer in a homebrew machine language, which you then decrypt at run time. Any critical components for your program should run in this virtual machine along side a copycheck. In order for the cracker to reverse your program, they must first reverse this machine, which adds a great deal of tedium, frustration and above all human effort.

I would not waste time on trivial things like anti-debugging tricks since most of those can be mechanically circumvented. Commercial protection schemes rarely offer much protection, since they are often very well documented and thoroughly exploited. About 90-95% of all the automatic protectors have an automatic unprotector, which renders them completely ineffective.

Remember: Force them to use a human, not a machine. If you can do that, then you've got a strong protection.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by tonymontana
thnks...i started to read the articles/resources i found..some of them requires assembly knowledge i am now on that part.Do you know EASY-assembly teaching tutorials(i saw some but i am a java C/C++ programmer ,off this assembly languagee is very irritating.):) they are not hard to understand but JE MOV etc..it is very hard to program this way)


http://www.asmcommunity.net/x86book/index.php?title=Main_Page
http://en.wikibooks.org/wiki/Reverse_Engineering/Anti-Reversing

Share this post


Link to post
Share on other sites
Quote:
Original post by robotichrist
[...]the best strategy I've ever seen is based on the idea virtual machines.[...]
That's called virtualization, and it's most effective when combined with obfuscation because that means there are now 3 things that must be untangled (the VM code, the VM instructions, and the actual machine instructions) and the obfuscation (and possibly interleaved encryption) makes each of those difficult to understand, much less all 3 at once (which is required since each is taking turns at doing important things).

The tool I linked to previously (EXECryptor) does both obfuscation and virtualization. I can't speak for how well it does it, as I haven't used the tool, but it's my standard example of what is out there (because it's the only one I've seen that looked at all reputable).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this