Req : "Audio Sculpture" (STX,...) even not running...

[JimDrew]

LOL! Sorry, remember I am not an "Atari guy". I spent most of my life (from 1977 til now) working on Commodore stuff. I never made products for the Atari line, but I sold a lot of Supercard Ami's to Atari ST user groups that used an Amiga 500 to back up their Atari ST disks.

[Steven Seagal]

Regarding the Pasti images, you might need to use the undocumented diag Code 16 in the Pasti Config Option pane. I'll provide later a correct 1.3 Pasti image that doesn't need this option. For 1.5 it is more difficult since we don't have a flux level dump of that version.

Tests seem to confirm that "diag 16" is indeed necessary to avoid random HALT (v 1.5).
Also this program is one of the most sensitive to some MFP timings in emulation. So this could be MFP emulation imprecision.
EDIT: Well no, the apparent MFP issue was hiding another real STOP issue.

About how to write back the disk, one definite way is to replicate what the dudes did: read track 3, compute the key and write it wherever it should be. So, the "master" approach in this case. This can be automated.

[MiggyMog]

I hope the attached are working ok. I didn't have time to test. I had a heck of a time getting my cosmosex to cooperate. Here goes:-

[troed]

I hope the attached are working ok. I didn't have time to test. I had a heck of a time getting my cosmosex to cooperate. Here goes:-

Boots up nicely in latest Hatari dev build here (TOS 1.62, will bomb out with TOS 2.06)

Thanks!

/Troed

[npomarede]

I hope the attached are working ok. I didn't have time to test. I had a heck of a time getting my cosmosex to cooperate. Here goes:-

Boots up nicely in latest Hatari dev build here (TOS 1.62, will bomb out with TOS 2.06)

Disk B seems badly preserved though, when loading module 'no_sense.mod' from the side2 directory, I get a disk error.
But it seems AS 1.2 disk B is the same as AS 1.3 disk B, so that's not such a big problem.

[MiggyMog]

That's good disk A was ok. I can re- image disk B at some point. But as you say not much value

[Maartau]

I hope the attached are working ok. I didn't have time to test. I had a heck of a time getting my cosmosex to cooperate. Here goes:-

Boots up nicely in latest Hatari dev build here (TOS 1.62, will bomb out with TOS 2.06)

Thanks!

/Troed

Thanks MiggyMog ...

...thanks Troed .

Thanks to : Steven, Nicolas & Jim too .

...also thanks to Brume & Dsp56001 .

[dlfrsilver]

and thanks to me for contacting frederic bautista, who told us how the protection is working

[Brume]

Dam, how can you forget Amiga-man, Maartau?

[MiggyMog]

Talking ofd Amiga. I seen the amiga version was for sale on eBay.

[Maartau]

and thanks to me for contacting frederic bautista, who told us how the protection is working

Dam, how can you forget Amiga-man, Maartau?

Hell yeah, my bad & apologizes : also thanks to dlfrsilver .

-> "we" can seek for an 1.4 original version too .

[ijor]

SCP already looks at the target drive and adjusts the bitcells so they are the same length (in time) for the rotational speed of the target drive. This was necessary because sometimes people dump disks with a 360 RPM drive and then want to write them back on a 300 RPM drive. I typically see +/- 1 bitcell variance when read/writing on the same drive.

I compared the original dump made by Brume and a copy of that dump written back to disk with the SCP (in a different drive):

Code: Select all

......   Original .......... Copy ............. Diff in # of transitions
 ===============================================================
Track 0: samples:  46654.    samples:  46665       11
Track 1: samples:  38500.    samples:  38518       18
Track 2: samples:  38637.    samples:  38664       27
Track 3: samples:  38082.    samples:  38114       32
Track 4: samples:  38448.    samples:  38474       26


The difference is more in the order of two or three full bytes. Not bad and probably close enough for almost any disk, except this one. For this protection it's way too much and has no chance.

[JimDrew]

Hmm... I don't see this much variance with any setup I have here. How are you determining the number of samples?

[ijor]

Hmm... I don't see this much variance with any setup I have here. How are you determining the number of samples?

Simply, from the track header of the SCP images.

[Maartau]

Holy sh*t !

I also forget to thanks you Ijor ...

...

I've got one question : who was responsible to produce/make the "duplication" ?

- Thundersoft dev ? -> Frédéric, Pascal, ...
- Expose Software ?
- Sync ?

[dlfrsilver]

Frédéric Bautista.

[Estrayk]

Hi troed, doesnt runs in Falcon coz AS doesn't run on it or because your crack doesnt work in Falcon?
Just curiosity,

thx

[troed]

Hi troed, doesnt runs in Falcon coz AS doesn't run on it or because your crack doesnt work in Falcon?
Just curiosity,

AS was written in 1990/1991. Falcon came out in 1992/1993 Even though AS handles TT nicely I would expect there to be many Falcon specific things that break it.

/Troed

[Steven Seagal]

Maybe the STOP is handled differently?

[npomarede]

Maybe the STOP is handled differently?

Yes, stop on 68020/68030 behaves "correcty", no test of S bit in the new SR (it was checked by Toni Willen on Amiga).
But even so, I think the cracked version made by Troed doesn't work on Falcon (the TOS is not supported I think)

[troed]

Maybe the STOP is handled differently?

Yes, stop on 68020/68030 behaves "correcty", no test of S bit in the new SR (it was checked by Toni Willen on Amiga).
But even so, I think the cracked version made by Troed doesn't work on Falcon (the TOS is not supported I think)

I don't believe AS uses TOS at all, I would expect the reason to be purely hardware differences. The uncracked version does patch TOS as part of its protection and that's the reason why it's not working on TOS 2.06 (came out later).

[DrCoolZic]

Being away for some times, I just discovered this old but very interesting thread!
I briefly looked at the image under Aufit and found lots of interesting info / problems that I need to eventually address.

But most of my problems are related to write splice detection ...
So if Ijor is still looking at this thread I have a question for him (actually anybody is welcome to answer): Can you explain simply what is the best way to detect the write splice. I am currently using a very complex process that checks both rupture in bit length and a state machine that checks rupture in bytes value etc. It works in most cases but it is complex and not reliable and therefore not satisfying.
Can this be done without interpreting the byte content, just a the flux level? And is there cases where it can't be detected reliably because the flux length of the write splice is equal or close to normal bit length?

I have attached a document that describes in more detail what is used in Aufit

Write Splices Information v1.0.pdf

[ijor]

Hi Jean,

But most of my problems are related to write splice detection ...
So if Ijor is still looking at this thread I have a question for him (actually anybody is welcome to answer): Can you explain simply what is the best way to detect the write splice. I am currently using a very complex process that checks both rupture in bit length and a state machine that checks rupture in bytes value etc. It works in most cases but it is complex and not reliable and therefore not satisfying.
Can this be done without interpreting the byte content, just a the flux level? And is there cases where it can't be detected reliably because the flux length of the write splice is equal or close to normal bit length?

I don't think there is a foolproof reliable way to detect a write splice. At least not without having access to the full analog magnetic recording (not just the transitions).

Yes, ideally you should combine both a low and a high level analysis. Sometimes the track is very "clean" at both levels, except at the splice point. In those cases it is relatively straightforward. Sometimes depending on how the track was recorded, the flux transitions might be very irregular. Sometimes there are multiple write splices. Sometimes there isn't exactly a write splice point, but recording was ended some time before the index (or the start). In those cases, the start and the end of the recording don't overlap. This is not so uncommon because duplicators usually ended the recording at a fixed data length, and if the drive was rotating slightly slower, the recorded length wouldn't cover a full revolution.

Yes, if you are "unlucky", the transitions at the write splice could be (just by chance) the same, or almost the same as a regular transition. And this obviously, is more likely when the track transitions are not so regular and normalized in the first place. IMHO, at the end of the day, the best you can do is to combine analysis at multiple levels and make a more or less educated guess.

