|
|
|
WMIACPI.SYS
) n/ i% J( C0 [. H$ T: h1. WMI Concept
2 K/ |# V6 u/ z& I, u2 D4 u, x! D6 s7 ~' L: l9 \
WMI全称Windows Management Instrumentation是一种管理计算机系统的方式。它是微软基于WBEM的实现，WMI希望为系统管理以及分布式数据描述提供一种模型，并且允许使用基于COM的user mode API对系统部件进行访问、管理、控制。/ N$ j8 w1 M$ Q' h
6 }1 p; n8 p( W. f
1 Q1 h) u3 t3 N; K9 I- p2. WMIACPI.SYS
4 G1 [5 s' Z X8 Z" k5 J4 F- g6 w! j' h( S& a! e% c8 {3 \/ H6 j
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达成的：
" v& I/ G+ K: G# [& q, bA．Acpi.sys
/ m. O; g0 H; x# jB．Wmiacpi.sys
0 q U) j' Z6 \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获得。2 ?. r( `1 Y9 M8 J' z! Y
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：0 \- N8 p& c R. C
4 Q9 K; _5 c. F D: }7 O1 I. Q- O
& N) [9 w5 w9 W% R; w/ C( p
当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再返回具体信息然后逐级回送。, n! Y; P+ _ D
" ~! l7 e$ E, B, b4 o7 b: I4 i
3. Under the hood5 P5 Q4 W8 W6 Z
& ~; s$ z2 |2 U$ w* I
前面都是原理的介绍，讲的我都快吐血了J,实践是检验理论的唯一标准。说不如做，随我揭开内幕一探究竟。WDK ver6000 src带了一个wmiacpi的samplecode，build之后会生成一只acpimof.dll，在BIOS里面将device.asl包进去然后再注册表中加入acpimof.dll的信息然后重启。讲到这里还要提到一个验证wmi的好工具叫做WMICodeCreator.exe微软的网站上有下载，下面我们就使用该tool验证前面的说法，下图2演示了我们定制wmiacpi之后的状况：
% W3 ], L5 `/ r+ n
& g& [5 z. O* \! V* w. e
+ {2 S6 H6 g2 B3 s. _7 q( |* n# T; R2 O/ u/ Q
图 2 8 K( x. p! D( z7 M8 i
图2红色方框标注的AcpiTest_**就是我们定制的WMI class。也就是OS Load wmiacpi.sys之后将其MOF档案解析出来并加入到WMI repository于是我们就看到了上图的信息。下面我们来跟踪一下访问具体的class的情况吧，祭出WinDbg，let’s go！首先查看一下wmiacpi.sys这支driver有没有被加载下图3表明该driver被正常加载了。
( P5 o8 O- }! V+ u/ { m0 e, w# G* Y
4 ]2 j% q; B' d6 Q& ]/ R8 j5 c4 m9 S" \* n( X1 M" b
图3 ; K% {) j/ M7 |0 A( O
由图3显示与wmi相关的有两个driver:wmilib.sys和wmiacpi.sys,wmilib.sys是干嘛的呢？别急后续讲述wmi driver的文章会详细介绍它。既然被加载了那我们就要dump wmiacpi.sys的symbol看看有哪些有用的信息，这样我们才比较容易下手J。下图4显示了wmiacpi.sys的所有symbol。9 a$ K6 a$ N7 v: G. l
h& ^! X, g: `7 o- a
4 L# _! a0 Q# W* @) r图4 / |: g: g p5 ^7 N$ A
前面我们还讲到wmiacpi.sys最终会调用到acpi.sys访问asl code那我们再看一看acpi.sys有哪些symbol，下图5显示了acpi.sys的所有symbol：
`; J' b* T/ P
0 d. C" j- t P4 ?: N* E* R
5 u" t7 F+ |$ \/ m图5
6 x9 y9 u! b# ^, j" x% I# ]& e经过分析上述symbol我觉得下述函数很有作案嫌疑，所以将它们秘密监控J都给设上断点，被怀疑的对象如下图6所示：
8 n p3 N1 ?0 u$ |( z* ~4 C2 s& Z4 v$ v, K/ b( v
, k, V5 U$ r) n9 c( M* {7 A. I图6 ; t* T6 Z' x; e h/ E! O
如图所示：3 s) Z" ~4 y/ e0 w( Y( P
^9 r; a' e8 z, t5 X
wmiacpi!WmiAcpiSetWmiDataItem
! D0 q0 A7 I0 ?/ [ }( V* r$ R6 f; S
wmiacpi!WmiAcpiSetWmiDataBlock
$ S, H5 Q" s/ R/ ?, D7 l- l9 _: Z: ^" I! a7 x7 c8 w2 s+ [0 h
wmiacpi!WmiFireEvent
* s. \- ]. e' [% t$ k" q) v* h4 H6 _9 p* {+ I
wmiacpi!WmiAcpiQueryWmiDataBlock; ?) I) q+ t9 P
+ W( w) V7 u! E! X: ]wmiacpi!WmiAcpiSendAsyncDownStreamIrp, N7 R7 F/ k) Z- C
+ a9 t, H6 [$ ?) P ?+ _wmiacpi!WmiSystemControl6 |( T5 n4 t) E8 D) d
- ~' y9 s e a/ Q# }
wmiacpi!WmiAcpiSystemControlDispatch
* ~# o( q* T3 x& C0 f* x; ?9 I6 J, [ K0 r t0 _
acpi!ACPIIoctlEvalControlMethod
8 A6 n! C$ g9 @
8 J5 W2 n' @# i4 n3 ~acpi!ACPIIoctlAsyncEvalControlMethod0 z" s- I" i+ C# B2 I
1 Q4 e9 B0 _9 r! t5 o. Zacpi!ACPIIoctlAsyncEvalControlMethodEx
/ Z3 W+ V1 r1 N
- v3 K4 ^: ^0 b2 B/ K) Q: I* uacpi!ACPIIoctlEvalControlMethodEx' K- Z, |" I8 Y3 N0 V6 f" C8 d: r
; p% q; Z8 Q J
acpi!ACPIButtonDeviceControl
) `! A. f& u+ g. n2 ~- q: i3 R
* W8 `9 w4 N, {% gacpi!ACPIEcInternalControl
" a5 c8 F. p$ c0 l% h! M! }" w( B8 S" E( @* x2 ~
acpi!AcpiEmbeddedControllerIrpDispatch/ S1 u. p; {3 i* A g
( L7 z$ N: I: b/ @5 W
acpi!ACPIIrpDispatchDeviceControl
, _- v, j2 A* C8 a: v Q, f8 S* s1 X1 c
, E2 ^0 c4 k- ]4 r4 L3 Tacpi!WmiSystemControl) D+ Y9 |2 }; k8 t
# }4 B: Q7 ^8 f% }" ?2 _
这些函数都被设置的断点，下面就我们读写一个class试试看了，图7证实了我之前的所说绝非空口无凭，我们读AcpiTest_MPackage class时发现先会call wmiacpi!WmiAcpiQueryWmiDataBlock,然后acpi!ACPIIrpDispatch DeviceControl会接手，当然后续还会有别的一些动作，但是上述行为就足以支撑我的论点了J。6 c q8 v5 _5 i/ Q% l! r8 }6 q) l! I
k6 X: Q' j7 C$ E$ |! |* _
1 O9 q9 f1 ^7 [- e( C% \- @2 J$ v4 S; a( z% A* L4 S ?
9 p. q" K, R# f2 J6 b5 E5 U图7
9 {4 s3 N. @ s( H, H 图8演示了我们发一个event的状况，图中显示acpi.sys会接到该event然后透过wmiacpi!WmiFireEvent送给上层AP,上层AP再透过IRP下来qurey其它相关的具体信息。' g0 f2 h; Q1 T; W/ w w' P
& _( }& y2 p- l
7 m4 R+ c Q: ~2 R- Q7 w! O/ C5 W2 Z& A* o& Z* d- q0 K5 q5 ~
图8 / M. i% a5 @* {) T4 R% P9 k/ w
以上就是我费尽九牛二虎之力挖掘的wmiacpi.sys的秘密了，再附上一幅我的debug环境J。
! \6 k) \+ {8 E! `2 w. v# z
* a( _4 | e+ y2 `# e" h: A/ J7 b9 Q1 d1 F' c
! R2 k- s3 F5 ~$ p5 T1 W5 H图9
& D* Y$ @0 s$ L" RThat’s all!
3 j( v! J0 W& i4 ?2 s1 Y% W1 }Peter 8 p0 b9 a4 B0 a1 |% s
- ]. o# p9 |$ `, w
[ 本帖最后由 peterhu 于 2009-5-25 09:31 编辑 ] |
|
IP卡
狗仔卡
发表于 2009-5-22 17:14:23
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-22 20:27:37
3 U5 p. M% @2 A _5 _& [6 O
今天我再试试也许就出来了