APIHook的透明加解密

 

采用ApiHook技术实现的透明加密不安全，很容易被破解

这个论调的提出，恐怕是某家采用驱动层透明加密的厂商放出来的。而且据说这家厂商破解了很多其他公司的加密软件，但是自己的还没有被破解。

其实认清这个问题很简单，透明加密软件的核心是加密，围绕在周围的还需要很多辅助模块，比如剪贴板的控制、比如拖放的控制、比如OLE嵌入的控制等等。而这些模块是不可能通过内核级的模块来处理的（理论上可行，但我相信没有人敢这么做，因为都是非公开接口，稳定性没有任何保证）。很自然的这些模块最终需要由应用层来完成。

一根水管，从自然水厂到家中，经过的接头越多，出问题的可能性就越高。加密软件同样如此，做同样一件事情，经过的环节越多泄密的风险自然也越大。APIHOOK所存在的泄密风险驱动级的产品必然也存在（因为他还是要用到APIHOOK)，而驱动级产品却还要承担驱动层泄密的风险。

那为什么就家公司能破解很多别人的产品而自己的很少被破解呢，很简单，开发人员的水平并不在同一个水平线上，目前市场上的大多数应用层透明加密软件均是通过产生临时文件的方式来实现的，并且对于UnHook、Dll强制卸载、Dll注入等均没有作有效的保护。产品满身都是窟窿自然不需要专业的水平就可以轻松破解。而另一方面，他的产品试用版的发放很严格，你拿不到产品自然就无法破解了。

  

反正采用APIHOOK技术实现的产品安全性不高，用生成临时文件的方式又有什么关系

这个命题其实是个伪命题，目前还没有任何证据能够证明APIHOOK技术存在着不可解决的问题，也没有证据能够证明APIHOOK技术安全性不高。但因为这是一个网友提出的论调，所以在此反驳一下。

一个透明加密软件的品质，有三点是很关键的，一个是自身的健壮性、一个是性能、一个是稳定性。由于复杂度的问题，驱动级产品的稳定性一直不是很好，在此我们不再比较。剩下的就是健壮性和性能，当采用生成临时文件的方式来实现时，因为明文落地了，此时无论你采用任何方式来保护都是不可能有效的（这在学术界早有定论），我们国家对于加密类产品也有这方面的要求。当然大多数厂商都还是会做一些保护的，比如加个驱动程序，不让其拷贝这个明文（美其名日驱动加密）、或者对FileMon做单独的处理，防止他监控到那个临时文件等。但这一切都是那么的脆弱。就象是建了一幢豆腐渣工程，然后再在里外加点竹竿撑一下而已。

而对于性能，那差距就更明显了，我们知道，现代计算机CPU的运算速度已经远远超出了我们常规使用的需求，而计算机中最慢的设备，真正能够使用户感觉到快慢的设备正是硬盘。而采用临时文件的方案，其最核心的恰恰是作用于硬盘。我们举个例子，Photoshop打开文件前可以进行预览，假如说有个文件是100M（这个不算大吧，我见过的广告公司的文件大多是超过500M的）。Photoshop这时候要去预览他，可能只需要读取100K的数据，但为了要读取到这100K的明文，却不得不将这100M文件读个遍，然后解密，然后写到硬盘的临时文件中，在我们的测试中，解密100M文件到硬盘根据机器性能的不同，大概需要8~15秒。用户本来预览一个文件根本就不需要等待，可安装加密软件后，预览每个文件却不得不多花那么多的时间，如果一个目录中有很多文件，他要一个一个找的话，我相信用户一定会发飙的

或许有人会说随着SSD硬盘的推广，性能方面的差距将会减小。我暂且赞同这种观点，但是不要忘了，这方案安全性方面的影响永远也解决不掉，当然了，如果你使用SSD硬盘的话会带来另外一个更为严重的问题，因为MLC芯片的寿命很短，大概只能写上10万次左右，而SLC芯片虽然要长得多，但和传统的温氏硬盘来讲，还是要差几个数量级。如果采用临时文件的方案，说不定哪一天硬盘就挂了。

  

