|
|
|
WMIACPI.SYS $ i* \ g$ h: q x! D6 l6 z- S; V
1. WMI Concept
7 U4 N4 X. r2 n# P9 ?& U) E6 L9 k8 j, z' o( a, X
WMI全称Windows Management Instrumentation是一种管理计算机系统的方式。它是微软基于WBEM的实现，WMI希望为系统管理以及分布式数据描述提供一种模型，并且允许使用基于COM的user mode API对系统部件进行访问、管理、控制。; h: }( N# q: T& S' f% U6 _
: [: r5 T: h: q* h
9 v3 ~% A$ Y2 h5 k* K3 E# ?' h2. WMIACPI.SYS
8 @" ]7 E! v7 s: E: \1 ?7 y0 l
/ r y1 c* K" VWmiacpi.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达成的：8 T8 a4 L: Y( q" W) l
A．Acpi.sys! u3 P; U$ t( c: }$ m
B．Wmiacpi.sys
( y9 U9 K$ d0 ^7 z$ ~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获得。
6 Z) ?0 S, T7 u" l g+ tB).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：
1 a) R( L9 @4 F- z% v) K1 a2 ], r- f( k* G9 v
+ ?( Q0 e1 w7 y3 I6 w7 E
$ f* u1 D6 m3 J3 \& ]: g
当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再返回具体信息然后逐级回送。, z" s* L9 k; S& Z: o' R# s3 \
{! l! ~+ f5 n& N
3. Under the hood2 L( e) e0 h4 N4 S% l* ~2 x$ ~* o- e
/ y( |) J2 l9 {/ k前面都是原理的介绍，讲的我都快吐血了J,实践是检验理论的唯一标准。说不如做，随我揭开内幕一探究竟。WDK ver6000 src带了一个wmiacpi的samplecode，build之后会生成一只acpimof.dll，在BIOS里面将device.asl包进去然后再注册表中加入acpimof.dll的信息然后重启。讲到这里还要提到一个验证wmi的好工具叫做WMICodeCreator.exe微软的网站上有下载，下面我们就使用该tool验证前面的说法，下图2演示了我们定制wmiacpi之后的状况：
" Y! H* @+ W5 u' T
; w/ n1 U) C4 p Y! g! b: }% O. I8 a
, E" @- N" @2 ^" P图 2
( R4 ^7 h) w( l( p; a, d图2红色方框标注的AcpiTest_**就是我们定制的WMI class。也就是OS Load wmiacpi.sys之后将其MOF档案解析出来并加入到WMI repository于是我们就看到了上图的信息。下面我们来跟踪一下访问具体的class的情况吧，祭出WinDbg，let’s go！首先查看一下wmiacpi.sys这支driver有没有被加载下图3表明该driver被正常加载了。5 |- w6 q) Z# p. ]" N
& l& l' @3 r& ?6 K5 s
9 y$ R8 x* o% ~" R* e, U
图3 + Z! p6 u7 L. P. B
由图3显示与wmi相关的有两个driver:wmilib.sys和wmiacpi.sys,wmilib.sys是干嘛的呢？别急后续讲述wmi driver的文章会详细介绍它。既然被加载了那我们就要dump wmiacpi.sys的symbol看看有哪些有用的信息，这样我们才比较容易下手J。下图4显示了wmiacpi.sys的所有symbol。/ E9 f7 K+ j% E6 A
/ |0 p+ ^# @" w6 A% l9 Y! p# T: i" \6 ]: K9 A
图4
3 J. r* Q' Q+ n+ y" x前面我们还讲到wmiacpi.sys最终会调用到acpi.sys访问asl code那我们再看一看acpi.sys有哪些symbol，下图5显示了acpi.sys的所有symbol：7 y3 a9 G% J. z* C& f
' z' w7 c1 E) b4 K( q9 Q3 Q/ v$ @/ \- R7 F! U: s9 C
图5
) E8 _* S5 J! F/ K, e经过分析上述symbol我觉得下述函数很有作案嫌疑，所以将它们秘密监控J都给设上断点，被怀疑的对象如下图6所示：! \ V7 {" v1 s
8 K" R, ?- R( e0 s2 {
* `- [" L/ [4 d; V- D s) @图6
+ ?; U1 r3 W* g8 Q6 X( q& l, i% S7 }如图所示：
2 z0 s! u: m2 ]' x3 ^! g+ {+ A. y* Y* \2 d; ?
wmiacpi!WmiAcpiSetWmiDataItem7 ?+ b6 W8 Q7 G8 ^2 ?/ r6 E
* I4 `4 {5 t6 y6 c5 |3 U0 _wmiacpi!WmiAcpiSetWmiDataBlock
4 ?# |. ?% m4 ~% H! u$ p
. Q, X+ f7 ^8 _" Z1 ]wmiacpi!WmiFireEvent
5 u1 C' m! r+ x7 @. y
; q \9 W& h% n; O% T- |+ u6 awmiacpi!WmiAcpiQueryWmiDataBlock/ G# r. P2 Q! E0 x: V* K- v6 j
; D) A# q4 n; z+ N, m! Q
wmiacpi!WmiAcpiSendAsyncDownStreamIrp u% ^& O. G+ t# K; F
& T. \! H2 @8 c0 {( i" i
wmiacpi!WmiSystemControl
8 l0 R% s% ~% E$ e( k- o W) W- Z& [
wmiacpi!WmiAcpiSystemControlDispatch" g. P9 O- \+ k9 P5 n/ l- t- \, m
1 u' G$ H5 {9 y$ e. A
acpi!ACPIIoctlEvalControlMethod: z# e( n0 z/ g
" }1 K+ _! Y, s" l
acpi!ACPIIoctlAsyncEvalControlMethod* g$ G+ v6 R/ m$ {" z3 z
& m+ P$ ~: `/ D8 m/ e+ b' k0 [! {
acpi!ACPIIoctlAsyncEvalControlMethodEx
' G0 r% f6 }6 ^5 |
0 w8 |& D( W% A% ]acpi!ACPIIoctlEvalControlMethodEx4 {. }8 b& [ f( l
: P v% r6 i7 q; l% Hacpi!ACPIButtonDeviceControl9 C; m( ^0 x( P0 @' J" ~) Z
. M* |& s, g* C {0 Nacpi!ACPIEcInternalControl
4 B) g" L) @! H
; |4 T2 D f- z( s2 V9 H! t: Iacpi!AcpiEmbeddedControllerIrpDispatch
- h( i; \1 J, ~' {7 [) T( d; D$ v
* q' R$ s" c8 bacpi!ACPIIrpDispatchDeviceControl" J8 _8 U, u$ B( |6 m# v; r
, P' D8 O, O6 Z( A- w
acpi!WmiSystemControl
) U* h; P5 c1 \! b
! B2 j9 K" T' C4 {/ x这些函数都被设置的断点，下面就我们读写一个class试试看了，图7证实了我之前的所说绝非空口无凭，我们读AcpiTest_MPackage class时发现先会call wmiacpi!WmiAcpiQueryWmiDataBlock,然后acpi!ACPIIrpDispatch DeviceControl会接手，当然后续还会有别的一些动作，但是上述行为就足以支撑我的论点了J。
5 b, X' N3 [9 {# U
$ K n0 T; j8 a' ?+ [4 ]
6 e5 [8 ]# j/ \4 u/ G8 ~3 U
- |) \( _/ H" o( K9 [5 }, Z: f% l7 D- k }6 ]5 k- q1 u' H
图7
# T; C6 ^+ z E* o+ ~ 图8演示了我们发一个event的状况，图中显示acpi.sys会接到该event然后透过wmiacpi!WmiFireEvent送给上层AP,上层AP再透过IRP下来qurey其它相关的具体信息。
4 i+ h. h( _# V
# W# }! N4 ~; ^" ~8 F7 ]: k4 o0 f; M1 H$ b/ \* }% L
" S( W9 N0 ^8 ^+ i( v% O6 Z
图8 ; ?, j% ?* N1 a$ R' n
以上就是我费尽九牛二虎之力挖掘的wmiacpi.sys的秘密了，再附上一幅我的debug环境J。3 t i* p( C# K8 E7 B+ e' d
( q: b1 T/ U |
0 W$ W+ Y' X, y0 M0 q8 o
$ d; x8 F, s# N6 c; R' I
图9
- K! b' R" N0 W- n9 A' b5 }That’s all!
1 Y; T$ i6 [ W/ m) R: N% {Peter ( b& q. {' i4 t, L) ?
/ Z9 M5 S/ F) Y. f3 n) a/ ?: [5 \
[ 本帖最后由 peterhu 于 2009-5-25 09:31 编辑 ] |
|
IP卡
狗仔卡
发表于 2009-5-22 17:14:23
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-22 20:27:37
今天我再试试也许就出来了