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?