|
|
|
WMIACPI.SYS 3 A9 T& Y7 {6 I, a9 \) d5 `7 H
1. WMI Concept
M& Y' [, ~& O' n6 c, D2 {& x
5 F" p" i. U) z% pWMI全称Windows Management Instrumentation是一种管理计算机系统的方式。它是微软基于WBEM的实现,WMI希望为系统管理以及分布式数据描述提供一种模型,并且允许使用基于COM的user mode API对系统部件进行访问、管理、控制。$ R5 g% H% P! l) b
* }: A; r! D" y5 z5 m4 ~9 L d1 J$ L* b9 `& A! p/ x
2. WMIACPI.SYS1 f# s' L( M0 N `. [$ {
% A; [# ]. l1 E' W3 R: U9 y
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达成的:8 k0 Q) G; Q" H* t+ r- z
A.Acpi.sys/ x! m- H$ h" t9 V9 C: \% A
B.Wmiacpi.sys8 k5 B. F) h. D, p" ~- E) a' p( ?
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获得。4 c( f7 C* C% D+ o G3 v
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:
( ]3 y2 w2 V8 T5 c/ d: ?4 H, [( c. G
{4 T1 |1 G& H6 l$ ?- z
$ l7 `$ C5 A' [( H* ]
当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再返回具体信息然后逐级回送。
! {7 E/ ~! c4 O7 c& [) H u. y0 F" ~+ v) Q% a3 u; z
3. Under the hood# w5 b" ^7 ^' Q& R3 ^
; K1 N$ H) x( N3 j/ `6 y
前面都是原理的介绍,讲的我都快吐血了J,实践是检验理论的唯一标准。说不如做,随我揭开内幕一探究竟。WDK ver6000 src带了一个wmiacpi的samplecode,build之后会生成一只acpimof.dll,在BIOS里面将device.asl包进去然后再注册表中加入acpimof.dll的信息然后重启。讲到这里还要提到一个验证wmi的好工具叫做WMICodeCreator.exe微软的网站上有下载,下面我们就使用该tool验证前面的说法,下图2演示了我们定制wmiacpi之后的状况:8 T$ y5 z) V' _: H
3 f( @/ `4 S H7 X/ ~0 V" l1 F* s
6 s" z" k/ H F
图 2 : t/ G3 B+ d8 N, P3 J0 E$ Z3 X3 c; B& t
图2红色方框标注的AcpiTest_**就是我们定制的WMI class。也就是OS Load wmiacpi.sys之后将其MOF档案解析出来并加入到WMI repository于是我们就看到了上图的信息。下面我们来跟踪一下访问具体的class的情况吧,祭出WinDbg,let’s go!首先查看一下wmiacpi.sys这支driver有没有被加载下图3表明该driver被正常加载了。* F" r( s' D' h' Z0 B+ e
8 v5 X s, l; s+ l
' a% I, X# @6 L4 w5 b% w# r5 S
图3 . p7 G% W( C; D9 Y8 W( u1 Y3 j, M; U* r
由图3显示与wmi相关的有两个driver:wmilib.sys和wmiacpi.sys,wmilib.sys是干嘛的呢?别急后续讲述wmi driver的文章会详细介绍它。既然被加载了那我们就要dump wmiacpi.sys的symbol看看有哪些有用的信息,这样我们才比较容易下手J。下图4显示了wmiacpi.sys的所有symbol。
5 \& I; A$ m: Z/ U0 @" e( g% i* o2 a$ X9 ]5 u+ p0 t( U8 X
5 x3 \1 X0 {( f6 _: q图4 1 F) Q3 J5 Z& X& J ~3 C
前面我们还讲到wmiacpi.sys最终会调用到acpi.sys访问asl code那我们再看一看acpi.sys有哪些symbol,下图5显示了acpi.sys的所有symbol:
& T0 `# f1 Z/ v! l) D. d+ j* _- s' f
3 K, Z% S8 q C4 K( j/ X5 u" C X图5 9 B2 ]2 f4 E$ {" a% F# d6 i
经过分析上述symbol我觉得下述函数很有作案嫌疑,所以将它们秘密监控J都给设上断点,被怀疑的对象如下图6所示:; V0 h, e c8 k- K
3 j1 C" M' z" @; R, B) l' j& W+ F S1 r
图6
. q4 M z& z2 \8 L7 H: f如图所示:
9 V. f# t1 B' K& g* T/ I9 r! o6 c' Y0 ^. c6 y- G8 Q, `( r$ K; C- W6 q( M
wmiacpi!WmiAcpiSetWmiDataItem
' n! N& S2 _- c: U3 t3 e5 ~& {1 b2 g% _1 y+ a6 B @
wmiacpi!WmiAcpiSetWmiDataBlock/ @, n" d8 T; R2 y2 g5 j
; y& o, e: [ Z6 v1 ]3 Jwmiacpi!WmiFireEvent! J0 H+ O' B. \9 b, r7 ^2 i0 T
5 Y! x( k z5 l$ wwmiacpi!WmiAcpiQueryWmiDataBlock4 E/ D2 ?- M$ g
7 f; n3 T- i/ J" N) _
wmiacpi!WmiAcpiSendAsyncDownStreamIrp
5 b# o$ E% ]$ l$ t; F5 U
6 C& r, ?3 I: X2 Z/ Jwmiacpi!WmiSystemControl
& O |2 b+ R9 L( `
) u8 Y. I7 p8 Q9 _+ b# \wmiacpi!WmiAcpiSystemControlDispatch
# g9 i6 w$ ~8 _; f
% Q( [( X9 Z# m7 @; B! ^acpi!ACPIIoctlEvalControlMethod4 {: Q$ m% K* |1 z2 a% B3 X) @5 p
2 d7 ^5 H f" ?4 Wacpi!ACPIIoctlAsyncEvalControlMethod( x! K s2 Y/ ~/ h
u2 A. u" U h: J ]1 }) racpi!ACPIIoctlAsyncEvalControlMethodEx
; u5 x" l0 I% _: h) Z% W8 M" ?/ B! _, a# G2 S9 T
acpi!ACPIIoctlEvalControlMethodEx
8 W8 X R+ u* F6 f- G- [' L
- |) k. ]- {7 Z" _1 E2 B( Eacpi!ACPIButtonDeviceControl
& ], W% u4 c2 `6 U- o$ A4 g0 c( @9 m7 y5 i# g& U% r
acpi!ACPIEcInternalControl
; i) m2 G9 `9 t7 [! }6 _$ T, ?1 p2 y- b/ P. ?: s
acpi!AcpiEmbeddedControllerIrpDispatch
- C: W8 f$ |8 L- z" F K4 @$ @, A. [, K5 _7 w
acpi!ACPIIrpDispatchDeviceControl
$ _+ t" m5 N6 R) x$ ]0 v: y& H- ~1 p9 [6 V) p; l: ]0 `3 `
acpi!WmiSystemControl2 _, o3 s0 E* ]
) e, m) P/ H0 O1 W, I这些函数都被设置的断点,下面就我们读写一个class试试看了,图7证实了我之前的所说绝非空口无凭,我们读AcpiTest_MPackage class时发现先会call wmiacpi!WmiAcpiQueryWmiDataBlock,然后acpi!ACPIIrpDispatch DeviceControl会接手,当然后续还会有别的一些动作,但是上述行为就足以支撑我的论点了J。
" t, ?3 _" g+ @
9 H, t1 [# j. I3 {9 i& d
2 K8 f- T, ?' }* b- N& j; b# t" S+ s
$ u# p! l5 d/ N" ]图7; G: }0 l6 |! E6 u
图8演示了我们发一个event的状况,图中显示acpi.sys会接到该event然后透过wmiacpi!WmiFireEvent送给上层AP,上层AP再透过IRP下来qurey其它相关的具体信息。9 s. D0 q& U: b
& F3 Y# G, P7 c# y# c8 P4 g B
! e5 K: I! w, M! k0 R& }
: w( @/ D- j0 k( y图8 6 p7 `4 c2 F( [; w
以上就是我费尽九牛二虎之力挖掘的wmiacpi.sys的秘密了,再附上一幅我的debug环境J。
1 N/ o4 L- w$ D, ^ K* A2 ^ i% }+ h; e
- K M5 K: @$ j+ N* C5 R5 P
E' t! r/ @ T7 f图9 4 \4 h, [$ }- ^) d
That’s all!2 d+ _7 |$ T! j6 n/ O5 R+ o' M4 t: c
Peter
# N0 M% r$ s$ j( h3 r) B4 ?
8 h2 `. S$ @$ j; `[ 本帖最后由 peterhu 于 2009-5-25 09:31 编辑 ] |
|