Cracking software
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 15 of 15

Thread: Cracking software

  1. #1
    Join Date
    Feb 2003
    Location
    Bangalore, India
    Posts
    1,354

    Post Cracking software

    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
    Code:
    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
    Even if our suggestions didn't help, please post the answer once you find it. We took the effort to help you, please return it to others.

    * While posting code sections please use CODE tags
    * Please check the codeguru FAQ and do a little search to see if your question have been answered before.
    * Like a post, Rate The Post
    * I blog: Network programming, Bible

    I do all things thru CHRIST who strengthens me

  2. #2
    Join Date
    Sep 2000
    Location
    Indianapolis
    Posts
    6,422
    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.
    Last edited by Brad Jones; January 7th, 2004 at 07:24 AM.
    -----------------------------------------------
    Brad! Jones, CodeGuru.com Site Director
    Developer.com Network Director / EiC

    webmaster@codeguru.com
    (My Latest Book)


    -----------------------------------------------

  3. #3
    Join Date
    Dec 2003
    Posts
    220
    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

  4. #4
    Join Date
    Aug 2001
    Location
    Stockholm, Sweden
    Posts
    1,664
    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.

  5. #5
    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)

  6. #6
    Join Date
    Dec 2003
    Posts
    8
    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
    Last edited by Paul6253; January 7th, 2004 at 10:25 AM.

  7. #7
    Join Date
    Dec 2002
    Posts
    1,050
    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"

  8. #8
    Join Date
    Feb 2003
    Location
    Bangalore, India
    Posts
    1,354
    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.
    Even if our suggestions didn't help, please post the answer once you find it. We took the effort to help you, please return it to others.

    * While posting code sections please use CODE tags
    * Please check the codeguru FAQ and do a little search to see if your question have been answered before.
    * Like a post, Rate The Post
    * I blog: Network programming, Bible

    I do all things thru CHRIST who strengthens me

  9. #9
    Join Date
    Aug 2001
    Location
    Stockholm, Sweden
    Posts
    1,664
    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.

  10. #10
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    3,845
    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.

  11. #11
    Join Date
    Aug 2003
    Posts
    938
    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.

  12. #12
    Join Date
    Feb 2003
    Location
    Bangalore, India
    Posts
    1,354
    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)
    Even if our suggestions didn't help, please post the answer once you find it. We took the effort to help you, please return it to others.

    * While posting code sections please use CODE tags
    * Please check the codeguru FAQ and do a little search to see if your question have been answered before.
    * Like a post, Rate The Post
    * I blog: Network programming, Bible

    I do all things thru CHRIST who strengthens me

  13. #13
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    3,845
    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.

  14. #14
    Join Date
    Apr 1999
    Posts
    27,426
    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

  15. #15
    Join Date
    Nov 1999
    Posts
    9
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Azure Activities Information Page

Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center