Windows内部解析サービス
豊田孝の「IT談話館」 Windowsメモリダンプ解析を依頼する WinDbgとシステム分析




本記事は、書籍 「インサイド Microsoft Windows」 程度の基礎知識をお持ちの方を想定しています。

講演申し込み



Windows 8/10のJobオブジェクト


 WindowsはSaaSとして提供される時代に入り、その内部は頻繁に更新されています。更新内容の多くは、いろいろな事情と理由から、公にされることはほとんどありません。
 Windows 10の短周期の内部更新は、性能向上と互換性維持に加え、ML/DL/AI時代への対応と位置付けられています。簡単に表現すれば、Windows 10はCloudサービスと連携しながらBig Dataを収集・蓄積する「ソフトウェアセンサー」、という役割を担っています。本「IT談話館」は、そのソフトウェアセンサーのユーザー空間とカーネル空間を独自の解析コードで詳しく解析する技術を保有し、「Windowsメモリダンプ解析サービス」を提供しています。
 メモリダンプを解析すると、システム内の「異様な動き」を検出・解析することができます。「異様な動き」の中には、システムパフォーマンスの低下、既存アプリの動作異常、あるいは、セキュリティー脅威なども含まれます。本館サービスをご利用の際には、所属チーム内でご協議の上、「ご連絡」ください。

 セキュリティーの視点からWindows10ソフトウェアセンサーを見た場合、本「IT談話館」の確認範囲では、次のような保護メカニズム階層が考案・実装されています。下記リンクはすべて本館記事を指しています。
  1. Silo/Server Silo
  2. Job
  3. Session
  4. Protected Process
  5. Mandatory Integrity Control(MIC)
  6. Windows API(+CPU)
  7. CPU

 本稿では、「Windows 8/10とJobオブジェクト(基礎)」前編に続き、Windows 8出荷タイミングで設計変更されたJobオブジェクトを取り上げます。前編ではJobオブジェクトを次のように整理しました。  本稿では、Windows 10環境で採取された新旧2種類の「Active Memory Dump」を本館の独自解析コードで解析し、Google社のChromeにおけるJobオブジェクトの実装過程を考察します。なお、独自解析コードの開発知識の習得には、「時間と予算」の投資が必要です。

 まずは、次のメモリダンプを解析してみます。
1: kd> vertarget
Windows 10 Kernel Version 17134 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 17134.1.amd64fre.rs4_release.180410-1804
Machine Name:
Kernel base = 0xfffff801`63699000 PsLoadedModuleList = 0xfffff801`63a561d0
Debug session time: Fri May 11 07:58:31.309 2018 (UTC + 9:00)
System Uptime: 0 days 0:32:48.173
 このメモリダンプは、2018年5月11日に採取されています。このダンプを解析してみます。
0xffffd30645650080	chrome.exe
0xffffd306474da580	chrome.exe
0xffffd306475e0080	chrome.exe
0xffffd306475f3080	eJob->0xffffd306478a3060	ProcLimit->1	TotalProcs->0001	ActiveProcs->1	InactiveProcs->0	chrome.exe
	+01: 0xffffd306475f3080	eJob->0xffffd306478a3060	ActiveThread->012	chrome.exe
0xffffd30647005080	eJob->0xffffd306474d3060	ProcLimit->1	TotalProcs->0001	ActiveProcs->1	InactiveProcs->0	chrome.exe
	+01: 0xffffd30647005080	eJob->0xffffd306474d3060	ActiveThread->016	chrome.exe
 この結果を見ると、Rendererと呼ばれる2つのプロセス「0xffffd306475f3080」と「0xffffd30647005080」がJobオブジェクトの制御下で動作していることが分かります。これらのプロセスは、次のようにControllerと呼ばれるプロセス「0xffffd30645650080」によって生成され、Sandbox化されています。
