Restore N3DS from FW 2.1 without NAND Backups

d0k3 · Apr 30, 2016

slslasher said:
Sure I will let you guys know the results. The 512 bytes do u mean using a hexeditor and copy the values 0x200 (512) bytes. Length in hex editor is 200.

Yup. But, as I said, you need to do the legwork on your own, or let other users help you with it.

slslasher · Apr 30, 2016

d0k3 said:
Yup. But, as I said, you need to do the legwork on your own, or let other users help you with it.

I got a N3DS dump on 10.7 to use from. Actually I did tried to update to 4.5 yesterday but using sky3ds with a game with 4.5 update but an error had occured. I am not sure whether sky3ds is causing the issue or just a bad dump of the game.

d0k3 · Apr 30, 2016

slslasher said:
I got a N3DS dump on 10.7 to use from. Actually I did tried to update to 4.5 yesterday but using sky3ds with a game with 4.5 update but an error had occured. I am not sure whether sky3ds is causing the issue or just a bad dump of the game.

Alright, last pointer I give you... Yes, you can upgrade to v4.5 with Sky3DS. Find a game that works (correct update, correct region) for you from here: http://www.3dsdb.com/

I've been told Animal Crossing [E] works for [E] consoles. If the first try does not succeed, try again.

slslasher · Apr 30, 2016

d0k3 said:
Alright, last pointer I give you... Yes, you can upgrade to v4.5 with Sky3DS. Find a game that works (correct update, correct region) for you from here: http://www.3dsdb.com/

I've been told Animal Crossing [E] works for [E] consoles. If the first try does not succeed, try again.

Stuck at updating to 4.5. Still trying different games despite getting this error.

d0k3 · Apr 30, 2016

slslasher said:
Stuck at updating to 4.5. Still trying different games despite getting this error.

Okay, after asking around... Try different versions (4.0 to *not including* 7.0, but try to stay below or on 4.5). You're goal is to get to a version with a SysUpdater entrypoint. That's all I know, for more you need to ask around.

slslasher · Apr 30, 2016

d0k3 said:
Okay, after asking around... Try different versions (4.0 to *not including* 7.0, but try to stay below or on 4.5). You're goal is to get to a version with a SysUpdater entrypoint. That's all I know, for more you need to ask around.

Ok I managed to update to 4.5. Turns out I need to remove the update files by going to the recovery and exiting. Currently formatting emunand using gateway. I have got a gateway card, would it work if I do everything in emunand instead? after that if emunand can be reverted back to 9.2 n3ds, I can flash it back to sysnand.

d0k3 · Apr 30, 2016

slslasher said:
Ok I managed to update to 4.5. Turns out I need to remove the update files by going to the recovery and exiting. Currently formatting emunand using gateway. I have got a gateway card, would it work if I do everything in emunand instead? after that if emunand can be reverted back to 9.2 n3ds, I can flash it back to sysnand.

Yes, do it on EmuNAND, no problem. I'm a bit unsure if it will work (running a N3DS type EmuNAND from a O3DS type SysNAND), though, but you will see.

Ichigo1000 · Apr 30, 2016

slslasher said:
ok I actually manage to flash back 2.1 emunand backup to sysnand which is working. Read from another thread that plailect is currently working on a solution for people like me who are stucked at n3ds 2.1 without a nand backup.

Shall wait for the good news.

https://github.com/Plailect/Guide/wiki/3DS-Stuck-(2.1.0-Without-Functional-Browser)

How did you extract an emunand backup from the sd card? Did you use another 3ds to dump it?

slslasher · May 1, 2016

d0k3 said:
Yes, do it on EmuNAND, no problem. I'm a bit unsure if it will work (running a N3DS type EmuNAND from a O3DS type SysNAND), though, but you will see.

Tried it on emunand didnt work. Just to confirm, slot 0x04 means nand.fat16.0x4.xorpad and slot 0x05 means nand.fat16.xorpad? Dump your CTRNAND meaning fat16 image? I am using 3DS Fat16 NAND tool GUI.

--------------------- MERGED ---------------------------

Ichigo1000 said:
How did you extract an emunand backup from the sd card? Did you use another 3ds to dump it?

I used 3ds-multinand to extract out from the micro sd

Ricken · May 1, 2016

Im curious to see how this turns out

Good Luck

slslasher · May 1, 2016

Still not working for me. These are the steps I took.

