実行中のプロセスをフックして任意のコードを実行する (Non-invasive instrumentation)

はじめに

掲題の方法を非破壊的、すなわちソースコードや実行可能モジュールのファイルを変更せずに実現するツールを作りました。より具体的には、「実行中のプロセスの任意の箇所をフックして、DLL に実装した任意のコードにジャンプして実行してから、元の処理に戻って動作を継続できる」ツールです。手前味噌ですがけっこう便利だと思います。現実的な使用場面として、パフォーマンス測定やカスタム ロギング、スレッドの競合を意図的に引き起こすためのタイミングの調整、などが考えられます。

msmania/procjack: Not Another Code Injection Toolkit
https://github.com/msmania/procjack

というわけでこの記事では、以下 2 つの実装例を紹介して Non-invasive instrumentation の便利さを伝えようと思います。残念ながら Windows の x86 と x64 限定です。あとユーザー モード限定です。なお Non-invasive instrumentation というキーワードは、私が勝手に思いついたものです。ググると、医療業界で使われている例が見つかります。

実装例 1: Google Chrome の関数のボトルネック箇所を特定する
実装例 2: Google Chrome と Microsoft Edge とでヒープ メモリ確保のパフォーマンスを比較する

Reflective DLL Injection meets Microsoft Detours

実装例紹介の前にキーワードを先に紹介すると、Non-invasive instrumentation は、Reflective DLL Injection を利用して Microsoft Detours をターゲット プロセス内で動的に実行するテクニックです。具体的には以下のようなコマンドを実行します。

> pj.exe 1248 clove.dll?200 00007FF8`02BCBED0

このコマンドは、「PID:1248 のプロセス内で新しいスレッドを作って clove.dll をロードし、序数 200 番の関数を実行せよ」という命令です。ロードされた clove.dll の関数が、コマンドで指定されているアドレス 00007FF8`02BCBED0 をフックし、DLL 内で予め定義されたカスタム コードを差し込みます。clove.dll における序数 200 番の関数はサンプルとして実装済の関数で、内容は後述します。新たな instrumentation を実装する場合は、Clove のコードをコピーして新しい DLL を作るか、Clove 内に新たなエクスポート関数を追加することができます。

この例から分かるように、instrumentation は、DLL をプロセスにインジェクトするためのツール ProcJack (pj.exe) と、インジェクトされた後にコードのフックを担当する Clove (clove.dll) の 2 つのモジュールから構成されています。以下、それぞれのモジュールを簡単に紹介します。

ProcJack

ProcJack は、動作中のプロセスに対して外部から DLL をロードさせ、任意のエクスポート関数を実行するためのコード インジェクション ツールです。過去にブログに書きました。

Reflective DLL Injection - すなのかたまり
https://msmania.github.io/2015/04/26/reflective-dll-injection.html

基本原理は、あるハッカーが Reflective DLL Injection と名付けた有名な方法です。オリジナルのReflective DLL Injection では、VirtualAllocEx と WriteProcessMemory で対象プロセスにデータを送り込み、CreateRemoteThread で LoadLibrary を起点としたスレッドを開始する方法です。DLL のエントリ ポイントである DllMain に実行したいコードを書いておくことで、ターゲット内での実行を可能にします。

ProcJack では、DllMain の代わりにエクスポート関数を呼び出せるようにし、さらにコマンドから任意の文字列をエクスポート関数に渡せるようにしています。これによって、インジェクトしたい複数の処理を 1 つの DLL に入れて使い分けることができます。

Clove

Clove は、Microsoft Detours を使ってプロセス内の任意の箇所をフックする処理を、ProcJack がインジェクトできるように DLL として実装したものです。Detours についても過去にブログを書きました。

Microsoft Research Detours Express 3.0 - すなのかたまり
https://msmania.github.io/2014/11/29/microsoft-research-detours-express-3-0.html

Detours の当時のバージョンは 3.0 で、ソースコードこそ公開されていたものの、そのままだとコンパイル エラーが出たり、無償版は 64bit で使えなかったりしました。久々にググってみると、GitHub にバージョン 4.01 が MIT ライセンスで、しかも x64 や ARM でも使えるようになっていました。時代の変遷を感じます。

Detours - Microsoft Research
https://www.microsoft.com/en-us/research/project/detours/

Detours の動作原理は、インポートテーブルの書き換えなどという生ぬるい手段ではなく、フックする箇所の命令を逆アセンブルし、トランポリン関数として別の場所にうまいこと退避させ、元の箇所にフック先への jmp 命令を埋め込むという巧妙な方法です。Detours Wiki に図があります。

OverviewInterception · Microsoft/Detours Wiki
https://github.com/microsoft/detours/wiki/OverviewInterception

Detours の基本的な使い方は、関数全体をフックすることです。例えば Detours の simple というサンプルで実現しているのは、SleepEx の呼び出しをフックして TimedSleepEx という関数を実行し、その中でオリジナルの SleepEx と追加の処理が実行するというものです。

Clove で実現できるようにしたのは、関数の先頭をフックして処理を置き換えるのではなく、関数の途中も含めた任意の箇所で新しいコードを実行し、その後でオリジナルの処理を継続することです。これはフックするコードを ret で終えるのではなく、トランポリン関数への jmp を埋め込むことで実現できるようにしました。Clove が使うための API を Detours に追加する PullRequest を投げたのですが、今のところ音沙汰がありません。

Add DetourAllocateRegionWithinJumpBounds API by msmania · Pull Request #27 · Microsoft/Detours
https://github.com/Microsoft/Detours/pull/27

ケーススタディ

冒頭で挙げた 2 つの実装例を紹介します。どちらの実装例も GitHub のリポジトリに含まれているので、手元ですぐに試すことができます。

実装例 1: Google Chrome の関数のボトルネック箇所を特定する
実装例 2: Google Chrome と Microsoft Edge とでヒープ メモリ確保のパフォーマンスを比較する

実装例 1: Google Chrome の関数のボトルネック箇所を特定する

新たに実装した関数が特定の状況下で妙に遅くなって、それをデバッグする場面は少なからずあると思います。そんなとき、Non-invasive instrumentation を使うとアドレス単位でボトルネックを調べることができます。また、複数の箇所における実行時間を定量的に比較することにも使えます。

従来の方法

Windows でパフォーマンスに関するトラブルがあった場合、WPA (= Windows Performance Analyzer) を試すことが多いと思います。

Exercise 3 - Understand Critical Path and Wait Analysis | Microsoft Docs
https://docs.microsoft.com/en-us/windows-hardware/test/wpt/optimizing-performance-and-responsiveness-exercise-3

上記ページに説明がある通り、WPA はコンテキスト スイッチのタイミングで ETW を記録し、前回のコンテキスト スイッチからの CPU 消費時間をプロセス、スレッド、コールスタック毎に分析できるという優れたツールです。ただこのツール、OS 全体から怪しいスレッドや関数の候補を絞り込むのには便利なのですが、いかんせんゴールがコールスタックなので、関数のどの部分がどれだけ遅いかまでは分析できません。例えば関数にループが複数あって、そのどれがが極端に遅い場合、そのループを特定することはできません。

あと、WPA がシンボルをロードする機能が原因不明で動かないことが多々あり、さらに動いても妙に遅いのでけっこうストレスが溜まるという理不尽な理由もあります。序盤は強いけど、終盤は弱いのです。

