Hacking SWITCH NOOB PARADISE - Ask questions here

[binkinator]

not installing but would could nintendo detect if i dumped the cartridge

Just dumping a cart? They can’t detect that. Especially if you’re offline and running NXDumptool (or whatever homebrew) on emunand.

 

[lasscat]

Just dumping a cart? They can’t detect that. Especially if you’re offline and running NXDumptool (or whatever homebrew) on emunand.

alright i dumped via sysnand cfw offline

 

[Gamemaster1379]

If my emuNAND were to corrupt, can I restore my dumped sysNAND to restore it? Or does it HAVE to be a dump OF the emuNAND?

If it must be an emuNAND, how do I make a proper dump of my emuNAND? How would I restore it?

 

[binkinator]

alright i dumped via sysnand cfw offline

I typically play it safer by only using emunand to make sure nothing hits the logs. We really don’t have ALL the fine details of how they run bans so everything we give to Ninty may be used against us.

 

[binkinator]

If my emuNAND were to corrupt, can I restore my dumped sysNAND to restore it? Or does it HAVE to be a dump OF the emuNAND?

If it must be an emuNAND, how do I make a proper dump of my emuNAND? How would I restore it?

You certainly can and should restore your corrupt emunand from a copy of Sysnand. It doesn’t have to be a dump of emunand. You will lose any data that you created on emunand since you took the last Sysnand snapshot. Only way around that would be frequent backups of your emunand.

You can do pretty much everything via NXNandManager and Emutool using your PC.

 

[Gamemaster1379]

You certainly can and should restore your corrupt emunand from a copy of Sysnand. It doesn’t have to be a dump of emunand. You will lose any data that you created on emunand since you took the last Sysnand snapshot. Only way around that would be frequent backups of your emunand.

You can do pretty much everything via NXNandManager and Emutool using your PC.

Cool. Good to know the sysNAND is a good start point. Makes sense I'd lose any differences since the restore point.

I managed to (unfortunately) corrupt my emuNAND on my 256 GB card. I was planning on migrating to a 512 GB anyway, so it gives me a good excuse to go and actually do it.

On the part of doing frequent emuNAND backups. Presumably I could restore backup and restore only select data partitions no?

That is to say, if I ever needed to do a full restore, I could first restore the sysNAND dump, then restore the select data partitions containing installed titles and saves after, no?

 

[regnad]

What does that mean to run from applet mode?

Isn’t using title override to go into HB Launcher going to be better than launching RA from a forwarder?

 

[binkinator]

Cool. Good to know the sysNAND is a good start point. Makes sense I'd lose any differences since the restore point.

I managed to (unfortunately) corrupt my emuNAND on my 256 GB card. I was planning on migrating to a 512 GB anyway, so it gives me a good excuse to go and actually do it.

On the part of doing frequent emuNAND backups. Presumably I could restore backup and restore only select data partitions no?

A lot of people don’t bother to make a single backup of their Sysnand. If yiu didn’t want to do everything yiu could do selected sections, yes. I honestly havent had the need to do anything but full restores (it’s only 32G to just do it all.)

That is to say, if I ever needed to do a full restore, I could first restore the sysNAND dump, then restore the select data partitions containing installed titles and saves after, no?

If it’s a full backup of your emunand you could completely restore the entire thing to last known good at any time. No need to go all the way back to Sysnand. My Sysnand is a different version so I treat it as a completely different machine with its own backup ancestory (and much fewer backups.)

 

[Gamemaster1379]

A lot of people don’t bother to make a single backup of their Sysnand. If yiu didn’t want to do everything yiu could do selected sections, yes. I honestly havent had the need to do anything but full restores (it’s only 32G to just do it all.)

If it’s a full backup of your emunand you could completely restore the entire thing to last known good at any time. No need to go all the way back to Sysnand. My Sysnand is a different version so I treat it as a completely different machine with its own backup ancestory (and much fewer backups.)

Makes sense. I appreciate the insight.

 

[binkinator]

What does that mean to run from applet mode?

Isn’t using title override to go into HB Launcher going to be better than launching RA from a forwarder?

Applet mode is a limited environment where resources are not pruned before launch. it’s good enough to run HB Menu and light homebrew apps that don’t need a lot of memory.

The converse is title override mode where as much resources are reclaimed before launching HB Menu giving your Home brew apps the most room for activities possible.

Forwarders make for a more seamless experience for launching games but is cosmetic. Title override is the preferred method to launch as far as I’m aware. It just requires extra clicks.

e: found the article where I read about the preference for title override, so if you believe those clowns , that’s going to be the best I can do.

 

[regnad]

