Hacking Pokemon Bank not working on emunand

[gamesquest1]

The exploit is run using the installer.nds......all your other card specific files remain the same

 

[mathieulh]

Pokemon Bank's NCCH from the EU store uses the new 7.x.x keys. (I just checked the flags)
https://twitter.com/Mathieulh/status/431002473625436161

I did warn people about this. More and more titles will keep using the new keys from now on.

 

[masterzero]

games that need 7.0 will need time to come out ? since I guess they couldn't change the update they need working in mid development ? or can they?

 

[mathieulh]

games that need 7.0 will need time to come out ? since I guess they couldn't change the update they need working in mid development ? or can they?

My guess is, any game built with SDK 7.0.0+ will be flagged to use the new keys.

 

[gamesquest1]

Would it be possible to just change the flag for 7.x keys, if the FW is patched to accept modified files

Or are the 7.x keys actually used to decrypt the game/apps

 

[WiiUBricker]

Which means an exploit for 7.X is needed.

 

[mathieulh]

Would it be possible to just change the flag for 7.x keys, if the FW is patched to accept modified files

Or are the 7.x keys actually used to decrypt the game/apps

It's obviously used to decrypt the container, you can't just hope for the NATIVE_FIRM to decrypt content that requires a key it can't access.

 

[profi200]

And now it begins. No flashcard company can do a shit against that. They would need to decap the SoC, which i don't think they will do. The part of the NATIVE_FIRM, which generates the key for that, is in internal memory and therefore not even a RAM dumping setup do a shit here.

Nintendo did his homework this time. As long, as the system is secure against exploits, there is no chance. Currently it doesn't look like there is anything exploitable...

 

[xextil]

And now it begins. No flashcard company can do a shit against that. They would need to decap the SoC, which i don't think they will do. The part of the NATIVE_FIRM, which generates the key for that, is in internal memory and therefore not even a RAM dumping setup do a shit here.

Nintendo did his homework this time. As long, as the system is secure against exploits, there is no chance. Currently it doesn't look like there is anything exploitable...

Why not? They have enough money for that, and if they do it, they could find new exploits and make more money.

 

[hjezz]

Wait, what? does pokemon witout card works?

 

[trance]

Why not? They have enough money for that, and if they do it, they could find new exploits and make more money.

Yep, all because of the Gateway drug cards. No point slagging Gateway for all the bricks when people will relapse for 7.x features

 

[mathieulh]

And now it begins. No flashcard company can do a shit against that. They would need to decap the SoC, which i don't think they will do. The part of the NATIVE_FIRM, which generates the key for that, is in internal memory and therefore not even a RAM dumping setup do a shit here.

Nintendo did his homework this time. As long, as the system is secure against exploits, there is no chance. Currently it doesn't look like there is anything exploitable...

Actually, you don't need to dump the generated key from ram, if you can read/write to memory all you need is to gain code execution by patching instructions before the ones that clear the keyslot is executed, then you simply use your own code to generate the key and output it to wherever.

That's assuming you do have a working hardware RAM setup.

Of course it's not as easy as it looks.

Also since you cannot read the initial keyslot set by the bootrom (or the bootrom itself), you will need to keep generating new keys that Nintendo might add through future NATIVE_FIRM.
That doesn't seem much of a showstopper though, assuming you have the right setup to generate one already.

You should keep in mind that as long as you do get ARM9 code execution, you can read/write the content of the internal memory as well and there is code running off the external RAM before NATIVE_FIRM is executed, so it doesn't seem far fetched.

 

[profi200]

Actually, you don't need to dump the generated key from ram, if you can read/write to memory all you need is to gain code execution by patching instructions before the ones that clear the keyslot is executed, then you simply use your own code to generate the key and output it to wherever.

That's assuming you do have a working hardware RAM setup.

No, you can do, what you want. You have no access to internal memory and therefore you can not patch anything. The NATIVE_FIRM is running in internal memory. If you have code execution through the RAM haxx, it is already to late.

Why not? They have enough money for that, and if they do it, they could find new exploits and make more money.

^ They don't really care about their customers. I bet they have enough money, so they could run off, if they want.

 

[Steena]

Given GW's constant delays I'd say it's pretty safe to assume that they won't be able to find a workaround for the aforementioned issue within the month (if ever, according to some of the more negative perspectives), so, for those that care about pokebank and are on emunand, you won't get to use your free month unless you use another 3DS.

 

[misterb98]

The only way I can see to get around this problem is for someone to make a CFW (which is far, FAR away). It would need to be based off of 7.X and yet be able to run unsigned code.

Its going to be a LOOOOOONG wait.


That is unless an exploit is found for 7.X+, lol.

 

[tyons]

[...] so, for those that care about pokebank and are on emunand, you won't get to use your free month unless you use another 3DS.

or, if someone can confirm that it would work, do the following:

mount the hardware mod;
backup the 4.x realnand;
update realnand to 7.x;
download the pokebank;
transfer the pokes from BW/BW2 to the global link (and I assume we don't need the X/Y cartridge at all to do it);
backup the 7.x realnand for the future;
restore the 4.x realnand;
enter X/Y in emunand and transfer the pokes into the game.

 

[gamesquest1]

Well I'm fairly sure you would need pokebank to run to be able to copy them over on to X/Y right? So I'm not sure that would even work

 

[tyons]

I thought we could do it just with the normal games. I don't know how the pokebank software works, that's the problem.

edit: ok I searched and probably we have to move the pokes from the bank's boxes to the game's ones, so yeah, that method doesn't work...

come onnn pokecheck guyssss!!! >_>

 

[DaveTheBaker]

Can some one check the us pokebank app now that it's out?

 

[Arras]

The only way I can see to get around this problem is for someone to make a CFW (which is far, FAR away). It would need to be based off of 7.X and yet be able to run unsigned code.

Its going to be a LOOOOOONG wait.


That is unless an exploit is found for 7.X+, lol.

And then Nintendo releases 8.x which uses a different key and fixes the exploit

Can some one check the us pokebank app now that it's out?

It's almost guaranteed to have the same issue considering it came out after the EU one.

or, if someone can confirm that it would work, do the following:

mount the hardware mod;
backup the 4.x realnand;
update realnand to 7.x;
download the pokebank;
transfer the pokes from BW/BW2 to the global link (and I assume we don't need the X/Y cartridge at all to do it);
backup the 7.x realnand for the future;
restore the 4.x realnand;
enter X/Y in emunand and transfer the pokes into the game.

You would be able to transfer from BW2->Bank yeah, but Bank->XY requires Bank to read the XY save data. If said save data was created with 4.X chances are very high it will read as corrupt on 7.1 realNAND, and even if it doesn't, after you save the save file will be corrupt on 4.X. And then there's the protection that prevents you from messing with save files that may trigger if you restore NAND.