How to use of The Gnome Services' Analyser utility
An interesting little article that gives a few tips on custom formatting and the like. It relates to the use of The Gnome Services' Analyser utility ... but there are plenty of ST utilities that can do the sort of things discussed here.
This section has nothing to do with "yer actual software piracy", but might prove interesting for the budding hacker .....
If by now you've used the Analyser on a few Games disks, because they seem to be the ones with the most aggro for honest hackers, I bet you're puzzled at some of what you've seen. Well, without giving away any secrets, no specific disks, etc, let's just talk a bit about what we could do to PROTECT a disk from those nasty pirates ............. or even someone who's bought a disk and can't use it without always shoving the original in drive B - probably the largest cause of hacking to date.
The first thing to do is to format a disk with more than 9 sectors per track, this is assuming a 512 byte sector of course - simple and probably old hat by now, but it catches out GEM.
In a similar vein, the good old ST uses 80 tracks - 0 to 79 - so if we format a disk with 81, then poor old GEM can't copy it. Bit naughty that one - you are assuming everyones' drive will reach the 81st track .......
Before we get a bit deeper, here's one that you can easily do yourself ... go and hide a file on the disk. How ? Well, have a look at the Hacking.doc for a few more hints, but by changing the file attribute you can make it invisible to the desktop. Of course this means you can't load it by clicking on it with the mouse - have to see it first, don't you ? BUT, you can still load it from within another of your programmes ........ go on, have a go !
We can be a bit more devious - the WD1772, which is the chip controlling your Atari drives, will write sectors of 128, 256, 512 & 1024 bytes long - but GEM can't cope with 1024 byte sectors. In fact it normally doesn't use anything but 512 byte sectors. So we can upset the operating system quite well by writing out some 1024 byte sectors, or even the 256 byte sectors if we want to. Or we can be really devious and write a track which has a mixture or 256, 512 & 1024 byte sectors on it - which will confuse the simple copiers.......
While we're talking about sectors, we don't have to start off with a sector ID number of 1 you know. No reason why our track shouldn't start off with sector 10, then go to 11, 12, 13, etc .... Really beggars up your operating system if you try to copy it as well......
Another thing to bear in mind is that if sector ID numbers are out of sequence, it is likely that the operating system won't find them - neither will most Disk monitors based on the orthodox operating system. What do I mean ?
Well, if you had a sequence of 1, 2, 3, 5, 6, 7 then GEM would stop at sector 3 - because it would expect to find a sector 4 and if it couldn't find one, than it terminates the command with an error. So you could hide something quite handy in sectors 5, 6 & 7.
Along with the actual sector ID number, we could put a different track number in the Sector ID field. Why ? Well, under GEM the track & sector number are tested before a sector is loaded. If the track number is different from the track register logged by the WD1772, then we have another error, don't we folks ? And guess what happens - it doesn't load !
A real nasty one is to send out sector or track numbers above 240, or anything with $F0 as a hex number. Now this is sneaky because bytes above $F0 are treated as control bytes by the WD1772 and it means a custom format routine to duplicate this.
What else can we do ? Well, we can write out sector IDs without actually putting a sector there, can't we ? Yes, of course we can. Then when you try to copy the disk you write out a sector where one doesn't really exist on the original - now that would be silly. In fact you could arrange the dummy ID field so that if you tried to write to it, the data area you created actually wrote over a VALID sector ID field, and hence the rest of the track was corrupted ......
Up to now, we have assumed that we are actually going to format a track with sectors. Don't have to you know. We can quite easily NOT format a track in the middle of a disk, and then after the programme has loaded, check the track to see if it has been formatted. Got to stop those nasty hackers somehow.
In fact, we don't even have to send out sectors in order to read information from a disk - we could just send out a few sync bytes and then a data mark. Ok, the data stands a fair chance of being corrupted but you can generally get the first 5 or 6 bytes reliably - enough for a registration mark.
Well, now most of these methods are becoming a bit old hat nowadays, but they do keep cropping up .......
