+CharlieChaplin Posted May 17, 2009 Share Posted May 17, 2009 (edited) Well, interested in copy protection ?!? Here is some old text I downloaded from ATP, since I have not visited their site since 2004 there might be a newer version available (if the site still exists). Probably some of the AR protection schemes are missing in this text, anyways, here it is: -Andreas Koch. ------------------------------------------------------------------------- Atari Protected Disk Image Format Version 1.6 Date 2004-4-11 Authors ATP Working Group 1. INTRODUCTION TRACKS SECTORS 2. SECTOR STATUS ERRORS SECTOR OK DATA CRC ERROR RECORD TYPE "DELETED" RECORD TYPE "DELETED" + CRC ERROR LOST DATA LOST DATA + CRC ERROR LOST DATA + RECORD TYPE "DELETED" LOST DATA + RECORD TYPE "DELETED" + CRC ERROR RECORD NOT FOUND RECORD NOT FOUND + HEADER CRC ERROR 3. DOUBLE SECTORS 4. SECTOR TIMING SECTOR SKEWING TRACK SKEWING SECTOR INTERLEAVING REFERENCE SECTOR 5. WEAK DATA WEAK HEADER WEAK SECTOR DATA WEAK DATA IN ATP 6. TRACK DENSITY CHANGE 7. ATP FILE FORMAT ATP FILE ATP DISK DATA ATP HEADER ATP TRACK ATP SECTOR ATP CRC ATP TIMING DATA 8. REFERENCES 9. HISTORY VERSION 1.6 1. Introduction Why do we need the ATP format? The current format for Atari 8-bit disk images is ATR. With this format it is not possible to store copy protected disks. The new ATP format should make this possible. So, what about the APE PRO format? Thus far it seems that the author of APE will not release any information about his 'PRO' format. Therefore we're simply forced to develop our own format. We probably need more supported protection features and since we propose an 'open' format this will be possible. PRESERVE ORIGINALS! Some disks are around 20 years old and who knows how many original copies or backups (original backups!) there are? It's time to make good copies where possible. With the ATP we will be able to store these copies on modern media. This is not an easy task, since many different copy protections are invented during the years. Not to mention the copy-programs which can make copies of protected disks, but not of the copy-program itself! Tracks Each disk contains a number of tracks. On the Atari drives the track number ranges from 0 to 39. The disk drives use the so called soft sectored disks. This means that a track can be seen as just one long data stream. With help of markers the FDC knows where to find the right sector data in this stream. In general a track looks like this: Start of track: Marker | Index mark Gap #1 | Post index mark NOTE: The XF551 & 1050 both ignore the index (if written to disk) First sector: Gap #2 | Pre address mark Marker | Address mark Data | Sector header + CRC Gap #3 | Post address mark Marker | Data address mark Data | Sector data + CRC Gap #4 | Post data mark The first sector is followed by the rest of the sectors which all have the same structure as the first sector. Note that the first sector doesn't have to be numbered as sector #1. Sectors A disk sector consists of the following three parts: - Sector header field (also called 'address field') . Gap bytes (should be at least 4 Bytes in SD, 8 Bytes in MD/DD) . Header mark (also called 'address mark') . Track number (0 - 39) . Side (0 or 1) the sector belongs to (the FDC ignores this byte) . Sector number (also called 'sector id') . Sector size (0=128, 1=256, 2=512, 3=1024 Byte) . Two CRC checksum bytes (used by the FDC to check the last 4 Bytes) - Sector data field (also called 'data field') . Gap bytes . Data mark . Sector data (SD/ED: 128 Bytes, DD: 256 Byte) . Two CRC-Bytes (used by the FDC to check the sector data) - Gap . Gap bytes until the next sector 2. Sector Status Errors After reading a protected sector, the status command returns the Floppy Disk Controller (FDC) status byte for the last read/written sector. A perfectly good sector has a status of $FF. The status byte can then be checked for error bits to identify the protection. Sometimes the sector data is also verified. Each bit of the FDC-status byte is low active and has the following meaning: Bit 7: /DOOR No Disk in drive (NOT valid on XF551 drives) Bit 6: /WP Write protected (valid only after a write command) Bit 5: /RT Record Type "Deleted" in the sector header field (address field) Bit 4: /RNF Record not found (sector not found) Bit 3: /CRC Checksum-Error (in the sector header or sector data field) Bit 2: /LD Lost data: the drive-CPU didn't send/receive all data to/from the FDC Bit 1: /DRQ Data request: the FDC asks for a byte read/written to its data register Bit 0: /BUSY The FDC is busy, the last FDC-Command hasn't completed yet For copy protection methods only the bits 5,4,3,2 are useful. The other bits are 1 after a read sector command. Bit 1 should always be 1, in combination with LD (Bit 2 = 0), Bit 1 is undefined (depends on the ROM revision of the disk drive). The possible FDC-status bytes are described below. Sector Ok This is a perfectly normal sector without error. Status: $FF (255) Data? : yes Data CRC Error The two CRC bytes of the sector data field aren't correct. This error is created by issueing a write command to the FDC and abort it before the complete sector is written. The sector data may be correct, and some programs verify the complete sector data since it is VERY difficult to abort the write command exactly when the CRC bytes are written by the FDC. Status : $F7 (247) Data? : yes Examples: Great American Road Race, track 32-39 MS Copy, sector 68 Record Type "Deleted" Also called "Deleted Data Mark". The data mark of the sector is set to "Deleted". The error can be created by issueing a write sector command to the FDC with Bit 0 set. The FDC treats a "Deleted Data Mark" not as an error, it's simply a possibility to mark sectors, so a DOS can detect if a sector is free or in use by a file. This is not used by the ATARI-XL/XE system nor PCs. Status: 223 ($DF) Data? : yes Examples: ? Record Type "Deleted" + CRC error This is a combination of a deleted data mark and CRC error. This type of error is often caused by a so called 'weak' or 'fuzzy' sector. According to the manual of the Super Archiver a 'Fuzzy' or 'Phantom' sector is "a sector in which the data does not regain constant. It will almost always carry with it a CRC error, because of the unstable data." Status: 215 ($D7) Data? : yes Examples: MS Copy, sector 67, 71 Lost Data Also called "Long Sector". The size byte in the sector header field is set to 1 or greater (meaning at least 256 Byte) on a SD/ED disk (resp. at least 512 byte on a DD disk). So the FDC will read 256 bytes or more data bytes, but the drive ROM will read only 128 data bytes, which results in lost data. In some ROM revisions the ROM doesn't reset the FDC after an error, this will result in Bit 1 (DRQ-Bit) set to zero. Therefore a program must allow $FB or $F9 or it won't work on all ATARI drives. This error must be created at format time since the size byte is in the sector header field (the sector header field cannot be modified when writing a sector). To create the sector data field without a CRC error the complete "long" sector (256 Byte) must be written by the drive ROM to the FDC. Or the drive ROM has to calculate the correct CRC. Status: $F9 (249) or $FB (251) Data? : yes Examples: MS Copy, sector 56-59, 64 Remarks: Not displayed by 'disk mapper' (a program used to analyse disks). Lost Data + CRC Error Same as "Lost Data" but the sector also contains a CRC error. The CRC part of this error is created the same way as in a simple CRC ($F7). Status: $F1 (241) or $F3 (243) Data? : yes Examples: MS Copy, sector 72 Lost Data + Record Type "Deleted" Same as "Lost Data" but the sector also contains a "Record Type" error. The "Record Type" part of this error is created the same way as in a simple "Record Type Deleted" ($DF). Status: $D9 (217) or $DB (219) Data? : yes Examples: ? Lost Data + Record Type "Deleted" + CRC Error Same as "Lost Data" but the sector also contains a "Record Type" error and a CRC error. The "Record Type" + CRC part of this error is created the same way as in a simple "Record Type" + CRC ($D7). Status: $D1 (209) or $D3 (211) Data? : yes Examples: MS Copy, sector 37 Record Not Found Also called "Missing Sector". The drive doesn't find the sector at all. There are three possible causes: - Sector not found There is no header field with the correct sector number. - Track not found A header field with the correct sector-nr but a wrong track-nr was found. - Data not found A correct header field was found but the data mark is missing. This error is created at format time by not writing the sector, the data mark or writing a wrong track number in the header field. Status: $EF (239) Data? : no Examples: Printshop, track 5 Ultra Copier, track 7-39 MS Copy, sector 73-90 Record Not Found + Header CRC Error Also called "Address CRC error" or "Sector ID CRC error". The sector header field has a bad CRC. This error is created by writing two zero bytes instead of the CRC bytes at format time. Status: $E7 Data? : no Examples: ? 3. Double sectors The sector ID can appear more than once on the same track. Often double sectors are placed 180 degrees away from eachother. That way you can read the same sector twice and get two sets of data. With the right timing it's possible to read data from multiple sectors with the same sector ID on one track. Short sectors can be used to get more sectors on a track to create complex protection schemes. Examples: Printshop, track 5 4. Sector timing Sector skewing The time between two consequetive sectors on a track is called skew-alignment. This space between sectors is infuenced by the placement of sectors on the track and the amount of gap bytes. Track skewing Since the Atari drives don't use the index hole to indicate the start of the first sector in a track, the alignment of two tracks can be different. A track skew of 0 means that the tracks are aligned, e.g. the first sector from the first track starts at the same position as the first sector on the second track. With a track skew of 180 degrees, the first sector on the second track start 180 degrees later on that track. According to the Super Archiver manual: "Skewing is the measurement of time between two different tracks. For example, if sector 1 on track 0 is located 180 degrees away from sector 1 on track 1, a program could read each sector 1, time it, and compare it to a given value. This sort of protection is used, and is quite effective against sector copiers, but not some enhancements (such as the Super Archiver 1050!). Normally what is done is to line up the first sector of each track (assuming all tracks in the skew section are the same format). The software will read that first sector of each track in a certain order, and compare it with a certain timing. For example, the same time it takes to read sector 1 on track 0 twice should be the same time it takes to read sector 1 on track 0, and sector 1 on track 1. When stepping more than 2 tracks, allowances need to be made for step rates, because certain drives step slower than others. Usually measuring the time between one track the very next one is effective enough. ... " Sector interleaving By sector interleaving sectors are placed on the disk in the most efficient order. When the sectors are positioned in a normal sequence (0, 1, 2 etc) the interleave factor is 1. With a sector interleave of 2, the next sector is placed two positions behind the first sector. Protection schemes can use custom interleaving or completely different sector layouts. With help of timing information, the original can be detected. Reference Sector Since the index hole is not used, a track has no clear beginning or end. Some protections measure the time between two sectors, but we don't know which sectors the program will check. Therefore we will use a specific sector to measure the time between this sector and all other sectors on the disk. First definition: The start of sector "1" on track "0" denotes the "virtual index hole" and serves as a physical reference position for all other sectors on the disk. There can be double sectors on the disk, but it's not likely that sector 1 - the bootsector - is a double sector (contact us if you have an example!). Just to be on the save side we will use the following definition: Final definition: The first, unique (i.e. non-double) sector on the disk (starting with track 0) is called the "reference sector". This "reference sector" serves as an absolute reference point (for all timing measurements). The start of this "reference sector" denotes the "virtual index hole". If there is no unique sector on the disk (i.e. each sector number occurs at least twice within a track), the user may choose any sector of the disk as a reference sector. 5. Weak data Some protections are based on weak data bits. These unstable bits can produce several errors when they appear in the sector header and/or corrupt data bits in the sector data part. Weak Header If the FDC cannot read the sector header correctly, the header-CRC checksum fails and the FDC will report 'sector not found'. If the header data is corrupted all the time, this will look like a completely missing sector. But if the sector header could be read correctly, the FDC will also read the sector data (without any weak bits in this case) and return 'sector read successful'. STEFAN Dorndorf: This only happens if the data CRC is correct. This very unlikely. A floppy emulator could simulate this case by randomly returning: 1) sector OK (plus valid data) 2) sector not found STEFAN Dorndorf: No, this error may be combined with Header-CRC or Record-Type status errors. FREDDY Offenga: This is not clear. Is the above simply wrong? Examples: ? Weak Sector Data In case of a broken bit in the data part, the data CRC-check will fail and the FDC will return partially correct data. This can be simulated by returning: 1) sector OK (plus valid data) 2) data CRC error (plus some partially garbled data) In the combination of weak bits in the data part and in the header part, we would end up with three possible cases that a floppy emulator has to return: 1) sector OK (plus valid data) Header and data read in OK. 2) data CRC error (plus some partially garbled data) Header was OK, but broken bit(s) in data part. 3) sector not found Broken bit in header and the FDC didn't have any chance to look into the data part - so it doesn't matter if there are any further broken/weak bits. Examples: ? Weak data in ATP Weak data is still unresolved for ATP. However, with the chunk-based format it is possible to add this information later. Here are the discussions regarding weak data: DISCUSSION: Multiple corrupted parts in one sector MATTHIAS Reichl: I'm still not sure how we would have to store the information about the corrupted part. Theoretically it could be possible to have multiple weak parts (or holes) within a single sector. Eg: first 16 bytes ok, then 16 weak bytes, then 16 bytes ok, then 16 weak bytes... I'm not sure if this would make sense, but if the FDC is actually able to re-synchronize and read in some correct data between garbled parts, we would also have to reflect this in our data structures. STEFAN Dorndorf: Theoretically, it is possible: A bit on the disk is represented by one (0-Bit) or two (1-Bit) low-to-high or high-to- low transitions (in SD). So the FDC can synchronize at least on every 0-bit. But if you write no transitions for some time on the disk (this can't be done by the FDC), the FDC won't find the transitions to synchronize and may deliver random bytes, the behaviour of the FDC isn't defined in that case, different revisions of the FDC may behave different. So I would define the ATP-Format to have this option but not include it in the first revision. MATTHIAS: ACK. IMO (for the first version) we should just store the starting position of the weak data, and assume that the FDC won't be able to re-sync and treat the following data as random data. This means: we simply store a single byte (denoting the number of stable bytes) and then either deliver: * the correct sector data, or * the first N "stable" bytes plus (128-N) random bytes and indicate a checksum-error DISCUSSION: Weak bits in FM and MFM MATTHIAS: In FM mode both clock and data bits are written to disk. So if the FDC misses a bit, it will probably read the following clock bits as data bits and vice versa. OTOH if the FDC won't get reliable clock bits (since it is actually reading data bits) it _could_ possibly re-sync to the clock bits. [bTW: since the clock bits are "1", the FDC will report $FF data 'til the end of the sector or 'til it re-syncs]. In MFM mode only data bits are written to disk, but with a special encoding so that there will not be long runs of zero-bits. Using this encoding clock bits aren't necessary any more and it can reliably re-generate the clock (and sync to it). A missed bit will impact the decoding in two ways: First, the current bit is lost (obviously) and second, due to the MFM encoding scheme, it will also affect decoding of the following data bits. IMHO this could show up a some garbeled bits and then (when the FDC re-synced again) correct data that is shifted by several bits (not necessarily bytes!). 6. Track density change Some tracks of the disk are formatted in SD, some in ED. This copy protection is effective, since there is no backup program that checks the density of a track. And what is more, this protection method can be created by standard ATARI disk drives: Simply format a disk in SD, than reformat it in ED but switch off the disk drive after 30 formatted tracks. Now the disk seems to be in ED but the last 10 tracks are in SD. To access these tracks write protect the disk, then execute a format command, which will switch the drive in SD read mode. And maybe the density can be changed in the middle of a track. Examples: ? 7. ATP File Format The ATP file format is a so-called chunk-based format. A chunk is simply a 4 bytes identifier and a 4 bytes length field followed by the amount of data bytes indicated by the length. <UINT32> : 32-bit 'big endian' unsigned integer ATP File <ATP_File> := <FORM_ID> <FORM_Length> <ATP_Disk_Data> <ATP_CRC> <ATP_Timing_Data> <FORM_ID> := "FORM" <FORM_Length> := <UINT32> The length of the ATP Disk-Data chunk (file length - , rest of file. ATP Disk Data <ATP_Disk_Data> := <ATP_Disk_Data_ID> <ATP_Disk_Data_Length> <ATP_Header> <ATP_Track>* <ATP_Disk_Data_ID> := "ATP1" The magic code to identify an ATP version 1 disk image. <ATP_Disk_Data_Length> := <UINT32> Length of ATP Disk Data chunk in bytes. ATP Header <ATP_Header> := <ATP_Header_ID> <ATP_Header_Length> <Nr_Of_Tracks> <Disk_Info> <ATP_Header_ID> := "INFO" <ATP_Header_Length> := <UINT32> Length of the ATP header info chunk (2 bytes). <Nr_Of_Tracks> := <UINT32> Number of tracks (chunks) in this ATP Disk Data chunk. <Disk_Info> := <UINT32> { #$00 | #$01 } bit 0, Disk write protection (0=off, 1=on) ATP Track The order of ATP sectors from each ATP track is important. It should be used to store different interleaves and place double sectors on a track. When a certain track number is not available in the ATP file, it means that it's an unformatted track (drive emulators should produce error 239 ($EF) - missing sector). Note: The tracks have to be stored in strictly ascending order! Sectors within a track also have to be stored in strictly ascending order, sorted by their sector starting time (= sector position on disk)! Each block of track data contains a track header followed by a sequence of sector blocks: <ATP_Track> := <ATP_Track_ID> <ATP_Track_Length> <ATP_Track_Data> <ATP_Track_ID> := "TRAK" <ATP_Track_Length> := <UINT32> Length of this ATP_Track chunk in bytes. <ATP_Track_Data> := <Track_Number> <Nr_Of_Sectors> <Density> <ATP_Sector>* <Track_Number> := <UINT32> Track number. <Nr_Of_Sectors> := <UINT32> Number of sectors on the track. <Density> := <UINT32> { #$00 | #$01 } bit 0, Density - 0=FM (SD,DD), 1=MFM (ED) ATP Sector Sectors which are not listed are simply 'missing' sectors and thus produce an error 239 ($EF). Each sector block has a sector header followed by an amount of data bytes: <ATP_Sector> := <ATP_Sector_ID> <ATP_Sector_Length> <Sector> <ATP_Sector_ID> := "SECT" <ATP_Sector_Length> := <UINT32> Length of ATP Sector chunk in bytes. <Sector> := <Sector_Nr> <Sector_Size> <Sector_Status> <Sector_Data>* <Sector_Nr> := <UINT32> Sector ID Number. <Sector_Size> := <UINT32> Sector Size (in bytes). <Sector_Status> := { #$D3 | #$D7 | #$DB | #$DF | #$E7 | #$F3 | #$F7 | #$FB | #$FF } Sector Status $D3 FDC error $D3 (%11010011) Lost Data + Record Type "Deleted" + CRC Error $D7 FDC error $D7 (%11010111) Record Type "Deleted" + CRC error $DB FDC error $DB (%11011011) Lost Data + Record Type "Deleted" $DF FDC error $DF (%11011111) Record Type "Deleted" $E7 FDC error $E7 (%11100111) Record Not Found + Header CRC Error $F3 FDC error $F3 (%11110011) Lost Data + CRC Error $F7 FDC error $F7 (%11110111) Data CRC Error $FB FDC error $FB (%11111011) Lost Data $FF FDC status $FF (%11111111) Sector Ok Note that status $EF (Record Not Found) is not allowed here, because these missing sectors should not be listed in the track data at all. <Sector_Data> := <BYTE>* Sector data bytes indicated by Sector Size. ATP CRC A CRC32 checksum of the data part of the ATP_Data chunk (excluding the 4-byte chunk id and 4-byte chunk length) is stored for quick image comparison. <ATP_CRC> := <CRC_ID> <CRC_Length> <32_bit_CRC> CRC_ID := "CRC1" CRC_Length := <UINT32> Length of ATP CRC chunk. Currently fixed at 4 (bytes). <32_bit_CRC> := <UINT32> A checksum calculated over the data part of the ATP_Data chunk. ATP Timing Data Starting with ATP version 1.6 the timing information has been separated from the sector data/status information and is stored in an own chunk. This is mainly to ease quick image comparison by using the CRC checksum. Since the timing information might be a little bit "fuzzy", it would break quick CRC-checks. On the other hand, there is a high possibility that two images are identical if they contain exactly the same image data. Note: the timing data chunk must contain exactly the same number of tracks as the ATP Disk Data chunk and each track must contain exactly the same number of sectors as the corresponding tracks in the ATP disk data chunk! <ATP_Timing_Data> := <ATP_Timing_ID> <ATP_Timing_Length> <Timing_Nr_Of_Tracks> <ATP_Track_Timing>* <ATP_Timing_ID> := "TIM1" Magic code to identify an ATP version 1 timing data chunk. <ATP_Timing_Lenght> := <UINT32> Length of the ATP Timing Data chunk in bytes. <Timing_Nr_Of_Tracks> := <UINT32> Number of tracks (chunks) in the ATP Timing Data (MUST be the same as <Nr_Of_Tracks> in Disk Data chunk. <ATP_Track_Timing> := <ATP_Track_Timing_ID> <ATP_Track_Timing_Length> <Track_Timing_Data> <ATP_Track_Timing_ID> := "TTI1" <ATP_Track_Timing_Length> := <UINT32> Length of ATP track timing chunk. <Track_Timing_Data> := <Timing_Track_Number> <Timing_Nr_Of_Sectors> <Sector_Timing>* <Timing_Track_Number> := <UINT32> Track number. <Timing_Nr_Of_Sectors> := <UINT32> Number of sectors in the current track. <Sector_Timing> := <Sector_Start_Time> <Sector_Time_Length> Timing information for each sector. <Sector_Start_Time> := <UINT32> The time distance in microseconds between the start-time of the reference sector and the start-time of the current sector. <Sector_Time_Length> := <UINT32> Length of the sector (from the start of the header til the end of the data block) in microseconds. 8. References - Atari 8-bit floppy disk formats, Mega Magazine #6, F.Offenga - The Super Archiver manual, CSS - The Happy Enhancement article series, Atari Magazin - The Hyper-XF manual, Stefan Dorndorf 9. History Version 1.6 - Adapted the ATP file structure for separate timing information - Changed all informational values from <BYTE> into <UINT32> - Removed FDC error $EF (239, Record Not Found) from <Sector_Status>. Sectors not listed in <Track_Data> should produce this error. - Removed FDC error values with the same meaning: + $D1 : FDC error $D1 Same as $D3 + $D9 : FDC error $D9 Same as $DB + $F1 : FDC error $F1 Same as $F3 + $F9 : FDC error $F9 Same as $FB <END> ------------------------------------------------------------------------------------------------- Edit: Just found the link to the site, no newer version exists though: http://members.chello.nl/taf.offenga/ATP16.htm Edited May 17, 2009 by CharlieChaplin Quote Link to comment Share on other sites More sharing options...
carmel_andrews Posted May 19, 2009 Share Posted May 19, 2009 Going by your post CC...sounds like somone's hacked AR's copy protection then Makes having a VAPI version of the game pointless Quote Link to comment Share on other sites More sharing options...
AtariNerd Posted May 19, 2009 Share Posted May 19, 2009 The trouble is whether this person is still in connection with the community. If not, we need to recreate what he did. Quote Link to comment Share on other sites More sharing options...
triverse Posted May 20, 2009 Share Posted May 20, 2009 Well, I finished reading this whole thing, took me the better part of a week but it was definitely worth it. Awesome discussiong going on. Love it. This got me back into playing Alternate Reality, unfortunately, the only version I can get to work is on an Apple IIe emulator. Quote Link to comment Share on other sites More sharing options...
Xebec's Demise Posted May 20, 2009 Author Share Posted May 20, 2009 Alternate Reality The City by Datasoft for Atari ST Starting Bid: $1.99(0 Bids) http://cgi.ebay.com/ws/eBayISAPI.dll?ViewI...em=170334512888 Quote Link to comment Share on other sites More sharing options...
Xebec's Demise Posted May 20, 2009 Author Share Posted May 20, 2009 Well, I finished reading this whole thing, took me the better part of a week but it was definitely worth it.Awesome discussiong going on. Love it. This got me back into playing Alternate Reality, unfortunately, the only version I can get to work is on an Apple IIe emulator. Where did you run into trouble with the Atari version? I would be happy to help you with any problems that come up. Quote Link to comment Share on other sites More sharing options...
Xebec's Demise Posted May 20, 2009 Author Share Posted May 20, 2009 I actually went to college with someone who cracked it. And this guy could do it. He was the scary combination of brilliant and brute force. It's been some 19 years now since we talked about it, but he talked about how you couldn't just disable the check, because it used the check code for decrypting other code. So he built his own loader, and decrypted *all* the code for it himself. Brute force. This same guy later got some poorly documented workstations from Kodak running, because he just started looking through the ROMs for the font data that he knew it displayed. And then looked for the code that referenced those locations, and on and on. But yeah. The AR stuff is *brilliant*. Especially considering how much of it let you have a copy that appeared to run on first glance, but it *knew* it was a copy. Still in touch with that guy? Quote Link to comment Share on other sites More sharing options...
Xebec's Demise Posted May 20, 2009 Author Share Posted May 20, 2009 Code creation - a fancy name for decryption, I reckon. I attempted to crack Dungeon years ago. The boot loader from memory loaded the subsequent section, then each section had it's loader code for the next. There was a decryption key that I think was 128 bytes. The decryption process, from memory, also relied on the previous byte as it was working... so if you were to change the program, then the code after it would become corrupted. Of course, the smart thing to do was just modify the thing so that the code was no longer decrypted. As for memory bank detection and detecting "pirate code" ... dunno about that. The Atari only clears the non-expanded RAM from $0000-$7FFF, $9FFF or $BFFF depending on if a cart's there, if BASIC is enabled etc. RAM under the OS and in 130XE and other expanded schemes isn't touched and should contain "random" bit patterns. Of course, a game could load itself, e.g. at $600 then just do an OR of every byte from e.g. $0A00 to (Display List Start - 1). It should all be zeros, and non-zero values found could indicate foul play. Thanks for offering some knowledge. I still feel like I'm in the dark guessing at what those are though. Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 20, 2009 Share Posted May 20, 2009 Isn't Mark (Wrathchild) working on a cartridge conversion of The City? He's probably had plenty of experience with the code in the game. I don't know if it's any more or less complicated than Dungeon so far as it's efforts against copying/reverse engineering, but might be worth the ask. I remember reading some of Philip Price's commentary that's on the disks, it gave a brief rundown of some of it. I think you could also view the text by booting one of the disks. Quote Link to comment Share on other sites More sharing options...
Xebec's Demise Posted May 20, 2009 Author Share Posted May 20, 2009 So, after removing this security code, the game might not function the same. Does the cracked version run differently than an original? It sounds like it would be very difficult to remove the real-time code, and anything it may affect, from the entire game without resulting to a few hacks that modify how the game runs. And, how would you ever know if you corrected ever bit of code that may have relied upon it? Is real-time code creation used in any other Atari 8-bit software? What about the other stuff? Can anyone explain these in further detail; 1) Block chain ciphers 2) Weak-bit anti-copy technology (I'm assuming this one the commonly used bad disk sectors) 3) Real-time code creation using data folding to prevent static analysis 4) Memory bank detection, if it detected a pirate code insertion, would use a self-relocating viral code to perform a memory wipe. Well,interested in copy protection ?!? Here is some old text I downloaded from ATP, since I have not visited their site since 2004 there might be a newer version available (if the site still exists). Probably some of the AR protection schemes are missing in this text, anyways, here it is: -Andreas Koch. Edit: Just found the link to the site, no newer version exists though: http://members.chello.nl/taf.offenga/ATP16.htm Ok, so that probably covers the copy protection such as I listed in #2, but the other 3 don't seem to be covered in that copy protection document. What about #1, #3, and #4? And would the gameplay be affected by removing all that code? Anyone ever test much between original gameplay and cracked? But it does make me wonder if a backup of AR The City can be made which is not cracked using the ATP format - and still have the backup run in an emulator? Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 20, 2009 Share Posted May 20, 2009 I'm fairly sure the cracked versions didn't bother altering the game code on other than the boot disk in AR. Unsure of Dungeon, it would make sense that it was probably just a flag or set of signature bytes somewhere that triggered/suppressed the FBI Agents coming at you once the game fully loaded, in which case the subsequent program after the initial boot stages might have been able to remain unaltered for cracked copies to work. Also, they actually encouraged owners to backup the other disks, which didn't have any copy protection. I suppose the way to work out if the subsequent disks were altered as part of the cracking process would be to use a cracked D1S1 along with other disks from distributed cracked copies. Quote Link to comment Share on other sites More sharing options...
triverse Posted May 20, 2009 Share Posted May 20, 2009 Well, I finished reading this whole thing, took me the better part of a week but it was definitely worth it.Awesome discussiong going on. Love it. This got me back into playing Alternate Reality, unfortunately, the only version I can get to work is on an Apple IIe emulator. Where did you run into trouble with the Atari version? I would be happy to help you with any problems that come up. It is not loading past the cityscape, before the UFO appears. It appears to lock up there, I have left it on for up to 15 minutes with nothing (I know it takes only a few seconds on other versions for the UFO to appear so I guess it is locked up). I am using this emulator, Atari800Win PLus 4.0, other games load up fine. I have everything set up right. I got it to goto the star field now (setting the performance at "Run as fast as possible" holding at about 600 to 1100%. I got it to work, just have to keep it unthrottled till it gets to the Create Character and such screen, throttle it, set that up, then unthrottle it again till it gets to the stats screen. Sorry for any trouble I may have caused. I have been playing the Amiga version on my PSP for a few weeks now (kind of annoying to switch to the onscreen keyboard and back but it is a portable version). Thanks for the help though, I do appreciate it. Quote Link to comment Share on other sites More sharing options...
kurtm Posted May 20, 2009 Share Posted May 20, 2009 I actually went to college with someone who cracked it. And this guy could do it. He was the scary combination of brilliant and brute force. Still in touch with that guy? Haven't talked to him in years, but I could see about looking up his email. Quote Link to comment Share on other sites More sharing options...
+remowilliams Posted May 20, 2009 Share Posted May 20, 2009 But it does make me wonder if a backup of AR The City can be made which is not cracked using the ATP format - and still have the backup run in an emulator? Well, I don't know about ATP, but it can be done with VAPI. And here's the Dungeon in VAPI for good measure. Alternate_Reality___Dungeon.VAPI.zip Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted May 20, 2009 Share Posted May 20, 2009 Isn't Mark (Wrathchild) working on a cartridge conversion of The City? He's probably had plenty of experience with the code in the game. I don't know if it's any more or less complicated than Dungeon so far as it's efforts against copying/reverse engineering, but might be worth the ask. I remember reading some of Philip Price's commentary that's on the disks, it gave a brief rundown of some of it. I think you could also view the text by booting one of the disks. The cart work was based off the cracked disk images so I didn't have to work through the protection myself. Also at that time I think the VAPI emulator didn't have the debugger enabled which would help with such an exercise. On today's emulators it maybe easier to repeat the impressive feats of those original crackers. From the little I've seen of the disk 1 protection, this has the deliberate disk errors and code dependent on these which would upset the loading of the intro etc if not present. Once the I/O switches to the custom sector layout structure then the protection is only in the form of the seeded and chained dependency of the overlays. Tools etc can turn these into an unencoded form and this has been used on those projects reverse engineering the code (e.g. evilmoo) but I haven't followed the state of progress on those. Though the Dungeon uses the I/O routines/encoding technique it does have the scheme employed by AR:City and in that sense is less complicated. The City uses a part of the second disk to store state information when swapping in other code/data and hence the need to copy that disk and use it instead of the original! One thing I'm not aware of though is if there is code in there that doesn't trigger until later stages in the game, as you say the knowledge of the game being a crack being deliberately ignored giving the cracker the impression that they had beaten it. I suspect not but you never know. Question: Does SIO2SD run the cracked AR:City or Dungeon images well? e.g. can all sides be mounted such that the game can be played with no further pressing of the SIO2SD buttons? I'm tempted to get one of these devices and this could sway it. As for the cart, no progress for far too long - 2009 started out with good promise for me A8-wise but I have many other things filling my time currently and so I'm happy to be regularly following AtariAge/AtariMax/AtariMania and AtariOnline.pl postings but can't seem to focus on progressing development projects. Not sure why VAPI images of the Dungeon aren't up on the AtariMania list, I'd sent those many moons ago - typically they confirm images from multiple sources before releasing them and so I'm guessing these haven't been confirmed yet? Regards, Mark Quote Link to comment Share on other sites More sharing options...
Xebec's Demise Posted May 21, 2009 Author Share Posted May 21, 2009 (edited) But it does make me wonder if a backup of AR The City can be made which is not cracked using the ATP format - and still have the backup run in an emulator? Well, I don't know about ATP, but it can be done with VAPI. And here's the Dungeon in VAPI for good measure. Alternate_Reality___Dungeon.VAPI.zip Excellent! Thanks, can't wait to try this out: http://www.atarimania.com/vapi.php?MENU=8&RUB=VAPI Edited May 21, 2009 by Xebec's Demise Quote Link to comment Share on other sites More sharing options...
www.atarimania.com Posted May 21, 2009 Share Posted May 21, 2009 IIRC, there are two or three different revisions of Alternate Reality - The Dungeon. Have they all been clearly identified? Thanks! -- Atari Frog http://www.atarimania.com Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 21, 2009 Share Posted May 21, 2009 That's a point worth considering. There's also the chance they took the opportunity to revise the copy protection as well... then again, maybe only some of the subsequent program/data not present on the first disk was changed. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted May 22, 2009 Share Posted May 22, 2009 I never found a copy of this that acted 100% like the store bought one I had..... would be interested in recreating it from VAPI but do not have the VAPI tool to do it... That's a point worth considering. There's also the chance they took the opportunity to revise the copy protection as well... then again, maybe only some of the subsequent program/data not present on the first disk was changed. Quote Link to comment Share on other sites More sharing options...
Xebec's Demise Posted May 23, 2009 Author Share Posted May 23, 2009 I never found a copy of this that acted 100% like the store bought one I had..... would be interested in recreating it from VAPI but do not have the VAPI tool to do it... What differences have you noticed between the crack and the original? Here's the VAPI site: http://vapi.fxatari.com Quote Link to comment Share on other sites More sharing options...
Xebec's Demise Posted May 23, 2009 Author Share Posted May 23, 2009 IIRC, there are two or three different revisions of Alternate Reality - The Dungeon. Have they all been clearly identified? I don't know about the Dungeon, but I have seen different version numbers on The City. I have several versions of the original packaging that I want to test, from USA, Europe, Datasoft, and U.S. Gold. ...I'm still waiting to get my real Atari back from MEtalGuy66 so I can test them... Quote Link to comment Share on other sites More sharing options...
Shamus Posted May 26, 2009 Share Posted May 26, 2009 Was there something wrong with the Heist Network crack of the Dungeon? My brother and I played that one all the time without encountering any problems. Solved all the quests, etc. Of note: I did buy a copy when it first came out directly from DataSoft. You can't begin to imagine the disappointment that me and my brother went through when we booted it up, created some characters, and immediately got attacked by FBI agents. Obviously DataSoft goofed up the copy protection on those disks; sometimes I wonder if that version ever got circulated or not. Quote Link to comment Share on other sites More sharing options...
Xebec's Demise Posted June 7, 2009 Author Share Posted June 7, 2009 Can anyone explain these in further detail; 1) Block chain ciphers 2) Real-time code creation using data folding to prevent static analysis 3) Memory bank detection, if it detected a pirate code insertion, would use a self-relocating viral code to perform a memory wipe. So, I take it, nobody else here really knows what these are in any further detail? Quote Link to comment Share on other sites More sharing options...
Xebec's Demise Posted March 16, 2010 Author Share Posted March 16, 2010 AR Dungeon Disks & Manual $9.99 ends in 5 days: eBay Auction -- Item Number: 330414185191 Quote Link to comment Share on other sites More sharing options...
triverse Posted March 17, 2010 Share Posted March 17, 2010 AR Dungeon Disks & Manual $9.99 ends in 5 days: eBay Auction -- Item Number: 330414185191 If that auction included the box, I would be all over it. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.