Hacking SWITCH NOOB PARADISE - Ask questions here

[impeeza]

There's a 90DNS Tester that you can run from your Switch to check if DNS MITM is actually working. Good to know that 90DNS has it's own script as well, thanks for mentioning that.


There's also this fix. I haven't tested it personally since I'm using Exosphere and DNS MITM. As for 90DNS, it requires that you manually set it up for every wireless connection. There's 90DNS setter as well, but I haven't tried it out yet.


Only thing they are currently missing in their hekate_ipl.ini file is the kip1patch=nosigchk line in both CFW configurations. Without them I believe that sigpatches won't work when chainloading fusee. (Provided I'm reading it correctly through sys-patch, which says Patched instead of Patched for fs patches, i.e. sys-patch did the patching instead of sigpatches.)


I've read it couple of times already but I couldn't find any info about this? Can you show me the source? Too bad if it's true, DBI really is an amazing tool.


It doesn't hurt to have exosphere's prodinfo blanking enabled while also having 90DSN/DNS MITM in place. Ever since 17.0.0 firmware got released and they fixed the prodinfo blanking, resulting in an error in both OFW and Atmosphere. Therefore, to me at least, it serves as a warning of sorts that maybe, just maybe, DNS MITM / 90DNS stopped working properly and my console tried to connect to the Nintendo servers, resulting in Atmosphere crashing with a specific error (can't remember which one right now, I'll have to look it up later).


@impeeza wrote a detailed explanation when I asked him the similar question. You can check his reply here.

I do not even remember that post, Thanks a lot, recently someone asked on other post and I has to write almost everything again.

 

[NeoYggdrasill]

There's a 90DNS Tester that you can run from your Switch to check if DNS MITM is actually working. Good to know that 90DNS has it's own script as well, thanks for mentioning that.


There's also this fix. I haven't tested it personally since I'm using Exosphere and DNS MITM. As for 90DNS, it requires that you manually set it up for every wireless connection. There's 90DNS setter as well, but I haven't tried it out yet.


Only thing they are currently missing in their hekate_ipl.ini file is the kip1patch=nosigchk line in both CFW configurations. Without them I believe that sigpatches won't work when chainloading fusee. (Provided I'm reading it correctly through sys-patch, which says Patched instead of Patched for fs patches, i.e. sys-patch did the patching instead of sigpatches.)


I've read it couple of times already but I couldn't find any info about this? Can you show me the source? Too bad if it's true, DBI really is an amazing tool.


It doesn't hurt to have exosphere's prodinfo blanking enabled while also having 90DSN/DNS MITM in place. Ever since 17.0.0 firmware got released and they fixed the prodinfo blanking, resulting in an error in both OFW and Atmosphere. Therefore, to me at least, it serves as a warning of sorts that maybe, just maybe, DNS MITM / 90DNS stopped working properly and my console tried to connect to the Nintendo servers, resulting in Atmosphere crashing with a specific error (can't remember which one right now, I'll have to look it up later).


@impeeza wrote a detailed explanation when I asked him the similar question. You can check his reply here.

Thanks, that was very helpful. The 90dns-tester shows that all domains are blocked (DNS-MITM only atm). I also added the fix to my atmosphere/exefs_patches directory.

 

[bupeapoop]

If I remember correctly, reboot to Hekate, go to Tools > Archive Bit - AutoRCM > Disable AutoRCM.

That's correct, or any other (similar) method that allows you to boot into RCM.

You can choose whether or not to update your RCMLoader with the latest hekate_ctcaer_x.x.x.bin file because bootloader/update.bin will be checked and, if newer, it will get loaded instead. It's already included with the zip archive you extract when you're updating your Hekate build.

Not that v6.1.1 has been released so do update to the latest whenever you're able to as you'll need it for the latest 18.0.0 firmware. Same goes for the Atmosphere's latest release, v1.7.0.

