以下の方法でLINEのパケットを調べてみた。

起動後何もせず1分ほど待つ
- (起動時などはネットワーク制御系のパケットやら、アップデートやらの邪魔なパケットが飛び交いまくるので暫く待つ)
WireSharkで使用中のネットワークインターフェースを指定する。
すぐにLINEを立ち上げる(やることは3種類)
- 普通のメッセージを送る
- カスタムスタンプを送る
- 送り先で既読をつける(既読の戻りパケットが欲しい)

f:id:yuyubu:20170814001029p:plain

WireSharkを止め、TCPのアクセスのあるIPからLINEっぽいものをピックアップ

LINEっぽいホストをピックアップ

13.32.194.153 Amazon EC2(LINEのCDN)*1
203.104.142.52 LINE
203.104.150.2 LINE
23.45.140.69 アカマイ(LINEのCDN)

一番上は違うかもちなみに、色分けルールもIP別に作成して解析しやすくした。 f:id:yuyubu:20170814013340p:plain

フィルタを使って通信を調べる

まずは全てのIPが含まれるフィルタ

ip.addr == 13.32.194.153 || ip.addr == 203.104.142.52 || ip.addr == 203.104.150.2 ||ip.addr ==23.45.140.69

通信の流れとしては

No1: 最初に23.45.140.69と一回きりの通信(後は音沙汰なし)
No2: 203.104.142.52と203.104.150.2を織り交ぜてチャットを実現？
No3: 通信の後半に13.32.194.153から大きなデータを一方的に送りつけられている

という内容。(3の終了後に2のパケットのやり取りが何度かあった)*2

23.45.140.69 アカマイ

最初に通信をしていたのがこのホスト。

TLSを使って何かを送信している

f:id:yuyubu:20170814004830p:plain

最後の行がEncrypted Alertと表示されているが、下記サイトによると、

d.hatena.ne.jp

セッションの途中やキャッシュが残っている状態でキャプチャを開始して、前述の共通鍵が入手できず通信の中身が分からないときです。さて、SSLでは通信切断時はAlertプロコトルのClose Notifyで通知します。つまりタネあかしをすると、先ほどの謎のAlertは、単なるClose Notifyのパケットです。

とのことですが、それだと自分のキャプチャ結果のClose Notifyのパケットはサーバー側から出ているように思える。(Close Notifyはサーバー側、クライアント側どちらが出しても問題ないのかな?)

通信内容としては、一通りTLSのやり取りを行った後、ホスト・クライアント双方で400バイトくらいのデータを交換している。

個人的に思った感想としては明らかにアプリケーションが送付するデータよりTLSの制御パケットの方が圧倒的に多いこと。

TLSはまだ勉強不足なのでこのへんで・・・ ※またこれ以後のサーバーも全てTLSを使っていますが、TLSに関する説明は略します。

このサーバーとの通信は、最初にちょろっとTLS経由でデータ交換をした後、音沙汰なしのため最初に必要なアクションであるログイン認証をこのサーバーを使ってやっていると予測してみる

203.104.142.52

アカマイCDNとの通信が終わった後は、LINEのサーバーとの通信が始まる。こちらは 203.104.150.2より先に通信が始まっている。多分これはメッセージを送付する前に送られてきた情報、つまりLINEのアプリの状態自体(受信メッセージなどはあるか)などの情報を取りに行っている処理ではないだろうか？