Note that the protection here doesn't attempt to detect the write splice. It just reads and compares the data that is supposed to be at the write splice. I also am not sure you can really detect this protection by a disk analysis alone. Probably in the best case you can determine that there is a sector that spawns the index and what it seems to be the write splice. You can of course guess/infer the possible/probable purpose of a such a sector.

[DrCoolZic]

Thanks Ijor. It looks like at least I am moving in the right direction…

I did not consider the possibility of multiple write splice (what I refer as ‘track write splice’) as the result of using duplicators with fix (and probably slightly shorter) track length.

As described in my document I am also trying to differentiate “sector write splice” from “track write splice”. To be able to make the distinction between the two requires high-level analysis. The reason for detecting sector write splice is to be able to detect if a FD has been modified (tampered). The splice detection as described is only available in my ‘in progress’ version 1.4 of Aufit. In this version, I am attempting to regenerate a “perfect master image” from known templates and splice detection is a requirement. The goal is to be able to write perfect image in IPF or STX format.

For the protections present on track three, I need to improve Aufit, because this track used a very smart mechanism that I have never seen before: Each sector contains two ID_field in front of the Data_field! We have exactly 30 bytes (post_id_gap=7 + id_field = 6 + post_id_gap=17) from the end of the first ID_field to the data_field. This is less than the maximum 43 bytes in DD allowed by the WD1772 to correctly read a sector. I have not yet tried to read this tracks under emulation with the WD1772, but in theory you should be able to read the same sector with two different id (sector 2 and sector 12, sector 3 and Sector 13, etc.). To be more precise the first ID declare a record length of 512 and should read without CRC error, while the second ID declare a length of 1024 and should reads with a CRC error (because it is a truncated sector) but the first 512 bytes should be the same.

as.PNG

About the last sector that contains the write splice: We also have two ID_fields: the first one describes a sector 10, and is followed by another ID_field that contains many invalid values and has a bad CRC. As sector 10 is declared to be 1024 bytes long it ‘extent over the index’ (where we have the write splice)… I have to further analyze this protection, but as the write splice is detected by Aufit INSIDE the content of the sector it should possible to use this information to detect this specific protection mechanism.

As far as I understand this protection was produced ‘by hand’ (not on a duplicator) and probably on an Atari? On the Atari, a track is written from IP to IP. As the last sector is declare with a length of 1024 the end of the sector is well behind the IP and consequently it is truncated by the WD1772 at the IP. As mentioned this position where is is truncated is dependent of the motor speed and should be different each time… Remember that if a write track is stopped by the IP, a read sector is not (can go beyond IP).

By the way there was no feedback from Jim being able to write back a working FD?
Therefore I assume nobody was able to produce a working FD from SCP (or from KF) for this protection?
This discussion about writing flux reminds me when I first discovered the Discovery Cartridge in the 80’s: At that time I could not understand why it was not possible to copy all existing FD just using a perfect ‘track flux copy’!

Question to ‘dlfrsilver’: Did you tried to analyze the program under CTA (I will give a try, but I first need to reinstall the dongle protection)? I think you were supposed to get information from people at SPS? Any news from them?

[DrCoolZic]

@dlfrsilver : I have setup my system to use CTA and guess what it does not seems to like this image!

It complains on almost all tracks! Actually if the FD has been written on an Atari this could make sense. CTA using some magic finds that the tracks have been tempered, which make sense, as probably each track is first formatted (write track) then content is written using write sector (this should generate sector write splice).

AS-sg-err.PNG

Therefore, it is a pain if you try to analyze the complete FD. So what I did is to is to only analyze track 3.0. I am first getting this error: SG error unresolved group (I never could get the meaning of this error from SPS?). Then, when analyzed CTA incorrectly detect (with probability of 50%) the track has a speelock track. By setting the Sync to DOS it correctly detects 10 sync marks (I guess data sync mark) but the content does not make too much sense. I have tried to select manually MFM format but it is rejected.

as-data-content.PNG

Can you have a look at the ctr image with CTA? Can you ask Istvan some help?

For info in Aufit I detect: last data_field is at about 179.85ms with length about 32.6ms -> places the end at 212.4 well beyond splice at 0 (=200)