Pokemon Ranger Protoype and Azure Flute

[Guest]

Terminology might be a bit off, but I stand by my opinion and definition. At no time during development, the debug/test cards were intended for being used with the final game. The true slot-2 distribution carts do actually act quite a bit different than decchi.bin. This file is merely a leftover of a very early version of the game's sources, a file that helped testing the source code. It got into the distro rom by accident, an oversight.
However, if you would even define a C++ source file being an "unreleased" file, then I guess your definition makes sense in its own way!

[Guest]

I'm not disagreeing with you, either way. I think it makes a lot of sense that we can't really call this an event, since for all intents and purposes it was never designed to actually be an event, just something they used as an in-house test.

Do you have any information on how the true slot-2 distro carts worked? If you can say they act quite a bit different, I assume you have some info about how they work. I've been wondering what they do if they are run in GBA mode (I don't expect them to do anything other than display something on screen, but still, curious about what they would display.)

[Deoxyz]

15 hours ago, Purin said:

It's just a leftover from the testing and debugging phase of the game. This wondercard was never meant to be released, so it's not an "unreleased event" in my opinion. The wondercard description also has the same text as the Old Sea Map wondercard from Pokémon Emerald, in case this wasn't mentioned yet.

However the Azure Flute/Infernape debug test stuff is leftover data used only by the developers. Much like the Litwick, Bulbasaur etc. wondercards in some of the Gen 5 distribution roms.

I agree with this. That's why I wasn't totally sure if calling it an "unreleased event" is the correct term to categorize them as, but it is similar enough to pokemon like Meteor Jirachi, so regardless I think they should all be well documented and archived.

I'd say just distinguish them in two separate categories, "Unreleased Test/Debug Pokemon" and "Unreleased Event Pokemon". I didn't even know about those test Gen 5 wondercards, which we should document alongside the Infernape/Azure Flute.

 

Edit: Just a note, I uploaded a new Infernape wondercard in the post I previously uploaded it in. Just an error fix with the preset OT not being retained when distributed, rather it was using the receiver's OT.

Edited January 15, 2017 by Deoxyz

[Guest]

So any new findings regarding decchi.bin?

[theSLAYER]

Tests Round 1
Test 1: Renaming the name as B5BE on decchi, and keeping the name in the list in ENG Pearl to B5BE didn't work.
Test 2: Keeping the name B5BJ on decchi, and renaming the name in the list in ENG Pearl to B5BJ didn't work.
Test 3: Renaming the name to B5BE on decchi, and renaming the name in the list of JPN Pearl to B5BE works.

There probably is some kind region tracking, but I can't tell if it's decchi or DPPtHGSS being the side that has the region byte that is being verified.

Interestingly enough, I can't seem to find the list in HGSS.

