Sansan 事業部 プロダクト開発部の宮崎です。
大分日が空いてしまいましたが、de:code 2019 のレポート2つ目です。
私のde:code 2019レポートでは「ハードコアデバッキング」をご紹介します。
何かと思われるかもしれませんが、そういうセッションのタイトルだったのです。 正直にいうと、私も名前に釣られて行ってみました。
いきなり…
センションのスタートと共に、
「唯一レベルのLv500*1ということです」
「ようこそ皆さん！ヘンタイの為のセッションへ！」
という刺激的なスライドが映し出されました。
くるところやっぱり間違えたかなぁ おらワクワクしてきたぞ！
さらに、
「考えるな感じろ」
やっぱり帰ろうかなぁ 早く先がみてぇぞ！
そして、
悪用厳禁ときました、ですよねー。
登壇者のお二人は「どちらかといえばマシン語の方が得意なので、喋る方はアレ」とおっしゃっていましたが、はじまりから個性的な発表スタイルで聴講者を惹きつけられていました。
テーマはカーネルモードデバッキングとデバッグ作業の自動化でした。
カーネルモードとは
カーネルモードでは、CPUはそのアーキテクチャの全ての操作が可能である （ハードウェア構成によっては不可能な操作もありうる）。 任意の命令を実行でき、入出力操作を開始でき、全メモリ空間にアクセス可能である。 他のCPUモードでは、ハードウェアによってCPUの動作に制限が加えられる。 典型的には、一部の命令が実行できなくなり、入出力操作ができなくなり、メモリ空間の一部にアクセスできなくなる。 通常、ユーザーモードでのCPUの機能はカーネルモードでの機能のサブセットであるが、 場合によっては（例えば他のアーキテクチャのハードウェアをエミュレーションしている場合など）、 カーネルモードのサブセットとは言えない全く異なった機能になっていることもある。
なるほど、わからん
要するに超すごい権限を使って…
- アプリケーションの処理の移譲先で起こったエラー
- Windows カーネル内で起こったエラー
等をデバッグできるのです。すごい（小並感）。
ここでは「ドライバーが原因で固まってしまうアプリケーション」のデバッグを題材にデモをしてました。
いきなり起動しないアプリケーションが登場
「あれ、起動しないですね…」 「あ、ちょうどよくここに WinDbg があるのでこれで起動してみましょう…」 「やっぱり起動しませんね…」
演出とはいえ…ちょうどよく WinDbg*3 なんてあるか！
この後セッションではカーネルモードを利用して、ALPC*4 のメッセージを追いかけながら
問題を起こしているドライバーを突き止めるまでの一連の流れがデモされました。
私はあいにくサーバーサイドエンジニアですが、弊社にはスキャナを操作するための Windows アプリを保守/開発しているチームがあったりします。
なので、こういう知識って実は無関係じゃなかったりします。
知っていれば役立つ事もあるかもしれません。
デバッグを自動化する
説明に用いられたシナリオは、1000台分のカーネルダンプの解析・調査を自動化して対応するという内容でした。 いや、1000台とかいくらなんでもハードコア過ぎるだろ…
どうやって自動化するの？
セッションでは JavaScript Extention を利用しての自動化が紹介されていました。
テストは自動化するけど…デバッグ作業って自動化できたんすね…というのが正直な感想でした。
デモでは WinDbg で名前空間を特定しながら、それをもとに
JavaScript Extention API で対応する物を探し、JavaScript を記述していくという内容でした。
これなら私でもできそうです活躍の機会なさそうだけどね。
感想
Windows のアプリをこのレベルでデバッグした経験はないので、正直難解な部分が多かったです。
でも、1つ感じたのはこういった技術と知識を駆使すれば
一見解決不能に見えるエラーに遭遇しても結構戦えるものなんだなと。
今度使っているアプリが変なフリーズを起こしたら WinDbg を使って調べてみようかなと思いました。
最後に
お後がよろしいようで。
*1:今回のde:codeにおいて最高の技術レベル。要するにとても人を選ぶということ
*2:写真撮影可のセッションだったので、当時撮影したものを掲載しております
*3:Windows Debugger のこと
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools
*4:Advanced Local Procedure Call のこと
