First the insane telemetry in Horizon and now this.
I learned to program writing GBA homebrew and absolutely love Nintendo games. The stuff they've done with the switch is so sad.
I learned to program writing GBA homebrew and absolutely love Nintendo games. The stuff they've done with the switch is so sad.
Bans are issued on some kind of unique per-device ID. So you're not completely safe using EmuNAND, unless you refrain from ever going online.
Common practice is to do homebrew activity on EmuNAND without going online there, and keeping a clean SysNAND for online activities. You can also wipe uniquely identifying keys on EmuNAND and essentially ban yourself there, then you won't be able to use any Nintendo services (incl. updates & online play) in EmuNAND but you can go online for homebrew stuff -relatively- safe.
So what you can't have is both homebrew and online services in the same NAND. Not to mention no matter how hard the community tries, each new update has the potential for Nintendo to introduce more "telemetry" to identify CFW devices before community gets wiser.
Either way, there are no certainties when it comes to ban evasion.
Replacing a memory chip would not do anything because those aren't used.
The artificial constraint is either that the code (firmware) is closed, or both closed and signed.
Otherwise, I like the criterion a lot. It's a decent distinction between what's "software" and "hardware".
Another blurry line is devices that come with a memory chip where their program code is loaded, but they later need to have a patch loaded by the OS each time (like Intel microcode). Yet another uncertainty depends on how we define root access. If we take it to mean "I have the last word", then Intel/AMD and some ARM CPUs don't qualify, as they have deep, manufacturer-signed-only modes.
Although I personally don't always consider this to be a hard reason not to use hardware, yes, I am indeed quite grumpy about the fact that most of my systems contain parts that I don't control. As to practical fallout, it varies by impact and options; since AFAIK I can't buy a modem that doesn't use binary blobs, I just factor it into my threat model with mitigations where reasonable (thankfully, not all phones expose all of main memory to the modem) and move on, but where there are reasonable options (yes, that's weasel-worded; I haven't yet switched to POWER because I don't want to pay 10x for my machines) I use them, for instance when I buy a phone I filter by whether it has an unlockable bootloader.
> The artificial constraint is either that the code (firmware) is closed, or both closed and signed.
Yes, agreed.
Back in the days when I used phone modems (USR Courier and Sportster) I actually flashed a cool custom firmware developed by an enthusiast hacker and there seemed to be no measures deployed to stop me from doing so.
IIRC at least USR Courier had Intel 80186 which was a full-fledged x86 CPU making the modem a real computer indeed.
I don't expect access to something running a minimal SoC with code burned to its ROM. I do expect it for something with a general OS that runs arbitrary code.
This can get tricky with modern devices. For example, pretty much every router runs some version of linux. Most do not give you root unless you flash your own firmware.