Hacking Godmode9 restore warning: "NCSD Differs between image and local"

dearjym · Jan 16, 2019

2 years ago I bricked my N3DSXL when my device entered sleep mode while I was on step 5 of Plailect's guide. After trying everything I could find, and pissing people off with my questions, I put it away. I recently got an NTRBOOT flashcart, and I am now able to run godmode9.

I have all of my files and backup's from Plailect's guide. Every step of the way, I made a folder containing everything for that step. I kept notes as well. From what I've been able to understand, I should be able to restore my system with my sysnand backup using godmode9. But I'm getting red screen warnings about Lvl3 write permissions because my:

"NCSD differs between image and local, elevated write permissions required. Proceed at your own risk"

I don't know what that means, nor do I know if there are dangers there (other than the obvious one) that I am unaware of. Besides the obvious implications of the warning, I have no idea if there are less obvious consequences of going forward with this restore. I want to fix the device, not make it worse.

There many ways to do the same thing it seems, and to make things more confusing for me, the process is constantly changing due to new discoveries, new software, new coders... which makes everything before them obsolete. For example, Plailect's old guide, the one I was using 2 and half years ago. The are several different kinds of bricks that can occur, so when someone is giving advice, it often difficult to tell if it applies to my situation, or not. So, after reading tutorial after tutorial, and reading so many threads on the forum, I'm just not sure what's right, what's responsible, what's obsolete. To make matters worse, everyone's problems aren't always identical, though the solutions can often be.

What is NCSD? What is the reason I'm getting this warning, or why do the NCSD's differ? Is that normal? There is little online dealing with this (that I could find). So, I'm finally giving in and asking for help.

TurdPooCharger · Jan 16, 2019