1) Extracted slot 0x05 (nand.fat16.xorpad) and slot 0x04 (nand.fat16.0x4.xorpad) XORpads
2) Upgrade to v4.5 using a cartridge (Sky3ds)
3) Used gateway to make a 4.5 emuNAND (Made a backup of it using 3ds-multinand so I can flash it back to sysNAND)
4) Using SysUpdater and a N3DS FW 9.2 update pack and updated the emuNAND
5) emuNAND is N3DS FW 9.2 but bricked now
6) Extracted bricked emuNAND 9.2 using 3ds-multinand
7) To unbrick, dumped my NAND, then dumped my CTRNAND from that with 3DSFAT16 tool using the slot 0x04 XORpad
8) Injected the CTRNAND back into the NAND dump using the slot 0x05 XORpad
9) Replace the first 512 byte of NAND dump with the first 512 byte from another working N3DS NAND dump FW 9.2 (I got an extra N3DS for this)
10) Injected back my "Unbricked" emuNAND 9.2 using 3ds-multinand back to micro sd
11) Tried to run emuNAND but black screen
12) Flash back to 2.1 and restore sysnand using OTPhelper to "Unbricked" emuNAND 9.2 but still black screen
13) Tried flashing the "Unbricked" emuNAND 9.2 directly by using hardmod method still didn't work either

Could my XORpad I extracted be a bad dump? File size for both is 1,106,247,680 bytes

I will tried again if I got the time. Please let me know if there is any steps I missed out or didn't do.

mathieulh · May 1, 2016

slslasher said:
Still not working for me. These are the steps I took.

1) Extracted slot 0x05 (nand.fat16.xorpad) and slot 0x04 (nand.fat16.0x4.xorpad) XORpads
2) Upgrade to v4.5 using a cartridge (Sky3ds)
3) Used gateway to make a 4.5 emuNAND (Made a backup of it using 3ds-multinand so I can flash it back to sysNAND)
4) Using SysUpdater and a N3DS FW 9.2 update pack and updated the emuNAND
5) emuNAND is N3DS FW 9.2 but bricked now
6) Extracted bricked emuNAND 9.2 using 3ds-multinand
7) To unbrick, dumped my NAND, then dumped my CTRNAND from that with 3DSFAT16 tool using the slot 0x04 XORpad
8) Injected the CTRNAND back into the NAND dump using the slot 0x05 XORpad
9) Replace the first 512 byte of NAND dump with the first 512 byte from another working N3DS NAND dump FW 9.2 (I got an extra N3DS for this)
10) Injected back my "Unbricked" emuNAND 9.2 using 3ds-multinand back to micro sd
11) Tried to run emuNAND but black screen
12) Flash back to 2.1 and restore sysnand using OTPhelper to "Unbricked" emuNAND 9.2 but still black screen
13) Tried flashing the "Unbricked" emuNAND 9.2 directly by using hardmod method still didn't work either

Could my XORpad I extracted be a bad dump? File size for both is 1,106,247,680 bytes

I will tried again if I got the time. Please let me know if there is any steps I missed out or didn't do.

For step 9, I would assume you decrypted/encrypted that data with the right keys/xorpad. Nand data is per console encrypted.

Envoyé de mon SM-G935F en utilisant Tapatalk

d0k3 · May 1, 2016

Ichigo1000 said:
How did you extract an emunand backup from the sd card? Did you use another 3ds to dump it?

There are other tools to do that (Multi EmuNAND Creator, for example), and with a little bit of knowledge you can even use dd for that. Or a standard imaging tool.

slslasher said:
Still not working for me. These are the steps I took.

1) Extracted slot 0x05 (nand.fat16.xorpad) and slot 0x04 (nand.fat16.0x4.xorpad) XORpads
2) Upgrade to v4.5 using a cartridge (Sky3ds)
3) Used gateway to make a 4.5 emuNAND (Made a backup of it using 3ds-multinand so I can flash it back to sysNAND)
4) Using SysUpdater and a N3DS FW 9.2 update pack and updated the emuNAND
5) emuNAND is N3DS FW 9.2 but bricked now
6) Extracted bricked emuNAND 9.2 using 3ds-multinand
7) To unbrick, dumped my NAND, then dumped my CTRNAND from that with 3DSFAT16 tool using the slot 0x04 XORpad
8) Injected the CTRNAND back into the NAND dump using the slot 0x05 XORpad
9) Replace the first 512 byte of NAND dump with the first 512 byte from another working N3DS NAND dump FW 9.2 (I got an extra N3DS for this)
10) Injected back my "Unbricked" emuNAND 9.2 using 3ds-multinand back to micro sd
11) Tried to run emuNAND but black screen
12) Flash back to 2.1 and restore sysnand using OTPhelper to "Unbricked" emuNAND 9.2 but still black screen
13) Tried flashing the "Unbricked" emuNAND 9.2 directly by using hardmod method still didn't work either