Applet mode is a limited environment where resources are not pruned before launch. it’s good enough to run HB Menu and light homebrew apps that don’t need a lot of memory.

The converse is title override mode where as much resources are reclaimed before launching HB Menu giving your Home brew apps the most room for activities possible.

Forwarders make for a more seamless experience for launching games but is cosmetic. Title override is the preferred method to launch as far as I’m aware. It just requires extra clicks.

e: found the article where I read about the preference for title override, so if you believe those clowns , that’s going to be the best I can do.

Thank you!

So the earlier poster who said forwarders use the same method as HBL and it doesn’t matter which you use is wrong?

You should always use title override to launch HBL and then launch RA from there?

 

[HelloShitty]

Can anyone Explain me what is this about fuses getting burned? What fuses are these, how and why do they get burned and what happens when there are no fuses left to burn?

 

[binkinator]

Thank you!

So the earlier poster who said forwarders use the same method as HBL and it doesn’t matter which you use is wrong?

You should always use title override to launch HBL and then launch RA from there?

Not sure of the context of the earlier quote. My statement was simply that of the folks from Libretro say the preferred way of running RetroArch is to use Atmosphère's title takeover feature.

As a general rule: If YOU can’t tell the difference between two scenarios, then for all intents and purposes those two scenarios are the same.

 

[binkinator]

Can anyone Explain me what is this about fuses getting burned? What fuses are these, how and why do they get burned and what happens when there are no fuses left to burn?

Here’s a good article about the fuses:

https://switchbrew.org/wiki/Fuses#Anti-downgrade

essentially there are physical countable hardware traces inside the chip that can be shorted out or “burnt” at will in certain scenarios. The system counts how many of these traces are burnt during boot and decides what to do based on the count. Very simple system In that regard. At a high level, Hekate is able to bypass the “burner” and “counter” algorithms, rendering the fuses useless so they remain in burnt and uncounted. Remove Hekate from your machine and it will return to normal operating procedures.

 

[HelloShitty]

Here’s a good article about the fuses:

https://switchbrew.org/wiki/Fuses#Anti-downgrade

essentially there are physical countable hardware traces inside the chip that can be shorted out or “burnt” at will in certain scenarios. The system counts how many of these traces are burnt during boot and decides what to do based on the count. Very simple system In that regard. At a high level, Hekate is able to bypass the “burner” and “counter” algorithms, rendering the fuses useless so they remain in burnt and uncounted. Remove Hekate from your machine and it will return to normal operating procedures.

Hum, ok. Yesterday I found some info in Hekate and I think I already have burnt fuses, no idea why. Does that article specifies which scenarios burn fuses?

Edited;
I think it doesn't.
But what I wonder is that if this is what it looks like to me, is that it's simply registers of a chip. Knowing that, what physical events can occur to a register from a software point of view? I mean, if no shorts are forced nor other over currents are forced to physically damage the chip, what are the risks of "burning fuses"? This term suggest that we are physically damaging the chip in a way that is not reversible! After all isn't this just setting bits to logical 0s and 1s, meaning 0V or 3.3V (or whatever the voltage the chip works at)???

 

[binkinator]

Hum, ok. Yesterday I found some info in Hekate and I think I already have burnt fuses, no idea why. Does that article specifies which scenarios burn fuses?

If you aren‘t bypassing the stock bootloader (where the fuse checker is) with Hekate it checks the chart listed in the article against the FW it’s trying to boot. If the fuses are too low according to the chart the checker will burn the necessary number of fuses to bring it in compliance with the chart. If the number of fuses are to high according to the chart the rest of the algorithm kicks in and it will refuse to boot. At that point you’d need to put Hekate back on your Switch and fix things with Daybreak.

Edited;
I think it doesn't.
But what I wonder is that if this is what it looks like to me, is that it's simply registers of a chip. Knowing that, what physical events can occur to a register from a software point of view? I mean, if no shorts are forced nor other over currents are forced to physically damage the chip, what are the risks of "burning fuses"? This term suggest that we are physically damaging the chip in a way that is not reversible! After all isn't this just setting bits to logical 0s and 1s, meaning 0V or 3.3V (or whatever the voltage the chip works at)???

Correct…it is actually physically damaging the traces by throwing too much electricity down the path and frying an actual trace in the circuit. Since this is inside the silicon there no way to restore the traces without damaging the chip itself. It’s broke, Jim.

 

[HelloShitty]

