depending on the nintendo system in question, there may or may not be copyrighted binaries involved.
Regardless, it is assuredly an EULA violation (since ninty sells you a console under the business model that you will then buy licensed games, and they make their REAL money collecting game license fees per sale.) and depending on the enforcibility of that in your region, it may or may not have teeth.
In general:
NES uses a hardware lockout chip that has STILL not been effectively defeated. (Rather, official lockout keys are removed from dead/discarded NES carts, and installed in the supermulticart flash offerings.)
SNES does not have a copy protection that I know of...
N64 same story
Game Cube uses a special disc, and signature enforcement. An early exploit was discovered in a game that was able to download updated copies of the main game binary from the internet, by masquerading as the game's server back-end with a special program. After that, additional exploits were found in the game disc loader firmware itself, allowing disc swap discs to be produced by action replay and pals. These discs could be used to load homebrew.
Wii uses a special disc format, along with digital signature enforcement. It is defeated by reintroducing the Trucha bug (IOS 58, iirc?) which allows the console to self-sign binaries for execution, which opens the door to installation of specially modified IOS handlers that effectively disable that signature enforcement, opening the system wide.
Wii-U uses a special disc format and digital signature enforcement, but has a better security model. It is defeated using a browser exploit which smashes the stack and allows unsigned code to run. This opens the door. Additionally, a hash collision was calculated on a handful of eshop titles, allowing a "Trojanized" eshop title to be used to exploit the console and execute unsigned code. On the vWii side, the same attacks as used on a Wii apply.
Nintendo Switch: Early revisions of the switch console had a vulnerable boot loader baked into the Tegra cpu itself, that could have its stack smashed, and execution jumped, by being fed a special (very very large) USB stack setup packet over the USB bus. This allowed the boot process to be hijacked before nintendo's Horizon OS could even load. In order to deliver the packet, the device has to be in a special recovery mode, called RCM, that is normally intended for factory refurbishment and repair. In order to put a stock console into that mode, an "RCM Jig" (two wires that touch two contacts on the right joycon rail) has to be inserted which causes a dead short, causing the unit to panic, and enter RCM. Once exploited however, changing a single byte in the boot0 binary causes the system to panic as well, and enter RCM. (this is what "autoRCM" actually is.) There are many modchips available that work in conjunction with autoRCM to inject the large setup packet that can be installed directly inside the switch, allowing for mostly painless operation. (Many early prototypes were built using the trinket M0, and have open firmwares, if you want to DIY. I remember that I thought it was quite funny that the GBATemp forum population made working modchips before china could.) Once the console's boot process is exploited, a custom firmware is loaded. (Such as ReiNX, SXOS, and pals.)
Nintendo of course, was "Very upset" that the switch could be hacked into in this fashion, and worked with AMD to fix the overflow in the RCM mode on subsequent models. All units in stores today are patched to prevent this exploit, and cannot run homebrew. (I happen to have an exploitable console...)
Author
Topic: The small random questions thread [WAAAAAAAAAAluigi] (Read 676399 times)