最終手段は、対象プログラムのソース コードを変更 (= instrument) し、計測したい箇所の前後の tick の差分を取ってそれをログに出力させるようなコードを追加する方法です。これは確実ですが手軽さが皆無なので、できれば避けたいです。例えば対象が Chromium のように巨大だったら、(潤沢なビルド環境を持たない私のような一般人は) 試行錯誤のために何回かビルドするだけで一日が終わりそうですし、そもそも対象プログラムのソースコードが無かったり、ビルド環境が無い場合もあります。また、コンパイラーの最適化の動作によって、オリジナルのプログラムと結果が一致しない可能性も考えられます。

Non-invasive instrumentation

ProcJack + Clove を使うと、プログラムを再ビルドしなくても instrumentation を動的に実現できます。発想は、以下のような 2 つの関数をボトルネック候補の開始地点と終了地点にそれぞれ埋め込んで、任意の範囲の実行時間を計測しようというものです。実際に Clove が埋め込むコードは C/C++ 関数のように ret で終わるのではなく、トランポリン関数へ jmp する必要があり、さらに rax など C/C++ の呼び出し規約では必要のないレジスターの復元が必要になるため、少なくとも処理の一部はアセンブリで書かないといけません。あれ、そこまで手軽じゃない・・・？

#include <cstdint>
#include <intrin.h>

uint64_t Counter_Local = 0;
uint64_t Counter_Total = 0;

void Measurement_Start() {
  Counter_Local = __rdtsc();
}

void Measurement_End() {
  Counter_Total += (__rdtsc() - Counter_Local);
}

実際に試してみましょう。パフォーマンスの計測は、Clove.dll の 100 番の関数です。ターゲットは何でもいいのですが、notepad.exe なんかだとあまりにもサンプル臭くて現実味に欠けるので、あえて大物の Google Chrome を使うことにしました。Chrome.exe はサンドボックス環境で動いているので、インジェクションを成功させるためには後述する方法で CIG という OS の保護機能を解除する必要があります。

パフォーマンスの測定対象は、条件分岐が少ない方が結果が明確なので、call が分岐なしで連続する chrome_child!blink::Document::UpdateStyleAndLayoutTree を使うことにします。この関数はレイアウト ツリーを更新する関数で、例えば JavaScript で scrollLeft や clientHeight といったプロパティを取得しようとしたときにレイアウトを確定するために呼ばれます。

ソースコードはここにあります。
https://chromium.googlesource.com/chromium/src.git/+/70.0.3503.0/third_party/blink/renderer/core/dom/document.cc#2123

測定は、関数を適当な複数の範囲に区切り、それぞれの範囲で消費される CPU サイクルを計測することで行います。まずはプロローグからエピローグの範囲で、関数呼び出しを中心に以下の 10 個の範囲に区切ることにします。このへんのアドレスの洗い出し作業はけっこう面倒かもしれません。

Address	Instruction	Comment
00007ffd`f81e2520	push rbp	Function prologue
00007ffd`f81e2672	call chrome_child!blink::DocumentAnimations::UpdateAnimationTimingIfNeeded
00007ffd`f81e2677	cmp byte ptr [rsi+201h],0	Immediately after the call to UpdateAnimationTimingIfNeeded
00007ffd`f81e269b	call chrome_child!blink::Document::UpdateUseShadowTreesIfNeeded
00007ffd`f81e26a3	call chrome_child!blink::Node::UpdateDistributionInternal
00007ffd`f81e26ab	call chrome_child!blink::Document::UpdateActiveStyle
00007ffd`f81e26b3	call chrome_child!blink::Document::UpdateStyleInvalidationIfNeeded
00007ffd`f81e26bb	call chrome_child!blink::Document::UpdateStyle
00007ffd`f81e26c0	mov rax,qword ptr [rsi+7A8h]	Immediately after the call to UpdateStyle
00007ffd`f81e2848	add rsp,0F0h	Function epilogue

以下のコマンドを実行することで、上記のように決めた範囲のアドレスを一気にフックできます。6848 はレンダー プロセスの PID です。

D:\pj\amd64\pj.exe 6848 C:\Windows\fonts\clove.dll?100 00007ffd`f81e2520-00007ffd`f81e2672-00007ffd`f81e2677-00007ffd`f81e269b-00007ffd`f81e26a3-00007ffd`f81e26ab-00007ffd`f81e26b3-00007ffd`f81e26bb-00007ffd`f81e26c0-00007ffd`f81e2848

後述しますが、chrome.exe プロセスは Untrusted レベルで動作しているため、アクセスできるファイルの場所が大きく制限されています。その対策として、数少ない読み取り可能な場所である C:\windows\fonts に clove.dll をコピーして pj.exe を実行しています。フックがうまくいくと、デバッガー コンソールに以下のようなログが出力されます。

ModLoad: 00007ffe`140a0000 00007ffe`14148000   C:\Windows\fonts\clove.dll
Detouring: 00007FFDF81E2520 --> 00007FFDB81E0000 (trampoline:00007FFDB81D0120)
Detouring: 00007FFDF81E2672 --> 00007FFDB81E002C (trampoline:00007FFDB81D0180)
Detouring: 00007FFDF81E2677 --> 00007FFDB81E0084 (trampoline:00007FFDB81D01E0)
Detouring: 00007FFDF81E269B --> 00007FFDB81E00DC (trampoline:00007FFDB81D0240)
Detouring: 00007FFDF81E26A3 --> 00007FFDB81E0134 (trampoline:00007FFDB81D02A0)
Detouring: 00007FFDF81E26AB --> 00007FFDB81E018C (trampoline:00007FFDB81D0300)
Detouring: 00007FFDF81E26B3 --> 00007FFDB81E01E4 (trampoline:00007FFDB81D0360)
Detouring: 00007FFDF81E26BB --> 00007FFDB81E023C (trampoline:00007FFDB81D03C0)
Detouring: 00007FFDF81E26C0 --> 00007FFDB81E0294 (trampoline:00007FFDB81D0420)
Detouring: 00007FFDF81E2848 --> 00007FFDB81E02EC (trampoline:00007FFDB81D0480)
[102c] Waiting..

結果の出力は、clove.dll の序数 3 の関数を呼び出すことで行います。

D:\MSWORK>D:\pj\amd64\pj.exe 6848 C:\Windows\fonts\clove.dll?3
Hijacking: PID=1ac0 (WIN64) TID=1540 VM=00000218DE3C0000

結果はデバッガーのコンソールに以下のように表示されます。フックしたアドレスの各範囲と、その右の数値がその範囲を実行するのにかかった CPU のクロック数、callcount は範囲の開始アドレスと終了アドレスが実行された回数です。total ticks は、各範囲のクロック数の合計です。まだブラウザーで何もしていないのでクロック数や呼び出し回数は全て 0 になっています。

