Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


ajxpk last won the day on December 23 2021

ajxpk had the most liked content!


577 Excellent


About ajxpk

  • Birthday 01/01/1988

Recent Profile Visitors

14723 profile views
  1. Thank you @agentman for your contributions! That's amazing! Where did you get these from? eBay? Sorry about that. Well as you might already know all these Mew in that era (since Nintendo Space World '97) were distributed via these special machines and it's always the same data, with the exception of ID and OT. We have already collected some and even obtained "distribution cartridges" filled with them and I think it might just got lost in the shuffle. Personally I also have to admit that I'm not too familiar with what has been distributed internationally, I'm usually more focused on the unlocalized distributions. These are still amazing contributions regardless and especially with the Surfing Pikachu you got my attention now. The Mew looks fine, I'm still thinking about whether or not the Surfing Pikachu is real, unfortunately because this is the first one I've ever seen and I can't confirm if it is authentic based on the data alone... What we do is building a database by collecting verified data, then we analyze the data and see what can be used for legality analysis. The main problem is that within the data structure of a Pokémon in RGBYGSC, there isn't really anything that can be checked other than the Pokémon's parameter. There's no other way and in my opinion even nickname trash data aren't useful to determine legitimacy, because there actually isn't any trash data (usually it's all EOM). So what we really need is verified data, we need documents such as letters and certificates to determine that something is authentic. Then we have something we can check against to at least confirm that it's legal. Is there any chance to get more information from the seller? I fixed it. The NINTEN OT edit came from @SnorlaxMonster, reference was MewtwoSama's posts at AzureHeight where he claimed that he owns a NINTEN Mew. Since MewtwoSama never proved from which official distribution he got it from, I don't believe the story and if you want my opinion... it's just a myth. Somehow the NINTEN Mew myth got mixed up with Surfing Pikachu, or it's because in Japan they distributed it with the OT ニンテン. I even can imagine how the rumors started, there's a screenshot in Pokémon Power Volume 6 Jan. 1999 that shows Mew with the OT NINTEN and different stats, which was from a Pokémon Red/Blue version in debug mode. So everyone who saw this expected that they eould distribute it with this OT, what they actually distributed was a Mew with the OT MARIO. IIRC this was also the reveal of Mew in the US, so this is very similar to the Mew reveal in May 1996 issue of CoroCoro Comic showed a screenshot of a Mew with the OT ゲーフリ, but at the end it was distributed with the OT コロコロ. Also, the stats are different and from what I know all machine Mew had the same stats. You're right about this and I wouldn't be surprised if the Surfing Pikachu's OT really is "YOSHIRA", because like you said, the Pokémon was distributed via the same machine & software. What I'm more confused about is the nickname "PIKCHU"... and the irony is that it could be either mean that it's a really bad hack or that this is actually real. If it's real I wonder why would it would be this way... What I do know is that the localization was very simple, they even left the Japanese SGB border with "POCKET MONSTERS"... If the cause for the decision for the name was because the software wasn't perfect this might explain it, but it still doesn't make sense. In order to get the correct RAM locations to set the Pokémon's nickname they need the correct lengths. The Japanese versions of the Pokémon games have a name length of 5 characters while the international version have 10 characters, + one additional character which is always EOM. In theory it could be possible that they have taken this into account for the offset calculation but not for the name itself. It still wouldn't make sense because PIKCHU is 6 characters, also based on all the known OT names up to 7 characters are possible...
  2. @pdcqqcjc was actually making a good point saying that @町田明日香's Japanese reads typically as if a translation tool was used, so maybe it wasn't a native japanese speaker after all? How does that make the rest of the story believable? In addition there are hacks in these save files, Asuka said she received these Pokémon by traveling around with her family when she was a child... Which Pokémon though? All of them? Some of them are clearly hacks so that story seems not to be true either. It should be said that you couldn't just go to these distributions to get these event Pokémon, back in the days you had to apply for a lottery by sending a postcard to Shōgakukan or later Nintendo who were responsible for Pokémon distributions at the time. Winners received a notification including instructions on how to prepare the cartridge for the distribution. If provided it would actually be possible to confirm legitimacy. Legality analysis only helps to determine what could be, but can't verify what is legit.
  3. @町田明日香さん、ようこそ。(*´▽`*) 貢献していただきありがとうございます。私はすでに保存データをチェックしており、いくつかの情報を共有します… コロコロミュウは本物ではありません。 コロコロミュウは、実際にはゲーム内のポケモンとして生成されました。 つまり、任天堂スペースワールド'97で最初に使用された「特殊マシン」で配信されたミュウとは異なり、ランダムなIVがあります。 ジーエスボールイベントがゲームにハッキングされました。モバイルシステムGBは使用されたことがなく、ダウンロードされたポケモンニュースデータはありません。 すでに孵化したなぞのタマゴはIVが0であり、それらは間違いなく本物ではありません。情報によると、それらは「ポケモン配布マシン」を介して配布されました。これは、2001年にニューヨークのポケモンセンターで最初に使用されたのと同じマシンです。 それについてもう少し教えていただけますか?個人的に受け取ったものを教えてください。これらのポケモンのいくつかは非常にまれであり、宝くじで配布されました。手紙や証明書などの書類がまだある場合は、それが役に立ちます。公の場で共有したくない場合は、個人的に話すことができます。よろしくお願いします。
  4. Distribution cartridge (via multi boot) and there is information that the 10th Anniversary Celebi & Space Center Deoxys were distributed using the same cartridge. Yes, this was the only English Celebi that was distributed at the time.
  5. Thank you! Sorry, I didn't noticed earlier that it was locked. This seems to happen to me all the time now when I update information the first post. Hope this won't happen again, I'm afraid to make edits now... I think in the future I will just make new posts and leave the main post as it is... Edit: Alright! Thanks again, it's fixed now.
  6. It's funny how every once in a while a thread like this pops up. There's actually a thread in this forum where we collect information about these distributions, it's mainly about collecting scans from magazines, blogs, screenshots ect. and this is as far we could get until now, if there's anything we find out you will find it there. @theSLAYER can you please unlock it? As theSLAYER said they can't be recreated because we're missing some important information. I'm not sure if they were traded, considering this distribution method was succeeded by the Special Machine, but the question to me is not how they were distributed but how they were created... If it's like Mew then it was made from the scratch, if it was like Surfing Pikachu then it's a Pokémon caught in-game and then edited, either way they all would have fix stats because they were copied (something the Special Machine does automatically). To confirm the missing information we would actually have to collect at least 1 Pokémon with proof that it's real like a notification or certificate, even better would be 2 Pokémon from different sources and as you might already know just 20 ever distributed. Realistically spoken I think it's almost impossible, we haven't even seen a full screenshot and we don't know the OT Name and the starting number of the incrementing ID which by the way doesn't necessarily have to start from 00000. Like I said I we definitely would need a proof that it's real, because datawise there aren't much indicator to be able to tell for sure and there is also the possibility that it was stored on Pokémon Stadium. I wouldn't say that there isn't anything special about it, especially if you compare these old distributions with modern standardized distributions distributed wirelessly, I think there is more work put into these, even as far as promotion goes and the distributions were also difficult to perform logistically. These are the most rare Event Pokémon that exist and Pokémon Stadium (2 in Japan) even has legality checks included to properly display these Pokémon with their Special Moves as legal. I do however agree with your point that there's no other way than to let it go...
  7. Well, depends on what you mean with it "seems" to work... at least it does not work in a secure way. Btw. I wonder why people always think these games work different on emulator than they do on the real hardware. An emulator is in fact a virtual machine that (if done properly) imitates what a real machine would do. SRAM bank switching is essential and has to work exactly like on the real hardware, otherwise the emulation will fail as soon as the game wants to switch banks and writes/reads values to/from incorrect locations. If there's really something here that works different my guess would rather be the cheat codes. There's nothing documented about it other than that Z is always 01, I don't think this is for the bank considering that the GB gameshark format predates the CGB hardware... I remember I haven't seen anything GS Ball related in the patch file, it should be in code.bin.
  8. SRAM bank switching works exactly the same way on emulator. As @BERRY Guru said... the only secure way to get to the exact location is inside the SRAM file. Edit: Sorry I always get confused reading information from different sources like Github or Glitch City Laboratories (R.I.P.) back in the days, it's better I read into the asm myself which I just did to refresh my memory. It turns out that it actually doesn't matter in which SRAM bank it is. It's the so-called Extra RAM (0xA000~0xBFFF) which is not to be confused with the Work RAM bank section (0xD000~0xDFFF). It doesn't change the fact that codes should be used with caution though. I also re-confirmed that the flag is at 0xA000 in memory. Háčky posted the asm of the debut function that sets GS Ball Flag a few years ago... SetGsBallFlag: ld a, $05 // GSBallFlag call $2FDA //open ram bank ld a, $0B // GSBALLFLAG ld [$A000], a //GSBallFlag call $2FEA //close ram bank ret With that being said, I don't know where you got that other location from, I can't find anything about it...
  9. The 00185 one looks good, I think it could be real. 45280 is a hack. クッパ is just like ドンキー from Nintendo Space World '97 .
  10. Wow! That's amazing! I also found something a while ago which I forgot to share here for some reason... Source: http://blog.livedoor.jp/sylphwatch/archives/6683625.html I think with this it is confirmed that コロコロ Mew with IDs over 01000 are potentially possible, but this should be taken with a grain of salt. It's unknown from which CoroCoro issue this is coming from, but this article is about all the requests to distribute CoroCoro Mew when they stopped distributing them, so the screenshot was most likely made after the last distribition and before the first Special Machine distribution. Would be good to know from which distribution this is coming from, if this was really from the very first Mew Distribution this is a piece of gold. This sticker looks very familiar, those were also used for the ニンテン Pikachu distribution. The red number has nothing to do with the ID No. though... Source: https://dorao.blog.ss-blog.jp/2010-11-15 Finally we have a proper description about how they had to prepare their game cartridges! Not sure if I would have shared Mew with my friends back in the days... This is from Nintendo Space World '97.
  11. At this point I wouldn't recommend using GameShark Codes in Pokémon Crystal, because the game switches SRAM banks, the activation flag for the GS Ball event is at loc 0x0000 of bank 5 (loc 0xA000 in the SRAM file). Now the problem is you can't see which bank is currently in memory so when you just write 0x0B at memory loc 0xA000 it could end up in any bank and cause chaos. I removed the content of my old posts...
  12. It turns out that the PKR-059 a00's header fields at offset 0x14 and 0x18 are time stamps representing minute, second, hour (u32) and year, month, day (u16). The .tsd and .dat save headers have their time stamps too at field offset 0x8 (minute, second, hour) & 0xC (year, month, day). date(u16) format = year, month, day time(u32) format = minute, second, hour PKR-059 a00 date = Previous date from header offset 0x18 (default value = 0xFFFF) time = Previous time from header offset 0x14 (default value = 0xFFFFFFFF) .tsd & .dat Whatever is currently on the stack (gets XORed all the time from what I've seen so far) *date = *date & 0xFF80 | year & 0x7F; *date = *date & 0xF87F | ((month & 0xF) << 7); *date = *date & 0x7FF | ((day & 0x1F) << 11); *time = *time & 0xFFE0FFFF | ((hour & 0x1F) << 16); *time = *time & 0xFFFFFFC0 | minute & 0x3F; *time = *time & 0xFFFFF03F | ((second & 0x3F) << 6); Field at 0x1A (u16) (PKR-059 a00 ) is a count. It's defaults at 0 in increments when the file is created and each time the file is overwritten until it maxes out at 0xFFFF (it doesn't overflow). With siskin.tsd, wren.tsd, hazel.tsd, set_delivery001.dat, set_delivery003.dat, set_delivery002.dat & set_delivery004.dat set it reaches 8 and will never be updated from here. Field 0x1C is always 10, the value is used as the maximum of files that can be saved and to calculate the reserved space (0xA * 0x30 + 0x20 = 0x200). .tsd & .dat files have a save count too at 0x10 (u32), which serves to select the current mirror, the top .tsd file being saved first takes the odd and the 2nd takes the even numbers. It maxes out at 0xFFFFFFFF without overflowing, there is an additional count for the block at 0xE (u32), which increments with each time the block is saved. It maxes out at 0xFFFF (again, no overflow). Field 0x14 in .tsd & .dat is used for enabling/disabling a save block, mainly used for the backup where the first time these save files are created an empty disabled backup block is created. Hazel.tsd (used for save states) makes use of this commonly as save states are deleted when they're used. PKR Main Save File header Adrs Description Type 0x00 "PKR-059 " str 0x07 "a00 " str 0x0C Seed u32 0x10 CRC16 u32 0x14 Time u32 0x18 Date u16 0x1A Count u16 0x1C Save Data Table Max u16 0x1E Unknown u16 Save Data header (.tsd & .dat) Adrs Description Type 0x00 Seed u32 0x04 CRC16 u32 0x08 Time u32 0x0C Date u16 0x0E Block Count u16 0x10 Global Count u32 0x14 Enable Flag u16 0x16 Unknown u16 Btw. the seeds for the encryption is created by via timer 0 (REG_TM0D) + a counter of its overflow (REG_TM0CNT = TIMER_ON | TM_IRQ | TM_FREQ_64). (REG_TM0D | (TM_IRQ_count << 16)) + 1
  13. Recently I found out that when you do something like writing on these encrypted save file chunks the game will delete them. When you for example overwrite the encrypted "PKR-059 a00 " save block (or its seed) it erases the whole save file. And that's for example how you can delete the save game but still keep the special missions... I think the same will also work vice versa, so you can just destroy the data/do anything that the sum check fails. The field at offset 0x1C is a u32 value and always 0xA, it's set when the game creates the header. Can be used to check whether a save file is already decrypted/encrypted. Also... Offset 0x10 of these other save file headers could be some kind of save count. Looks like the 2nd is really a backup save, its chunk is created when you save for the 2nd time (before that it only has these blocks only have the save file header). Edit: Meanwhile I located the functions for checking the agb ("beacon") & mission data. The first 128 bytes starting from offset 0x08100010 is an array which is swapped for some kind of cryptostuff which reminds me on RC4, but tbh I don't know much about this and it looks tough to reverse engineer so I think I will leave it there. If I understand it correctly it's in fact very similar to what I've seen in the localized versions of Diamond & Pearl etc. where it does a signature verification with 128 bytes from 0x08020000, it looks almost identical (just the key is different from what I've seen). In addition there are SHA1 checks for the mission data starting at offset 0x08100090, apparently the total size checked is the size of the full data -191 bytes. I didn't even go further (it's possible that the data is compressed), this whole thing is more complicated than I thought, a lot research would be necessary to make it work... If someone is interested in it... the initiate BL to the subroutines for the SHA1 and the cryptostuff is at offset 0x020B0284. The function that makes the .dat save file block and updates the main save (PKR) is at 0x02001D80. I think the best approach would be to figure out how saving works in detail, which would have to be done either way as we need to know more about these other values from the header... Edit 2: Btw. Meanwhile I know where the Special Mission data struct from siskin.tsd is coming from, they were installed from the .dat files... The D00X struct is always 100 bytes copied straight from the .dat. The rest of the data is information for title, description and the name of client. The string data was copied with varying lenths, the struct includes information about the number of characters (u16). set_delivery001.dat D00X: D001 (0x50D0) Description offset: 16 chars Client name offset: 97 chars Title: "だいじなタマゴを とりもどせ!" (0xD490) Description: "シンバラきょうじゅが てにいれた マナフィの タマゴを ゴーゴーだんに うばわれてしまった! かれらに あくようされる まえに だいじな タマゴを とりもどせ!" (0xD4B0) Client: "シンバラ" (0xD554) set_delivery003.dat D00X: D002 (0x1D10) Description offset: 16 chars Client name offset: 111 chars Title: "デオキシスと わかりあえるか?" (0x5874) Description: "なんらかの りゆうで こうげきてきに なった デオキシスが はっけんされた。 まわりの ポケモンや にんげんに ひがいが でるまえに デオキシスを せいじょうな じょうたいに もどすのだ!" (0x5894) Client: "ハヤテ" (0x5954) set_delivery002.dat D00X: D003 (0x1BC0) Description offset: 13 chars Client name offset: 107 chars Title: "セレビィを すくいだせ!" (0x43A4) Description: "ライラのもりに あらわれた セレビィを ゴーゴーだんの れんちゅうが ねらっているという じょうほうが ある。 セレビィを ぶじに ほごするために かれらよりも さきに キャプチャせよ!" (0x43C0) Client name: "ハヤテ" (0x447C) set_delivery004.dat D00X: D004 (0x1520) Description offset: 15 chars Client name offset: 115 chars Title: "まぼろしのミュウを さがせ!" (0x397C) Description: "まぼろしのポケモンと いわれている ミュウが ジャングルで もくげきされた。 シンバラきょうじゅの けんきゅうの ため ひとりの レンジャーの めいよの ため ぜひ ミュウを キャプチャしてほしい!" (0x399C) Client name: "シンバラ" (0x3A64)
  14. Good work! Now I finally understand why there were 3 functions for decryption. One was for the first two chunks with the save info, the second is a hardcoded decryption function with a * 5 loop to decrypt the first 20 bytes of a chunk, (I guess just for save file checks) and the third one for the rest of the non-static chunks. This is the directory list struct based on my understanding. (Updated! @BlackShark Sorry for the confusion, I think I mixed the numbers up a little, the struct with the save info is complete now...) Savedata List 0x00 File name (28 chars) 0x1C Unknown (u16) 0x1E Mirror (u16) 0x20 Address (u32) 0x24 Data Size (u32) 0x28 Sector Size (u32) 0x2C Unknown (u32) file name type data size area size siskin.tsd 2 0x260C 0x4E00 wren.tsd 2 0x30D4 0x6200 hazel.tsd 2 0x30D4 0x6200 set_delivery001.dat 1 0xE7E8 0xE800 set_delivery003.dat 1 0x67E8 0x6800 set_delivery002.dat 1 0x4FE8 0x5000 set_delivery004.dat 1 0x57E8 0x5800 The most interesting one is siskin.tsd, which starts with the setting data, it also includes the ranger id (offset 0x10) and data related to the special missions, like the "new mission" flag (offset 0xA) and manaphy egg information at offset 0x8 (not received yet/received/sent) and the time info when it was obtained year/month/day (starts at offset 0xC). There's also the title and desciption strings, wren.tsd apparently includes player info... the name is at offset 0xE for example. Last but not least, hazel.tsd is used for quick save/save states... And then we have the Special Mission .dat files... the international versions have those localized included in the directory data\mission. Edit: I extracted the special mission .dat files and attached them to this post In addition I attached a thingy table which I made in case you want to look for strings. Pokemon Ranger Special Missions (JP).zip Pokemon Ranger Character Encoding (JP).tbl I still don't know how we can utilize the .dat files at this point... they seem to include all the data that is needed for the missions, including the title and description, but just using them with a ZP3J cartridge doesn't seem to work, I still get this screen when I boot the game with it... I will have to find out in what kind of form it wants to receive the data. I already located the functions (in version 1.1), the Ranger Net jump table function for Slot-2 is in overlay_0009.bin (loc 0x020FC628), there's the call to a familiar function that gets the cartridge data at 0x0209A558 (it's almost identical to the one in Diamond & Pearl ect.). It seems everything is ok, At least it gets the size information from 0x8100000 and the data starting from 0x8100010. Just for some reasons it returns false when the data is checked. Maybe because of failed validation checks. Now if I force it to return true I get this btw...
  • Create New...