|
|
|
WMIACPI.SYS
/ D, d- E- {& f9 {; R3 r3 U2 Y1. WMI Concept4 U9 _* c4 k/ H* |7 D7 t
, U: Z. l% \6 @ o- p
WMI全称Windows Management Instrumentation是一种管理计算机系统的方式。它是微软基于WBEM的实现,WMI希望为系统管理以及分布式数据描述提供一种模型,并且允许使用基于COM的user mode API对系统部件进行访问、管理、控制。7 k/ M! X+ Y9 d% A# h' Z3 v& _
0 A& E3 U* q- @% U
& |5 @: U/ C2 o5 V2 U
2. WMIACPI.SYS
: E* D' S% Y. w: S- B/ V! D% G; F8 v- R
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达成的:
7 D4 x) P% [7 G+ @, Y- ~$ gA.Acpi.sys
+ E" z8 J, G) [9 n* ]B.Wmiacpi.sys
5 ^, E) u) x) ?: _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获得。, T* A6 F2 ]8 n% E/ d/ S
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:9 r3 W$ B1 T% E8 [3 Q# j
?2 v$ n9 l6 K* Y5 e
9 H! C* h h# }+ z
: A0 G* i9 s% J+ P9 y. ]2 P8 j( W
当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再返回具体信息然后逐级回送。; d! b( Y: l4 j3 U C4 B
# p$ S4 q7 |( d! a. U' |; z3. Under the hood# w: C" v6 t/ |: j9 ~4 {
. ^8 a$ q' `! X, N
前面都是原理的介绍,讲的我都快吐血了J,实践是检验理论的唯一标准。说不如做,随我揭开内幕一探究竟。WDK ver6000 src带了一个wmiacpi的samplecode,build之后会生成一只acpimof.dll,在BIOS里面将device.asl包进去然后再注册表中加入acpimof.dll的信息然后重启。讲到这里还要提到一个验证wmi的好工具叫做WMICodeCreator.exe微软的网站上有下载,下面我们就使用该tool验证前面的说法,下图2演示了我们定制wmiacpi之后的状况:
* l# b! X" r2 t5 ]2 T# F+ \3 e0 ?. H9 W: w( {8 l
" V! Y3 W# J* m( R# R- R) c! M# l
图 2
/ d- f) H1 r5 r5 h; w图2红色方框标注的AcpiTest_**就是我们定制的WMI class。也就是OS Load wmiacpi.sys之后将其MOF档案解析出来并加入到WMI repository于是我们就看到了上图的信息。下面我们来跟踪一下访问具体的class的情况吧,祭出WinDbg,let’s go!首先查看一下wmiacpi.sys这支driver有没有被加载下图3表明该driver被正常加载了。& d9 m& J! x8 E+ l& q4 o2 B, s
. W3 j3 G' t8 T p& \7 ?* @
2 s6 I% k5 W* U8 a; E% O( ?1 c图3
2 Q, ~; ` h- }, R; M$ u. @! A( I3 X由图3显示与wmi相关的有两个driver:wmilib.sys和wmiacpi.sys,wmilib.sys是干嘛的呢?别急后续讲述wmi driver的文章会详细介绍它。既然被加载了那我们就要dump wmiacpi.sys的symbol看看有哪些有用的信息,这样我们才比较容易下手J。下图4显示了wmiacpi.sys的所有symbol。
" ]: M4 ^$ V( a" |( w5 N9 ~1 V3 j( N' d; U7 C q
5 J: R# U- H ~4 X# L1 u
图4 ; g9 W/ {$ Q' E2 {& w. D
前面我们还讲到wmiacpi.sys最终会调用到acpi.sys访问asl code那我们再看一看acpi.sys有哪些symbol,下图5显示了acpi.sys的所有symbol:) G. L- x9 v7 L k3 J
. \* ~# ]4 d$ _1 e5 J
7 |; H! I( c0 J" x2 W" ~图5
) s5 E' W" h* i3 Z经过分析上述symbol我觉得下述函数很有作案嫌疑,所以将它们秘密监控J都给设上断点,被怀疑的对象如下图6所示:
) l/ d7 {3 o/ W9 f# c- g6 [% h$ h; |9 ^ e: `0 h% c2 @) O
: k: l: r u' J. ~) V( K5 C图6
% L: F3 d8 }* z( z如图所示:
& b% y q- b' x. z) o/ [) ^( G# X$ p5 @9 l# {* R: r; t$ Q$ h6 l
wmiacpi!WmiAcpiSetWmiDataItem M8 j, F, K" n* E; E7 {: G9 O0 a! I
6 v! c4 D* s E$ g d
wmiacpi!WmiAcpiSetWmiDataBlock
. l* K# }9 t$ |/ e7 `8 l
1 W, X# w, s& [0 }2 ywmiacpi!WmiFireEvent
. S: M+ O; y4 }3 \2 f) u% z) J* z/ W+ f1 _ T
wmiacpi!WmiAcpiQueryWmiDataBlock
4 k- y" X R2 E" \. h! H9 k/ {; W+ B5 I& b T7 K1 c' h$ |- G
wmiacpi!WmiAcpiSendAsyncDownStreamIrp
/ v+ U, g/ G4 j I
6 H k( F: m1 ^( |0 ^wmiacpi!WmiSystemControl7 W; P* c3 F% q$ B. T1 [1 N4 d
: [3 j( H7 @9 f8 a9 O" g8 G
wmiacpi!WmiAcpiSystemControlDispatch5 |. I* J2 x& |0 p7 K* Y) {0 J
. T/ r, n4 S# G/ T" r
acpi!ACPIIoctlEvalControlMethod# O) R& I$ h: n& @4 a9 c
; D9 R1 y; Y5 J1 q
acpi!ACPIIoctlAsyncEvalControlMethod
2 i& o( h1 h0 j, |: z+ E( |7 l# L. N# ^) j- n; {' }. m6 n$ [
acpi!ACPIIoctlAsyncEvalControlMethodEx) y2 \- X6 W% t$ J8 {! A* |
8 A0 _; W9 ^8 q8 ]
acpi!ACPIIoctlEvalControlMethodEx R( c/ e! g, r/ z
* e. x1 p7 H% x$ }) C: o
acpi!ACPIButtonDeviceControl5 U: @8 M1 D. f; V8 Q$ s) U! H
! s/ M4 i! t2 O9 f$ A, D. r( \
acpi!ACPIEcInternalControl4 A$ f, U! `" d' j/ l- H
0 G& g' l% d# R5 a* Xacpi!AcpiEmbeddedControllerIrpDispatch
" y( n1 T$ {+ q& {: b6 n3 a2 ?! {6 l1 U% O i3 |
acpi!ACPIIrpDispatchDeviceControl
$ n. \' e I: W5 \8 ]" ?2 S+ [/ T& a' u# y- A) K0 Z$ S: N
acpi!WmiSystemControl
1 S# O$ A* u& ?& j/ w
( m+ z8 ^1 A6 K; W- T( j这些函数都被设置的断点,下面就我们读写一个class试试看了,图7证实了我之前的所说绝非空口无凭,我们读AcpiTest_MPackage class时发现先会call wmiacpi!WmiAcpiQueryWmiDataBlock,然后acpi!ACPIIrpDispatch DeviceControl会接手,当然后续还会有别的一些动作,但是上述行为就足以支撑我的论点了J。
' [' d9 c" j1 G- n6 n
; l( F7 N8 M( y U+ o
& V$ _) f3 y' y; x4 A9 K5 X% R/ w9 l. n
2 f# a3 c: `; q1 J( c& g图79 h1 b1 Z: c8 z. T: n: O5 ^
图8演示了我们发一个event的状况,图中显示acpi.sys会接到该event然后透过wmiacpi!WmiFireEvent送给上层AP,上层AP再透过IRP下来qurey其它相关的具体信息。
7 i! O/ _! t% z. W0 i
! T8 Q+ z: f. t4 k3 E% s% K$ @2 z8 a+ |3 x8 ~7 `- Y) c9 a
' _; `+ G2 ~+ f; s' V1 K2 q图8 9 @, \2 [7 n# E, m
以上就是我费尽九牛二虎之力挖掘的wmiacpi.sys的秘密了,再附上一幅我的debug环境J。
1 V; S; s6 M; c4 s& E% ~( |3 S- I0 r/ O" y' h& u
1 }$ ?# R3 ?8 Y6 N+ ]. n7 H. ~( A1 ~" o9 U& g
图9 6 z g0 `" b; ]
That’s all!
# k$ @* w) Z. w: g1 _* a3 UPeter % L( B5 w9 E' y( _ z* U- f
+ F7 T: t% K- W2 g: s[ 本帖最后由 peterhu 于 2009-5-25 09:31 编辑 ] |
|