|
|
|
WMIACPI.SYS
0 U$ f% n0 r0 l7 S5 O+ K# V0 a1. WMI Concept: t! ?5 W7 z$ k' \5 i
9 K( I8 x4 H: F1 w' q! T
WMI全称Windows Management Instrumentation是一种管理计算机系统的方式。它是微软基于WBEM的实现,WMI希望为系统管理以及分布式数据描述提供一种模型,并且允许使用基于COM的user mode API对系统部件进行访问、管理、控制。
1 |) t) e5 }; p8 L$ C3 J% \, _% P7 F- e
* k, I! g' q* ]- c2 W/ u9 ^2 k2. WMIACPI.SYS7 n9 U. U0 ?( C" u
4 x: \$ c8 L* {& {Wmiacpi.sys 是微软提供的一只generic mapping driver它的Plug and Play ID为 PNP0c14.,ACPI包含丰富的系统信息,OEM厂商可以利用这支mapping driver定制平台相关的功能而且允许使用WMI获取,如此便可以在单机或者在网络环境中获得平台的特定信息。关于如何在BIOS、OS中定制wmiacpi,bini已经给出了非常详细的讲解,有兴趣可以参考bini的文章。在这里我会讲解一下原理部分。ACPI-to-WMI mapping function是通过下述两只driver达成的:* F- `! t$ g. n+ B
A.Acpi.sys4 R# H- p- p% Q4 J. M2 F: @
B.Wmiacpi.sys& B( V6 ^. Z- o1 s3 |4 M5 ], Y
A).Acpi.sys的一个主要功能是解释和执行aml,而aml就是asl code的机器码,所以ACPI asl code真正的执行是由acpi.sys触发的,而不是BIOS主动执行的。它的另一个功能就是查找ACPI spec定义的device Plug and Play ID,并据此创建相应的software device后续OS会为这些device加载对应driver。如power button driver,battery driver,lid driver,fan driver等等。Device 对应的Plug and Play ID可以查阅ACPI spec获得。# x& G# \, l! v( g5 Q: D
B).Wmiacpi.sys它的Plug and Play ID为PNP0c14,一旦BIOS 在asl code给出定义,acpi.sys就会创建这个pseudo device,OS就会load wmiacpi.sys作为该device的driver。当然仅仅加载这支driver还是不够的,为了能够使用WMI访问该software device包含的具体信息我们还需要一个供BIOS使用的asl文件以及与asl code对应的MOF文件而微软并没有提供Wmiacpi.sys相关的MOF文件。那么MOF文件到底有什么作用呢?要搞明白这一点我们来研究一下WMI的工作原理了,下图1展示了WMI Architecture:: |7 u7 a2 l# m# r
% O' B# p' J9 I( s4 `3 Q( D0 _" L
2 S, ^) u t+ B! S' @
+ k# s! l1 s5 z* P# X
当user使用API访问WMI信息时,WMI CORE会查看repository中已知的scheme定义,然后将希望获得的信息通过IRP的形式送给Providers这些Providers通常都是WMI Driver,它们处理IRP并将所需信息送给上层。那么也就是说必须要将MOF scheme加到WMI repository之中,consumer 才可能透过WMI COM API访问到。完整的过程是这样的OS在加载WMI驱动程序的时候会查看驱动程序的MOF scheme,如果驱动程序MOF scheme 部分正确无误,那么OS会将MOF scheme提取出来并自动加入到repository之中。所以OS仅仅加载wmiacpi.sys并不行,我们还需要给出与ACPI asl code对应的MOF scheme,并且通过在WMIACPI service key 下面建立一个key MofImagePath它的value指向MOF档的路径。如此在OS加载wmiacpi.sys时就会将对应的MOF scheme加入到repository之中,后续consumer访问时WMI CORE就会检索到scheme信息,然后下IRP给wmiacpi.sys。讲到这里原理应该差不多了但还要注意的是wmiacpi.sys并不会去执行asl code,最终执行动作还是会由acpi.sys发动。driver是层次结构的,acpi.sys是wmiacpi.sys的lower driver,wmiacpi.sys会将上层对asl的访问转化为low level IRP 送给acpi.sys,acpi.sys再返回具体信息然后逐级回送。
! {$ m4 y8 L4 r: F' \' r8 P9 l. n- S8 m8 ?8 \* N" `& p
3. Under the hood0 r' u! e1 ]! K+ w
/ k5 p' n: N8 W) A2 F; ]8 n前面都是原理的介绍,讲的我都快吐血了J,实践是检验理论的唯一标准。说不如做,随我揭开内幕一探究竟。WDK ver6000 src带了一个wmiacpi的samplecode,build之后会生成一只acpimof.dll,在BIOS里面将device.asl包进去然后再注册表中加入acpimof.dll的信息然后重启。讲到这里还要提到一个验证wmi的好工具叫做WMICodeCreator.exe微软的网站上有下载,下面我们就使用该tool验证前面的说法,下图2演示了我们定制wmiacpi之后的状况:; N+ q3 {$ G P* _" d
+ Z5 d6 F) [* T. K9 ]6 ^
0 W {- k1 c6 E2 W) k+ T
. b: d4 I1 K7 _. s1 m$ n0 C7 q4 p图 2 & S) Z$ q3 B+ m \, r
图2红色方框标注的AcpiTest_**就是我们定制的WMI class。也就是OS Load wmiacpi.sys之后将其MOF档案解析出来并加入到WMI repository于是我们就看到了上图的信息。下面我们来跟踪一下访问具体的class的情况吧,祭出WinDbg,let’s go!首先查看一下wmiacpi.sys这支driver有没有被加载下图3表明该driver被正常加载了。
$ l8 ` ~- F! ]" I6 |% Q0 m) N9 @' O6 s' s; z! [0 {6 G
2 n7 p& E; e! n- R2 @$ o3 b: @9 D图3 5 i6 e! r! l8 Q, v7 _
由图3显示与wmi相关的有两个driver:wmilib.sys和wmiacpi.sys,wmilib.sys是干嘛的呢?别急后续讲述wmi driver的文章会详细介绍它。既然被加载了那我们就要dump wmiacpi.sys的symbol看看有哪些有用的信息,这样我们才比较容易下手J。下图4显示了wmiacpi.sys的所有symbol。( o2 F& U* R4 B- L
" y: F. Z( [5 A4 N, D1 q1 p, e K/ _
0 V/ Y2 r- r1 x9 D( @$ Q! y
图4
[# H6 \1 X9 s2 B& P前面我们还讲到wmiacpi.sys最终会调用到acpi.sys访问asl code那我们再看一看acpi.sys有哪些symbol,下图5显示了acpi.sys的所有symbol:
5 `: u5 N0 ~* _4 y E* V" _2 `7 E* c, d( A: q _
% @* _$ W4 y+ I" H
图5 ' s; v' v8 R; r2 i7 f
经过分析上述symbol我觉得下述函数很有作案嫌疑,所以将它们秘密监控J都给设上断点,被怀疑的对象如下图6所示:, B7 b) h# ~, E$ L; ]1 g6 d1 F
: g$ |4 V9 {) j) v2 J) b
+ x# t) {8 @) n图6
7 |1 ^, s7 }1 d) `如图所示:
% G' u; Q8 a: _9 C3 b: q, j: x* m" H3 Q6 z
wmiacpi!WmiAcpiSetWmiDataItem5 c- \& f1 Z: }$ D3 h, I* i8 C
6 ^! |( ~' ^# |- s& c5 @wmiacpi!WmiAcpiSetWmiDataBlock) f' B6 @& C: F2 R; c: h; w/ i
. F4 `( T6 ?7 Q- j+ m( W) y
wmiacpi!WmiFireEvent- g4 W' u1 H: o* U7 m7 F' r7 ^
; L2 V# }: M! r+ k9 x0 u
wmiacpi!WmiAcpiQueryWmiDataBlock7 X% a( @6 O7 n7 G
- S1 z# ?0 g8 Y; a2 O5 o5 Jwmiacpi!WmiAcpiSendAsyncDownStreamIrp6 R8 _' V l" ]+ r( c9 q
) p* t5 B) B/ vwmiacpi!WmiSystemControl1 o0 s- _4 @; U
* _! P! I3 z; K! [7 F7 t4 \' `
wmiacpi!WmiAcpiSystemControlDispatch- B) t! W$ ^; X' s( }
8 P7 {2 I3 y( P/ C9 t) V4 c
acpi!ACPIIoctlEvalControlMethod+ h+ }4 \7 x; ^7 O- U
4 q2 _9 c/ D: @% B4 m% u* r" jacpi!ACPIIoctlAsyncEvalControlMethod9 P% O0 t8 ]# U# B3 y6 J
' q. w1 \1 }, ?" F. y
acpi!ACPIIoctlAsyncEvalControlMethodEx: e& |# b0 G% s8 O4 O( ?0 x! `
5 b+ \. v7 p0 r& T4 R- q
acpi!ACPIIoctlEvalControlMethodEx
( v% f/ Y9 K1 Z: e( f, L" ]
. f/ f0 s9 q0 F. K5 Y! jacpi!ACPIButtonDeviceControl
1 w9 y2 v* Q9 i! U. d$ d1 ~
, s& t. L; a* t9 K9 t qacpi!ACPIEcInternalControl; l% u+ w- I& p0 d
8 B, A5 Q/ C3 T& Nacpi!AcpiEmbeddedControllerIrpDispatch
. C. g: c- n N7 _4 ] C b2 X
4 A8 |/ N# V# Z( C. x. Y8 _) T7 E6 zacpi!ACPIIrpDispatchDeviceControl
. n& x0 h' s5 _/ X
2 [/ e# P2 P7 L2 Tacpi!WmiSystemControl
8 j6 ^) N8 v) G# N ~7 w5 x+ ~" [. B1 {$ o( E n
这些函数都被设置的断点,下面就我们读写一个class试试看了,图7证实了我之前的所说绝非空口无凭,我们读AcpiTest_MPackage class时发现先会call wmiacpi!WmiAcpiQueryWmiDataBlock,然后acpi!ACPIIrpDispatch DeviceControl会接手,当然后续还会有别的一些动作,但是上述行为就足以支撑我的论点了J。6 t- a& Q0 p$ n. v! I
' o1 J8 W+ O! C; |* q$ T8 v) {
" {6 ~1 }3 v8 w
! a# {; A1 V& C7 P. t# s
( n3 T2 M' A9 q1 _5 r& h图7
9 {) C3 C; s0 \ 图8演示了我们发一个event的状况,图中显示acpi.sys会接到该event然后透过wmiacpi!WmiFireEvent送给上层AP,上层AP再透过IRP下来qurey其它相关的具体信息。
' M6 m4 U* j+ K% G: ?+ N! p/ K
" x, w5 g* J& M9 y9 w6 F( ~/ @9 f- j7 T3 F8 c- m O
- V+ i( `7 V1 X, n8 Q图8 . h6 U0 n7 {. V4 B7 h
以上就是我费尽九牛二虎之力挖掘的wmiacpi.sys的秘密了,再附上一幅我的debug环境J。# ^! J% W1 X* V" q5 ?6 c1 ?, [
; Y4 F0 L" } D* q1 F5 z2 ~+ K* r/ O
* h' |, q2 E/ }; Z$ \
c( Q9 O% K- F; ?图9
, A2 K7 E3 ^. h p- h) f( eThat’s all!
& r+ P6 r! {$ ~) v/ J* Z$ ?Peter }& |$ h3 t* W+ d! w
3 ?- x/ A3 s4 B1 b+ ]% _. q5 A[ 本帖最后由 peterhu 于 2009-5-25 09:31 编辑 ] |
|