|
|
|
WMIACPI.SYS
5 V9 H( D) ~9 h' t4 u1. WMI Concept8 H, Q7 |3 u3 R. W1 ^
: j' b+ R6 j/ J% i3 E6 m$ `WMI全称Windows Management Instrumentation是一种管理计算机系统的方式。它是微软基于WBEM的实现,WMI希望为系统管理以及分布式数据描述提供一种模型,并且允许使用基于COM的user mode API对系统部件进行访问、管理、控制。
5 f+ J: l5 _1 q! P5 D q# D( v" z7 U5 B4 S3 B, R! ]
$ Y/ U# d6 A8 B/ y( U) j2. WMIACPI.SYS
8 [/ Z4 `4 b" t- q2 T% m, ]1 H2 L: P6 i+ i* L
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达成的:
) e3 p2 {" v7 H U5 VA.Acpi.sys
! t" t8 I$ W! S2 Y% ~! jB.Wmiacpi.sys
3 L- [9 X+ p. @4 R" [7 Z' RA).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获得。) b0 r$ V; D' K9 W8 j- d
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:, \) L/ O% H0 }6 X* e
w1 e' E( F% |; e0 V& Q
( k( }4 b+ _! p. b1 L% c1 |
, t& B% z9 M5 ^9 l当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再返回具体信息然后逐级回送。/ V: v/ l$ G! ? y, G
& d- i# M% l! T/ v6 V4 ?- \) Z: L3. Under the hood1 s2 T8 S* e9 `4 A
# N8 L1 l% D4 p9 C前面都是原理的介绍,讲的我都快吐血了J,实践是检验理论的唯一标准。说不如做,随我揭开内幕一探究竟。WDK ver6000 src带了一个wmiacpi的samplecode,build之后会生成一只acpimof.dll,在BIOS里面将device.asl包进去然后再注册表中加入acpimof.dll的信息然后重启。讲到这里还要提到一个验证wmi的好工具叫做WMICodeCreator.exe微软的网站上有下载,下面我们就使用该tool验证前面的说法,下图2演示了我们定制wmiacpi之后的状况:
: H* H# Y0 y- v# R1 U- _
( c6 e; b0 ^* }" A) m5 A0 E$ V) r! C1 o1 X
. ]9 B. o5 X \6 z5 ]: ^" y# h* Q" e/ z+ ~图 2
; @0 A- E, n1 h) T图2红色方框标注的AcpiTest_**就是我们定制的WMI class。也就是OS Load wmiacpi.sys之后将其MOF档案解析出来并加入到WMI repository于是我们就看到了上图的信息。下面我们来跟踪一下访问具体的class的情况吧,祭出WinDbg,let’s go!首先查看一下wmiacpi.sys这支driver有没有被加载下图3表明该driver被正常加载了。
; s0 L, G3 A2 P5 @1 v1 c! O t- O! g
- x* D5 W( Y, N! Q5 Y; e1 o
图3
, y/ R- ? M( A( }( r' n由图3显示与wmi相关的有两个driver:wmilib.sys和wmiacpi.sys,wmilib.sys是干嘛的呢?别急后续讲述wmi driver的文章会详细介绍它。既然被加载了那我们就要dump wmiacpi.sys的symbol看看有哪些有用的信息,这样我们才比较容易下手J。下图4显示了wmiacpi.sys的所有symbol。4 w1 Q0 P' L: _. K
- J5 p8 Z; [, p2 D7 A) c$ k# p
9 c8 U. |! f0 D8 l8 S
图4 7 @ i; u; _# [) L. [3 Q2 ?: ~
前面我们还讲到wmiacpi.sys最终会调用到acpi.sys访问asl code那我们再看一看acpi.sys有哪些symbol,下图5显示了acpi.sys的所有symbol:% [( A$ ^, y6 m9 B1 e
1 D- j. E+ F+ K2 `# q# Z% i
0 E N# g2 L4 D9 t/ B; `
图5
4 ]/ M' z/ q/ ~. O经过分析上述symbol我觉得下述函数很有作案嫌疑,所以将它们秘密监控J都给设上断点,被怀疑的对象如下图6所示:
# A" n' M6 {% @8 W o1 I R9 U# a- k
9 n% K# z' l6 J, g7 h" \
图6 3 ? X9 n6 d# C3 T
如图所示:0 [0 k0 f1 g# I) q
9 L0 A* l0 g4 |: E3 _6 T/ ]
wmiacpi!WmiAcpiSetWmiDataItem
: k4 V5 k6 B- s. o1 b \$ S/ `9 V* g! w2 ?6 W. b
wmiacpi!WmiAcpiSetWmiDataBlock& t( T& K q% K5 R$ m9 r2 Y6 l3 C
3 ^, @% h' k; C$ ~0 O$ b
wmiacpi!WmiFireEvent8 B- @! W' k; b8 z2 ]* a; C
R8 U& U& y+ J; y3 Hwmiacpi!WmiAcpiQueryWmiDataBlock. C% m0 e% X0 j/ a7 E' p/ {+ [- W
I$ `0 ^0 f5 Swmiacpi!WmiAcpiSendAsyncDownStreamIrp
% ~' b/ F+ z; P: t0 o U
. Z+ X' I8 G: N, H- L, ?wmiacpi!WmiSystemControl
2 i/ S% ]: s1 R4 |% x* y, q- |1 B4 y+ N( C2 o6 c
wmiacpi!WmiAcpiSystemControlDispatch
# X; g. w; ~8 a9 d2 v: f( l( u/ X8 E7 T7 l2 s- Z* Q) `
acpi!ACPIIoctlEvalControlMethod
U6 O& T: [% j7 W$ {0 z
6 ~% v, L/ B' m: v Zacpi!ACPIIoctlAsyncEvalControlMethod2 y- W# N" U; o. B4 b( G3 _2 B
- t" A- r+ o$ K9 ~
acpi!ACPIIoctlAsyncEvalControlMethodEx
" h! n; U8 h4 [4 w( |
( R. V Y: |! S. e; yacpi!ACPIIoctlEvalControlMethodEx0 @( L* f+ t0 ~( F; |9 W. e
7 i; T4 g& b6 y Y6 _5 [
acpi!ACPIButtonDeviceControl1 T$ H$ X- @( Q, j* k+ }$ h1 j% v+ p
( c* A( V0 }3 r, s! J' t
acpi!ACPIEcInternalControl6 F) d" h7 S5 S
1 f3 D+ v& l' j, `3 Nacpi!AcpiEmbeddedControllerIrpDispatch
! z) z5 |+ k+ f) ~
% G- g" h! K6 W, h, }* ]7 d+ z' ^acpi!ACPIIrpDispatchDeviceControl
; [" @* l" W1 P& p- F/ q, U/ a+ D5 a7 z, u9 n3 M" B: @
acpi!WmiSystemControl7 N) ~$ t5 K6 F
' I/ d# X6 H, F这些函数都被设置的断点,下面就我们读写一个class试试看了,图7证实了我之前的所说绝非空口无凭,我们读AcpiTest_MPackage class时发现先会call wmiacpi!WmiAcpiQueryWmiDataBlock,然后acpi!ACPIIrpDispatch DeviceControl会接手,当然后续还会有别的一些动作,但是上述行为就足以支撑我的论点了J。
6 b7 g$ d/ I' r; o+ W9 l& O
9 B' v( O1 N' l, B
@1 P, h" A. V1 l4 L5 n0 F, `8 ~# A- Y0 l. Y" L
. g( v7 E- p( F2 k. B. h图72 D% B$ g' X9 L/ d7 P8 g" c3 q
图8演示了我们发一个event的状况,图中显示acpi.sys会接到该event然后透过wmiacpi!WmiFireEvent送给上层AP,上层AP再透过IRP下来qurey其它相关的具体信息。
3 v- g4 F% ^: F9 c4 s" g2 O( ?
) n* v5 m4 |, k1 T' O- | U4 d# A {% R2 g5 U- O
9 i2 s* J2 t& j+ M% [图8 % X5 N; B+ f6 [9 A5 ]
以上就是我费尽九牛二虎之力挖掘的wmiacpi.sys的秘密了,再附上一幅我的debug环境J。! g- u& k; h7 Y6 j" h
$ J: A& P- x! y% h
3 s3 ~2 e) K; D9 X4 I; k4 Q5 V% e- G: H) D, ?, S
图9 $ X( F; U7 h* c1 f
That’s all!0 ~$ y1 T+ n* B9 ~
Peter 4 n! d' R+ [. m" I
2 s% j! D6 o/ n3 o( [+ `6 ?2 A
[ 本帖最后由 peterhu 于 2009-5-25 09:31 编辑 ] |
|