suloku Posted March 21, 2017 Share Posted March 21, 2017 I've been doing some test, but seems BlackShark make a lot more research! I was about to post about the flag location and found he already did quite the research. It's curious that they allow for the 8 legendaries in the structure, while the game only allows to transfer 6 pokémon at a time (legendaries + catched) for some reason. I made a quick test and I managed to re-receive some of the legendaries, but not all of them. What I did was get my savegame that hadn't made any Dream Radar connection, get the 0x25E00 value and paste it in a save that has received 7/8 legendaries at 0x25E00 and 0x7F004, I also cleared 0x25E04 and 0x25E08. I'm gonna set 0x25E00 to 0x00 and see what happens when transfering something over. EDIT: I just noticed that after receiving landorus on the 0x00 file, the dream radar block still has the 0x80808080 for tornadus, so maybe what's needed is to clear the flags and those "identificators". The value I got at 0x25E00 after a single transfer when it was all zeroed is "86 FF A0 F1" (direct hex view). EDIT 2: I've just realized that for our purposes, we don't really need to know how it exactly works, we can just reset the whole thing to an "unused" state, as if dream radar was never used in that savegame, there's really no need to individually clear each flag. 1 Link to comment Share on other sites More sharing options...
BlackShark Posted March 21, 2017 Share Posted March 21, 2017 48 minutes ago, suloku said: I've been doing some test, but seems BlackShark make a lot more research! I was about to post about the flag location and found he already did quite the research. It's curious that they allow for the 8 legendaries in the structure, while the game only allows to transfer 6 pokémon at a time (legendaries + catched) for some reason. I made a quick test and I managed to re-receive some of the legendaries, but not all of them. What I did was get my savegame that hadn't made any Dream Radar connection, get the 0x25E00 value and paste it in a save that has received 7/8 legendaries at 0x25E00 and 0x7F004, I also cleared 0x25E04 and 0x25E08. I'm gonna set 0x25E00 to 0x00 and see what happens when transfering something over. EDIT: I just noticed that after receiving landorus on the 0x00 file, the dream radar block still has the 0x80808080 for tornadus, so maybe what's needed is to clear the flags and those "identificators". The value I got at 0x25E00 after a single transfer when it was all zeroed is "86 FF A0 F1" (direct hex view). 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. Link to comment Share on other sites More sharing options...
suloku Posted March 21, 2017 Share Posted March 21, 2017 2 hours ago, BlackShark said: 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. Yes, I also tweaked it a little and was able to receive again some pokémon (but not all of them). I'm going to try the full reset with arbitrary 0x25E00/0x7F004 value, see if I can receive them all all over again. Also I'll check again the 8 at once transfer, but I didn't have any normal pokémon and it didn't allow me to transfer all 8 for some reason. EDIT: it did not allow me to transfer all 8 at once yet again, only 6. I only had legendaries. Lugia and Ho-oh were left out. EDIT 2: Do you have a savefile that has never transfered anything from Dream Radar? Maybe the same value at 0x25E00 is used for all games, or tied to TID/SID in some way to make it unique. Mine at 0x25E00 is 0x783398F2 and I checked the first savefile backup (right before selecting the starter) and my latest one (never had used dream radar) and the value is unchanged. TID: 07310, SID: 41549 In any case I'll start a new game and check what gets in 0x25E00 EDIT 3: seems random, I even tried used my savegame with memory transfer (which always results in the same key for the key system), but also generates one at random. Changing TID/SID doesn't seem to have any effect. I've noticed a suspicious value at 0x19428, but it may be unrelated as it lays in the trainer region. EDIT 4: 0x19428 is unrelated, pokestock doesn't handle the receive flags. On a save that had received all 8 legendaries, I went and put the data for the 0x25e00 block and dream radar block from a save before ever interacting with dream radar and I could receive them again. Link to comment Share on other sites More sharing options...
AyanamiRei0 Posted March 21, 2017 Author Share Posted March 21, 2017 Well this has really confused me stuff like this is really out of my league. Link to comment Share on other sites More sharing options...
suloku Posted March 22, 2017 Share Posted March 22, 2017 Basically, it seems that clearing the flags needs an extra step since they seem to be encrypted in some unique per savegame way. I've just thought a tedious way of locating where the secret value migth be, albeit time consuming: 1) Create two blank savefiles (A and B) (blank so less data is in them, the 3DS link feature is accessible anyways). 2) Put the value at 0x25E00 from B in A, then check if any of the lengendaries can't be transfered anymore (we want at least one to be flagged as already transfered) 3) Start inserting blocks from savegame B into savegame A. After each insertion, check if the game allows to transfer the legendary again. 4) Repeat 3 until we can transfer the lengedary. Those steps would allow us to locate the block where the value used with 0x25E00 is stored, from there locating the actual value should be easier...at least in theory. Another option would be to reverse engineer how the value at 0x25E00 is generated on a new game, but that's something I can't do. This reminds me of the mirage island in ORAS, I hope this uses a simple operation with a value somewhere in the save, and not a complicated algorythm like that one (which someone actually went and kindly reversed). EDIT: I've been using desmune and I've noticed that each time you receive 3DS link data, the value at 0x25E00 is different, so as I feared this seems to have some RNG involved... 1 Link to comment Share on other sites More sharing options...
BlackShark Posted March 22, 2017 Share Posted March 22, 2017 @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 1 Link to comment Share on other sites More sharing options...
suloku Posted March 22, 2017 Share Posted March 22, 2017 Nice find! I've just tried it myself, at first 3DS Link option claimed the data was corrupted (I used Pockestock to insert the data instead of the actual app), so I basically wiped out 0x25e00 to be all zeroes and put the dream radar data at 0x7F000 with an encryption key of 0x00000000. Now I'm thinking that clearing both 0x7F000 and 0x25e00 block should reset the flags, but I think I already tried and my save got erased due to corruption...probably I messed up somewhere. By the way, the value at 0x25e00 (and enc key) gets updated also when transfering non lengedaries/items... I wonder how that works. I'll code my own version of PokeTrainerS tomorrow, with an option to "reset" the encryption key to receive the legendaries again. Or maybe I should just make it always wipe the data and write it unencrypted for simplicity? ps: in the end you were the one who did all relevant research and findings Link to comment Share on other sites More sharing options...
BlackShark Posted March 23, 2017 Share Posted March 23, 2017 7 hours ago, suloku said: Nice find! I've just tried it myself, at first 3DS Link option claimed the data was corrupted (I used Pockestock to insert the data instead of the actual app), so I basically wiped out 0x25e00 to be all zeroes and put the dream radar data at 0x7F000 with an encryption key of 0x00000000. Now I'm thinking that clearing both 0x7F000 and 0x25e00 block should reset the flags, but I think I already tried and my save got erased due to corruption...probably I messed up somewhere. By the way, the value at 0x25e00 (and enc key) gets updated also when transfering non lengedaries/items... I wonder how that works. I'll code my own version of PokeTrainerS tomorrow, with an option to "reset" the encryption key to receive the legendaries again. Or maybe I should just make it always wipe the data and write it unencrypted for simplicity? ps: in the end you were the one who did all relevant research and findings 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. Link to comment Share on other sites More sharing options...
suloku Posted March 23, 2017 Share Posted March 23, 2017 On 23/3/2017 at 7:49 AM, BlackShark said: 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. Yes, I thought that might have been the culprit, I should have explored more why my save got deleted after clearing the blocks. I did plan a dream radar editor since the begining, but never got to research it. I already have functions for block managing, checksum fixing and decrypting so It's not like I have to make all from scratch. In fact, I'd like to replicate all pokestock functions that can't be done with pkhex (I think entralink records and other stats may be the only thing missing since other functions can be done with pokegen or other english tools, but I'd also like to see those in an open source fashion), but since there's no demand or personal need motivation to do it just lacks. As ultimate goal, integrating all into pkhex would be great, but my coding style and knowledge isn't adecuate for it, but at least an open source program can serve as some sort of documentation for someone else to integrate it into pkhex. EDIT: I have the editor nearly finished and stumbled upon a problem, but after comparing two examples with pockestock I've noticed how the actual encryption key is generated: Enc key at 0x7F014 is XORed with the legendaries flags present at 0x25E04, and then that's the actual encryption key that will be used and stored at 0x7F090. The value at 0x25E00/0x7f004 might be just a seed to generate the next encryption key...it doesn't serve any apparent purpose. In any case, with that last piece of information I can complete the editor, hopefully bug-free. EDIT 2: You may find the updated program with the 3DS link editor here: https://github.com/suloku/BW_tool/releases Hopefully it's bug free, it seemed to work fine for what I tested, even just reseting the flags worked.@AyanamiRei0@BlackShark EDIT 3: I've just re-read BlackShark's post and turns out I failed to understand that he already explained how the flags where XORed with the encryption key... (blame it to language or me being tired, luckily I didn't spend more than 15 minutes to figure out, it would be a shame if I spend hours trying to find something already found and posted...) 1 Link to comment Share on other sites More sharing options...
AyanamiRei0 Posted March 28, 2017 Author Share Posted March 28, 2017 (edited) On 23/03/2017 at 11:44 AM, suloku said: Yes, I thought that might have been the culprit, I should have explored more why my save got deleted after clearing the blocks. I did plan a dream radar editor since the begining, but never got to research it. I already have functions for block managing, checksum fixing and decrypting so It's not like I have to make all from scratch. In fact, I'd like to replicate all pokestock functions that can't be done with pkhex (I think entralink records and other stats may be the only thing missing since other functions can be done with pokegen or other english tools, but I'd also like to see those in an open source fashion), but since there's no demand or personal need motivation to do it just lacks. As ultimate goal, integrating all into pkhex would be great, but my coding style and knowledge isn't adecuate for it, but at least an open source program can serve as some sort of documentation for someone else to integrate it into pkhex. EDIT: I have the editor nearly finished and stumbled upon a problem, but after comparing two examples with pockestock I've noticed how the actual encryption key is generated: Enc key at 0x7F014 is XORed with the legendaries flags present at 0x25E04, and then that's the actual encryption key that will be used and stored at 0x7F090. The value at 0x25E00/0x7f004 might be just a seed to generate the next encryption key...it doesn't serve any apparent purpose. In any case, with that last piece of information I can complete the editor, hopefully bug-free. EDIT 2: You may find the updated program with the 3DS link editor here: https://github.com/suloku/BW_tool/releases Hopefully it's bug free, it seemed to work fine for what I tested, even just reseting the flags worked.@AyanamiRei0@BlackShark EDIT 3: I've just re-read BlackShark's post and turns out I failed to understand that he already explained how the flags where XORed with the encryption key... (blame it to language or me being tired, luckily I didn't spend more than 15 minutes to figure out, it would be a shame if I spend hours trying to find something already found and posted...) This normal? Edited March 28, 2017 by AyanamiRei0 Link to comment Share on other sites More sharing options...
theSLAYER Posted March 28, 2017 Share Posted March 28, 2017 What is Waterfox.exe? edit: Nvm, quick google search shows its a modified Firefox browser. Lol at its name. Avast is blocking Github? that's weird Link to comment Share on other sites More sharing options...
AyanamiRei0 Posted March 28, 2017 Author Share Posted March 28, 2017 It's just the download I put the URL for the file into VirusTotal and it only got found by two antivirus I don't think it's a virus I'm just going to build the thing myself Link to comment Share on other sites More sharing options...
suloku Posted March 28, 2017 Share Posted March 28, 2017 The source is there, I don't know what triggers avast, but you may check the code (or build by yourself). I used sharpdevelop 5.1. Link to comment Share on other sites More sharing options...
AyanamiRei0 Posted March 29, 2017 Author Share Posted March 29, 2017 9 hours ago, suloku said: The source is there, I don't know what triggers avast, but you may check the code (or build by yourself). I used sharpdevelop 5.1. Yeah I built it with Visual Studio just fine 1 Link to comment Share on other sites More sharing options...
Lightning Flik Posted June 16, 2022 Share Posted June 16, 2022 I know this was a long time ago and as I am a complete beginner with coding I was wondering if it would be possible to make an AR code to reset the flags / replace a chunk of the block? Link to comment Share on other sites More sharing options...
mewto2015 Posted May 14 Share Posted May 14 On 3/19/2017 at 4:40 AM, BlackShark said: 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. ONE QUESTION, im new in this how can i reset the recibe again pokemon of pokemon radar? Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now