Straight cracks from Farb's ATX-Torrent

[+remowilliams]

Hi Remo,

 

 

I might try to improve the VAPI imaging tool for the Happy, if there is enough demand, but it is a bit of a PITA currently. Don't you happen to have low level imaging hardware? Kryoflux or SCP?

 

Hi Ijor!

 

Yes I do have a Kryoflux and I actually found it and a working 5.25 drive! I've never actually used it before... partly because I couldn't find it and a drive at the same time frame.

 

So after a little bit of reading up, lets try: Mail.Order.Monsters.ATX.rar

[Mclaneinc]

2 disk B's?

[+remowilliams]

2 disk B's?

 

Same disk image, different format. If I'm imaging something that I suspect (or know) is unprotected I usually supply an ATR of it as well.

 

Some additional images, D-Bug is complete, only A side supplied for RDS and Seven Cities..

 

 

D-Bug.ATX.rar

Racing Destruction Set.A.ATX.rar

Seven Cities of Gold.grey.A.ATX.rar

 

EDIT: edited for name consistency, same files

[ijor]

Yes I do have a Kryoflux and I actually found it and a working 5.25 drive! ...

 

Just great! But please share the raw dumps as well.

[Keatah]

This is perfect timing since I'm going all 100% original disks. 4am does something similar on the Apple II.

 

Yes! We're seeing a lot of new and unmolested cracks coming into the Apple II archives. I think that both versions, with cracktros, and without cracktros are equally important.

 

These days, a zip file with the unmodded crack + a text file is usually sufficient. And if you do good work, no cracktro screen is required. Everyone in the Apple II scene recognizes a 4am crack and knows it will be a good thing.

 

Now, the REAL reason I made this post.. Where can *I* get Farb's AT torrent??

[+DjayBee]

To Djaybee,

Did you ever figure something out regarding making skew alignment FAIL using an emulator (hopefully Altirra)?

 

According to firestorm my titles won't boot on a floppy and a suspect that it's the same issue you faced with Microprose titles (not being able to make the protection fail).

 

Did using an .atx (as suggested by ijor) work? If so what .atx did you use?

 

I wish there was a option on Altirra to mimic a random skew alignment

 

You're my hero for today.

The empty ATX solved my problem. Finally the plain sector copy crashes and my crack still works.

 

Concerning your disks I believe that the solution does not lie in a properly skewed ATX but the opposite. Remove every trace of timing from the code and hardcode the expected values.

 

I had the same problems with timed duplicate/multiple sectors where the same sector for a certain number of times has to be read within an expected time frame.

Typically they do the following:

LDA #0

STA RTCLOK+2

... read same sector n times

LDA RTCLOK+2

CMP #<expected value>

 

Each time i changed the number of reads or the CMP-value to anything then it failed under certain conditions

SInce then I do it this way:

LDA #0

STA RTCLOK+2

... read same sector n times

LDA #<value_from_ATX>

CMP #<expected value>

 

I guess that something similar should work for skewing as well.

[Roydea6]

 

Yes! We're seeing a lot of new and unmolested cracks coming into the Apple II archives. I think that both versions, with cracktros, and without cracktros are equally important.

 

These days, a zip file with the unmodded crack + a text file is usually sufficient. And if you do good work, no cracktro screen is required. Everyone in the Apple II scene recognizes a 4am crack and knows it will be a good thing.

 

Now, the REAL reason I made this post.. Where can *I* get Farb's AT torrent??

http://atariage.com/forums/topic/234684-atari-8-bit-software-preservation-initiative/?p=3230078

 

This is the first of the series. Later ones have corrections plus adds to the Torrent..

[Keatah]

Great thanks man! I'll be sure to seed it for a while too.

[+Ripdubski]

The SynTrend - Stat disk in the archive does not work correctly. The Format disk, and Save File routines fail. The Format disk will not report error, but doesnt work. The save file reports acts like it will work, sounds like it starts to work (serial io), then eventually gives error 138 (device timeout). I was able to create a data disk on real hardware using the real disk, make an atr of the data disk, and use the image Load file - so at least load is working.

 

