Getty Images
How do people crack computer programs and games? originally appeared on Quora: the place to gain and share knowledge, empowering people to learn from others and better understand the world.
How do people crack computer programs and games? By thinking like a:
- User.
- Architect.
- Mechanic.
Software cracking refers to:
“Modification of software to remove or disable features which are considered undesirable by the person cracking the software, especially copy protection features (including protection against the manipulation of software, serial number, hardware key, date checks and disc checks) or software annoyances like nag screens and adware.”
First step: Think like a user.
This entails understanding the program itself, in its unmodified form. For example, this could be a piece of software with a 30-day full-featured trial, and once the trial period is over the software application no longer functions. Before someone develops a crack, they often need to understand what undesirable features are present or what features are left to be desired. Adding features is usually called “modding”, which is significantly harder than “cracking” (disabling certain features).
Hypothetically, if a cracker is trying to circumvent a license for a game, she might have to buy the game for herself and beat the game from start to finish to try and understand what a “full-featured” system looks like.
Second step: Think like an architect.
Specifically, the cracker puts herself in the mindset of the application engineer in order to try and guess how the undesirable feature was implemented. For example, a naive implementation of a 30-day trial software might add a key-value to the Windows registry (if running on Windows OS), and — at startup — check if the current timestamp is older than the registry value by less than 30 days.
This forms the basis of how the cracker will approach the problem. Some simple tests the cracker might perform is to see if simple hacks like wiping the registry value or setting the clock back in time can bypass these features.
Third step: Think like a mechanic.
Reverse-engineering a piece of software is very much like taking a car apart and putting it back together with a blindfold on - you’re not even exactly sure what car model you’re disassembling, but you roughly know how a car works and can feel with your hands what pieces connect to each other, what parts are critical for the car to function, etc.
Technically, all you need to crack a piece of software is a text editor that can edit hexadecimal values in a binary (Hex editor software is well-suited to this). Cracking a piece of software ultimately boils down to overwriting a few choice bytes in a binary.
However, it’s nearly impossible to understand a complex binary by simply looking at hex values, much less modify it. So software like disassemblers (otool, Ida Pro, etc.) and runtime visualization tools (BinaryAnalysisPlatform/qira) can help visualize/inspect higher-level representations of the program, so the cracker can figure out what’s going on inside a program.
Some more popular tools:
- Metasm: https://github.com/jjyg/metasm/
- Radare: http://radare.org/
- Capstone: http://www.capstone-engine.org/
- IDA: https://www.hex-rays.com/product...
- Hopper: http://www.hopperapp.com/
- Panopticon: das-labor/panopticon
- OTX
- Medusa: https://github.com/wisk/medusa
- x64dbg: http://x64dbg.com/
- Bindead: https://bitbucket.org/mihaila/bi...
- binaryninja: https://binary.ninja/
This step is by far the hardest, as often there will be a number of safeguards put in place by the program that make it difficult to simply delete calls to “checkIfLicenseIsValid()”, such as prodigious use of md5 hashing + code obfuscation to verify the entire program has been left unmodified.
The security research and reverse engineering fields are continuously innovating to out-maneuver the other, and that’s part of what makes the reverse engineering field so interesting.
This step takes a long time. At my day job, it’s hard enough reading hundreds of lines of code written by someone else with documentation and architectural reference, much less read code that lacks documentation and has been deliberately obfuscated into a very-hard-to-read symbol table. Crackers usually are very patient and thorough, and spend an unreasonable quantity of time to achieve their results (they don’t just do it for fame and glory, but also the thrill of solving a complex “puzzle”).
Incidentally, I’ve found that reverse-engineering code is really good for practicing the scientific method. It’s almost exactly like the empirical research one finds in biological/wet-lab research, where scientists have a complex system (an organism) that they try to take apart and put back together without an instruction manual. Even the 3 steps I mentioned have biological analogues. An example:
- User: Observe that lobsters can live a long time, rarely suffer from aging-related disorders like cancer.
- Architect: Wonders how cancer-resistant aging is handled in lobsters. Hypothesize that lobsters have some robust telomere-lengthening mechanism, or perhaps a more stable DNA replication strategy that prevents carcinogenesis even if telomeres get too short.
- Mechanic: Use all tools at one’s disposal to test the above hypothesis.
A couple of years ago I wrote a simple tutorial: Reverse-Engineering Apps: a Step-by-Step Beginner's Guide that goes through this process. It wasn’t sophisticated or particularly impressive, but it goes through the process I just described in an end-to-end fashion.
This question originally appeared on Quora - the place to gain and share knowledge, empowering people to learn from others and better understand the world. You can follow Quora on Twitter, Facebook, and Google+. More questions: