Jump to content
IGNORED

Disk-Master 1050 disk copy protection


ijor

Recommended Posts

Disk-Master 1050 by Stefan Wachter, apparently released on 1986 in Germany. The manual being in German I'm not 100% sure about the exact capabilities, but basically it is an editor for producing custom disk formats using an enhanced 1050 drive. The copy I've seen is for the Happy 1050, but if I understand the manual correctly, there is also a version for the Speedy.

 

It uses a very special copy protection method. It is in enhanced density and a handful of tracks have a sector numbered #27.

 

There are not too many disk copy protection methods for the Atari 8-bit. The possible methods are limited by the low level capabilities of Atari drive. A protection must be able to be checked and detected on a standard stock drive that is the one that the user has. The mentioned protection using tracks with sectors #27 can't be detected on a stock drive. Standard firmware on Atari drives ignore completely any sector number beyond the normal range according to the density. There is no way to check if such a sector is present or not and then the protection can't be verified. At least not in a standard drive. But this particular title doesn't run on a stock drive, it requires a Happy. It is then not bounded by the limits of standard Atari drives. In theory, very advanced and exotics protections are possible.

 

This is the 4th title I've seen that uses a special protection that targets an enhanced drive. The other three are all Archiver variants. I've been told there are a couple more also released on Europe.

 

It is also interested how exactly the protection is verified. The software first "programs" the Happy and installs a custom command table. It then issues one of the custom commands that attempts to read all the sectors #27. If the command fails for some reason, the software, obviously doesn't run. It is not too difficult to bypass the protection check performing a quick crack. Then the program continues, the menu is displayed and the software is operational. But when the custom command reads those special sectors, it doesn't just verify that they exist. They are all read into Happy's extended RAM and they include most of the in-drive custom code that it is required for actually producing a custom format. So the quick crack will fail when at that point.

 

The software might be able to copy itself. Or at least it might be able to produce tracks with sectors #27. May be it can create such tracks but not write those sectors. Don't know for sure. Again, the manual is in German so I'm not sure exactly about its capabilities.

  • Like 5
Link to comment
Share on other sites

I guess that tracks in the copy-protected disk only have 26 sectors, and one of them has been renumbered to 27, so there is also a missing one.

 

If the previous is true, data from sector 27 could be copied to the "unused" one of the track (of the copy disk) to have the whole data inside the disk. Then, the "protected" data/code can be read into Happy's extended RAM if it is read from the "new" sectors instead of the ones numbered as 27.

 

  • Like 1
Link to comment
Share on other sites

Up to date no hacked/cracked AND working copy of this title exists !

 

Stefan had a series in the german Atari Magazin for the Turbo 1050, Speedy 1050 and Happy 1050 drives and their programming and copy protection capabilities.

 

http://www.atarimania.com/atari-magazine-atari-magazin_81.html

(e.g. january/february 1987, pages 36-41 for the first part; march/april 1987, pages 50-55 for the second part; there is a review of Diskmaster on page 37 of that issue; may/june 1987 pages 40-44 for the third part; july/august 1987, pages 36-39 for the fourth part; september/october 1987, pages 44-46 for the fifth part; the series abruptly ended then and was replaced with a new series about game programming and later also RPG programming)

 

He started with the Happy 1050, but later he also included the Speedy 1050 and Turbo 1050 drives. After a short while the series ended (with a few type-in listings in TB XL and Assembler) and Diskmaster 1050 was presented to the public. It was advertized as a program to create and analyze various copy protections - but the program itself could not be analyzed nor copied on any of the enhanced 1050 drives (one could copy it with a normal sectorcopy program and would not get errors, but the copied program would not run)...

 

Some german publishers (AMC-Verlag, Compyshop, etc.) used Diskmaster to protect their commercial programs in single and enhanced density (e.g. Herbert, Herbert II, Print Star, Print Star II, etc.)... let's wait and see if nowadays someone is able to crack it and make a fully working copy... ;-)

 

(Besides, thought I read that the XF551 is able to use up to 31 sectors per track in medium/enhanced density ? But that drive was not available on the german market in 1986...)

Edited by CharlieChaplin
  • Like 1
Link to comment
Share on other sites

Hello Vitoco

 

I guess that tracks in the copy-protected disk only have 26 sectors, and one of them has been renumbered to 27, so there is also a missing one.

 

According to either "Atari Software Protection Techniques" or "Advanced Atari Protection Techniques" by George Morrison and Alpha Systems, more sectors can be created if shorter sectors are used. As in, sectors with less than the normal amount of bytes in it. Missing sectors mainly "appear" when double sectors are used. Double sectors meaning two sectors with the same sector number.

 

Sincerely

 

Mathy

 

PS both books have been scanned and are available on the net for free.

Link to comment
Share on other sites

I was just looking at the WDX279x-02 datasheet, and it's interesting it claims that valid sectors are in the range of 1 thru 1A - which is 1-26, so 27 as you mention is 'out of range'. But in the 1050 case, mostly because the stock Atari ROM doesn't go past that.

 

Is reading/writing 27 actually beyond the capabilities of the WDC controller, or just beyond the "IBM Format" standards for compatibility? With custom firmware, are there any real limits on the sector number? ie, could the controller be told to write sector numbers up to 255...

post-53052-0-84824100-1555977344_thumb.png

Link to comment
Share on other sites

Most (all?) commercial games or at least those with protection used 810 type 18 sector/track floppies.

 

It's been a while but in theory you should be able to write out a track and give the sectors any numbers you want up to a certain value, e.g. start at 10 and have several sector 20s and just miss some in the middle. The "certain value" I think might actually be around F7 or so (higher values being commands to do stuff like sync marks).

 

Often the duplicate sector protection method works by reading in a certain order which can predetermine which of the dups you get next, assuming of course a standard drive.

 

* note - in saying that, I mean by using commercial disk production or non-Atari drives.

Edited by Rybags
Link to comment
Share on other sites

I guess that tracks in the copy-protected disk only have 26 sectors, and one of them has been renumbered to 27, so there is also a missing one.

 

No, those tracks have 27 sectors. There are no missing sectors. As CharlieChaplin said, you can copy the disk with a sector copier and you won't get any (apparent) error.

 

Up to date no hacked/cracked AND working copy of this title exists !

I am aware about a version without copy protection. Don't know if it's a crack or if it was originally released like that.

 

Stefan had a series in the german Atari Magazin ...

 

Interesting info. Thanks.

 

It was advertized as a program to create and analyze various copy protections - but the program itself could not be analyzed nor copied on any of the enhanced 1050 drives ...

Surely that the disk can be copied, at least with the right software. It is basically a very simple protection. But seems that no copier has such capability.

 

(Besides, thought I read that the XF551 is able to use up to 31 sectors per track in medium/enhanced density ?

I'm not sure exactly how many med density sectors it can use, would need to test or make the math. But it is exactly the same for the 1050 and the XF551. The only difference is that the XF551 can format a track with more precision because it uses the index hole for formatting. So it could stuff slightly more data when formatting. Reading is the same.

 

 

According to either "Atari Software Protection Techniques" or "Advanced Atari Protection Techniques" by George Morrison and Alpha Systems, more sectors can be created if shorter sectors are used. As in, sectors with less than the normal amount of bytes in it. Missing sectors mainly "appear" when double sectors are used. Double sectors meaning two sectors with the same sector number.

Yes, but it is not the case here. Here there are no "short" sectors, all sectors are complete. Furthermore, the protected sectors are "big" sectors with 256 bytes size. A track can fit more data than its nominal formatted capacity.

  • Like 1
Link to comment
Share on other sites

Is reading/writing 27 actually beyond the capabilities of the WDC controller, or just beyond the "IBM Format" standards for compatibility? With custom firmware, are there any real limits on the sector number? ie, could the controller be told to write sector numbers up to 255...

 

The FDC can read any sector number you want, even 0 or 255. Some sectors numbers can't be formatted by the FDC because they have a special meaning at format time. But you can format them with different hardware (say, Kryoflux, SCP or BitWriter) and the FDC would happily read them. The "IBM format" has no strict limit either. The limited range is just a consequence of the high level interface of Atari 8-bit drives.

 

When you read a sector on an Atari disk you specify a logical sector, not a physical sector. So the firmware will simple compute the modulus (18 or 26 depending on the density) plus one to select the physical sector #.

 

Edited by ijor
  • Like 3
Link to comment
Share on other sites

I was just looking at the WDX279x-02 datasheet, and it's interesting it claims that valid sectors are in the range of 1 thru 1A - which is 1-26, so 27 as you mention is 'out of range'. But in the 1050 case, mostly because the stock Atari ROM doesn't go past that.

 

Is reading/writing 27 actually beyond the capabilities of the WDC controller, or just beyond the "IBM Format" standards for compatibility? With custom firmware, are there any real limits on the sector number? ie, could the controller be told to write sector numbers up to 255...

 

I´ve tried to crack this tool in the 80s, but never - as all other, too - win that race. What I know from these times, one of the nasty copy protection was mixing different sector lengths and wrong sector headers together. You can reach (i.e. test, if the disk is genuine) the "special sectors" only by reading the sectors backwards and in a special order. Standard copy tools (sector copier) read from 1...720 or 1040 and they copy a protected disk without errors - but the copy won´t run, because these special protected sectors are hidden when read one by one upwards...

 

It was real cool stuff what Stefan have create this years...

Link to comment
Share on other sites

I´ve tried to crack this tool in the 80s, but never - as all other, too - win that race.

I didn't check the software side of the protection. One of the problems is that you might need extra space to fit the data that originally is present in those special sectors. If you crack it and use a

standard unprotected disk, you have a few less sectors. Conceivable, in the worst case, it should be possible to use double density. A Happy 1050 is required anyway, so double density shouldn't be a problem.

 

We'll see what a pro cracker like Djaybee can do :)

 

What I know from these times, one of the nasty copy protection was mixing different sector lengths and wrong sector headers together. You can reach (i.e. test, if the disk is genuine) the "special sectors" only by reading the sectors backwards and in a special order. Standard copy tools (sector copier) read from 1...720 or 1040 and they copy a protected disk without errors - but the copy won´t run, because these special protected sectors are hidden when read one by one upwards...

You can't read those sectors #27 with a stock drive and original firmware. It is not a matter of order. There is no way at all to read them (well, except might be somehow exploiting a bug in the diagnostic commands). The software reads them because it doesn't run on a standard drive, a Happy 1050 is required. With a Happy you are not bound by the limits of the firmware anymore.

 

In the same way, it is rather simple to implement a copier that would run on any 1050 enhanced drive that would be able to copy this disk.

Link to comment
Share on other sites

Here's just an idea: if the software only checks the protection once, wouldn't it be possible to run it up to everything is done (i.e. check the extra sectors, uploading its contents to the drive etc. whatever it does) and then make a dump, freezer style, of both the Atari's memory and the 1050 Happy's memory? After that, is shouldn't be too hard to have a bootable disk that ends in exact the same situation?

 

Edit: btw is Altirra's 1050 Happy emulation good enough to run this? That would be really helpful I guess.

Edited by ivop
Link to comment
Share on other sites

But for a start: Where is an ATX of it?

Sorry, no ATX yet, working on it. I'll let you know when it's ready.

 

Edit: btw is Altirra's 1050 Happy emulation good enough to run this? That would be really helpful I guess.

I think it is, at least for the purpose of loading the program. The problem currently is more related to how to handle this at the file image level.

 

Btw. I forgot that the Archiver for the Happy 810 has a similar protection with several long sectors that are loaded directly from the disk to the drive RAM with custom code. Unlike DiskMaster, they are all on the same track and there are no invalid sector numbers. And of course it is in single density.

 

Btw2. Disk Master 1050, at least the version I have, has a bug and requires the a Happy with the old rev1 firmware. It won't load if the Happy has firmware rev2. Strange, by the time this was released Happy was shipping rev2 for quite some time I believe.

Edited by ijor
Link to comment
Share on other sites

I think it is, at least for the purpose of loading the program. The problem currently is more related to how to handle this at the file image level.

Altirra can't handle this yet because the internal disk storage is based on logical sectors, so it will toss physical sectors that don't map to a logical sector on load or format. The FDC emulation could handle it, but there's no way to store the sector.

Link to comment
Share on other sites

LOL, no idea if I am up to this challenge.

But for a start: Where is an ATX of it?

 

One of the problems here, and perhaps the main reason that this software was never cracked, is that it requires a different type of know how. You need a good knowledge and understanding of the Happy internals (that was never documented), something that most crackers were probably not familiar with. And probably the very few that did were familiar with Happy technicals at the time, weren't so good crackers :) The fact that some sectors are somewhat hidden doesn't help either. They are hidden in the sense that they are difficult to extract the data with standard tools. Most other titles can be cracked from an ATR image. In this case an ATR image would miss some critical data.

 

I was checking the Archiver for the Happy 810. I never looked into this program before because I had no way to test it. Only recently that Phaeron implement full Happy 810 emulation I could. The protection is even more complicated than DiskMaster in some senses. Another challenge for you, Djaybee, or any other volunteers :)

 

 

