谁动了我的Scancode?

 

谁动了我的Scancode?

一．Bug report

 

    DQA测试发现搭配在NB出货的一只软体，在某一model上运行发现：当打开vitsa的device manager后，该软体就无法正常工作了。

 

二．Bug Analysis

            

            我看到这条bug后，去找相关部门借了机台进行复制，发现复制不到该现象。请求DQA帮忙复制，DQA重灌OS后就又出现了这个问题。好像有点莫名其妙了，找不到复制手法，然后我又去借来了相似的model测试，仍然复制不出问题，一时间我有点没有方向了！L苦苦思索以后，灵光乍现，“会不会是uac导致的呢？”vista下的这个uac可是个大麻烦。后来我将uac disable一试，果然OK，一旦uac enable bug就又出现了。而且这些使用同一只软体的model上都是如此。所以完整的复制手法就是：打开device manager而且让它是Forground window，而且uac enable时，会出现该bug。

       复制手法找到了，下一步就应该去分析导致bug的真正原因了。祭出windbg挂上该软体，将断点现在Keyboard hook dll的回调函数中。（该软体通过使用hook拦截scancode然后再去做相应的处理动作），按照前面分析出的复制手法，开始复制问题，一次、两次，连续n次以后，奇怪了windbg一次都没有断下，没给我分析的机会？：），于是怀疑是不是windbg环境没有配置好？接下来我再在Keyboard hook dll埋上一只message，重新build dll并替换原来的dll，继续测试。结果依旧！那么谁动了我的scancode呢？结论是开启device manager并且foreground window的情况下，uac会屏蔽掉keyboard hook，于是该软体就没办法工作。

 

三．How to fix it?

 

找到root cause以后，就要研究解决问题的方法了。我能够想到的方法有以下几种：

 

1.     通过Raw input API获得keyboard的输入数据。

2.     通过60 port从EC端获取scancode。

3.     读取BDA keyboard data buffer获取scancode。

4.     写一只kbfilter driver拦截scancode。

 

方法1实验以后被否决了，该方法同样会遇到uac的问题。方法2应该也不行，因为只在interrupt 9到来时候去读60 port才会获得scancode，我在OS下拦截中断会有问题，如果scancode一旦被我从60 port读走，kbcobf就会被清零，OS就没有办法获得scancode。方法3打开SE后也被我否决了，按键下去以后BDA根本都不动，所以OS下keyboard 部分BIOS应该不处理了。所以只剩下方案4了。确定方向就开始行动了。WDK sample code有一只kbfiltr driver的example我打算拿它开刀了。Kbfilter driver在OS中的层次如图1红色部分所示：

 

 

在Kbfiltr driver中创建了符号链接以及设备节点而且拦截了需要的scancode，可是我发现上层AP无法通过打开文件和发送IOCTL和该driver沟通（不知道为什么，希望有知道why的各位老大指点一下小弟），后来我的做法是借BDA一用将41E~43E这段32 bytes的区域用作keyboard scancode fifo，上层AP读取该区域的内容获得当前 scancode。经过测试证明上述做法可以绕过 uac！

                    

              Peter

              12/20/2008