|
|
|
WMIACPI.SYS
; O0 a. {1 ?* Y0 P8 R: C1. WMI Concept/ S" q" ?) f+ K; S! n- z' Z
0 J9 x: H, s1 V8 V' H
WMI全称Windows Management Instrumentation是一种管理计算机系统的方式。它是微软基于WBEM的实现,WMI希望为系统管理以及分布式数据描述提供一种模型,并且允许使用基于COM的user mode API对系统部件进行访问、管理、控制。/ P6 g8 ^* _1 y' i/ p
& P9 _5 w( A+ r# J
- e( L% n0 c" `: X* W
2. WMIACPI.SYS
# x9 u: w0 @, [. }& f- n( W$ Z% t" T+ O" c6 v9 O) q0 C
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达成的:. n6 b1 ^( ~- ]+ |, P& {
A.Acpi.sys
( ?, t' h/ d+ E3 C: Z2 WB.Wmiacpi.sys
* }( w6 S0 s: O( P: IA).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' b+ k$ Z; O, _
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:! E7 X) H# S- J
, W6 y; {$ K" r0 O$ F, I6 h
8 ^; ^0 \" O+ k/ i9 b
$ D6 i' R/ Q& W! j当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再返回具体信息然后逐级回送。, C, u2 d y- \1 n
0 k/ k3 m y% z2 c& K* F8 T
3. Under the hood
/ J4 c; h2 i2 z+ }. ^, i
9 l. X% L4 z% z9 W前面都是原理的介绍,讲的我都快吐血了J,实践是检验理论的唯一标准。说不如做,随我揭开内幕一探究竟。WDK ver6000 src带了一个wmiacpi的samplecode,build之后会生成一只acpimof.dll,在BIOS里面将device.asl包进去然后再注册表中加入acpimof.dll的信息然后重启。讲到这里还要提到一个验证wmi的好工具叫做WMICodeCreator.exe微软的网站上有下载,下面我们就使用该tool验证前面的说法,下图2演示了我们定制wmiacpi之后的状况:( z) ^6 ]3 S4 K* S8 e' U# X
5 }( J0 D4 f# l4 Z L
" a) J" t9 [( j+ g( r
' f% t2 ^. X5 _图 2 4 _2 T2 m& }) ?: k9 w
图2红色方框标注的AcpiTest_**就是我们定制的WMI class。也就是OS Load wmiacpi.sys之后将其MOF档案解析出来并加入到WMI repository于是我们就看到了上图的信息。下面我们来跟踪一下访问具体的class的情况吧,祭出WinDbg,let’s go!首先查看一下wmiacpi.sys这支driver有没有被加载下图3表明该driver被正常加载了。. O/ r( K' {/ A, s3 W
7 W3 ]2 b& f* i, C g/ k2 W( y. `7 [; K2 m. B, u
图3
2 l: w3 ^8 g. ]* ^* T. _' d由图3显示与wmi相关的有两个driver:wmilib.sys和wmiacpi.sys,wmilib.sys是干嘛的呢?别急后续讲述wmi driver的文章会详细介绍它。既然被加载了那我们就要dump wmiacpi.sys的symbol看看有哪些有用的信息,这样我们才比较容易下手J。下图4显示了wmiacpi.sys的所有symbol。$ }1 e+ @6 z8 d+ R; i
6 z1 ?! m& u) e: z f( T
* J# F: u' d! E7 o; q0 b
图4 % F' B( W# p3 W9 \5 [2 W
前面我们还讲到wmiacpi.sys最终会调用到acpi.sys访问asl code那我们再看一看acpi.sys有哪些symbol,下图5显示了acpi.sys的所有symbol:# ~4 [) b+ ^# T8 Z
; U8 Q4 \- n. N2 O2 w, O. g# ]2 H+ Z0 @" w9 T9 r
图5 1 Y4 V% H- g4 ^6 s( m- w
经过分析上述symbol我觉得下述函数很有作案嫌疑,所以将它们秘密监控J都给设上断点,被怀疑的对象如下图6所示:
/ K, s6 c, A7 m/ |" W1 a6 }, f( a) S: x( Z1 n6 Z8 `# N0 }2 [0 C2 J. p4 M
( ~, V7 u5 k' p" ]& r图6
* `% Z5 f/ q# z7 X7 c) l如图所示:
: e4 Y: v/ w" t! I: E+ \8 E1 ]9 I) o0 a$ v
wmiacpi!WmiAcpiSetWmiDataItem
4 y! F) f) b( ]- T s# ~2 R0 i5 K; \+ }$ ^1 [% i" O3 w) D
wmiacpi!WmiAcpiSetWmiDataBlock5 ?5 w& w) X+ I7 W1 P( C
- t9 L3 ?) f; L" i+ A# Q8 ^
wmiacpi!WmiFireEvent
; M/ F" N( Q f! i# H0 a; ^+ U, O- A7 n* p5 B) N+ ~5 P
wmiacpi!WmiAcpiQueryWmiDataBlock
# U5 g/ p& @9 P8 D; \0 M3 C% M ^1 V5 d
wmiacpi!WmiAcpiSendAsyncDownStreamIrp2 L% O& N5 i0 n& B1 p( F5 @
% U! Q; u, t% f3 g8 C( N
wmiacpi!WmiSystemControl" }1 n4 M7 e s2 A* V
4 L/ P& w6 m/ |9 q; y
wmiacpi!WmiAcpiSystemControlDispatch9 L' _8 {' |" Z- n
7 A& u: A- ^# L
acpi!ACPIIoctlEvalControlMethod
" D) @$ w; m/ {9 Z9 F$ S9 S
8 d4 Q8 V w) t' m/ ^0 ^5 Jacpi!ACPIIoctlAsyncEvalControlMethod/ A/ F) C9 K: T Z
, o; e/ z( o- c* D% i' ?5 B6 e: j
acpi!ACPIIoctlAsyncEvalControlMethodEx
: n& H. W$ y w; \: y1 q% d# ~! X0 k3 a& n7 ]# |3 B- c5 x: }5 m
acpi!ACPIIoctlEvalControlMethodEx! g3 {/ d& ], X
7 [4 \( O B2 d- M4 E4 f4 macpi!ACPIButtonDeviceControl3 o% ]# f2 `7 C2 ~
! \1 o" ?4 V3 Z/ ?3 n0 J
acpi!ACPIEcInternalControl
4 i2 z- }7 A6 L7 c
- c- j2 u9 n' L7 e8 _% U$ ]acpi!AcpiEmbeddedControllerIrpDispatch
# ?6 w9 m, a' P& p: P, l" k7 M- R: {4 r& _$ B) R+ r, S' e# _
acpi!ACPIIrpDispatchDeviceControl
6 U, [# I" k3 y7 O4 y) X: H. }% n) x! Y; V! h" y9 z
acpi!WmiSystemControl/ {# }( n2 Q! [5 d
% t Z: f3 s; F2 ]这些函数都被设置的断点,下面就我们读写一个class试试看了,图7证实了我之前的所说绝非空口无凭,我们读AcpiTest_MPackage class时发现先会call wmiacpi!WmiAcpiQueryWmiDataBlock,然后acpi!ACPIIrpDispatch DeviceControl会接手,当然后续还会有别的一些动作,但是上述行为就足以支撑我的论点了J。7 Q/ {3 S, M" E7 u$ [) L/ o
! E6 |8 V& F- ^$ u. [ t+ f" q* K8 i$ j2 N" b) K' i0 D6 T
/ N& `+ t& g. I* y: {
, f+ ^, h& z0 u3 _) u+ T
图79 Q6 q2 z# u: t! d
图8演示了我们发一个event的状况,图中显示acpi.sys会接到该event然后透过wmiacpi!WmiFireEvent送给上层AP,上层AP再透过IRP下来qurey其它相关的具体信息。
0 n9 u; |0 L d& O3 Z; M# Q6 K% j8 t
* |3 `$ ^6 @ H+ t" `# k$ |; b
2 F* p6 z/ a, Z( V3 Q0 R, z6 g+ m1 }, K4 n1 Y/ _
图8
9 H G+ {* G0 } Z2 F7 H以上就是我费尽九牛二虎之力挖掘的wmiacpi.sys的秘密了,再附上一幅我的debug环境J。
/ q( @9 [& M5 h1 x/ Y" C# ?, V- ^$ c9 P
8 W( h8 {2 R' H8 ? E1 n- @5 T, t5 G: M% l- t
图9
6 E% H4 B; \! a# T) R+ ]That’s all!
$ Q8 L; N* U5 C* L5 j3 UPeter D7 U0 [! v M7 g" Z
) `% S6 Y% ], \' I. y Z[ 本帖最后由 peterhu 于 2009-5-25 09:31 编辑 ] |
|