セキュリティとは関係のないハードウエア_ソフトウエア開発の話

IoTSecJP Vol.4でのお話。

Transcript

1. ハードウエアとソフトウエアと私 それで動くと思うな。貴方が有能だからではない。説。 2018/09/15 KIDASAN
2. アジェンダ • どうでもいい前振り • ハードウエアが動き出すまで • ソフトウエアの実装
3. どうでもいい前振り • あくまでも一個人の見解です。企業としての見解とは一致しないことがあり ますのでご注意願います。 • いわゆる老害の酸味が含まれているかもしれません。必要であれば、お口 直しにソフトドリンクをお召しになってください。
4. 自己紹介 • 本来、SOC事業、ペネトレーションテストやマルウエア解析が本業であるべ き会社でIoTの特にハードウエアのみに特化したエンジニア。 • 入社してからソースコードを仕事でまともにみるのは希。 • バイナリ解析は趣味。 • ハンドル： kidasan (twitter: @kidasan) • 先週まで名古屋でオートモーティブワールド名古屋2018に企業ブース出展してました。 • 働き方改革と言われながら、上司の掲げた今週は休むというミッションは未達成。 • 9/16 西早稲田で開催されるETロボコンの試走会に出場します（守護神役）。
5. ちょっと宣伝 • CYBER GRID Journal Vol.6が刊行されました。 • WEBでも9/12解禁されました （https://www.lac.co.jp/lacwatch/report/20 180912_001687.html）
6. ちょっと言い訳 • 子会社による番外編ネットエージェン トジャーナルではありません。 • エンジニア向けというよりはもうちょっ とライトな層向け。
7. ハードウエアが動き出すまで • その昔は、職人どうしが回路をCADで書いて。 • それをアートワーク屋さんにお願いして。 • 緑の基板に部品を実装してもらう。 • で、動きました。一応。 • 今でもワンチップマイコンでROM/RAMもその中だけなら可能。
8. ハードウエアの性能が上がったらそうはいかず • 複数の高いハードルが存在します。 • 基板設計には高周波シミュレータが必要。 • 外付けメモリへの配慮。 • ソフトウエアどう載せる？ • デバック方法。 • ソフトウエア屋さんに渡すタイミングと連携。
9. 21世紀の最適な解決方法 • 回路図と付随ソフトウエア（最小 限）が公開されているベンダの評 価ボードを買う。 • ある程度、ソフトウエア屋さんに遊 んで貰いながらハードの実現性に ついて検討する。 • よければ採用して自社向けにアレ ンジして基板作成する。
10. 評価ボードの選択を誤ると大変なことに いわゆる、セキュリティの PoCが刺さる刺さる。 回避策を取れず に強制的に生産 終了を宣言するし かない。
11. 評価ボードをベースにするには理由がある。 • なくても基板までは作れます。 • その先で途方もない苦労をする。 • といってもハードウエア屋の苦労はさして変わらない。 • 設計時にFLASH/DRAMの制御パラメータ、バス周波数、仕様を一覧とできるか。 • 採用するCPU(ASSP)の仕様を一覧とできるか。 • つまりソフトウエアを走らせることができる保証をしないと何も動かない。
12. 高機能な基板を作ったらやること • JTAGデバッガを接続可能にする。 • バスラインと制御ラインを全部ジャンパを引き出してロジックアナライザに繋ぐ。 • ソフトウエア屋さんに（できなければ自分で）アセンブラだけでFLASHにアクセスするプログ ラムとDDRを初期化してDDRにアクセスするプログラムを作ってもらう（これ大事）。 • ところが、普通にＣで書いてくるエンジニア多数。 • いや、アセンブラで任意のＦＬＡＳＨの番地から走るプログラムをお願いしているのだが… • 書かれた（正しい筈の）ソフトウエアが正しくハードウエアにアクセスを繰り返して居ること をアセンブラの16進数ダンプとロジックアナライザのバスの数値から判断する。
13. さぁ、ソフトウエアを動かそうか！の前に • JTAGを接続可能にする。 • ICEではなくJTAGなのでCPUの代替え機 能としては動作しない。 • 動かすには先に述べたハードウエアに 関連する制御仕様からコンフィグレー ションファイルを記述する必要がある。 • 最初に繋いでブートのデバッグとローダ 部分のＦＬＡＳＨへの書き込みまでする 必要がある。
14. ソフトウエアを動かす • ブートローダを動かせれば、あとはどうにでもなる。 • U-bootを採用するのであれば、ここまでで利用したプログラムコードが活き る（特にメモリの設定）。 • まさか、この段階からYoctoとかいう輩はいないだろうが。さて….。
15. デバック • JTAGを繋ぐ努力をしたので楽。 • 普通にブレークポイントを張りつつ、メモリをダンプして様子を見ることがで きる。 • 動かないときに、何をしたら動かなくなったかのレポートをしやすい。 • 超能力はいらない。ハンドパワーもいらない。
16. ひとつだけ文句を言わせて • Yocto/AOSPについて • ビルドするのにディスク容量とCPU要求しすぎ。 • AOSPはまだしろ、Yoctoはとりあえずでpullされたコードが多いので気が付けば動かないコードだらけ。 • やるなら動く状態を一旦branchするなりExportして社内で管理するのが良い。 • AOSPはまだしもYoctoとくにAGL(Automotive Grade Linux)は機能優先をポリシーとしているのでセキュリティはcloneした側が 頑張る仕組み。 • ちなみに、実際のAOSPで実機をターゲットとしている場合にはQualcommのNDAコードと書き込み用バイナリ生成ツールが 用意されます（これが実際にGoogleに転がっているバイナリの元）。 • 過去にあった最悪の手引き • Yoctoのgitからダウンロードしますの一言だけのコード手引き。 • →ブランチタグさえも不明なので気付けば全く違うコードになっていて追加のカスタムコードがビルドできず、そして動かず。
17. 注意事項 • ソフトウエアからシンボル情報を削除するのはデバックが全部終わってか らにしましょう。 • シンボル情報の無いソフトウエアのデバックはJTAGでは一筋縄でできない ので普通のコンソール版Linuxと同様の苦労が必要。 • _mainすらわからず、アセンブラ表記だけが画面に並ぶ。
18. 番外編 作ったハードをハニポにしてマルウエア解 析 • 必要なもの • JTAGデバッガ • IDA Pro (またはrader2)
19. 環境設定 • IDA ProとJTAGデバッガ連携のためのプラグインをPythonで書く。 • とにかくハードウエアのその時の状態を診れるのにシンボル情報がないと苦行を強い られる。 • デバッガ連携しているとIDA Proがある程度分岐についてサポートしてくれる。
20. ということで • ２０分くらい経ったかな？