1: kd> !process 0xffffd306475f3080 0
PROCESS ffffd306475f3080
    SessionId: 1  Cid: 0e2c    Peb: de77d53000  ParentCid: 186c
    DirBase: acf00000  ObjectTable: ffff91043a9f0300  HandleCount: 421.
    Image: chrome.exe

1: kd> !process 0xffffd30647005080 0
PROCESS ffffd30647005080
    SessionId: 1  Cid: 1f08    Peb: 55f34a000  ParentCid: 186c
    DirBase: 115f00000  ObjectTable: ffff9104356f9700  HandleCount: 350.
    Image: chrome.exe

1: kd> !process 186c 0
Searching for Process with Cid == 186c
PROCESS ffffd30645650080
    SessionId: 1  Cid: 186c    Peb: 55ae4ec000  ParentCid: 09a0
    DirBase: 93200000  ObjectTable: ffff91043ae2f780  HandleCount: 1177.
    Image: chrome.exe
 Sandbox化プロセス以外の「0xffffd30645650080」をはじめとするプロセスはJobオブジェクトの制御下に入っていません。なぜ?という疑問が沸きますが、次の比較的新しいメモリダンプの解析結果を見てみます。
0: kd> vertarget
Windows 10 Kernel Version 18362 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 18362.1.amd64fre.19h1_release.190318-1202
Machine Name:
Kernel base = 0xfffff804`59a00000 PsLoadedModuleList = 0xfffff804`59e480b0
Debug session time: Sun Nov  3 09:56:47.110 2019 (UTC + 9:00)
System Uptime: 0 days 1:42:54.949
 このダンプは、2019年11月3日に採取されています。先ほどと同じ解析コードを実行し、情報を収集します。
0xffffc48924b9a080	eJob->0xffffc48927174080	ProcLimit->0	TotalProcs->0025	ActiveProcs->6	InactiveProcs->0	chrome.exe
	+01: 0xffffc48924b9a080	eJob->0xffffc48927174080	ActiveThread->030	chrome.exe
	+02: 0xffffc489267ee080	eJob->0xffffc48927174080	ActiveThread->008	chrome.exe
	+03: 0xffffc48924bf5080	eJob->0xffffc48927174080	ActiveThread->003	chrome.exe
	+04: 0xffffc489264e1080	eJob->0xffffc48927174080	ActiveThread->000	chrome.exe
	+05: 0xffffc48920b72080	eJob->0xffffc48927174080	ActiveThread->000	chrome.exe
0xffffc489267ee080	eJob->0xffffc48927174080	ProcLimit->0	TotalProcs->0025	ActiveProcs->6	InactiveProcs->0	chrome.exe
	+01: 0xffffc48924b9a080	eJob->0xffffc48927174080	ActiveThread->030	chrome.exe
	+02: 0xffffc489267ee080	eJob->0xffffc48927174080	ActiveThread->008	chrome.exe
	+03: 0xffffc48924bf5080	eJob->0xffffc48927174080	ActiveThread->003	chrome.exe
	+04: 0xffffc489264e1080	eJob->0xffffc48927174080	ActiveThread->000	chrome.exe
	+05: 0xffffc48920b72080	eJob->0xffffc48927174080	ActiveThread->000	chrome.exe
0xffffc48924bf5080	eJob->0xffffc48927174080	ProcLimit->0	TotalProcs->0025	ActiveProcs->6	InactiveProcs->0	chrome.exe
	+01: 0xffffc48924b9a080	eJob->0xffffc48927174080	ActiveThread->030	chrome.exe
	+02: 0xffffc489267ee080	eJob->0xffffc48927174080	ActiveThread->008	chrome.exe
	+03: 0xffffc48924bf5080	eJob->0xffffc48927174080	ActiveThread->003	chrome.exe
	+04: 0xffffc489264e1080	eJob->0xffffc48927174080	ActiveThread->000	chrome.exe
	+05: 0xffffc48920b72080	eJob->0xffffc48927174080	ActiveThread->000	chrome.exe
