まじかよ！Wiiでブログ運用とか凄すぎ！セキュリティは大丈夫なの？

FYI。Photo Boothの代わりにQuicktime Playerで「新規ムービー収録」を使えば、画像の反転問題を解決できると思うよ。

うん、OBSでもいいね。

＞macOSのPhoto Boothでキャプチャカード使ってたんだけど、ビデオフィードの反転を無効にできなかったんだよね。
OBSを使って。

Photo Booth使ってたのが意外だった。iOSデバイスみたいにQuickTime Playerで録画すると思ってた。

パフォーマンスは悪くないね。NintendoのTCPスタックを使ってないのは明らかだ。Wiiのはマジで酷かったから。

Nintendoのネットワーキングは、どのゲーム機でもなぜかイマイチなんだよね。

ニンテンドーのマイナーな機能に関わる、最高にひどい経験をしたことがあるんだ。
ネットワーキングっていうのはコンソールスタックのことだと思うけど、それなら経験あるよ…うん、マジで良くない。ウェブサービスも（10年以上前だから、今はマシになってるといいけど）マジで酷かった。
当時も今も思うのは、彼らはあんまり気にしてないみたいで、ゲームと差別化されたハードウェアでイノベーションを起こすことに集中してるってこと。
若い頃の俺は「時代遅れ」だって思ってたけど、今はリスペクトしてる。

昔はNintendo Switchのために全てのUDPポートを開放しろって言ってたよね。今は1024から65535を開放しろって言うだけになった。

信じない人のためにソース：https://en-americas-support.nintendo.com/app/answers/detail/…
(「PCまたはスマートデバイスで」の4番目のポイント)

＞当時も今も変わらないのは、彼らはあまり気にしていないように見えるってこと。ゲームと差別化されたハードウェアでイノベーションを起こすことに集中してるんだよね。＜br>そういうことを専門とする会社にネットワーク関連のニーズをアウトソースすればいいのにって思うよね。

優先順位を尊重するよ。最高のウェブサービスは必要なくて、マリオカートオンラインをプレイするのに十分であればいいんだから。

興味深いね！当時何がそんなに酷かったのか、もっと詳しく教えてくれないかな？(Nintendoの弁護士は読まないで)

WiiのTCPスタックに割り当てられたメモリがすごく少なかったから、ほとんどウィンドウを開けなかったし、bandwidth delay productも小さかったんだよね。だから、ローカルネットワークとNintendoのサーバーに十分な帯域幅があっても、システムのアップデートに時間がかかったんだ。
サーバーの実装も悪くて、TCP PEPs[1]をサーバーの前に設置して、なんとか許容できるパフォーマンスを得たらしい。
WiiはFast Ethernet(100Mbps)ポートを最大限に活用できる計算能力とメモリを持ってるのに、設計上の問題で実際には1Mbpsも出せなかったんだ。システムのアップデートが大きくなるにつれて、この問題が深刻になってきてたんだよね。
[1] https://en.wikipedia.org/wiki/Performance-enhancing_proxy

