按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
以很方便地被几乎所有Windows下的编程工具所调用，因此目前基于IE内核的电子书似乎占据了主流位置。
2。2。1 CHM格式
CHM（发音为“chum”）的原意是piled HTML help file，是微软作为HLP格式（16位Windows下的标准帮助文件格式）的替代格式提出的，因此微软自己不仅随4。01以上版本的IE一起提供免费的浏览器，而且免费提供制作工具Microsoft HTML Help Workshop。
CHM文件内部使用ITS格式，这是一种非常优秀的压缩格式，感觉压缩比要比zip、rar大。
由于ITS格式的开放性，国外早就有人做出了CHM格式的独立编译、反编译工具，并且公开了全部源代码，需要的人可以到这里看：
bonedaddy/pabs3/hhm/
这个网站除了提供CHM编译、反编译工具及其源代码外，还提供CHM格式的详细说明，当然是英文的。我做的UnEBook在开始的时候，就使用了其中chmdeco的源代码，实现批量反编译CHM的功能。如果这个网站不幸登录不了，google一下chmdeco就好，有很多备份站点的。chmdeco内部使用的是chmlib的源代码，这份源代码很有名，除chmdeco外，chmtools用的也是它。
不过在使用了一段时间后，我发现这份代码在反编译某些CHM文件的时候，会出现数组越界错误。这种错误出现的概率虽然不大，但是出现后还是比较心烦，因此最终放弃了这份代码。
现在UnEBook使用的CHM反编译代码是从这里改出来的：
codeproject/winhelp/htmlhelp。asp
这份代码使用了微软未公开的ITS文件访问接口，直接对文件进行操作。由于使用的都是微软的东西，不仅目标码比较小，兼容性也好得多，目前还没有遇到反编译不出来的CHM文件（唯一的一次例外，是那个CHM文件本身就打不开），内存漏洞什么的也没有发现。看来微软的东西还是要由微软来对付，方为王道。
另外某些人制作CHM电子书的时候，为了省事，没有制作index。htm，而是单纯依赖左侧的目录树进行导航。对于这样的电子书，在反编译后，一般还需要根据生成的hcc文件，自动生成一个索引页，以免看的时候不方便。hcc文件结构大致如下：
多级目录通过控制，见到的时候往下走一级目录，往回走一级。
目录项以开始，以结束。以存放项名称，存放项链接。
某些目录项可能只有名称，没有链接。
在UnEbook中，不仅能够根据hcc文件自动生成索引页，还能自动生成框架页，将索引页和显示页嵌入框架中，以最大限度模仿CHM中的目录效果。如果要完全模仿能够动态伸缩的树形目录效果，则需要增加图片、js、css等文件，实在得不偿失。
2。2。2 EXE格式
除了CHM格式外，大量基于IE内核的电子书是以EXE格式提供的。制作EXE格式的电子书工具现在似乎已成为一个产业，养活了大批的程序员。虽然很多人认为这种格式的电子书很酷：一个文件就可以执行，界面也可以做得很漂亮，还可以带密码保护。但是我个人对这种格式的电子书是最最痛恨的：除了前面说到的安全性、速度、空间、检索等问题外，我最心烦的一点是目前的EXE电子书都没有好用的书签功能，尤其是没有能够定位到页面中任意位置的书签功能，看长文档看到一半的时候被打断会很麻烦，所以自从MyReader实现了书签功能后，我就下定决心一定要解决反编译问题。
2。2。2。1 Web piler 1。67
这种格式的电子书，因为其制作工具在国内出现得比较早，而且有非常彻底的汉化解密版，所以曾经比较流行，E书时空提供的很多电子书都是这种格式。不过也正因为它的流行，导致想反编译它的人也多，引出了各种反编译工具，所以现在用的人似乎已经不多了。
反编译工具里，收费的就不去说它了，国内RMH和Fbilo还联合推出过免费的unwebpiler，并且提供全套的Delphi源代码，有需要的到google或百度搜索一下unwebpiler就有了。不过可能国内大多数软件网站的管理员都不是开发人员出身，对源代码不感兴趣，所以收藏的都是212 KB的EXE，有源代码的不多，需要仔细找一下。
在unwebpiler的源代码里，RMH和Fbilo对Web piler 1。67生成的电子书的文件格式进行了详细描述，在这里我就不做无聊的重复，有兴趣就自己去看吧。我做的UnEBook也使用了他们提供的源代码，实现对Web piler 1。67生成的电子书的批量反编译，不过被我将代码从Delphi改成了C，似乎长度缩短了一些（原代码中有一段在字符串和十六进制数之间转换来、转换去，看起来比较怪异，被我省了），不过LHA解压缩部分改起来实在太麻烦，我直接在网上找了一段现成的C代码来用。
2。2。2。2 Caislabs eBook Pack Express 1。6
这个电子书制作工具也出过汉化版，所以在国内也有一定影响，不过这种影响似乎还没有大到足以使反编译工具满天飞的程度，嘿嘿……
在分析这种格式的电子书的时候，我没有使用任何反汇编工具，用UltraEdit32和系统监视工具就猜出来了：
文件标识：以十六进制串 00 F8 03 00 结尾。这个似乎是一种惯例，差不多所有EXE格式的电子书都有自己特殊的文件结尾。
目录块起始地址指针：0003F81C
目录块中目录项结构：以0字符结尾的文件名＋4字节起始地址，文件名起始字节为FF则目录块结束。
如果文件存放在子目录里，则文件名首字符：02＝。。/，01：第一个00变成/，直到遇到02。
文件内容实际起始地址：目录项里的4字节起始地址＋9
文件内容长度：目录项里4字节起始地址所指内容，DWORD。
在分析出目录结构后，我曾经想通过调试工具，分析文件加密算法，再反编译出具体的文件内容，但是很快我就发现那样干太累了，实在是得不偿失。
不过在经过几次尝试后，我还是找到了一个偷懒的办法：
通过安装hook的方法，往电子书的进程空间注入一个DLL。
在这个DLL里，用Windows标准的API函数URLDownloadToFile，就可以下载到指定的文件。文件的URL可以按前面说的方法，从目录项得到相对路径，再加上一个固定前缀（〃file：//Z：_caislabs_ebk”）构成绝对路径。
UnEbook在批量反编译这种格式的电子书的时候，就是按照上面的分析结果实现的。
不过到了更高版本的Caislabs eBook Pack Express的时候，似乎Caislabs公司也开始意识到文件内容保护的重要性，因此不仅对文件内容采用更强的加密算法，杜绝了可以用URLDownloadToFile下载的漏洞，连目录块的加密强度都强到足够使我不想去分析了。幸好这个时候我已经有了更好的反编译思路－－与具体文件格式无关的，专门针对使用IE内核的电子书的通用反编译思想。
2。2。2。3 通用反编译思路
在分析过几种电子书格式后，我开始领悟到一个真理：电子书内部文件结构的变化是无穷的，而我的时间和精力是有限的；把有限的时间和精力投入到对抗无穷的变数中去，早晚会有累死的一天。
有此认识后，我开始思考有没有什么通用的方法，可以解决大部分电子书的反编译问题（我还没有幼稚到相信这世上会有万能药的程度）。按照惯例（不可救药的职业病），第一步当然是市场调查、产品定位，结论是目前大多数电子书都是基于IE内核的，但是根据我在开发MyReader时对IE内核的了解，这里面明显存在一个误区：微软以控件的形式提供IE内核，其目的就是希望通过控件接口的开放性、方便性，吸引更多的人加入微软的标准阵营，如果想在此基础上添加加密、保护等等内容，恐怕与微软的初衷不合（我说的是当时，以后微软改主意了也说不定）。因此我相信IE内核一定有后门可走！经过一番努力，果然没有令我失望。
1、基本原理
针对IE内核电子书的通用破解技术实现起来可能需要一些技术和技巧，但是原理却很简单，几句话就可以说清楚：不论电子书在存储的时候如何对内容进行加密，在将内容传递给IE内核进行显示的时候，一定要将内容转换成IE内核能够识别的标准格式－－HTML格式。而IE内核为了便于显示、刷新，在对HTML代码进行解