Once I had a professor who had a top secret clearance and did some government work. He couldn't reference this because it's never been unclassified. But in one of his courses, he had an image of these two circles aligned just like this when discussing a relevant topic, and I don't know if anyone in my section picked up on it.

Still kind of insane to think about the US government using underwater submarines or something to hack into the communications of US companies to spy on Americans and that not being, like, a bigger deal in 2013.

That :¬) face makes for a great custom emote in security-related channels.

It’s so funny so see a top secret label below what’s clearly a hastily scribbled diagram

>SSL Added and removed here!

And CloudFlare!

I used to have that as a shirt, but I think I lost it: https://philkast.com/2013/10/30/spying-tshirt.html

Please write this up somewhere!

See, I would have just put a WiFi extender near my bed...

Haha what? I simply must know more about how you achieved that!

Yeah or OBS.

I was surprised at the Photo Booth usage as well. I would have just recorded it with the QuickTime Player as if it were an iOS device.

Nintendo's networking is bad no matter what console somehow

Yeah also in general the WFC code is a bit dated and not very secure.

This actually reminds me of two very interesting bugs which used together basically make it so that you can play WFC games (basically just Mario Kart Wii, nowadays) as simple as changing the DNS settings on your Wii

1. Firstly, as long as you set a particular field in the certificate, it just is completely happy with an invalid cert. (This was fixed by the NWC library by the time it was released In Korea, notably, although this bug was present in DWC for a long while.

(Aside:

I actually suspect that this bug was present in the RVL SDK (used by games and such on the PPC), but also is caused by the same cause as the signing/Trucha bug[1]. While the latter is a IOS specific exploit, it wouldn't surprise me if the same code was used in both this and DWC (the networking library). Given that Mario Kart Wii has an associated IOS version of IOS36[2], but DWC code isn't part of IOS, my hunch is that they used either the same or similar validation logic OR both bugs were squashed a part of some security related cleanup.

I haven't actually gone through the reverse engineering effort to confirm this yet, but given that this doesn't work on the Korean version of MKW, which notably uses a later version of IOS and other libraries, my hunch is that those bugs are one in the same. The fix timing at least seems interesting to me. Anyway side note over.)

2. The networking library also has an RCE caused by a buffer overrun, basically from the first message it has a length that's unchecked and the DWC library blindly memcpys data from the packet. This is kinda why it's important to have some sort of patchset that fixes these bugs (because the operating system and libraries ship with the game and you can't update those except for in memory).

The culmination of this is all you have to do is

1. Change your DNS settings on your unmodified Wii to point to a specified DNS server.

2. Start Mario Kart Wii (probably, although some other games work too), open up WFC

So that the game...

3. Does a DNS lookup for the WFC server which intentionally links to a 3rd party server

4. Passes validation of a bad cert which intentionally sets one of the fields to a null value in order to make the Wii accept it

5. Receives a message that contains an exploit which patches the game in memory to fix the known RCEs and setup URLs to resolve to different domains instead of using the old WFC ones among other things (such as cheat reporting that is all client-side based, etc)

all so you can play Wii games (probably Mario Kart Wii) online 11 years after WFC shut down for good :)

[1]: https://wiibrew.org/wiki/Signing_bug

[2]: https://wiibrew.org/wiki/IOS36

The author should have just disabled TLS! It would have been perfectly reasonable under the circumstances, and then the website would have been fully Wii-hosted, no caveats!

It puts up a bit of a fight.

https://blog.infected.systems/status/ for a plaintext status of what the Wii's doing load-wise (if it's still up, updated every ~15 minutes according to the blog).

https://archive.is/6QvVA

Loads for me at the moment

OP's been preparing for this moment: https://blog.infected.systems/posts/2024-12-04-hugs-of-death...

The status page doesn't seem to be updating....

Unfortunately the time you get to the point of even valid HTTP responses it will look less like a SNES and more like whatever-you-plugged-into-a-snes-for-power. E.g. the original Family Computer Network System addon already had more RAM and CPU power than the original console it attaches to just to interface as a modem at all, let alone something "basic" like CGI.

The Wii is probably the first Nintendo console where all the hardware you need to do this is fully built in (though maybe the Nintendo DS, depending how much you're willing to try to get Linux + your server to fit in memory without plugging in a RAM expansion pack to the GBA slot).

if you can run a web server on a C64, you can in theory run one on the NES, but you'd have to find a way around the NES's relative RAM constraints

you can run a C64 OS on the NES because of the shared CPU features, with limitations: https://github.com/calcwatch/nes64

which means you can port C64 LUnix NG to NES by adding the Famicom Disk System, which adds more RAM: https://hackaday.com/2024/02/11/running-unix-on-a-nintendo-e...

LUnix NG comes with an experimental web server: https://github.com/ytmytm/c64-lng/blob/b76b0470e28ec20d08c37..., https://github.com/ytmytm/c64-lng/blob/b76b0470e28ec20d08c37...

So in theory you could serve HTTP 1.0 from a NES. ("to whom" would be the big next question)

For SNES - absolutely, if you get an FXPAK PRO and proxy over USB. It would be slooow, though, the transfer rate isn’t amazing (limitation on the firmware side, probably due to ancient USB standard?). Basically though - write incoming packets to a well known place in RAM, read another well known place in RAM for outgoing packets. The good news is that you have 12MB of ROM to work with. The bad news is that you really don’t want to transfer too much data at once, and you only get 128Kb of RAM. Not sure if you could do this easily with an NES, I don’t know if the everdrive supports RAM access over USB (it doesn’t on GB* which makes me super sad).

See also https://youtu.be/bsMV0EAF25o?si=Q6i8EH0HMMPa8xA3 for doing this (sorta) via serial over the controller ports (basically…)

Whatever you end up doing on the NES would end up not being a website anymore. You want to interface with joystick port 1? Not TCP/IP anymore. Whatever gateway you would use to connect to the custom protocol would have a lot more oomph than a NES.

I don't think so without significant work, NES has only 2KB of RAM and an 8 bit CPU without MMU or many niceties taken for granted in General Purpose OS's

I doubt you can go much further back than Fifth Gen (of consoles) or so

Working from the fact that the NetBSD sees the OHCI controllers which are on the Starlet's AHB this runs with AHBPROT disabled (as does most homebrew), so NetBSD can in theory not only interact with Starlet mailboxes (as any normal game), but can also do pretty much anything to it as the entire Starlet address space is R/W accessible from Broadway (which on the other hand makes interacting with Starlet pretty much irelevant for normal use, as you can interact with the hardware directly using normal drivers instead of going through IOS)

AFAIK, it's not, but it'd be fun to expose it and do silly things with it.

If you’re taking about the status page:

  So I put together a simple shell script that runs from the crontab every 15 min, outputting some system stats to a basic HTML file in the webroot.