0xffffc48925830080	eJob->0xffffc48926db2080	ProcLimit->1	TotalProcs->0001	ActiveProcs->1	InactiveProcs->0	chrome.exe
	+01: 0xffffc48925830080	eJob->0xffffc48926db2080	ActiveThread->012	chrome.exe
0xffffc48925cce080	eJob->0xffffc48926db0080	ProcLimit->0	TotalProcs->0001	ActiveProcs->1	InactiveProcs->0	chrome.exe
	+01: 0xffffc48925cce080	eJob->0xffffc48926db0080	ActiveThread->015	chrome.exe
0xffffc48926deb080	eJob->0xffffc489265ec080	ProcLimit->1	TotalProcs->0001	ActiveProcs->1	InactiveProcs->0	chrome.exe
	+01: 0xffffc48926deb080	eJob->0xffffc489265ec080	ActiveThread->012	chrome.exe
 この情報を見ると、Google社のChromeチームはJobオブジェクトの適応範囲を劇的に変更しています。つまり、Rendererプロセスだけではなく、Controllerプロセス「0xffffc48924b9a080」をはじめとする他のプロセスもJobオブジェクトの制御下に置いています。ちなみに、すべてのJobオブジェクトのFlagは次のように設定され、Sandbox化が進められていることが分かります。
+001: 0xffffc48924b9a080	EJob->0xffffc48927174080	Flags->01800000	LFlags->0x800	Flags2->0x0	TotalProc->25	ActiveProc->0006	chrome.exe
+002: 0xffffc489267ee080	EJob->0xffffc48927174080	Flags->01800000	LFlags->0x800	Flags2->0x0	TotalProc->25	ActiveProc->0006	chrome.exe
+003: 0xffffc48924bf5080	EJob->0xffffc48927174080	Flags->01800000	LFlags->0x800	Flags2->0x0	TotalProc->25	ActiveProc->0006	chrome.exe
+004: 0xffffc48925830080	EJob->0xffffc48926db2080	Flags->01800010	LFlags->0x2108	Flags2->0x0	TotalProc->1	ActiveProc->0001	chrome.exe
+005: 0xffffc48925cce080	EJob->0xffffc48926db0080	Flags->01800010	LFlags->0x2000	Flags2->0x0	TotalProc->1	ActiveProc->0001	chrome.exe
+006: 0xffffc48926deb080	EJob->0xffffc489265ec080	Flags->01800010	LFlags->0x2508	Flags2->0x0	TotalProc->1	ActiveProc->0001	chrome.exe
 この情報も本館の独自解析コードで取得しています。個々のフラグをビットレベルで解析すると、これら複数のChromeプロセスの様々な性質や設計変更内容が手に取るように分かります。時には、担当開発者たちの思考回路をはじめとする、きわめて興味深い情報さえ取得できます。

 以上、Google社のChromeチームのJobオブジェクトの応用過程を解析してみました。Chromeチームは人材が豊富でブラウザ分野で圧倒的な地位を示しているといわれていますが、Windows 8で大幅に仕様変更されたJobオブジェクトの実践的な応用にはそれなりの研究時間が必要であったことが推察されます。なお、上記情報をよく吟味してみると、いくつかの不可解なデータも散見されます。たとえば、実行中スレッドを1個も持たないChromeプロセスの姿などが検出されています。セキュリティー上は好ましいことではないでしょうが、本稿ではその方面の解析紹介は割愛します。

 なお、JobオブジェクトはWindows 10ではSiloやServer Siloと不可分の関係を持つようになりました。この方面の情報は本館の「この記事」で提供しています。


「Windowsメモリダンプ解析サービス」のご案内

講演申し込み




本「IT談話館」は書籍 「インサイド Microsoft Windows」 程度の基礎知識をお持ちの方々を想定しています。
プロ向けのWindowsメモリ内部解析技術資料

Copyright©豊田孝 2004- 2020
本日は2020-04-07です。