Restore ProdInfos backed up with Incognito

[ZeCroque]

Hi,
I have a Switch on which I removed prodinfos after backing them up with Incognito_RCM. I still have the backup but can't find any version of Incognito nowhere that works for my current HOS version (15.0.1).
I tried to restore it with NxNandManager but it gives me the error "Can't backup a decrypted file to an encrypted location". I don't know how I can encrypt those files...
I also have a full nand backup I've done just before doing any homebrew with my console and thus it must have the keys in it. Infortunately I think I can't restore this backup since I burnt eFuses by disabling the No-GC patch.
How can I do to restore my sysnand back to normal ?
Thanks in advance,
Lucyf3r

 

[Hayato213]

You don't have any backup of the prodinfo that incognito made or any NAND backup prior to blanking your serial number?

 

[ZeCroque]

No, I do have both. Sorry if I've been unclear but it's stated in my OP.

 

[binkinator]

if you are on Erista/V1 you can try this https://github.com/mistervampi/Incognito_RCM





noGC only impacts your GameCard. Check fuses in Hakate to make sure.

Even if you temporarily downgrade to an older FW version you will be able to boot it w/ Hekate and ignore fuses. Based on your recollection, restoring to a known good backup will get your keys back (even if your game card is disabled).

If you have never been Online with this Switch, you will then be able to use the Nintendo servers to update your FW to latest.

If you are unsure you can stay offline and simply use Daybreak.nro to update using firmware downloaded from Darthsternie firmware that yiu can look for Online w/ your PC.

https://rentry.org/UpgradeDowngrade

 

[ZeCroque]

Thanks a lot for the modified Incognito_RCM it dit the work !

About the eFuses discussion, I checked in Hekate and there is the following line :

Burnt Fuses (ODM 7/6): 17 - 0 (HOS: Unknown)

Is there any way I can verify my old Nand backup won't brick my Switch if I restore it ? I'm unsure but I think my HOS version was 6.X at the time.
I didn't got it with the NoGC patch? My Ring Fit Adventure Gamecard got updated ? What is this update doing to the game card ?

 

[binkinator]

Thanks a lot for the modified Incognito_RCM it dit the work !

Sweet!

About the eFuses discussion, I checked in Hekate and there is the following line :

here is a good article on fuse levels. Read the entire thing if you want to know how it all works. They cannot be undone no matter what you do.

Fuses — Hekate bypasses the anti-downgrade fuse process but you still might be curious how many fuses are expected to burn for each FW version

Is there any way I can verify my old Nand backup won't brick my Switch if I restore it ? I'm unsure but I think my HOS version was 6.X at the time.

Unless there is something wrong with your backup, you won’t brick your switch due upgrading or down grading your Switch w/ a backup. Hekate will allow you to bypass the anti-downgrade features altogether.

I didn't got it with the NoGC patch?
My Ring Fit Adventure Gamecard got updated ? What is this update doing to the game card ?

The nogc patch is a completely different beast. Certain levels of firmware contain additional firmware for the game card system. If you’re running newer firmware the code is in there to upgrade your game cart reader. There’s nothing you can do about that being on your system. What you can do is enable nogc options in Hekate and /atmosphere/config/stratosphere.ini. All these do is disable your game card reader so they Switch will skip any upgrades. Here is a chart with the versions of firmware that will try to upgrade to the next game card firmware:

https://gbatemp.net/blogs/fuses-gc-fw-key-versions.19175/

you won‘t have to worry about these because you can turn off (disable) the game card using nogc settings.

bottom line: thanks to Hekate and nogc you don’t have to worry about the entire fuse system as they can help you completely get around any fuse or firmware issues.

 

[BigOnYa]

Sorry, posted to wrong thread.

 

[binkinator]

Sorry, posted to wrong thread.

There are 32 fuses, so we’re about 1/2 way there.

 

[ZeCroque]

Thanks for taking the time to answer.

I always used ChoixDuJour and then Daybreak to upgrade my firmware and I thought they were preventing my fuses to be burnt but I see that's not the case as I've burnt the fuse count expected for HOS 15. Maybe Daybreak is burning the fuses but not ChoixDuJour because I'm pretty sure I read ChoixDuJour was preventing fuses to be burnt back in the days.

When I was speaking about restoring the nand backup without bricking, I meant restoring to vanilla state. If I boot without RCM the console will refuse to boot if it detects the wrong number of fuse, am I wrong ?

And eventually for NoGC, why is it applied by default with Hekate ? Since it has nothing to do with eFuses, why is it important to keep the gamecard firmware from being updated? Is it to make sure you will be able to run gamecards on all firmware versions ? Or maybe the gamecard firmware isn't part of emuMMC and Hekate tries to prevent the emuHOS to impact the real console ?

 

