Hacking How does SX OS Emunand work?

Draxzelex · Sep 25, 2018

aleuts said:
But isn’t the flip side that nsp is more “dangerous” than xci with regards to leaving a trace on the system? That’s a big factor if true

With regards to being banned, both .XCI and .NSP can flag a user for a ban (people have been banned for both up to this point). The key here is if you restore a NAND, it reduces your chances of getting banned to nearly 0%, regardless if you use .XCI or .NSP. So if you are not restoring a clean NAND prior to going online, it may be better to stick to .XCI files but bans for .NSP files are typically due to the fake tickets installed into the system needed to launch them which you can remove in Tinfoil before going online (as well as uninstalling the software manually).

DiscostewSM · Sep 26, 2018

Mauste said:
You would not have to keep the emunand on low FW. As it would be "dirty" anyway, you could simply update it with ChoiDuJourNX, and if some exploits appear that need a lower firmware, you could downgrade the emunand to that firmware.

For example:

- Clean OFW /w AutoRCM (or careful booting) for online & legit play - Latest Firmware
- Dirty Emunand /w AutoRCM - Latest Firmware with the option for downgrade in case new exploits appear.

Does this make any sense? I barely slept last night, so maybe I am not thinking straight

So for perhaps my position, I'd update OFW to 6.0 using ChoiDuJourNX so it won't burn fuses and allow me to play my legit games and go online, also having CFW Emunand at 6.0 with Stealth Mode so I can have my homebrew and emulators, all while having AutoRCM to prevent further burnt fuses? Is that correct?

Philourer · Sep 26, 2018

If you're playing online, a legit xci backup (with the cart's unique header) is safer than an nsp. I refuse to go online with a switch that has had any nsp installed (eshop purchases are fine, I'm talking about if you have an actual nsp file that you have to manually install).

Any of this is a ban risk, but some things are more likely to result in a ban than others. At this point, I haven't been banned even though I played (legit) xcis online (on 5.1.0, not brave enough to try on 6.0 yet) or been online with 6.0 with only 6 fuses burned and AutoRCM enabled (same system that I played xci backups with on 5.1.0). I'm not recommending anyone do this, or claim that it's safe. But it's "safe-ish" enough for me.

Philourer · Sep 26, 2018

DiscostewSM said:
So for perhaps my position, I'd update OFW to 6.0 using ChoiDuJourNX so it won't burn fuses and allow me to play my legit games and go online, also having CFW Emunand at 6.0 with Stealth Mode so I can have my homebrew and emulators, all while having AutoRCM to prevent further burnt fuses? Is that correct?

Any of that could cause a ban. If it were me, I'd wait until emunand has matured a bit more. If you're in a rush, I'd consider trying what you stated with one exception: let the switch download the update to 6.0 and install normally. It appears as though installing any way other than via an online update is currently a possible ban flag (since it's currently impossible for a switch to legitimately upgrade to 6.0 without the online update). This is what I did. It's not foolproof though. I made sure the jig was properly installed, even disabled AutoRCM to make sure it was the jig that got me in RCM mode (I already had 6 fuses blown, so no biggie if it didn't work first go). Anyway, boot normally into OFW, have the jig and dongle (or whatever you send the payload with) plugged in. Let it update to 6.0. When it says it's done (and is about to reboot), push and hold the volume+ button until you are in RCM mode (don't just push and release, it must be held down while it is booting up). Don't skip holding the vol+ button, the official upgrade will turn AutoRCM off and you must hold vol+ with the jig in to enter RCM mode. Also note, it's fine if you press vol+ early, all you'll do is turn the volume up

Now is a good time to re-enable AutoRCM; it's not strictly necessary, and may be "safer" from a ban standpoint to keep it off; but I reckon going online with a wrong fuse count is just as (un)likely to be flagged for a ban, so I personally would recommend AutoRCM. This way you can NOT accidentally boot straight into OFW, and burning extra fuses. Do read up on the pros and cons, don't just enable it blindly and get mad at me if something goes wrong.

