Lachesis Shield 设计上的抉择

最近有很多朋友和同学跟我谈起 Lachesis Shield 设计上的一些问题。我想我需要总结一下我的设计策略，虽然这是个看起来简单得不能再简单的工具。

我面临的选择：

 

1 界面位置
显然，有很多位置可以摆放这么个不起眼的东西，比如说：
a 就放在桌面上做成悬浮窗口，用 layered window 做成半透明。
b systray。
c deskband。

 

2 权限调整
a 只有两种状态，受限和不受限。并且对被控制进程来说一旦创建就不可更改。
b 用驱动定义多种权限并可以自由转换。

 

3 界面
a 鼠标单击切换。
b 针对软件复杂的功能设计复杂的界面和配置系统。

 

ok，以上就是我可以做出的选择，当然一切技术上的问题都不是问题。以下就是我的选择和理由：

 

首先这个工具最好是随系统启动，这个不影响选择。

其次，为了hook api，我可以用注册表，常规钩子注入dll，remotethread等等，我甚至可以用驱动。

 

我注意到一个事实：大部分的程序其实都是用户操作运行起来的，而这第一道门就是explorer。那么其实我只要把explorer的口封上，对于我来说目的基本就达到了。

于是，deskband成了不二之选。为什么呢？

作为进程内COM组件，deskband会被explorer自动加载，自然就完成了随系统的启动（其实是登录了）而启动，而且explorer被关闭还会自动重新启动，免除了额外设计恢复机制的麻烦。
其次，既然是进程内COM，自然就免除了注入代码这个手续。注意一个事实：很多杀毒软件对CreateRemoteThread这个调用是敏感的。
最后，deskband毫无疑问就是用来做界面的。

 

剩下的问题就比较简单，我没有必要也不可能选择驱动，这样不仅仅是带来额外的复杂性的问题。用驱动来修改windows内核的安全子系统的内部数据结构我不是不会，问题是这已经属于rootkit，绝对会被杀软封杀。其次这属于在windows内核的安全子系统插入第三方代码并且加入了令牌权限调整功能接口，这本身就是一个安全悖论。最后，这种奇技淫巧在windows x64上行不通，除非我再强迫系统关闭PatchGuard，这又是另外一个安全悖论了，我不能为了自己这么一个工具在系统上开两个大大的口子。

 

至于复杂的配置，我考虑过黑白名单，但是短期内我并不想加上，如果这个黑白名单被篡改就得不偿失了。

 

当然具体实现上还有一些其它的问题，比如必须用themeapi自绘，没有采用微软的detrous等等。目前被gdi+和safer api限定也很不爽。还有就是deskband这个接口貌似只有微软用得很正常（WMP），第三方包括msdn的例子运行起来都有点小问题。