[MeasurementChain] total ticks: 0
  00007FFDF81E2520-00007FFDF81E2672: 0 (callcount: 0 0)
  00007FFDF81E2672-00007FFDF81E2677: 0 (callcount: 0 0)
  00007FFDF81E2677-00007FFDF81E269B: 0 (callcount: 0 0)
  00007FFDF81E269B-00007FFDF81E26A3: 0 (callcount: 0 0)
  00007FFDF81E26A3-00007FFDF81E26AB: 0 (callcount: 0 0)
  00007FFDF81E26AB-00007FFDF81E26B3: 0 (callcount: 0 0)
  00007FFDF81E26B3-00007FFDF81E26BB: 0 (callcount: 0 0)
  00007FFDF81E26BB-00007FFDF81E26C0: 0 (callcount: 0 0)
  00007FFDF81E26C0-00007FFDF81E2848: 0 (callcount: 0 0)

ここまでで準備ができたので、レイアウトの更新が発生するような操作を実際にブラウザー上で行ない、再度結果を表示させます。レイアウトの更新は、マウス カーソルをページ上で適当に動かすだけでもいいですし、ハイパーリンクをクリックしたり F5 更新をしてもいいです。今度は結果は以下のようになりました。

[MeasurementChain] total ticks: 49720220
  00007FFDF81E2520-00007FFDF81E2672: 211704 (callcount: 250 29)
  00007FFDF81E2672-00007FFDF81E2677: 696406 (callcount: 29 29)
  00007FFDF81E2677-00007FFDF81E269B: 9168 (callcount: 29 29)
  00007FFDF81E269B-00007FFDF81E26A3: 11122 (callcount: 29 29)
  00007FFDF81E26A3-00007FFDF81E26AB: 28517 (callcount: 29 29)
  00007FFDF81E26AB-00007FFDF81E26B3: 7787139 (callcount: 29 29)
  00007FFDF81E26B3-00007FFDF81E26BB: 26144 (callcount: 29 29)
  00007FFDF81E26BB-00007FFDF81E26C0: 39574513 (callcount: 29 29)
  00007FFDF81E26C0-00007FFDF81E2848: 1375507 (callcount: 29 250)

callcount の数値が一致していない範囲があります。これは、開始アドレスは実行されたものの終了アドレスが実行されなかったことを意味しており、実行時間を正しく計測できていません。上の例では、関数自体は 250 回実行されたものの、00007FFDF81E2672-00007FFDF81E2677 の範囲である UpdateAnimationTimingIfNeeded 関数の呼び出しを実行せずにエピローグまで early return するコードパスがあることを示唆しています。

このままだと結果が分析しづらいため、プロローグからエピローグまでの関数全体の範囲と、関数呼び出しが行われる関数中盤の範囲との 2 つに計測範囲を分割することにします。つまり、コマンドの実行を 2 回に分けます。

新しい計測を始める前に、現在のフックを解除する必要があります。これは序数 2 番の関数を実行します。

D:\MSWORK>D:\pj\amd64\pj.exe 6848 C:\Windows\fonts\clove.dll?2
Hijacking: PID=1ac0 (WIN64) TID=0af8 VM=00000218DE3B0000

デバッガーに以下のような出力が表示され、clove.dll がプロセスからアンロードされます。

Sending a signal to terminate shimming..
Cleanup is done.  Goodbye!

では新しい計測を、以下の 2 つのコマンドを続けて実行して開始します。

D:\MSWORK>D:\pj\amd64\pj.exe 6848 C:\Windows\fonts\clove.dll?100 00007ffd`f81e2520-00007ffd`f81e2848
Hijacking: PID=1ac0 (WIN64) TID=0558 VM=00000218DE270000
D:\MSWORK>D:\pj\amd64\pj.exe 6848 C:\Windows\fonts\clove.dll?100 00007ffd`f81e2672-00007ffd`f81e2677-00007ffd`f81e269b-00007ffd`f81e26a3-00007ffd`f81e26ab-00007ffd`f81e26b3-00007ffd`f81e26bb-00007ffd`f81e26c0
Hijacking: PID=1ac0 (WIN64) TID=1514 VM=00000218E0F90000

デバッガーの出力は以下の通りです。

ModLoad: 00007ffe`13fe0000 00007ffe`14088000   C:\Windows\fonts\clove.dll
Detouring: 00007FFDF81E2672 --> 00007FFDB81E0000 (trampoline:00007FFDB81D0120)
Detouring: 00007FFDF81E2677 --> 00007FFDB81E002C (trampoline:00007FFDB81D0180)
Detouring: 00007FFDF81E269B --> 00007FFDB81E0084 (trampoline:00007FFDB81D01E0)
Detouring: 00007FFDF81E26A3 --> 00007FFDB81E00DC (trampoline:00007FFDB81D0240)
Detouring: 00007FFDF81E26AB --> 00007FFDB81E0134 (trampoline:00007FFDB81D02A0)
Detouring: 00007FFDF81E26B3 --> 00007FFDB81E018C (trampoline:00007FFDB81D0300)
Detouring: 00007FFDF81E26BB --> 00007FFDB81E01E4 (trampoline:00007FFDB81D0360)
Detouring: 00007FFDF81E26C0 --> 00007FFDB81E023C (trampoline:00007FFDB81D03C0)
[1514] Waiting..
Detouring: 00007FFDF81E2520 --> 00007FFDB81E0294 (trampoline:00007FFDB81D0420)
Detouring: 00007FFDF81E2848 --> 00007FFDB81E02C0 (trampoline:00007FFDB81D0480)

前回と同様、レイアウト更新が発生する操作を行ない、序数 3 番の関数を実行して結果を見ます。今度は以下のような結果が得られました。

[MeasurementChain] total ticks: 44568167
  00007FFDF81E2672-00007FFDF81E2677: 2787346 (callcount: 75 75)
  00007FFDF81E2677-00007FFDF81E269B: 24438 (callcount: 75 75)
  00007FFDF81E269B-00007FFDF81E26A3: 29281 (callcount: 75 75)
  00007FFDF81E26A3-00007FFDF81E26AB: 60680 (callcount: 75 75)
  00007FFDF81E26AB-00007FFDF81E26B3: 1961842 (callcount: 75 75)
  00007FFDF81E26B3-00007FFDF81E26BB: 64567 (callcount: 75 75)
  00007FFDF81E26BB-00007FFDF81E26C0: 39640013 (callcount: 75 75)
[MeasurementChain] total ticks: 46541365
  00007FFDF81E2520-00007FFDF81E2848: 46541365 (callcount: 246 246)

callcount の数値を見ると、関数全体は 246 回実行されたものの、UpdateAnimationTimingIfNeeded から始まる関数の呼び出しは 75 回しか実行されていません。したがって、残りの 171 回はその前の return 文で early return したことが分かります。total ticks の数値を見ると、ともに約 45M クロックぐらいを示しているので、early return したときの実行時間は誤差の範囲で、関数中盤を 75 回実行するのにかかったクロック数が、early return した分も含めた 246 回の関数全体の実行クロック数とほぼ同じであることが分かります。

中盤の関数呼び出しの内訳をみると、明らかに 00007FFDF81E26BB-00007FFDF81E26C0 のコード範囲がボトルネックであり、関数全体の実行時間の 89% (=39640013 / 44568167) を占めています。前述の表から、このアドレス範囲は chrome_child!blink::Document::UpdateStyle 呼び出しです。

よって、chrome_child!blink::Document::UpdateStyleAndLayoutTree の実行のうち、89% はchrome_child!blink::Document::UpdateStyle が占めていることが分かりました。もしこの関数のパフォーマンス向上が求められる場合、UpdateStyle の処理を改善することが最優先になります。これが結論です。

