Reverse-engineer the Crystal "base" data inserted by tools/stadium.c #752
Comments
|
Here's a CSV of all the
|
|
All 21 unique base data sequences (each beginning with
|
|
After the " All of them have |
|
This is in Stadium 2 (https://github.com/pret/pokestadium/blob/master/stadiumgs/main.s): However, other ROMs have their manufacturer codes where Also note that the data at the end of is similar but not identical to the checksum data for US Crystal. |
|
I've personally written this off as unsolveable, at least merely using officially released data. I should point out that this data only exists in US/AU and EU Crystal, but it doesn't exist in any language of Gold and Silver, nor japanese Crystal! Since this issue is blatantly referring to the leaks, and this, unlike the stadium checksums, probably can't be solved without taking a peek at the plethora of builds in there (I should point out that it seemingly doesn't contain any tools that generate this data), I'll point out that the stadium 2 header refers to the rom located at |
|
Yeah, I was searching for any files that could even resemble a base-data-generating tool, but only turned up the builds containing that data, so went ahead and documented what we do know about it. |
|
The data format is: ASCII " This can be found with RevEng, searching across all 21 ROMs' base data: (The checksum bytes are appended to the end of each hex string, swapped for endianness.) This is the same |
|
The remaining 16 bytes of The bytes Banks with 1s in US 1.0 and their sections:
|
|
First thing that popped into my mind when I saw your comment was comparing the banks, partially because I've heard stadium loads banks selectively (which is why crystal load times are slower or smth), and because those are all banks that have no reason to change between localization revisions, so here's a little script: #!/usr/bin/env python3
base = open("crystal_base0.bin", "rb").read()
rel = open("BYTE00-0.gb", "rb").read()
for x in range(0x80):
for y in range(0x4000):
off = x * 0x4000 + y
if base[off] != rel[off]:
break
else:
print("%02x" % x, end=" ")
print()And the most important bit, the output: See any similarities with your list? |
|
mid-kid, hi! Brilliant! I didn't know that about Stadium. Unfortunately (Edit: Stadium has some of Crystal's banks, in compressed form, as well as checksums for both Crystal Japan rev 0 and Crystal USA.) |
|
Bank $66 of |
|
Reopening since this was never solved - |
|
I think this can remain closed. We solved and documented what the bits actually mean. Generating them from the built ROM instead of hard-coding them would add extra complexity and would still require even more hard-coded data (the expected checksums of |
|
Since we still don't have any conclusive answer as to how this data affects stadium, I'd prefer generating the data correctly. If anything, it helps codify the research in this issue, and explain the data better. Since there's no way to recover some of the necessary Keeping this issue open as a personal reminder. I'll probably do it myself at some point. |
|
Instead of using the half-bank checksums, we can checksum each whole bank (using the 0xFEFE init value), and compare with a hard-coded array of the base ROM's 128 bank checksums. That avoids any collisions, at least for the ROMs we generate so far (US, AU, debug). Verification script: https://pastebin.com/xmcJ2GgL (Let's make sure it works for the EU ROMs too though.) (The .c file can also comment that the base checksums came from crystal_base0.bin; we already mention the original debug ROMs' names in the readme.) |
|
https://pastebin.com/yrweqJw3 (This always prepends Also I want to refactor this to not depend so much on the runtime ROM filesize. The stadium data is always going to assume 128 banks, so we just need to avoid reading file data past that. |
|
Apparently there's been an error in the so-far-unused EU base data (needed for ES, DE, FR, and IT i18n). It should have been: There's a problem with the EU base data (needed for ES, DE, FR, and IT i18n). The actual ROMs, and the current hard-coded stadium.c bytes, have: Could they have been patched after the base data was generated, before release? Edit: Never mind, they use crystal_base1.bin. |
This is 24 bytes of data starting with ASCII "
base" that come right before the Stadium 2 checksums in Crystal. It's not present in G/S.One version of this data is in the US 1.0, US 1.1, and AU ROMs; another is in the EU ROMs; another is in the US 1,0 and 1.1 debug ROMs. Some of the early Crystal builds have still other versions, or no such data.
https://github.com/pret/pokecrystal/blob/master/tools/stadium.c#L27-L37
The original xtal, xtal_revise, and xtal_AUSTRALIA pmcenv each have a crystal_base0.bin file; and xtal_euro pmcenv has a crystal_base1.bin file. These are particular ROM builds without the base or Stadium data at the end.
It may not be possible to reverse-engineer, in which case tools/stadium.c will continue to insert it from hard-coded values.
The text was updated successfully, but these errors were encountered: