Blog hosted on a Nintendo Wii | Hacker News Reader

Blog hosted on a Nintendo Wii

blog.infected.systems

622 pointsedent104 comments

For those unaware, the "SSL Added and removed here!" image is a reference to a diagram describing unencrypted communications between Google datacenters that leaked from the NSA in 2013 [1].

[1] https://arstechnica.com/tech-policy/2013/10/new-docs-show-ns...

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

Looks like a design interview round

I am convinced [1] most people can fall into handling anything with levity. You see the same thing happening in the medical field, and undoubtedly in more macabre organisations as well (see WW2 testimonies, for example).

[1] Unsourced learned experience, consider with a grain of salt.

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

Have a horizontal copy:

˙ ͜ʟ˙

>SSL Added and removed here!

And CloudFlare!

I know Cloudflare used to support unencrypted backends, but they encourage SSL on the origin machine too. It might be with a Cloudflare signed "origin cert" but it's SSL either way

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.

The hesitance around that time to prosecute political leaders who were obviously breaking the law is, I think, a big part of what lead to our current era of political leaders who are now, in effect, entirely above the law. James Clapper's "not wittingly" testimony[1], where he plainly and purposely lied under oath during a congressional hearing and received zero consequences, is another example where we showed we will not hold political leaders accountable for their actions. It became clear during that decade that the law has no teeth, so why should political leaders not break the law at every opportunity if it serves them? And here we are.

[1] https://www.npr.org/sections/thetwo-way/2013/07/02/198118060...

Watergate

Iran-Contragate

Iraq yellow cake

So many examples.

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

One of the coolest revelations to me, just looking at the status page [1] is that the Wii only had 88 MB of RAM - split between 24 MB built in to the SoC and 64 MB of GDDR3.

Given that this is the case, ntpd using 15% of the system memory means it was using about 13 MB of RAM - hardly a huge chunk by today's standards but not small either. I wonder if reducing the number of time servers would improve this much? On my system I can see I'm tracking about 9 servers from the debian pool.

Compare this to the XBox 360 which even at the time had 512 MB, it's really amazing how much they managed to squeeze out of such a tiny chip.

[1] - https://blog.infected.systems/status/

I'm thinking back to my first NetBSD boxes in 1995 which must have run in 4-8MB RAM and ran a mail server, a webmail server I wrote, and multiple users logging in to play MUDs and sit on IRC.

> Rebooting NetBSD reboots the whole console, and not just the NetBSD ‘app’, so you’ll find yourself back at the Wii Menu after any kernel patch or system upgrade.

This can be mitigated by installing Priiloader, and having it autoboot into either the Homebrew Channel or the NetBSD .dol file

I love this sorta stuff! I once had my blog hosted on a docker container on my Robot Vacuum. I switched back to a saner host when I started getting uptime alerts when the vacuum went under my bed and lost wifi signal!

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

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

Please write this up somewhere!

This reminds me of a project I saw more than 24 (!) years ago. Someone made a webserver for the GBA.