Could my XORpad I extracted be a bad dump? File size for both is 1,106,247,680 bytes

I will tried again if I got the time. Please let me know if there is any steps I missed out or didn't do.

Okay... we'll try it differently then, just one remark: Flashing a NAND backup via OTPHelper and flashing it via the hardmod is (almost) the same. OTPHelper only has some extra safety. If OTPHelper allowed you to flash it, you should have done everything right, while the hardmod (ofc) doesn't check any additional stuff.

Now, see this special build here:
https://up1.ca/#rsWBQLswqYxG2QT3gw7j9Q

This one automates steps 6.) to 10.) in the same way a FW 2.1 EmuNAND is unbricked. Now, updates can go wrong. One first thing that you could try is to get the FIRM90.bin from somewhere (no help from me for that, but it is the same as is used in the a9lh installation process), pad that to 4MB, then inject it into your 9.x EmuNANDs FIRM0 & FIRM1 (after doing the other steps). For the FIRM90 SHA-256, see here: https://github.com/delebile/arm9loaderhax

If it still does not work, I know, it would be a pain to do, but one way to make sure it did not go wrong would be to check the SHA-256s of all updated titles or compare them in a different way (WinMerge, maybe?) with the files from the update pack. A dumped CTRNAND can be mounted on PC via OSFmount.

Additional info: HxD can check SHA-256 and pad file to a specific length, and so can many other tools.

EDIT: Just to make sure, the order in which you should try this:

Use the new 9.x unbricker instead of the manual method, test EmuNAND, flash to SysNAND
In addition to 1., inject the FIRM90.bin to FIRM0 & FIRM1, then try again
In addition to 2. and 1., check the files manually (I hope you don't have to do this)

EDIT2: Also make sure your update pack is the correct region.

EDIT3: ... and use OTPHelpers NAND validator to perform a basic check of your SysNAND / EmuNAND between steps.

slslasher · May 1, 2016

d0k3 said:
There are other tools to do that (Multi EmuNAND Creator, for example), and with a little bit of knowledge you can even use dd for that. Or a standard imaging tool.

Okay... we'll try it differently then, just one remark: Flashing a NAND backup via OTPHelper and flashing it via the hardmod is (almost) the same. OTPHelper only has some extra safety. If OTPHelper allowed you to flash it, you should have done everything right, while the hardmod (ofc) doesn't check any additional stuff.

Now, see this special build here:
https://up1.ca/#rsWBQLswqYxG2QT3gw7j9Q

This one automates steps 6.) to 10.) in the same way a FW 2.1 EmuNAND is unbricked. Now, updates can go wrong. One first thing that you could try is to get the FIRM90.bin from somewhere (no help from me for that, but it is the same as is used in the a9lh installation process), pad that to 4MB, then inject it into your 9.x EmuNANDs FIRM0 & FIRM1 (after doing the other steps). For the FIRM90 SHA-256, see here: https://github.com/delebile/arm9loaderhax

If it still does not work, I know, it would be a pain to do, but one way to make sure it did not go wrong would be to check the SHA-256s of all updated titles or compare them in a different way (WinMerge, maybe?) with the files from the update pack. A dumped CTRNAND can be mounted on PC via OSFmount.

Additional info: HxD can check SHA-256 and pad file to a specific length, and so can many other tools.

EDIT: Just to make sure, the order in which you should try this:

Use the new 9.x unbricker instead of the manual method, test EmuNAND, flash to SysNAND

In addition to 1., inject the FIRM90.bin to FIRM0 & FIRM1, then try again

