Jump to content

BlackShark

Contributor
  • Posts

    1692
  • Joined

  • Days Won

    102

Everything posted by BlackShark

  1. I guess you are asking only for the skins? They should hold original data. Except that Mincinno skin for the reasons I have explained above. You should use PokeGen for importing/exporting skins as it can do this correctly, PKHeX seems to have some problems (?) but the feature is still WIP there and PokeCGear might result in corrupted data.
  2. You can't clear the whole 0x7F000 block. The CRGF identifier has to be there. Otherwise the DR thinks you don't have a save file. I have an assumption for why both values get updated. I would think 3DS Link generates a new encryption key everytime it's used. Regardless of what is beeing received. This means 0x7F00C will be encrypted with the new key. 0x25E00 changes as well because I would guess this is the value used to determine the actual new key with an unknown formular. 0x7F014 and after isn't changed because it's not needed anymore and the key to decrypt this is at 0x7F090 anyway. An editor would definetly be great! I tried to code one myself a few days ago but you are more skilled so go ahead if you want to.
  3. @suloku I found our culprit! Actually it's 0x7F00C, the value which is used as the new encryption key for the next transfer. I'm not sure if it's a proper way to just set 0x7F00C to zero but the DR actually seems to get the key anyway even if it's not there. Probably the key is actually derived somehow from the 0x25E00/0x7F004 value? But since setting 0x7F00C to zero works I guess knowing the origin of the value is not so important anymore. I assume 0x7F00C is not the new encryption key but rather the legendary flags which are encrypted by the new key (where ever it comes from)! I'm thinking so because 1 XOR 0xD4C5D9CE (the new encryption key from 0x7F090 in sav 4) is actually 0xD4C5D9CF (the value at 0x7F00C in sav 2)! I've attached my save so you can see yourself. POKEMON B2.0.sav - clean save before DR transfer POKEMON B2.1.sav - after DR transfer with Tornadus POKEMON B2.2.sav - after receiving 3DS Link POKEMON B2.3.sav - 0x7F00C set to zero! POKEMON B2.4.sav - Tornadus transfered again! B2 Saves.zip
  4. I only have the PAL version of Colosseum and according to your link it's buggy. I could give it a try at the weekend though. Actually I already looked for Bidoof a few weeks ago but I couldn't find it. Maybe I've overseen it or it was only on Nintendos servers back then. Here's Celebi. You can also get it from the GameStop Shiny Beasts distribution cart at offset 0x5F250.
  5. You can transfer all 8 legendary Pokemon at once but if you have 1 legendary and 6 normal Pokemon the last one of the normal Pokemon won't be transfered and will wait in the Dream Radar for the next transfer. Also clearing the Tornadus value won't let you receive it again. Once you transfer the next data over from DR the whole area will be overwritten with the new data and the Tornadus value will be zero anyway. I assume it must have something to do with 0x25E00 and/or 0x7F004. I did some test with those value yesterday and I was able to block Tornadus on a save that hasn't received it yet.
  6. Damn I got confused in my post above. I should have tested on real hardware instead of relying on my 3 year old notes and crappy Pokestock lol. Actually the header values are zero when the data is transfered from the Dream Radar. The values get set by the game when receiving the data. 0xC is the encryption key, but it i only used by the DR to encrypt the next transfered data. The key to decrypt the data is at 0x90. Also I finally found the flags that were responsible for the legendaries! They are at 0x25E04 and get set by the game when receiving the data. The DR itself only touches the 152 bytes at 0x7F000. Save Offset 0x25E00 0x00 unknown (changes when the data is received) 0x04 legendary received flags 0x08 1 after DR data was received the first time, does not increase Legendary received flags Bit Pokemon 0 Tornadus 1 Thundurus 2 Landorus 3 Dialga 4 Palkia 5 Giratina 6 Ho-Oh 7 Lugia ====================================================================== Save Offset 0x7F000 (the Dream Radar itself only touches this area!) 0x00 received/not received flag (1 after the Pokemon were received) 0x01 - 0x03 0x000000 0x04 - 0x07 unknown (derived from offset 0x25E00) (0x00000000 if the Pokemon were not yet received) 0x08 - 0x0B always 0x43524746 (CRGF) 0x0C - 0x0F Encryption Key used for the next transfer from DR (0x00000000 if the Pokemon were not yet received) 0x10 - 0x11 CRC-16-CCITT over 0x00 - 0x0F 0x12 - 0x13 0x0000 0x14 - 0x33 legendary Pokemon (see values below) (8 x 4 Bytes) 0x34 - 0x4B normal Pokemon (6 x 4 Bytes) 0x4C - 0x63 Items (6 x 4 Bytes) 0x63 - 0x8F probably unused (all zero) 0x90 - 0x93 Decryption Key 0x94 - 0x95 CRC-16-CCITT over 0x14 - 0x93 0x96 - 0x97 0x0000 Legendary Pokemon Values 0x80808080 Tornadus 0x92567284 Thundurus 0x87643567 Landorus 0x96436763 Dialga 0x43867368 Palkia 0x17693572 Giratina 0x44798367 Ho-Oh 0x96636983 Lugia Pokemon Structure 0x00 Gender (0 - Male, 1 - Female, 2 - Genderless) 0x01 unknown/unused 0x02 - 0x03 Species ID Item Structure 0x00 - 0x01 Quantity 0x02 - 0x03 Item ID EDIT: Unfortunately it's not enough to just reset the flags at 0x25E04. It seems the unknown value 0x25E00 has something to do with the legendaries as well. That value is randomly created at the beginning of each save file but it changes when receiving the Pokemon/Items. EDIT2: I still don't know how the DR detects if a Pokemon has already been received, but I overlooked that legendary Pokemon seem to be handled similar like the Key System data. I don't know if there's also a unique ID or where it is. 0x04 can't be it because it's not constant while the values for the legendarys are.
  7. Maybe the ability already gets set during download?
  8. After receiving the data only the first byte, the encryption key at 0xC and the unknown value at 0x4 get erased. The Pokemon and item data is kept there. I guess a new encryption key is set by the Dream Radar each time data is transfered and the unknown value is taken from 0x25E00. EDIT: See here https://projectpokemon.org/forums/forums/topic/40323-white-2-dream-radar-flags/?do=findComment&comment=211659 I don't think there's an ability modifier in the structure as they should always have their hidden abilities. But maybe they planned to implement Pokemon without hidden abilities.
  9. Yes Pokestock has this feature. It's in PokeTrainerS at the bottom right corner, the AR button. The structure I have posted above is pretty much complete. Here are a few re-battle codes that I know. Zekrom/Reshiram Hold Select while entering the top floor. 94000130 FFFB0000 B2000024 00000000 10036C0C 00000000 D2000000 00000000 Kyurem Hold Select while entering the room. 94000130 FFFB0000 B2000024 00000000 10036D18 00000000 D2000000 00000000 Lati@s Press Select 94000130 FFFB0000 B2000024 00000000 10020A38 00000005 D2000000 00000000 Volcarona Press Select 94000130 FFFB0000 B2000024 00000000 10036BF8 00000000 D2000000 00000000
  10. Check offset 0x25E00. There you can find the encryption key and maybe there are some flags as well. You would need to compare the area after the mentioned offset between saves from before and after using the Dream Radar.
  11. Oh well the encryption key is actually at 0x0C but once you received your Pokemon it gets zero'd. EDIT: See here https://projectpokemon.org/forums/forums/topic/40323-white-2-dream-radar-flags/?do=findComment&comment=211659
  12. Look at the top right corner of your post. There you will find Moderation Actions where you can choose to delete or hide your post.
  13. Dream Radar data is at 0x7F000 - 0x7F095. 0x00 - 0x0F some kind of header? 0x10 - 0x11 CRC-16-CCITT over 0x00 - 0x0F 0x12 - 0x13 FF FF 0x14 - 0x33 legendary Pokemon (8 x 4 Bytes) 0x34 - 0x4B normal Pokemon (6 x 4 Bytes) 0x4C - 0x63 Items (6 x 4 Bytes) 0x63 - 0x93 unknown 0x94 - 0x95 CRC-16-CCITT over 0x14 - 0x93 I started doing research a few years ago but then I lost interest. This is all I currently know. Also I guess the data is encrypted somehow.
  14. Kanto x Alola Regional Rumble regulation 015, which is downloadable from the Festival Plaza. Regulation 015.zip EDIT: Japan Championships 2017 Regulations 5101 - Junior, 5102 - Senior, 5103 - Master Japan Championships 2017.zip International Challenge April 2017 4109 - Junior, 4110 - Master International Challenge April 2017.zip
  15. I'm going to give it a try tomorrow. But I already looked at the source you posted above and it seems you made some mistakes, at least I've seen one yet. In ine 57 in your script you are calling D669 while in the original it is D66A there. By looking at the memory it seems like this should be D66F in your script.
  16. You don't have to create a python script from the source. It's just the bootstrap and the payload. The first 75 or 76 lines is the bootstrap,anything after is the payload. You would need a way to convert ASM into a Gen 1 Script. Or you could just take the bootstrap and the payload from the python script. There you search for the values that you have changed in the source and change them there as well.
  17. Well the 19-P002 card was dumped and is out there. The problem is it will not work on emulators. The mechanics of Emerald and FRLG e-Cards is different from those of Ruby/Sapphire and neither No$GBA nor VBA are handling this correctly.
  18. What kind of information do you need?
  19. That's correct. Actually there's no difference between US and PAL Ruby/Sapphire.
  20. US Channel can't distribute any Jirachi, but US Ruby/Sapphire can receive them.
  21. Here are the Festival Plaza Downloadable Regulations 012, 013 and 014 for all languages ready to use for the ExtData! Also included is an older version of the WCS17 rules which I assume should be 011 if they use ongoing numbers. It was available only for a short time and was then removed due to an error. The PGL Tournament need proper naming, they are still named as they are on the server. But the size is already padded to 64KB. Festival Plaza.zip PGL Tournaments.zip
  22. It's likely 012, 013 and 014 for all regions. I checked my German version and they are named like that. Offsets without the 0x296 bytes BOSS header. 0x00 seems to be always 1 0x04 number of rules 0x10 1st rule offset 0x14 1st rule size 0x18 2nd rule offset 0x1C 2nd rule size 0x20 3rd rule offset 0x24 3rd rule size So the rules for the current file are 0x028 - 0x4CF 1st rule 0x4D0 - 0x977 2nd rule 0x978 - 0xE1F 3rd rule They are padded with zeros to a size of 0xFFFF when saved in the ExtData.
  23. Here's the Wailord test wondercard Purin mentioned above. It's in the European Movie 11 Shaymin cart. You can find it in the data.bin file or if you don't unpack the ROM at offset 0x6BD50. This is it's wondercard text, it says something about it beeing a test wondercard. ふしぎなおくりものテストだよ ふなつきばに ふるびたかいずを もっていくと さいはてのことうに いけるぞ! やせいのミュウに あいにいこう! 0011 - ふしぎなおくりものテストだよ.pcd
  24. PKHeX can do that.
  25. Check the Gallery. It is there as pk1 and pk7 files. It doesn't have any Wonder Cards since it is transfered like any other Gen 1 Pokemon. Virtual Vonsole Mew
×
×
  • Create New...