Hacking SWITCH NOOB PARADISE - Ask questions here

[dug]

Thank you for the explanation!
I understand now, we need something like for 3DS to bypass the ticket check. The WII U was different in that.
I think I will wait for that kind of exploit to be released, it's a little too sensitive for now.
Thanks

 

[ChokingVictim87]

On my switches home screen,I can see all the game images,however one is a blank square that constantly has a loading circle-what is this and how do I remove it?

 

[Xana]

It's been a while so I don't remember the exact details, but I think that's because the Wii U didn't really care what you installed on it, be it a game or a homebrew app. So long as it had a ticket and could function, that was all the system cared about. Several people could use the same ticket and there would be absolutely no penalties: even the eShop didn't care (DLC was another story though since that actually required a unique ticket, so you needed some exploit to ignore the system's checks).

All of the Switch's exploits rely on loading alternative bootloaders since we can't really write anything to the system partition that would render its protections useless (yet). Same thing with the 3DS: unless it was a legit CIA, you need to find some exploit to bypass them. To be honest, I've never really been sure why the Wii U had this trait but I'm not complaining .

IIRC, the Wii U's ticket format didn't include whether the ticket was for a disc or a digital title as part of its signature verification. Therefore, you could just take a digital ticket, change it to a disc ticket, and voila, it works on any system. You just needed CFW to run the code necessary to install it.

 

[A Generic User]

IIRC, the Wii U's ticket format didn't include whether the ticket was for a disc or a digital title as part of its signature verification. Therefore, you could just take a digital ticket, change it to a disc ticket, and voila, it works on any system. You just needed CFW to run the code necessary to install it.

Right, I remember back when installing backups first took off that the tickets had to be changed after being dumped from the discs (or you got them from..........alternative places xD). I didn't realize that was what was changed (all I remember was that it prevented the system from crashing when you tried to run it, or it wouldn't install to begin with).

But man lmao, the fact that they let something like that slip up....makes their step up in security with the Switch seem like something obvious .

 

[Zozolight]

What does keys mean? Like i understand that's what is holding up the CFW release but idk why i have to BYOK if i want to work. Where are my keys? lol i lost them again hahahahah


but seriously what are the keys in context to having your of CFW

thanks!

 

[Draxzelex]

On my switches home screen,I can see all the game images,however one is a blank square that constantly has a loading circle-what is this and how do I remove it?

Either try pressing + on it to delete it from the Home Menu or from Data Management under System Settings. Its size should be 0.0 MB

What does keys mean? Like i understand that's what is holding up the CFW release but idk why i have to BYOK if i want to work. Where are my keys? lol i lost them again hahahahah


but seriously what are the keys in context to having your of CFW

thanks!

There are some technical terms here to be aware of to fully comprehend what is going on but I'll try to dumb it down as much as possible.

CFW is basically patching OFW to remove certain restrictions and allow us to do whatever we want with the console. However everything on the console is encrypted with certain keys. Now before 6.2, all of these keys were in the NAND and since we had complete access to the NAND via Fusee Gelee, the current exploit (aka sending payloads via USB while its in RCM), Nintendo cannot hide these keys for very long.

Now as of 6.2, they started hiding the keys in another place known as TSEC. This is a completely separate chip from the NAND meaning Fusee Gelee is useless against it; it might be easier to think of it as another console within the console. This means in order to get the key from TSEC, we need a TSEC exploit. We sort of used one on 6.2 which Nintendo immediately patched as well as implemented another new key only found in TSEC via firmware 7.0. Of course, hackers were able to discover this key but this presents a dilemma. Releasing the key is not only illegal but puts at risk the people who dumped it as very few people would be capable of finding it in the first place so it would be easy for Nintendo to potentially track down whoever dumped it. On the other hand, they could release the exploit to dump the key at the risk of telling Nintendo exactly what to patch in a future firmware update leaving the scene stuck in the same problem it is currently in. The best possible scenario is finding a TSEC exploit that Nintendo cannot patch similar to Fusee Gelee but that's easier said than done.

This is where the B.Y.O.K. comes into play. If you have the necessary keys, you can decrypt the OFW and boot CFW. However for reasons just explained, the general public cannot do this. A likely reason why B.Y.O.K. support was implemented is for those who are successful to dump/find the keys can help in finding a way around the above situation; a situation where sharing the keys and releasing the exploit to dump the keys are not viable in the long run. The B.Y.O.K. is not useful in any way, shape, or form for the general public.

 

[werneck14]

I have a 6.0.1 NAND Backup. Currently I'm on OFW 7.0, is it safe to restore my 6.0.1 NAND considering the burning fuses and etc? Wha should I use do restore? Hekate? I was reading it doesn't work on OFW 7.0.

 

[Draxzelex]

I have a 6.0.1 NAND Backup. Currently I'm on OFW 7.0, is it safe to restore my 6.0.1 NAND considering the burning fuses and etc? Wha should I use do restore? Hekate? I was reading it doesn't work on OFW 7.0.

No CFW supports firmware 7.0. You will need to restore your complete NAND backup meaning the eMMC raw GPP or rawnand.bin as well as boot0/boot1.

 

[werneck14]

No CFW supports firmware 7.0. You will need to restore your complete NAND backup meaning the eMMC raw GPP or rawnand.bin as well as boot0/boot1.