It seemed magical to me at the time and I still remember going to this site often to see updates (that's why I remember the URL).

Thankfully the Wayback Machine still has it:

https://web.archive.org/web/20030204043536/http://fivemouse....

Based on previous experience with Wii homebrew, you could probably circumvent the (expected) reliability issues of the smaller SD by swapping to a regular USB thumbdrive post exploit, ports are only 2.0 but you're bound by processor anyway

FYI - instead of Photo Booth you can use Quicktime Player and "create new movie recording". I believe that should fix the image flipping problem.

Yeah or OBS.

>I was doing this bit using a capture card and Photo Booth on macOS which doesn’t actually support disabling the image-flip on the video feed

Please use 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.

Performance is not bad. It's clear they aren't using Nintendo's TCP stack, as it was notoriously terrible on the Wii.

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

Nintendo's networking is bad no matter what console somehow

I had the awesome, yet terrible experience to work on an obscure Nintendo feature.

By networking, I am assuming you mean console stack... which I had experience with myself, and yeah... not great. But even more, their web services (more than 10 years ago at this point, hopefully better now) were so, so bad.

The thing that struck me then, and continues to seem true, is how much they just don't really seem to care and that they singularly focus at being good at innovating where it matters: games and differentiated hardware.

Young me thought they were silly for being so "behind the times". Older me respects it more.

I respect the prioritization. It doesn't actually need the best web services, it really only needs enough to play Mario kart online.

For a while they told you open all UDP ports for the Nintendo Switch. Now they just tell you to open 1024 to 65535.

Source for everybody not believing this:

https://en-americas-support.nintendo.com/app/answers/detail/... (Point 4 under "On a PC or smart device")

Interesting! Can you perhaps elaborate a bit more on what you saw at the time, in the sense of why it was so bad (Nintendo lawyers, look away)?

It has been awhile, but from what I remember Nintendo was extremely skimpy with the memory allocated to the TCP stack on the Wii meaning it couldn't open the window up hardly at all and had a tiny bandwidth delay product. This is why updating the system took absolutely forever, even when your local network and the Nintendo servers had ample bandwidth.

Beyond that the servers were also badly implemented and from what I understand they had to call in a third party company to install TCP PEPs[1] in front of the servers to get acceptable performance.

The Wii has ample compute power and memory to max out a Fast Ethernet (100Mbps) port, but due to the design decisions it was barely able to push 1Mbps in real life. This was becoming a problem as system updates were getting larger and the built-in "channel" games were moving beyond NES and SNES ports to actual third party indie titles that sometimes got rather large.

[1] https://en.wikipedia.org/wiki/Performance-enhancing_proxy

A sidenote is that Wii actually ran a separate operating system (nicknamed IOS by the community) in a dedicated ARM processor (Starlet), that was responsible for performing the majority of device input/output, including disk access, internal and external storage, and notably in this case, networking - the TCP/IP stack was implemented entirely there.

Besides running on a weaker CPU, IOS can access (for exclusive use) some of the main system memory, but it was usually about 12-16MB to not starve the actual games running on the main CPU (https://wiibrew.org/wiki/Memory_map), which can help explain why everything except for the actual games was so slow.

Originally, code running on the main PPC CPU could not access directly most of the IO related hardware at all (only GPU/display output and wired controllers - the bluetooth stack was also on IOS AFAIK, but the Wiimote drivers themselves were userspace), so even the Linux ports had to "proxy" some hardware access through the IOS, but later after reverse-engineering the full boot process, people were able to create a replacement IOS that could enable full access through a special register: https://wiibrew.org/wiki/MINI, enabling full-speed Linux ports, and since that functionality is about a decade old now, I would guess that the NetBSD port also takes advantage of that.

> The thing that struck me then, and continues to seem true, is how much they just don't really seem to care and that they singularly focus at being good at innovating where it matters: games and differentiated hardware.

You'd think they'd just admit that and outsource their network-related needs to a company that specializes in that sort of thing.

Innovating on games with multiplayer and then putting in a wifi chip that gives a ping of like 100ms at best seems like orthogonal goals.

Not to be a stickler, but the blog isn't actually FULLY hosted on the Wii until you move that Caddy instance to it or drop it :)

Nice work.

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!

lol rare wowfun sighting made me happy (hi from nacho@atmosphir)

got hugged.

Maybe the next post will say "Blog is hosted on a Nintendo Wii (running Varnish)"

Loads for me at the moment

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

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

The writer's post on the fediverse announcing this post gave me a good chuckle when it came across my feed.

https://infosec.exchange/@alexhaydock/114377262481451962

> https://blog.infected.systems/posts/2025-04-21-this-blog-is-...

Didnt think I'd ever be id'd so accurately on a blog about running a webserver on a WII.

https://web.archive.org/web/20250421184947/https://blog.infe...

Really impressed by how low the load average is (0.06 @15 min).

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

Depending on how often you are refreshing - the status page only updates every 15 minutes:

> 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.

I checked it again and it seems to update every 15 minutes.

this is pure beauty. Do you think something like this can be done on a NES? like a simple CGI website

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).

> The Wii is probably the first Nintendo console where all the hardware you need to do this is fully built in

Even though accessories were required, you could probably do this with both the N64 Disk Drive or GameCube network adapter. Both were network interfaces that still dispatched to the underlying system.

The N64 Disk Drive [1] would be a fun case, because the storage medium is a glorified floppy disk drive. It does connect over a modem, so there'd be some fun middleware.

The Super Nintendo had a network adapter as well, and both the NES and SNES [2] had satellite networking adapters in Japan. IIRC, there was also a network adapter for the Game Boy. I'm not sure how or if those would work, or how much control was surrendered to the hardware/software of the network adapter itself to let it do all the driving.

[1] https://en.wikipedia.org/wiki/64DD

[2] https://en.wikipedia.org/wiki/Satellaview

Are you sure the Satellaview was available for the Famicom (NES)?

I was wrong about the satellite integration [1]. It was dial-up.

I'm almost certain I remember a similar effort for the Game Boy Pocket, though it might not have entered the market.

[1] https://en.wikipedia.org/wiki/Family_Computer_Network_System

The Genesis also had Sega Channel (IIRC?).

This reminds me SO much of Atari's "Graduate Computer" attachment for the 2600.

Unfortunately, I can't find an accessible link from where I am right now. Maybe when I get back home...

Some links for the curious:

- http://www.atarihq.com/museum/2678/graduate.html

- https://atarimuseum.ctrl-alt-rees.com/videogames/consoles/26...

Thank you for stepping in, Evan!

My original post was from work, and when I tried to find a reference, I was blocked from following any links! Think they recently instituted a policy...

So I finally do the lookup from home, and what do I find at the bottom of the first page, but a link to YOUR REPLY!

We're Google famous!

Yeah, the DS probably is the first one that has enough inbuilt support since it has support for Wi-Fi out of the box although Linux seems a bit heavyweight for this perhaps(?)

DSLinux exists but you need the RAM expansion cartridge. from what I found it supports networking but you've only got 8MB minus the space used by the system. and an ancient binary-only toolchain to wrangle with

4 megabytes* ought to be enough for anybody, and if you're any depth into DS homebrew, you probably have a 3in1 which expands it to 8 megabytes.

Can it run Linux? Ehhh....... can it run a web server? Absolutely.

* we don't talk about using the 0.6MB VRAM for purposes other than video (even though it should work fine).

DSLinux absolutely runs in 4 MB (i.e. w/o a RAM expansion pack), it's just going to take a bit of work to also fit the web server + whatever CGI they wanted without a pack.

The EZ-Flash V 3-in-1 actually added a whopping +16 MB (128 Mb) of PSRAM! Growing up I only ever had the +8 MB pack from Opera... what a weird bit of history that browser port was :).

