486はなぜ返ったのか。仕様のないLAN家電をPCAPから解析した実験ノート -Panasonic VL-MWD701で、SIP登録・Digest認証・暗号化NOTIFYを切り分けるまで-

家のドアホンを自作プログラムから使えるようにした。

対象はPanasonicのVL-MWD701。

最終的には、

機器探索

↓

SIP MESSAGE

↓

PhoneID取得

↓

SIP REGISTER

↓

Digest認証

↓

NOTIFY受信

↓

暗号化本文の復号

↓

状態XML取得

まで実機で確認できた。

結果だけを見ると、それほど複雑には見えない。

実際、最終的な通信仕様や確認できたパラメータはZenn側に整理している。

しかし、当然ながら最初からこの構造が分かっていたわけではない。

486 Busy Here が返ってくる。

401 Unauthorized が返ってくる。

ようやく登録できたと思ったらNOTIFYが読めない。

暗号を解いたと思ったらXMLパーサーがエラーを出す。

一つ分かるたび、別の分からないものが出てきた。

無料noteではその流れを読み物として書いた。

Zennでは最終的に確認できた技術情報をまとめた。

この記事では、その間にあったものを書く。

つまり、

正解が分からない機器を、どうやって一つずつ切り分けたのか。

そこを整理してみることにした。

VL-MWD701固有の話は出てくるが、考え方としては、仕様の分からないLAN家電やIoT機器を調べるときにも使えると思っている。

最初にやったのは、解析ではなく「分からないものを分ける」ことだった

調査を始めた時点で確実に分かっていたことは、それほど多くなかった。

分かっている

・親機がLANにつながっている

・Androidアプリから親機を発見できる

・Androidアプリから登録できる

・親機とAndroid端末の間で通信が発生する

一方、分からないものは多かった。

分からない

・どうやって親機を発見しているのか

・登録に何が必要なのか

・認証があるのか

・登録後にどうやって通知されるのか

・通知には何が入っているのか

・暗号化されているのか

・状態値が何を意味するのか

これを最初から、

VL-MWD701のプロトコルを解明する

という一個の問題として扱うと大きすぎる。

だから、通信を操作ごとに分けることにした。

アプリ起動

↓

機器探索

↓

スマートフォン登録開始

↓

登録要求

↓

認証

↓

登録後の待受

↓

通知

この分割は後からかなり効いた。

ブラックボックスを丸ごと理解する必要はない。

まず、「この操作をすると何が増えるか」を見ればよかった。

1. PCAPは操作単位で取った方が分かりやすかった

最初にやりがちなのが、アプリ起動から終了まで全部キャプチャして眺める方法だった。

当然、いろいろ出てくる。

DNSもある。

関係ない通信もある。

同じようなパケットも何度も出てくる。

そして、何が何に対応しているのか分からなくなる。

そこで途中から、キャプチャ条件を分けるようにした。

例えば、

A：アプリを起動しただけ

B：機器探索まで

C：親機を登録待機状態にしただけ

D：登録操作を行った

E：登録後、そのまま待機した

という具合になる。

AとBを比較すれば、探索で増えた通信が分かる。

BとDを比較すれば、登録操作によって増えた通信が分かる。

DとEを比較すれば、登録後に親機から送られてくるものを探せる。

大量のPCAPを読むのではなく、

条件を一つ変えて差分を見る。

やっていることはかなり単純だった。

2. 観測した事実と、自分の予想を分ける

最初に見つかった特徴的な通信は、

255.255.255.255:50000

へのUDPだった。

本文には、

pnvi,<数値>,00:00:00:00:00:00

のようなデータがある。

ここで、

pnvi は機器探索プロトコルである。

と書きたくなる。

でも、この時点で確認できているのは、

観測事実

・UDPである

・宛先はブロードキャスト

・宛先ポートは50000

・本文先頭にpnviがある

・途中の数値がキャプチャごとに変わる

までだった。

一方、

仮説

・pnviは機器探索を意味する？

・途中の数値は応答先ポート？

・最後の値は端末識別用MAC？

は、あくまで予想だった。

この二つを混ぜないようにした。

今回の調査では、これが意外と重要だった。

もっともらしい名前や数字を見ると、それだけで意味が分かった気になってしまう。

後で何度もそれに引っ掛かった。

ここから先では、

・486 Busy Hereをどう切り分けたか
・ClientではなくSmartphone1を使うと判断した理由
・401を「失敗ではない」と判断した根拠
・Digest認証値の候補をどう評価したか
・NOTIFY本文をどこで分割したか
・試した鍵候補と失敗結果
・復号成功を何をもって確定したか
・途中で棄却した仮説

を、実際の検証結果に沿って書いている。

最終仕様そのものはZennで無料公開している。
この記事で有料にしているのは、その答えへ到達するまでの判断過程になる。