[hatari-devel] TOS use of PRG_ssize vs Hatari's

[Troed Sångberg <troed@xxxxxxxxxxx>]

Hi all,

I've spent the last few days analyzing a protection scheme released in 1994 for the Steinberg Synthworks programs. Before their last release they used dongles exclusively, but in 1994 it was changed so that you only needed to run them once with the dongle inserted, after that they could run without one as long as you didn't try to change their path, move to another system etc. The thread on this can be found here: https://www.atari-forum.com/viewtopic.php?t=43138

I got interested since the thread starter had already figured out that the only thing that differed after having done the first dongle-run was four bytes in the beginning of a file - and when I looked at the hex dump I realised that the file (named ".BIT") was in fact an executable. Thus, these four bytes were in the actual PRG header.

It's the symbol size field, "PRG_ssize" in the Pexec Cookbook. And this had me stumped for a while. The way we know the offset to the FIXUP table is, again according to the Pexec Cookbook, "PRG_tsize+PRG_dsize+PRG_ssize+$1C" so having a PRG_ssize of (actual example) B3 24 77 2C seems absolutely impossible - it would point right outside of any available memory size. And indeed, when I traced the launcher .PRG it did a Pexec 0 on the file and got the error "-66 EPLFMT Invalid program load format" back.

So I turned to the experts in #atariscne, George Nakos (ggn) and Steven Tattersall (tat).

Tat mentioned that since I was using hrdb/Hatari there was a different Gemdos implementation in action, and pointed to this piece of code:

https://github.com/tattlemuss/hatari/blob/e26acc62dd2bacd94742da122bade686801efd67/src/gemdos.c#L4337C10-L4337C10

ggn went and looked for what TOS does with PRG_ssize:

xlseek(flen + prg->g_ssize + sizeof(PRG), h, 0);

xread(h, 4L, &relst);

  if (!relst)

    goto zrobss;

I then copied the program to a disk image and turned off Hatari's Gemdos hard disk - and that went fine (since Hatari is then using the TOS code) and I could Pexec the program.

So, this seems to be an extremely unknown (ab)use of TOS specific behavior than nonetheless is part of released commercial software. Additionally, it _seems_ as if Hatari is not the only codebase not emulating this correctly. I cannot launch the code on my Mega ST either - but it runs HDDriver, USB2TOS and Bigdos and I don't know which if any of those would be the culprit. Zeroing out the PRG_ssize field works fine in both cases.

TOS using PRG_ssize only as a parameter to a seek means (AFAIK) that any value that ends up seeking to the end of the file becomes capped - and so it is possible to "store" data in PRG_ssize, just as the app is doing. (They store a "hash" of system information on the first dongle-use run and then compare that hash to known values on subsequent usage).

regards,

Troed