What is actually very(at least to me) surprising is how relatively non-gnarly the hack is.
As anyone who has spent some time poking at cellphones and tablets can tell you; the wonderful world of cryptographically locked bootloaders is a reality; and a fairly common one.
Based on the directions for performing the hack, it appears that Nintendo used a slightly oddball roll-your-own arrangement for the device’s filesystem(possibly with a bit of obfuscation there for anti-tamper purposes, possibly just basic ‘nobody is ever going to see it, so as long as it works’ dirty-hacks-on-a-deadline’ stuff); but the technique for dumping the device’s firmware and re-flashing the modified firmware image uses exactly the same tools used for USB-debugging most Allwinner SoCs(which, because Allwinner is one of those ‘GPL compliance with Chinese characteristics’ shops, kind of suck; but the ones that support the NES Classic don’t differ from the ones you use for every other cheapo tablet, android-TV-streaming-puck, or phone based on one of their SoCs); and the NES Classic boots without complaint even after its firmware has been modified(which would break any cryptographic signatures or checksums).
I found this so surprising that I’ve been trying to do some more digging: The ‘R16’ SoC used in the Classic is, apparently, a relabled A33; and the datasheet for that part shows no mention of efuse storage or ‘secure boot’ support. A variety of other SoCs in Allwinner’s lineup do have those features; but the R16 appears to only have a basic crypto accelerator block.
It’s a trifle astonishing, especially given that Nintendo has been attempting hardware-enforced restrictions since CIC/10NES back in 1983; but unless I’m missing something, they appear to have pinched pennies so hard on this product that it actually lacks the common(and often very effective) bootloader lockdown seen in even relatively cheap gear.