In addition to 2. and 1., check the files manually (I hope you don't have to do this)

EDIT2: Also make sure your update pack is the correct region.

EDIT3: ... and use OTPHelpers NAND validator to perform a basic check of your SysNAND / EmuNAND between steps.

Ok so I do not need to extract the xorpads n put it at root right? The special build will do everything for me.

So I just have to update emunand to 9.2, use the special build otphelper to unbrick and try to boot into emunand. If it fails inject the firm90.bin into firm0 and firm1 and try again.

Is there anyway I can boot into otphelper with a 4.5 fw rather 2.1? Flashing back usin a hardmod is really very slow. I think I bricked my n3ds more than 10 times while trying out all sort of solutions.

d0k3 · May 1, 2016

slslasher said:
Ok so I do not need to extract the xorpads n put it at root right? The special build will do everything for me.

So I just have to update emunand to 9.2, use the special build otphelper to unbrick and try to boot into emunand. If it fails inject the firm90.bin into firm0 and firm1 and try again.

Is there anyway I can boot into otphelper with a 4.5 fw rather 2.1? Flashing back usin a hardmod is really very slow. I think I bricked my n3ds more than 10 times while trying out all sort of solutions.

No XORpads, meaning you can skip that step as well.

Just use the Launcher.dat and the GW website (go Gateway something, see D9 readme) or CakeHax OTPHelper.dat (again, D9 readme) from 4.5. I wouldn't view a non booting EmuNAND as a given for it not working on SysNAND, especially since there are some things strange with how GW implements things, so you will have to try. It is better if you let OTPHelper handle all the NAND dumping / restore for you anyways. And, as you have gone through that. make sure you at least have that OTP.bin.

EDIT: Considering this, MSET may be the better entrypoint for you on 4.5. You should take a look into the D9 readme, that describes all possible entrypoints (OTPHelper, too).

The Real Jdbye · May 1, 2016

mathieulh said:
The keyslot used to decrypt/encrypt CTRNAND changed from 0x04 on o3ds to 0x05 on n3ds, when you downgraded to 2.1.0 which uses an o3ds firm, you re-encrypted your CTRNAND using the 0x04 keyslot, but using a card or system settings to update your console will write a n3ds FIRM (after all, your console is a n3ds) which needs CTRNAND to be encrypted with keyslot 0x05, because it's not encrypted with the right key, it will fail to boot.

That's true, but that's not the real reason though. The keys used by arm9loader to decrypt the FIRM binary are changed to bogus keys due to how arm9loaderhax works and after updating it leaves arm9loader unable to decrypt the real firm binary. I believe as long as the NAND header is the o3DS one it will use the 0x04 keyslot to decrypt but it doesn't matter because it would brick either way.

slslasher · May 1, 2016

d0k3 said:
No XORpads, meaning you can skip that step as well.

Just use the Launcher.dat and the GW website (go Gateway something, see D9 readme) or CakeHax OTPHelper.dat (again, D9 readme) from 4.5. I wouldn't view a non booting EmuNAND as a given for it not working on SysNAND, especially since there are some things strange with how GW implements things, so you will have to try. It is better if you let OTPHelper handle all the NAND dumping / restore for you anyways. And, as you have gone through that. make sure you at least have that OTP.bin.

EDIT: Considering this, MSET may be the better entrypoint for you on 4.5. You should take a look into the D9 readme, that describes all possible entrypoints (OTPHelper, too).

I am currently using the gateway entrypoint now using the browser. The unbrick 9.x and validate nand option. It just hang at the NAND CID: (Many letters n numbers) screen. No % running at the bottom right. Which means its not working? What do you mean by pad it to 4mb? Using hxd add 00000 behind till it hits 4mb?

d0k3 · May 1, 2016

slslasher said:
I am currently using the gateway entrypoint now using the browser. The unbrick 9.x and validate nand option. It just hang at the NAND CID: (Many letters n numbers) screen. No % running at the bottom right. Which means its not working? What do you mean by pad it to 4mb? Using hxd add 00000 behind till it hits 4mb?

Yup, add zeroes till it is 4MB. And, better use the CakeHax entrypoint then.

EDIT: Or, try this test build: https://up1.ca/#lDbq--0Ang0uOQQoLCuFjw

slslasher · May 1, 2016

d0k3 said:
Yup, add zeroes till it is 4MB. And, better use the CakeHax entrypoint then.

EDIT: Or, try this test build: https://up1.ca/#lDbq--0Ang0uOQQoLCuFjw

Ok shall use this, currently I am flashing back 2.1 because I tried using your latest OTPhelper using launcher.dat and it cannot verify the sysnand too. I already made a emunand 9.2 backup so I am gonna test that.

The 4mb which means 4194304 bytes? I used a converter. Cant wait to test the otphelper in 2.1

d0k3 · May 1, 2016

1mb = 1024 * 1024
And don't worry, nothing can go wrong if you get something wrong. Your situation can't get worse at this point, too.

3DS Homebrew Legend

Well-Known Member

3DS Homebrew Legend

Well-Known Member

3DS Homebrew Legend

Well-Known Member

3DS Homebrew Legend

Well-Known Member

Well-Known Member

Searching for the air to breathe~

Well-Known Member

Well-Known Member

3DS Homebrew Legend

Well-Known Member

3DS Homebrew Legend

*is birb*

Well-Known Member

3DS Homebrew Legend

Well-Known Member

3DS Homebrew Legend

Similar threads

Popular threads in this forum

is birb