Alkatraz obfuscation?

[Irmak]

I've been working on TaylorMade, Alan Cox's interpreter for later AdventureSoft games, adding support for graphics among other things (for modern computers). Most files load just fine, but some of the tzx file versions contain data that is not quite the same as the memory contents you get after loading it. It seems to be obfuscated somehow (or compressed, but the size seems to be about the same as the final data.) Fuse reports the loader as Alkatraz.

I'd like to convert it into something useful (directly, without going through an emulator), and I'd like to know if anyone has investigated this format already.

[Stu]

Some versions of Alkatraz have the game data encrypted, and decrypt it after loading using the contents of screen memory as part of the decryption process -- if this is the case for the games in question then I'm not sure how easy it would be to convert it without using an emulator tbh.

[Irmak]

Thanks! I'll guess I'll just have to take a long, hard look at the disassembly then. The screen data is there in the file, so it shouldn't be impossible to replicate what the loader does, but probably a lot of work.

[zup]

Not feasible without an emulator.

Alkatraz loader is a beast, than includes tenths of decryptors. From the start, it uses many cheats to keep you from seeing it's code (anti MERGE, anti LIST, point of entry obscured through clever use of ERROR system variables). Then it uses a decrypter that decrypts... another decryptor and more encrypted data. And it goes on and on. That pause that lasts some seconds between BASIC loader and the game is the time it takes to the loader to be decrypted, go figure how many layers of code are inside it.

And then it loads the game code. A game code that is almost an entire snapshot of the memory and... it's encrypted. Fortunately it is only encrypted one time.

The good news is that you can (easily) got through it with an emulator. Most times, the game is left in a pre-execution state where the BASIC system variables and registers are fine, before executing the game. So you may try:

1) Start loading the game on an emulator (not using fast-loaders, I'd recommend using ZX Spin and edge detection so loading is fast but not instant).
2) Pause the emulator after the screen is loaded (in ZX Spin, press TAB).
3) Put a conditional breakpoint when tape is stopped (br tape:stop in fuse) or anywhere outside the loader (i.e.: pc<64000).
4) Continue loading until it returns to debugger.

So you should end in a state where the game is not still executed but loaded and fully decrypted. Then make your snapshot or peek around to see if the (original) BASIC loader is still on RAM or there are calls to addresses around 1218 (SAVE routine), so you can find the original start address of CODE blocks and make a (better or simpler) loading scheme.

Or, if you feel lazy, load the game entirely and make a snapshot ASAP after loading (better a .SNA snapshot, because it is not compressed and may be easier to examine later).

[Bedazzle]

(better a .SNA snapshot, because it is not compressed and may be easier to examine later).

It is better to use Z80 format.

https://sinclair.wiki.zxnet.co.uk/wiki/SNA_format

The program counter is not stored in the header. Instead, the behaviour of a real Microdriver is emulated: when the snapshot is made, the program counter is pushed onto the stack. To resume execution, an emulator should simulate a RETN instruction, which will copy IFF2 to IFF1 and retrieve the program counter from the top of the stack. This use of the stack can cause problems if the stack pointer is in ROM at the time the snapshot is made, or if the stack is being used to copy data.

[zup]

It is better to use Z80 format.

https://sinclair.wiki.zxnet.co.uk/wiki/SNA_format

The program counter is not stored in the header. Instead, the behaviour of a real Microdriver is emulated: when the snapshot is made, the program counter is pushed onto the stack. To resume execution, an emulator should simulate a RETN instruction, which will copy IFF2 to IFF1 and retrieve the program counter from the top of the stack. This use of the stack can cause problems if the stack pointer is in ROM at the time the snapshot is made, or if the stack is being used to copy data.

Yes, it is true... if you MUST preserve the game exactly as is. As you said, if SP is pointing to ROM or if stack is very tight and you manage to write outside the reserved "frame" you might end with an unusable or a (maybe non-obvious) corrupt snapshot.

At least in theory... 99% or more of snapshots taken will run as intended.