市场上那么多软件都是采用依赖临时文件的重定向方式

如果所有的软件都是采用重定向的方式来实现，或许大家都会心照不宣，相安无事。但这只是一厢情愿，还是有不少产品是用的是真正的透明加密技术，假李鬼早晚会碰上真李逵的。只要大家把工作原理一讲，有哪个客户还会用采用文件重定向方式做的产品呢？

做软件和造房子真的很象，核心技术就象是地基，如果核心技术就是一个伪技术，那么在这上面构建的产品无论功能多么非富，界面多么漂亮都只不过是一些装修豪华的豆腐渣而已。如果房子造好后被客户发现没有地基，这时候恐怕只能拆掉重建了。

  

64位的操作系统将不再能够进行ApiHook

What a surprise.我不知道怎么会有这样的说法，但我的确碰到不少不明真相的群众向我咨询这个问题。我要说的是我对某些散布谣言的人已经出离愤怒了。

众说周知，64位系统为了更高的安全性，加入了PatchGuard——一种防止恶意软件进入内核的功能。同时他也使得象杀毒软件等于内核紧密相连的产品也被阻挡在外，这使得Mcafee、Symentec等厂商奔走相告，威胁要对Microsoft提出垄断指控。最后Microsoft不得不让步向这些厂商提供相关技术资料。但是毫无疑问，他决不会向所有的厂商均提供此技术，很遗憾的是，绝大多数中国厂商均不可能获取这方面的技术资料。要想突破PatchGuard，只能Diassembling。就象病毒木马的作者一样做。

切入正题，谈下ApiHook的技术能不能在64位系统下正常工作，我们知道Microsoft有一个产品叫做Detours——当前最新版本是2.1——一个提供ApiHook功能的库。他就提供了X86/X64/IA64三种指令体系的支持。Detours在Microsoft内部被广泛的应用于调试一些底层软件等工作。他也同时对外提供商业产品，对于非商业应用也是提供源代码的（当然仅支持X86体系）。笔者研究了下Detours的源码，将非商业源码改成支持X64的工作量并不大，主要是CPU指令集有所变化及地址长度不同。

如果您想将自己塞入保险箱中，那么找一个北美地区的朋友购买一份商业版本的Detours源码。否则参照AMD的X64指令集，重新修改一下Detours的源代码，这比突破PatchGuard要简单和正当的多了。

TES透明加密模块FAQ

Q:可以选择性加密码？（比如同一个WORD里面有些后缀加有些后缀不加可以做到吗？）
A:可以。

Q:安全模式下和虚拟机里面是否可以操作？
A:可以

Q:系统除了2000以上VISTA以下操作以外，ghost、久久猫、番茄家园、电脑公司版本等都可以装的上去吗？
A:可以

Q:记事本可以加密吗？
A:可以。

Q:临时文件是怎么处理的？
A:我们的工作原理不需要生成额外的临时文件。

Q:截屏是怎么处理的？
A:可以自行处理，或者另外购买反截屏模块。

Q:XES的稳定性怎么样？会蓝屏和死机吗？会不会有加密的文件解密了之后导致打不开的现象呢？
A:非常稳定，这是我们最大的优势，同时基于应用层的方案不可能会导致蓝屏。基于应用层的方案也不会出现文件打不开的情况。

Q:听说基于驱动层的透明加密技术更容易破解，是这样吗？
A:目前市场上的绝大多数基于应用层的加密软件，因为没法处理几个关键性的技术问题，所以大多采用了文件重定向的方式来做，即当要打开一个加密的文件时，首先将文件解密至一个临时文件中，然后将所有针对那个加密文件的读写全部重定向到解密出来的文件。毫无疑问，采用这种方式，速度的影响非常大，另外更为关键的是由于在硬盘上生成了明文，只要稍有技术的人即可知道文件是解密到什么地方的，然后就可以破解。毫无疑问，采用这种方式的应用层加密是很容易被破解的。而TES透明加密模块采用了突破性的技术，可以真正的实现硬盘无明文的目标，同时也是不会对速度有明显的影响。