Just checked, still have eshop access on my 6.0 switch that has AutoRCM enabled and only 6 fuses burned. I'd say it's safe-ish for now, but certainly not 100% safe (far from it).

bundat · Sep 26, 2018

DiscostewSM said:
So for perhaps my position, I'd update OFW to 6.0 using ChoiDuJourNX so it won't burn fuses and allow me to play my legit games and go online

Just a warning about doing that though:

bundat said:
I was thinking updating (back when 5.1.0 was the latest) using ChoiDujourNX was semi-safe because while you never asked N's servers for the 5.1.0 update, it's possible you may have gotten the 5.1.0 update offline from a cartridge that had it.

But right now, AFAIK there are no cartridges out yet with 6.0 FW, so it would be like a giant red flag (imo) to suddenly be on FW 6.0 without your Switch ever asking N's servers for the update officially... because where else could your Switch have gotten the 6.0 update?

Draxzelex said:
Initially when I saw 2 new homebrew only bans, I was highly suspicious of why these users were suddenly banned without touching .NSP, .XCI, or LayeredFS. However, someone brought up some food for thought.

-snip-

Sure enough, these 2 people updated using ChoiDujourNX because they indicated they updated without burning fuses and the reason why they were banned is explained as above. To summarize, it is impossible to be on firmware 6.0 without going online beforehand so if you're already on firmware 6.0 prior to connecting to the Internet, it most likely set a red flag to Nintendo which led to a ban. Now there are other risk factors to consider here such as AutoRCM and other homebrew possibly utilized. However given the evidence, logic dictates that if you to update to firmware 6.0 without a ban, you should do so via official methods until a cartridge comes with firmware at the very least.

I personally use this method, which does not have the risk stated above:
https://gbatemp.net/threads/an-easy...ch-firmware-without-burning-any-fuses.511847/
But it's risky (in that you may burn your fuses if your jig is not 100% reliable). I have 100% reliable jigs though (SX pro and xkit.xyz jigs)

EDIT: this method is what the poster above me is talking about (as well as the offline update ban risk), I didn't realize someone already mentioned these because I didn't read through the new replies here right away

I also recommend using this payload with this method to be 100% sure your jig is installed correctly: JigTester RCM Payload

@Philourer you might also find this payload useful for future updates. No need to disable AutoRCM anymore to test if your jig is installed properly.

Philourer · Sep 26, 2018

bundat said:
I also recommend using this payload with this method to be 100% sure your jig is installed correctly: JigTester RCM Payload

@Philourer you might also find this payload useful for future updates. No need to disable AutoRCM anymore to test if your jig is installed properly.

I just put jigtestet.bin on the root of my sd, boot to the SX OS screen, select that payload, and it'll give me some confirmation message? Sounds cool, will try to check it out later. I have the SX jig which may or may not have given me issues once (on reflection I think I may have forgotten to press vol+, I became so used to how AutoRCM works).

Thanks!

bundat · Sep 26, 2018

Philourer said:
I just put jigtestet.bin on the root of my sd, boot to the SX OS screen, select that payload, and it'll give me some confirmation message? Sounds cool, will try to check it out later.

Yeah it loads a program that can show in REALTIME the jig connection status.
I tried plugging in the jig very lighty, and the message was flickering between "is pressed" and "is not pressed".
So I was able to figure out how deep I have to seat my jig in to maintain a stable connection.

Myron49485 · Sep 26, 2018

Draxzelex said:
Even deleting the Wi-Fi settings are not sufficient as the Switch has hidden Wi-Fi settings embedded in it that we know as Nintendo Hotspots.

