'Track-to-track alignment'
Author:Lord Crass (guest: search)
Date: Fri, Apr 08th, 2011 @ 01:51 ( . )

Was looking at the DiskMaker Plus protection this evening and saw that it checks track alignment between track 20 and 21. It reads from track 20, then steps the head to 21 and reads the next header. This header needs to be from sector 7 or it will crash. The image I have loads track 13 in the emulator instead, and therefore doesn't work.

I was going to try cracking it since I've never seen a proper crack or parameter for this one, but thought of a different approach instead...

What if I just swapped sector 7 and sector 13 in the G64 image file?

It worked in Vice! (Note this title is NTSC-only). Sort of an ugly hack I suppose. A cleaner method would be to rotate the whole track ahead by 6 sectors so that you keep any expected sector skew that the fastloader might be taking advantage of.

BTW Pete, your disk database shows DiskMaker Toolkit as having no protection, but the SuperCard+ disk has a parameter specifically for this, and all the other DiskMaker programs are quite heavily protected so it seems unlikely there'd be no protection on that one. Perhaps someone ran the parameter on the copy you have in the database?


REPLY: [With No Quote] --- [With Quoted Text]

'Track-to-track alignment'
Author:hyper active (registered user: 296 posts )
Date: Fri, Apr 08th, 2011 @ 06:45 ( . )

protections such as rapidlok check track alignment, it can be remastered in nibtools by using the -t switch. -t for track alignment.
nibwrite -t -S20 -E21 filename.nib.


REPLY: [With No Quote] --- [With Quoted Text]

'Track-to-track alignment'
Author:Pete Rittwage (registered user: 558 posts )
Date: Fri, Apr 08th, 2011 @ 08:47 ( . )

It's certainly possible- or I made an error when cataloging.

I recall that DiskMaker had a skew protection that required me to add the skew option in nibwrite. This one didn't work with straight track alignment, but had a 50us skew or something similar. I'll look into adding the skew support to G64 output as well.

In VICE, all tracks are always perfectly aligned since it resets to the start of track every time a new track is accessed, instantly.


REPLY: [With No Quote] --- [With Quoted Text]

'Track-to-track alignment'
Author:Lord Crass (guest: search)
Date: Sat, Apr 09th, 2011 @ 16:36 ( . )

I properly rotated track 21 in the g64 image so the protection works in emulators and keeps the original sector skew. I also removed the protection and created a d64 image that works as well. I've sent both copies to you, Pete.

The fast loader on this one is V-Max again. I had no idea how common V-Max was outside of games, where it was always shoved in your face during the initial loading.


REPLY: [With No Quote] --- [With Quoted Text]

'Track-to-track alignment'
Author:Pete Rittwage (registered user: 558 posts )
Date: Sun, Apr 10th, 2011 @ 21:13 ( . )

How are you sending? I must have missed the e-mail...


REPLY: [With No Quote] --- [With Quoted Text]

'Track-to-track alignment'
Author:Lord Crass (guest: search)
Date: Tue, Apr 19th, 2011 @ 01:17 ( . )

Took another look at DiskBusters 2. It's a track-to-track synchronization protection.

V-Max loader is at track 1, then it immediately steps back to track 18, reads the sector 0 header, then steps to 19 and reads the first sector header that comes along. It then takes the sector number and adds it to the current track number, then steps to that track and does it again. It does this 4 times.

The final track number that you land on is used as a decryption key for some drive code that gets uploaded right before the copier starts.

The final track you need to land on for the correct key is track 30 (the key is $1e).

It probably doesn't match the original, but you could easily fix the image to pass the protection by rotating the 2nd last track it normally lands on (track 23 for the d64) so that sector 7 is the first sector it finds. You could even do this in a D64 and it will work.

Needless to say, this is one of those copiers that can't copy itself. What a ringing endorsement for its abilities...

Interestingly, the name Paul Rowe is mentioned in the code. This is likely the same Paul Rowe who co-wrote DiskMaker Plus (another one that couldn't copy itself) along with Mike Howard (who was also a programmer on the Maverick copier)


REPLY: [With No Quote] --- [With Quoted Text]


--- 0 Users Online --- 0 Recent Unique Posters

Q67=1656901655 - Threads: / 1656901655