HDMIケーブルはどんな制御信号を送っているのか　悪意ある「BadHDMI」を見分けるために知っておくこと

HDMI制御系に存在する2つのプロトコル「CEC」「DDC」

mzyy94氏：「HDMI探検隊」と題して、LT（ライトニングトーク）をお送りします。自己紹介はさっくりと。元セキュリティ系で今は映像系をやっているエンジニアです。

探検に行く前に「みなさん、HDMIをご存じですか？」というところから、基礎を押さえておきましょう。

知っている人がほとんどだと思いますが、HDMIは、映像と音声を送る端子とケーブル、そしてその通信規格のことです。イーサネット通信や、制御系としての機器コントロールや、ディスプレイコントロールなどもできます。今回はこのHDMI制御系の探検をしていきたいと思います。

HDMI制御系には2つのプロトコルが存在しています。1つがConsumer Electronics Control（CEC）というプロトコルで、もう1つがディスプレイをコントロールするDisplay Data Channel（DDC）というプロトコルです。

CECは、主にリモコン操作や、テレビ・ディスプレイの入力切替や、HDMIがつながっている機器のスタンバイ状態やそれが復帰したときの通知などを行う単線のバス規格なのですが、DDCはもうちょっと複雑で、ディスプレイとのやりとりを中心とした、I-squared-C（I2C）を使った機器間のプロトコルです。

このDDCをもう少し深堀りすると、仕様にはこれら4つが策定されています。

1つ目、DDC/CI（DDC Command Interface）は、ディスプレイのボリュームを上げたり、ディスプレイの輝度を変えたりなどの操作をI-squared-C（I2C）を通して行う規格です。

2つ目です。コンテンツ保護のため映像自体を本当は鍵で暗号化するのですが、その鍵をやりとりするためにDDCの中ではHDCPというプロトコルが使われています。

3つ目です。EDIDは、ディスプレイが表示できる解像度やrefresh rateなどをHDMIの機器に対して送るためのプロトコルです。

4つ目に挙げているのが、SCDCです。HDMI 2.0から追加された、DRMやスクランブルなどいろいろな情報を追加でやりとりするためのプロトコルです。

この4つがDDCのプロトコルに策定されています。

HDMI制御系のピン配列と役割

これら制御系がハードウェアに対してどのようにつながっているのかは「Wikipedia」でググると出てくるのですが、HDMIの結線は一般的なType Aの端子で19本つながっています。

この図のようにつながっていて、これら4つが主に映像と音声を伝送する役割を担っていて、残りが制御系を担っています。

cec-clientコマンドを使ってCECを探検する

ここまでが制御系と映像の基礎知識でしたが、ここからは制御系の探検をしていきたいと思います。

HDMI制御系をいじっていくのですが、一般の家庭にもあるこういった機器を使って、制御系はいじることができるので、これを使いたいと思います。

Raspberry Piの回路図には、ハードウェア的にもHDMIのこの制御線がきちんとつながっていることが記されていて、ライブラリがAPIとして提供されているので、VideoCoreにつながっているHDMIの制御線をこのVideoCoreを経由して操ることができます。これらを使って探検を進めていきます。

CECを探検していく方法として、愚直にVideoCoreのAPIを叩く方法もあるのですが、もう1つの方法の、VideoCoreのAPIを使ったラッパーみたいな存在のcec-clientというコマンドを使って、CECフレームを送ってみます。

CECフレームは、けっこう単純な形式になっていて、上位ビットから「送信元バスID」「宛先バスID」「OPコード」に「引数」というかたちで流すことで、送りつけることができます。

認証機構もないCECフレームは送り放題

こういったことを踏まえていろいろとやってみると、CECのフレームは送り放題なんですね。通信元の偽装はたまに弾かれるんですが、認証機構もなくけっこう自由にできます。なので、機器のリモコン操作なども、勝手にほかの機器に対して送りつけることができます。

バス自体が単線でだいぶ低速なので、送り過ぎると、けっこうな頻度でほかのCECの通信が妨害できることがわかりました。ほかにも、引数を不正なものにしてみたり、細工をしたものが実際にどうなるかをちょっと調査したところ、あまりおもしろい挙動にはつながらないことがわかりました。

「Raspberry Pi」を使ってDDCを探検する

次は、DDCを探検してみます。これも愚直にVideoCoreのAPIを叩く方法があるのですが、Raspberry Piはデバイスツリーのオーバーレイを当ててI2C自体を露出させられるので、これを使ってI2Cのバスを出して、実際に触ってみることで探検を進めていきます。

オーバーレイを当てると、Raspberry Pi 3までは2番のバスに、Raspberry Pi 4からは12番のバスにDDCのI2Cバスが出てくるのですが、これでフレームアドレスをチェックすると「0x37、0x3a、0x50、0x54」といったアドレスのバスが露出していることがわかります。「0x37」がDDC/CI、「3a」がHDCP、「50」がEDID、「54」がSCDCです。

これがわかったので、i2ctransferのコマンドなどを使って、いろいろと仕様書を片手にやってみると、HDCPのやりとりはけっこうな確率でテレビやディスプレイ側が処理待ちをする挙動になっているので、途中で止めると不安定になりました。あとは、HDCPの失効リストというSRMファイルが提供されているのですが、それを書き換えることでデバイスを失効させることもできました。ほかにもDDC/CIを使って、ディスプレイ設定を好き勝手にいじることができました。

悪意をもった「BadHDMI」も不可能ではない

簡単にいじり回せるということは、悪用も簡単にできるということですよね。「BadHDMI」と勝手に命名しましたが、「BadUSB」のHDMI版みたいなものがあってもおかしくないなと思います。

善良なHDMIデバイスのフリをして、BadUSBみたいにあるとき急に悪さをするHDMI機器が現れたとしたら相当危険じゃないか、ChromecastやFire TVなどの安全なデバイスに慣れきっている世間には衝撃が走るんじゃないかなと危惧をもっています。

認証がないので、CECやDDCが端子につながってさえいれば、どんな機器からでも送れるという点が、大きな問題点かなと考えています。

攻撃例としては、CECでリモコン信号を送りつけて、ほかのHDMI機器を勝手に操作したり、単線のバスなCECは機器によってはすべての通信が見られるので、パスワード入力を盗んだり、DDC/CIで輝度を高頻度で変えたり、ボリュームを大小さまざまな値にセットしてハードウェアに負荷をかけたり、挙動を不安定にさせたり、HDCPやSCDCの手続きを無視することで、ファームウェア側で待ちに入るのを利用して、ディスプレイ自体をハングアップさせたりなどの悪用が考えられます。

単純なPoC（Proof of Concept）をTwitterに投稿したので、興味のある方はこのハッシュタグ（#BadHDMI）で検索してもらえればと思います。

ということで、発表「HDMI探検隊」は、HDMI制御系を探検していたらBadHDMIにつながるんじゃないかなというところに着地しました。以上、発表を終わります。