|
|
|
WMIACPI.SYS u) k; }" a0 ?4 d. X: y
1. WMI Concept
1 v+ L/ Q5 S7 F6 U' @1 t5 V! f
( L& Y8 d$ D* k- T( `0 ?% g; ZWMI全称Windows Management Instrumentation是一种管理计算机系统的方式。它是微软基于WBEM的实现，WMI希望为系统管理以及分布式数据描述提供一种模型，并且允许使用基于COM的user mode API对系统部件进行访问、管理、控制。
* O0 X4 O6 q2 ~6 V- G- j+ o/ p3 \% j0 ~" N L# i
# q Y* i: P8 W% {
2. WMIACPI.SYS
7 G7 o& ?" r, }! i2 }0 [
y4 K& i, w; W/ A0 I1 m: FWmiacpi.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达成的： Z& M! E7 p' |: y5 C
A．Acpi.sys5 a! `! v0 _$ ?) ~$ O3 p2 y6 W
B．Wmiacpi.sys4 t0 [$ { M" i6 d& E$ I7 q
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获得。" H4 l/ i" ?2 w2 @# u2 o N3 M
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：
6 C; R/ g: m1 H" u2 i6 J
" B! C4 f( J- X; s5 w/ \1 \. U2 t2 Z1 \. S. ^- h. ^0 g' |
, X' G% p; G: ]5 y" t* K当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再返回具体信息然后逐级回送。
8 ]- {. e. y5 }9 Y8 z2 g+ E- M% n1 |# D
3. Under the hood3 S' B( v- U* M; Y/ o
, C; d+ k/ o) g3 I3 u; a
前面都是原理的介绍，讲的我都快吐血了J,实践是检验理论的唯一标准。说不如做，随我揭开内幕一探究竟。WDK ver6000 src带了一个wmiacpi的samplecode，build之后会生成一只acpimof.dll，在BIOS里面将device.asl包进去然后再注册表中加入acpimof.dll的信息然后重启。讲到这里还要提到一个验证wmi的好工具叫做WMICodeCreator.exe微软的网站上有下载，下面我们就使用该tool验证前面的说法，下图2演示了我们定制wmiacpi之后的状况：
% F( k7 `) j( b6 a( z
9 }1 ~* a# ^ z, ~, f* y
/ S$ _) } M3 d7 x0 A) a6 I0 o5 I! |* N) w! C5 p
图 2
/ n' T. I0 N) k X) Q图2红色方框标注的AcpiTest_**就是我们定制的WMI class。也就是OS Load wmiacpi.sys之后将其MOF档案解析出来并加入到WMI repository于是我们就看到了上图的信息。下面我们来跟踪一下访问具体的class的情况吧，祭出WinDbg，let’s go！首先查看一下wmiacpi.sys这支driver有没有被加载下图3表明该driver被正常加载了。- y* l* K( x" N; t8 J0 }
, z K8 W; ~. q
- R( w7 Q# e1 A图3 2 |3 l: v. m* G) S" {
由图3显示与wmi相关的有两个driver:wmilib.sys和wmiacpi.sys,wmilib.sys是干嘛的呢？别急后续讲述wmi driver的文章会详细介绍它。既然被加载了那我们就要dump wmiacpi.sys的symbol看看有哪些有用的信息，这样我们才比较容易下手J。下图4显示了wmiacpi.sys的所有symbol。
5 o) ^3 q; A0 T4 d4 M8 E0 _6 [* Y4 V5 @" G" c! D+ i
6 X- B6 C1 E; Q0 S. k8 X图4
( } g8 g4 ?' ~6 L+ i& _4 C4 ^4 i前面我们还讲到wmiacpi.sys最终会调用到acpi.sys访问asl code那我们再看一看acpi.sys有哪些symbol，下图5显示了acpi.sys的所有symbol：
/ D& ]0 c3 ]# b( S3 o( g, ^" z5 m3 w; X8 C& e
1 }* g4 M# @/ g$ ^5 H+ j) Y
图5
0 ]7 B( r; v6 k' W# s! z# s经过分析上述symbol我觉得下述函数很有作案嫌疑，所以将它们秘密监控J都给设上断点，被怀疑的对象如下图6所示：6 A2 f; G' E1 T5 ~. [
7 L$ p2 U6 _% x+ {
: C0 ~8 z: r9 J, v: d- c图6
* I+ o$ \# A4 B7 Z" c. L/ y如图所示：
6 K" w+ e: w- H/ ?6 s3 [* P. Q0 y1 {1 K7 P
wmiacpi!WmiAcpiSetWmiDataItem ~. s% \) b, F7 w+ i5 M, ]
4 X9 `/ ~$ u0 q, S2 M M
wmiacpi!WmiAcpiSetWmiDataBlock' V. `- S& d" T+ n, D# j
a5 m7 c6 H0 L& v1 L5 zwmiacpi!WmiFireEvent
/ [2 G7 S9 P; j" h$ ?4 l0 e
4 p2 Z+ @& U8 @wmiacpi!WmiAcpiQueryWmiDataBlock
+ V, Q6 f$ v/ u2 g K- p0 G! u2 p* c( _. a/ o/ r/ x
wmiacpi!WmiAcpiSendAsyncDownStreamIrp- L9 F H) L% M i5 ~
) T: Z* b! H) @
wmiacpi!WmiSystemControl3 W; U( z1 I& D+ h: O0 ?: }
- d: G4 X: j7 b) |+ ~% L0 Uwmiacpi!WmiAcpiSystemControlDispatch
/ d& j0 l' |5 a- _8 ^: f7 p+ w5 I/ V1 L5 o- b# v1 a# [3 R6 u& Z t5 v
acpi!ACPIIoctlEvalControlMethod
, ]5 |8 h0 f: Q3 _' _
/ \; J4 W7 X; f: ^' Uacpi!ACPIIoctlAsyncEvalControlMethod
, |, z& G! u" R2 ~' n: |# ^% X1 W4 S
, I5 {6 u( c5 @% A, q6 `acpi!ACPIIoctlAsyncEvalControlMethodEx' q/ D% d3 [) }: M3 \
1 m, r8 Q4 z$ y9 o) i8 \& nacpi!ACPIIoctlEvalControlMethodEx7 z9 `; [! X' u6 o2 A
. X }! @/ R; U, W: Bacpi!ACPIButtonDeviceControl$ Q5 H1 g2 m, N- D
' P; y: t* Q) f! d' Xacpi!ACPIEcInternalControl
( r! h9 j. A6 z2 {; a, \
z# b# Y% S! P& Y3 |& pacpi!AcpiEmbeddedControllerIrpDispatch
- h6 [+ p) s P# e6 v
9 K. V3 \ V0 A9 Tacpi!ACPIIrpDispatchDeviceControl* l b* v# a2 P: Z5 L
0 q$ g5 r3 g3 m5 L. x t9 r0 F( dacpi!WmiSystemControl! W! ?* a9 z; B* I# c* F
* r+ | L! b5 p" h6 N% E# _
这些函数都被设置的断点，下面就我们读写一个class试试看了，图7证实了我之前的所说绝非空口无凭，我们读AcpiTest_MPackage class时发现先会call wmiacpi!WmiAcpiQueryWmiDataBlock,然后acpi!ACPIIrpDispatch DeviceControl会接手，当然后续还会有别的一些动作，但是上述行为就足以支撑我的论点了J。* V8 H+ O! S# v0 b
# B3 K0 h: o" ]* W* F! b' _0 b5 I
( s. s+ Y( o0 e
: _' v* w) l7 A7 Q1 L+ y
+ {4 o% t8 K$ @8 s9 C W( O3 ?% Y# z# c% \
图7 H$ e& e, h% o0 H% @6 W
图8演示了我们发一个event的状况，图中显示acpi.sys会接到该event然后透过wmiacpi!WmiFireEvent送给上层AP,上层AP再透过IRP下来qurey其它相关的具体信息。
1 ]$ ~2 K* X, u. a, R* l
0 m, }0 F- p D S
" N# R7 P5 x, C* h
1 t0 ~0 X% I% N# I图8
4 m8 ~4 u& ]% g4 k9 k* D5 N1 A9 }; ]3 e( Y以上就是我费尽九牛二虎之力挖掘的wmiacpi.sys的秘密了，再附上一幅我的debug环境J。
: {# E& U' t0 k' b
6 w, B( f! f) e- l. O! ?: e3 g- D2 c% U
3 T% @. [, _5 {4 `, j) l; P4 _
图9
. j+ f; }. S* Y! qThat’s all!
% ^/ P k2 Y, S9 t5 ^Peter - k% @' t# [2 N" H* l* x9 V, H* Q
( A) P" z# k; V$ Q- B2 W: n
[ 本帖最后由 peterhu 于 2009-5-25 09:31 编辑 ] |
|
IP卡
狗仔卡
发表于 2009-5-22 17:14:23
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-22 20:27:37
今天我再试试也许就出来了