If you aren‘t bypassing the stock bootloader (where the fuse checker is) with Hekate it checks the chart listed in the article against the FW it’s trying to boot. If the fuses are too low according to the chart the checker will burn the necessary number of fuses to bring it in compliance with the chart. If the number of fuses are to high according to the chart the rest of the algorithm kicks in and it will refuse to boot. At that point you’d need to put Hekate back on your Switch and fix things with Daybreak.

Correct…it is actually physically damaging the traces by throwing too much electricity down the path and frying an actual trace in the circuit. Since this is inside the silicon there no way to restore the traces without damaging the chip itself. It’s broke, Jim.

Hum, ok.
I'm actually still struggling to understand the variety of bootloaders, CFWs, OFWs, etc.
I'm trying to organize my mind about all this int he following manner:

Bootloader:
Hekate
Original Nintendo bootloader (I don't know the name nor if after we mod the console, we still have access to it)

Firmwares:
Nintendo OFW
Atmosphère CFW

OS'es
Homebrew ???
Nintendo OS

No idea if I can think of it this way, can I?

And if so, by choosing Hekate -> Launch - Stock OS am I or am I not loading the 100% OFW as if I never modded the console?

 

[binkinator]

Hum, ok.
I'm actually still struggling to understand the variety of bootloaders, CFWs, OFWs, etc.
I'm trying to organize my mind about all this int he following manner:

Bootloader:
Hekate
Original Nintendo bootloader (I don't know the name nor if after we mod the console, we still have access to it)

Firmwares:
Nintendo OFW
Atmosphère CFW

OS'es
Homebrew ???
Nintendo OS

No idea if I can think of it this way, can I?

And if so, by choosing Hekate -> Launch - Stock OS am I or am I not loading the 100% OFW as if I never modded the console?

I’ll take a stab at this and allow others with more detailed knowledge correct any mistakes I make and fill in any gaps.

Hekate is a bootloader. I think of it like a BIOS. There is a normal “BIOS“ already inside the Switch that gets all the components (like usb, sd card, screen, digitizer, etc) powered up and communicating before it hands them off the OS (and does things like checking for burnt fuses.) The stock system is hard coded to boot nothing but the Horizon Operating System (HOS). Hekate is ”injected” to interrupt the normal ”BIOS” process and allows us to skip and alter some of them and ultimately hand odd to our own stack.

Original Firmware (OFW) is HOS.

Custom Firmware (CFW) is Atmosphere. Atmosphere isn’t a replacement OS but more like a custom set or wrappers around the original HOS that makes it behave the way we want and break out of the walled garden. SXOS and ReiNX were similar alternate CFWs that, again, were not replacements of HOS.

L4T and Android are examples of Operating Systems that completely replace HOS.

One of the advantages of breaking out of the system is we can ignore or modify things. Things that would require code to be cryptographically signed in order for HOS to run it no longer have to be under CFW. This enables homebrew.

Homebrew apps are unsigned programs that interface with the OS and make it so things it originally was not intended to do. Since the entirety of the Os has been laid bare we can pretty much do anything we want within the limits of the OS and the hardware. Sky is the limit (as long as the OS and memory, CPU, graphics etc etc will allow it.)

I’m going to stop there as I’m probably already stretching things beyond my knowledge and making some real OGs cringe with my noobness.

So to answer your question, by using Hekate as an ”injected” BIOS to boot the stock OS…

Hekate hands off to 100% OFW and HOS then runs as if you have not modded the console.

 

[HelloShitty]

I’ll take a stab at this and allow others with more detailed knowledge correct any mistakes I make and fill in any gaps.

Hekate is a bootloader. I think of it like a BIOS. There is a normal “BIOS“ already inside the Switch that gets all the components (like usb, sd card, screen, digitizer, etc) powered up and communicating before it hands them off the OS (and does things like checking for burnt fuses.) The stock system is hard coded to boot nothing but the Horizon Operating System (HOS). Hekate is ”injected” to interrupt the normal ”BIOS” process and allows us to skip and alter some of them and ultimately hand odd to our own stack.

Original Firmware (OFW) is HOS.

Custom Firmware (CFW) is Atmosphere. Atmosphere isn’t a replacement OS but more like a custom set or wrappers around the original HOS that makes it behave the way we want and break out of the walled garden. SXOS and ReiNX were similar alternate CFWs that, again, were not replacements of HOS.

L4T and Android are examples of Operating Systems that completely replace HOS.

One of the advantages of breaking out of the system is we can ignore or modify things. Things that would require code to be cryptographically signed in order for HOS to run it no longer have to be under CFW. This enables homebrew.

Homebrew apps are unsigned programs that interface with the OS and make it so things it originally was not intended to do. Since the entirety of the Os has been laid bare we can pretty much do anything we want within the limits of the OS and the hardware. Sky is the limit (as long as the OS and memory, CPU, graphics etc etc will allow it.)

I’m going to stop there as I’m probably already stretching things beyond my knowledge and making some real OGs cringe with my noobness.

So to answer your question, by using Hekate as an ”injected” BIOS to boot the stock OS…

Hekate hands off to 100% OFW and HOS then runs as if you have not modded the console.

I'll try to rephrase by my own words just to be sure I understood your words.
Ok, so from what I could understand, the stock bootloader still runs some code until Hekate comes in and stop it so that we can have some control over the initial processes. Am I, at least, close?

Then, when we choose to launch Atmosphere, it will also stop HOS from running alone, allowing us to do things we wouldn't be able with HOS unless those changes could be cryptographically signed so that they could be "seen" as legit by HOS.
Am I close here to?

But in the end, this was not my initial question. heheh. But it was also a question I wanted to know more about in a near future.
As of now, my main interest was to understand the custom and otiginal bootloaders, custom and original firmwares, custom and original OS'es so that I can keep track of what people say and understand what they say.

As an example, I was confused when you mentioned "stock bootloader" because I don't even know if there is a specific name like we have for Hekate (which I take as a custom bootloader).

And when we call firmware to Atmosphere, I mean, firmware can be any piece of code we load onto a chip, as far as I'm concerned! Operating system is also a firmware but at a higher level, which allow us to interface lower layers (hardware, protocols, etc) with higher level laayers such has software running on top of an Operating system! So, this is confusing to me!
For instance, something like this table, would be clear to me:

ONB - Original Nintendo Bootloader
ONF - Original Nintendo Firmware (the files we download with versions like 14.1.1)

But I think things cannot be separate just like this.

 

[binkinator]

I'll try to rephrase by my own words just to be sure I understood your words.
Ok, so from what I could understand, the stock bootloader still runs some code until Hekate comes in and stop it so that we can have some control over the initial processes. Am I, at least, close?

Yes, correct.

Then, when we choose to launch Atmosphere, it will also stop HOS from running alone, allowing us to do things we wouldn't be able with HOS unless those changes could be cryptographically signed so that they could be "seen" as legit by HOS.
Am I close here to?

Yes, correct.

But in the end, this was not my initial question. heheh. But it was also a question I wanted to know more about in a near future.
As of now, my main interest was to understand the custom and otiginal bootloaders, custom and original firmwares, custom and original OS'es so that I can keep track of what people say and understand what they say.

Yes, I had to give a little bit of history to get to where we wanted to be today.

As an example, I was confused when you mentioned "stock bootloader" because I don't even know if there is a specific name like we have for Hekate (which I take as a custom bootloader).

Yes, Hekate is a custom RCM injectable bootloader. I don’t know the name of the official process that handles the fuse checking and other initiation processes. (I guess I should be calling it a Boot ROM.)

edit: Found the name of the official bootloader! Package1ldr decrypts and validates Package1. This in turn hands off to NX bootloader.
More information on this here: https://switchbrew.org/wiki/Package1

Here are a couple of the original docs on the topic:
https://github.com/Qyriad/fusee-launcher
https://fail0verflow.com/blog/2018/shofel2/

And when we call firmware to Atmosphere, I mean, firmware can be any piece of code we load onto a chip, as far as I'm concerned! Operating system is also a firmware but at a higher level, which allow us to interface lower layers (hardware, protocols, etc) with higher level laayers such has software running on top of an Operating system!

Horizon OS is an upgradeable Firmware and Operating System. Purists would call me out for not being more specific but I tried looking it up for clarification and Wikipedia says the same thing, so it‘s a packaged all in one deal.

https://en.wikipedia.org/wiki/Nintendo_Switch_system_software

So, this is confusing to me!
For instance, something like this table, would be clear to me:
View attachment 307054

ONB - Original Nintendo Bootloader
ONF - Original Nintendo Firmware (the files we download with versions like 14.1.1)

But I think things cannot be separate just like this.

Yeah, you can’t separate it like that.

I would think of it more like a car analogy…

You have a car with an upgradable engine (HOS with FW updates) and you can start it with the key like normal or you can remote start it with a special key fob (Hekate) that turns off the speed governor (no more fuses) and turns on a few performance mods like a supercharger and full access to the electrical system (Atmosphere). Devs can tap into the electrical system and attach things like a boost gauge or change the engine timing to something more aggressive or install a stereo system inside (Homebrew apps) that were not accessible in the stock car. I think the analogy is starting to come apart a little so I’ll stop.

bottom line: None of the components we talk about here are replacements for anything stock, but rather augmentations of what was already there.