dave@interlan.Interlan.COM (Dave Goldblatt) (02/25/91)
In article <1991Feb25.054200.4817@uokmax.ecn.uoknor.edu> norlin@uokmax.ecn.uoknor.edu (Norman Lin) writes: > Indeed so; I used to create bad sectors by using a simple USR call to the > resident disk handler to write a sector, and while it was writing the sector > I wedged a piece of folded paper in between the diskette jacket and the top > of the drive slot, so that the increased pressure on the diskette would bring > it almost to a stop. I'm sure it did wonders for my diskette, to mention > nothing of the disk drive motor... but it did create bad sectors by altering > the RPM in a very crude manner. What I am still not quite sure about is -- > why does altering the speed create bad sectors? That was the oldest (and just about the easiest) way to create a hard bad sector on the Atari. One of the oldest programs I saw to do it (I think it was for sale in ANALOG for $30) said to put a piece of masking tape on the disk, close the drive door with the tape hanging out, and when prompted, to pull on it (as it kept writing out that particular sector). High tech. The easiest (and safest) was to do it was to pop off the cover of the drive, find the speed adjustment screw, and to crank down the speed of the drive (to around 270RPM), write the sector, then bring the drive back up to speed. Essentially (if I can remember my 810 schematics and operation), what happens is this: During normal operation, the write head is only activated for a very precise amount of time -- just long enough to write a particular sector. If it is turned on for any greater length of time, it will continue writing on the next sector(s). The trick to writing a bad sector was that when you slowed down (or sped up) the speed of the drive, the write operation occurred outside the olerances on the disk (either the sector wasn't long enough, or too long). For the most part, Atari drives couldn't handle illegal sectors, which is why you'd hear the head banging around as to tried to read the sector again. > Very interesting... "plain ol' unreadable sectors" had occurred to me, as > they were the most obvious to detect, but short sectors and duplicate sector > headers... What would duplicate sector headers do? Short sectoring seems > quite ingenious too, though how could you tell how much "valid" data was > read? Let's say you're using SIO to read a disk sector into memory, and > only 100 bytes are "valid"; what would the rest of the target buffer in RAM > contain? Garbage? Unchanged? Zeroes? The original form of copy protection on the Atari was the standard hard-error bad sector. That was one MAJOR difference between the Atari and the Apple II. The Apple disk controller was in the machine itself, and subject to complete software control. The Atari controller, on the other hand, was inside the drive. Because of this, only specified operations could be performed on the Atari, and thus modified disk formats were very difficult. That is, until the advent of modified disk controllers, of which the Happy Drive was the first. Another one, called "The Chip" was a drop-in replacement for the Atari disk controller. The Happy drive was actually an additional logic board which provided even more capabilities than The Chip. It buffered reads by track, for example. Duplicate sectors were fairly neat. What happened was two identical sector numbers would be written onto the disk, but with different data within the sector.. When the program called for a disk read on that sector number, one of those sectors would be read in -- but which one depended on where the disk head was currently located! So the test was (a simplified example) to read in sector 7, then sector 8 (the duplicate sector), then sector 10, then sector 8. Then compare the two reads from sector "8". If it was the original disk, you'd see different data. Short sectors were fairly simple to check for as well. You'd initialize a 128-byte block of memory to a value (arbitrarily assume 0x55), then read in the known short sector. If all 128 bytes were altered, you'd know the short sector didn't exist. SIO would only copy the data it could read into RAM. If you just did a straight disk copy on a short-sectored disk, those sectors would (usually, depended on your copy program) read back zeros in the copy of the unused area on the original (i.e. if the sector on the original had only 50 bytes of data before the end-of-sector marker, and you make a sector-by-sector copy with SIO, the duplicate sector would have 128 bytes on it, and thus when that sector was read back in, the buffer you had allocated would change). > As you said, how this brings back memories. :-) I recall one time > disassembling the code to some game (forgot what it was) to see how the copy > protection worked. It was incredible how almost incomprehensible the code > was; 25 or so pages of self-modifying, self-decrypting, partially-resident- > and-partially-loaded-from-disk security checking. Pretty clever, these > copy-protectors... One of the more interesting programs I saw had a one-sector boot loader, which then loaded another loader sector by sector, XORing all of the data in each sector with an incrementing count and the sector number. Normally, just XORing the data with an incrementing count was standard, and this particular one was a tough one to figure out (it was self-modifying as well). But since every program HAD to have just one normal, executable sector (the boot sector), everything else could be derived. :-) -dg- -- "Hey, Copperfield! * Dave Goldblatt [dave@interlan.com] Suck on this!" * - Penn Jillette, of * (No longer working for, or Penn & Teller * representing Racal InterLan, Inc.)
wilmott@utopia.rutgers.edu (Ray Wilmott) (02/28/91)
-- >It was incredible how almost incomprehensible the code was; 25 or >so pages of self-modifying, self-decrypting, partially-resident and >partially loaded from disk security checking. Pretty clever... Reminds me of the time I tried to decode Alternate Reality (still my fave Atari game...anybody still into it?) The City way back in '84 or so. Aside from wanting to "crack" it to make a backup, I mainly wanted to cheat and get a looksy at the imbedded text blocks of the game. The copy protection started by looking for a flawed sector. Easy to take out. Then there was the loading and decrypting of a few sectors (load 'em, EOR each byte with some number and store the result somewhere, then jump and execute the resulting code). Cute, and again pretty easy. Then that resulting code used a chained decryption scheme on a bunch of other sectors (read a byte from disk, EOR it with some memory location, add something else to it, EOR it with something else, then store the result in a memory location based upon some formula, then execute the resulting code). This one was annoying, but do-able. This chunk of code then did the same sort of thing, but with a much more complex set of formulas to decrypt and lots of jumping back and forth between subroutines. What a mess. I gave up. Kinda strange that they'd go to such lengths to more or less annoy hackers and pirates (ie-rather than just go all out to start with, they start simple and draw you into each more complex level of protection). BTW, did anyone out there ever "crack" this game and extract the text encrypted within sides 3 and 4 of the game? If so, I'd love to hear from ya...always wondered if there were more hidden things I hadn't discovered within the game... -Ray
wilsont@mist.CS.ORST.EDU (WILSON TIMOTHY EDWARD) (03/01/91)
In article <Feb.27.21.18.09.1991.2156@utopia.rutgers.edu> wilmott@utopia.rutgers.edu (Ray Wilmott) writes: >4817@uokmax. > >-- > >Reminds me of the time I tried to decode Alternate Reality (still my >fave Atari game...anybody still into it?) The City way back in '84 > > > -Ray I still play it every now and then. I was however disapointed when "the dungeon" came out..the graphics were horible and it seemed impossible to play..also..you couldn't return to the city.. I have a happy drive and when backing up disk 1 side 1..it showed you a bunch of wierd stuff.. tracks with 8 ,16, if think there was a 31 sector track or something. It could only e used on a happy drive since the drive programmed itself to do all the wierd stuff...and it was wierd! have you booted side 2 of disk one? I also tried manipulating my character..but never found the name..so i started trashing sectors ..but i never found it even that way and gave up.
fseipel@hpuxa.ircc.ohio-state.edu (Frank E. Seipel) (03/01/91)
There seem to be so Alternate Reality players on here, but did any of you ever try the Ultima series? I think I still have a text file describing what each byte on the disk mapped to (for Ultima III), that is, a character set; there was a byte to represent a lock, a guard, a wall, and each letter of the alphabet. It was fun to change HOTEL CALIFORNIA and other large text (16 x 16 bit) in Ultima II to other sayings. And of course to change the character attributes. When I purchased Ultima II, the game had a bug -- you couldn't find the blue tassles which allowed you to command a ship, so disk editing was mandatory.
norlin@uokmax.ecn.uoknor.edu (Norman Lin) (03/01/91)
wilmott@utopia.rutgers.edu (Ray Wilmott) writes: >The copy protection started by looking for a flawed sector. >Easy to take out. Then there was the loading and decrypting of a few >sectors (load 'em, EOR each byte with some number and store the >result somewhere, then jump and execute the resulting code). Cute, >and again pretty easy. Then that resulting code used a chained >decryption scheme on a bunch of other sectors (read a byte from disk, >EOR it with some memory location, add something else to it, EOR it >with something else, then store the result in a memory location >based upon some formula, then execute the resulting code). This one >was annoying, but do-able. This chunk of code then did the same sort >of thing, but with a much more complex set of formulas to decrypt >and lots of jumping back and forth between subroutines. What a mess. >I gave up. I have an Atari 800XL, and one major advantage of having an 800XL over a 400 or an 800 is the replacable O.S. One time I loaded in the Translator, thereby giving the old OS with the 4K section $C000-$CFFF free (since the old OS didn't use it). What's great is that now the NMI (non-maskable interrupt) vectors are in RAM, too. So I hooked into the NMI a routine to dump all memory to disk when I pressed a certain key combination. The routine itself was stored in the unused $C000-$CFFF region, known to be safe and free (much safer than, say, page 6!). Then, after doing this, I'd make a call to $E477 to reboot the computer then boot up a piece of software. After it loaded I'd replace it to disk and press the key combination to dump it all to disk. I had to save the PC (pushed onto the stack as with all interrupts) and all registers. What was tricky was how to load the thing back into memory; you had to restore the PC and the stack and all kinds of things like that that could quite easily disrupt the loader program itself. Bottom line is, it worked for some simple non-graphics oriented stuff, but didn't work for any games. Reason? The hardware registers, the strange little region $D000-$DFFF. Many (most?) of these locations are not the same when you write to them as when you read them. (And of course since many commercial graphics-oriented programs do away with system VBIs, shadow registers are useless, too.) Thus, for instance, P/M graphics could be initialized, but by saving the contents of location $D01D I wasn't saving the state of the P/M enable port but rather getting the status of some totally different input port. I never found a solution to this so abandoned this project. As a matter of curiosity *is* there any way to totally save the current state of an Atari, including all the changes that have been made to the hardware registers? Still, though, if you have an 800XL you can hook in some pretty neat NMI's into the O.S. that will let you, for instance, cheat on games. One that I once had constantly stored 0 into HITCLR (forgot the memory address, but that's the location that clears the registering of P/M collisions) unless you pressed a certain key or moved the second joystick or something similar, so that any game that involved P/M graphics would never register any collisions. Useful for getting to the end of some games. Just more ramblings from an old hacker... ---|\-#-/_|-------/|-------,*.----||---Norman Lin, University of Oklahoma---- ---|/-----|------/-|---,"--|---,"-||------norlin@uokmax.ecn.uoknor.edu------- --/|------------/-*'---|/------|--||-----(IP addr: 129.15.[20|22|24].2)------ -|/|\---/_|-----|-----------------||-"I gazed in your eyes, and saw the moon- --\|/-----|----*'-----------------||------------and the skies"---------------
wilmott@utopia.rutgers.edu (Ray Wilmott) (03/02/91)
---
>I also tried manipulating my character but never found the name...
Yeah, I spent much time trying to alter my characters' attributes
as well. I did manage to "map out" the character disk after a bit
and find out that such and such a byte on sector x represented
how much food you had, etc. Problem was I couldn't edit it even after
finding it because the program used some sort of checksum and if
you messed with anything, your character either ended up dead or
diseased. About 2 years ago I did find a character cheater program
(one for the City, and one for the Dungeon) on a local BBS. Worked
great...alters all stats, lets you "transport" to any location
(including "secret" locations that the programmers locked you out
of by not making any doors into the area), adjust the time, etc.
The only thing I haven't found out about the game is how to decode
the text strings buried on the disks...
-Ray