Reverse engineering has been a constant interest for me but I've never managed to get it to "click" for me. I don't particularly need the skill, but it's one I'd like to have (at least to the extent of being able to do simple crackmes).
My earliest exposure to computers was the ZX Spectrum, an 8-bit home-computer from the 80s, which was insanely populare in the UK.
Having few games, and little budget for more, most of the kids around would swap home-copied games. I used to have fun removing protection, or hacking the games for infinite lives. At the time I was 12-15 and it was very much a case of trial or error.
Assuming a game started with 3 lives I would look for every occurance of "LD A,3", and change the 3 to 5. If that didn't work I'd eventually replace every occurance of 3 with a different number. As you can imagine this was a tedious process!
If I was lucky enough to find the right "starting value" I'd then go on to look which memory-address the value was saved in. That would then let me search for that same address in the rest of the program, and hopefully spot something like:
LD A,(addr)
DEC A
LD (addr),A
At that point I was done. Removing the decrement would stop the lives-counter from being decreased - giving you as many as you wanted.
Later I moved to the PC, and I found +fravia's site very educational. There are still mirrors which show how you could remove protection from commercial software - and oftentimes I'd be reminded of my previous attempts. Sometimes it is very simple, and sometimes not. Educational regardless.
The main reason I stopped this work? Few programs on Linux prompt you for license keys! But a good disassembler is a worthwhile thing to explore, whether for debugging your own code, or randomly exploring crackmes.
My first and only hacks were at the age of 12 where i "patched" the copy protection keywords from the first XWing in 1993 [0].
I only knew 1 password and searched for it in a hex editor. I found it and recognized a pattern with similar words.
Replacing them with the Ascii Space resulted in "press return to pass" password checks :D Damn i was proud.
At the same age, i rewrote the Story Text of "The Adventures of Robin Hood" (1991)[1] via hex and "Try and Errored" all Ascii combinations to develop my own Ascii chart.
You can imagine what a 12 year old rewrote a love story to... my older brother was quite happy :D
I later tried to patch Dune2 Level files to create my own but did not understand a thing.
Now i write medical software and sometimes feel the same ;)
My enjoyment of fravia's philosophizing led me to try my hand at the crackmes and other stuff. I could get a few but never really got the hang of it, it was a great educational exercise.
I highly recommend anyone who's interested (particularly people who don't remember a pre-Google, pre-Facebook internet) in bold (and crazy) ideas about technology reading his work.
Edit: I suppose many if not most of the essays aren't strictly "pre-Google" but they are from its much earlier days when it was a very different service.
Random aside: I'm constantly impressed by the output of the HCU folks and sorely wish that both the community around HCU and +Fravia were still around.
It's a tricky art. It's helpful to learn some of the basics such as how variables are passed to a function on the stack for x86 or as registers with x64. Beyond that it takes practice. Things that have helped me are writing c code and dissassembling it, stepping through code with GDB and working on crackmes and CTFs.
Yeah, writing simple C programs using various constructs (switch/if/for statements, structs, different APIs, etc.) and then looking at the produced assembly is a good way to learn.
Another thing I like to do is to rewrite complex parts of the disassembly in pseudo-C (though radare has an option to do this automatically), which makes the overall logic easier to see (and is, of course, the entire point of decompilers like Hex-Rays).
This works. Be sure to try different compilers and optimization levels.
You can become a better programmer this way. You start to get a real feel for what the compiler can and can't optimize. For example, you can see how a do...while loop is usually the best kind of loop, but without seeing the assembly you might assume they are all the same.
