Hacking 3DS Flashcarts - News, Updates, and Support Thread

  • Thread starter Thread starter pedrobarca
  • Start date Start date
  • Views Views 759,433
  • Replies Replies 3,108
  • Likes Likes 11
Actually I don't think they were lying to me. I'm sure they will release something in the next 24-48 hours, but the question is what. Might just be another beta with Pokemon/ACNL support, but without Multirom. Also, if you take a closer look at the news, they never fully confirmed that all the features listed in the new years news will be included in 2.0:



Nand based titles compatibility and Multirom will be 2.0, sure. But they've never confirmed the rest. The other features might just be their goal for other updates in 2014.
Correct me if I'm wrong.


They confirmed ROM dumping to be in 2.0 in an email they sent me
But yeah, you could be right about the beta
 
Actually I don't think they were lying to me. I'm sure they will release something in the next 24-48 hours, but the question is what. Might just be another beta with Pokemon/ACNL support, but without Multirom. Also, if you take a closer look at the news, they never fully confirmed that all the features listed in the new years news will be included in 2.0:

Nand based titles compatibility and Multirom will be 2.0, sure. But they've never confirmed the rest. The other features might just be their goal for other updates in 2014.
Correct me if I'm wrong.
I think they confirmed "Back up your own game cartridges". In addition, they must release "New real time save system" (I think it means that the save gets transfered directly to your microSD) to be at the same/ a higher level with MT-Card.
 
I just sent them a nice juicy email asking about all of what you guys are wondering about. I also asked them to answer my questions fully, which I hope they do rather than sending me a one sentence email saying the update will be released soon. When I get a reply, I will share it with the rest of you :)
 
Says it's in the same function. That's all. You understand what that means, right?
nope. it says it's initialized from the same function as the savegame key. as in at the same time and most likely in the same manner. as in once a firmware below 7.x is done loading (6.x for the savekey) the seed data for key generation isn't there anymore.

and trust me: this is one of the topics regarding my opinion on the 3DS I'd love to be proven wrong.
 
nope. it says it's initialized from the same function as the savegame key. as in at the same time and most likely in the same manner. as in once a firmware below 7.x is done loading (6.x for the savekey) the seed data for key generation isn't there anymore.

and trust me: this is one of the topics regarding my opinion on the 3DS I'd love to be proven wrong.

That's basically what I just said. Whether it's "initialized from the same function" or "in the same function", that's basically the same thing. My guess is that it was worded that way to give an idea on when it's actually generated. Since you seem to be so sure, though, tell me how you're going to decrypt statically encrypted game data with a dynamic key that changes with every console.
 
I just sent them a nice juicy email asking about all of what you guys are wondering about. I also asked them to answer my questions fully, which I hope they do rather than sending me a one sentence email saying the update will be released soon. When I get a reply, I will share it with the rest of you :)
I'm willing to bet a few bucks you'll get a "we're working on it" but possibly reworded.
That's basically what I just said. Whether it's "initialized from the same function" or "in the same function", that's basically the same thing. My guess is that it was worded that way to give an idea on when it's actually generated. Since you seem to be so sure, though, tell me how you're going to decrypt statically encrypted game data with a dynamic key that changes with every console.
The key is the same for every console.
1. Key is generated on console boot.
2. Key is written to a write-only keyslot that can only be used by the decryption engine.
3. Key is cleared from RAM.
4. Console starts up, with no way to recover the key.
Done. At least, that's roughly how it works from what I know.
 
The key is the same for every console.
1. Key is generated on console boot.
2. Key is written to a write-only keyslot that can only be used by the decryption engine.
3. Key is cleared from RAM.
4. Console starts up, with no way to recover the key.
Done. At least, that's roughly how it works from what I know.

I know. That means it is recoverable in some way, however. And due to it being static, it doesn't matter how it's done in the end. You probably won't be able to do it without hardware mods, but who cares? And once "we" have it, we can put it to use.
 
That's basically what I just said. Whether it's "initialized from the same function" or "in the same function", that's basically the same thing. My guess is that it was worded that way to give an idea on when it's actually generated. Since you seem to be so sure, though, tell me how you're going to decrypt statically encrypted game data with a dynamic key that changes with every console.