I believe DSLinux is uCLinux, not real Linux. And it has to be, because there's no MMU.

Is that PSRAM? For some reason I thought the bigger storage was Flash.

I wouldn't say uClinux was any less Linux, over time its features even merged to mainline in the 2.x series, including the ability to run MMU-less in version 2.5.46 https://lwn.net/Articles/14823/

The EZ-Flash V 3-in-1 also had either 64 MB or 128 MB of NOR flash (depending on the revision) in addition to the 16 MB of PSRAM. There was also some battery backed SRAM for save data.

This leads to an interesting philosophical debate about where the line to "cheating" is. I'd imagine the NES is more than capable of handling HTTP. I own a small managed network switch with a Web UI (and CGI) all running on an 8051 built into the switch ASIC, and if that can do it, it doesn't seem like such a far fetch that the NES can. The hard part is storage and I/O.

This is purely theoretical, but a 6522 could be used to bitbang SPI, opening the possibility of adding an SD card and Ethernet controller (with a chip like the Wiznet W5500). Add a small amount of SRAM (~16/32Kbit) and a loader ROM, and you'd be able to make the NES into a workable general purpose computer using only the cartridge slot. If needed, one could steal an interrupt from the expansion slot.

Admittedly, this could still be considered "cheating" because the W5500 has a built-in TCP/IP stack, but personally I would feel comfortable saying the NES is hosting the site.

