436 replies to this topic

[CharlieChaplin]

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.chell...fenga/ATP16.htm

Edited by CharlieChaplin, Sun May 17, 2009 12:29 PM.

[carmel_andrews]

Going by your post CC...sounds like somone's hacked AR's copy protection then

Makes having a VAPI version of the game pointless

[AtariNerd]

The trouble is whether this person is still in connection with the community. If not, we need to recreate what he did.

[triverse]

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.

[Xebec's Demise]

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

[Xebec's Demise]

triverse, on Tue May 19, 2009 7:32 PM, said:

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.

[Xebec's Demise]

kurtm, on Sun May 17, 2009 4:51 AM, said:

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?

[Xebec's Demise]

Rybags, on Sun May 17, 2009 1:34 AM, said:

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.

[Rybags]

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.

[Xebec's Demise]

Xebec's Demise, on Sun May 17, 2009 1:07 AM, said:

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.

CharlieChaplin, on Sun May 17, 2009 11:24 AM, said:

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.chell...fenga/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?

[Rybags]

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.

[triverse]

Xebec's Demise, on Tue May 19, 2009 11:49 PM, said:

triverse, on Tue May 19, 2009 7:32 PM, said:

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.

[kurtm]

Xebec's Demise, on Tue May 19, 2009 11:54 PM, said:

kurtm, on Sun May 17, 2009 4:51 AM, said:

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.

[remowilliams]

Xebec's Demise, on Wed May 20, 2009 12:03 AM, said:

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   312.03K   69 downloads

[Wrathchild]

Rybags, on Wed May 20, 2009 6:00 AM, said:

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

[Xebec's Demise]

remowilliams, on Wed May 20, 2009 2:50 PM, said:

Xebec's Demise, on Wed May 20, 2009 12:03 AM, said:

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   312.03K   69 downloads

Excellent! Thanks, can't wait to try this out:

http://www.atarimani...MENU=8&RUB=VAPI

Edited by Xebec's Demise, Thu May 21, 2009 2:20 AM.

[www.atarimania.com]

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

[Rybags]

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.

[_The Doctor__]

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...

Rybags, on Thu May 21, 2009 8:24 AM, said:

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.

[Xebec's Demise]

_The Doctor__, on Fri May 22, 2009 11:28 AM, said:

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

[Xebec's Demise]

www.atarimania.com, on Thu May 21, 2009 6:01 AM, said:

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...

[Shamus]

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.

[Xebec's Demise]

Xebec's Demise, on Sun May 17, 2009 1:07 AM, said:

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?

[Xebec's Demise]

AR Dungeon Disks & Manual $9.99 ends in 5 days:

eBay Auction -- Item Number: 330414185191

[triverse]

Xebec's Demise, on Tue Mar 16, 2010 1:35 PM, said:

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.