Wiiは専用のARMプロセッサ(コミュニティではIOSと呼ばれてる)で別のOSを実行してて、ディスクアクセス、内部/外部ストレージ、特にネットワークなど、デバイスの入出力の大部分を担当してたんだ。TCP/IPスタックは完全にそこで実装されてたんだよね。
IOSはメインCPUより弱いCPUで動作するけど、メインシステムのメモリの一部に(排他的に使用するために)アクセスできたんだ。でも、メインCPUで実行されてるゲームを邪魔しないように、通常は12〜16MBだったんだ(https://wiibrew.org/wiki/Memory_map)。
メインPPC CPUで実行されてるコードは、ほとんどのIO関連ハードウェアに直接アクセスできなかったんだ(GPU/ディスプレイ出力と有線コントローラーだけ)。だからLinuxポートもIOSを介してハードウェアアクセスをプロキシする必要があったんだ。でも、完全なブートプロセスをリバースエンジニアリングした後、特別なレジスタを介してフルアクセスを可能にする代替IOSを作成することができたんだ(https://wiibrew.org/wiki/MINI)。

＞当時も今も変わらないのは、彼らはあまり気にしていないように見えるってこと。ゲームと差別化されたハードウェアでイノベーションを起こすことに集中してるんだよね。＜br>マルチプレイヤーゲームでイノベーションを起こして、pingが100msくらいのwifiチップを搭載するのは、目標が矛盾してるように思える。

WFCのコードはちょっと古いし、セキュリティも甘いんだよね。WiiのDNS設定を変更するだけでWFCゲーム(マリオカートWii)をプレイできるバグがあって…。証明書の特定のフィールドを設定すると、無効な証明書でもOKになっちゃうんだ。(これは韓国版で修正済)
もう一つは、ネットワークライブラリにバッファオーバーランによるRCEがあって、最初のメッセージの長さをチェックせずにデータをコピーしちゃうんだ。
だから、DNS設定を特定のDNSサーバーに変更してマリオカートWiiを起動するだけで、WFCサーバーへのDNSルックアップが行われ、不正な証明書の検証をパスして、エクスプロイトを含むメッセージを受信してゲームをパッチできるんだ。
WFCが終了して11年経っても、Wiiのゲーム(たぶんマリオカートWii)をオンラインでプレイできるんだよ。

細かいことを言うようだけど、CaddyインスタンスをWiiに移動するか削除するまでは、ブログは完全にWiiでホストされてないよ！
ナイスワーク。

作者はTLSを無効にすればよかったのに！そうすれば、完全にWiiでホストされたウェブサイトになったのに！

lol、rare wowfun sightingで嬉しくなった(nacho@atmosphirよりこんにちは)

😊

この投稿についてfediverseでライターが告知してたんだけど、それがフィードに流れてきてマジ笑った。

ハグされた。
もしかしたら次の投稿は「Blog is hosted on a Nintendo Wii (running Varnish)」って言うかもね。

ちょっと抵抗してるね。
https://blog.infected.systems/status/ でWiiがどんな感じかplaintextで見れるよ(もし動いてたら。ブログによると15分ごとに更新されるらしい)。
https://archive.is/6QvVA

今のところちゃんと表示されるよ。

OPはこの瞬間のために準備してたんだね:
https://blog.infected.systems/posts/2024-12-04-hugs-of-death…

＞https://blog.infected.systems/posts/2025-04-21-this-blog-is-…
WIIでウェブサーバーを動かすブログでこんなに正確に特定されるとは思わなかった。

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

ロードアベレージがマジ低い(15分で0.06)のすごい。

ステータスページ、更新されてないみたいだけど…

更新頻度によるけど、ステータスページは15分おきにしか更新されないよ。
＞簡単なシェルスクリプトを組んで、crontabから15分おきに実行して、システムの統計情報をwebroot内の基本的なHTMLファイルに出力してるんだ。

もう一度確認したら、ちゃんと15分おきに更新されてるね。

これはマジですごい。NESでも同じようなことってできると思う？例えばシンプルなCGIのウェブサイトとか。

残念ながら、有効なHTTPレスポンスができるようになる頃には、SNESというより、SNESに何かを接続したような状態になると思う。例えば、オリジナルのFamily Computer Network Systemのアドオンは、モデムとして機能するためだけでも、元のコンソールよりも多くのRAMとCPUパワーを搭載していた。ましてやCGIのような「基本的な」ことなんてね。
Wiiはおそらく、これに必要なハードウェアがすべて内蔵されている最初のNintendoコンソールだよ（Nintendo DSでも、RAM拡張パックをGBAスロットに接続せずにLinux + サーバーをメモリに収めることができるかどうかによっては可能かも）。

これは「チート」の線引きに関する興味深い哲学的な議論につながるね。NESはHTTPを処理できるだけの能力があると思う。私はWeb UI（とCGI）を備えた小型のマネージドネットワークスイッチを持っていて、それはスイッチASICに組み込まれた8051で動作している。それができるなら、NESでも不可能ではないと思う。難しいのはストレージとI/Oだ。
これは純粋に理論的な話だけど、6522を使ってSPIをbitbangすれば、SDカードとEthernetコントローラー（Wiznet W5500のようなチップ）を追加できる可能性がある。少量のSRAM（〜16/32Kbit）とローダーROMを追加すれば、カートリッジスロットだけでNESを汎用コンピュータにできる。必要に応じて、拡張スロットから割り込みを奪うこともできる。
W5500にはTCP/IPスタックが内蔵されているから、「チート」とみなされるかもしれないけど、個人的にはNESがサイトをホストしていると言ってもいいと思う。
6522を使ったSPIのBitbangingについてはこちら：https://wilsonminesco.com/6502primer/potpourri.html#BITBANG_…

これは絶対に可能だと思う。https://mitxela.com/projects/kiloboot を思い出した。これはEthernetにENC28J60を使ってる。SPIのbitbangはかなり簡単にできると思う。メモリ空間にいくつかのアドレスを割り当ててバスと直接やり取りするようにすれば（もっと簡単にするために、別のシフトレジスタチップを使ってもいい）。画面への書き込みを諦めれば、Ethernet側で何かが起こるまで待機して、リクエストされたパスを読み取り、そのパスに対応するデータをROMから取り出して送り返せばいい。

＞Wiiはおそらく、これに必要なハードウェアがすべて内蔵されている最初のNintendoコンソール
アクセサリーが必要だったとしても、N64 Disk DriveかGameCubeネットワークアダプターでもできたかもしれない。どちらもネットワークインターフェースで、システムにディスパッチしてた。
N64 Disk Driveは面白いケースだね。ストレージメディアはフロッピーディスクドライブのようなものだし。モデムで接続するから、ミドルウェアが必要になるだろうけど。
Super Nintendoにもネットワークアダプターがあったし、NESとSNESには日本で衛星ネットワークアダプターがあった。Game Boyにもネットワークアダプターがあったと思う。それがどう機能するか、ハードウェア/ソフトウェアにどれだけの制御を委ねるかはわからない。
[1] https://en.wikipedia.org/wiki/64DD
[2] https://en.wikipedia.org/wiki/Satellaview

衛星統合については間違ってた。[1]ダイヤルアップだった。
Game Boy Pocketでも同じような試みがあった記憶があるけど、市場に出なかったかもしれない。
[1] https://en.wikipedia.org/wiki/Family_Computer_Network_System

GenesisもSega Channelあったよね確か？

これAtari 2600のGraduate Computer思い出すわー。残念ながら今リンク見つけられないんだよね。家帰ったら探してみる。

参考リンクだよー。
・http://www.atarihq.com/museum/2678/graduate.html
・https://atarimuseum.ctrl-alt-rees.com/videogames/consoles/26…

Evanさん、フォローありがとう！仕事中に書いたから、リンク全部ブロックされちゃって参照できなかったんだよね。ポリシー最近変わったみたいで…。家から見たら、トップページの一番下にあなたの返信が！Googleで有名人だ！

DSが一番最初からWi-Fi対応してるから、色々サポートされてるのかもね。Linuxはちょっと重いかな？

DSLinuxがあるけど、RAM拡張カートリッジが必要。ネットワーク使えるみたいだけど、システムが使う分を除くと8MBしかないんだよね。ツールチェインも古いし。

4MBあれば十分でしょ。DSのhomebrewやるなら、3in1持ってれば8MBに拡張できるし。
Linux動くかって？Webサーバーなら絶対動くよ。
VRAMは置いといて。

DSLinuxはRAM拡張なしの4MBで動くよ。WebサーバーとかCGIとか色々入れるのは大変だけどね。EZ-Flash V 3-in-1は16MBのPSRAM追加できたんだよ！Operaのブラウザ移植版とか懐かしい。

DSLinuxってuCLinuxだよね？MMUないから普通のLinuxじゃないと思う。PSRAMだったっけ？Flashだと思ってた。

uClinuxもLinuxだよ。MMUなしで動く機能も2.x系でmainlineにmergeされたし。
> https://lwn.net/Articles/14823/
EZ-Flash V 3-in-1は、16MBのPSRAMに加えて、64MBか128MBのNOR flashも搭載してた（revisionによる）。バッテリーバックアップSRAMもあったね。

C64でウェブサーバー動かせるなら、理論的にはNESでもいけるはずだけど、RAMがネックだな。NES64ってプロジェクトでC64 OSをNESで動かしてる例もあるし。Famicom Disk System足せばRAM増えるから、C64 LUnix NGを移植できるかも。LUnix NGには実験的なウェブサーバーも入ってるし。つまり、NESでHTTP 1.0サーバーを立てるのも夢じゃないかもね。誰が使うんだって話だけど(笑)。

裏技的な話だけど、NESのカートリッジにRAMを増設してるゲームもあったりするんだよね。カートリッジスロットからCPUのデータ線とかアドレス線が直接出てるから、割と簡単にできるんだ。

SNESならFXPAK PRO使ってUSB経由でプロキシできるよ。ただ、激遅だけどね。転送速度がイマイチなんだよね(ファームウェア側の制限かな？)。RAMの特定の位置にパケットを書き込んで、別の位置からパケットを読み出すみたいな感じ。ROMは12MBもあるけど、RAMは128KBしかないのが難点。NESで同じことができるかは不明。everdriveがUSB経由のRAMアクセスに対応してないんだよね(GB*では非対応で残念)。コントローラーポート経由でシリアル通信する方法もあるみたい。

SNESoIPってのもあるんだね。

NESで何かやったとしても、それはもうウェブサイトとは言えないんじゃないかな。ジョイスティックポート1と通信したいなら、TCP／IPじゃないし。カスタムプロトコルに接続するためのゲートウェイは、NESよりも高性能になっちゃうだろうし。

NESはRAMが2KBしかないし、MMUもない8bit CPUだし、かなり厳しいと思うよ。第5世代(のゲーム機)よりも前の世代は難しいんじゃないかな。

ウェブページとTCPスタックを書き込んだカートリッジを用意して、イーサネットのハードウェアも用意する必要があるけど、メモリ要件を減らすための工夫はできるよ。一度に処理できるパケットは少ないだろうけど、低スペックなハードウェアでもTCPスタックを実装してる例はあるし。TLSは無理だろうけど。TCPはメモリやCPUサイクルが少ないマシンで開発されたんだから。Atari 2600は厳しいかもしれないけど、NESならできるはず。

拡張とかカスタムソフトウェアを使うよりもシンプルだけど、OPが言ってるような「汎用OSを焼いて、すぐに使えるようにする」のとは程遠い気がするな。

Jupiter Aceは少ないRAMで色々なことができたから、あなどれないよ。シリアル<>PPPの外部モジュールを追加すれば、もっと面白いことができる。

面白いことに、第5世代ではほぼ不可能だけど、第6世代(特にXbox。ほぼPC)では簡単なんだよね。

6th genの主要なゲーム機は全部、有線Ethernetをサポートしてたんだよね。Xboxだけが標準装備だったけど(PS2スリムもそうだったか)。どれもウェブページを表示できたんじゃないかな。5th genでもできるかもしれないけど、Ethernetがないとモデムかシリアルインターフェースになるから、今だと家の別の高性能なホストに接続する方が確実だよね。Apple Pippinは5th genらしいし、Macみたいなもんだから、Ethernet接続は一番簡単だと思うよ。変なピン配置のPCIスロットだけどね。

うちのスイッチはほとんどがアンマネージドだから、無理だね。DSLとかケーブルモデムならできるかもだけど、ISPが管理してると難しいかも。

めっちゃクールで面白いね。消費電力についてだけど、後のWiiは改善されたみたい。初期のWiiは後期のより“熱い”んだ。