実装例 2: Google Chrome と Microsoft Edge とでヒープ メモリ確保のパフォーマンスを比較する

ある操作を行ったときに、ある関数がどのスレッドからどんなパラメーターで何回ぐらい呼ばれるのかを知りたい時があります。定番の方法は、ソースコードにトレース関数を書いておき、限定された状況でのみトレースを取るようにすることです。これまでの経験では、リリース前の開発時に書かれたトレースは、リリース後のトラブルシューティングではポイントがずれていてあまり有益でなかったり、詳細過ぎて解釈が難しい、もしくはログの量が多すぎてそのせいでプログラムがまともなスピードで動かなかったりなどの理由で、結局使わないことが多いです。デバッグ ビルドのときだけ有効というトレースも多いですが、ビルドし直すのはけっこう手間ですし、そもそもデバッグ ビルドはリリース ビルドとの違いが多すぎて使い物にならなかったりします。

Non-invasive instrumentation の 2 つめの使用例として、Chrome と Edge とでヒープからメモリを確保している場所をフックし、そのときのスレッド ID、確保するサイズ、リターン アドレス、そして確保にかかった CPU のクロック数を記録し、そのパターンの比較を行いました。

ログを仕込むアドレスは以下の 2 箇所を使います。

	フックする関数	確保サイズの場所
Chrome	chrome_child!blink::Node::AllocateObject	第一引数
Edge	edgehtml!MemoryProtection::HeapAllocClear<1>	第一引数

トレースを取るための clove.dll の関数は 200 番で、対象のアドレスを一つパラメーターとして指定します。パフォーマンス計測の実装を簡単にするため、関数の先頭でのみ動くようになっています。したがって、以下のコマンド例で指定されているアドレスは、それぞれのヒープ関数の先頭アドレスです。途中のアドレスにフックすると、おそらくプロセスがクラッシュします。

先に Chrome からデータを取ります。Chrome を起動して、適当なページを開き、以下のコマンドを実行してフックを行ないます。処理が重い cnn.com をテストページとして使っています。