BTW, the version in the archive is the 1985 version, even though it states 1983 copyright. I have only seen minor differences in the version, mainly in the load editor splash screens. The 1983 version uses graphics 1, and displays additional text once the disk load is done (but before it is ready to run). The 1985 version uses graphics 2, and only says "loading editor" even after the disk load is complete (but before it is ready to run). I validated this on real hardware with real disks as well.

[Diaperboy]

To Djaybee,

Another way I was thinking about to defeat sector skew alignment was to alter the sector numbers that get read during the check. On EA disks, it reads sector #1 a bunch of times, then reads a bunch of random-ish sectors. All the random-ish sector numbers are the FIRST sector on the track. If I replaced all the random-ish sector reads with repeatedly reading sector #1, I suspect it would eliminate the sector read timing variations.

[ijor]

The SynTrend - Stat disk in the archive does not work correctly. The Format disk, and Save File routines fail. The Format disk will not report error, but doesnt work. The save file reports acts like it will work, sounds like it starts to work (serial io), then eventually gives error 138 (device timeout). I was able to create a data disk on real hardware using the real disk, make an atr of the data disk, and use the image Load file - so at least load is working.

 

In which archive? I don't see SynTrend in the Torrent, if that's what you mean.

Also, which emulator are you using?

[+Ripdubski]

Yeah, nm. Apologies. I just checked and it wasn't from the torrent (which is what I meant). Not sure what the hell I was thinking. Now I need to track down where...

[Diaperboy]

I think I have solved the sector skew issue in the EA sector skew (40 sector boot) copy protection.

 

When the copy protection runs it first checks for the double sector. After checking for the double sector (which had previously been patched), the protection routine reads sector #1 a bunch of times. After this (NORMALLY) it reads the FIRST sector of several "random" tracks in pairs (#199 - #19 / #73 - #37 / #91 - #55 / #19 - #73 / #163 - #91...). These pairs are located on different tracks. It compares the timing variations between reading each pair.

 

Tracks ALL aligned = similar timing variations between reading the pairs. (ORIGINAL)

 

Tracks NOT aligned = larger variations in timing between reading the pairs. (COPY)

 

