title
No, the toolkit only creates a dump. You still need to use Hekate to restore. A dump made with the toolkit can be restored with Hekate though
How can I do this? I made a NAND backup and it made a bunch of .bin files, of 2 or 3GB size I can't remember since I'm not in my laptop right now.
Alright thanks!! On a side note, I did make the backup after getting the console, connecting it to internet and updating to the last firmware. Then I started launching CFW. Does that mean I I have more risk of getting banned if I connect the console to wifi again?you need to join the small files with the joiner script, then restore with hekate, sorry I'm not at home so I can't link the script
Alright thanks!! On a side note, I did make the backup after getting the console, connecting it to internet and updating to the last firmware. Then I started launching CFW. Does that mean I I have more risk of getting banned if I connect the console to wifi again?
Yeah, I even downloaded some demos and free games. Then I started looking up for hack stuff, THEN I made the NAND backup, and THEN I launched CFW. Still, I haven't connected my console to internet since before I made the backup (deleted all wifi networks and switched to airplane, then backed up). Always airplane mode. Btw, how do I check my burnt fuses? In what cases are burnt fuses risky? (sorry all these questions, I'm new to this).If after the update, you opened OFW even once, the fuses are burnt. So you'd have to inject a payload to even use it, and you'll get banned.
The Nintendo Switch's bootloader aka the part that controls the boot-up process for the console checks the number of fuses burnt and compares it to the current firmware. If they do not match, it will either prevent the console from turning on or it will burn them to compensate. While both Hekate and SX OS V1.2+ not only bypass the fuse check entirely as substitute bootloaders but also prevent fuses from being burnt, this is not enough protection against burning fuses during system updates. The reason for this is because when you update the Switch normally, it reboots the console so the Switch has a chance to burn fuses. Even if you initially boot the console with either Hekate or SX OS V1.2+, when you update normally within the Switch, the Switch's bootloader will take over when the console is rebooting after the update. Therefore, ... AutoRCM is a means to prevent you from accidentally booting the Switch normally which will burn fuses,... It should also be worth noting that updating removes any and all forms of AutoRCM, which must be reactivated manually or VIA whatever tool being used.
In theory, you can update ... using the official way while not burning fuses IF you can stop the console from turning back on after it updates successfully. This is a very user-oriented window that if you miss will permanently burn the fuses and is a risk you can take should you acknowledge it. Another problem is that once you do manage to turn off the console with the correct timing, you have to ensure from that moment onwards that you will boot your console from RCM only because it will burn the fuses if you turn it on normally. This means you must have some means of inducing RCM with 100% confidence or you risk burning your fuses. AutoRCM cannot save you in this case if it hasn't been reinstalled after a update.
OK, well it sounds like you updated then made a NAND backup. So your at whatever FW your at. I would advise using autoRCM now, if you aren't. This is a good habit, and will prevent any burnt fuses in the future.
So since you disabled all internet since the backup, in theory you "should" be ok upon a restore of the NAND.
About the fuses, if you want to check them, I believe Hakate payload has fuse-checking as well as the briccmii payload.
Here is a quote from another thread as its put rather well, in regards to fuses and updating, I edited some parts about the guide it was referring to and put any changes in italic...
OK the point of the fuses is to tell what version of firmware you are on. After they burn you cannot go back.
For example:
I officially updated to FW version 3.0.0, it will have 3 fuses burnt.
Then I officially update to FW version 6.1.0, it will have 7 fuses burnt.
If I attempt to restore back to 3.0.0 and try to boot my switch normally I will get a black screen since I have 7 fuses burnt, and it was looking for 3. So the "risk" is later on I cannot go back to my older firmware (without using a payload to circumvent the fuse check, which defeats the goal of having "virgin" backup).
Now in your instance you updated, booted into OFW (which burnt the fuses), then made a backup and started using CFW. So your fuses are burnt in accordance to whatever FW you are on.
It is, however, never too late to read up about AutoRCM and doing any future updates using ChoiDujourNX which is a tool for applying updates safely and keeping AutoRCM enabled.