Altirra can't handle this yet because the internal disk storage is based on logical sectors, so it will toss physical sectors that don't map to a logical sector on load or format. The FDC emulation could handle it, but there's no way to store the sector.

 

Yes, I know. I implemented an ugly and very dirty hack to solve this and I have a working version. But this is not the only problem. The other problem is that ATX images don't (didn't) store full long sectors. Working on this as well.

 

  • Like 1
Link to comment
Share on other sites

 

One of the problems here, and perhaps the main reason that this software was never cracked, is that it requires a different type of know how. You need a good knowledge and understanding of the Happy internals (that was never documented), something that most crackers were probably not familiar with. And probably the very few that did were familiar with Happy technicals at the time, weren't so good crackers :) The fact that some sectors are somewhat hidden doesn't help either. They are hidden in the sense that they are difficult to extract the data with standard tools. Most other titles can be cracked from an ATR image. In this case an ATR image would miss some critical data.

 

This is the reason why I questioned to be up to this challenge.

 

My hope is that the code which is executed inside the drive is not obfuscated and straightforward.

Then it might be possible to extract the data of these sectors #27 from the ATX and put the contents to sectors with standard numbers and just patch the reading routine to access these sectors.

Link to comment
Share on other sites

My hope is that the code which is executed inside the drive is not obfuscated and straightforward.

Then it might be possible to extract the data of these sectors #27 from the ATX and put the contents to sectors with standard numbers and just patch the reading routine to access these sectors.

 

The code seems to be present on the disk in cleartext, not encrypted in anyway. Then it should be easy to modify. But of course, I don't know if the program verifies if the code was altered on way or the other. Harvesting the data from sectors #27 would have been difficult back at the day. Nowadays is not big deal.

 

The disk has lot of space. Initially I thought that if it was full, it might be a problem to locate space for reallocating those sectors #27. But I can see it won't be a problem at all.

 

One of the examples in the Atari Magazin tutorials was for reading tracks (I think it is a debug/diagnostic command for the FDC), you could probably get some useful info with this.

Yes, it is one of the main program options (see below). Not very useful for us though. But thanks for the tip.

 

Some more info:

 

The programs requires a Happy with 8K Ram. Older Happy 1050 boards have 6K Ram only. Don't know if the author was not aware and assumed all Happy 1050 boards always have 8K. Or may be he knew but it was difficult to make it work with 6K Ram and he may be, warned the buyers about the 8K requirement.

 

The disk has an additional, advanced protection that I didn't note before! The protected tracks, those with a sector #27, have a special signature at the gap, outside the sector data. It is difficult to access data outside the sectors. The only way to read this with a standard FDC is with read track command. When I saw this I thought it was used as an ever more advanced copy protection, but doesn't seem so ...

 

As mentioned, the program have an option to read the track from a disk using the special FDC Read Track command. I'm not completely sure why the program has this option. If the main purpose is to analyze copy protections, then it is missing the main scan analysis tool, as Archiver has. The point here, however, is that the program has that option. And it seems that the author was afraid that it could be used to read the protected tracks on the actual DiskMaster disk. So the custom code at the drive that implements the Read Track command performs the following:

 