the base key (the one used since 1.0 for code verification/decryption) is generated the same way on every console no matter which firmware version is running. so its the same on 1.0, 4.5, 7.1 and 7.1 loaded from 4.5 (where it will be already there as the original 4.x has it already generated).

along come 6.0 and 7.0, which each generate another _extra_ key. using seed data which becomes unavailable once the generation is complete (see #1688) and putting the key in an unaccessible memory location (register, slot, whatever).

heck, if they are doing it right neither the seed nor the actual keys get ever leaked outside the soc.
 
I know. That means it is recoverable in some way, however. And due to it being static, it doesn't matter how it's done in the end. You probably won't be able to do it without hardware mods, but who cares? And once "we" have it, we can put it to use.
I know, but if it was that easy, don't you think the save key problem would have been solved by now? As cartridge saves can be loaded on multiple 3DSes, that can't be console exclusive either.
 
Damn, you both have a point.. still, it should be possible with the right hardware mod to catch the key as it is written to the key store. Or so I hope.
 
Finding an exploit for 7.0.0 or
Getting a bootrom dump through chip decapping

Chip decapping is so old school, security researchers are extracting keys from chips using side channel attacks, using either EM or sound. Someone out there has to go to a university with sophisticated signal analysis equipment, this would make a great project for a thesis.
 
Chip decapping is so old school, security researchers are extracting keys from chips using side channel attacks, using either EM or sound. Someone out there has to go to a university with sophisticated signal analysis equipment, this would make a great project for a thesis.
From what I know, you need to be able to feed any data you want into the decryption engine in order to figure it out though. At least, that's my understanding of the 4096-RSA attack.
 
since nobody replies in the noob paradise thread, I'll ask here:

can I rollback to 2.0b1 or even 1.2 if I have the 7.1 firmware on emunand? are they compatible?
also: I only have retail pokemon X for now (the GW card is arriving). will my save be in danger with 2.0b1? or aren't retail cards' saves affected?
in case 7.1 isn't compatible with 2.0b1, I can recreate emunand with 6.3 since I have it downloaded in realnand. but, again, what will happen to my pokemon X save?

thanks for the help.
 
since nobody replies in the noob paradise thread, I'll ask here:

2.0b1 has some bugs with emunand 7.1 (region free doesn't work for example).
1.2 will just ignore emunand.

If you've already made a save on pokemon (I assume you have two systems), then it will show as corrupted on emunand and you need to wipe and start over.

You can either have a save made on a retail system with pokemon or one made on an emunand system. They are not compatible with each other.
 
nono, I'm using gateway's launcher because I had access to a DS flashcard.
soo, apart from the region free issues that aren't a problem for me, do the save corruption issues affect retail cartridges' saves?
also, I just remembered that prior to 2.0b2 there were issues with firmware 4.1 (I have this). I don't remember what they were, though.

basically, I don't know how the saves work with emunand and retail games. are they partially stored in the sd card or are they entirely in the cartridge?
 
nono, I'm using gateway's launcher because I had access to a DS flashcard.
soo, apart from the region free issues that aren't a problem for me, do the save corruption issues affect retail cartridges' saves?
also, I just remembered that prior to 2.0b2 there were issues with firmware 4.1 (I have this). I don't remember what they were, though.

basically, I don't know how the saves work with emunand and retail games. are they partially stored in the sd card or are they entirely in the cartridge?

Using the first beta in 4.1 nullifies all of their spoofing patches, as well as having emuNAND in 7.1 (I could be wrong with something here, but that's what I remember).
The save corruption issue is entirely unrelated to retail cartridges.
For roms, the save is supposed to be stored in the GW's card at first, then copied to the SD card after closing the game. The issue with the saves occurs in this process, but it is avoidable if you load and then close a rom; if it freezes, then just reset; if it doesn't, then it's safe to keep playing as long as you don't turn off the console or go to system settings.
 
FUUUUUUUUUUU
and I can't even install another firmware with a rom since I don't have the GW flashcart.

So you sold the flashcard and you only want to play regular cartridges? Well, you certainly don't need to worry about it if you already have the emuNAND in 7.1 or 6.3.
 

Site & Scene News

Popular threads in this forum