Chapter 11

Wi-Fi とネットワークをつつく — IP が喋る機器

この章のゴール.
Wi-Fi や有線 LAN を持つ組み込み機器を、ネットワーク側から観測・テストする—— 何のポートを開け、どんなプロトコルを喋り、どう振る舞うかを、スキャン・パケットキャプチャ・API 叩きで外から確かめられるようになること。
この章で使う既出の用語（定義は各リンク先）. オラクル（01 章 8 節）、デバッグポート（01 章 2 節）、SDR（02 章 4 節）、I²C（06 章 1 節）、SPI（06 章 1 節）、接続（09 章 2 節）、ファジング（10 章）

1. ネットワーク機器という広い面

Wi-Fi が載った瞬間、機器はIP ネットワーク上のサーバ／クライアントになる。BLE と違って、ここには成熟した道具（nmap、Wireshark、curl、mitmproxy）が山ほどあり、PC 側の経験をそのまま流用できる。反面、面（テスト対象）が急に広がる: TCP/UDP ポート、HTTP API、MQTT、mDNS、クラウド連携……。生成 AI 製ファームは「とりあえず動くサーバ」を建てがちで、余計なポートや無防備な API が残りやすい。

図11-1　ネットワークテストの 4 段階。

2. まず地図を描く — スキャンと発見

対象がどこにいて何を開けているかを最初に把握する。

IP を見つける: DHCP のリース、ルータの一覧、mDNS/Bonjour（avahi-browse）、arp-scan
開いているポート: nmap（例: nmap -sV <ip>）でポートとサービス種別・バージョンを推定
想定外のポート: デバッグ用の telnet、隠れた HTTP、開発サーバが残っていないか
mDNS/SSDP のサービス広告: 機器が自分から「こんな機能あります」と広告していないか

nmap -sV -p- 192.168.1.50      # 全ポートを走査してサービス版を推定
avahi-browse -art              # mDNS で広告されているサービスを列挙

3. 会話を覗く — パケットキャプチャ

I²C/SPI をロジアナで覗いた（06 章）のと同じ発想を、ネットワークで行うのがパケットキャプチャである。

Wireshark / tcpdump: 流れるパケットを丸ごと捕まえて中身を読む。平文か暗号化か、何を送っているか
どこで捕るか: PC を同じ Wi-Fi に置く、ミラーポートのあるスイッチ、あるいは PC を中間に置く（次節）
観測点として: 「ボタンを押したら何が送られるか」「起動時にどこへ繋ぎに行くか」を可視化

図11-2　中間者としてのパケット観測・注入。

平文で秘密（トークン、測定値）が流れていないか、想定外のサーバ（解析用の外部ホスト）へ繋いでいないか——キャプチャは設計ミスをよく暴く。

4. 間に割り込む — プロキシと中間者

HTTP/HTTPS API を叩く機器なら、PC を中間に置いて通信を観測・改変できる。

mitmproxy: HTTP/HTTPS を透過的に中継し、リクエスト／レスポンスを閲覧・書き換え。機器が証明書検証をサボっていれば HTTPS も丸見え（=それ自体が不具合、17 章）
改変で試す: サーバ応答を異常値・エラー・巨大レスポンスに差し替えて、機器がどう振る舞うか（サーバ側障害の模擬、15 章の HIL 的発想）
DNS を握る: 機器が繋ぐ先を自前サーバに向け、クラウドをまるごと模擬（フェイク）する

中間者（man-in-the-middle） とは、通信の当事者の間に割り込んで内容を読む／書き換える立場のこと。攻撃手法の名だが、テストでは正当な観測・注入の手段として使う（自分の機器を、自分の PC 経由で通す）。

5. API を直接叩く

機器が REST API や WebSocket、MQTT を提供するなら、それは外から呼べるテスト面である。

REST: curl／Python requests で叩く。認証なしで叩けるエンドポイント、境界値、不正 JSON（ファジング、16 章）
MQTT: mosquitto_sub/mosquitto_pub でトピックを購読・publish。誰でも購読できる秘匿トピックがないか
WebSocket: websocat で接続し、フレームを送り込む
認証・認可の抜け（他人の ID を指定できる、権限昇格）——ネットワーク機器で最も多い欠陥

import requests
r = requests.get("http://192.168.1.50/api/status", timeout=3)
assert r.status_code == 200 and r.json()["state"] == "idle"   # オラクル
requests.post("http://192.168.1.50/api/cmd", json={"n": 10**9})  # 境界値攻め

6. 接続の乱れに耐えるか

BLE（10 章）と同様、ネットワークの異常への耐性が重要。

Wi-Fi の切断・再接続、電波の弱い所での挙動（RSSI と再送）
IP アドレス変更、DHCP 失効、DNS 応答なし、サーバ到達不能
遅延・パケットロス（tc netem で人工的に劣化させる）でタイムアウト処理が正しいか

7. 何をオラクルにするか

開いているポートが仕様どおり（余計なデバッグポートがない）
秘密が平文で流れない、証明書検証をサボっていない
API の認証・認可が正しく、不正入力を拒否する
切断・遅延・サーバ障害から回復する

8. 手を動かす

ポートとレイテンシを観測する

この章のポイント

Wi-Fi が載ると機器は IP 上のサーバ／クライアントになり、PC 用の道具（nmap/Wireshark/curl/mitmproxy）がそのまま使える
まずスキャンで地図を描く（IP・ポート・mDNS）。想定外のポートは要注意
パケットキャプチャで会話を覗き、平文の秘密や意図しない接続先を暴く
プロキシ/中間者で通信を観測・改変し、サーバ障害やクラウドを模擬できる
API を直接叩き、認証・認可・境界値・接続の乱れへの耐性を確かめる