按键盘上方向键 ← 或 → 可快速上下翻页,按键盘上的 Enter 键可回到本书目录页,按键盘上方向键 ↑ 可回到本页顶部!
————未阅读完?加入书签已便下次继续阅读!
心烦,因此最终放弃了这份代码。
现在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代码进行解析后,并不是立刻就把这些HTML代码抛弃,而是在内存里保存了一份备份。因此只要将这份备份从IE内核里搞出来,就得到了解码后的内容,也就是反编译想得到的内容。
至于网页中的其它内容,包括图片、css、js、Flash文件等,就更简单了:模拟IE内核,直接找电子书要就好。如果电子书分辨不出请求是来自IE内核还是来自其它地方,自然会乖乖把我们需要的东西双手奉上!
虽然反编译的原理几句话就可以说清,但是要加以实现,还需要经过艰苦的探索和试验,我自己就经过了长期的努力,IE内核的源代码都翻来覆去看了好几遍(吹的,别当真!)。而我思想的发展也大概经历了两个阶段:第一个阶段是在得到某份传说中的源代码(没错,就是那份展开后近700MB,被国内主流媒体形容为噱头、无足轻重、充满无聊垃圾的东西)之前,完全立足于微软公开的IE内核接口。当时我考虑将电子书内容按照HTML、图像等分类,分别解决获取问题。第二个阶段是在得到那份源代码之后,我突然发现其实对于所有文件,我都可以直接找电子书要,只要假装是IE内核在要就行了。
由于某些东西比较敏感,因此下面叙述的主要是我第一个阶段的想法,其中有些属于基础性的东西。第二个阶段的实现恕我不便奉告。
2、获取HTML源代码的方法
从IE内核获取HTML源代码的方法不仅我一个人在想,从国内到国外,从CSDN(CSDN的VC/MFC区有一个栏目专门讨论IE内核编程)到MSDN,早就有很多人讨论过了,归纳起来,一般认为可以通过下列步骤实现:
不管是通过鼠标点击也好,通过EnumChildWindow也好,总之先找到IE内核的显示窗口,也就是电子书显示网页内容的那个窗口。
通过这个窗口的句柄(HWND),取得这个窗口对应的IE内核文档接口IHTMLDocument2的接口指针。取得的方法目前认为有两种,我个人认为这两种需要结合使用,否则总有一些电子书会搞不定:一个是通过MSAA,一个是通过WM_HTML_GETOBJECT消息。至于具体的实现代码,在CSDN上都快被讨论烂了,因此此处从略,有需要的自己到CSDN上找。不过这两种方法都对平台有要求:XP下是完全没有问题,2000下可能需要装IE 6,98/Me/NT就不要想了。
在得到IHTMLDocument2接口指针后,按照这个接口提供的标准方法,即可获得文档的HTML代码。具体实现代码见CSDN中的例子。
除了上面这种方法外,我自己还尝试过一种方法:使用MIME Filter。
对于搞过网页在线翻译、网页内容过滤的人来说,MIME Filter可是吃饭的本钱,它的作用和实现机理应该早就烂熟于心,但是对于其它人来说,可能还不是很熟,