[Hayato213]

Thanks for taking the time to answer.

I always used ChoixDuJour and then Daybreak to upgrade my firmware and I thought they were preventing my fuses to be burnt but I see that's not the case as I've burnt the fuse count expected for HOS 15. Maybe Daybreak is burning the fuses but not ChoixDuJour because I'm pretty sure I read ChoixDuJour was preventing fuses to be burnt back in the days.

When I was speaking about restoring the nand backup without bricking, I meant restoring to vanilla state. If I boot without RCM the console will refuse to boot if it detects the wrong number of fuse, am I wrong ?

And eventually for NoGC, why is it applied by default with Hekate ? Since it has nothing to do with eFuses, why is it important to keep the gamecard firmware from being updated? Is it to make sure you will be able to run gamecards on all firmware versions ? Or maybe the gamecard firmware isn't part of emuMMC and Hekate tries to prevent the emuHOS to impact the real console ?

It won't boot because your firmware and fuses count doesn't match, like if you have a firmware 6.2.0 firmware and 17 burnt fuses it won't boot. It is nice to have lower fuse count and being on higher firmware if you have older NAND backup.

 

[kidkat210]

Thanks for taking the time to answer.

I always used ChoixDuJour and then Daybreak to upgrade my firmware and I thought they were preventing my fuses to be burnt but I see that's not the case as I've burnt the fuse count expected for HOS 15. Maybe Daybreak is burning the fuses but not ChoixDuJour because I'm pretty sure I read ChoixDuJour was preventing fuses to be burnt back in the days.

When I was speaking about restoring the nand backup without bricking, I meant restoring to vanilla state. If I boot without RCM the console will refuse to boot if it detects the wrong number of fuse, am I wrong ?

And eventually for NoGC, why is it applied by default with Hekate ? Since it has nothing to do with eFuses, why is it important to keep the gamecard firmware from being updated? Is it to make sure you will be able to run gamecards on all firmware versions ? Or maybe the gamecard firmware isn't part of emuMMC and Hekate tries to prevent the emuHOS to impact the real console ?

Daybreak and choi neither burn nor prevent efuse burning, what burns efuses is booting stock after a firmware update. It burns the efuses during the reboot process. What prevents efuse burning is autorcm (this is probably where you may have thought choi prevented efuse buring, since choi gives you the option to enable autorcm) since having autorcm enabled, you're always gonna boot to hekate, directly into cfw, ect. Which then skips the efuse check.

You are correct bout the mismatch efuse check. If you downgrade sysnand, then try to boot stock. The switch will panic and refuse to boot. You would have to go through rcm to get around it.

The only reason I know of (if someone else has more info on this I'm all ears) of why nogc is important, is because it acts the same way as autorcm. If the gamecard reader updates but you've saved your efuses, then downgrade firmware. The game card reader would no longer work untill your update to a firmware that supports that game card readers "firmware" (im calling it firmware for simplicity sake). So by having nogc enabled, it prevents the game card reader from updating when you update firmwares. I could be wrong bout this but I believe that no matter wether your in emunand or sysnand. if nogc isn't enabled, you'll burn the card readers "efuses"

 

[binkinator]

Daybreak and choi neither burn nor prevent efuse burning, what burns efuses is booting stock after a firmware update. It burns the efuses during the reboot process. What prevents efuse burning is autorcm (this is probably where you may have thought choi prevented efuse buring, since choi gives you the option to enable autorcm) since having autorcm enabled, you're always gonna boot to hekate, directly into cfw, ect. Which then skips the efuse check.

You are correct bout the mismatch efuse check. If you downgrade sysnand, then try to boot stock. The switch will panic and refuse to boot. You would have to go through rcm to get around it.

The only reason I know of (if someone else has more info on this I'm all ears) of why nogc is important, is because it acts the same way as autorcm. If the gamecard reader updates but you've saved your efuses, then downgrade firmware. The game card reader would no longer work untill your update to a firmware that supports that game card readers "firmware" (im calling it firmware for simplicity sake). So by having nogc enabled, it prevents the game card reader from updating when you update firmwares. I could be wrong bout this but I believe that no matter wether your in emunand or sysnand. if nogc isn't enabled, you'll burn the card readers "efuses"

You nailed it. Saved me some typing. If you ever want to downgrade your firmware (if there were a cold boothax released for example that uses 4.0.0) in the future, you’ll be glad your GC firmware will work at the lower versions. if you already have all the requiremente, there are no scenarios where you have to use a physical game cart so might as well leave it permanently off.