Homebrew Official [Release] EmuNAND9 - Open Source EmuNAND Formatter & Manager

  • Thread starter Thread starter d0k3
  • Start date Start date
  • Views Views 253,945
  • Replies Replies 961
  • Likes Likes 87
Hi again, d0k3,

Well, I don't see much reason at the moment why the starter.bin should not be copied in step 2) (which that option totally does, you just have to select the "auto" version).

I'm still a bit confused about how Sys/Emu formater works, in general. From my understanding, data is stored on random blocks on NAND based SD cards, rather than on continuous blocks in conventional platter based HDs. If we were to run Sys/Emu formater (auto) while starter.bin and NAND.BIN is on the SD card, wouldn't it possibly cause data corruption?

If the above is true, wouldn't it make sense to copy our starter.bin and Sys/Emu NAND.BIN onto the SD card after the partitions are setup to insure data integrity?
 
Hi again, d0k3,



I'm still a bit confused about how Sys/Emu formater works, in general. From my understanding, data is stored on random blocks on NAND based SD cards, rather than on continuous blocks in conventional platter based HDs. If we were to run Sys/Emu formater (auto) while starter.bin and NAND.BIN is on the SD card, wouldn't it possibly cause data corruption?

If the above is true, wouldn't it make sense to copy our starter.bin and Sys/Emu NAND.BIN onto the SD card after the partitions are setup to insure data integrity?
No. the EmuNAND is just a (hidden) partition at the beginning of the SD card. When formatting, we either choose the full capacity of the SD card (excluding the possibility of EmuNAND) or we leave x byte free at the beginning for that EmuNAND partition. Other than that, an EmuNAND format is the same as a regular (non-EmuNAND format). And if you run any format option (there is no SysNAND format option in there), there won't be data corruption in your SD card - your SD card will be completely wiped, as expected from a format.
 
Last edited by d0k3,
Wasup man. I tried updating my EmuNAND via the EmuNAND update guide, but I'm getting a black screen. So I tried using this emuNAND Tool here to inject my backup, but that programs giving me trouble.

Can I boot into your EmuNAND9Tool from sysNAND > Homebrew Launcher to inject my EmuNAND backup back into my EmuNAND? thanks.
 
@MelonGx
Well, I looked into the EmuNAND sizes issue. Annoying as hell as I said... Anyways, I'll add a third (fifth & sixth if you count the 'auto' variants) format option, that will create a bigger / more compatible EmuNAND partition. The other two format options will stay as they are.

Now, what sizes should I choose for best compatibility? I only have one N3DS to test (~1,8GB NAND), so I can't fully decide. Should I just reserve 1GB (for O3DS) / 2GB (for N3DS). Also, will EmuNAND Tool really not work with 'small' EmuNAND partitions? Can you give me the exact error message?
Personally I think 954MB is good for O3DS.
For N3DS I would like to seperate 2 options for 1.21GB & 1.84GB.

Just tried emuNANDTool 1.0.3.
Extract the emuNAND is OK.
Inject NAND to emuNAND comes an error:
 

Attachments

  • 1.png
    1.png
    1.1 KB · Views: 217
Personally I think 954MB is good for O3DS.
For N3DS I would like to seperate 2 options for 1.21GB & 1.84GB.

Just tried emuNANDTool 1.0.3.
Extract the emuNAND is OK.
Inject NAND to emuNAND comes an error:
Well, I already updated the EmuNAND9 source and will make a proper release later. There is now a third format option called 'legacy'. This does it exactly the same as GW does it (2GB for N3DS / 1GB for O3DS). Quite wasteful, but that's the only way we can 100% ensure compatibility with old and no more updated tools. n1ghty seems to have abandoned EmuNAND tool / the forums and won't release the source code either. I won't get any information on expected sizes for EmuNAND Tool either. And, yes, I am a bit frustrated with this compatibility issue :/.

The default option is still based on the actual NAND size, though.

By the way, I might have gotten that wrong, but you can't choose a small EmuNAND size (fe. 1.2GB) on a big SysNAND 3DS (f.e. 1.8GB). It would not work because of the way EmuNAND is implemented in CFWs.
 
Last edited by d0k3,
  • Like
Reactions: MelonGx
Hello !

I have an issue with EmuNAND9.

I choose the option "Complete EmuNAND setup" but it seems that it formated my sysnand o.O ! When it was over, I rebooted the 3DS. I saw a message like "updating your content", and then my download content was not here. It's normal as it wipe the SD card. So I transfered my SD card data back, but my data is still gone !

