电子书制作及其反编译

来源:百度文库 编辑:神马文学网 时间:2024/03/29 17:50:43
2008年12月21日16:55来源:360doc平白
一、EXE输出格式类制作工具
目前比较流行也是被许多人青睐的一种电子读物档案格式。这种格式的相关制作工具也是最多的。它最大的特点就是阅读方便、制作简单且制作出来的电子读物相当精美而且无需专门的阅读器支援就可以阅读。这种格式的电子读物对执行环境并无很高的要求。但是这种格式的电子图书也有一些不足之处,如多数相关制作软件制作出来的EXE档都不支援Flash和Java及常见的音频视频档,需要IE浏览器支援等。常见EXE输出格式类制作工具:
1、ActivE-BookCompiler4.22
软件大小:2.14MB
软件类型:共享软件
公司网站:http://www.ebookcompiler.com
执行平台:Windows9X/NT/2000
下载地址:http://www.answers2000.freeserve.co.uk/422/aeb422a.exe
软件简介:该软件是同类产品中比较出色的一款。它支援基本的HTML元素、图片、音频、表格、框架、CSS、javascript、Add-Ins等。软件的操作介面从左到右共分为9个选择标签,即电子图书资讯、加密、过期、安装、开始执行资讯、用户介面、输入档案资讯、Add-Ins和输出档案资讯,所有选项一目了然,为我们提供了强大的编辑功能并且使用起来也十分的方便。另外,该软件对中文的支援也很好。
注意事项:在操作过程中,如果需要修改某一项的属性值,选中那一项并双击滑鼠,软件会自动弹出该选项相应的编辑视窗,修改完毕后软件会自动纪录您的操作。由于该软件的未注册版本对使用者的操作做了很大程度上的限制,强烈建议您注册该产品。
2、ePublisherGold1.5
软件大小:559KB
软件类型:共享软件
公司网站:http://www.inzonesoftware.com
执行平台:Windows9X/NT/2000
下载地址:http://www.inzonesoftware.com/epublish.zip
软件简介:该软件是使用向导的方式引导用户制作出版电子图书。软件支援基本HTML元素、CSS、javascript等相关技术。软件要求制作者和读者的电脑上安装有IE4.0或以上版本。软件除基本功能以外还具有以下特色:可以加入作者版权资讯;支援自己编写电子图书资讯(即"关于"对话方块);可以对全部档案或者单个档案进行存取许可权限制;软件制作的EXE档压缩率高于同类产品,这也是软件的一个优点。
制作步骤:单击Next按钮略过欢迎面板,加入制作者、网址和版本资讯。接下来的页面中我们需要加入待组建的档案(注意最好将图片档和页面档放置在同一个目录下面)。然后设置执行时出现的图片、起始页面、首页、关于对话方块文本等,可以对页面进行保护,可以是单个页面也可以是多个页面。最后一步就可以组建输出EXE档了。
3、E-BookHTMLCompilerPro2.12
软件大小:1.62MB
软件类型:共享软件
公司网站:http://www.bigwig.net
执行平台:Windows9X/NT/2000
下载地址:http://www.win2000.com.cn/down/ebook.zip
软件简介:该软件提供了最基本的制作选项,软件的操作介面如图所示。软件支援最基本的HTML元素,如框架、图片、表格等,支援使用48*36图元的动态图片作为产品的标识。但不可以直接换掉EXE档案图示,不支援CSS、javascript等技术。与其他软件不同的是,该软件可以按照用户显示器的解析度来随意调整执行的默认视窗大小。另外软件还支援点击音效,并且在安装档中有一个名为E-BookCompilerEncryption的工具,可以使用该工具来对档案进行加密。在E-BookHTMLCompilerPro+版本中,软件还给我们提供了设置产品存取权的面板。软件的使用方法与其他软件类似。在使用该软件的过程中要注意以下两点:1.单击打开档案以后,您选择的目录下面的所有档案将会被加入到档案列表框中。但是请您注意,如果您制作完一个产品之后,请务必将档案列表清空!否则下一次软件还会将上一次的档案捆绑到当前的EXE档案当中。2.软件在组建HTML档以前,要求用户输入EXE档执行的起始页面,否则将会提示找不到页面,请注意一定要保证档案名的尾码也一定要正确。
4、HTML2EXE2.2
软件大小:1.28MB
软件类型:共享软件
公司网站:http://www.html2exe.com
执行平台:Windows9X/NT/2000
下载地址:http://www.html2exe.com/dl/h2e22d.zip
软件简介:该软件支援常见HTML基本元素,包括表格、表单、图片、背景音乐等,但不支援Java、javascript、CSS等相关技术。软件的操作介面很美观并采用了IE风格的浮动图片变色按钮。虽然软件的操作比较简单,但是软件在作品的版权保护方面还需加强。另外,我们可以指定当前默认的HTML编辑器对页面进行编辑。但是需要向大家说明一点:不要使用中文作为组建的档案和资料夹名。软件提供给我们两种储存格式:EXE和H2E。如果储存成后者,则只能使用该软件的Viewer进行存取。在读者的电脑没有安装浏览器的情况下,这种方式便显得十分有用了。软件还会对输出的档案进行LZH压缩,而且还可以更换成品的标识(bmp或ico格式)。
5、InfoCourier1.38(该软件不再更新)
软件大小:617KB
软件类型:共享软件
公司网站:http://www.smartcode.com
执行平台:Windows9X
下载地址:ftp://ftp.smartcode.com/icour.zip
软件简介:该软件与Webcompiler2000都是一个公司的产品。但是由于InfoCourier是一个16位元的软件,所以它不能正常工作在WindowsNT或Windows2000下。软件的操作介面十分简单。组建档案时提供的选项很少,只能设置常用的工具是否可用、视窗状态、过期时间等。另外,软件只支援基本的HTML标识,不支援框架、CSS、动态GIF图片、javascript等。要说明一点,由于在InfoCourier中浏览的页面效果和IE以及Netscape稍有不同,所以请在组建前仔细检查每一个页面以保证读者看到相同的效果。
6、MediaPacker2.0
软件大小:1.93MB
软件类型:共享软件
公司网站:http://www.microdream.com
执行平台:Windows9X/NT/2000
下载地址:http://www.newhua.com.cn/down/mediapacker20.zip
软件简介:该软件组建生成的档案介面与其他软件风格不同,翻页、列印、关闭等按钮均在视窗的右上方并且阅读介面近乎全萤幕。软件要求读者的电脑上安装有IE4.0或以上版本。该软件支援图片、表格、框架、CSS等HTML基本元素。软件以向导的方式一步一步引导用户制作电子读物。整个制作过程明朗、简单,提供了相当多的选项给用户来设置最后EXE档的格式。而且对电子读物的安全性和版权等相关问题都作了相当多的考虑。另外值得一提的是,软件安装后带有一个提供给用户的KeyGenerator,这个工具是用来设置出版的电子读物的使用权限的。它较好的保护了作者和出版商的利益。这也是该软件最有特点的地方。
注意事项:在汇入组建出版档的时候,由于软件不能自动搜寻放置在其他目录下的档案,请注意把图片等与页面相关的档案和页面档案放置于同一目录下,否则将会出现组建后的EXE档无法显示图片等相关档案的现象。
7、WebExe1.4
软件大小:1.6MB
软件类型:共享软件
公司网站:http://www.aw-soft.com
执行平台:Windows9X/NT/2000
下载地址:http://www.aw-soft.com/wexsetup.exe
软件简介:该软件是专门用来制作HTML档转化成EXE档的。软件的优点在于它使用了智慧的向导来引导使用者一步一步完成整个制作过程。所以,我们不用担心制作的时候忘记什么,按照软件提供的向导我们可以轻松制作出精美的电子图书来。另外,软件的操作介面简洁、明瞭,使用起来很方便。但是不足之处是,软件不支援Java,javascript、DHTML、Flash等技术,不可以直接换掉输出档的图示,必须借助于相关的工具来制作。该软件到目前为止还没有Linux以及Mac版本。
8、WebCompiler20001.5
软件大小:2138KB
软件类型:共享软件
公司网站:http://www.webcompiler.com
执行平台:Windows9X/NT/2000
下载地址:ftp://ftp.webcompiler.com/wc2k.zip
软件简介:该软件是德国WebCompiler公司出品的用于将多个HTML页面(包括图像档)组建成可执行性档案的软件,目前是同类产品中比较出色的一款软件。其最大的特点就是软件本身相当于一个小型的Web浏览器,对原来的HTML档不会产生任何的损伤。软件支援CSS,javascript等常见Web技术。但是不支援Java和Flash,而软件对是否支援Plugin和ActivX的回答是"也许\",因为这要看Plugin和ActivX的安全程度等相关问题。另外,WebCompiler2000不支援ActiveServerPages。软件需要制作者的电脑上面装有IE4.0或以上版本,并且该软件没有Unix,Mac版本,也没有基于Natscape浏览器的版本。但是软件由于是32Bit,所以基于微软Windows平台的作业系统均可以执行。
注意事项:在制作的过程中,请不要使用中文名作为需要组建的档案或者资料夹名称,否则软件将会弹出视窗提示找不到页面的资讯。另外,您可以制作自己的标识和图示来作为您作品的标志。但是您必须拥有注册版的Webcompiler2000。
9、WebCompiler981.14汉化版
软件大小:356KB
软件类型:免费软件
作者网站:http://lytes.home.chinaren.com
执行平台:Windows9X/NT/2000
下载地址:http://www.guxiang.com/epubcn/so ... er.exe
软件简介:WebCompiler98是WebCompiler2000的前身,具有WebCompiler2000的几乎所有功能。由于该汉化版本非常成功,几乎所有的地方都作了详细的汉化,所以现在很多朋友都在使用该软件。但是由于该汉化版是在解密WebCompiler98的基础之上才汉化的,所以软件目前还具有某些缺憾:即作品的标志和图示不可以换。
10、EbookBuilder4.0
软件大小:615KB
软件类型:免费软件
作者网站:http://members.xoom.com/JanVee/freeware.htm
执行平台:Windows9X/NT/2000
下载地址:http://www.newhua.com.cn/down/ebookbuilder4.zip
软件简介:该软件最大的特点就是它的拖拽操作,即当我们打开一个目录时,软件将会将目录中的所有档案显示在档案列表中,我们可以从列表中选中一个或者多个档案通过拖拽的方法将档案加入待组建档案列表中。而我们可以在待组建档案列表中控制档案的排序和执行顺序。另外在制作过程中我们可以任意并且最好指定整个档案执行的开始和结尾。软件支援HTML基本元素以及CSS,但是不支援javascript、Java等技术。另外,软件在组建输出的EXE档执行过程中可以直接跳到指定的页面,这是很方便的一项功能。但是软件没有对组建档作任何的版权限制,所以这不利于作者以及出版商的权利和利益。软件以档案总管的样式设计。在左上角选择需要组建的档案所在路径,则选中的资料夹中的所有档案将会出现在左下方的档案列表当中。然后从这些档案中选择全部或者部分档案(可以多选),然后使用滑鼠将这些档案拖拽到右边的待组建档案列表当中即可。在最后组建输出以前,请读者最好加入整个档案执行的开始和结尾标识,即单击软件功能表Insert下的BookBegin和BookEnd来指明执行的开始和结尾之处。当然,我们需要将右边待组建的档案进行排序,否则很可能最后的执行顺序不对。另外,如果您首次执行组建后的EXE档,您会发现当前页面会以分屏的方式显示,选中功能表Options>SinglePage选项即可。
11、HyperMakerHTML2002.06
软件大小:2.5MB
软件类型:共享软件
公司网站:http://bersoft.com
执行平台:Windows9X/NT/2000
下载地址:http://bersoft.com/hmhtml/hypermaker.exeHyperMakerHTML2000软件简介:同类产品中支援档案格式和效果最多的软件,性能相当出色。该软件支援HTML3.0及以后版本大部分的识别字;支援Flash、Acrobat、AVI和MPEG;可以嵌入Word、PowerPoint、Zip格式的档案;支援动态标识的使用;使用HyperMakerViewer存取支援点击音效。值的一提的是,软件自身带有阅读器,虽然我们在输出档案以后不需要专门的阅读器就可以进行存取,但是软件自身的阅读器方便我们在制作过程当中察看页面的浏览效果是否符合要求。另外,该阅读器可以播放MIDI、WAV、MP3、AVI和MPG格式的音频视频档,可以存取PDF和Flash档案,可以存取Word、Excel等档案,这些特性都是同类产品所无法比拟的。所以通过上面可以看出,软件在同类产品中的确具备相当专业的水准。不足之处是,HyperMakerHTML2000软件的制作过程相对于其他软件来说较复杂,并且软件没有给我们提供向导功能,所以整个制作步骤需要我们手动完成。另外,软件不支援CSS,输出档案的大小在同样的条件下比别的要大一些。
12、WebPaker1.29
软件大小:1.26MB
软件类型:共享软件
公司网站:http://bersoft.com
执行平台:Windows9X/NT/2000
下载地址:http://bersoft.com/webpacker/webpacker.exe
软件简介:该软件与HyperMakerHTML2000是同一个公司的产品。从操作介面上来看,该软件更像是HyperMakerHTML2000的简化版本。软件依然保持了HyperMaker的操作风格,并且支援基本HTML元素、CSS、Flash、javascript、Java、AVI、各种音频档等等。所以,该软件也是同类产品当中支援的档案格式比较多的一款。与HyperMaker相比,该软件去掉了Interface、Options、External、Setup、Viewer五个选项标签,而把Interface和Options两个标签合为一个名为MainOptions的选项标签。另外,软件不像HyperMaker那样,需要先生成Publication档然后才能生成EXE档,软件可以直接将所有档案组建输出成EXE档。另外建议读者注册该软件,否则组建的EXE档只能存活7天,并且软件的某些功能不可以使用。
13、WinEBookCompiler2.3
软件大小:2.42MB
软件类型:共享软件
公司网站:http://superwin.com
执行平台:Windows9X/NT/2000
下载地址:http://regvac.com/wnebookc.exe
软件简介:SWB档案格式是该软件专有的档案格式。这种格式的档案需要WinEbookCompilerViewer来阅读。软件支援TXT、RTF两种档案格式,而且软件可以对页面进行编辑,如插入图片、超连结等。值得一提的是,软件支援播放背景音乐。这是一个非常好的功能,读者可以设想边看书边听音乐的感觉,而且可以根据书中不同的情节设置不同的音乐。软件的其他显著的特性:档案的页面切换效果独一无二,翻页的时候,下一页会从萤幕右方"滚动"出来并带有音效,还可以控制翻页速度;支援人声朗读文本,但目前还不支援中文朗读;无需返回目录即可通向任意页面(通过下拉功能表实现);支援放大缩小文本;支援档案加密功能。由此可以看出,软件具备其他很多软件没有的优点,但是由于所支援的档案格式只限于TXT和RTF,所以很多目前基于Web的技术都不能够实现。另外对软件的局限提出以下三点,希望读者注意:1.不可以超过100个Chapter;2.每一个Chapter的大小最好不要超过312KB,否则打开时将会等待很长时间;3.最好不要打开超过5个阅读视窗,否则将会出现某些问题。
14、NeoBook4.0.9
软件大小:3.8MB
软件类型:共享软件(30天使用限制)
公司网站:http://www.neosoftware.com
执行平台:Windows9X/NT/2000
下载地址:http://www.neosoftware.com/software/nbw40.exe
软件简介:该软件是同类产品中比较"另类"的一款。我们习惯于将多个Web页面以及图片等其他档案汇入软件中,然后通过编辑直接输出EXE档。但是该软件完全不是这样。可以这样说,制作一本电子图书的所有过程需要作者手动完成,包括文字编辑、图片音频档案的插入、颜色的搭配、文字图片定位,甚至翻页按钮都得由作者来制作。所以,该软件的优点在于制作电子图书从始至终完全由作者一手来完成,而我们完全不可以将已经编辑好的HTML档插入到软件中,否则只会出现HTML档的源代码。软件默认识别的档案格式是TXT。另外,软件带有一个浮动的编辑面板,可以帮助作者编辑文字、插入图片、制作按钮等等。当然,用户也可以自己来指定编辑各种格式的档案的编辑器。汇出的EXE档在执行的时候将以全萤幕的方式来显示。软件还有一个显著的特点,那就是允许用户自己编写Action。例如,如果你想实现翻页按钮的功能,那么你必须加入例如GotoPrevPage这样的Action。在页面切换的时候也可以加入相应的Action。软件在编辑使用的灵活度上给我们留下了极大的余地,而且我们可以根据自己的喜好创建很多动态的效果。但是软件抛开了传统的插入HTML档汇出EXE档的模式,这对于初学者来说不是很好的一件事情。
15、EasyBook2.5
软件大小:1.34MB
软件类型:共享软件(30次使用限制)
公司网站:http://www.easyteach.com
执行平台:Windows9X/NT/2000
下载地址:http://www.easyteach.com/download/ezbook1.exe
软件简介:该软件只能汇入TXT、RTF和EZF格式的档案,不支援使用图片等其他与Web相关的元素。就是说,它只能将纯文本形式的档案组建成EXE档。软件的易用性做的不是很好,而且选项比较复杂而且层层嵌套,对初学者来说不是一个最好的选择。软件需要先建立一个工程档,然后在此工程档的基础之上一篇一篇地加入文本,最后将所有文本组建成EXE档。软件每一步的设计几乎都可以预览当前编辑的状态。这里要说明一点,如果您使用的是非注册版本,那么将会有30次使用限制,而且不可以输出EXE档。所以建议您注册该软件。
16、BoxBuilder
软件大小:476KB
软件类型:免费软件(需要执行密码)
执行平台:Windows9X/NT/2000
下载地址:http://download2.ccidnet.com/school0622/boxbuilder.zip
软件简介:该软件是我见过的同类软件当中最简单的一个。我没有抓取该软件的介面图是因为根本没有必要抓。执行软件以后(如果是首次执行,软件将会提示输入密码,这个密码在软件的打包档中有),视窗上面只有三个按钮:SelectSourceFiles(选择原始档案)、CreateTarget(创建目标)、Help(帮助文档)。软件几乎不支援所有的Web技术,而且你需要将图片档放置在和html档相同的目录下面,否则软件是不会自动找到图片的正确位置的。软件的操作步骤极其简单(两步):选择html档(多选);输出成exe档。软件无任何输出档设置选项,没有防止拷贝等相关的保护措施,就连最后输出的exe档的工具列也只有一个---Home按钮。根据以上我们可以看出,如果你想偷懒的话,这个软件是再适合不过了,两步就搞定!
常见电子书格式及其反编译思路
作者:马健
主页:http://stronghorse.yeah.net
电邮:stronghorse@tom.com
版本:1.00
日期:2004.05.30
声明:
本文可能夹杂大量技术术语,如果您对此感到不快,请勿继续阅读。
本文仅仅讨论一些思路,不会提供相关源代码,最多也只提供源代码网站的链接。如果您对此有所不满,请勿继续阅读。
本文仅仅从技术角度讨论电子书反编译问题,请勿将之用于侵犯版权等等非法目的,或损害他人利益。如果您对此感到失望,请勿继续阅读。
本文版权归作者所有,转载前请先征得作者书面同意。
1. 前言
2. 常见电子书格式及其反编译思路
2.1 PDF格式
2.2 基于IE内核的电子书
2.2.1 CHM格式
2.2.2 EXE格式
2.2.2.1 Web Compiler 1.67
2.2.2.2 Caislabs eBook Pack Express 1.6
2.2.2.3 通用反编译思路
2.3 HLP格式
2.4 小说网/小说世界(ebx/XReader)
3. 结论
附录 基于IE内核电子书的实现方式探讨
1. 前言
本文所描述的电子书,指的是将原始的、可编辑的HTML、TXT、RTF、图像文件等,打包成一个独立的EXE,或其它只有专用浏览器才能读取的文件,打包后的文件通常不可用常规工具进行编辑、全文检索。
本文所描述的电子书反编译,指的是将电子书中的内容提取出来,还原或转换成标准的、可编辑的HTML、TXT、RTF及图像文件等。
就像世间其它事物一样,电子书编译器和反编译器的出现也都不是偶然的,都有其必然性。
在电子书编译器这一方来说,大概从有电子文档那天开始,就有人琢磨着要对电子文档打包了。我个人认为这主要是从以下几个方面进行考虑:
便于阅读、管理。当年在DOS下阅读文本文件,尤其是中文文件比较麻烦,因此出现了自带中文字库、自带基本浏览(翻页、滚动)功能的DOS电子书;由于需要在不同OS平台上获得相同的阅读效果,因此产生了跨平台的PDF格式电子书;随着互联网络的发展,大量信息以HTML格式出现,但是面对一大堆HTML文件,并不是每个人都知道该去双击index.htm或default.htm的,而且文件太多,管理也成问题,因此出现了CHM格式和各种基于IE内核的EXE格式电子书。
便于保护知识产权、商业机密。这个问题的重要性相信大家现在都能理解了,不要说那些包含核心商业机密的东西,就算是区区一本小说,都会有些卑鄙小人把原始的HTML、TXT文件拿去加LOGO、打包,然后声称是自己“辛苦扫校的成果”,再堂而皇之地收取所谓“VIP费用”。因此PDF一直将文档安全性作为卖点之一,国内的各种独门格式电子书也以防反编译、防内容复制为首要目标。
而反对将通用格式打包成独门格式的人,当然也有自己的道理:
便于全文检索。如前所述,电子书一般不可用通常的检索工具进行全文检索,这就为资料的有效利用设置了障碍。我个人认为,藏书量在几十本、上百本的时候,手工建立摘要、索引可能还可以接受;再多以后,我想要的就只是一个快速的全文检索工具,就好像在互联网环境下,对google的依赖一样。
便于修改。俗话说:“金无足赤,人无完人”,电子书也是人做的,有时难免会出点什么错,或者因为资讯的发展,需要对原有内容加以修正、补充,这个时候如果面对的是一个不可编辑的EXE,您会有什么感想?
节省时间和耐心。Windows在显示文件列表的时候,需要读取文件信息,EXE文件还要读取ICON等,如果装有反病毒软件,进入文件夹的时候,反病毒软件一般还会自动对文件夹中的EXE文件进行自动检查,而电子书大小一般都在MB级,因此打开包含EXE格式电子书的时候,感觉速度巨慢,比较令人反感。
节省空间。一般EXE格式电子书的标准架构是:可执行体+内容+TOC。可执行体指的是电子书的执行代码部分,包括程序代码、插件代码、界面资源等。内容指的是电子书中真正包含的文本、图像内容,一般使用某种压缩、加密算法进行处理。TOC(Table Of Content)相当于目录索引,作用是加速对内容的访问。因此相对于直接用WinZip、WinRAR对原始内容进行压缩,每一本EXE格式的电子书都会浪费一部分磁盘空间,以存储执行体部分。电子书的软件界面越花哨,这种浪费一般也越大,我见过最夸张的电子书比原始内容足足多出 1 MB多的东西。
避免垃圾。对于某些基于IE内核的电子书来说,由于实现技术的限制,可能会在注册表和系统目录下留下垃圾。
安全。如果说如今的网络社会是一个充满恶意、毫无诚信的环境,可能有点夸张了,不过确实有人不知“做人要厚道”为何物。老实说,每次拿到一个来路不明的EXE格式的电子书的时候,我都在怀疑里面有没有什么木马、病毒,实在难受。
便于平台转换,包括转换到手持设备。EXE格式的电子书看起来可能很爽,但是毕竟只能在Windows下看,如果想在其它系统下看,尤其是在手持设备上看,唯一的出路就是反编译了它。
当然,在反编译后,也必须寻找合适的替代品,以继续满足原先的需要:
打包工具。建议选择Winzip或WinRAR,不仅使用方便,而且打包后文件也小,进入目录还快。
阅读工具。现在可以不解包就直接阅读zip/rar文件内容的软件不少,一搜一大把,我自己都做过一个MyReader,不仅可以直接从ZIP/RAR中读取内容,还有自动定位index.htm、书签、现场保护、资源浏览器右键菜单扩展、zip/rar密码自动记忆等功能。
全文检索工具。可以直接在zip/rar中全文检索的软件也有不少,我自己也做过一个FindStr,支持加密zip/rar,这个工具还可以与MyReader集成,搜索结果可以直接用MyReader直接打开,不需解包。另外它还支持批量文本替换,所以也经常被我用来整理下载到的或反编译出来的小说,包括去除广告链接、绝对URL改成相对URL等。
对劳动成果的保护。这个直接用zip/rar的密码保护就好。
2. 常见电子书格式及其反编译思路
2.1 PDF格式
PDF格式是Adobe公司推出的一种跨平台电子文档格式,Adobe公司提供专用的文档浏览器,使用户可以在不同平台下获得相同的阅读效果。
其实Adobe公司提供的PDF编辑工具--Adobe Acrobat本身,就已经支持将PDF文件另存为RTF格式,因此我对PDF的反编译研究不多。不过这个功能似乎受到“文档安全性”的限制,好在我google了一下,破解PDF安全保护的软件似乎不少。如果真的对批量转换有兴趣,在codeproject上也有一篇文章,提供将PDF转换成纯文本的源代码。
从我使用的情况看,Adobe Acrobat本身输出的RTF格式,对英文文档来说应该没有什么太大的问题,顶多是格式有点变化,但是在输出中文文档的时候,偶尔会因为字符集代码错误,导致输出的文件在Word、写字板中打开的时候,只能看到一堆乱码。对于这种情况,手工替换一下字符集编码即可解决。
出现乱码还有一种可能就是PDF文件中使用了自定义的字库,导致转换出来后的文件无法正常显示,这个比较麻烦。PDF文件自带字库有两种方式:自带一种完整的字库,称为font embedding;只自带一种字库中要用到的那几个字符,称为font subsetting。在e类出版物论坛的“图书制作、阅读工具区”对此有过讨论,需要的可以自己去看。
不过有一次我试着用过一个叫PDF2Html的软件,这个软件的思想是将PDF文件的每一页转换成一个JPG文件,然后将JPG文件封装到HTML文件里,加上目录、翻页按钮等,这样在网络浏览的时候,连客户端的Acrobat Reader及客户端字体支持都可以省了。这个软件的HTML文件模板做得怎样先不去说它,最令我奇怪的是,转换出来的图像格式只能是JPG,不能是PNG。其实对于有大片白色背景的页面来说,使用PNG格式不仅文件长度比JPG小,而且不会象JPG格式一样,在文字、图像边缘产生许多细小的碎片(高次杂波)。
2.2 基于IE内核的电子书
随着互联网的发展,现在越来越多的网络文档内容是以HTML格式提供的,而微软本身又以控件的形式提供了IE浏览器的内核,可以很方便地被几乎所有Windows下的编程工具所调用,因此目前基于IE内核的电子书似乎占据了主流位置。
2.2.1 CHM格式
CHM(发音为“chum”)的原意是Compiled HTML help file,是微软作为HLP格式(16位Windows下的标准帮助文件格式)的替代格式提出的,因此微软自己不仅随4.01以上版本的IE一起提供免费的浏览器,而且免费提供制作工具Microsoft HTML Help Workshop。
CHM文件内部使用ITS格式,这是一种非常优秀的压缩格式,感觉压缩比要比zip、rar大。
由于ITS格式的开放性,国外早就有人做出了CHM格式的独立编译、反编译工具,并且公开了全部源代码,需要的人可以到这里看:
http://bonedaddy.net/pabs3/hhm/
这个网站除了提供CHM编译、反编译工具及其源代码外,还提供CHM格式的详细说明,当然是英文的。我做的UnEBook在开始的时候,就使用了其中chmdeco的源代码,实现批量反编译CHM的功能。如果这个网站不幸登录不了,google一下chmdeco就好,有很多备份站点的。chmdeco内部使用的是chmlib的源代码,这份源代码很有名,除chmdeco外,chmtools用的也是它。
不过在使用了一段时间后,我发现这份代码在反编译某些CHM文件的时候,会出现数组越界错误。这种错误出现的概率虽然不大,但是出现后还是比较心烦,因此最终放弃了这份代码。
现在UnEBook使用的CHM反编译代码是从这里改出来的:
http://www.codeproject.com/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 Compiler 1.67
    这种格式的电子书,因为其制作工具在国内出现得比较早,而且有非常彻底的汉化解密版,所以曾经比较流行,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内核在要就行了。
    由于某些东西比较敏感,因此下面叙述的主要是我第一个阶段的想法,其中有些属于基础性的东西。第二个阶段的实现恕我不便奉告。
    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可是吃饭的本钱,它的作用和实现机理应该早就烂熟于心,但是对于其它人来说,可能还不是很熟,所以这里简单介绍一下:为了便于对IE内核的功能进行扩展,微软规定在IE内核显示某种标准格式(HTML、TEXT等)的内容之前,会先将要显示的内容传递给这种格式的过滤器,即MIME Filter,由它先对内容进行预处理(如将英文翻译成中文,将下流文字替换成星号等),然后再显示。
    按照这个原理,如果实现一个针对HTML格式的MIME Filter,即可拦截到最原汁原味的HTML代码。可惜,经过我的尝试,这招对IE本身是灵的,对某些电子书也有效,但是对另一些无效。再加上使用IHTMLDocument2接口指针的方法要比这种方法简单得多,也可靠得多,所以后来在我开发的反编译工具KillEBook、IECracker和CtrlN里就没有使用这种方法。不过这种方法也有一个好处:与平台无关,我在98/Me/2000/XP下都试过,当然都是在虚拟机下试的啦。
    MIME Filter的作用机理、实现方法在MSDN里有详细说明,并提供了详细的实例代码,有需要的可以到MSDN上搜“MIME Filter”。
    3、获取图像的方法
    与HTML代码相似,IE内核对图像的处理也有一个“下载->解码->显示”的过程。考虑到显示代码的抽象性,原来各种各样的图像格式,包括JPG、GIF、PNG、TIFF等,在解码后都被统一表示成位图格式,而原有格式数据在解码后即被从内存中释放,只在IE的cache中留有文件备份。如果指定不允许保存本地cache,则连这个备份都没有。在IE中通过右键菜单选“图片另存为...”的时候,其实就是将cache中的文件备份拷贝一份出来,如果cache中已经没有备份,就只能保存内存中的位图(*.bmp)了。现在明白为什么有些图片明明是jpg格式,但是用IE却只能保存为“无标题.bmp”了吧?
    因此,获取图像文件要比获取HTML文件难得多。而且在MSDN里说得很清楚,用IHTMLDocument2接口只能得到图像的链接,用MIME Filter也不能搞到网页里的图像数据,因此需要另想办法。我想过、试过的包括:
    先将图像复制到剪贴板,再从剪贴板里获取图像数据,然后根据图像文件扩展名(可以从图像元素的URL里解析),编码成原始图像格式,包括jpg、png、gif、tiff等。这个方法实现比较简单,到MSDN KB里搜索Q293125,拷贝图像到剪贴板的现成源代码就有了,图像编码的源代码则可以参考cximage,这个也是google一下就有的。不过这个方法远非完美无缺:a). 对于png、gif等允许带透明背景的格式,用这种方法处理后就不透明了。b). gif动画处理后就动不起来了,只能显示其中的某一帧。c). 对于jpg这样的有损压缩格式来说,每压缩一次就损失一次,多压缩几次可能就没法看了。d). 在电子书里,可以通过标准的Windows API函数,使剪贴板失效。
    将IE内核导航到图片,然后通过IViewObject接口获取图片的拷贝。这个方法与上面的方法基本相同,不过不通过剪贴板,可以防止因为剪贴板被封锁而搞不到图像。
    使用IE图像解码插件。IE内核在下载到某种格式的图像文件后,会调用对应的解码器,对图像进行解码(类似于MIME Filter)。为了便于扩充,解码器是做成插件形式的。如果自己做一个图像解码器插件,对解码请求进行拦截,即可获得解码前的原始图像格式数据。解码器的接口、实现方法在微软公开文档中没有任何蛛丝马迹,但是在那份传说中的源代码里,不仅有详细的接口规范,而且有好几个内嵌图像解码器的实现代码,可供借鉴。奇怪的是,虽然在MSDN中找不到,但是我在google上搜的时候,却发现有一个日本人在自己的个人网站上,早就给出了详细的图像解码器插件实现方法,一步一步说得很清楚,而且落款时间是2002年12月!看来这份源代码的泄漏时间可能比想象的要早。当然这个日本人也可能本来就在微软工作,或与微软有合作关系,可以光明正大地查看解码器源代码也说不定。
    4、通用反编译器的实现
    在解决了HTML、页面元素等的获取方法后,通用反编译器KillEBook的实现就很简单了,其算法可以描述如下:
    打开电子书。
    定位电子书的显示窗口。
    获取当前显示页面的HTML代码。
    解析页面HTML代码,得到其中的所有链接。
    获取页面上的所有元素内容,包括图片等。
    引导IE内核依次加载HTML链接页面。
    重复步骤3~6,直到所有页面及其中的元素都已获取到。
    5、进一步讨论
    在完成KillEBook后,我发现其实对它扩展一下,就可以成为一种新的离线浏览器,解决传统离线浏览器(Offline Explorer Pro、Webzip等)面临的一个问题:传统离线浏览器多半与IE内核没什么瓜葛,因此在抓静态网页的时候都没有什么问题,但是在抓用session维持的动态网页时,都有点问题,更不用说抓需要PKI证书验证的HTTPS网站。
    因此我考虑可以实现这样一个离线浏览器:
    提供一个地址栏供用户输入起始URL。
    内嵌一个微软web browser控件(IE内核),供用户交互,包括在网页上输入用户名/密码、从IE证书库中选择证书。
    用户登录成功、进入需要开始抓取的网页后,设定递归深度、URL过滤条件,点“开始”按钮开始抓取。
    离线浏览器自动引导web browser进入每个页面,每进入一个页面,都通过web browser控件获取客户端HTML源代码及页面元素,包括图片、css、js、flash等。
    采用这种方法实现的离线浏览器,由于使用web browser控件,因此可以维持客户端session,抓取到动态网页。虽然网页抓取下来就成了静态的,但是对离线浏览来说应该不成问题,对付收费的网上教育等网站正好合适。
    2.3 HLP格式
    这种格式出现得比较早,在16位Windows(Windows 95以前的各Windows版本)下曾是标准的帮助文件格式,因此大概也算是Windows下出现得最早的电子书格式之一了。
    由于这种格式比较流行,国外研究的也比较多,不过公开源代码的我似乎只见过一个HELPDECO v2.1。这个软件是一个控制台程序,因此有人做了一个GUI外壳DuffOS对它进行封装。国内有人对HELPDECO进行过汉化,到汉化新世纪搜索一下就可以找到,包括全部源代码。
    在UnEBook中使用了HELPDECO的源代码,实现对HLP文件的批量反编译。不过从我使用的情况看,原版HELPDECO有一个小小的不足:反编译出来的RTF文件没有指定字符集。这对英文RTF来说没有任何影响,但是对中文RTF来说,其影响足够强到使您打开RTF后看到的是一堆乱码。它的修正方法有两个:
    用文本编辑器打开反编译出来的RTF文件,手工指定中文字符集。这个是一种比较累的方法。
    修改HELPDECO源代码,加上字符集修正,这个是一劳永逸的办法。但是不知道为什么,在汉化新世纪推出的汉化版上,我看到的还是原版的HELPDECO。看来汉化者只是用它反编译过英文HLP,没有反编译过中文HLP。
    另外这份源代码还有一个不知道算不算是严重的问题:变量没有统一初始化、释放,因此不仅在程序退出的时候,VC++会报告有内存漏洞,而且就象当年的DOS内核一样,几乎没有可重入性。我曾经试图修复这个bug,但是在经过一个下午的奋斗后,有两处泄漏死活找不到。最后我还是决定向DuffOS学习:将HELPDECO代码封装成一个独立的DLL,每反编译一个HLP文件,都动态加载、释放一次DLL。这样一方面可以利用Windows本身的DLL管理机制,弥补HELPDECO产生的内存漏洞,一方面解决不可重入问题。收费的“耶书制造”软件提供的HLP反编译功能也是用DLL文件实现的,因此我严重怀疑它的作者可能也曾遇到过相同的烦恼,嘿嘿嘿……
    从HLP文件反编译出来的RTF文件,一般包含大量书签、分页符等与实际文本内容无关的东西,有必要转换成纯文本格式。这个实现倒是比较简单:
    创建一个Windows标准的RichEdit控件,当然没有必要在用户界面上显示出来。
    按SF_RTF格式,StreamIn原RTF文件内容。
    按SF_TEXT格式,StreamOut文本内容。
    UnEBook提供的从RTF到TXT的批量转换功能,就是按照上面的方法实现的。
    2.4 小说网/小说世界(ebx/XReader)
    这两家网站提供的电子书使用的是同一个阅读器,只不过小说网出现得比较早,提供的电子书多半不需要验证码,而小说世界出现得比较晚,提供的电子书多半需要输入验证码。
    这种电子书分两种:ebx和EXE格式。ebx格式的电子书需要用专用浏览器XReader才能浏览,EXE文件的内容其实就是XReader + ebx包构成。
    国内Cyu曾经推出过反编译这种EXE格式的工具--xReader Unpacker。从我试用的情况来看,这个工具的实现应该是基于对EXE文件格式的辛苦分析,果然勤劳善良的中国人什么时候都有啊!不过从我试用的结果看,这个工具也存在下列问题:
    一次只能反编译一个文件,不能批量反编译,使用起来略有不便。
    反编译出来的文件用左侧目录树中对应的节点命名,完全失去了文件的先后顺序。
    在反编译某些文件,如《血酬定律--中国历史中的生存游戏》的时候,会出错退出。我个人猜想可能是因为对书中多级目录处理不当。
    奇怪得很,只能对EXE文件进行反编译,不能对ebx文件反编译,其实这两种文件本是两位一体的。
    当然,我试用的只是最初版本的xReader Unpacker,后来听说作者又进行了更新,这些问题都解决了也说不定。
    在考虑反编译这种格式的电子书的时候,因为我已经在思考针对IE内核的通用反编译方法,因此从一开始我就没打算对文件格式进行分析,而是打算从界面元素入手,看看有没有什么后面可走:
    先用IECracker抓一下窗口,发现根本就不是基于IE内核的东西。这个时候首先想到的就是:软件作者会不会向起点中文网学习,将内容转换成图片,然后再显示?但是很快就否定了这个可能,一方面是因为XReader提供了文字放大、缩小功能,另一方面是因为启动金山词霸后,将光标往窗口上一放,词霸显示出了抓词内容。这个时候脑袋里一闪念间,也曾出现过一个反编译方案:干脆向金山词霸学习,做一个API hook,抓它的显示内容算了,哈哈……
    在确定XReader显示的东西不是图片后,我就启动SPY++,打算看看XReader的显示窗口用的是什么东西。但是查看的结果令人惊奇:每启动一次XReader,显示窗口的class name就会变化一次,是一个完全随机的字符串,从上面根本看不出这个窗口使用了什么控件。
    再多看几本电子书后,我发现所有电子书都有一个特点:完全没有图片,清一色都是纯文本,但是鼠标放到窗口上的时候,光标不会变成通常文本窗口的插入光标(一条竖线),还是箭头光标。到这个时候,我已经开始准备相信软件作者完全继承了国人勤劳善良的光荣传统,自己写了一个文本输出控件了。……且慢,为什么在打开这个大文件的时候光标会闪一下,从竖线变成箭头?再前后动动鼠标滚轮看看,每次不多不少,正好滚动3行,这个不是RichEdit控件的特性之一吗?!
    立刻启动SPY++,这次不看class name了,改看消息流。果然每次点击左侧目录树,都会向右侧显示窗口发送一堆RichEdit控件的消息:EM_SETBKGNDCOLOR(设置窗口背景色)、EM_SETCHARFORMAT(设置光标形状)、EM_SETMARGINS(设置左右页边距)、EM_STREAMIN(导入显示内容)。
    既然已经确定右侧显示区用的是一个标准的RichEdit控件,而左侧目录树是一个标准的TreeCtrl控件,那么反编译方案其实也就出来了:周游左侧目录树,依次选中每个节点,然后拦截右侧RichEdit控件的输出,写入文件即可。
    不过在搞清楚XReader的原理后,我也产生了一个疑问:RichEdit控件本身是可以同时显示文本、图片的(RTF格式),但是为什么XReader只显示纯文本,不显示图片呢?要知道这样可是会使做出来的电子书增色不少。开始我以为是为了保密,象我自己一开始不也差点误入歧途?如果不是偶然看到光标闪烁,再动动鼠标滚轮,可能我一时也想不起来他用的是标准RichEdit控件。后来在看到早期版本的XReader后,我想更大的可能是为了兼容:早期版本用WM_SETTEXT传递显示信息,只能显示纯文本,后来才改用EM_STREAMIN的。
    总结一下,XReader中采取了下列措施防拷贝、防反编译:
    随机更改RichEdit控件的class name,防止被人识破。
    对光标形状进行设置,一方面防止被人识破使用的是RichEdit,一方面避免用鼠标选择、复制内容。
    对WM_COPY、WM_GETTEXT、EM_STREAMOUT等等消息进行了过滤,因此直接从窗口获得文本内容就不要想了。
    可惜,微软提供的RichEdit控件是用于开放环境的,一旦被识破,用微软本身提供的接口就足以搞到所需的内容了。
    后来看到小说网早期放出来的EXE格式电子书,才发现XReader这个软件也是不断发展的,而版本升级的目的主要就是为了加强安全性,ebx格式本身却没有什么变化,一直很稳定,新的ebx文件也可以用老的XReader打开:
    早期版本的XReader支持用命令行参数的方式,传入需要打开的ebx文件路径,这样容易被人利用,实现文件自动打开。后来版本的XReader就只能通过菜单或工具条,点“打开电子书”才能打开文件。当然这个限制也不是不可以突破,不过毕竟没有用命令行参数传递这么方便。
    早期版本的XReader其实就使用WM_SETTEXT消息显示文本。如果早点看到这个版本的电子书,说不定我还可以少费点周折。后来版本改用EM_STREAMIN,估计一方面是为了保密,另一方面是为了速度和性能:在显示大文件的时候,EM_STREAMIN比WM_SETTEXT快得多;EM_STREAMIN可以显示RTF文件,而WM_SETTEXT只能显示文本文件;EM_STREAMIN可以显示大型文件,而WM_SETTEXT支持的文件长度是有限的。
    3. 结论
    就像信息安全中的攻与防一样,电子书的编译与反编译之间的斗争也将是一个永无止境的死循环。我相信不论电子书反编译技术如何发展,都不会导致电子书的绝迹,毕竟有实际的需要。但是本文的发表,毫无疑问将会刺激电子书制作软件和制作技术的新一轮升级。那么我的文章和软件会不会随之升级呢?我自己是没什么自信啦,毕竟我的自由时间越来越少,而如果没有其他人愿意象我这样研究反编译技术和软件(收费的免谈),我想最终胜利的一定是有商业利益支撑的电子书制作软件。
    先分析电子书的详细文件格式,再有针对性推出专用反编译器的方法,在初期确实是一个不错的方法,但是随着电子书格式的增多,如果每一种都要去分析一遍,早晚会累死。
    电子书制作软件其实也是人开发的,开发者当然也会有人类的通病——懒!只要有现成的东西可用,很少有人会再花力气去修练自己的独门功夫。而目前Windows下的东西,开放性的考虑要比安全性的考虑更多一些,如果能够找到这些东西的突破口,即可突破同一类使用这些东西的电子书。
    利用现成控件的接口或漏洞,实现通用电子书反编译,这其实也是程序员懒惰的一种体现。这种方法虽然比老老实实分析、跟踪电子书简单许多,但是也有其天然缺陷:只能反编译显示到控件中的内容。通俗一点说,如果电子书是加密码保护的,那么这种方法并不能在不知道密码的情况下,反编译出电子书的内容。
    附录 基于IE内核电子书的实现方式探讨
    电子书看多了,有时候我也会想,如果是我自己做一个电子书制作工具,我会采用什么样的技术加以实现?考虑到现在HTML格式文档的普遍性,在有人开放出新的HTML render之前,我的想法还是只能围绕IE内核打转。下面就是我想到的一些思路。
    1、基于res协议
    res协议是IE内核提供的一种非常简单的协议,允许将需要浏览的页面存放在EXE或DLL的资源(resource)中,IE根据URL定位EXE或DLL,装载其中的资源。下面这个URL就是这种协议的一个例子:
    res://C:\WINNT\system32\shdoclc.dll/http_404.htm
    如果您在IE中要浏览的页面不存在,IE就会通过这个URL,打开C:\WINNT\system32\shdoclc.dll,查找其中名为http_404.htm的资源,找到后提取、显示出来,您看到的就是一个提示页面不存在的网页。
    从上面这个页面的源代码可以看到,除HTML代码外,res协议还允许在页面中包含图片等内容,如上面这个页面就显示了一个名为pagerror.gif的图片,其绝对URL为res://C:\WINNT\system32\shdoclc.dll/pagerror.gif。
    虽然res协议非常简单,基本上不需要额外的编程,但是我目前还没有看到有人用它做电子书,最多只看到有人用它显示软件的About信息。仔细想想,可能是因为这种协议太不保密了:随便找一个资源编辑器,就可以直接获取、替换资源内容了。
    2、基于文件方式
    这种方式的思路其实非常简单:需要显示网页的时候,先将网页解压缩到临时目录,然后用IE控件显示,退出的时候删除临时文件。
    这种方式我早就知道,但是因为它实在是太简单了,所以连我自己都不相信有人真的会用它做电子书,直到我见到雄风网的电子书:这个网站早期发行的电子书,虽然要求用户输入密码进行验证,但是在密码输对以后,就会把全部内容解压缩到temp目录下,然后用IE控件打开文件进行浏览。虽然temp目录下的文件属性被设置为隐藏,但是这点小伎俩实在不值一提,所以只要破解了认证密码,电子书本身就已经提供了完整的反编译功能了。
    该网站后来发行的电子书虽然经过升级,但还是延续了这种模式,只不过在temp目录里存放的是加过密的HTML文件,但是图像文件却是不加密的,因此我猜测他们可能改用MIME Filter技术了。
    3、基于流或document.write方法
    用流往IE控件中写入内容的方法,在MSDN和CSDN中都有详细的讨论,连源代码都有。有需要的到MSDN搜索“Loading HTML content from a Stream”即可。
    document.write在动态网页中比较常用,很多网页加密工具都是使用这招来实现网页源代码的隐藏。对于VC、Delphi等来说,这招不过是换成了IHTMLDocument2::write,效果是一样的。
    使用这种方法做电子书的虽然不多,不过毕竟还是有的,我见过的就是读写网。由于打开这个网站的电子书后,IE主页就会自动设置为这个网站的URL,所以在这里就不给出这个网站的URL了,以免各位受到意外伤害。破解这种电子书的收费验证的方法,已经有人在紫宸殿网络论坛的技术区贴出来过,有兴趣的可以去看看。
    在MSDN中对这种基于流的方法的局限性说得很清楚:
    页面不能太复杂,如果页面包含的tag太多,显示出来的就不是解析后生成的页面,而是原始的HTML代码。大概就是因为这个原因,所以读写网放出来的电子书清一色都只有纯文本,加背景色。
    当前页面的URL永远不变(读写网的永远都是about:blank),因此IE内核没有办法从相对URL自动构造出绝对URL。就是因为这个原因,读写网早期的电子书在页面中使用jpg文件作为背景,就只能将这个背景图片写到temp目录下,然后在网页中使用绝对URL引用这个图片。也正是因为这个原因,所以在页面中不能包含“上一页”、“下一页”、“回目录”等链接,只能自己在左侧放一棵目录树,让用户一页、一页去点。
    由于这种电子书的页面没有自己的URL,因此不能用KillEBook进行反编译,只能用IECracker或CtrlN,一页、一页手工抓取。
    4、采用MIME Filter
    与基于流的方法相比,这种方法不仅支持包含众多tag的复杂HTML页面,而且可以从相对URL构造绝对URL,因此支持页面之间的链接,实现也不复杂,MSDN上就有现成的例子可供参考。
    不过这种方法的缺点也很明显:不能对图像等内容进行加密处理。下面说的协议插件方法就比这种方法强些。
    5、基于web服务器
    对于不懂行的人来说,“web服务器”听起来可能是一个很了不起的东东,但是对于懂行的人来说,实现其实很简单:
    起一个监听线程,对本地80或任何一个指定的端口进行监听。
    每监听到一个连接请求,起一个服务线程,根据请求内容,按照HTTP协议,返回内容。
    在codeguru和codeproject上,有很多现成的web server代码,直接拿来用就好,自己只要考虑怎么填写返回内容即可。VC 6自带的MSDN光盘上,也带了一个名为HTTPSVR的例子,说明如何用MFC和WinSock创建web server。
    使用这种方法虽然简单、直截了当,而且只要愿意,差不多能够模拟一个真正web server的功能(就算想实现app server也并非不可能,不过要花点功夫),但是也有问题:
    基本上没有什么保密性可言,服务器起来后,本机其它进程很轻松就能下载到需要的内容。
    如果本机上其它进程也提供TCP/IP服务,可能会产生端口冲突。
    6、协议插件(Asynchronous Pluggable Protocols)
    这个是微软专门为IE扩展的东西。
    在互联网上,常见的应用层协议包括http、FTP等。出于种种原因,微软允许用户在标准的应用层协议之外,扩展自己的协议,称为Asynchronous Pluggable Protocol。到MSDN、codeguru和codeproject上搜索这几个关键字,从理论到源代码都能找出一堆,在这里我就不罗嗦了。
    Asynchronous Pluggable Protocol可以指定对所有进程有效,这个在注册表的HKEY_CLASSES_ROOT\PROTOCOLS\Handler下注册一下就好;也可以指定只在某个进程内有效,以增加保密性,不过这个时候微软就不叫它Asynchronous Pluggable Protocol了,而是Pluggable Namespace Handler。
    由于Asynchronous Pluggable Protocol具有一定的保密性,实现起来又有例子可参考,而且差不多与架设web server一样,能够对网页显示提供全面的支持,因此在电子书中得到了广泛的应用,我见过的就有mk(chm)、ada99(eBook Workshop)、wc2p(Web Compiler 2000)、ic32pp(Web Compiler 2000—exe防反编译格式)、e-book(E-Book Creator)、mec(E-ditor eBook Compiler)等。不过这种技术如果使用不好,可能会在注册表中产生垃圾,或产生垃圾文件(插件本身是一个COM控件,一般用DLL实现,使用前必须在注册表中注册)。
    7、最后一招
    即使使用Asynchronous Pluggable Protocol,由于在IE内核中还存在可显示的HTML源代码,因此还是存在被导出的可能,这个就是上面正文里讨论了半天的东西。
    我想到的最后一招制作防反编译的电子书的办法就是:在制作的时候,将所有页面内容全部转换成图片,然后再打包。将网页转换成图片的源代码参见这里:
    http://www.codeproject.com/internet/htmlimagecapture.asp
    使用这种方法,在拿到一本制作好的电子书后,想得到原始文本信息的方法大概只有两个:OCR和key in。这个也可以用起点中文网的方法来对付:使用手写体,加水印,故意增加错别字或替换标点符号等。据传说,起点就是根据用户ID,生成错别字和错误标点的,因此如果是原样key in或OCR,就可能被查出来。
    但是回头一想,如果哪个电子书制作工具真的走到了这一步,大概也就离消亡不远了,用户还不如直接去做PDF:
    所有动态效果全部没有,页面上的链接也全部失效,大概又只能靠在左侧放一棵目录树才能导航了。
    页面大小、字符大小基本固定,显示的时候很难放大、缩小,尤其是放大的时候,要么速度比较慢,要么必须忍受难看的锯齿。
    文件尺寸大增。对于以收藏为目的的电子书来说,这是一个必须以严肃的态度,认真地加以考虑的问题。
    点击进入更多精彩>>>