Hacking Pokemon X/Y retail on GW 2.0 *ONLINE WORKING*

[Luizim]

OK, I've seen a lot of people wanted to know about this, myself included. So I went ahead and bought a Pokemon X retail cartridge at the store.

I was able to connect normally to the internet on GW emuNand. I've received my Mystery Gift already, and was also able to connect to GTS, Wonder Trade, add friends, etc.

Hope this helps clear things out about online playing with RETAIL GAMES on emuNand.

Cheers!

UPDATE:
Patched X to 1.1 and it's still working normally/online.

Apparently there's still no way to get X/Y with saves from real nand consoles working on emuNand. If a way is found, I'll update here.

 

[JonnyMohawk]

Strange, I can't get my retail copy of X to work.

Others seem to be having the same issue, it looks like it may only affect those who already started a game on another system.


I attached an image of the error I get, works fine on my 2DS....

 

[DarkKnigh_t]

Thank you very much this is a big thing i was wondering about this and nice to see someone tested it out and posted thank you again!

 

[Luizim]

Strange, I can't get my retail copy of X to work.

Others seem to be having the same issue, it looks like it may only affect those who already started a game on another system.


I attached an image of the error I get, works fine on my 2DS....

Yes, I've read about this on another topic.

Apparently it will work fine with a brand new Pokemon X/Y cartridge, while it might give errors for cartridges that have been used before.

 

[Keylogger]

I'll try with MarioKart 7 online

 

[Pong20302000]

its the Save KeyY used, if you have a existing save the KeyY is wrong
but on a new cart it will use the 4.5.0 KeyY
so if those people where to then use the cart on a official 6.3.0 they would get the same error

 

[mathieulh]

As far as I've tested, online works fine as long as the game you are using is from the same region as your 3DS. I could be wrong though, all the EU games I tested on my EU 3DS worked fine online. I could even purchase phoenix wright 5's in-game DLC.

 

[Snailface]

My retail card works too although it can't read the game's save.

 

[mathieulh]

its the Save KeyY used, if you have a existing save the KeyY is wrong
but on a new cart it will use the 4.5.0 KeyY
so if those people where to then use the cart on a official 6.3.0 they would get the same error

Ironically, it'd most likely load fine on a real 6.x.x system because the old KeyY is still present in it's keyslots.
You are right though, you pinpointed the issue as that's exactly what's going on.
Since the KeyY slot is "write only" the only way to get the key is to dump or decrypt the new bootloader (the keyslot is written/set by the bootloader) as you can't read the slot directly on a live system (the decryption goes through the AES hardware engine)

 

[DarkKnigh_t]

Well thats still something as long as it works thats the main thing.

 

[Arras]

Yeah, pretty much. The retail game will work 100% okay on an emuNAND, but it will fuck up save files from 6.3 3DSes.

 

[mathieulh]

Yeah, pretty much. The retail game will work 100% okay on an emuNAND, but as soon as you try playing it in a real 6.3 3DS it fucks up your save file. The same is true for the other way around. This ALSO means that if Gateway ever adds real NAND 6.3 compatibility, you can't update to that without fucking over your save files.

Hum... I guess that as soon as it detects an application compiled with the 6.x.x SDK it forces the use of the new KeyY, either that or a new save function that only uses the KeyY slot is used and GW somewhat patches it to use the old slot because the new KeyY doesn't exist on emuNAND, that would explain why the save encrypted with the older key doesn't load on newer firmwares.

 

[Arras]

Hum... I guess that as soon as it detects an application compiled with the 6.x.x SDK it forces the use of the new KeyY, that would explain why the save encrypted with the older key doesn't load on newer firmwares.

I was guessing and just edited my post to change it. Sorry for the confusion

 

[mathieulh]

I was guessing and just edited my post to change it. Sorry for the confusion

Ok, then as I've said, although I have not tested this, it's likely a save encrypted with the old KeyY would load just fine on an official 6.x.x firmware (but not the other way around)

 

[Arras]

Ok, then as I've said, although I have not tested this, it's likely a save encrypted with the old KeyY would load just fine on an official 6.x.x firmware (but not the other way around)

That would make sense, otherwise it might screw over people who are using a regular 3DS, create a save file and then update it to some firmware that uses a newer KeyY, right? Then again Pokemon was never intended to run on 4.5 anyway.

 

[Snailface]

Yeah, pretty much. The retail game will work 100% okay on an emuNAND, but it will fuck up save files from 6.3 3DSes.

I got a save corruption error right as the game booted on 6.3 emunand. I just turned the power off immediately and the save still worked on my official 6.3 system. Thank goodness.

 

[mathieulh]

That would make sense, otherwise it might screw over people who are using a regular 3DS, create a save file and then update it to some firmware that uses a newer KeyY, right? Then again Pokemon was never intended to run on 4.5 anyway.

It doesn't work that way, only games compiled using SDK 6.x.x use the new KeyY, older games still use the old key, even on newer firmwares.

 

[Arras]

I got a save corruption error right as the game booted on 6.3 emunand. I just turned the power off immediately and the save still worked on my official 6.3 system. Thank goodness.

As long as you don't give it the chance to re-initialize the save file or whatever it does it's fine, yeah. I'm not sure whether it does that automatically when it detects a corrupted save or only when you actually try to save though.

 

[tHciNc]

Hum... I guess that as soon as it detects an application compiled with the 6.x.x SDK it forces the use of the new KeyY, either that or a new save function that only uses the KeyY slot is used and GW somewhat patches it to use the old slot because the new KeyY doesn't exist on emuNAND, that would explain why the save encrypted with the older key doesn't load on newer firmwares.

the KeyY is firmware dependant as no SDK 6.x games have shown up yet, aslong as game has 6.X update or was finalized after 6.x release, it will use new flags to determine new keyY method, i think highest sdk for a game i have seen is 5.2.2
6.0.0-11 Savegame keyY
6.0.0-11 implemented support for generating the savegame keyY with a new method, this method is much more complex than previous keyY methods. This is enabled via new NCSD partition flags, all retail games which have the NCSD image finalized after the 6.0.0-11 release(and 6.0.0-11+ in the system update partition) will have these flags set for using this new method.

I think since EmuNAND is using 4.5 base like pong said, it doesnt know any of the new flags and will just save using the old KeyY method, not sure if this means its corrupt if you then try to play on a 6.3 system, but more than likely it will as flags will expect the newer KeyY, not the old, EmuNAND is like a chameleon, 4.5 masquarading as 6.3

 

[mathieulh]

the KeyY is firmware dependant as no SDK 6.x games have shown up yet, i think highest have seen is 5.2.2
6.0.0-11 Savegame keyY
6.0.0-11 implemented support for generating the savegame keyY with a new method, this method is much more complex than previous keyY methods. This is enabled via new NCSD partition flags, all retail games which have the NCSD image finalized after the 6.0.0-11 release(and 6.0.0-11+ in the system update partition) will have these flags set for using this new method.

Ok that makes more sense, the firmware simply enforces the use of a new key with a NCSD partition flag.
They actually patched this routine in the GW payload to use the old savedata generation since the new key doesn't exist in the emuNAND and the new 6.x.x most likely does not ignore that flag anymore.

This also means the key generation isn't game code dependent, as one could just flag an old game to use it, as long as the firmware supports it, it would, no matter what SDK it's been compiled with or libs/functions it's using.

P.S. Thanks, that's very useful information, where did you get it from ? (I don't have a copy of the official sdk or the like to see changelogs)