|
| |
 精品推荐 |
 |
|
| |
|
|
|
|
常见电子书格式及其反编译思路
|
日期：2008年3月18日 作者： 查看:[大字体
中字体 小字体]
|
这种格式的电子书，因为其制作工具在国内出现得比较早，而且有非常彻底的汉化解密版，所以曾经比较流行，E书时空提供的很多电子书都是这种格式。不过也正因为它的流行，导致想反编译它的人也多，引出了各种反编译工具，所以现在用的人似乎已经不多了。
反编译工具里，收费的就不去说它了，国内RMH和Fbilo还联合推出过免费的unwebcompiler，并且提供全套的Delphi源代码，有需要的到google或百度搜索一下unwebcompiler就有了。不过可能国内大多数软件网站的管理员都不是开发人员出身，对源代码不感兴趣，所以收藏的都是212 KB的EXE，有源代码的不多，需要仔细找一下。
在unwebcompiler的源代码里，RMH和Fbilo对Web Compiler 1.67生成的电子书的文件格式进行了详细描述，在这里我就不做无聊的重复，有兴趣就自己去看吧。我做的UnEBook也使用了他们提供的源代码，实现对Web Compiler 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:\\com_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代码进行解析后，并不是立刻就把这些HTML代码抛弃，而是在内存里保存了一份备份。因此只要将这份备份从IE内核里搞出来，就得到了解码后的内容，也就是反编译想得到的内容。
至于网页中的其它内容，包括图片、css、js、Flash文件等，就更简单了：模拟IE内核，直接找电子书要就好。如果电子书分辨不出请求是来自IE内核还是来自其它地方，自然会乖乖把我们需要的东西双手奉上！
虽然反编译的原理几句话就可以说清，但是要加以实现，还需要经过艰苦的探索和试验，我自己就经过了长期的努力，IE内核的源代码都翻来覆去看了好几遍（吹的，别当真！）。而我思想的发展也大概经历了两个阶段：第一个阶段是在得到某份传说中的源代码（没错，就是那份展开后近700MB，被国内主流媒体形容为噱头、无足轻重、充满无聊垃圾的东西）之前，完全立足于微软公开的IE内核接口。当时我考虑将电子书内容按照HTML、图像等分类，分别解决获取问题。第二个阶段是在得到那份源代码之后，我突然发现其实对于所有文件，我都可以直接找电子书要，只要假装是IE内核在要就行了。
上一篇:磁盘坏道修复
下一篇:10种常见计算机无法启动故障解决方法
|
| 相关文章： |
|
|
|
| 相关软件： |
|
|
|
|
