View Single Post
Old 03 December 2019, 19:11   #236
jarre
Registered User
 
jarre's Avatar
 
Join Date: Sep 2016
Location: Deventer - Netherlands
Posts: 599
don't know for sure but gateway Y, from golem seems to be a bitch........

found it:

Quote:
Originally Posted by Galahad/FLT View Post
it is quite an ingeniously setup protection.

So Disk 1 is part interrupt loading format and part standard MFM, with $1900 size tracks.

Disk 2 is entirely interrupt loading format, and that format is like this.

So interrupt disk format is two different sync marks, $4489 and $4522, but the data is structured not as one complete $1900, but as two big "sectors" of $c80 bytes.

So first part of track is $4489 and $c80 worth of data, then the second part of that track is $4522 and also $c80 worth of data.

The problem is that the programmer only loads in $c80 sizes when interrupt loader is running, which means he has set a REALLY small track buffer to decode MFM data, which is neatly positioned inbetween code and onscreen graphics, when wanting to load next half of the track, he just swaps the SYNC and it will load the next part, of course AmigaDOS $4489 style track can not be decoded in such a tiny memory space and there is literally NO room in 512k in which to do it.

The disk format is also quite large, $FA000 per disk, so even if I could find the room, I wouldn't be able to fit all the data on the disks and keep it as two like the original.

Lots of sneaky stuff, like if you try and bypass his interrupt loader entirely, it will miss stuff that is setup in memory for other routines which will crash, lots of self modifying encryption (the weakest part of the protection), checksums (again, strangely weaker than the disk protection), if you try and mess with the interrupt loader, it does stuff like seek to track 83 which is all kinds of fun the first time it happens!!!!!

So now i've had to change the interrupt loader system to a multi loader, I have to preserve chip memory to extra memory so I can load the different parts and then restore that used memory, it was quite the headache to figure out a system that wouldn't fall foul of the programmers stuff trying to trip me up.

Very competent protection, and a few schoolboy errors by me along the way didn't help either!
and also a note from the prgrammer:

Quote:
"Hi cracker, very good!!! But warning: This could be your last crack signed Hans Tel: Int 43 2633 2100"

Last edited by jarre; 04 December 2019 at 06:17.
jarre is offline  
 
Page generated in 0.06815 seconds with 11 queries