|
|
|
WMIACPI.SYS
9 j% f* h6 Y/ O" h5 \! W! i8 ~1. WMI Concept
/ w" ?# _5 X1 _% M: z+ c2 ?
+ R9 [" I2 Z- ?& SWMI全称Windows Management Instrumentation是一种管理计算机系统的方式。它是微软基于WBEM的实现，WMI希望为系统管理以及分布式数据描述提供一种模型，并且允许使用基于COM的user mode API对系统部件进行访问、管理、控制。# Y- S9 y+ Z/ x3 J' Y# e
7 d5 \3 F1 u _) ?8 s% e" w1 F
4 k1 n |* ?3 q3 ]$ r; W3 K2. WMIACPI.SYS
" y/ D0 H4 Z2 } E6 w- s# S
Q8 D' o( I5 ]9 V6 R7 sWmiacpi.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达成的：
1 [* ?5 \5 V! D! i2 z5 yA．Acpi.sys
9 O% i2 ]4 @) }8 l' F( N. |B．Wmiacpi.sys
5 B i1 o+ a2 W' {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获得。
9 x7 T2 @, x' b* ^3 XB).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：) x7 Y/ q" o6 I: Q9 x
( k0 b) [- {; f5 u, T1 B6 f4 W! j
, T1 c8 g3 y4 h+ w
4 i- D/ t6 O$ C, Q
当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再返回具体信息然后逐级回送。& G3 {. Y2 M8 n. P* ?
3 o3 D, o0 b, U6 R) y
3. Under the hood
z9 m5 W8 L1 @7 c* j% p& K0 L5 Q5 X. C6 g1 z7 b
前面都是原理的介绍，讲的我都快吐血了J,实践是检验理论的唯一标准。说不如做，随我揭开内幕一探究竟。WDK ver6000 src带了一个wmiacpi的samplecode，build之后会生成一只acpimof.dll，在BIOS里面将device.asl包进去然后再注册表中加入acpimof.dll的信息然后重启。讲到这里还要提到一个验证wmi的好工具叫做WMICodeCreator.exe微软的网站上有下载，下面我们就使用该tool验证前面的说法，下图2演示了我们定制wmiacpi之后的状况：- d5 L3 _ M' G; J
& v H, e' \' m
8 G- m2 \) a+ `
& U7 Y- ^ H c6 X) M1 I
图 2 ' ~) r% @( |) ]- q
图2红色方框标注的AcpiTest_**就是我们定制的WMI class。也就是OS Load wmiacpi.sys之后将其MOF档案解析出来并加入到WMI repository于是我们就看到了上图的信息。下面我们来跟踪一下访问具体的class的情况吧，祭出WinDbg，let’s go！首先查看一下wmiacpi.sys这支driver有没有被加载下图3表明该driver被正常加载了。- M/ c( {0 S0 G
1 [2 b2 ~6 q0 J0 k& b
1 O7 X, O. p1 s2 G
图3 ) E+ |8 T+ I5 {, d4 H
由图3显示与wmi相关的有两个driver:wmilib.sys和wmiacpi.sys,wmilib.sys是干嘛的呢？别急后续讲述wmi driver的文章会详细介绍它。既然被加载了那我们就要dump wmiacpi.sys的symbol看看有哪些有用的信息，这样我们才比较容易下手J。下图4显示了wmiacpi.sys的所有symbol。+ a+ ^- Y1 X* f& z
1 @# g* w4 m r- ^6 I. C0 N
: W4 h7 o+ U+ d图4 # N+ ]/ [) F7 R5 W$ T: U, A
前面我们还讲到wmiacpi.sys最终会调用到acpi.sys访问asl code那我们再看一看acpi.sys有哪些symbol，下图5显示了acpi.sys的所有symbol：
) w! P5 q8 f" V" v# v+ Q0 J/ a! s+ p* i
4 w5 P6 C1 _3 T5 E9 `9 _: ]$ C图5
0 e9 w2 `# {" } R* y) Y经过分析上述symbol我觉得下述函数很有作案嫌疑，所以将它们秘密监控J都给设上断点，被怀疑的对象如下图6所示：, H( s6 u q) d7 L1 {8 P1 t
- f8 t9 M( j3 f1 I& n' l+ v
& h2 B3 D9 X) N8 P图6 8 A' `7 ^+ ^- ?. c* G
如图所示：8 A+ j" U! D. B; P/ b a8 [2 i
) m) a% b. ]4 D* c3 R
wmiacpi!WmiAcpiSetWmiDataItem. i& Y0 s2 f0 L4 B' Y: p. N
: R/ \ H* q/ U) {6 M J
wmiacpi!WmiAcpiSetWmiDataBlock
- v! s6 ~* B L* ^' Y; F1 {0 j
6 |' L. A2 {; c2 A: y$ F" ] C+ N2 Lwmiacpi!WmiFireEvent
: K) Z7 [) X# u8 @: _4 s
+ @6 | @+ t9 h- F; O: fwmiacpi!WmiAcpiQueryWmiDataBlock7 v& B5 A: T7 I( s/ w
4 L- Y5 G, K6 c( @ a( }
wmiacpi!WmiAcpiSendAsyncDownStreamIrp( y1 d4 B ^: ^8 W/ P* G) w
) S6 l+ @% R* f
wmiacpi!WmiSystemControl. X* V$ }" L4 j/ Q5 ?" A
9 D" @6 } V2 U2 x9 h8 v: \" @! E! k
wmiacpi!WmiAcpiSystemControlDispatch+ G2 O Q" D$ r3 o8 z$ Z" Q
8 Z/ D7 z7 F4 S! L/ y# i: Y
acpi!ACPIIoctlEvalControlMethod" V b' f4 R z! x7 v
: x8 R/ l0 }5 T( h
acpi!ACPIIoctlAsyncEvalControlMethod
; E- ~; {$ E4 E- C! ~! R/ e+ u9 ~' |$ o7 |0 F+ D
acpi!ACPIIoctlAsyncEvalControlMethodEx6 I7 G7 N) q ]0 y* Z* _
) C. O, p4 j/ T3 T/ ? Y) R2 b
acpi!ACPIIoctlEvalControlMethodEx6 O; I6 S! F- B
' M/ J: g* ^; N/ o- g/ yacpi!ACPIButtonDeviceControl
% W1 L& w1 [! S' K/ K4 c( `3 J
8 @+ \* S4 N+ S4 F; ?acpi!ACPIEcInternalControl
/ Q$ l5 W p* l/ H2 ]' f' N& Q3 p, D
; B9 |9 ?- @2 _4 H5 I5 s/ ~acpi!AcpiEmbeddedControllerIrpDispatch
( @* _- I9 T) v9 E b! w0 J: b* s! X* b7 S
acpi!ACPIIrpDispatchDeviceControl
3 Y u- P4 U$ b t" [9 {6 \' R9 h: w+ |1 a& j, g7 ]3 O( s6 a
acpi!WmiSystemControl+ }1 e7 N! l" J$ A, k3 E# r* t
8 |4 L" k& F4 I) @9 A
这些函数都被设置的断点，下面就我们读写一个class试试看了，图7证实了我之前的所说绝非空口无凭，我们读AcpiTest_MPackage class时发现先会call wmiacpi!WmiAcpiQueryWmiDataBlock,然后acpi!ACPIIrpDispatch DeviceControl会接手，当然后续还会有别的一些动作，但是上述行为就足以支撑我的论点了J。" ]# V8 }7 @/ ?% O$ j
& ]+ Q$ C6 g8 Y/ y7 O, R _+ S% X: u G' S+ j: d8 c4 Y
! |- p' b5 i: W `: ]9 |9 @* w
: a) W+ K( \+ a Q; C5 Q8 \) e' L
图7
5 j1 \( H$ V* ~$ x/ d! I 图8演示了我们发一个event的状况，图中显示acpi.sys会接到该event然后透过wmiacpi!WmiFireEvent送给上层AP,上层AP再透过IRP下来qurey其它相关的具体信息。
, e( O/ @! x( ?/ |" q( Q- X" {. [! g. F0 M4 o) S
. ]6 i1 \+ Z2 S1 q& \
" u! I0 P; w- ], M2 z8 O
图8
- D) ~* t" ]: [& y% y以上就是我费尽九牛二虎之力挖掘的wmiacpi.sys的秘密了，再附上一幅我的debug环境J。- r5 P! m* U2 S$ u& \
* M: h! T- ?4 O) P, T3 l6 l3 f& w. U7 r; \
! R7 D, J) r6 E# U; O8 ]
图9
% C$ b9 F! E" ~8 T' l& `; ?That’s all!
6 B' t2 R$ z& v9 wPeter , Q+ ^& O% p+ W* V! G5 ^" E2 Q
: x7 v* j' Z) |# j9 S, O[ 本帖最后由 peterhu 于 2009-5-25 09:31 编辑 ] |
|
IP卡
狗仔卡
发表于 2009-5-22 17:14:23
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-22 20:27:37
今天我再试试也许就出来了