Note that, if you were using sigpatches for game backups to work, they will no longer work with the latest official Atmosphere (v1.7.0 and newer). You have a few options:
1) Use the latest sys-patch (v1.5.1) module.
2) Use the latest sigpatches, but load Atmosphere's package3 via Hekate's fss0 (to do so, extract the previously downloaded sigpatches ZIP archive to the root of your SD card, reboot to Hekate, go to Launch and select CFW - emuMMC or CFW - sysMMC, depedning on which one you use) or use a modified fusee.bin payload with ips kip patches support.

Blythe93 you have been a tremendous help. You won't believe how many times I found myself banging my head off the wall in my attempt to disable AutoRCM. Your memory stands correct, you did simply reboot to Hekate, go to Tools > Archive Bit - AutoRCM > Disable AutoRCM..

Do you want to know what's hilarious? For months, I thought my Switch was toast. Every time I'd boot it up, I'd have no response. I'd power on my Switch in an attempt to boot to the official Nintendo Switch OS not knowing that AutoRCM was enabled the entire time.... D'oh!

Thanks for notifying me of the new updates to Hekate, Atmosphere and the Sigpatches. I'll go ahead and update both of these tonight since it's Easter Sunday and I'm off from work tomorrow!

Once again, I have another question relating to the Nintendo Standard OS.

Last week, I made the effort to pick up where I left off and began jailbreaking my Switch on a fresh SD Card for the first time in well over a year. Since then, I haven’t once booted into the official Nintendo Switches OS. No doubt, my Switch will need to be updated to the latest 18.0.0 version.

My question is do you recommend that I proceed with updating to the latest Switch Version? Will this cause any issues with any apps that I intend on installing? I don't own any games and I don't intend on playing online etc. I’ll wait for your response before I log into the Switch just in case it attempts to update the minute I boot up.

 

[Draxzelex]

I've read it couple of times already but I couldn't find any info about this? Can you show me the source? Too bad if it's true, DBI really is an amazing tool.

duckbill has stated multiple times that dbi has been discontinued and he's moved onto other projects already. This post is the earliest instance of him saying as such. Personally, I don't really mind its absence but we are in a very bad situation where no title installers are being actively updated. If a future firmware update breaks all currently existing ones, we're in trouble.

It doesn't hurt to have exosphere's prodinfo blanking enabled while also having 90DSN/DNS MITM in place. Ever since 17.0.0 firmware got released and they fixed the prodinfo blanking, resulting in an error in both OFW and Atmosphere. Therefore, to me at least, it serves as a warning of sorts that maybe, just maybe, DNS MITM / 90DNS stopped working properly and my console tried to connect to the Nintendo servers, resulting in Atmosphere crashing with a specific error (can't remember which one right now, I'll have to look it up later).

If 90DNS and dns.mitm can function on their own but not exosphere/Incognito, then the issue lies in the former. Not to mention that you do not obtain extra protection. There are ways Nintendo can obtain info through both being active at the same time. They are theoretical which means you're paranoid about a scenario that has no precedent and if you're that paranoid, then you would also realize the double protection is meaningless. This is similar to people who have both the patches on their SD card as well as sys-patch; its extra space taken on your SD card for no additional payoff. I'm not going to police what you or other people put on your SD card but I'm not going to tell people to waste room on their cards without a good reason.

 

[impeeza]

There are ways Nintendo can obtain info through both being active at the same time

Even DBI can tell you real Serial number even if you have BOOT0 edited with Incognito RCM and Atmosphère's blank_prodinfo

 

[Blythe93]

duckbill has stated multiple times that dbi has been discontinued and he's moved onto other projects already. This post is the earliest instance of him saying as such. Personally, I don't really mind its absence but we are in a very bad situation where no title installers are being actively updated. If a future firmware update breaks all currently existing ones, we're in trouble.

Ah, I do remember seeing his posts about discontinuing DBI, but as far as I know rashevskyv picked it up? Unless he dropped it as well? Or is there something else that I should be aware of?