Bitbanging SPI with the 6522 -- https://wilsonminesco.com/6502primer/potpourri.html#BITBANG_...

I feel like this would definitely be possible. I was reminded of https://mitxela.com/projects/kiloboot, which uses an ENC28J60 for the ethernet stuff. I feel like you could probably quite easily bitbang SPI, given it's quite a forgiving protocol, just dedicate a couple of addresses in the memory space to interact directly with the bus (maybe with a separate shift register chip if you want to make things a bit easier). If you give up writing anything to the screen, I'd imagine you could just spin until something happened on the ethernet side, then read the requested path, pull some data off the ROM that corresponds to that path and send it back again

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

You would have to burn a cart that contained the webpage and TCP stack, as well as having the ethernet hardware, but there are tricks you can do to reduce the memory requirements. It's not going to be able to handle more than a packet or two at a time, but I've seen TCP stacks squeezed onto really low end hardware. Obviously you won't be able to open much of a TCP window so performance will be lousy, but it's a 1.8Mhz CPU so that was always going to be the case. Just don't have any misconceptions about being able to run TLS on it. Remember that TCP was developed on machines that did not have a lot of memory or even CPU cycles.

An Atari 2600 might be a bridge too far, but a NES should be able to do it.

Fair enough, seems a lot simpler than what I had in mind with expansions and custom software, but also a far cry from OP's "flash" a general purpose OS and more or less get to working

You would be surprised with what a Jupiter Ace could do with few KB of RAM. Add a external module for serial <> PPP and the fun begins.

Funny how that works. It's almost impossible on fifth gen but trivial on sixth gen (at least on the Xbox, which pretty much was a PC).

All the mainstream 6th gen consoles had first party support for wired ethernet; although only the Xbox had it built in (well, the slim ps2 had it built in too). I'd expect they've all served web pages at one time or another.

5th generation could probably make it happen, but without ethernet, you're looking at a modem or serial interface, and in today's world that's almost certainly talking to something else in your house that's a better host. :P Wikipedia categorizes the Apple Pippin as 5th gen, and it's more or less a Mac with a weird pinout for the PCI slot, so I'd guess it's the easiest to get ethernet with; without resorting to something that has more smarts than the 'host'

Even with Ethernet, aren't you're plugging the console into a switch that can probably serve webpages as well as the console?

Most of my switches are unmanaged, so probably not. Maybe the dsl or cable modem or whatever can serve pages, but especially if it's isp owned, it might not be easy to.

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.

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)

I don't know if this is cheating, but there were a few NES games that had extra RAM on the cartridge. Pretty easy to do as the cartridge slot directly breaks out the data and address lines from the CPU.

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…)

Ohh https://github.com/mupfdev/SNESoIP exists too

Very cool and fun. Regarding power draw, later Wii revisions improved this. My OG Wii runs much "hotter" than my later one.

Hey, if anyone wants Wii colo on public address space in New York, get in touch. We gotchu.

https://wtfhost.onefreecomputer.org

We also have android dedis.

Anyone knows if the Starlet co-processor is accessible from NetBSD?

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

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)

Cool, but I sense a slowdown!

edent, my question is what tool did you use to make the Wii ASCII art?

incredible! great job!

Interesting how the times don't update with each refresh... CDN?

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.

It only updates every 15min which is why you’re getting stale data.

this is so dope

Try using ZZ to exit vim ;)

...Then the hardest part is only remembering what layout you're on if you regularly swap keyboard layouts between QWERTY and QWERTZ

..or wait are you even on a keyboard there?

Are you still looking for PS2 Linux?

beautiful

Interesting work! Definitely deserved the #1 spot on HN

Reply on news.ycombinator.com