Author: Bill Collins (209-250-50-59.wispnet.net)
Date: 02-23-2010 10:39
Over the years, many techniques have been employed to obscure/hide the basic source code. (Replacing the variable_name_table with weird bytes, compiling, etc.)
There's an atari disk called "Pirates Treasure Chest" which has details on how to break those techniques, including a utility to replace the variables in the variable_name_table back to something human-readable. Any search for this ATR image will yield a downloadable copy. The documentation that accompanies that disk is worth reading.
Most compilers use pseudo-code, converting basic into tokens, which can be reverse-engineered from the tokens back into the original basic. Writing in direct assembly language is even more obvious, as the 6502 opcodes "are" the source code. The only hope to obscure your code is to use a compiler that converts to true binary, and to occasionally place weird/useless statements in your source code, and use ridiculous branching and unnecessary variable references. This is basically writing spaghetti code, and employing every bad design technique that your pascal/fortran/cobol teacher in college told you never to do. :)
Look at how the pompey pirate/automation CD's were made for the atari ST: They decompact before they run. Just place an assembly routine at the front of the program that decrypts the real code and then does a branch to the code after it is decrypted. An emulator with a "save state" function could then save the contents of ram (all 64k of it), which can be examined with a hex editor later, so even that method has vulnerabilities.
I just realized that I'm writing at 3am about security measures for obfuscating source code on an outdated, 30-year-old, 8bit operating system....This antiquated stuff means more to me than dhtml/java/css, blog monetization, page rank, and ad revenue...No wonder I'm behind the times.
|
RE: Compiling Atari Basic on XL.