If 90DNS and dns.mitm can function on their own but not exosphere/Incognito, then the issue lies in the former. Not to mention that you do not obtain extra protection. There are ways Nintendo can obtain info through both being active at the same time. They are theoretical which means you're paranoid about a scenario that has no precedent and if you're that paranoid, then you would also realize the double protection is meaningless. This is similar to people who have both the patches on their SD card as well as sys-patch; its extra space taken on your SD card for no additional payoff. I'm not going to police what you or other people put on your SD card but I'm not going to tell people to waste room on their cards without a good reason.

So, what you suggest is to use either 90DNS or DNS MITM, and not prodinfo blanking? I do know that having both sys-patch and sigpatches at the same time hardly serves a point.

Even DBI can tell you real Serial number even if you have BOOT0 edited with Incognito RCM and Atmosphère's blank_prodinfo

Ouch. So prodinfo blanking is pretty much meaningless?

I'm not going to police what you or other people put on your SD card but I'm not going to tell people to waste room on their cards without a good reason.

Fair enough, I do like to keep my SD card as clean as possible so I'll reword my suggestions in the future replies (and clean up mine as well by doing that). It really helps to hear criticism from time to time as I'm hardly an expert, but I'd like to do my part and help others if possible, purely based on my own experience.

 

[Carquinca]

Hey guys, Im looking for help as something went wrong with my oled install.
Everything was working perfectly, glitching worked 100% of the time, and as I was installing games through tinfoil in the emunand something crashed and an error with the game cartridge started to appear. Now I cannot boot into hekate as it goes straight into ofw, and there is an error that says that the game cartridge could not be read even though I do not have any game cartridge.
The picofly is showing bad D0 as its a long pulse and a short one.

 

[impeeza]

Ouch. So prodinfo blanking is pretty much meaningless?

somehow seems you are correct, I wondered how DBI was able to give my original serial even I have my EmuNAND incognito and blank prodinfo on atmosphère, asked and the answer was "creative coding" but if DBI was able I guess big N will be able too.

 

[Draxzelex]

Ah, I do remember seeing his posts about discontinuing DBI, but as far as I know rashevskyv picked it up? Unless he dropped it as well? Or is there something else that I should be aware of?

Nah its just him hosting the .NRO file since duckbill presumably closed the GitHub page for the original repo. And since its closed source meaning no open source code to work with, I doubt that other person is actively developing it. He even specifically mentions the author is duckbill and not himself.

So, what you suggest is to use either 90DNS or DNS MITM, and not prodinfo blanking? I do know that having both sys-patch and sigpatches at the same time hardly serves a point.

If you want something to keep you safe while using FTP, the homebrew store, or pseudo-online LAN play, then yes. If you aren't using any of these utilities, don't even bother with 90DNS or dns.mitm. My emuMMC is allergic to Wi-Fi settings.

Ouch. So prodinfo blanking is pretty much meaningless?

I'm not surprised. After all, SciresM himself stated that the protection it provided wasn't fullproof. There is information that Nintendo can still obtain without PRODINFO such as the battery serial, which may or may not be linked. I'm pretty sure the only reason he created exosphere was so that people would stop blanking their PRODINFO because without a backup, you've basically banned yourself. And this has happened multiple times if you search up people losing their PRODINFO backups. For this reason, I have never ever recommended Incognito and by extension exosphere.

Fair enough, I do like to keep my SD card as clean as possible so I'll reword my suggestions in the future replies (and clean up mine as well by doing that). It really helps to hear criticism from time to time as I'm hardly an expert, but I'd like to do my part and help others if possible, purely based on my own experience.

No seriously, as a fellow tech supporter, your contribution is greatly appreciated. Nowadays, I only intervene when malicious misinformation is being spread. Your advice is basically on point most of the time so keep up the great work. I'm more nitpicky because I hate how the community turned its back on tools like 90DNS or why the reentry guide makes users chainload fusee through Hekate.

 

[impeeza]

My console just now:

On settings applet, and the black rectangle is on DBI System Info Tool. the guessed one is exactly the one on the box.

 

[Blythe93]

Nah its just him hosting the .NRO file since duckbill presumably closed the GitHub page for the original repo. And since its closed source meaning no open source code to work with, I doubt that other person is actively developing it. He even specifically mentions the author is duckbill and not himself.

Ah, I thought it was just him acknowledging the previous author. Well, I guess the situation is pretty... gray at the moment.

If you want something to keep you safe while using FTP, the homebrew store, or pseudo-online LAN play, then yes. If you aren't using any of these utilities, don't even bother with 90DNS or dns.mitm. My emuMMC is allergic to Wi-Fi settings.

Understood.

Mine used to be allergic to Wi-Fi settings as well, but I wanted to try out Mario Kart Live: Home Circuit and, to do that, I had to connect to the wireless network initially. Later sometime, when I bought a second Switch, my girlfriend and I started playing Animal Crossing: New Horizons. Ever since then, my Switch got used to it. ^^

I'm not surprised. After all, SciresM himself stated that the protection it provided wasn't fullproof. There is information that Nintendo can still obtain without PRODINFO such as the battery serial, which may or may not be linked. I'm pretty sure the only reason he created exosphere was so that people would stop blanking their PRODINFO because without a backup, you've basically banned yourself. And this has happened multiple times if you search up people losing their PRODINFO backups. For this reason, I have never ever recommended Incognito and by extension exosphere.

I see. I remember reading about prodinfo protection in exosphere's template, I think. But seeing that DBI correctly guessed mine, I can expect the same coming from Nintendo. People losing their prodinfo backups (and any backups in general) is, sadly, too much of a common thing, indeed.

No seriously, as a fellow tech supporter, your contribution is greatly appreciated. Nowadays, I only intervene when malicious misinformation is being spread. Your advice is basically on point most of the time so keep up the great work. I'm more nitpicky because I hate how the community turned its back on tools like 90DNS or why the reentry guide makes users chainload fusee through Hekate.