D:\MSWORK> D:\pj\amd64\pj.exe 6024 C:\Windows\fonts\clove.dll?200 00007ffd`f817c390
Hijacking: PID=1788 (WIN64) TID=04a0 VM=000001EA8C120000

適当な操作を行ってデータを取ります。F5 更新やスクロール、リンクのクリックなど何でもいいです。操作が終わったら、前回のケースと同様 3 番の関数をパラメーターなしで実行し、デバッガー上に結果を表示させます。以下のような表示が得られました。

[FunctionTracePack 00007FFDF817C390] 7992 calls (7992 records stored at 000001EA92B49060 000001EA92BA6AE0-1)

このログは、chrome_child!blink::Node::AllocateObject 関数が 7992 回呼ばれ、プロセス内の 000001EA92B49060 のアドレスから始まる領域に 7992 回分のトレースデータが連続して保存されていることを意味します。

デバッガー コンソールには件数とレコードの保存先アドレスが表示されるだけで、データの分析は生のデータをファイルに保存してから自力でやる必要があります。データをファイルに保存するぐらいの機能は clove.dll に実装してもいいのですが、Edge のようにローカル ファイル システムへのアクセスが制限されているプロセスがあり汎用的なものが作れないため、今のところ実装していません。そこで、デバッガーの .writemem コマンドを使ってファイルを保存します。先ほどのデバッガー コンソールに表示されている場所のメモリを .writemem コマンドの保存範囲として指定します。

0:003> .writemem D:\MSWORK\chrome-oilpan-cnn 000001EA92B49060 000001EA92BA6AE0-1
Writing 5da80 bytes.....................................................................

0:003> .dump /ma D:\MSWORK\chrome-cnn.dmp
Creating D:\MSWORK\chrome-cnn.dmp - mini user dump
QuerySystemMemoryInformation failed, 0x80004001
QueryProcessVmCounters failed, 0x80004001
Dump successfully written

後からリターン アドレスなどを分析できるように、ついでにプロセスダンプも取得しておきます。

Chrome はこれで終わりです。次に Edge からデータを取得します。Edge でも同様に cnn.com を開き、コンテンツプロセスに対して 200 番の関数を実行します。その後、適当な操作を行ってから 3 番の関数を実行して結果をデバッガー コンソールに表示させます。結果はこうなりました。まさかの 10 万件越え。現在の clove.dll の実装では、100 万件分のレコードの保存領域を予め確保するようになっているので、ツール的には 10 万程度なら余裕です。

[FunctionTracePack 00007FFE0835BED0] 114016 calls (114016 records stored at 0000027CF3F00020 0000027CF4438220-1)

Chrome のときと同様、表示されているアドレスの範囲を .writemem でファイルに保存し、かつプロセス ダンプを取得します。

0:032> .writemem D:\MSWORK\edge-heap-cnn 0000027CF3F00020 0000027CF4438220-1
Writing 538200 bytes..

0:032> .dump /ma D:\MSWORK\edge-cnn.dmp
Creating D:\MSWORK\edge-cnn.dmp - mini user dump
QuerySystemMemoryInformation failed, 0x80004001
QueryProcessVmCounters failed, 0x80004001
Dump successfully written

保存したデータはバイナリ データで、フォーマットは clove!FunctionTracePack::Record 構造体の std::vector になっています。例えば上記 Edge の一件目のデータは、デバッガーから以下のように確認できます。

0:032> dt clove!FunctionTracePack::Record 0000027CF3F00020
   +0x000 tid_             : 0x1144
   +0x008 ticks_           : 0x16f0
   +0x010 ret_             : 0x00007ffe`080f5aa6 Void
   +0x018 args_            : [3] 0x00000000`000000b8 Void

データは取れたので、加工していろいろ遊んでみましょう。R だとバイナリ ファイルを読み取るのが面倒なので、Python でテキスト データに変換するスクリプトを書きました。

clove.py

import struct
import sys
import numpy as np

def read32(bstr, offset):
  return struct.unpack('I', bstr[offset:offset+4])[0]

def read64(bstr, offset):
  return struct.unpack('Q', bstr[offset:offset+8])[0]

def main():
  filename = sys.argv[1] if len(sys.argv) >= 2 else 'NOFILE'

  linesize = 0x30
  offset_tid = 0x00
  offset_clocks = 0x08
  offset_return = 0x10
  offset_size = 0x18

  with open(filename, 'rb') as f:
    data = f.read()

  n = int(len(data) / linesize)

  threads = np.ndarray(n, dtype=int)
  sizes = np.ndarray(n, dtype=int)
  clocks = np.ndarray(n, dtype=int)
  returns = []

  for i in range(0, n):
    threads[i] = read32(data, i * linesize + offset_tid)
    clocks[i] = read64(data, i * linesize + offset_clocks)
    sizes[i] = read64(data, i * linesize + offset_size)
    returns.append(hex(read64(data, i * linesize + offset_return))[2:])

  with open(filename + '.txt', 'w') as f:
    _ = f.write('TID,AllocSize,Clocks,Return\n')
    for i in range(0, n):
      _ = f.write('%d,%d,%d,%s\n'
                  % (threads[i], sizes[i], clocks[i], returns[i]))

if __name__ == '__main__':
  main()

デバッガーから保存した 2 つのバイナリ ファイルをそれぞれ変換します。元のファイル名に .txt をつけたテキストファイルが生成されます。

$ python clove.py chrome-oilpan-cnn
$ python clove.py edge-heap-cnn
$ head edge-heap-cnn.txt
TID,AllocSize,Clocks
4420,184,5872,7ffe080f5aa6
4420,112,5364,7ffe080f650e
4420,184,6426,7ffe080f5aa6
4420,112,4130,7ffe080f650e
4420,184,4310,7ffe080f5aa6
4420,112,2584,7ffe080f650e
4420,184,5270,7ffe080f5aa6
4420,112,2796,7ffe080f650e
4420,184,14916,7ffe080f5aa6

これでデータが扱いやすくなったので、分析は R で行うことにします。とりあえずデータフレームにロードします。

setwd('D:\\MSWORK')
chrome <- read.table('chrome-oilpan-cnn.txt', header = TRUE, sep = ',')
edge <- read.table('edge-heap-cnn.txt', header = TRUE, sep = ',')

まずはパフォーマンスの傾向を見るため、Clocks の部分をヒストグラムにしてみます。極端にクロック数が大きいデータは除外して、5000 クロック以内のデータに絞ります。

par(mfrow=c(2,1))
hist(subset(chrome, Clocks < 5000)$Clocks, breaks=seq(0,5000,200))
hist(subset(edge, Clocks < 5000)$Clocks, breaks=seq(0,5000,200))

Chrome の関数は、パフォーマンスが速くなるにつれ頻度が上がっています。おそらくほとんどの場合で O(1) の Fast Path が実行されているからだと考えられます。イレギュラーなケースは、もしかすると VirtualAlloc で Region を OS から確保してきたか、スイープ処理が走ったからかもしれません。

Edge は、Chrome ほど綺麗なパターンになっていません。ただし、一方的に Edge の設計が悪いと決めつけることはできません。というのも、今回トレースを取得した関数の性質に違いがあるからです。

Chrome で使った chrome_child!blink::Node::AllocateObject では、確保するオブジェクトは DOM ノードに限られており、Oilpan の特定の Arena だけを使います。したがって、DOM ノード以外のオブジェクト確保/解放の影響は一切受けません。一方 Edge の edgehtml!MemoryProtection::HeapAllocClear<1> は、その名前から DOM ノードの要素に限らず、汎用的なオブジェクトの領域を確保するのに使われているはずです。このことは、同じような操作をしたのに Chrome の関数の実行回数は7992、Edge は 114016 というように大きな違いがあったことからも推測できます。

試しに、各レコードが実行されたスレッドの ID を見てみます。

> unique(chrome$TID)
[1] 4696
> unique(edge$TID)
 [1] 4420 2832 5900 5168 4512 4548  800  312 4048 6580 6652 5500 5968 5780 6648
[16] 6864 5872 5252 5848 4820 4680 3648 5476 2012 4472 3500 1960 1972 1772 6284
[31]   32 5904 5076

Chrome の DOM ノード生成は全て 1 スレッドで処理されているのに対し、Edge は 33 スレッドが関与しており、スレッドの排他制御などで待ち時間が発生してパフォーマンスが低下している可能性が考えられます。詳細は分かりませんが、Chrome の場合は Site Isolation が有効であり、今回トレースを取得したプロセスが cnn.com だけを処理していたのに対し、Edge のプロセスは複数のサイトを複数スレッドで同時に処理していた可能性もあります。その点でも Edge は不利です。

次に、確保したサイズの傾向を見てみます。サイズでも極端に大きな値が含まれているので、それらを除外し、500 バイト以下の領域だけをグラフにしてみました。

par(mfrow=c(2,1))
hist(subset(chrome, AllocSize < 500)$AllocSize, breaks=seq(0,500,20))
hist(subset(edge, AllocSize < 500)$AllocSize, breaks=seq(0,500,20))

面白いことに、Chrome の方は DOM ノード限定で Edge は汎用であるにも関わらず、同じようなパターンが現れました。100 バイトのあたりにピークがあり、200 のあたりにもう一つのピークがあります。リターンアドレスを使って、それぞれ何のオブジェクトを作っているのかを推測することもできそうです。

リターン アドレスを見ると、どこからの関数呼び出しがあったのかをアセンブリ言語レベルで特定できます。まずは頻度分析をして棒グラフを作ってみます。

freq_table.chrome <- sort(table(chrome$Return), decreasing=TRUE)
freq_table.edge <- sort(table(edge$Return), decreasing=TRUE)

par(mfrow=c(2,1))
barplot(freq_table.chrome)
barplot(freq_table.edge)

このグラフからは特に何も読み取れなさそうです。では最後に、頻度が多かった呼び出し箇所はどこだったのかを特定してみます。Top 2 を見ます。

> head(freq_table.chrome / sum(freq_table.chrome), n = 2)
7ffdf8405a29 7ffdf844bd05 
   0.1705455    0.1338839 

> head(freq_table.edge / sum(freq_table.edge), n = 2)
7ffe0847260b 7ffe080f630e 
   0.1063710    0.0932413 

Top 2 で Chrome は全体の 30%、Edge は 20% を占めています。アドレスからシンボル名を見るには、先ほど取得しておいたプロセス ダンプを使います。まずは Chrome から。

0:003> ub 7ffdf8405a29 l1
chrome_child!blink::Text::Create+0x14:
00007ffd`f8405a24 e86769d7ff      call    chrome_child!blink::Node::AllocateObject (00007ffd`f817c390)
0:003> ub 7ffdf844bd05 l1
chrome_child!blink::HTMLDivElement::Create+0x10:
00007ffd`f844bd00 e88b06d3ff      call    chrome_child!blink::Node::AllocateObject (00007ffd`f817c390)

1 位はテキスト ノード、2 位が DIV エレメントでした。これはとても納得のいく結果です。CNN のページの 17% はテキスト ノード、13% は DIV エレメントで構成されていると言えるかもしれません。

次に Edge を見ます。

0:032> ub 7ffe0847260b  l1
edgehtml!Tree::ElementNode::GetComputedStyle+0x42:
00007ffe`08472606 e8c598eeff      call    edgehtml!MemoryProtection::HeapAllocClear<1> (00007ffe`0835bed0)
0:032> ub 7ffe080f630e l1
edgehtml!CSCASerializationContext::CloneStreamFromVar+0x39:
00007ffe`080f6309 e8c25b2600      call    edgehtml!MemoryProtection::HeapAllocClear<1> (00007ffe`0835bed0)

これは名前からは判断がつきません。GetComputedStyle の方は CSS 関連な感じはしますが、CSCASerializationContext はさっぱり見当がつきません。さらに調べるとすれば、ライブデバッグしてコールスタックを見る、などの方法が思いつきます。

以上、Non-invasive instrumentation を使って関数のトレースを取得する例について紹介しました。今回の例よりも、より比較しやすい関数をチョイスすれば、もう少し遊べるデータが取れると思います。Chrome で PartitionAlloc と Oilpan とを比較してみても面白そうです。

(余談) パブリック シンボル を使った edgehtml.dll のデバッグ

ところで、そもそもソースコードが公開されていない edgehtml のヒープってどこにあるんだ、って話ですが、edgehtml!CElement::CElement みたいなコンストラクターで適当に止めて、その前の処理を見ると分かります。こんな感じ。

0:018> g
Breakpoint 0 hit
edgehtml!CElement::CElement:
00007ffe`28532bb0 48895c2408      mov     qword ptr [rsp+8],rbx ss:000000e9`ad9fcac0=000001fd78d13040
0:018> kL4
Child-SP          RetAddr           Call Site
000000e9`ad9fcab8 00007ffe`285ea56c edgehtml!CElement::CElement
000000e9`ad9fcac0 00007ffe`284a035a edgehtml!CHeadElement::CreateElement+0x3c
000000e9`ad9fcaf0 00007ffe`284a026f edgehtml!CreateElement+0x7a
000000e9`ad9fcb40 00007ffe`285e4686 edgehtml!CHtml5TreeConstructor::InsertAnHTMLElement+0x5f
0:018> ub 00007ffe`285ea56c l10
edgehtml!CHeadElement::CreateElement+0x5:
00007ffe`285ea535 57              push    rdi
00007ffe`285ea536 4883ec20        sub     rsp,20h
00007ffe`285ea53a bbd8000000      mov     ebx,0D8h
00007ffe`285ea53f 488bfa          mov     rdi,rdx
00007ffe`285ea542 8bcb            mov     ecx,ebx
00007ffe`285ea544 e88719e0ff      call    edgehtml!MemoryProtection::HeapAllocClear<1> (00007ffe`283ebed0)
00007ffe`285ea549 8bd3            mov     edx,ebx
00007ffe`285ea54b 488bc8          mov     rcx,rax
00007ffe`285ea54e e80d10fcff      call    edgehtml!Abandonment::CheckAllocationUntyped (00007ffe`285ab560)
00007ffe`285ea553 488bd8          mov     rbx,rax
00007ffe`285ea556 4885c0          test    rax,rax
00007ffe`285ea559 7429            je      edgehtml!CHeadElement::CreateElement+0x54 (00007ffe`285ea584)
00007ffe`285ea55b 41b835000000    mov     r8d,35h
00007ffe`285ea561 488bd7          mov     rdx,rdi
00007ffe`285ea564 488bc8          mov     rcx,rax
00007ffe`285ea567 e84486f4ff      call    edgehtml!CElement::CElement (00007ffe`28532bb0)

edgehtml!MemoryProtection::HeapAllocClear<1> とかいうのがそれっぽいですね。その関数の呼び出し前のコードを見ると、0D8h という即値が ebx を経由して ecx に渡されており、おそらくこれが edgehtml!CHeadElement というクラスのサイズでしょう。C++ でオブジェクトを new するコードは、アセンブリで見るとヒープから固定サイズを確保してコンストラクターを呼び出すコードにコンパイルされるからです。

念のため、edgehtml!MemoryProtection::HeapAllocClear<1> にブレークポイントを設定してステップ オーバーを繰り返してみます。

0:018> g
Breakpoint 0 hit
edgehtml!MemoryProtection::HeapAllocClear<1>:
00007ffe`283ebed0 4053            push    rbx
0:018> r
rax=00007ffe284dce90 rbx=0000020579930020 rcx=0000000000000160
rdx=0000020579930020 rsi=0000020579930020 rdi=00007ffe291631a0
rip=00007ffe283ebed0 rsp=000000e9ad9fca88 rbp=000000e9ad9fcb50
 r8=0000020579930020  r9=000001fd27f2aae0 r10=00000fffc509b9d2
r11=0000000000040000 r12=000000e9ad9fcb58 r13=000001fd28a43800
r14=000001fd201b06b8 r15=000001fd27f42a00
iopl=0         nv up ei pl nz na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
edgehtml!MemoryProtection::HeapAllocClear<1>:
00007ffe`283ebed0 4053            push    rbx
0:018> p
edgehtml!MemoryProtection::HeapAllocClear<1>+0x2:
00007ffe`283ebed2 4883ec20        sub     rsp,20h
0:018>
edgehtml!MemoryProtection::HeapAllocClear<1>+0x6:
00007ffe`283ebed6 488bd9          mov     rbx,rcx

...ひたすらステップオーバー...

0:018>
edgehtml!MemoryProtection::HeapAllocClear<1>+0x33:
00007ffe`283ebf03 5b              pop     rbx
0:018>
edgehtml!MemoryProtection::HeapAllocClear<1>+0x34:
00007ffe`283ebf04 48ff25e5590b01  jmp     qword ptr [edgehtml!_imp_?MemProtectHeapRootAllocYAPEAXPEAX_KZ (00007ffe`294a1
8f0)] ds:00007ffe`294a18f0={chakra!MemProtectHeapRootAlloc (00007ffe`27bdccf0)}
0:018>
chakra!MemProtectHeapRootAlloc:
00007ffe`27bdccf0 4c8bdc          mov     r11,rsp
0:018> r
rax=0000000000000003 rbx=0000020579930020 rcx=000001fd78d13040
rdx=0000000000000160 rsi=0000020579930020 rdi=00007ffe291631a0
rip=00007ffe27bdccf0 rsp=000000e9ad9fca88 rbp=000000e9ad9fcb50
 r8=0000020579930020  r9=000001fd27f2aae0 r10=00000fffc509b9d2
r11=0000000000040000 r12=000000e9ad9fcb58 r13=000001fd28a43800
r14=000001fd201b06b8 r15=000001fd27f42a00
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
chakra!MemProtectHeapRootAlloc:
00007ffe`27bdccf0 4c8bdc          mov     r11,rsp
0:018>

突然 jmp してchakra!MemProtectHeapRootAlloc に来ました。この後も実行を続けるとchakra!Memory::Recycler::RealAlloc<8,1> とかいう関数にたどり着くのですが、そこまでしなくても MemProtectHeapRootAlloc でググると、GitHub にある ChakraCore のコードがヒットして、第一引数が memProtectHeapHandle というポインター、第二引数が要求サイズだと分かります。第二引数は rdx なので上記例だと 0x160 で、同じ値が edgehtml!MemoryProtection::HeapAllocClear<1> のときには rcx にあり、確かに第一引数として渡されているらしいことが分かります。というわけで、edgehtml!MemoryProtection::HeapAllocClear<1> が edgehtml におけるヒープの関数で、第一引数が確保したいサイズだと推定できました。

制約など

2 つの事例から、ツールの動かし方や結果の見方を紹介しました。ここでは、事例では記載しきれなかった技術的な制約について紹介します。

フックできないコードのレイアウトについて

近接しすぎた箇所同士

Detours は、指定したアドレスのコードを jmp +rel32 命令に置き換えるため、フックできない範囲が存在します。例えば以下のコードのうち、00007ff6`82fc3e12 の rbp 命令のところをフックするとします。

notepad!SetTitle:
00007ff6`82fc3e08 48895c2410      mov     qword ptr [rsp+10h],rbx
00007ff6`82fc3e0d 48897c2418      mov     qword ptr [rsp+18h],rdi
00007ff6`82fc3e12 55              push    rbp
00007ff6`82fc3e13 488dac24d0f8ffff lea     rbp,[rsp-730h]
00007ff6`82fc3e1b 4881ec30080000  sub     rsp,830h
00007ff6`82fc3e22 488b05bfe40100  mov     rax,qword ptr [notepad!_security_cookie (00007ff6`82fe22e8)]

フックした後のコードはこうなります。

notepad!SetTitle:
00007ff6`82fc3e08 48895c2410      mov     qword ptr [rsp+10h],rbx
00007ff6`82fc3e0d 48897c2418      mov     qword ptr [rsp+18h],rdi
00007ff6`82fc3e12 e961c3febf      jmp     00007ff6`42fb0178
00007ff6`82fc3e17 cc              int     3
00007ff6`82fc3e18 cc              int     3
00007ff6`82fc3e19 cc              int     3
00007ff6`82fc3e1a cc              int     3
00007ff6`82fc3e1b 4881ec30080000  sub     rsp,830h

00007ff6`82fc3e12 に jmp 命令が置かれ、その次の lea 命令の置かれていた場所は全て int 3 である 0xcc で埋められています。この0xcc の部分すると、そもそも実行されない上、今度は 00007ff6`82fc3e1b の命令が書き換わってしまうのでフックしてはいけません。

この動作から、フックする箇所から 5 バイト先までの範囲がカバーする命令が埋められている場所はフックができません。

ret 命令

上記と同様の理由で、ret 命令を直接フックするのは危険です。例えば、notepad!SetTitle の ret 近傍のコードを見てみましょう。

0:001> u 00007ff6`82fc3f69 l10
notepad!SetTitle+0x161:
00007ff6`82fc3f69 e882540100      call    notepad!_security_check_cookie (00007ff6`82fd93f0)
00007ff6`82fc3f6e 4c8d9c2430080000 lea     r11,[rsp+830h]
00007ff6`82fc3f76 498b5b18        mov     rbx,qword ptr [r11+18h]
00007ff6`82fc3f7a 498b7b20        mov     rdi,qword ptr [r11+20h]
00007ff6`82fc3f7e 498be3          mov     rsp,r11
00007ff6`82fc3f81 5d              pop     rbp
00007ff6`82fc3f82 c3              ret
00007ff6`82fc3f83 cc              int     3
notepad!NpResetMenu:
00007ff6`82fc3f84 48895c2408      mov     qword ptr [rsp+8],rbx
00007ff6`82fc3f89 55              push    rbp
00007ff6`82fc3f8a 56              push    rsi
00007ff6`82fc3f8b 57              push    rdi
00007ff6`82fc3f8c 4156            push    r14
00007ff6`82fc3f8e 4157            push    r15
00007ff6`82fc3f90 4883ec20        sub     rsp,20h
00007ff6`82fc3f94 4c8bf1          mov     r14,rcx

ret の後 1 バイト 0xcc が置かれていて、そのすぐ次は別の関数の開始アドレスになっています。もし ret をフックすると、次の関数 notepad!NpResetMenu の先頭アドレスが書き換えられてしまうので、notepad!NpResetMenu が呼ばれたときに変な命令を実行しようとしてクラッシュします。ただし、そもそも Detours API はフックしようとする部分に int 3 があるとエラーを返すようになっているのでフックそのものが失敗します。

したがって、関数の最後の部分をフックしたい場合には ret から少なくとも 5 バイト上流の場所を選ぶ必要があります。特に 64bit コンパイラーの場合は関数が密に充填されているので、ほとんどの場合 ret 命令を直接フックすることはできません。

フック先にジャンプするコードがある場合

少し見つけづらい例ですが、以下のコードで 00007fff`4ce8e838 をフックしてはいけません。理由は、00007fff`4ce8e836 の位置にある jmp 命令のジャンプ先が 00007fff`4ce8e83b になっているからです。

0:001> u 00007fff`4ce8e82e
COMDLG32!GetFileTitleW+0x5e:
00007fff`4ce8e82e 488bc8          mov     rcx,rax
00007fff`4ce8e831 e8d63b0000      call    COMDLG32!StringCchCopyW (00007fff`4ce9240c)
00007fff`4ce8e836 eb03            jmp     COMDLG32!GetFileTitleW+0x6b (00007fff`4ce8e83b)
00007fff`4ce8e838 498bdf          mov     rbx,r15
00007fff`4ce8e83b 440fb7c5        movzx   r8d,bp
00007fff`4ce8e83f 498bd6          mov     rdx,r14
00007fff`4ce8e842 488bcb          mov     rcx,rbx
00007fff`4ce8e845 e82e000000      call    COMDLG32!GetFileTitleX (00007fff`4ce8e878) 

もしフックするとコードは以下のようになり、00007fff`4ce8e83b は命令の境界からずれたアドレスになります。このときもし 00007fff`4ce8e836 からのジャンプが発生するとプロセスがクラッシュします。

0:002> u 00007fff`4ce8e82e
COMDLG32!GetFileTitleW+0x5e:
00007fff`4ce8e82e 488bc8          mov     rcx,rax
00007fff`4ce8e831 e8d63b0000      call    COMDLG32!StringCchCopyW (00007fff`4ce9240c)
00007fff`4ce8e836 eb03            jmp     COMDLG32!GetFileTitleW+0x6b (00007fff`4ce8e83b)
00007fff`4ce8e838 e93b19febf      jmp     00007fff`0ce70178
00007fff`4ce8e83d cc              int     3
00007fff`4ce8e83e cc              int     3
00007fff`4ce8e83f 498bd6          mov     rdx,r14
00007fff`4ce8e842 488bcb          mov     rcx,rbx

フックするアドレスを選ぶときは、jmp に置き換わる部分が別のところからのジャンプ先になっていないことも確認する必要があります。

Windows のプロセス保護

ブラウザーなど、インターネット上のデータをメモリにロードするようなプロセスは、そのデータが悪意あるコードで未知の RCE などを引き起こす可能性があるため、万が一プロセスが乗っ取られても被害が最小限に抑えられるように通常のプロセスよりも権限が制限されていることがあります。インジェクトされたコードも、当然ターゲットのプロセスと同じ権限で動作するため、その制限の影響を受けて意図した通りに動かない場合があります。また、そもそもインジェクトが失敗するプロセスもあります。その回避方法について説明します。

Windows の各プロセスには Integrity Level という権限レベルが割り当てられています。Integrity Level は Process Explorer や Process Hacker で見ることができます。

• System: SYSTEM ユーザーで動くプロセス。主に Windows サービス。
• High: Administrator ユーザーで動くプロセス。UAC プロンプト経由でユーザーの承認が必要。
• Medium: 既定のレベル。
• Low: Protected Mode が有効のときの Internet Explorer や、Firefox のコンテント プロセス。
• Untrusted: Chrome のレンダー プロセス。
• AppContainer: UWP アプリケーション (いわゆる Windows Store アプリ)。Microsoft Edge のコンテント プロセス。

Non-invasive instrumentation で問題になるのは、ファイルへのアクセス権です。Medium 以上のレベルでは、ローカル ファイル システムへのアクセスはプロセスの実行ユーザーに依存するのみで、ユーザーにアクセス権があればファイルへのアクセスが可能です。しかし Low 以下では、ユーザーにアクセス権があったとしても、明示的に Low Integrity Level や各 AppContainer に対してアクセス権が設定されていないファイルにはアクセスできません。

Integrity Level によるファイル アクセスの制限は、インジェクト対象である clove.dll にも適用されます。もしプロセスが clove.dll にアクセスできない場合は、そもそも DLL をロードできないため、インジェクションが失敗します。これを Clove.dll の権限変更で対応することもできますが、けっこう面倒な作業なので、どんなプロセスからも見える場所に DLL をコピーしておくのが簡単な方法です。万能な場所が、ケーススタディのところで使った C:\Windows\Fonts フォルダーです。コピーしたときにフォルダーの権限が自動的に継承されるので、ファイルをコピーするだけで済みます。System32 フォルダーもほとんどの場合に使えますが、Untrusted プロセスである Chrome からは System32 配下のファイルが見えないので Chrome には使えません。

Code Integrity Guard (例: Google Chrome, Microsoft Edge)

最近の Windows には CIG という保護機能が導入され、ユーザーモードのプロセスでもロードするモジュールにデジタル署名を要求することができるようになりました。そのようなプロセスは、インジェクト対象の clove.dll にも署名を要求し、署名がなければロードが失敗します。CIG のレベルは EPROCESS の SignatureLevel と SectionSignatureLevel から確認できます。Google Chrome と Microsoft Edge の値を見てみましょう。

lkd> !process 0n5148 0
Searching for Process with Cid == 141c
PROCESS ffffd48098cf5080
    SessionId: 1  Cid: 141c    Peb: aa91b42000  ParentCid: 033c
    DirBase: 11000000  ObjectTable: ffffbd81025f39c0  HandleCount: 1119.
    Image: MicrosoftEdgeCP.exe
lkd> dt nt!_EPROCESS ffffd48098cf5080 SectionSignatureLevel SignatureLevel
   +0x6c8 SignatureLevel        : 0x8 ''
   +0x6c9 SectionSignatureLevel : 0x6 ''

lkd> !process 0n5480 0
Searching for Process with Cid == 1568
PROCESS ffffd480956b0080
    SessionId: 1  Cid: 1568    Peb: 19903aa000  ParentCid: 18cc
    DirBase: 5c840000  ObjectTable: ffffbd8103328640  HandleCount: 296.
    Image: chrome.exe
lkd> dt nt!_EPROCESS ffffd480956b0080 SectionSignatureLevel SignatureLevel
   +0x6c8 SignatureLevel        : 0x8 ''
   +0x6c9 SectionSignatureLevel : 0x8 ''

Clove で問題になるのは SectionSignatureLevel の方で、これは実行権限を持つページにマップされるモジュールに要求する署名レベルを表しています。8 や 6 といった数値の意味は、Alex Ionescu 氏のブログの以下の記事に書かれており、8=Microsoft, 6=Store です。

Protected Processes Part 3 : Windows PKI Internals (Signing Levels, Scenarios, Root Keys, EKUs & Runtime Signers) « Alex Ionescu’s Blog
http://www.alex-ionescu.com/?p=146

上記結果から、Chrome も Edge も、インジェクトする clove.dll にデジタル署名を要求します。しかし Edge の場合、bcdedit /set testsigning on を実行して testsigning モードを有効にするとなぜか SectionSignatureLevel が 0 になり、DLL への署名は不要になります。

Chrome は Edge よりも要求レベルが厳しく、testsigning モードが有効でも SectionSignatureLevel は 8 のままです。これをユーザー プログラムから何とかする方法は見つけられなかったので、Chrome へのインジェクトを成功させるには、カーネル デバッガーで SectionSignatureLevel を 0 に設定して CIG を強引に解除する必要があります。作業としてはデバッガーで eb コマンドを実行するだけです。Windows 10 だとローカル カーネル デバッグが使えるので、難しくはありません。

lkd> !process 0n7516 0
Searching for Process with Cid == 1d5c
PROCESS ffff808c7f9c6080
    SessionId: 1  Cid: 1d5c    Peb: c25854f000  ParentCid: 1c18
    DirBase: 2ddb00000  ObjectTable: ffffd6839e1e3640  HandleCount: 415.
    Image: chrome.exe

lkd> dt nt!_EPROCESS ffff808c7e5b0080 SignatureLevel SectionSignatureLevel
   +0x6c8 SignatureLevel        : 0x8 ''
   +0x6c9 SectionSignatureLevel : 0 ''
lkd> eb ffff808c7e5b0080+6c9 0
lkd> dt nt!_EPROCESS ffff808c7e5b0080 SignatureLevel SectionSignatureLevel
   +0x6c8 SignatureLevel        : 0x8 ''
   +0x6c9 SectionSignatureLevel : 0 ''

少し前に書いた記事で、PPLKiller というドライバーを紹介しました。このドライバーは SectionSignatureLevel の値も 0 に書き換えるので、デバッガーを使わず PPLKiller で解除する方法も有効です。

Windows 10 の保護プロセスを jailbreak してデバッガーをアタッチする方法 - Qiita
https://qiita.com/msmania/items/19547606b9c197c64d70

Arbitrary Code Guard (例: Microsoft Edge)

CIG に加え、Edge では ACG という保護機能も有効になっています。ACG とは、実行可能なメモリ領域が動的に作成/変更されることを防ぐ機能です。例えば Detours では、トランポリン関数を作るために VirtualAlloc で PAGE_EXECUTE_READWRITE 権限のページを確保します。ACG が有効な場合、このような要求は ERROR_DYNAMIC_CODE_BLOCKED というエラーコードで失敗します。したがって clove.dll のインジェクトは成功しても、フックが失敗します。

Edge の場合、testsigning モードを有効にすると、CIG とともに ACG も無効になります。あっけない解除方法ですが、それだけです。

ACG は、GetProcessMitigationPolicy におけるProcessDynamicCodePolicy というポリシーです。そしてこのポリシーは SetProcessMitigationPolicy で変更できることになっています。が、この API はポリシーを有効にすることはできても無効にすることはできないようです。とはいうものの、Process Hacker のコードを見ると、この Mitigation Policy は結局 NtSetInformationProcess というシステムコールを直接実行して変更できるみたいなので、pj.exe に ACG を解除するロジックを実装して -d オプションで実行できるようにしてあります。何らかの理由で testsigning モードが使えない場合は試してみてください。

Edge の保護機能や ACG の参考資料はこちらです。

Mitigating arbitrary native code execution in Microsoft Edge
https://blogs.windows.com/msedgedev/2017/02/23/mitigating-arbitrary-native-code-execution/

Microsoft's strategy and technology improvements for mitigating native remote code execution
https://cansecwest.com/slides/2017/CSW2017_Weston-Miller_Mitigating_Native_Remote_Code_Execution.pdf

おわりに

以上、Non-invasive instrumentation を行なうツールの紹介でした。いまいち記事のポイントを絞り切れず、非常に読みづらいものになってしまった気がします。もともとはケース スタディ 1 のような仕事の依頼が来たことがきっかけでアイディアを思いついて、Detours がオープンソースになったことを知って実装に着手しました。

本記事は事例の紹介を中心にして、新たなフック用の関数を実装する方法について触れていません。本来は GitHub にちゃんとした README を書くべきなのでしょうが、ProcJack の README をそれなりに真面目に書いたところで力尽きました。繰り返し手前味噌ですが、応用範囲は広く、多くの人に使ってもらいたいので、そのうち Clove の README は書くと思います。

このプロジェクトをベースにいろいろと他のアイディアも思い浮かんできたので、しばらく開発意欲が継続しそうです。