Yeah I understand that. But can I just restore my 6.0.1 Backup using Hekate with no problem? I have 9 fuses burnt and the NAND backup is from OFW 6.0.1 not CFW, is there anything i should do before restoring? And is AutoRCM still dangerous? Like having the switch battery drained while on rcm mode and bricking it.

 

[Draxzelex]

Yeah I understand that. But can I just restore my 6.0.1 Backup using Hekate with no problem? I have 9 fuses burnt and the NAND backup is from OFW 6.0.1 not CFW, is there anything i should do before restoring? And is AutoRCM still dangerous? Like having the switch battery drained while on rcm mode and bricking it.

Several things:

1. Restoring the NAND backup is in fact the easiest way to downgrade. The alternative method involves rebuilding your NAND with ChoiDujour and its a rather lengthy (and slightly dangerous) process
2. All bootloaders aka payloads that boot CFW bypass the fuse check so you can boot any firmware with the current exploit meaning you will be fine as long you are booting through RCM which is easiest with AutoRCM. Speaking of which...
3. AutoRCM was and never will be dangerous. The only thing dangerous are uninformed users (just look at everyone updating to firmware 7.0, not particular talking about yourself but in general). All AutoRCM does is "brick" your console (reversibly, mind you) and causes the console to reboot into RCM when you turn it off from Horizon. Nobody charges their console or even leaves it in RCM for extended periods of time, AutoRCM or otherwise.

 

[werneck14]

Several things:

1. Restoring the NAND backup is in fact the easiest way to downgrade. The alternative method involves rebuilding your NAND with ChoiDujour and its a rather lengthy (and slightly dangerous) process
2. All bootloaders aka payloads that boot CFW bypass the fuse check so you can boot any firmware with the current exploit meaning you will be fine as long you are booting through RCM which is easiest with AutoRCM. Speaking of which...
3. AutoRCM was and never will be dangerous. The only thing dangerous are uninformed users (just look at everyone updating to firmware 7.0, not particular talking about yourself but in general). All AutoRCM does is "brick" your console (reversibly, mind you) and causes the console to reboot into RCM when you turn it off from Horizon. Nobody charges their console or even leaves it in RCM for extended periods of time, AutoRCM or otherwise.

Thanks for the tips! One more thing. I just made a backup of OFW 7.0, if I switch back from 6.0.1 to 7.0 restoring the OFW 7.0 NAND will it pass the fuse check and boot normally without the need of injecting a payload?

 

[Draxzelex]

Thanks for the tips! One more thing. I just made a backup of OFW 7.0, if I switch back from 6.0.1 to 7.0 restoring the OFW 7.0 NAND will it pass the fuse check and boot normally without the need of injecting a payload?

Your console is designed to normally boot firmware that matches the fuse count. If you don't know your fuse count, you can check with either briccmii or Hekate under Fuse Info then compare the fuse count to the expected firmwares here.

 

[sean222]

My first noob question, Google searches have failed. Up and running fully on SX OS Pro. Launching .nsp installed games are fine. Once I boot Hekate and load up Reinx or Atmosphere (verified running ok, HB menu ok), the exact same .nsp game goes straight to a black screen after launching, any ideas what this means?

Happens with both Reinx and Atmosphere. Atmosphere has all the patches downloaded via Kosmos. I tried SDFiles site too.

 

[Adran_Marit]

My first noob question, Google searches have failed. Up and running fully on SX OS Pro. Launching .nsp installed games are fine. Once I boot Hekate and load up Reinx or Atmosphere (verified running ok, HB menu ok), the exact same .nsp game goes straight to a black screen after launching, any ideas what this means?

Happens with both Reinx and Atmosphere. Atmosphere has all the patches downloaded via Kosmos. I tried SDFiles site too.

My first thought is emunand?

 

[sean222]

My first thought is emunand?

Never used emunand at all.
On 6.2 now. I'm wondering if it's because I installed all my .nsps through the SX OS installer... That doesn't really make sense though...I think.

 

[Adran_Marit]

Never used emunand at all.
On 6.2 now. I'm wondering if it's because I installed all my .nsps through the SX OS installer... That doesn't really make sense though...I think.

i dunno, I dont use sx, so it was just a thought, maybe. but atmo and rei both black screen them? try reinstalling?

 

[werneck14]

Your console is designed to normally boot firmware that matches the fuse count. If you don't know your fuse count, you can check with either briccmii or Hekate under Fuse Info then compare the fuse count to the expected firmwares here.

Restored the nand and everything works fine. My NAND Backup actually was version 5.1.0. Is there any reason/advantage to update to 6.2.0?

 

[Adran_Marit]

Restored the nand and everything works fine. My NAND Backup actually was version 5.1.0. Is there any reason/advantage to update to 6.2.0?

some games require it

 

[mugendc4]

Restored the nand and everything works fine. My NAND Backup actually was version 5.1.0. Is there any reason/advantage to update to 6.2.0?

also to add above, some game updates and DLC will require to be on newer firmware. So if you want the latest roster of SSBU, you will need to be on 6.2.0

 

[teelo]

Is there a program for windows I can use to extract a save file from a NAND dump (including boot and user and whatnot) then inject it into another NAND dump??