Does this mean that SX Stealth Mode is more effective than using a blocking DNS? Since SX Stealth Mode blocks all telemetry, while the DNS only blocks telemetry for saved connections (which doesn't block these Nintendo Hotspots).

danhern · Sep 26, 2018

Philourer said:
Totally serious that these are plausible, but not confirmed (at the time of my post, though it seems I may have been partially right about #3 after all).

Yeah, I've done emunand on the wii and wii u. After it was a mature process. No idea what it was like at first. They are different consoles though, just because the wii works great with certain exploits doesn't mean you can run a quick sed changing "wii" to "switch" in your code. I'm fairly certain we'll get emunand on sd on the switch, after the developers have more time to work on it.

As for your comment on #3, SX OS doesn't appear to be marketed as a pro(sumer) item. I MIGHT agree that bans should be expected, but simply using a product as intended should not result in a brick. That's like saying a newbie buying a switch off Amazon should have known better than to buy the "recommended with this item" 3rd party dock. I know better, but I already knew of these forums before purchasing a switch. I'm not the average consumer.

I never claimed that emunand would be a quick fix. However, no code would increase or decrease the performance of the emunand once it's actually released. The switch OS is much less intensive than the Wii U OS, so there's no problem regarding SD card usage that would make that a bad option.

#3. You are hacking your switch. You play with fire, you get burned. A newbie wouldn't be trying to do this ever, you shouldn't even need to be told not to do that unless you knew exactly what you were doing. You don't accidentally load the nand off of another switch onto yours.

Draxzelex · Sep 26, 2018

Myron49485 said:
Does this mean that SX Stealth Mode is more effective than using a blocking DNS? Since SX Stealth Mode blocks all telemetry, while the DNS only blocks telemetry for saved connections (which doesn't block these Nintendo Hotspots).

Stealth Mode and DNS servers only differ by one URL and that's the connection test (actually I'm not sure if Stealth Mode blocks that one too). In terms of telemetry URLs, both block all of the necessary ones so functionally, they're identical.

Myron49485 · Sep 26, 2018

Draxzelex said:
Stealth Mode and DNS servers only differ by one URL and that's the connection test (actually I'm not sure if Stealth Mode blocks that one too). In terms of telemetry URLs, both block all of the necessary ones so functionally, they're identical.

Should the Nintendo Hotspots be a concern?

I use 90DNS for all my saved connections. 90DNS only blocks telemetry that goes through saved connections. However, the Switch could send telemetry through these Nintendo Hotspots, which aren't protected by 90DNS.

So is it correct to say that 90DNS does not block Nintendo Hotspots? And since SX Stealth Mode blocks telemetry from within the system, it should be able to block these Nintendo Hotspots?

Draxzelex · Sep 26, 2018

Myron49485 said:
Should the Nintendo Hotspots be a concern?

I use 90DNS for all my saved connections. 90DNS only blocks telemetry that goes through saved connections. However, the Switch could send telemetry through these Nintendo Hotspots, which aren't protected by 90DNS.

So is it correct to say that 90DNS does not block Nintendo Hotspots? And since SX Stealth Mode blocks telemetry from within the system, it should be able to block these Nintendo Hotspots?

While these Nintendo Hotspots can cause a console to randomly connect to the Internet, you can simply use Airplane Mode if you're out and about since I doubt you will be using FTP or updating SX OS while near a Nintendo Hotspot.

Philourer · Sep 26, 2018

danhern said:
You don't accidentally load the nand off of another switch onto yours.

That's my point though. With the current implementation, flawed as it may or may not be, a newbie with their new SX OS will NOT be able to accidentally run the wrong emunand. But had the emunand been stored on the sd card, it'd be really easy to if you have multiple switches (I started with three, I now have a fourth that does not have an SX OS license). Let's say I redo a card (maybe I get tired of Fat32 and reformat as exfat, or I upgrade to a bigger card), I get the right license.dat file, but bugger-all, I copy the wrong emunand! An easy mistake to make (I may or may not have made many similar mistakes in the past). Or maybe I know what I'm doing and just want to try it out. If the developers know it's buggy to do that, they should make sure it's not possible to do or warn against it (but then we'll hear stories of "if they knew....).

I stand behind my overall theory which is "They wanted to be first with an emunand, had to cut some corners and didn't have time to properly test every possible scenario. Expect more functionality in the next release."

Captain_N · Sep 26, 2018

instead of dropping these nand.bin files in a known position why not disguise them as any installed games's save file. You pick a game or a demo and it replaces the games/demos save file. Its still named the same as the game but contains the nand.bin content. since it can any game/demos save file it would be alot harder to detect. There would have to be a way for the sx os to know what game it is. Oh and you better not load that game or you would have to reinstall emunand. also dont send the save to nintendos clould lol

thaikhoa · Sep 26, 2018

If N would detect any trace of cfw's stuff (nand and sd) none could stop them.
For example
atmosphere, switch, reinx, rajnx, sxos folder
*.nro, *.kip

Draxzelex · Sep 26, 2018

thaikhoa said:
If N would detect any trace of cfw's stuff (nand and sd) none could stop them.
For example
atmosphere, switch, reinx, rajnx, sxos folder
*.nro, *.kip

Not really, you can just simply have stuff that happens to share the name of CFW on your SD card. Them being on your SD card alone doesn't mean your console is hacked; it just means you threw some weird looking files on your SD card. What would cause a red flag is something being stored in the USER partition that isn't supposed to be there such as PRODINFO which is normally stored in the SYS partition. Not to mention it is probably illegal for Nintendo to scan SD cards as they can very easily contain private and personal information.

Philourer · Sep 26, 2018

Draxzelex said:
Not really, you can just simply have stuff that happens to share the name of CFW on your SD card. Them being on your SD card alone doesn't mean your console is hacked; it just means you threw some weird looking files on your SD card. What would cause a red flag is something being stored in the USER partition that isn't supposed to be there such as PRODINFO which is normally stored in the SYS partition. Not to mention it is probably illegal for Nintendo to scan SD cards as they can very easily contain private and personal information.

Nintendo seems to be taking the "innocent until proven guilty beyond a reasonable doubt" approach to banning. Simply having some files on an sd card is not proof you hacked your switch. Maybe you borrowed a friend's card. Maybe you put some files on the card you downloaded off the internet thinking it was legit, but didn't actually hack (i.e. you didn't get a dongle and jig, never booted into rcm, etc.). Maybe you backed up your partition table on your linux pc and saved it as boot.dat on your sd card. Heck, it's been semi proven that simply playing a game before it's released isn't enough. Think about it. What if you bought a game on release day, but for some reason the switch had the wrong date on it and thought it was last month (or year)? The logs would show you played it a month (or year) before the release date. So, that in and of itself isn't enough for a ban. Now, if you played it, have logs of playing it, AND connect online BEFORE it's released, then you absolutely positively did something shady, and you're banned.

So, they won't (likely) ban you simply for having a file called "I_Pirated_this_copy_of_Mario_Kart.xci" on the sd card. They don't seem to be that aggressive. But they COULD ban you for having a file called "Totally_not_an_emunand_haha.bin" on the sysnand itself. There is no legitimate reason or excuse for that file to be on the sysnand. Someone purposely hacked the console. Ban away.

datnodude · Sep 26, 2018

Draxzelex said:
With regards to being banned, both .XCI and .NSP can flag a user for a ban (people have been banned for both up to this point). The key here is if you restore a NAND, it reduces your chances of getting banned to nearly 0%, regardless if you use .XCI or .NSP. So if you are not restoring a clean NAND prior to going online, it may be better to stick to .XCI files but bans for .NSP files are typically due to the fake tickets installed into the system needed to launch them which you can remove in Tinfoil before going online (as well as uninstalling the software manually).

If I have a xci file mounted and install a nsp update file of the title, will that cause the ticket issue?

Draxzelex · Sep 26, 2018

datnodude said:
If I have a xci file mounted and install a nsp update file of the title, will that cause the ticket issue?

Well updates do not need tickets to be played since they aren't user specific unlike DLC or games but installing an update artificially is still not considered safe.

ChibiReaper · Sep 26, 2018

Probably a dumb question but imI going to ask anyway, if I just set up my emunand with a 128gb sd card in and I just got a 256gb card, when I copy/pasta all the files from my current card to the new one, will I have any problems booting? I know the emunand is on the switch storage but I just want to be cautious.

Hacking How does SX OS Emunand work?

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

¿

Well-Known Member

¿

Well-Known Member

Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Active Member

Well-Known Member

Well-Known Member

Similar threads

Popular threads in this forum