And now I have two différents folders in the Nintendo 3DS folder, does it mean that my NANDS are unlinked ? So my sysnand has been formated ? I didn't wanted that, it seamed to me that it just installed the emunand with a copy of the sysnand, I didn't want my NANDS to be unlinked.

Is it normal or is there a problem ? How can I have my data back on the sysnand ?

Sorry for the bad English.
 
Personally I think 954MB is good for O3DS.
For N3DS I would like to seperate 2 options for 1.21GB & 1.84GB.

Just tried emuNANDTool 1.0.3.
Extract the emuNAND is OK.
Inject NAND to emuNAND comes an error:
Wouldn't it give a problem if i wanted to inject emunand for some obscure reason to sysnand, if emunand is 954MB and sysnand is only 943MB?
 
Hello !

I have an issue with EmuNAND9.

I choose the option "Complete EmuNAND setup" but it seems that it formated my sysnand o.O ! When it was over, I rebooted the 3DS. I saw a message like "updating your content", and then my download content was not here. It's normal as it wipe the SD card. So I transfered my SD card data back, but my data is still gone !

And now I have two différents folders in the Nintendo 3DS folder, does it mean that my NANDS are unlinked ? So my sysnand has been formated ? I didn't wanted that, it seamed to me that it just installed the emunand with a copy of the sysnand, I didn't want my NANDS to be unlinked.

Is it normal or is there a problem ? How can I have my data back on the sysnand ?

Sorry for the bad English.
@d0k3 this isn't the first report I've heard of this (others were elsewhere) it'd be a good idea to look into this
 
Hello !

I have an issue with EmuNAND9.

I choose the option "Complete EmuNAND setup" but it seems that it formated my sysnand o.O ! When it was over, I rebooted the 3DS. I saw a message like "updating your content", and then my download content was not here. It's normal as it wipe the SD card. So I transfered my SD card data back, but my data is still gone !

And now I have two différents folders in the Nintendo 3DS folder, does it mean that my NANDS are unlinked ? So my sysnand has been formated ? I didn't wanted that, it seamed to me that it just installed the emunand with a copy of the sysnand, I didn't want my NANDS to be unlinked.

Is it normal or is there a problem ? How can I have my data back on the sysnand ?

Sorry for the bad English.
@d0k3 this isn't the first report I've heard of this (others were elsewhere) it'd be a good idea to look into this

Oh well... it can't have to do anything with EmuNAND9, because EmuNAND9 can't write to the SysNAND. The function call for that is stubbed, meaning it just does nothing. The only way to reach a result such as this is by using system format from the homemenu settings. It is also not unlikely you did something wrong... didn't copy the data to the correct location, used the wrong data, catched an update (maybe?), etc... It's also possible that is what happens if you don't copy the SD data back before starting the SysNAND again (unlikely though, right?). Maybe it also has to do with the recent wave of bad downgrades. Needless to say, without the knowledge, without a NAND mod, that downgrade still is not for noobs.

@Galcian44 if you did make a backup of your SysNAND before doing the setup, use EmuNAND9 to clone that backup into the EmuNAND now, then see if you have you're data back in EmuNAND. Also, if you have done anything else, for example with rxTools, tell us, so we might have an idea.

@dark_samus3 at least a very big part of the recent reports must be due to the shear number of new exploit users and the unreliable downgrade. It is still good to keep an ear open.
 
Last edited by d0k3,
I'm back ! And I understood the problem ! In fact when your create the emunand, you have to shutdown the 3DS when it's done, and not reboot.

If you reboot, then the 3DS believe that the SD card is new (it's the case as it is wiped !), and create a new folder in "Nintendo 3DS/XXXXXX/" where XXXXXX is your NAND ID.

In fact, in my SD backup it was :
Nintendo 3DS/XXXXXX/FolderA

(FolderA was a generated string)

When I copy my backup back in the SD card, the 3DS had created this :
Nintendo 3DS/XXXXXX/FolderB

So the XXXXXX part was the same (meaning that the NAND ID was the same) but the 3DS read the FolderB as the new SD content folder.

What you have to do is this : keep the FolderB name in a Notepad, delete it from the SD card, and rename the FolderA with the name of FolderB.

You should retrieve all your data.

Once again, sorry for the bad English.

EDIT : Well d0k3, I did restart my sysnand before copy my SD backup back :). My bad, I didn't remember that the SD card was wiped off and I wanted to shutdown the 3DS properly with a nice reboot on the sysnand xD
 
Last edited by Galcian44,
I'm back ! And I understood the problem ! In fact when your create the emunand, you have to shutdown the 3DS when it's done, and not reboot.

