3 ms·

I remember cracking Teenage Mutant Turtles and IBM Writing assistant just with the "debug" tool provided in the standard MS-DOS. It definitely took half an hour

by wiz21 12y ago

I remember cracking Teenage Mutant Turtles and IBM Writing assistant just with the "debug" tool provided in the standard MS-DOS. It definitely took half an hour or so. The tests were very dumb, that's for sure. Just replacing a "JE" by "JNE" or something like that would do the trick. I also cracked Ultima 6. That took me 3 days of intense work. The protection was hidden in the dialog engine. So you were not seeing the actual code, but the interpreter of dialogs actually interpreting the protection in the dialog engine (that was a super simple interpreter, more like a state machine). In the end, it was just a matter of understanding the dialog data and extracting the answer to the protection question ("on page 34, what is the third word ?"). I also cracked some football game by writing a program that would intercept disk access and the replay the disk-errors to cheat it. An emulation layer if you like. The games that I've never cracked were Elite 2 frontier (the damn thing had checks all over the place and that was too hard); "le manoir de mortevielle" had super nasty decryption stuff. IIRC they were running decrypting code inside the interrupt table (so if you had to use the keyboard or timer to trace the code, then woosh :-)). I also went mad on Leisure Suit Larry were the protection was written in an interpreted language. At that time I was 16 or 17 and had no idea of what an interpreter was = >I've never understood the scheme :-( You had also games with special messages in it such as "we worked very hard on this so don't crack us). But the best thing I've seen is when I've tried to look into a already cracked game .the previous hacker Mr. Detergent I think, send a message along the line of "you're weaker than me". I Was sooooo upset :-) I guess I cracked 20 or 30 games on PC. Most of them were very simple. But in the end things were getting harder. I had to use the Soft-ICE debugger (massive thing :-)) and then, well some had these hardware debugger and came the protected mode and, well, I got lost and started working on more creative stuff (Imphobia if one remembers :-)) stF

stevekemp 12y ago
Having code run in interrupt routines reminds me of some of the hardest stuff I ever had to touch in the 8-bit days. In the Z80 processor there is a magic register, the R-register, which has a value which increments magically after each instruction has executed. It is possible to calculate how much it goes up by, for example "XOR A" increments R by one, but "LD IX,23000" increments R by two. If R is given a predetermined value at the start of the protection system, its value is known after every instruction until the loading system starts. This was used in many of the protection routines on Spectrums, usually as part of code that would decrypt routines, and it was a pain for the same reason that the interrupt would have been - if you're in a debugger you mess up the global state of that register.
- wiz21 12y ago
  I just can imagine :-) I also learned after that some protections used undocumented processor instructions or edge cases of some... But back in the days, you had no internet, access to documentation was not easy esp. if you were young... So although I regret the lack of friends-like-me by that time, I also appreciate the various tricks of the trades that I've learnt then... Now I write python... That's much easier but it makes programming so much more mundane. Bah, another time, another story :-) stF
- to3m 12y ago
  This was on occasional occurrence on Acorn's BBC Micro, which was 6502-based and had a 16-bit free-running timer. There were a number of then-little-known details of the 6502's operation and the interaction between the 1MHz timer clock and the 2MHz CPU clock that made it difficult to predict what the hell was going on (on top of the usual code obfuscation tricks). Interesting thread - well, for former BBC Micro programmers perhaps! - on the topic: http://stardot.org.uk/forums/viewtopic.php?f=1&t=696 http://stardot.org.uk/forums/viewtopic.php?f=1&t=696
  - makomk 12y ago
    That is an interesting copy protection scheme, partly because it'd probably be a criminal offence to write anything like it these days. It contains code intended to silently reformat whatever's in the floppy drive if any of the checksums fail - something that could easily happen if the tape or hardware's even slightly flaky - and because genuine copies are loaded from tape that's going to be an unrelated floppy, quite possibly one with important data on it.

by wiz21 12y ago

stevekemp 12y ago

Having code run in interrupt routines reminds me of some of the hardest stuff I ever had to touch in the 8-bit days. In the Z80 processor there is a magic register, the R-register, which has a value which increments magically after each instruction has executed. It is possible to calculate how much it goes up by, for example "XOR A" increments R by one, but "LD IX,23000" increments R by two. If R is given a predetermined value at the start of the protection system, its value is known after every instruction until the loading system starts. This was used in many of the protection routines on Spectrums, usually as part of code that would decrypt routines, and it was a pain for the same reason that the interrupt would have been - if you're in a debugger you mess up the global state of that register.

wiz21 12y ago
I just can imagine :-) I also learned after that some protections used undocumented processor instructions or edge cases of some... But back in the days, you had no internet, access to documentation was not easy esp. if you were young... So although I regret the lack of friends-like-me by that time, I also appreciate the various tricks of the trades that I've learnt then... Now I write python... That's much easier but it makes programming so much more mundane. Bah, another time, another story :-) stF
to3m 12y ago
This was on occasional occurrence on Acorn's BBC Micro, which was 6502-based and had a 16-bit free-running timer. There were a number of then-little-known details of the 6502's operation and the interaction between the 1MHz timer clock and the 2MHz CPU clock that made it difficult to predict what the hell was going on (on top of the usual code obfuscation tricks). Interesting thread - well, for former BBC Micro programmers perhaps! - on the topic: http://stardot.org.uk/forums/viewtopic.php?f=1&t=696 http://stardot.org.uk/forums/viewtopic.php?f=1&t=696
- makomk 12y ago
  That is an interesting copy protection scheme, partly because it'd probably be a criminal offence to write anything like it these days. It contains code intended to silently reformat whatever's in the floppy drive if any of the checksums fail - something that could easily happen if the tape or hardware's even slightly flaky - and because genuine copies are loaded from tape that's going to be an unrelated floppy, quite possibly one with important data on it.