NCSD is the header of *.3ds/*.cci roms and raw NAND format.

[3dbrew.org] NCSD

Searching the GodMode9 official thread and GitHub issues, some info was found at:

[Issue #166] Feature Request: Full CTRNAND transfer ala Decrypt9

TL;DR - Mismatching NCSD means there's a sighax difference between the 3DS system and NAND image.

Layman Explanation
It's a bad idea restoring a SysNAND image previously made in Gateway, RxTool, or arm9loaderhax custom firmware when your system now has boot9strap.

***

Try repairing the 3DS firmware with 11.5.0 CTRTransfer followed by Recovery Mode.

If that same warning appears when you attempt CTRTransfer, stop what you're doing and report back.

dearjym · Jan 16, 2019

Thank you for the explanation, I understand much better now. I will follow your advice and report back the outcome.

EDIT: Does this mean that my SysNAND backups created under arm9loaderhax were essentially rendered useless by using NTRBOOT?

EDIT #2:
I successfully completed CTRTransfer & CTRTransfer Ticket Copy, but upon rebooting the device (step #23), I get this error:

TurdPooCharger · Jan 16, 2019

dearjym said:
Thank you for the explanation, I understand much better now. I will follow your advice and report back the outcome.

EDIT: Does this mean that my SysNAND backups created under arm9loaderhax were essentially rendered useless by using NTRBOOT?

EDIT #2:
I successfully completed CTRTransfer & CTRTransfer Ticket Copy, but upon rebooting the device (step #23), I get this error:

View attachment 155292

Oh dang, you're the second person this week that has had this error.

Help Unbricking a New Nintendo 3DS

Go from the beginning in following the step-by-step guide found there in posts [9, 11, 13]; you can skip step 9 since you already tried CTRTransfer with GodMode9.
With the exception of step 9, you do not want to skip ahead for the other steps.

dearjym · Jan 17, 2019

I completed all of the steps up to the CTRTransfer with Decrypt9WIP (step #10). After running the transfer I get this error:

DocKlokMan · Jan 17, 2019

Just curious, was step 5 back then downgrading to 2.1.0 on your new 3DS?

TurdPooCharger · Jan 17, 2019

dearjym said:
I completed all of the steps up to the CTRTransfer with Decrypt9WIP (step #10). After running the transfer I get this error:
View attachment 155367

Errh, did you happen to have used the EUR CTRTransfer *.bin & *.sha image on a USA n3DSXL system? My mistake on step 10. If yours USA region, it was suppose to be:

New 3DS or 2DS - 11.5.0 - USA - CTRTransfer
sdmc:/files9/11.5.0-38U_ctrtransfer_n3ds.bin
sdmc:/files9/11.5.0-38U_ctrtransfer_n3ds.bin.sha

I've seen this failure before helping out someone trying to restore her JPN o3DS that was partially region changed to USA 3DS firmware.
CTRTransfer in Decrypt9WIP won't work if the SecureInfo_A/B at 0x100 offset has a mismatch in region value, or there is no SecureInfo_C to act as substitute. Sorry for that.

AnalogMan said:
Just curious, was step 5 back then downgrading to 2.1.0 on your new 3DS?

Oh wow, the creator of Lazarus3DS and ultraSuMoFramework. I don't believe I've seen your presence on GBAtemp last year, so hello there.

dearjym · Jan 17, 2019

The downgrade to 2.1.0 was Part #4, Section #2, Step #10.
Part #5 was the installation of arm9loaderhax.

DocKlokMan · Jan 17, 2019

dearjym said:
The downgrade to 2.1.0 was Part #4, Section #2, Step #10.
Part #5 was the installation of arm9loaderhax.

Great, so the error in your first post is expected. Since the new3DS never had a 2.1.0 firmware, one had to be Frankensteined together using bits of old 3DS FW and new 3DS FW. This is the cause of the NCSD mismatch. Your 3DS has an old 3DS NCSD installed due to the 2.1.0 downgrade. CTRNAND transfers don't correct this, which is also why it failed. If you actually have your NAND backup from prior to the 2.1.0 downgrade, restore that. Proceed passed the NCSD error. Restoring your NCSD is what will bring your 3DS back to working order.

dearjym · Jan 17, 2019

TurdPooCharger said:
Errh, did you happen to have used the EUR CTRTransfer *.bin & *.sha image on a USA n3DSXL system? My mistake on step 10. If yours USA region, it was suppose to be:

New 3DS or 2DS - 11.5.0 - USA - CTRTransfer

sdmc:/files9/11.5.0-38U_ctrtransfer_n3ds.bin

sdmc:/files9/11.5.0-38U_ctrtransfer_n3ds.bin.sha

I've seen this failure before helping out someone trying to restore her JPN o3DS that was partially region changed to USA 3DS firmware.
CTRTransfer in Decrypt9WIP won't work if the SecureInfo_A/B at 0x100 offset has a mismatch in region value, or there is no SecureInfo_C to act as substitute. Sorry for that.

Oh wow, the creator of Lazarus3DS and ultraSuMoFramework. I don't believe I've seen your presence on GBAtemp last year, so hello there.

My n3ds is USA, so I didn't use EUR.
system info:

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

AnalogMan said:
Great, so the error in your first post is expected. Since the new3DS never had a 2.1.0 firmware, one had to be Frankensteined together using bits of old 3DS FW and new 3DS FW. This is the cause of the NCSD mismatch. Your 3DS has an old 3DS NCSD installed due to the 2.1.0 downgrade. CTRNAND transfers don't correct this, which is also why it failed. If you actually have your NAND backup from prior to the 2.1.0 downgrade, restore that. Proceed passed the NCSD error. Restoring your NCSD is what will bring your 3DS back to working order.

Yes, I have all the backups from that guide, and SDCard contents from each part as well. I just want to confirm that Godmode9 should be used to restore the nand backup?

TurdPooCharger · Jan 17, 2019

dearjym said:
My n3ds is USA, so I didn't use EUR.
system info:

Yes, I have all the backups from that guide, and SDCard contents from each part as well. I just want to confirm that Godmode9 should be used to restore the nand backup?

Back up the currently broken SysNAND. If you have doubts in whether to restore your previously made NAND images in GodMode9 or Decrypt9WIP, you'll have that to fall back on. Try it in GodMode9 first with the SysNAND Restore (Safe).

dearjym · Jan 17, 2019

TurdPooCharger said:
Back up the currently broken SysNAND. If you have doubts in whether to restore your previously made NAND images in GodMode9 or Decrypt9WIP, you'll have that to fall back on. Try it in GodMode9 first with the SysNAND Restore (Safe).

Earlier I used Godmode9 and flashed the SysNAND I created before the 2.1.0 downgrade. It completed with no errors. The system booted for the first time since June, over 2 years ago. I'm still surprised that I had kept all the files and backups from that old guide in perfect order, and notes to remind me, just in-case THIS happened. It's showing that I'm on "Sys 9.2.0-20U". I'd like to add Homebrew & update. On my N2DS, I used my NTRBoot flashcart. If I use the same process to install CFW on this device will it be safe if I update afterwards through normal update?

Also, thanks to both you & AnalogMan for sharing your knowledge and experience. Most of us are tip-toeing thru these processes like it's broken glass, but you guys just run barefoot in the dark.

TurdPooCharger · Jan 17, 2019

dearjym said:
Earlier I used Godmode9 and flashed the SysNAND I created before the 2.1.0 downgrade. It completed with no errors. The system booted for the first time since June, over 2 years ago. I'm still surprised that I had kept all the files and backups from that old guide in perfect order, and notes to remind me, just in-case THIS happened. It's showing that I'm on "Sys 9.2.0-20U". I'd like to add Homebrew & update.

You should see this other person who also recently decided to fix his kid's n3DS that's been bricked for 2 years. Technically, his wife made him go do it. You're not alone.

black screen + no luma3ds and hourglass

Did you get your n3DSXL up and running again after restoring the SysNAND? Did it go without a hitch?

If you did, you follow the Finalizing Setup to complete the guide. Here's a starter kit if it helps with double checking and saving time collecting files.

dearjym said:
On my N2DS, I used my NTRBoot flashcart. If I use the same process to install CFW on this device will it be safe if I update afterwards through normal update?

A 3DS/2DS system that is perfectly working before being hacked with boot9strap CFW will continue to work after it's hacked.

If you have the latest Luma3DS v9.1, boot9strap v1.3, and GodMode9 v1.7.1 on both the SD card and CTRNAND,, updating the 3DS firmware will not soft brick the system nor will it remove/undo the custom firmware.

dearjym said:
Also, thanks to both you & AnalogMan for sharing your knowledge and experience. Most of us are tip-toeing thru these processes like it's broken glass, but you guys just run barefoot in the dark.

The thanks mostly goes to @AnalogMan. His greater expertise in what that NCSD mismatch really meant and what to do to fix is what saved the day. He's one of the early pioneers, if not THE one, who's researched worst case scenario 3DS softbricks and how to fix them.

To @AnalogMan, thank you for your audience and this lesson in what to expect with 2.1 downgrade frankenfirm.

dearjym · Jan 17, 2019

That's what's so daunting about the whole process. I found only 2 different cases that (superficially) mirrored mine, including errors, behavior, and screen text. Yet both of them had different solutions, and neither of those solutions worked for me.

Obviously there are hundreds of bricked systems out there, or more. Due to the sheer numbers, researching a solution for unbricking my own device really limited any confidence I had on possible success. But what kept me going is that almost all of them involved "symptoms" that didn't match my situation, they had black screens, blue screens or no screens at all. And, since none of those bricks were created the way I created mine, their solutions didn't work.

So when I found a few people that DID have a similar bricks, I thought I had found the solution. But it turns out, they caused their bricks differently than I did, it's just that, ultimately, we had the same "symptoms", but different illness.

For ex: https://gbatemp.net/threads/cant-ac...-ctrnand-and-cant-restore-nand-backup.481483/

Back when this happened, I remember being told that it may never be unbrickable. That is usually all the excuse I need to tear into something for fun, taking it apart and ultimately ruining it. Luckily, I put it away and waited. So again thanks, and definitely thank you to @AnalogMan.

Deleted-236924 · Jan 19, 2019

TurdPooCharger said:
Layman Explanation
It's a bad idea restoring a SysNAND image previously made in Gateway, RxTool, or arm9loaderhax custom firmware when your system now has boot9strap.

A nand backup is a nand backup. GM9 specifically leaves firm untouched when restoring from a backup.

TurdPooCharger · Jan 19, 2019

Ammako said:
A nand backup is a nand backup. GM9 specifically leaves firm untouched when restoring from a backup.

Can you clarify if this is the case for Restore SysNAND (Full)?

Edit - This option is available in the NANDManager.gm9 script.

Deleted-236924 · Jan 19, 2019

TurdPooCharger said:
Can you clarify if this is the case for SysNAND Restore (Full)?

I don't use those scripts. The only built-in GM9 nand restore is Safe, which leaves firm untouched. But yes, Full would overwrite firm (this is mentioned when the script is run.)

Full risks bricking if you restore an emunand that was updated through GW, or if your emunand had edits done to it that render it unbootable without cfw (GW used to write-protect emunand firm partitions, if you updated from an older FW version emunand to a newer one, firm partitions would not be getting updated, and this causes problems.)
Not all emunands will brick if flashed to sys, but they don't recommend doing it regardless, because you never know when the user had something going on with their emunand that actually renders the nand unbootable without cfw, so it's easier to just tell everyone not to do it and avoid potential problems.

Safe shouldn't brick if you have sighaxed firms (or a9lh but that's ancient), unless your nand backup is broken enough to the point where even cfw doesn't allow it to boot, but that can still be recovered even without a proper backup (though this is of course not desirable, but it is possible if needed.) If you're using ntrboot then there is a possibility that there could be problems caused by mismatched firms, but if you're restoring a nand backup through ntrboot there is no reason not to do a Full restore.

Aside from that, it really doesn't matter from where or how your nand backup was made if it's a clean sysnand backup. I still have my backup from 2015 that I made with GW Launcher and I've never needed anything else.

Actually, a backup on N3DS made at a time where a9lh was installed could, from my understanding, cause problems if Safe-restored to a system with B9S installed, because secret sector 0x96 in nand has to be fixed when upgrading from a9lh to B9S (or uninstalling a9lh in any way), but this doesn't matter on non-New systems as far as I can tell. Correct me if I'm wrong.
In any case, it should still be possible to manually fix secret sector after restoring the nand backup. As far as GW, rxtools, etc. is concerned though, if your sysnand was clean at the time of backup, it doesn't really matter what you used to make the backup.

Hacking Godmode9 restore warning: "NCSD Differs between image and local"

Member

Meh.

Member

Meh.

Member

Plugin Dev

Meh.

Member

Plugin Dev

Member

Meh.

Member

Meh.

Member

Deleted-236924

Guest

Meh.

Deleted-236924

Guest

Similar threads

Popular threads in this forum