Jump to content

ajxpk

Innovator
  • Posts

    769
  • Joined

  • Last visited

  • Days Won

    29

Everything posted by ajxpk

  1. The 00185 one looks good, I think it could be real. 45280 is a hack. クッパ is just like ドンキー from Nintendo Space World '97 .
  2. 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.
  3. 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...
  4. 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). YMD(u16) is taken from the "PKR-059 a00" header offset 0x18 (default value = 0xFFFF) msh(u32) is taken from the "PKR-059 a00" header offset 0x14 (default value = 0xFFFFFFFF) year, month, day, hour, minute & second are read from the Nintendo DS's RTC *YMD = *YMD & 0xFF80 | year & 0x7F; *YMD = *YMD & 0xF87F | ((month & 0xF) << 7); *YMD = *YMD & 0x7FF | ((day & 0x1F) << 11); *msh = *msh & 0xFFE0FFFF | ((hour & 0x1F) << 16); *msh = *msh & 0xFFFFFFC0 | minute & 0x3F; *msh = *msh & 0xFFFFF03F | ((second & 0x3F) << 6); The field at 0x1A (PKR-059 a00) or 0xE (.tsd & .dat) is the save count. It's 1 when the file is created and each time the file is overwritten it increments, until it maxes out at 0xFFFF (it doesn't overflow). For .tsd & .tsd this would only increment after each second save, if there is one. There is an additional save count for .tsd & .dat at 0x10 (u32), which defaults by two and increments each time the file is saved. It maxes out at 0xFFFFFFFF (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 Stamp (msh) u32 0x18 Time Stamp (YMD) u16 0x1A Save Count u16 0x1C Fixed Value (0xA) u32 Save Data header (.tsd & .dat) Adrs Description Type 0x00 Seed u32 0x04 CRC16 u32 0x08 Time Stamp (msh) u32 0x0C Time Stamp (YMD) u16 0x0E Save Count 1 u16 0x10 Save Count 2 u32 0x14 Enable/Disable Flag u32 Btw. the seeds for the encryption are created by a combination of a fast timer (REG_TM0D) and a slower 2nd timer. timer0 | ((_DWORD)timer2 << 16)
  5. Btw. 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. Btw. 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 reverted for some kind of decompression. Also 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. This seems more different than I expected... 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 data transformation 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. At least then it could be possible to go through the process from back to forth.. it would be much easier with the real ZP3J for analysis and then use that to distribute the other missions though... Just for the science I determined where the Special Mission data for siskin.tsd is coming from. Only the spacing of the text is a little bit different. だいじなタマゴを とりもどせ! set_delivery001.dat D001: 50D0-5133 (0x64) Text: D490-D55F (0xD0) デオキシスと わかりあえるか? set_delivery003.dat D002: 1D10-1D73 (0x64) Text: 5874-595F (0xEC) セレビィを すくいだせ! set_delivery002.dat D003: 1BC0-1C23 (0x64) Text: 43A4-4487 (0xE4) まぼろしのミュウを さがぜ! set_delivery004.dat D004: 1520-1583 (0x64) Text: 397C-3A73 (0xF8)
  6. 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 save data info 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...) Save Info Entry (48 bytes) 0x00 file name 0x1E number of copies 0x20 offset 0x24 data size 0x28 reserved space The chunks are essentially files (.tsd) and even have names like siskin, wren & hazel. Btw. the field 0x1F is the number of copies, 0x24 is the total size of the reserved space and so those with 2 have 1 backup save (to determine the offsets divide space by num). These are the static values of these 3 types: file name num size space siskin.tsd 2 0x260C 0x4E00 wren.tsd 2 0x30D4 0x6200 hazel.tsd 2 0x30D4 0x6200 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. file name num size space set_delivery001.dat 1 0xE7E8 0xE800 set_delivery003.dat 1 0x67E8 0x6800 set_delivery004.dat 1 0x4FE8 0x5000 set_delivery004.dat 1 0x57E8 0x5800 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...
  7. Meanwhile I did some reverse engineering and I found the encryption/decryption algorithm, it's this function... unsigned int __fastcall PokemonRangerCrypt(int a1, unsigned int s_rand, int size, _DWORD *dest) { unsigned int i; // r5 unsigned int result; // r0 unsigned int rand; // ST04_4 unsigned int h_rand; // r0 for(i = 0; i < size/4;) { rand = 1566083941 * s_rand; // the initial seed is located before the decrypted/encrypted data h_rand = rand; s_rand = 1566083941 * rand; *dest ^= h_rand & 0xFFFF0000 | (s_rand >> 16); ++dest; // this increments by 4 (u32 data) ++i; } return result; } The initial seed for this comes right before the encrypted data itself... for example, the first two chunks include a header with the string "PKR-059 a00 ". Right after that (loc 0xC) there is the initial seed which becomes the first "s_rand" value, the encrypted data follows (at loc 0x10). The encrypted chunk size for the first chunk is 496 bytes, the 2nd chunk starts at location 0x200, size of this chunk is still unknown. We can't just loop through this thing from start to end and have to figure out where each chunk starts and hopefully their seeds are stored there as well, but I think this should be easy from here now and tests should reveal that... It's still unknown how the initial seed was originally calculated... (could be a checksum?). At least the two first chunks are sharing the same seed. It looks like there could be different initial seeds for other chunks, so if something doesn't decrypt properly watch out.
  8. @BlackShark I was looking at those uploaded save files and noticed that you missed out on Japanese Special Missions including the Mew Mission for Pokémon Ranger and Shadows of Almia is completely missing. This website I showed you guys earlier has plenty of really nice save files including Pokémon Ranger save files with all downloadable content. ポケモンレンジャー (Pokémon Ranger) https://ux.getuploader.com/savedate/download/226 ポケモンレンジャー バトナージ (Pokémon Ranger - Shadows of Almia) https://ux.getuploader.com/savedate/download/227 ポケモンレンジャー 光の軌跡 (Pokémon Ranger - Guardian Signs) https://ux.getuploader.com/savedate/download/223 Also it would be really cool to know how you managed to erase the Pokémon Ranger save file with the missions still on them. I haven't found a way to do that in-game... any information about that?
  9. I know that this is an old thread and it's been over two years but I still wanted to inform you that I'm doing some research now. I just figured out that the flags are at location 0x0212E44A, setting each Special Mission's bit sets them back to "NEW!". in my case for example since I have all 4 missions in the game there are 4 bits (0-3), starting with bit 0 for the Manaphy Egg Mission and ending with bit 3 for the Mew Mission. I also learned that they originally planned 7 Special Missions. Edit: I just remembered that someone already figured this out. But it's a different location which is kinda weird...
  10. Sorry for the late relpy. They could win a GB Pocket, Red, Green & Blue and Mew? Cool! Wished there was more information, about the year, month and from which magazine this was... Since the Pikachu version isn't there I assume this is from 1996 or 1997.
  11. @GNSTCDRD The Old Sea Map was only distributed in Japan, that's why we have only this one. As already mentioned a non-Japanese Mew caught in Emerald isn't legal, but if you still you want to do it anyways you can go with the debug Mystery Gift. It works exactly like an officially distributed Mystery Gift would do and it won't corrupt anything, it's just that the Wonder Card isn't that beautiful as it was made for debug. If you don't like the Card you can toss it in-game after you received the Old Sea Map.
  12. Why would you do that? There's a much better and less sloppy way!
  13. Nope, there is no encryption or anything like that and all language versions work exactly the same way.
  14. Two Mystic Tickets from Pokémon Rocks America 2005 were collected from indepentent sources, it's the same as the one that was distributed at the Nintendo World Store aka '"MYSTIC TICKET" Exchange Card'. Since this Wonder Card was definitely distributed at Pokémon Rocks America 2005 I have updated the Bulbapedia article. In addition I removed "Pokémon Rocks America 2005" from the Missing Mystery Gift list. Only @Soniktts claims that it exists and that it's in his possession, but he can't proof it. Not even with a screenshot or provide its data for verification, which now would be more important than ever.
  15. ツイッターに登場したコロコロミュウ2体について聞かれました... これは本物のコロコロミュウではないと思います! そのようなデータで販売された古い中古カートリッジの多くのケースについて聞いたことがあります。 これが注目や好きなものを集めるためだけに本物であるという証拠なしに自慢するのではなく、あなたが実際にこの研究を支持できることを願っています。 次に、これが本物かどうかを判断できます。ご要望があればお手伝いさせていただきます。 私たちはみんなコレクターなので、一緒に研究に取り組みましょう。 実際には、何が本物で何が本物ではないかを学ぶのに役立つ指標が1つあります。ただし、コロコロミュウがデバッグモードで生成されたかどうかによって異なります。これは今のところ未確認です... 実際、コロコロミュウには2つのバージョンがあります。 最初の20コロコロミュウは森本茂樹がPCで作ったものです。それらのIDは00001~00020です。これらのミュウがまだ存在する可能性は非常に低いです... しかし、コロコロコミックのその後のイベントのために作られた特別なポケモンバージョンがあったようです。たとえば、WHFで使用されます。 このポケモンゲームでは、ミュウを入手して通信ケーブルで転送することができました。次世代世界ホビーフェアで小学館が使用しました。これはコロコロコミックで見たミュウです。最初のミュウとマシンからのものと同様に、IDはミュウが生成されるたびに増加していました。ID番号は00001から始まりました。可能な最大ID番号は数百の範囲になると言わなければなりません... これは、既知のID00128およびID00250によって示されます。そして、使用されたカートリッジは1つだけではありませんでした... そのため、ID01024は疑わしい番号です。ID00008は潜在的に可能です。 それがまだ本物である可能性はごくわずかですが、データを確認する必要があります。何が本物で何がそうでないかを知るのに役立つ指標が1つあります。ただし、コロコロミュウがデバッグモードで生成されたかどうかによって異なります。 本物かどうか知りたい方はご連絡ください。自分でデータを抽出でき、私たちが協力して完全なデータを共有することを恐れている限り、完全なデータを交換せずにそれを行うこともできます。あなたが私に連絡するならば、私はあなたに詳細について知らせることができます。 時間が実行されています...こういうものがよく保存されていることを願っています。 これはすべてのコレクター向けです。 一緒に仕事しよう! 世界中のポケモンコミュニティのためにそれを行い、この種の驚くべき歴史のいくつかを保存してください。
  16. I wished so too... At least it's a clean Lv. 15 Magikarp, which confirms the Level. It kinda makes sense, since a normal Magikarp learns Tackle at Lv.15. Everyone expected it would be Lv.5, otherwise I would have guessed it could be Lv.10 to match with the card... Also... this could be hint for what the OT Name might could have been. There are some strange missspells like マツ instead of instead of ます. Later I noticed this other page... The guy in the middle is イマクニ?(Imakuni?) and the person on the left is "マツモト教授" (Professor Matsumoto), representing the タマムシ大学 (Tamamushi University). Apperently those misspells are from マツモト and I wouldn't be surprised if that's the OT Name, just like イマクニ was the OT Name for the Surfing Pikachu, which was also distributed around the time... What makes this even more interesting... I have a feeling that the Surfing Pikachu was distributed at Level 15 as well. The only one I've ever seen was Level 16...
  17. Thanks for the screens. So what I realized is that the Rom is just mimicking the look of the Pokémon Blue in a similar way the Pokémon Machine 2 Software does it with Ruby & Sapphire. This also means that the software could be something different than what we might expect. At least it’s clear that the Gold & Silver Version is the same software, the Pokémon is still looking to the right like in Gen 1, it’s still the same text box obj from the Blue Version and I know this is hard to see but the bg palette is still the same as in the Blue Version, most importantly the ID is still displayed as 6 numbers. So the only thing that was changed visually is the SGB Border, which btw. is always the Japanese, even in the International Version. Also the text alignment for the ID No. is incorrect in the International Versions, for some reasons it is centered unlike the other text. That's all we can learn just based on the screens though...
  18. Yeah, exactly. It displays the ID as 6 numbers instead of 5. Cool screen! Ready for Round 2? You need to zoom in a little, it’s a bit harder because of the blurriness, but it’s the best image of the Japanese version we have to make a good comparison... Why not making a screen for this too?
  19. Interesting. They called it "Download Machine" in Germany. In Japan they were just called "Machine". By the way... There's something about the software I noticed previously... Let's play a game and see who can find the error. Round 1 One hint: It's not about Mew, pay attention to the details.
  20. Good to have it confirmed now. I have added it to the first post.
  21. Just wanted to point out that the .pk1 file was altered, it has a terminator added after the OT Name. This was done by PKHeX and is a bug I pointed out a few years ago, it never got fixed. The only way to get it untouched into your game at this point is trading it from another game that has an untouched ゲーフリ/GF Mew. Edit: The untouched version is here
  22. This is something I discovered before, the original default name that was selected for the Player is RED. In the Japanese games every name has a length of 6 bytes, while the English games are a little bit inconsistent, a named Player/Rival has a length of 7 bytes, default names and the Pokémon names have a length of 11 bytes. So in the English games when you select RED as your name the game copies this as your Player name: 91 84 83 50 60 6B 67 50 89 80 82 R E D A S H J A C When we look at the Mew Trading App Restore Point the name was overwitten with 7 bytes, same as if the Player was ingame named: 86 85 00 00 00 00 00 50 89 80 82 G F J A C Edit: I believed they used some kind of debug version, but it rather looks like they made an memory edit/patched it. The 7 byte thing is suspicious, but the naming function automatically sets a terminator (0x50) after the last selected char. Char 0x00 is NUL and not accessible in a normal ingame scenario, all chars are taken from a table and 0x00 is not in it. Also I think Mew wasn't generated by ingame functions, since that would set the bit for the PokéDex entry. Not sure what happened to Charmander, maybe it was overwritten in the process?
  23. I would be very surprised if Nintendo Power, an official magazine from Nintendo of America, would have used an unlicensed hardware/software instead of just using their own debug hardware and software. lol I agree that this Mew wasn’t generated like the Machine Mew, since the Trainer ID appears randomly generated. Otherwise it would mean that this Mew was the 24145th NINTEN Mew they generated beforehand, a very unlikely scenario. If I understand this correctly, this picture was made before Mew was distributed in the US which reminds me on the ゲーフリ(GameFreak) Mew from the initial reveal from the CoroCoro Magazine May 1996 issue. The first Mew in Japan (コロコロ) were generated procedurally by Shigeki Morimoto on his PC, it’s been said (still not confirmed, since none was preserved and examined) that they had random DVs. What we can say for sure is that they started to use these Pokémon Machines at the Nintendo Space World ‘97 Event, which was the first huge mass event with 100000 distributed Mew. That’s when the A1C5 Mew was born. If it’s true that this NINTEN Mew or other Mew with different DVs were distributed, we need to do everything we can to preserve them and if we can’t at least try to analyze the DVs. The game uses the same function for creating a Pokémon to transform it between Party and the more compact Box format. This means in case a Pokémon reaches LV 100 before maxing EVs, it’s possible to max the EVs and to put it on a Box to force stat recalculation. I really hope ryuko2002 can reach MewtwoSama, so that this can be preserved.
  24. Couldn’t have said it any better than @Deoxyz. It’s kinda impossible to recreate something that you don’t know how it works... we can only make assumptions based on Pokémon Machine 2 which is the successor of the first Pokémon Machine 1. What we would need is not only a piece of software but also the customized developer hardware that was used to make this event possible. I already have a theory how the events were done and coded but never can say for sure. We can only hope that the said hardware and software wasn’t destroyed and preserved by someone.
×
×
  • Create New...