Obfuscated Software?

[jhd]

I just found an interesting, if unsourced, claim in Wikipedia:

 

"In the 1980s when computer gaming came into being, many hardware game cards on ATARI and other machines implemented obfuscation techniques in order to keep the games from being reverse engineered."

 

This seems unlikely, given the widespread "recycling" and even outright copying of code between and across game companies; for example, look at the huge number of Asian-produced pirate cartridges.

 

Would using unusual bank switching techniques be considered a form of obfuscation?

[Alp]

That's funny, because I'm pretty sure that pirates have actually done more to prevent piracy. Look at Earthworm Jim on the Famicom.

[Kylearan]

Obfuscation was used for games on traditional computers like the Apple II or the C64 as a counter-measure against piracy; I've seen titles from as early as 1982 that were heavily obfuscated, and I guess there are even older titles that used that technique. Same for even older arcade machines. But obfuscation techniques like semantic NOPs, jump into the middle of instructions, opaque predicates, VM packing etc. always come at the expense of ROM, heavily so if they should be actually useful. Other techniques, like decryption on the fly, need RAM. Both ROM and RAM are very scarce resources on the VCS, so I heavily doubt they were used back then.

 

 

 

This seems unlikely, given the widespread "recycling" and even outright copying of code between and across game companies

Note that obfuscation techniques can only make reverse engineering harder, not outright prevent it. There are games on the C64 or Apple II that use an INSANE amount of layered obfuscation techniques, and they were always cracked regardless. Same with modern PC games or obfuscated malware. Obfuscation can only slow down a dedicated reverse engineer.

Edited January 8, 2016 by Kylearan

[Kylearan]

For those interested, here's a write-up (not by me!) of cracking the obfuscation techniques for a 6502 version of Burger Time from 1982 (cracked in 2015 ): https://ia801505.us.archive.org/33/items/BurgerTime4amCrack/BurgerTime%20(4am%20crack).txt Some techniques I mentioned above are used there: Jump into middle of instructions, opaque predicates and decryption on the fly.

Edited January 8, 2016 by Kylearan

[Thomas Jentzsch]

I have disassembled a number of old Atari 2600 games and there is also some original source code available. But I haven't found any intentional obfuscation. However there exist some optimizing tricks (e.g. using BIT to skip the next instruction), which may look like obfuscation.

[Kylearan]

Yep, tricks like having several "cmp #$c9" instructions to use as a slide to jump into for cycle-exact kernel positioning, are also very similar to some obfuscation techniques, and in fact often confuse disassemblers in a similar way.

[raindog]

Fixed the Wikipedia article... in addition to being unsourced, I really don't think a reference to software obfuscation should be one of the two historical points offered for hardware obfuscation. The article as a whole could use some help, but it probably requires a hardware greybeard, not a software one.

[awhite2600]

For those interested, here's a write-up (not by me!) of cracking the obfuscation techniques for a 6502 version of Burger Time from 1982 (cracked in 2015 ): https://ia801505.us.archive.org/33/items/BurgerTime4amCrack/BurgerTime%20(4am%20crack).txt Some techniques I mentioned above are used there: Jump into middle of instructions, opaque predicates and decryption on the fly.

 

 

I skimmed through the article in the link. Wow, did that take me back. I was a C-64 guy - so most of the Apple ][ references in the article were too foreign to understand. I cracked quite a few games in the C-64 era. I had a bunch of self developed techniques that I used over the years. One of my favorites involved intercepting the communication between the C-64 and the 1541 disk drive. Many games would load normally (encrypted or not) and then "talk" to the disk drive to execute the copy protection. I would insert code into the original loader to save this communication to RAM when an original disk was used. I could then substitute a modified loader on the cracked copy to load the saved communication and "play it back" when an unprotected disk was used. This method worked very well on quite a few games. Sometimes a few other techniques were required if the programmer used additional protection methods.

 

My favorite trick when stumped by someone else's code was to take a break and walk my dog. It was amazing how much I would figure out by taking a 15 minute break in the fresh air.

 

My days of cracking came to an end around the time that most C-64 games moved from a fairly standard disk format to custom formats. It wasn't that I couldn't crack that type of protection. I just graduated school, had a full time job and got bored with cracking games.

[Kylearan]

I was a C-64 guy

Me too. And the 6502 and 68000 reverse engineering/cracking and assembly skills I acquired back then now serve me well when analysing Windows malware or exploits.

 

My favorite trick when stumped by someone else's code was to take a break and walk my dog. It was amazing how much I would figure out by taking a 15 minute break in the fresh air.

Absolutely! That works for almost any area. Just yesterday I went back to optimizing my VCS music player after leaving it for a couple of days to get some creative distance, and lo and behold! I was able to shave off another 8(!) bytes, even though I previously thought this impossible.

[Thomas Jentzsch]

Me too.

Same here. I got there from trying to patch already hacked games for extra or unlimited lives.

 

Later I cracked a game I already owned (Thrust), just for the sport of doing it (and faster loading times).