Q:TES加密模块会影响性能吗？
A:从理论上讲，多了一层加密肯定会有一定的影响。但TES透明加密是按需完成的。他并不存在瞬间并发的处理，所以真正使用的时候用户是不会感觉到这种差别的。举个例子，photoshop去打开一个图的时候可能会先显示这个图的预览。如果这张图有100M。而显示预览所需的数据为20K。那么我们实际上只要解密这20K的数据，并且这个过程是在内存中完成的。在当今如此高性能的CPU下，这个影响用户根本不可能感觉出来。

Q:TES透明加密模块与TEFS、SEFS等内核层加密的技术主要有哪些区别？
A:与基于驱动层的加密技术不同，TES始终将稳定、兼容性放在最优先的位置上。首先从技术层面上讲，他绝不可能产生蓝屏。其次由于微软操作系统的封闭性，越是到底层越有不为人知的技术细节，操控这越困难。使得基于驱动层的加密经常会产生如文件永久性损坏等问题，而这些却根本无法有效解决。而TES均是采用的成熟技术，目前在13,000台左右的机器上使用，均未有任何记录表明其会导致文件损坏。另外国内的正版情况很差，大量的系统带有木马、病毒等恶意软件，基于驱动层的加密对这些情况兼容性很差，通常会要求客户的电脑很干净，而TES在这方面的要求相对要宽松的多。

Q:TES透明加密模块同其他的应用层加密技术有什么不同？
A:同现在一些公司采用的应用层加密技术相比，TES有着本质性的突破。在扩展性方面，TES采用同驱动层加密相近似的处理方式，对于所有的IO操作均采用统一的处理方式，所以并不需要对不同的应用软件做单独的开发。在速度方面，TES采用的工作原理并不会导致性能明显下降。在抗破解方面，TES已经处理了现在能知道的破解方式。

Q:TES既然是基于应用层的，那么对于不同的应用程序需要做专门的开发吗？
A:TES内部的实现方式类似于内核层的处理方式，他是对系统各输入输出接口的完整处理，所以不需要做特定的开发。包括象控制台程序、采用内存映射方式读写文件的程序均可正常处理。

 

 

前几天看了一个介绍NB的透明加密软件

看其介绍是能够支持内存映射文件的，但通常的做法是文件重定向，即打开时解密文件，关闭时加密文件。不知道这软件是怎么个实现原理，按照习惯的方式，运行Word，随便写一段文字，然后运行FileMon，设置过滤条件为WriteFile。OK,保存文件，没有明显的记录表示采用了重定向的处理方式，莫非他也实现与TES类似的处理方式。但感觉总有点怪，保存文件的时候有点卡。突然想起了以前在开发TES内核时碰到的诸多难题后打算放弃，采用重定向的方式来实现。当时就有一个恶心的处理方式来防止重定向时被FileMon发觉。莫非这哥们也很有才^_^。

这回换用FileMon的增强型版本ProcMon。过程还是一样，运行Word，设置ProcMon的条件为：processName=winword.exe,operation=write_file。OK，保存文件，狐狸尾巴终于出来了，日志清楚的表明了其重定向的路径。

看来我的想法一点都没错，用的就是我N年前想到过的处理方式。我们知道FileMon是从驱动中获取各种对文件的操作，然后传递给应用层模块进行显示的。而Filemon早期的版本是开源的，传递数据的格式就是公开的。利用这一点，我们可以对FileMon这个软件进行单独的处理，当日志的内容为重定向文件时，就将这条日志清除掉。

再次运行FileMon，然后运行RKU。点Cood Hooks，再次映证了我的观点，FileMon的DeviceIoControl被Hook了。

在我做完这一切后，系统竞然提示我说虚拟内存不足，我赶紧查了一下，发现Explorer.exe竞然占了800多M的内存，看来这个NB软件在内存泄漏方面也是很NB