Cracking software

[Mathew Joy]

We all know that there are cracks available for most of the s/w that have a few restrictions/disabled features in them. Recently I've met a person who has done some R&Ds in security. He told me that it is not very difficult to trace the equalities in the exe. Once that is traced out a few statements can be inserted to bypass that block (or something like that). According to what he said if I have a statement like

if(TotEvalDays > 30) {
	[.display a message that s/w has expired.]
	[.exit.]
}

this can be traced and bypassed. The tracing is facilitated by checking the code that is executed when the message box is displayed. And as from what he said defence can be added by avoiding these two statements (esp the message box) from the checking part. I found this a bit tough to digest...but is this true?? If not, how are s/w cracked? Any opinions??

Thanx

[Brad Jones]

Admin Note:

This thread is not to digress into talking about how to illegally crack software, rather it is to help people understand how to prevent cracking and to understand the implications of such.

Please keep this thread focused.

Thanks.

[Homestead]

Originally posted by Brad Jones
Admin Note:

This thread is not to digress into talking about how to illegally crack software, rather it is to help people understand how to prevent cracking and to understand the implications of such.

Please keep this thread focused.

Thanks.

Mr Jones,
I think if people know how to crack it, they will also find out a way to prevent it..Because it is really impossible to immediately discuss the main problem with out telling anyone what the problem is about...

I am also always wondering why so many softwares can become "trial" while I think they are absolutely the same with the real ones, I also think manufacturers (sorry, Iam in business not in computer, I dont know what to call them) enclosed some kind of functions as Mathew said to package their softwares...If we can do as Mathew told, the trial version will be the real ones. Is it correct ? May I ask ?

Thanks a lot,

Regards,

homestead

[j0nas]

Mathew Joy, your friend is right. But there is no 100 % proof way of protecting your software (by software). Even Microsoft fails in this area.

The best way is probably to obscure the protection code as much as possible. This will confuse crackers. Some will try 5 minutes, others may go on for 5 hours... It's just a matter of time and skill before someone breaks it.

[DHillard]

I think the root of this problem is developers releasing complete applications as shareware trial versions. To keep shareware from being cracked, the developer should keep some basic critical functionality out of the code. Once registered, (paid for) the user would then get a new executable with the needed code in it.

One step short of this is to include the code but restrict its usage. Again, this restriction must be the only code available in the executable to prevent the equality detection/skip/hack/patch.

The trial version can contain menu items of the missing functionality, but keep the code out of the finished executable. Then if the hacker wants to try to crack it, let 'em try. They've got more time than you, plus they'll be wasting their time trying to crack into code that isn't there, plus the time they spend trying to crack it is time they won't spend trying to crack something else.