This patch manipulates the "random" sector reads so that the pairs are always matching (#19 - #19 / #37 - #37 / #55 - #55 / #73 - #73 / #91 - #91...). This seems to defeat the sector skew. I suspect this is because the timing of reading the SAME sector twice would be similar no matter how the tracks were aligned.

 

Hopefully somebody can test this out on a floppy on genuine Atari hardware. I have included an .atr version AND an .atx version. The .atx is not copy protected, but I have included it because it was written on a "blank" with random sector skew (like a disk formatted on a 1050 drive). This emulates random sector skew on Altirra emulator. If I am correct the .atr version SHOULD be able to be written to a floppy and boot correctly (fingers crossed)

 

M.U.L.E.zip

[+DjayBee]

Yes I do have a Kryoflux and I actually found it and a working 5.25 drive! I've never actually used it before... partly because I couldn't find it and a drive at the same time frame.

 

If you happen to find your MECC-originals and dump them you might bring a happy face to Kevin Savetz and Allan.

 

On EA disks, it reads sector #1 a bunch of times, then reads a bunch of random-ish sectors. All the random-ish sector numbers are the FIRST sector on the track.

 

This is the same as the MicroProse titles I cracked. If you look inside the ZIP in post #57 you can see the code fragment on how it is working.

[Diaperboy]

remowilliams

 

Thanks so much for the copy of D-Bug. It's 130XE OS compatible too...SWEET!

[ijor]

Re: Syntrend

 

Yeah, nm. Apologies. I just checked and it wasn't from the torrent (which is what I meant). Not sure what the hell I was thinking. Now I need to track down where...

 

Ok. But it is an ATX (VAPI) image? Or it is a crack (ATR image)?

[ijor]

I think I have solved the sector skew issue in the EA sector skew (40 sector boot) copy protection.

 

This patch manipulates the "random" sector reads so that the pairs are always matching (#19 - #19 / #37 - #37 / #55 - #55 / #73 - #73 / #91 - #91...). This seems to defeat the sector skew. I suspect this is because the timing of reading the SAME sector twice would be similar no matter how the tracks were aligned.

 

Any reason why not removing the reading of those sectors altogether, and just patch the routine that checks the result? Or is that on purpose to make it as much close to the original as possible.

 

One interesting issue precisely about this. The original disk once in a while does fail. IIRC, the timing would be wrong if a VBL interrupt is triggered at some specific point. And that's besides possible failures because the drive rotation time is not that constant.

 

Your way of cracking would preserve that behavior. Not judging if it is a good thing or not. Just noting

[firestorm]

MULE works on real Atari 1050, big thanks to Diaperboy!!!

[Roydea6]

Thanks for all the encouragement! I'd like to thank the original poster for all his hard work as well.

Here are the rest of the EA titles (skew align copy protection - 40 sector boot) that I have. I don't have a copy protected image of D-Bug, so that will have to wait...for now

 

Type A:

Music Construction Set

 

Type B:

Axis Assassin

Financial Cookbook

Hard Hat Mack

Word Flyer

 

Type C:

Murder On The Zinderneuf

Worms?

Electronic Arts II.rar

This is the first time I ever tried to run the Program Worms? This is a 4 person paddle program. I never liked paddle games and also never had 3 other people to play with because my children would rather play shooters like GTIA Blaster.

 

Main reason I am posting is because I am wondering if any one has a save Worms secondary disk with saved worms..

[Diaperboy]

to firestorm,

Thanks, once again, for testing Archon on a floppy. I'm glad that it works! You rock!

 

to ijor,

Absolutely no offense taken in regards to asking why I patched the sector skew check the way that I did Questions are good. There are several reasons I chose to re-direct the sector reads instead of changing the code that checks the results.

 

One reason was to keep it as close to original code as possible. Another reason was to keep the "theme" of this crack the same. I used the same re-direct method to defeat the double sector check...meaning I didn't patch the code that checks the results of the double sector check, I just re-directed which sectors get read during that check. Another reason was because both the double sector check and the sector skew check use the SAME memory location to know which sector to read next. I didn't have to do any "research" because I already knew the location. It will also be easy to find the sector skew patch locations in the two other memory layouts (types) of this copy protection.

 

There is a THIRD aspect to this copy protection that I have also left intact and completely unaltered. There is a data check (checksum?) that detects ANY alterations to the disk (at least all the data of the copy protection routine anyway). This data check starts high in memory location (and in sector number) and sweeps towards the lower memory locations. My crack "avoids" this data check instead of defeating it. It takes advantage of the fact that it is a high-to-low data check and runs only once. (EA super-tracks copy protection runs the data check more than once )

 

The area that needs to be patched to defeat the double sector check is located on sector #23 (the sector skew patch is located somewhere near this). The problem is that, IF I patch this location on the disk it will FAIL the data check. Even worse, it will FAIL too early to be able to use my patch at sector #11. (everything relies on this) I left sector #23 unaltered, but instead used the patch on sector #11 to jump to a subroutine that patches the code located on sector #23 (in memory). This occurs AFTER the data check at this memory location (high), so it finds nothing altered. It also patches the sector skew at this time.

 

Because the data check sweeps to lower memory locations, the patch on sector #11 WILL get detected by the data check. To avoid this, the first subroutine unpatches the patch made to sector #11 (in memory) restoring it the original value. This happens BEFORE the data check at this location (low), so it finds nothing altered.

 

This crack, essentially, is not really cracked on the disk but done "on-the-fly" in computer memory each time it loads. The ONLY alteration to the actual protection routine code is on sector #11 (changing a JMP location). All the other needed code is essentially "stow away" on the disk (sectors #18,19,40). These areas don't contain protection routine code and are not subject to data checks. Sector #40 is the last sector loaded and is not full. I use the space after the data. I really don't know what the data on sectors #18,19 is for (if anything) there is a bunch of empty space, but I do end up over-writing a little bit of "code" on sector #19. Changing or over-writing this data seems to have no effect on the copy protection (or anything for that matter).

 

I'm going to "port" the sector skew defeat patch to the other memory layouts of this copy protection soon.

[ijor]

There is a THIRD aspect to this copy protection that I have also left intact and completely unaltered. There is a data check (checksum?) that detects ANY alterations to the disk (at least all the data of the copy protection routine anyway).

...

The area that needs to be patched to defeat the double sector check is located on sector #23 (the sector skew patch is located somewhere near this). The problem is that, IF I patch this location on the disk it will FAIL the data check.

 

Well, the idea of removing the protection check altogether, obviously involves patching that routine that checks alterations as well.

 

But again, I'm not judging your cracking method. I was just curious about the reasons you preferred it over a more "classic cracking" approach.

[Diaperboy]

To ijor,

 

Questions are a good thing.

As to why I left the data check intact...mainly to keep the "theme" the same. Really NOTHING about this crack conforms to a "classic" cracking job. All three of the protection routines are still intact. I've just altered what gets checked, so it conforms to what the protection routine expects to see from a genuine disk.

 

Leaving the data check intact also makes it a bit more fun to crack. Kinda like "mission impossible" breaking into an art gallery and "avoiding" the alarm system...I know it's a bad comparison. Lol.

 

I've nearly got the code "ported" to all 3 types. I've also been working on adding an "easter egg" to the load screen just for fun. No it's not a "crack intro" or anything like that, it just changes the load screen IF it's triggered.

[Diaperboy]

Wondering?

Has anybody used copy / paste when running Disk Wizard II on Altirra emulator? I tried it last night and it works absolutely GREAT!

One of my biggest problems when editing disks using Disk Wizard II has been typing in the hexadecimal code CORRECTLY. The code might work, but if it's not keyed correctly it's not going to work.

By having the code set up correctly on notepad, it can be pasted directly into Disk Wizard II. YES! multiple lines of code!

 

Code set up like:

 

$4C

$01

$00

$9A

$00

 

Can be pasted into Disk Wizard II using Altirra emulator.

[ijor]

I've nearly got the code "ported" to all 3 types.

 

Shouldn't be four types now? The ones I sent you aren't a different variant?

 

[Diaperboy]

To ijor,

Yes you are correct. The older OS compatible titles are different...quite different in fact. I might even call them a different protection scheme alltogether.

 

The EA sector skew copy protections that I've labled Type A, Type B, Type C are IDENTICAL in operation and structure, with the exception of having different memory location layouts. All the same commands are located on the same sector in the same place on each sector.

 

The Older OS compatible titles (Worms, Murder on the Zinderneuf) actually have a different structure than Type A, B, C. They seem to operate in a similar manner, but they are different. The older OS compatible titles actually boot to sector #36 (not sector #40) before starting the copy protection. There is some data "missing" in comparison to Types A, B, C. My sector #11 patch seems to be in the same place, but I'm not sure about the rest. I used sector #40 on (Types A, B, C) as a place for my data to be a "stow-away" to get into memory, but those titles don't boot to sector #40. I suspect my "stow-away" locations on sectors #18, 19 will be in a different location or possibly not exist at all (the missing data had to come from somewhere).

If that's the case, I will have to "insert" an extra sector or two into the boot process (done by modifying the second byte of the first sector). I think the initial boot is 5 sectors, then it reads sectors #6-36. By extending the initial boot, I will have to redirect the reading of sectors #6, 7 to another location on the disk. If I leave the data check intact (which I probably will) I'll have to patch out the initial boot extention and the redirected sectors. I used the same method to "insert" sectors into the Archon II boot process, so I know it can be done.

 

I'm not sure if I'll work on the older OS compatible EA titles or the EA super-tracks titles first. I have already covered the older OS compatible games in Types A, B, C, so there won't be much to "gain" by doing them. I've only pulled off one EA super-tracks copy protection crack (Archon II), so I'm curious to see if I can do more.

 

I will be posting all of the EA sector skew align titles (Types A, B, C) tonight. They all defeat double sector checks and sector skew alignment checks. They all have a hidden "easter egg" in the loading screen as well.