If you reboot, then the 3DS believe that the SD card is new (it's the case as it is wiped !), and create a new folder in "Nintendo 3DS/XXXXXX/" where XXXXXX is your NAND ID.

In fact, in my SD backup it was :
Nintendo 3DS/XXXXXX/FolderA

(FolderA was a generated string)

When I copy my backup back in the SD card, the 3DS had created this :
Nintendo 3DS/XXXXXX/FolderB

So the XXXXXX part was the same (meaning that the NAND ID was the same) but the 3DS read the FolderB as the new SD content folder.

What you have to do is this : keep the FolderB name in a Notepad, delete it from the SD card, and rename the FolderA with the name of FolderB.

You should retrieve all your data.

Once again, sorry for the bad English.
Nope, that is pretty good. Thank you! The <id0> in Nintendo 3DS/<id0>/<id1> is your NAND ID, which can only be changed by a system format. <id1> is in fact generated based on your SD card... Now, can you make sure your data really works? And, keep that backup!
 
Nope, that is pretty good. Thank you! The <id0> in Nintendo 3DS/<id0>/<id1> is your NAND ID, which can only be changed by a system format. <id1> is in fact generated based on your SD card... Now, can you make sure your data really works? And, keep that backup!
Yup, it's working properly :).

I injected BBM with Decrypt9 on the health and security program in order to update the Emunand to 9.5 (I'm on N3DS) but it seems that my 9.5 package was corrupted, I had an error message and my Emunand is not working anymore (black screen). Not a problem, I'm restoring it with the Emunand backup I did before :).

Thank you very much for these Tools (Decrypt9 and EmuNAND9), it's perfect and simple to use.

It's off topic but do you know where I can find a proper dump of 9.5 FW (for N3DS) cias ? 3DNUS doesn't work anymore (it freezes in the middle of the download).
 
Yup, it's working properly :).

I injected BBM with Decrypt9 on the health and security program in order to update the Emunand to 9.5 (I'm on N3DS) but it seems that my 9.5 package was corrupted, I had an error message and my Emunand is not working anymore (black screen). Not a problem, I'm restoring it with the Emunand backup I did before :).

Thank you very much for these Tools (Decrypt9 and EmuNAND9), it's perfect and simple to use.

It's off topic but do you know where I can find a proper dump of 9.5 FW (for N3DS) cias ? 3DNUS doesn't work anymore (it freezes in the middle of the download).
Hmmm... well in fact, once the folder names change, the encryption of the file in it should change as well, so I'm a bit stumped now this works :D. As long as it does everything is fine, though. And no, you need to ask about that somewhere else. I have no idea, and the files should also be copyrighted, so no good asking here.
 
Hmmm... well in fact, once the folder names change, the encryption of the file in it should change as well, so I'm a bit stumped now this works :D. As long as it does everything is fine, though. And no, you need to ask about that somewhere else. I have no idea, and the files should also be copyrighted, so no good asking here.
I understand for the FW, not an issue I will try to launch sysupdater on the emunand (by installing the CIA with BBM).
Like you said, it only changed the <id1> part, the <id0> part is still the same. I didn't try many things, I just saw that the DL games where back on the menu, and I tried to launch one (Ace attorney 5) with success, so I guess everything's OK right ? Moreover, I can see them in the data management menu (in the settings menu)
 
Oh well... it can't have to do anything with EmuNAND9, because EmuNAND9 can't write to the SysNAND. The function call for that is stubbed, meaning it just does nothing. The only way to reach a result such as this is by using system format from the homemenu settings. It is also not unlikely you did something wrong... didn't copy the data to the correct location, used the wrong data, catched an update (maybe?), etc... It's also possible that is what happens if you don't copy the SD data back before starting the SysNAND again (unlikely though, right?). Maybe it also has to do with the recent wave of bad downgrades. Needless to say, without the knowledge, without a NAND mod, that downgrade still is not for noobs.
@dark_samus3 at least a very big part of the recent reports must be due to the shear number of new exploit users and the unreliable downgrade. It is still good to keep an ear open.
Well I was talking to a guy who wasn't exactly a noob, he had a good downgrade afaict, he could boot into CFW and run unsigned CIAs... anyways he formatted a different card for emuNAND and then put his original back into his system and somehow sysNAND wouldn't show any of his eShop content (which was working before the emuNAND format) it would show up in emuNAND if he copied all of the content from one card to the other though
 
Well I was talking to a guy who wasn't exactly a noob, he had a good downgrade afaict, he could boot into CFW and run unsigned CIAs... anyways he formatted a different card for emuNAND and then put his original back into his system and somehow sysNAND wouldn't show any of his eShop content (which was working before the emuNAND format) it would show up in emuNAND if he copied all of the content from one card to the other though
I think the reason is because when SysNAND is run without the data on the SD card, a new folder is created. As @Galcian44 put it. Good thing is, after the "Complete EmuNAND Setup", everyone has a copy of their SysNANDs, right there in the EmuNAND. I still wonder why that does not happen with GW... Maybe GW can't be rebooted that easily?
 
I think the reason is because when SysNAND is run without the data on the SD card, a new folder is created. As @Galcian44 put it. Good thing is, after the "Complete EmuNAND Setup", everyone has a copy of their SysNANDs, right there in the EmuNAND. I still wonder why that does not happen with GW... Maybe GW can't be rebooted that easily?
That can't be it, I have several SD cards that I use with my console, all of the sysNAND folders have the same <id0>/<id1> folders as the number is stored in the NAND (I didn't copy one over to the other, I did a fresh format on each card and the folders were automatically generated by the console) until you do a system format, at which point it'll generate a new set of id folders... (the NAND has a similar structure to the SD card in the fat partition afaik, so it copies the folder names from NAND to your SD card) not really sure how EmuNAND9 messes with it (if it does that is, but it seems that it is the culprit)
 