Tests Round 2
Replacing all bytes that contain 0x01 to 0x02 between offsets 0xC0 to the end, did not make it not receivable on JPN games. (The idea was to accidentally replace a JPN language byte with ENG, but that didn't work)

Maybe what controls it is the script in decchi (script for the wonder card transfer), as opposed to a language byte being checked.

[BlackShark]

If you replace every byte from 0xC0 - 0xFFFFF with zeros the distribution cart still works without difference if I remember correctly. So I suppose these bytes are unrelated to the distribution functionality.

In that area you can find the image you can see when booting on a GBA, showing ZP3J (offset 0x514) as well as 9 more similar images.

 

[theSLAYER]

What is found is, editing the text POKE RANGER B5BJ01- to POKE RANGER B5BJ00- for some odd reason breaks Japanese redemption. Editing the 01 to anything else breaks Japanese redemption
I wonder if that's related to language recognition.

edit: It's probably just game cart recognition. NDS games have similar title structure too. Something something 01

Also, removing the AGB header breaks redemption.

Interesting, changing all bytes from range: 0xC0 to 0xFFFFF, to data: 0x01 or 0x0100 breaks redemption too.
Filling them with 0x01000000 re-allowed redemption.
(0x00 made it work fine, as described earlier by BlackShark)

edit2: redocumenting decchi and PCD relations

Spoiler

decchi : PCD
100010 - 10005F : 104 - 153
100060 - 1000FF : 000 - 09F
100100 - 10014F : 104 - 153
100150 - 1004A7 : 000 - 357

it still works when it's trimmed down: final byte being 0x1004A7

Heck, it still works when 0x10010 to 0x100FF are replaced by 0x00s

edit3:
What if we're misunderstanding how the block works.
Maybe it's not looking for a "region code", but rather, the field where extra cards for languages could have been are not populated, hence it can't find a card? (probably not...)

Given that I blanked out all the apparently unused areas, and trimmed down the size, I'm guessing it's the NDS cart that is searching for a particular value within the 'useless' region. (Given that changing that entire sector to non-00 kills the distribution for JP)

 

[BlackShark]

Found the pointers to the wondercard in Japanese Diamond:
0x30BC20 points to 0x100100
0x30BC50 points to 0x100000
It doesn't look like there's any other pointer nearby.

The first pointer seems to exists in US Diamond at 0x2FC7AC.

[theSLAYER]

2 hours ago, BlackShark said:

The first pointer seems to exists in US Diamond at 0x2FC7AC.

maybe that's the one. I'll take a quick look at what's there.
edit: Nothing, lol. I'll shift the wondercard down to that location, see if it works

realized what you meant, lol

There's one pointer that points to 0x100100 , but unlike the Japanese one, I don't see another one point to 0x100000 nearby..

[Wokann]

On 2019/6/21 at AM5点55分, theSLAYER said:

测试第 1 轮
测试 1：将 decchi 上的名称重命名为B5BE，并将 ENG Pearl 列表中的名称保留为B5BE ，但不起作用。
测试 2：将 decchi 上的名称保留为B5BJ，并将 ENG Pearl 列表中的名称重命名为B5BJ ，但不起作用。
测试 3：将 decchi 上的名称重命名为B5BE，并将 JPN Pearl 列表中的名称重命名为B5BE ，但起作用。

可能存在某种区域跟踪，但我无法判断是 decchi 还是 DPPtHGSS 是具有正在验证的区域字节的那一侧。

有趣的是，我似乎无法在 HGSS 中找到列表。

测试第 2 轮
替换偏移量 0xC0 到末尾之间包含 0x01 到 0x02 的所有字节，并没有导致它在 JPN 游戏中无法接收。（想法是意外地用 ENG 替换 JPN 语言字节，但没有成功）

也许控制它的是 decchi 中的脚本（奇迹卡传输的脚本），而不是被检查的语言字节。

In addition to the B5EE byte, the game program will also verify a 128-byte RSA signature in the slot2 file.

I have checked all the language ROMs of GEN4 (DPPT, HGSS), the result is that all the Japanese versions of GEN4 do not perform signature verification, while all the overseas versions of GEN4 require signature verification.

After I tried to remove the signature verification and changed B5EJ to B5EE, the slot2 file can be received as a distribution normally for English peral.

At the same time, the files in dechi.bin do not contain language flags, which means  whatever language of pcd file you inject to dechi.bin, it all can be recognized by gen4 rom after changed B5EJ and skip signature check(which is different from the language setting in the Deoxys distribution ROM)

[theSLAYER]

4 hours ago, Wokann said:

In addition to the B5EE byte, the game program will also verify a 128-byte RSA signature in the slot2 file.

I have checked all the language ROMs of GEN4 (DPPT, HGSS), the result is that all the Japanese versions of GEN4 do not perform signature verification, while all the overseas versions of GEN4 require signature verification.

After I tried to remove the signature verification and changed B5EJ to B5EE, the slot2 file can be received as a distribution normally for English peral.

At the same time, the files in dechi.bin do not contain language flags, which means  whatever language of pcd file you inject to dechi.bin, it all can be recognized by gen4 rom after changed B5EJ and skip signature check(which is different from the language setting in the Deoxys distribution ROM)

That’s cool information. Where would the 128-byte RSA signature be located at if it wasn’t removed?

[xblau]

On 7/23/2024 at 8:47 AM, theSLAYER said:

That’s cool information. Where would the 128-byte RSA signature be located at if it wasn’t removed?

The signed data starts at offset 0x10000 and is 1192 bytes long. The signature starts at 0x20000 and is 128 bytes long.

To make the original decchi.bin work on an English copy of Platinum, change the ID from B5BJ to B5BE and use a hex editor to replace this:
 

Spoiler

$ hexdump -C -s 0x20000 -n 128 -v decchi.bin
00020000  e1 e1 e1 e1 e1 e1 e1 e1  e1 e1 e1 e1 e1 e1 e1 e1  |................|
00020010  e1 e1 e1 e1 e1 e1 e1 e1  e1 e1 e1 e1 e1 e1 e1 e1  |................|
00020020  e1 e1 e1 e1 e1 e1 e1 e1  e1 e1 e1 e1 e1 e1 e1 e1  |................|
00020030  e1 e1 e1 e1 e1 e1 e1 e1  e1 e1 e1 e1 e1 e1 e1 e1  |................|
00020040  e1 e1 e1 e1 e1 e1 e1 e1  e1 e1 e1 e1 e1 e1 e1 e1  |................|
00020050  e1 e1 e1 e1 e1 e1 e1 e1  e1 e1 e1 e1 e1 e1 e1 e1  |................|
00020060  e1 e1 e1 e1 e1 e1 e1 e1  e1 e1 e1 e1 e1 e1 e1 e1  |................|
00020070  e1 e1 e1 e1 e1 e1 e1 e1  e1 e1 e1 e1 e1 e1 e1 e1  |................|
00020080

 

With this:
 

Spoiler

$ hexdump -C -s 0x20000 -n 128 -v decchi-eng.gba
00020000  25 df fd 2f 5a f6 5b cf  cd cc 4c 32 fc 22 90 08  |%../Z.[...L2."..|
00020010  d0 e1 ba 4a 2a 08 5e ad  7f 2c cf 54 5f c2 11 75  |...J*.^..,.T_..u|
00020020  9c 61 cf ca b6 43 a7 74  c2 b3 c0 a7 6a e9 fa c5  |.a...C.t....j...|
00020030  97 72 57 d6 ee 9a 36 70  1c 0a da c4 b4 8d d8 76  |.rW...6p.......v|
00020040  80 29 7b 59 22 a5 d3 58  44 b2 f2 1b 0c ac f5 22  |.){Y"..XD......"|
00020050  2b 78 71 61 5a 2b 68 e6  bc 9f 7e 0f ea 9a 6a 11  |+xqaZ+h...~...j.|
00020060  9b 5d 06 27 0c 74 be 76  19 8e 93 75 62 cd b3 b2  |.].'.t.v...ub...|
00020070  c3 4a 2e 0b 8d f8 da 5b  b4 12 a7 18 27 50 09 8e  |.J.....[....'P..|
00020080

 

(Since the 4-letter ID is outside the signed payload, you can change the last digit to F for French games, I for Italian games, S for Spanish games...)

[theSLAYER]

8 hours ago, xblau said:

The signed data starts at offset 0x10000 and is 1192 bytes long. The signature starts at 0x20000 and is 128 bytes long.

To make the original decchi.bin work on an English copy of Platinum, change the ID from B5BJ to B5BE and use a hex editor to replace this:
 

  Hide contents

$ hexdump -C -s 0x20000 -n 128 -v decchi.bin
00020000  e1 e1 e1 e1 e1 e1 e1 e1  e1 e1 e1 e1 e1 e1 e1 e1  |................|
00020010  e1 e1 e1 e1 e1 e1 e1 e1  e1 e1 e1 e1 e1 e1 e1 e1  |................|
00020020  e1 e1 e1 e1 e1 e1 e1 e1  e1 e1 e1 e1 e1 e1 e1 e1  |................|
00020030  e1 e1 e1 e1 e1 e1 e1 e1  e1 e1 e1 e1 e1 e1 e1 e1  |................|
00020040  e1 e1 e1 e1 e1 e1 e1 e1  e1 e1 e1 e1 e1 e1 e1 e1  |................|
00020050  e1 e1 e1 e1 e1 e1 e1 e1  e1 e1 e1 e1 e1 e1 e1 e1  |................|
00020060  e1 e1 e1 e1 e1 e1 e1 e1  e1 e1 e1 e1 e1 e1 e1 e1  |................|
00020070  e1 e1 e1 e1 e1 e1 e1 e1  e1 e1 e1 e1 e1 e1 e1 e1  |................|
00020080

 

With this:
 

  Hide contents

$ hexdump -C -s 0x20000 -n 128 -v decchi-eng.gba
00020000  25 df fd 2f 5a f6 5b cf  cd cc 4c 32 fc 22 90 08  |%../Z.[...L2."..|
00020010  d0 e1 ba 4a 2a 08 5e ad  7f 2c cf 54 5f c2 11 75  |...J*.^..,.T_..u|
00020020  9c 61 cf ca b6 43 a7 74  c2 b3 c0 a7 6a e9 fa c5  |.a...C.t....j...|
00020030  97 72 57 d6 ee 9a 36 70  1c 0a da c4 b4 8d d8 76  |.rW...6p.......v|
00020040  80 29 7b 59 22 a5 d3 58  44 b2 f2 1b 0c ac f5 22  |.){Y"..XD......"|
00020050  2b 78 71 61 5a 2b 68 e6  bc 9f 7e 0f ea 9a 6a 11  |+xqaZ+h...~...j.|
00020060  9b 5d 06 27 0c 74 be 76  19 8e 93 75 62 cd b3 b2  |.].'.t.v...ub...|
00020070  c3 4a 2e 0b 8d f8 da 5b  b4 12 a7 18 27 50 09 8e  |.J.....[....'P..|
00020080

 

(Since the 4-letter ID is outside the signed payload, you can change the last digit to F for French games, I for Italian games, S for Spanish games...)

Hmmm, curious, would you be able to say where this info is from? Seems to be a command line dump of some kind?