You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
Separate from this, system and title integrity (i.e. that you aren't using warez IOSes or a "pirated" HBC) is checked by a whole bunch of code (that is much more obvious), and the result stored in a Graphics Quantization Register, read by doing bit manipulation on a stored float.pic.twitter.com/o2aDrqsPTs
Of course addresses are obfuscated in similar ways to what @JonTt did, by breaking them up into chunks and shifting/offsetting them. And one of the potential outcomes is... good old upside down screen.pic.twitter.com/w47k58NEk0
At an outer layer, in the executable packer, we depend on a hardware bug that corrupts uncached MEM2 writes to generate an AES key, which is also mixed with the code itself (antitampering) and a check that we're running from an address in range. This is what breaks Dolphin.pic.twitter.com/0PNgj03uTb
The installer has many checks including custom ARM code that reads titles and checks signatures, but the best is the Ioctl Fun Machine, which sends random ioctls to IOS and compares timing against what we expect for a standard retail IOS. Also has encrypted functions.pic.twitter.com/qPqpPhhX9t
Also, if you try to install HBC/BootMii on a devkit, it just installs them without using any exploits, using legitimate devkit signing keys (which are published with the SDK and thus leaked a long time ago).pic.twitter.com/OWeYMSsFHj
Also we may or may not be sending some strings to devkit/debugger print vectors.pic.twitter.com/qV41v4bmLi
One of the supported IOS exploits is hidden in the middle of the Ioctl Fun Machine. A simpler version of this kind of obfuscation/misdirection was featured in the very first Homebrew Channel Installer that didn't rely on the signature validation bug.pic.twitter.com/wAiquwVdOu
We're not all evil, though. While the installer stops/refuses to work in some cases, HBC never does (not completely). We considered the possibility of someone messing up their system so badly that an existing (broken) install of HBC is the only way to fix it.
Under certain circumstances, HBC will show a scam warning screen and stop working. But it won't really: it lets you proceeed after one hour. Similarly, even in "crashy mode", you can get an app loaded some of the time.
Basically we *hate hate hate* bricks. All of this protection is *also* to ensure the system is in a sane state for installation, so we know it'll work. We do many sanity checks too, *much* more paranoid than Nintendo's update code. We *never* want to be responsible for a brick.
Switching gears, the BootMii boot2 update code contains a functional (not line-by-line) duplication of Nintendo's boot1 loader code, that it uses to confirm the exact layout and state of the existing boot2 installed on the Wii.pic.twitter.com/pUg93gyVwH
We validate that the NAND has two valid, clean, working, hashed-OK, known version copies of boot2. Then we patch BootMii in (in RAM) and hash-check. We run write tests on empty boot2 blocks to ensure they are usable. Only then do we commit and write BootMii to empty blocks.pic.twitter.com/zhcU0L6uBT
The installer is designed to use unused NAND blocks for the install, and, as the last step, writes a newer-generation blockmap that marks the original boot2 blocks as bad. Thus, there is zero failure window (you can power off at any time), and uninstallation = erasing blocks.pic.twitter.com/zbAI1zgivu
Nintendo's boot2 update code is so terribad it writes the new bootloader before even verifying its signature (and leaves it clobbered if the sigcheck fails). Combined with a plaintext HTTP CDN, that leaves the TCP checksum as the only thing preventing a corrupted first copy.
And since shit happens and the second copy could become corrupted, this is how Nintendo managed to brick a good fraction of Wiis, hacked or not, when they pushed a dummy version bump of boot2 as an attempt at uninstalling BootMii.
To my knowledge, we have never bricked a Wii. Ever. With over 6 million users. The closest we came, there was a bug in the boot2 code with bad block handling. Since we'd checked that there was a working second copy, the person who hit it could still boot.
Subsequent runs of the installer detected the bad state and refused to do anything. So we got a bug report, and no consoles were harmed.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