My point is that you'll want to have an uncompressed, flat-model snapshot for easier analysis. Z80 has the disadvantage that (by default) most emulators will use the "compressed" variant, and (due to format definition) nobody grants you that RAM page 4 comes after RAM page 3 in the snapshot (well, that also happens in 128k sna snapshots).

[spider]

You might find a regular .tap / .tzx that's been built out of the game rather than the original loader, I don't mean a snapshot tap file , a conventional loader version. They may exist as .trd disc or .tzx images perhaps.

As said Alcatraz is quite complex, its sort of like the "next gen" Speedlock, well I see it that way. There's a shedload of decryptors in it. Must of been fun "back then" trying it with a Multiface (which iirc it can detect and crash your machine) and a disassembler. Its hard enough (for me at least) with an emulator where I can quickly revisit it and insert as many breakpoints as I want.

Seem to recall a magazine article on the various loading schemes, Jon North maybe did them ?

[Irmak]

So far, I've found that the decryption takes place during loading, not after. Looking at the memory contents when the tape stops, the unencrypted data is all there, and the loader just has to move it into position.

[spider]

So far, I've found that the decryption takes place during loading, not after. Looking at the memory contents when the tape stops, the unencrypted data is all there, and the loader just has to move it into position.

I've not looked closely but early Speedlocks do that (later ones too but its encoded on those) and they sort of shuffle the code about a bit, SPL1 uses what was the 'printer buffer' area on the 48K machines for this purpose, at least in the one I looked at a while back.

[jpnz]

I've been working on TaylorMade, Alan Cox's interpreter for later AdventureSoft games, adding support for graphics among other things (for modern computers). Most files load just fine, but some of the tzx file versions contain data that is not quite the same as the memory contents you get after loading it. It seems to be obfuscated somehow (or compressed, but the size seems to be about the same as the final data.) Fuse reports the loader as Alkatraz.

Which titles are you working with?

I'd like to convert it into something useful (directly, without going through an emulator), and I'd like to know if anyone has investigated this format already.

The source code for the Alkatraz saving/loading routines have recently been uploaded to the archive:

Code: Select all

Saver/Loader Source Code Listings for the Alkatraz Protection System 

The 6 files in this archive are listings of the tape saver/loader routines
that are used by the Alkatraz Protection System:

	    C.S -  48K counter only
	    M.S -  48K message scroller only
	   MC.S -  48K message scroller and counter
	 C.S128 - 128K counter only with bank support
	 M.S128 - 128K message scroller only with bank support
	MC.S128 - 128K message scroller and counter with bank support

Note that the C.S listing has an issue on line 00271

	00271   LSTC   DEFW FLEADR-LN2

By reviewing the other listings, this can be corrected with the following code

	00271   LSTC   DEFW 16384

These listings can also be found on the the microdrive "06 - Loaders" in the main download image

[Irmak]

Which titles are you working with?

Right now I'm looking at Temple of Terror (graphics version). The other titles that use Alkatraz are Terraquake (Masters of the Universe) and Kayleth.

Thanks a lot for the link to the source code!

The actual decryption seems to happen in the "Fast Load" routine at line 330 in the file named C.S, line 327 in the file M.S and 328 in MC.S. A byte is loaded from the tape pretty much as in the ROM tape loading routine, into the L register. A stored byte value (called LOACON in the source) is loaded into A which is then XORed with D, E, IXh, IXl, and then finally the with the byte loaded from tape, held in L. At this stage i think DE holds the remaining number of bytes to be read from tape, and IX is the address to be written to. After this, A holds the final decrypted byte value, which is written to (IX+0).

The tricky part is the calculation of the LOACON value. I haven't figured that out yet.

[Irmak]

Update: I can now decrypt the Temple of Terror tzx file on the fly.

I cheat a little by looking at the memory contents in Fuse at the start of the decryption process and copying some "magic numbers" rather than trying to calculate them in the same way that Akatraz does, but as I'm only doing this for three games, it is not much of a problem.

Thanks a lot to all who helped!