(This won't do jack to keep your registered users from distributing their full version to the world, but you will be guaranteed at least one sale)

[Paul6253]

I like DHillard's suggestion. Dont relaese programs that can be
'unlocked' with a key. This has been a standard for too long.
As far as ethics go, I dont see anything wrong in code
patching so long as you have PAID for the software.
The amount of knowledge and time involved to crack s/w is
not proportionate to the cost of purchase (in most cases).
By that I mean most crackers do not care about using the software, they are only interested in the challenge.
I have two friends who work for comanies that retrieve lost data. This line of work requires low-level assembler knowledge and superb debugging skills. They *must* crack the software.
It's thier job.
These skills come in handy when they
dont like an application they bought-- they mod it to thier liking.
Why wait for the 'next patch' if you can do it yourself?
I'm sure it kind of frustrates HLL/OO coders knowing the truth in that there is alot of smart kids know more about cpu internals than they do. All I can say to that is 'smarten-up'.
In any event, Programmers should get thier due.
regards

end note: here is a very good link to ideas on techniques we
can use to protect our software. Excellent Read!
http://www.searchlores.org/protec/protec.htm

[mdmd]

This site has some tips from a few people to make cracking harder
Also, at the bottom, are some links to a few anti-cracking type
sites.

FRAVIA'S "HOW TO PROTECT BETTER"

[Mathew Joy]

Hi all,
A lot of things happened between my first post and the second (Brads). By that time I read to a link to a thread he posted me, plus a few articles. And I came to a few conclusions.

1. To crack (c/c++) programs you need to know assembly language programming. There is no tool that disassembles your exe back to the code (c/c++). So there is a vast difference between knowing 'how to crack' and 'how to prevent from cracking' (against what was pointed out by homestead)

2. There is no practical way to prevent it from determined crackers. There are generally 2 types of crackers/hackers. A real cracker and 'script kiddies'. The script kiddies uses certain tools and minor code changes to accomplish the purpose. They don't have the knowledge or patience, if the code is 'protected'

3. The best way to protect, as DHillard pointed out, is to keep the code away from trial version than to protect it. You can't crack a code if it is not present.

4. The next best way is to update your s/w frequently so that patches(cracked) won't be working for long

5. Use some techniques to throw these script kiddies out of track. Links to them are posted in this thread. Few of them (simplest) may be using inline function where checking is done and do the same in many places, not hard coding critical (such as "Not registered") strings, moving the checks from the displaying windows, using multithreading etc, etc, etc...

6. Stop worring and avoid putting too much time and effort into the prevention. People who use the cracked version of your product will almost never pay if the cracked version is unavailable. Target your s/w to those who pay and make it good and robust.

There may be other points that can be added here.

Even Microsoft fails in this area.

Let me comment about this. Its not exactly that they fails, but they secrectly allows their products to be cracked/pirated (I'm not talking about all the products). It is just recently they started to add security to their os. Other big names like AVG (if I remember correctly) deliberately added loop holes to allow ftp programs to download their s/w and patches. The answer to why, is to increase popularity/awareness of their name/product. Many s/w firms (esp big ones) are adopting such stategy and many other including Bad publicity is the best publicity

Thanks for all your views in this thread and hope this discussion was useful.

[j0nas]

Originally posted by Mathew Joy
Its not exactly that they fails, but they secrectly allows their products to be cracked/pirated (I'm not talking about all the products). It is just recently they started to add security to their os. [/I]

Ok, maybe so (for their apps), but I was thinking of their code-signing stuff that aren't fully secure (it can never be, becuase it's software). For instance, you can easily patch away the code that verifies signatures on certian DLLs or EXEs (performed by advapi32.dll). Developers perhaps think MS has good security when they must send their modules to MS to get them digitally signed.

[OReubens]

1. To crack (c/c++) programs you need to know assembly language programming.

Definately ! Although a casual understanding of the various instructions isn't going to be enough. It takes a dedicated mind focused on the job and the ability to glance over a series of instructions and 'immedialtely' know what the code does.

It's this dedication, and the 'kick' of getting something cracked that gets most crackers to do what they do.
While most programs can be cracked in a matter of minutes or a few hours. Some crackers are prepared to spend DAYS in order to get a piece of software cracked.

EVERY software protection can be broken. Heck, even hardware protection can be broken (remember the whole stir when all of a sudden a program appeared that could crack the hardware based DVD protection !
The fact that some software seemingly doesn't get cracked just points out that that piece of software was less enticing for the crackers to begin with. Most likely because there is better software around that does the same job.

There is no tool that disassembles your exe back to the code (c/c++).

Back to C/C++ code... No, although there are programs that will decompile into a very clean assembly listing. Even tagging part of the code as 'library code' and insert the proper library names. If you really wanted to, you could then do a manual job over the assembly listing to reconstruct the C/C++ code.

I demonstrate this very principle in one of my classes/courses on advanced debugging.

So there is a vast difference between knowing 'how to crack' and 'how to prevent from cracking' (against what was pointed out by homestead)

True. But you can't ever hope to become good at preventing it, if you don't know 'how to crack'.

2. There is no practical way to prevent it from determined crackers.

No there isn't. The current trend in the music CD bussiness to 'copy protect' CD's just makes me laugh. It is a temporary measure. Sooner or later some smart kid will figure out how to work around the protection and will manage to extract the audio stream anyway. Or some hardware manufacturer will see a market in making a CD-drive that isn't bothered with the protection altogether.
Think about it. Companies like Pioneer, Sony, Phillips... who ALSO have an interest in the music CD bussiness are making the very tools to allow copying the CD's in the first place. And I'm not only talking CD-ROM-Writers. they are also making HiFi components that allow you to copy (part of) a CD.
The CD has from the very beginning supported a 'copy protection' bit. All it really should have taken is __ALL__ CD-manufacturerers stricly imposing the copy protection. But they don't. because it means more sales in CD-Drives.

3. The best way to protect, as DHillard pointed out, is to keep the code away from trial version than to protect it. You can't crack a code if it is not present.

This is indeed the easiest solotion. And in C/c++ easy enough to do. Build 2 release versions. one for the shareware version, one for the full version. Use #ifdef _RETAIL type constructs to compile out the unwanted parts.
If you have a strong tie with your customers, it can even be advantageous to watermark/id each copy sent out, embed this in the code, but never touch it from the code itself. If a version does pop up in the warez scene, check the watermark/id, and then sue the client that has caused the leak. This may need a special type of user licence agreement in some countries though.



CONCLUSION:
If you have a piece of software that won't be used but by a small amount of people, then crackers won't bother with it in the first place. Hence you don't have to bother with any form of advanced protection, a simple validation will be enough.

If, on the other hand, you have a product that thousands/millions of people would like, then there will be crackers trying to break it, and nomatter how hard you try someone will eventually crack it or if you chose to have separate retail/shareware versions, a retail version WILL get spread in the open.

The best you can hope for is that there will always be a percentage of people that WILL buy the product, and some just won't ever buy it, if you could make your software cracker proof, those people would just use another program altogether. In the end those people can still be of use since they provide word-of-mouth type advertisement if your program is good at what it does.
Do your best at making the programs you write the best they can possibly be and provide decent after sales support, and you will always have a steady income from sales and upgrades. The fact there are people using illegal versions of your software.. Well. you just kinda have to take that along with it.

[Quell]

there is nothing like crack proff software. whatever you make it will get cracked , it doesnt' matter at all. NO protection is good. it is jsut a metter of time. There will alywas be sdomone who will crack your soft no metter what kind of soft you amde and if there are 100 better then yours.
So my advice is don't implement something beyond basic security , because it will keep noobs aways from crackign it , but since more advance crackes will still crack it , it will make the time you spend makign the basic protection worhwhlie , and now having to see your soft cracked after you soent 40+ ours on making super good protection that wil get cracked anyways. There is no other way.

[Mathew Joy]

Originally posted by OReubens
......................................

Nice detailed explanation. In my post I forgot to mention that the exe that I (and every one here) was talking about was the release build and not the debug build. Debug builds have lots of information about the code stored in the exe. Some one may come up in the thread yelling "Hey you guys are wrong! I got the codes disassembling the exe." (It had happened before)

[OReubens]

Nice detailed explanation. In my post I forgot to mention that the exe that I (and every one here) was talking about was the release build and not the debug build. Debug builds have lots of information about the code stored in the exe. Some one may come up in the thread yelling "Hey you guys are wrong! I got the codes disassembling the exe." (It had happened before)

Actually, there is quite a bit of readily available information in a releasebuild as well.
All API functions come from importtables (except explicit links via loadlibrary/getprocaddress), and each call to a Windows API call can be cleanly written in the assembly listing.
Since you can identify LoadLibrary/LoadProcAddress anyway, you can also cleany identify each function called through LoadLibrary/LoadProcAddress.

If you have a database of different runtime libraries, you can also identify the byte pattern for these functions, and then replace each call to those functions with the proper name (strcpy instead of something like 'func000147').

Even other common libraries like MFC, STL (various versions) and the like can be readily identified.

I have an advanced decompiler (appended with lots of addons and an extended database to 'common' libraries I made myself) that does just that, and can strip out all of the CRT, STL, MFC (and a few other) libraries, leaving all the code you've written yourself in assembly, but with proper function names to calls to the libraries. From there to reconstructing the C/C++ code is fairly straightforward, although it does take time.

Now, this is not for cracking purposes (although some might call it that), I regulary have to do this as part of reverse engineering a piece of software for which we don't have the sourcecode and for which the original author/company has stopped supporting it.

[Paul McKenzie]

Originally posted by OReubens
Even other common libraries like MFC, STL (various versions) and the like can be readily identified.

So if you use your own template classes, how can you tell if this is STL or not (especially if the compiler does optimizations)? You may be stripping away user-code, not library code.

Regards,

Paul McKenzie

[Arhkos]

Quell has it right... if someone wants to crack your software, they will eventually figure out how to do it. As someone else mentioned, there are websites on how to crack software, the best I know of is Fravias. Knowledge of how to crack equals knowledge of how to prevent... or rather slow down crackers. You just need to make it hard enough so the wannabe cracker can't break it, but not complex enough to temp those hardcore guys. As you can see in some of the "student articles" at Fravias HCU: the more complex the protection, the more eager they are to crack it.

Anyway, +Fravia has a good section on prevention. It's valuable info if you ask me.