Thank you very much! Thanks to you, impeeza and binkinator (while he was still active), I've solved pretty much all of the problems I've encountered so far (not that I'm actively looking for new ones, that is ^^). And I've learned a thing or two along the way from other users as well. Hayato213. Dust2dust and BigOnYa lurk around here a lot and their replies helped me here and there.

Rentry's fine as long as you take their guides with the grain of salt. Same goes with the NH Switch guide which has a lot more info, but here are there a thing or two could've been explained better. Good old Switch Homebrew Guide that was recently shut down was my usual go-to place. Despite being outdated, some of the core practices didn't really change a lot over the years.

My console just now:

View attachment 429012

On settings applet, and the black rectangle is on DBI System Info Tool. the guessed one is exactly the one on the box.

As soon as you mentioned it, I checked mine as well and "creative coding" did the job properly.

 

[Skv0ra]

So, do we have a clear and definitive instructions to upgrading to a larger microSD WITHOUT losing games/saves/user profiles/etc? I've been searching all the past threads and nothing really fully worked for me.

 

[impeeza]

So, do we have a clear and definitive instructions to upgrading to a larger microSD WITHOUT losing games/saves/user profiles/etc? I've been searching all the past threads and nothing really fully worked for me.

That has ben answered several times, there are two class:

If you are using File Based EmuNAND or not using EmuNAND at all, simple: copy all files from a cart to another.

If you are using Raw Partition Based EmuNAND, you need to backup your EmuNAND and restore it on the new card, then use Hekate to select and setup the new EmuNAND also DO NOT FORGET TO COPY ALL FILES FROM OLD CARD TO NEW ONE.

For backup and restore Raw partition based EmuNAND EmuTool Is your friend.

 

[Skv0ra]

That has ben answered several times, there are two class:

If you are using File Based EmuNAND or not using EmuNAND at all, simple: copy all files from a cart to another.

If you are using Raw Partition Based EmuNAND, you need to backup your EmuNAND and restore it on the new card, then use Hekate to select and setup the new EmuNAND also DO NOT FORGET TO COPY ALL FILES FROM OLD CARD TO NEW ONE.

For backup and restore Raw partition based EmuNAND EmuTool Is your friend.

And when EMUtool has target card options all grayed out?

Or just copy the hidden partition as Atmosphere files, and then re-inject from that?

 

[impeeza]

And when EMUtool has target card options all grayed out?

Or just copy the hidden partition as Atmosphere files, and then re-inject from that?

Emutool BACKUP AND RESTORE the EmuNAND

First you backupt your Raw Partition EmuNAND AS A SET OF FILES (EVEN YOU CAN USE THAT FILES FOR CREATE A FILE BASED EMUNAND)

THEN you use the backup to RESTORE the EmuNAND on a free space of the DESTINATION SD Card.

 

[jgs88]

Hi all,

I'm new to all of this, somewhat a noob, and I'm kinda stuck in the process.

I have an unpatched v1 Switch with a 128gb microSD in it: I have the rcm-clip and the device has hekate on it.
I have the tegrarcmgui installed on the pc. And i've downloaded some nsp, nsz and xci files on my computer. I also did the 90DNS where you block the Nintendo-server (or so?),

And this is where i get stuck

I want to put the games on the Switch so I can play some Switch-games.
What do I need to do from this point on? I feel like being far away, and close at the same time

 

[Blythe93]

Hi all,

I'm new to all of this, somewhat a noob, and I'm kinda stuck in the process.

I have an unpatched v1 Switch with a 128gb microSD in it: I have the rcm-clip and the device has hekate on it.
I have the tegrarcmgui installed on the pc. And i've downloaded some nsp, nsz and xci files on my computer. I also did the 90DNS where you block the Nintendo-server (or so?),

And this is where i get stuck

I want to put the games on the Switch so I can play some Switch-games.
What do I need to do from this point on? I feel like being far away, and close at the same time

Since you're probably new to the Switch hacking scene, I'd suggest that you go through these two guides: NH Switch guide and Rentry.org Switch guide. Getting familiar with the terms used will make updating your Switch and troubleshooting your issues much easier for you.

For game backups to work, you'll need either sigpatches (download the latest ones as they are compatible with all the previous versions of firmware and Atmosphere) or sys-patch [1][2]. If unsure, go with the sys-patch, especially if you're using fusee.bin to boot into Atmosphere. Optionally, you can install Tesla + nx-ovlloader as that will allow you to see whether sys-patch is working properly, after you press L + D-pad Down + R (Stick) combo, select sys-patch, followed by Log. If it says:

1. Patched = the pattern it's searching for is already patched by sigpatches, so there's no need to patch it again;
2. Patched = the pattern is patched by sys-patch (i.e. sigpatches are not present or haven't been applied on boot);
3. Unpatched = the pattern wasn't found by sys-patch on the current system so there's no need to patch them (only present if you turn off the Version skip in the Options).

If you'd like to use sigpatches instead of sys-patch, note that Atmosphere 1.7.0 or newer won't support ips kip patches anymore, so you'll have to either use the modified fusee.bin with the ips kip patches support restored or load Atmosphere's package3 via Hekate's FSS0 (note that sigpatches archive from here comes with the necessary entries in the bootloader/hekate_ipl.ini file, therefore booting into Hekate, followed by Launch and selecting either emuMMC or sysMMC CFW, depending on which one you use, will result with the sigpatches working properly again).

You can also use both, if you want. It won't cause any conflict, but it's recommended to stick to one that works for you in order to reduce the clutter on your SD card since they are doing the same thing.

To install the games, I generally suggest using DBI. Here's a good video tutorial by sthetix.

 

[bupeapoop]

After following the NH Switch Guide from start to finish, I finally got to the point of Launching CFW. After following the instructions by navigating to 'Launch' followed and looking for 'Atmosphere FSS0 emuMMC' before launching it. However, my Switch states that no main boot entries found...

In the Launch page of my Switch it states the following:

No main boot entries found...
Check that bootloader/hekate_ipi.ini has boot entries
or use More configs button for more boot entries

Can someone explain where I may have gone wrong or what to do to resolve this issue? I looked back through the NH Switch Guide and I can't seem to see where I missed a step?

There was no mention of updating the hekate_ipl.ini file using the NH Switch Guide. After a quick search, I went ahead and used the config file from the patches thread insitead. Upon doing so, I now received the following error message when attempting to boot into the emuMMC

Failed to apply 'nosigchk'!
Press POWER to continue
Press VOL to go to the menu
Failed to launch HOS!
Press any key...

With regards to sigpatches, I went ahead and chose to the use the latest sys-patch (v1.5.1) module. Now I'm not sure if that has any effect on the fact I chose to use the config settings from the sigpatches thread? Also, I'm unsure why the NH Switch Guide has no mention of updating the hekate_ipl.ini file. The NH Guide tells you to launch 'Atmosphere FSS0 emuMMC'. When I updated the hekate_ip.ini file with the Sig Patches settings, it gave me 3 options:

• CFW - sysMMC,
• CFW - emuMMC
• Stock - sysMMC,

There's no mention of the Atmosphere FSS0 emuMMC as stated in the NH Switch Guide.

To say I'm a little confused at the moment would be an understatement?

 

[Blythe93]

To say I'm a little confused at the moment would be an understatement?

I feel ya. All those guides do some things a little bit differently than others so no wonder users run into errors. It takes some time getting used to all the terms being thrown around.

There was no mention of updating the hekate_ipl.ini file using the NH Switch Guide.

hekate_ipl.ini is mentioned here. However their config is missing the kip1patch=nosigchk line for both CFW boot entries.

I went ahead and used the config file from the patches thread insitead.

That one should be good, it's the same one that I'm using currently.

I now received the following error message when attempting to boot into the emuMMC

Can you check if you have patches.ini file in bootloader folder?

Now I'm not sure if that has any effect on the fact I chose to use the config settings from the sigpatches thread?

Long story short, for what you're trying to accomplish, I don't think it has any effect.

There's no mention of the Atmosphere FSS0 emuMMC as stated in the NH Switch Guide.

That's because you've overwritten NH Switch guide's hekate_ipl.ini with the one from sigpatches, which is totally OK. Their Atmosphere FSS0 emuMMC is the sigpatches archive's CFW - emuMMC. The only thing the NH Switch guide is missing is the kip1patch=nosigchk line for both CFW boot entries, which the sigpatches' one has.



Since Atmosphere 1.7.0 no longer supports ips kip patches (check the release notes here), which are usually used for piracy reasons, here are your options:

• You can load Atmosphere's package3 via Hekate's FSS0 - You'll need to reboot to Hekate, go to Launch and select emuNAND CFW or sysNAND CFW (depending on which one you use). If you've downloaded the sigpatches from here. your bootloader/hekate_ipl.bin will already have everything you need to have configured.
• Use sys-patch instead of sigpatches. This way, booting into Atmosphere with fusee.bin payload will work and sys-patch will make your game backups work.
• Use modified Atmosphere's fusee.bin payload with ips kip patches support. With this, sigpatches will work the same way they used to work prior to v1.7.0.

I'd suggest that you pick either sys-patch or sigpatches in order to reduce clutter on your SD card and make your life a bit easier going forward. Using both is totally fine, too, as they aren't conflicting each other.

Hopefully, that cleared a thing or two for (and didn't introduce any new one). ^^

 

[Carquinca]

Hey guys, my console is failing to boot due to D0 but it starts up good when its cold. Do you think that the problem is the emmc flex, or could it be the quality of the cable used to solder to the picofly? also to fix this, what do you recommend, kamikaze method or soldering a cable below the emmc or soldering the flex onto the emmc with a heatgun?