After reading the track, it scans the buffered track for the special signature mentioned above. If the signature is found, it scrambles the whole buffer before the program can download it. So "our" special protected track remains hidden ! :) Again, seems that this protection is used only for this purpose of scrambling the data. The signature doesn't seem to be required to run the program.

 

 

  • Like 1
Link to comment
Share on other sites

Hi,

 

I think if the signature makes the track loader scramble the data, you're hiding the signature, the fact that sector #27 exists, and also the contents of sector #27. Would this show up in the archiver(/editor) in a super archiver, e.g. one that handles 1050 enhanced density tracks?

 

I'm trying to remember the example code from Atari Magazin, I think that the read address example code discards out of range sector numbers, but I can't remember for sure.

 

The example code for reading tracks returns data outside of individual sectors (iirc), so the code in disk master was probably based on this, and just extended a bit. Would be interesting to see how the code in disk master that gets uploaded to the Happy has evolved. Presumably the Speedy upgrade is also supported?

Edited by E474
Link to comment
Share on other sites

The read track code for the Happy is in Atari Magazin, issue 5 (September/October), 1987, page 44 onwards.

 

And attached here, as well as all other programs Stefan published in his AM series... (4 TB XL programs + the read track COM file). The programs are locked on the disk image, so they are easier to find - but I do not think that any of the programs will help in hacking the Diskmaster copy protection...

HAPPY1.zip

Link to comment
Share on other sites

I think if the signature makes the track loader scramble the data, you're hiding the signature, the fact that sector #27 exists, and also the contents of sector #27. Would this show up in the archiver(/editor) in a super archiver, e.g. one that handles 1050 enhanced density tracks?

Yes, it basically hides the whole track. The Super Archiver won't show the signature, of course. I'm not that familiar with the SuperArchiver but I think it will ignore the sector #27 completely.

 

The example code for reading tracks returns data outside of individual sectors (iirc), so the code in disk master was probably based on this, and just extended a bit. Would be interesting to see how the code in disk master that gets uploaded to the Happy has evolved. Presumably the Speedy upgrade is also supported?

Using the Read Track command on an enhanced 1050 is rather cumbersome. In first place the command is designed to be aligned with the index pulse otherwise it might be difficult to align the data you read with the Read Track command. In this case it is much worse because there is not enough ram available to buffer a whole track, even on a Happy with 8K ram, let alone an MFM track. So you need to issue the Read Track command several times to be able to read the whole track. And you need some smart code to be able to combine all the partial readings, which might not be trivial at all. Furthermore, the Read Track command is not very reliable on MFM, and some data can't be read.

 

The version I have is for the Happy only (Happy with rev1 firmware and 8K ram, to be precise). The manual does mention a Speedy version, but no idea if it was released or not. CharlieChaplin might know better.

 

Actually, as far as I can tell, there is no way to encode the signature in an ATX file, as the signature is outside the sector data.

Correct. And actually there is (was) no way to store full long sectors. But as I said, the signature is not required. The program, as far as I can see, doesn't use the signature as a copy protection in the strict sense. Otherwise I would consider implementing something at the ATX specs. But note that Altirra currently doesn't support the Read Track command anyway. And it is understandable. It is a lot of work and this is the first program I've seen that uses this command on the 8-bit (it is very common on other platforms, like the ST).

 

... The programs are locked on the disk image, so they are easier to find - but I do not think that any of the programs will help in hacking the Diskmaster copy protection...

At the time, using the Read Track command would have been useful because there was no tool that could give you much information about those tracks with sector #27. Nowadays we don't need it. There are now better and more powerful means.

Link to comment
Share on other sites

  • 2 months later...
  • 1 year later...
On 4/29/2019 at 10:00 AM, ijor said:

The programs requires a Happy with 8K Ram. Older Happy 1050 boards have 6K Ram only.

 

On 4/29/2019 at 6:06 PM, ijor said:

The version I have is for the Happy only (Happy with rev1 firmware and 8K ram, to be precise).

Requires an 8K happy with Rev1 firmware? That seems almost a nonexistant combination. I've yet to hear of someone, at least in recent times on AA, with such a genuine happy board, other than a clone like "smirk" .

 

Fascinating thread regardless... you could easily store 40 extra 256 byte "invisible" sectors (10KB) on a disk by tacking one onto each track...

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...