That can't be it, I have several SD cards that I use with my console, all of the sysNAND folders have the same <id0>/<id1> folders as the number is stored in the NAND (I didn't copy one over to the other, I did a fresh format on each card and the folders were automatically generated by the console) until you do a system format, at which point it'll generate a new set of id folders... (the NAND has a similar structure to the SD card in the fat partition afaik, so it copies the folder names from NAND to your SD card) not really sure how EmuNAND9 messes with it (if it does that is, but it seems that it is the culprit)
One of the two numbers is stored in the movable.sed (the <id0>) (not in cleartext, though). The other one is generated from SD CID, but don't ask me how. And yes, of course the <id1> is stored somewhere in the NAND, too. Point in place: EmuNAND9 can't modify the SysNAND at all. It is absolutely impossible. That function is disabled. You can even confirm this by comparing SysNAND backup0 (before format) with SysNAND backup1 (after format, but before rebooting).

I have a suggestion, though. Something to test that I can't do (I have only one console). Format a SD in EmuNAND9, then use it in another 3DS. Try this in two runs: (1) don't copy anything onto the freshly formatted SD (starter pack is okay), and (2) copy the original Nintendo 3DS folder that belongs to the console you're just testing, then try again.

EDIT: At a second glance, comparing SysNAND backups would be interesting, too, after the reboot. More interesting would be the decrypted CTRNAND after reboot vs decrypted CTRNAND before format.
 
Last edited by d0k3,
One of the two numbers is stored in the movable.sed (the <id0>) (not in cleartext, though). The other one is generated from SD CID, but don't ask me how. And yes, of course the <id1> is stored somewhere in the NAND, too. Point in place: EmuNAND9 can't modify the SysNAND at all. It is absolutely impossible. That function is disabled. You can even confirm this by comparing SysNAND backup0 (before format) with SysNAND backup1 (after format, but before rebooting).

I have a suggestion, though. Something to test that I can't do (I have only one console). Format a SD in EmuNAND9, then use it in another 3DS. Try this in two runs: (1) don't copy anything onto the freshly formatted SD (starter pack is okay), and (2) copy the original Nintendo 3DS folder that belongs to the console you're just testing, then try again.

EDIT: At a second glance, comparing SysNAND backups would be interesting, too, after the reboot. More interesting would be the decrypted CTRNAND after reboot vs decrypted CTRNAND before format.
Don't have 2 consoles to test on either (wish I did) and yeah I also think a comparison of CTRNAND before and after would be interesting... That'd be something I could test if I could find another SD card
 
Don't have 2 consoles to test on either (wish I did) and yeah I also think a comparison of CTRNAND before and after would be interesting... That'd be something I could test if I could find another SD card
Hmmm... @Shadowtrance, could you help us? This is not actually dangerous (don't worry, we'll find dangerous stuff later ;)).

By the way, Shadowtrance, I hope you see this... the last few commits will also help further limit the number of edits you have to make. You don't need to edit common.h anymore, a small change in the Makefile will suffice. Plus, the new Makefile will also automagically copy theme files.
 
Last edited by d0k3,
  • Like
Reactions: dark_samus3

Site & Scene News

Popular threads in this forum