PCを使用している場合、ブラウザのインスペクタを開くことで通信している内容・タイミングなんかを眺めることができます。
じゃあモバイル端末の場合はどうなんだということを思ったので、今回はAndroidアプリの通信を眺めてみる話をします。
※文中には適宜ふわふわした表現が含まれます。自信がない部分については可能な限りより詳しいドキュメントへの参照を貼らせていただきます。誤りなどあれば指摘いただけると幸いです。
パケットキャプチャの導入
モバイル端末の通信内容を取得するためにパケットキャプチャを導入します。
パケットキャプチャー
通信路を流れるパケットを取得するためのツールの機能や、その行為をする者。ツールとしての総称は「スニファー」という。
様々な目的に使われるが、プロトコルの情報を整形し通信状態を解析するツールを「プロトコルアナライザー」という。
https://www.wdic.org/w/TECH/パケットキャプチャー
要するに通信内容を取得するツールです。しかし通信内容といっても、例えばメールで送信されたテキストがそのまま読み取れたりといったことは（基本的に）出来ません。
そういうことをするにはバイナリ解読およびリバースエンジニアリングの知識が必要になります。
というわけで、私には無理なので今回はパケット本体のことは忘れてヘッダから取り出した情報を眺めて何かできないか考えてみようと思います。
Android端末用のパケットキャプチャ導入
tPacketCaptureというのを導入しました。調べてください。
VPN経由で通信内容のキャプチャを行うそうです。
端末上でやることはアプリでキャプチャのON/OFFを切り替えるだけです。
キャプチャした内容はファイルに書き出されるので、後のことはPCに移して処理します。
pcapファイルの確認
tPacketCaptureで取得した内容は.pcap形式のファイルで書き出されるので、 Wiresharkで開きます。
開くとこんな感じになります。
これだけ見るとなんのこっちゃって感じであり…
ここからどうするかというのは目的によるのですが、とりあえずここにはパケットキャプチャが有効になっている間に行われた全ての通信が記載されています。
これらの情報を眺めてみます。
IPアドレスを見る
ヘッダには送信先と送信元のIPアドレスが記載されています。
sourceとdstのどちらかに10.8.0.1というアドレスが記載されていますが、これはローカルIPアドレスなのでこれが記録された端末のことを指していると思われます。
そして10.8.0.1で絞り込むことで上りもしくは下りのパケットを絞り込めます。
絞り込みにはWiresharkのフィルタ欄に以下のように打ち込みます。
上り：ip.src == 10.8.0.1
下り：ip.dst == 10.8.0.1
また、送信元IPアドレスからホストを逆引きすればなんとなくアタリをつけることもできます。
❯ host 142.251.42.161
161.42.251.142.in-addr.arpa domain name pointer nrt12s46-in-f1.1e100.net.
1e100.net.はgoogleの所有しているドメインです。
つまり、多分これはgoogleのデータセンターから送信されたパケットだろうなという気持ちになります。
キャプチャされた内容は雑多なバックグランド通信なども含んでいるので、やろうと思えばそれらを分類することも可能ですね。
https通信の本体っぽいのを探す
パケットをずらっと眺めて、該当アプリがどのようなプロトコルで通信しているかアタリをつけます。
今回の私の場合だとprotocolはTLS、ポート番号はだいたい443、info欄にclient helloだのserver helloだのの文字列が観測されました。
なので多分https通信を行っているんでしょうということが察せます（自明）。
https通信の構造についての解説は他のサイトに任せるとして、ここから通信の本体を抜き出します。
とりあえずACKだのSYNだののパケットが凄く鬱陶しいですが、これらはTCP層なのでtlsでフィルタを掛ければ弾き出せます。
あとはinfoの部分を見てApplication Dataのパケットを抜き出せばいいですね。
ただし、Wiresharkではinfoの内容に対して例えば文字列検索などでフィルタを適用することはできません。そういう用途じゃないから仕方ないので、別途書き出してよしなに外部で処理するのがいいと思います。
時系列およびデータ長をみる
ヘッダからはパケットの送信されたタイミングおよびデータ長が見られます。
これらを集積すれば、アプリのデータ通信にかかる負荷を計測することができます。
こちらはGoogleスプレッドシートのアプリを動作させて総通信量をプロットしたものです。
実は今回やったのはこの計測を行うことが目的だったりもします。
端末上で操作を行ったタイミング等を記録しておいて比較すると、どのイベントに対応して通信が走ったか把握できるので面白いです。
おわり。
普段やらないことをすると、知らないことを色々調べることになるので楽しいです。