How to automatically calculate offsets + larger file size

[maehw]

Hi!

In test.sh you're using a fix offset of $((0x0256130A)).

Can you please describe the steps how this value has been determined?

It would be interesting how this can be automated.

When you're patching in the modified version, you use zero-padding (with $((2828 - "$(wc -c < test.bin)")) bytes). Is there a way of patching larger binaries than the original version or would this break everything?

If it breaks things, do you see a chance to make larger space for bigger patched binaries with tttool?

Cheers

[nomeata]

I used tttool explain:

~/projekte/tiptoi/binaries $ tttool explain WWW\ Europa.gme |grep Single\ binary\ 2
At 0x025612EA Size       32: Header/Single binary 2
At 0x0256130A Size     2828: Header/Single binary 2/OidMain.

I don’t think it would be hard to let tttool assemble take in binaries just like audio files, and will add that in due time. Ideally, I first find out how binaries address the audio samples (as their order is currently not perserved by tttool).

Is there a way of patching larger binaries than the original version or would this break everything?

So far I didn’t need that, and first removed parts of the binaries that are not used.

If it breaks things, do you see a chance to make larger space for bigger patched binaries with tttool?

It would probaly work to append the new binary to the file, and just patch the new offset into the header.

[maehw]

Thank you for pinpointing me to tttool explain. I get that we detect binaries there. Why is it specifically "Single binary", is there some alternate " Multiple binaries"? How do you know that its the 2nd and not the 1st binary? I must have lost track in the last months to years. :)

Indeed, it would be great if tttool assemble could be used for that! :+1:

Appending binaries that are bigger than the original at the end of the file seems like a reasonable workaround to circumvent re-calculation of offsets, right!

Having bigger binaries than the original will allow us to "inject" further code for a more detailed runtime analysis.

https://github.com/maehw/snowbirdopter/tree/master/examples/dump_regs_inside_gme should offer a proof of concept for that, where the assembly function _still_works relates to your still-works.txt. Dumping of registers has been discussed on the mailing list.

IIRC you also do not have the book, do you already have a document for print so that I could try a modified version? Edit: just discovered "WWW Europa.pdf". ;)

[nomeata]

Thank you for pinpointing me to tttool explain. I get that we detect binaries there. Why is it specifically "Single binary", is there some alternate " Multiple binaries"?

It seems that every GME with binaries has three “main” binaries (one for each generation), and then three sets of “games” (one set for each generation, likely one binary per game). The single binaries are the ones running at start, so I am focusing on these.

How do you know that its the 2nd and not the 1st binary? I must have lost track in the last months to years. :)

Trial and error; zeroed out the offset to one after another until my pen wouldn’t load the file anymore.

IIRC you also do not have the book, do you already have a document for print so that I could try a modified version? Edit: just discovered "WWW Europa.pdf". ;)

Right, which is just the output of tttool oid-codes for this file :-)

[maehw]

Thank you for the clarification.

For "WWW Europa.gme" I get:

Checksum found 0x20B2A9BB, calculated 0x20B2A9BB
At 0x0255C202 Size       32: Header/Single binary 1
At 0x0255C222 Size     2832: Header/Single binary 1/OidMain.
At 0x025612EA Size       32: Header/Single binary 2
At 0x0256130A Size     2828: Header/Single binary 2/OidMain.

So I don't quite understand why you say 3 games and 3 generations.

For "Spielfiguren1.gme" I get:

Checksum found 0xC81C6087, calculated 0xC81C6087
At 0x01A1E58F Size       32: Header/Single binary 1
At 0x01A1E5AF Size    18036: Header/Single binary 1/Main3201
At 0x01A2C28B Size       32: Header/Single binary 2
At 0x01A2C2AB Size    18032: Header/Single binary 2/Main3202

I again see only 2 binaries - so 2 generations and 1 game?

Are the names derived from the contents of the binary? The 3201 and 3202 probably refer to the pen generations/processor, I got that. Are they always executed when you scan the game activation OID as far as we know?

Best regards Matthias

Edit: What do you get for a patched file (with "still works" code)? "Bitte lade die Audio-Datei ..." or "Berühre erst das Anchaltzeichen" or rather normal behavior?

[nomeata]

Did you scroll far enough? I get

$ tttool explain WWW\ Europa.gme|grep -i binar
At 0x0255C202 Size       32: Header/Single binary 1
At 0x0255C222 Size     2832: Header/Single binary 1/OidMain.
At 0x0255CD5E Size       32: Header/Binaries 1
At 0x0255CD7E Size    17728: Header/Binaries 1/Game1.bi
At 0x025612EA Size       32: Header/Single binary 2
At 0x0256130A Size     2828: Header/Single binary 2/OidMain.
At 0x02561E42 Size       32: Header/Binaries 2
At 0x02561E62 Size    17724: Header/Binaries 2/Game1.bi
At 0x025663CA Size       32: Header/Single binary 3
At 0x025663EA Size     2824: Header/Single binary 3/OidMain.
At 0x02566F1E Size       32: Header/Binaries 3
At 0x02566F3E Size    17736: Header/Binaries 3/Game1.bi

Are they always executed when you scan the game activation OID as far as we know?

Likely, but unclear.

Are the names derived from the contents of the binary?

The names are in the GME file.

Edit: What do you get for a patched file (with "still works" code)? "Bitte lade die Audio-Datei ..." or "Berühre erst das Anchaltzeichen" or rather normal behavior?

With the unmodified assembly, you get bit-wise identical GME, so everything works.

With the still-works.txt, you don’t hear anything when activating, but then other fields of the book work.

[maehw]

Sorry, I was using a pretty old self-built version of tttool. Got it fixed by using the most recent release.