leed@orstcs.UUCP (05/16/84)
<Hi There Crypto-Nuts> I would like to stick my neck out and talk about a specific cryptographic system. I speak of the system the Fortune 32:16 uses for encrypting their software releases. I have recently been playing with a 32:16, and have, just for the fun of it, been trying to decipher their coding scheme. So far, I have discovered the following: 1. The only files encoded on the disk are the object files. All others are normal un-encrypted ascii. 2. The disks are just file systems - i.e. all that's needed is to mount them 3. The encrypted object files do NOT have the exec header encrypted 4. The encryption scheme is NOT trivial. Beyond this, I only speculate, but my speculation leads me to believe that the encryption scheme uses either crypt(1) or some already UN*X resident equivalent. I have not been able to spend as much time as I would like attempting to break this code, but I intend to figure it out, if possible. I am NOT a cryptographer (although I continue to learn more about this), and would appreciate any help I can get from out there. So far, my plan of attack is to try using the vanilla crypt(1), trying different 'keys'. Let me state my disclaimer: I do NOT wish to steal Fortune software in any way, shape, or form, but I DO resent software companies in general that think that they can encrypt or otherwise restrict software. As a simple example, the 32:16 I work on belongs to someone with two of them, and, using Fortune's scheme, they would have to buy TWO sets of software!!! (what a rip) Doesn't Fortune make enough $$$ on their software anyway. (I'm sorry! Flame OFF!). Fortune people, I'm sorry, but if you put a puzzle in front of people, they'll try to solve it! For Fortune's sake, please reply (if at all) through mail, as I'm sure they don't want everybody knowing these things (they'd probably prefer NOBODY)! Thanks in advance (I hope) )M-^Y^^M-NM-\M-ZM-W^VzM-8M-p (That Lee Duncan, crypted with Lee Duncan) AKA : ...!hplabs!hppcd!orstcs!leed (:-:)
gnu@sun.uucp (John Gilmore) (05/22/84)
The first place I would look is in the object code of the program that decrypts their releases. Why go for a random soultion when you have an algorithm (for a 68000)? Pay the extra $400 or whatever to get adb and go to it! PS: This is a preferred method for copy protected disks too. You also find out interesting coding techniques and security tricks. While decoding a "guaranteed absolutely unbreakable" game I thought up (and invented ways around) four or five fiendish security tricks that they hadn't even used!
olson@fortune.UUCP (05/25/84)
#R:orstcs:1464966996:fortune:26600006:000:1227
fortune!olson May 24 18:24:00 1984
Speaking as the current person in charge of software protection at
Fortune, I don't think you'll be able to manage it (at least for our
more recent products!) I've heard rumors that various people have
broken our protection algorithms, but have yet to see concrete proof.
If you do manage it, send me the algorithm or clear text as proof.
I will say that I personally (NOT Fortune Systems!) feel that it would
be better to allow sharing of software, and charge for support, updates,
and documentation, since that is where the real costs are.
(I should mention something which has been pointed out before:
possession [AND DISTRIBUTION!] of decrypted Fortune software is probably
evidence enough to go after people on legal grounds; no one expects that
any software protection scheme is unbreakable. What Fortune (and other
people) are after is a way to show that someone made a significant
effort to pirate our software. Note the 'AND DISTRIBUTION' above;
possession alone is probably legal...)
Dave Olson, Fortune Systems
UUCP: {ihnp4,ucbvax!amd70}!fortune!olson
ARPA: amd70!fortune!olson@BERKELEY
Note: The above is my personal opinion, and does not constitute
the policy or opinions of Fortune Systems Corp.