3. 結(jié)論

1. 就像信息安全中的攻與防一樣，電子書的編譯與反編譯之間的斗爭也將是一個永無止境的死循環(huán)。我相信不論電子書反編譯技術(shù)如何發(fā)展，都不會導(dǎo)致電子書的絕跡，畢竟有實際的需要。但是本文的發(fā)表，毫無疑問將會刺激電子書制作軟件和制作技術(shù)的新一輪升級。那么我的文章和軟件會不會隨之升級呢？我自己是沒什么自信啦，畢竟我的自由時間越來越少，而如果沒有其他人愿意象我這樣研究反編譯技術(shù)和軟件（收費的免談），我想最終勝利的一定是有商業(yè)利益支撐的電子書制作軟件。
2. 先分析電子書的詳細文件格式，再有針對性推出專用反編譯器的方法，在初期確實是一個不錯的方法，但是隨著電子書格式的增多，如果每一種都要去分析一遍，早晚會累死。
3. 電子書制作軟件其實也是人開發(fā)的，開發(fā)者當然也會有人類的通病——懶！只要有現(xiàn)成的東西可用，很少有人會再花力氣去修練自己的獨門功夫。而目前Windows下的東西，開放性的考慮要比安全性的考慮更多一些，如果能夠找到這些東西的突破口，即可突破同一類使用這些東西的電子書。
4. 利用現(xiàn)成控件的接口或漏洞，實現(xiàn)通用電子書反編譯，這其實也是程序員懶惰的一種體現(xiàn)。這種方法雖然比老老實實分析、跟蹤電子書簡單許多，但是也有其天然缺陷：只能反編譯顯示到控件中的內(nèi)容。通俗一點說，如果電子書是加密碼保護的，那么這種方法并不能在不知道密碼的情況下，反編譯出電子書的內(nèi)容。

附錄 基于IE內(nèi)核電子書的實現(xiàn)方式探討

電子書看多了，有時候我也會想，如果是我自己做一個電子書制作工具，我會采用什么樣的技術(shù)加以實現(xiàn)？考慮到現(xiàn)在HTML格式文檔的普遍性，在有人開放出新的HTML render之前，我的想法還是只能圍繞IE內(nèi)核打轉(zhuǎn)。下面就是我想到的一些思路。

1、基于res協(xié)議

res協(xié)議是IE內(nèi)核提供的一種非常簡單的協(xié)議，允許將需要瀏覽的頁面存放在EXE或DLL的資源（resource）中，IE根據(jù)URL定位EXE或DLL，裝載其中的資源。下面這個URL就是這種協(xié)議的一個例子：

res://C:\WINNT\system32\shdoclc.dll/http_404.htm

如果您在IE中要瀏覽的頁面不存在，IE就會通過這個URL，打開C:\WINNT\system32\shdoclc.dll，查找其中名為http_404.htm的資源，找到后提取、顯示出來，您看到的就是一個提示頁面不存在的網(wǎng)頁。

從上面這個頁面的源代碼可以看到，除HTML代碼外，res協(xié)議還允許在頁面中包含圖片等內(nèi)容，如上面這個頁面就顯示了一個名為pagerror.gif的圖片，其絕對URL為res://C:\WINNT\system32\shdoclc.dll/pagerror.gif。

雖然res協(xié)議非常簡單，基本上不需要額外的編程，但是我目前還沒有看到有人用它做電子書，最多只看到有人用它顯示軟件的About信息。仔細想想，可能是因為這種協(xié)議太不保密了：隨便找一個資源編輯器，就可以直接獲取、替換資源內(nèi)容了。

2、基于文件方式

這種方式的思路其實非常簡單：需要顯示網(wǎng)頁的時候，先將網(wǎng)頁解壓縮到臨時目錄，然后用IE控件顯示，退出的時候刪除臨時文件。

這種方式我早就知道，但是因為它實在是太簡單了，所以連我自己都不相信有人真的會用它做電子書，直到我見到雄風(fēng)網(wǎng)的電子書：這個網(wǎng)站早期發(fā)行的電子書，雖然要求用戶輸入密碼進行驗證，但是在密碼輸對以后，就會把全部內(nèi)容解壓縮到temp目錄下，然后用IE控件打開文件進行瀏覽。雖然temp目錄下的文件屬性被設(shè)置為隱藏，但是這點小伎倆實在不值一提，所以只要破解了認證密碼，電子書本身就已經(jīng)提供了完整的反編譯功能了。

該網(wǎng)站后來發(fā)行的電子書雖然經(jīng)過升級，但還是延續(xù)了這種模式，只不過在temp目錄里存放的是加過密的HTML文件，但是圖像文件卻是不加密的，因此我猜測他們可能改用MIME Filter技術(shù)了。

3、基于流或document.write方法

用流往IE控件中寫入內(nèi)容的方法，在MSDN和CSDN中都有詳細的討論，連源代碼都有。有需要的到MSDN搜索“Loading HTML content from a Stream”即可。

document.write在動態(tài)網(wǎng)頁中比較常用，很多網(wǎng)頁加密工具都是使用這招來實現(xiàn)網(wǎng)頁源代碼的隱藏。對于VC、Delphi等來說，這招不過是換成了IHTMLDocument2::write，效果是一樣的。

使用這種方法做電子書的雖然不多，不過畢竟還是有的，我見過的就是讀寫網(wǎng)。由于打開這個網(wǎng)站的電子書后，IE主頁就會自動設(shè)置為這個網(wǎng)站的URL，所以在這里就不給出這個網(wǎng)站的URL了，以免各位受到意外傷害。破解這種電子書的收費驗證的方法，已經(jīng)有人在紫宸殿網(wǎng)絡(luò)論壇的技術(shù)區(qū)貼出來過，有興趣的可以去看看。

在MSDN中對這種基于流的方法的局限性說得很清楚：

1. 頁面不能太復(fù)雜，如果頁面包含的tag太多，顯示出來的就不是解析后生成的頁面，而是原始的HTML代碼。大概就是因為這個原因，所以讀寫網(wǎng)放出來的電子書清一色都只有純文本，加背景色。
2. 當前頁面的URL永遠不變（讀寫網(wǎng)的永遠都是about:blank），因此IE內(nèi)核沒有辦法從相對URL自動構(gòu)造出絕對URL。就是因為這個原因，讀寫網(wǎng)早期的電子書在頁面中使用jpg文件作為背景，就只能將這個背景圖片寫到temp目錄下，然后在網(wǎng)頁中使用絕對URL引用這個圖片。也正是因為這個原因，所以在頁面中不能包含“上一頁”、“下一頁”、“回目錄”等鏈接，只能自己在左側(cè)放一棵目錄樹，讓用戶一頁、一頁去點。

由于這種電子書的頁面沒有自己的URL，因此不能用KillEBook進行反編譯，只能用IECracker或CtrlN，一頁、一頁手工抓取。

4、采用MIME Filter

與基于流的方法相比，這種方法不僅支持包含眾多tag的復(fù)雜HTML頁面，而且可以從相對URL構(gòu)造絕對URL，因此支持頁面之間的鏈接，實現(xiàn)也不復(fù)雜，MSDN上就有現(xiàn)成的例子可供參考。

不過這種方法的缺點也很明顯：不能對圖像等內(nèi)容進行加密處理。下面說的協(xié)議插件方法就比這種方法強些。

5、基于web服務(wù)器

對于不懂行的人來說，“web服務(wù)器”聽起來可能是一個很了不起的東東，但是對于懂行的人來說，實現(xiàn)其實很簡單：

1. 起一個監(jiān)聽線程，對本地80或任何一個指定的端口進行監(jiān)聽。
2. 每監(jiān)聽到一個連接請求，起一個服務(wù)線程，根據(jù)請求內(nèi)容，按照HTTP協(xié)議，返回內(nèi)容。

在codeguru和codeproject上，有很多現(xiàn)成的web server代碼，直接拿來用就好，自己只要考慮怎么填寫返回內(nèi)容即可。VC 6自帶的MSDN光盤上，也帶了一個名為HTTPSVR的例子，說明如何用MFC和WinSock創(chuàng)建web server。

使用這種方法雖然簡單、直截了當，而且只要愿意，差不多能夠模擬一個真正web server的功能（就算想實現(xiàn)app server也并非不可能，不過要花點功夫），但是也有問題：

1. 基本上沒有什么保密性可言，服務(wù)器起來后，本機其它進程很輕松就能下載到需要的內(nèi)容。
2. 如果本機上其它進程也提供TCP/IP服務(wù)，可能會產(chǎn)生端口沖突。

6、協(xié)議插件（Asynchronous Pluggable Protocols）

這個是微軟專門為IE擴展的東西。

在互聯(lián)網(wǎng)上，常見的應(yīng)用層協(xié)議包括http、FTP等。出于種種原因，微軟允許用戶在標準的應(yīng)用層協(xié)議之外，擴展自己的協(xié)議，稱為Asynchronous Pluggable Protocol。到MSDN、codeguru和codeproject上搜索這幾個關(guān)鍵字，從理論到源代碼都能找出一堆，在這里我就不羅嗦了。

Asynchronous Pluggable Protocol可以指定對所有進程有效，這個在注冊表的HKEY_CLASSES_ROOT\PROTOCOLS\Handler下注冊一下就好；也可以指定只在某個進程內(nèi)有效，以增加保密性，不過這個時候微軟就不叫它Asynchronous Pluggable Protocol了，而是Pluggable Namespace Handler。

由于Asynchronous Pluggable Protocol具有一定的保密性，實現(xiàn)起來又有例子可參考，而且差不多與架設(shè)web server一樣，能夠?qū)W(wǎng)頁顯示提供全面的支持，因此在電子書中得到了廣泛的應(yīng)用，我見過的就有mk（chm）、ada99（eBook Workshop）、wc2p（Web Compiler 2000）、ic32pp（Web Compiler 2000—exe防反編譯格式）、e-book（E-Book Creator）、mec（E-ditor eBook Compiler）等。不過這種技術(shù)如果使用不好，可能會在注冊表中產(chǎn)生垃圾，或產(chǎn)生垃圾文件（插件本身是一個COM控件，一般用DLL實現(xiàn)，使用前必須在注冊表中注冊）。

7、最后一招

即使使用Asynchronous Pluggable Protocol，由于在IE內(nèi)核中還存在可顯示的HTML源代碼，因此還是存在被導(dǎo)出的可能，這個就是上面正文里討論了半天的東西。

我想到的最后一招制作防反編譯的電子書的辦法就是：在制作的時候，將所有頁面內(nèi)容全部轉(zhuǎn)換成圖片，然后再打包。將網(wǎng)頁轉(zhuǎn)換成圖片的源代碼參見這里：

http://www./internet/htmlimagecapture.asp

使用這種方法，在拿到一本制作好的電子書后，想得到原始文本信息的方法大概只有兩個：OCR和key in。這個也可以用起點中文網(wǎng)的方法來對付：使用手寫體，加水印，故意增加錯別字或替換標點符號等。據(jù)傳說，起點就是根據(jù)用戶ID，生成錯別字和錯誤標點的，因此如果是原樣key in或OCR，就可能被查出來。

但是回頭一想，如果哪個電子書制作工具真的走到了這一步，大概也就離消亡不遠了，用戶還不如直接去做PDF：

1. 所有動態(tài)效果全部沒有，頁面上的鏈接也全部失效，大概又只能靠在左側(cè)放一棵目錄樹才能導(dǎo)航了。
2. 頁面大小、字符大小基本固定，顯示的時候很難放大、縮小，尤其是放大的時候，要么速度比較慢，要么必須忍受難看的鋸齒。
3. 文件尺寸大增。對于以收藏為目的的電子書來說，這是一個必須以嚴肅的態(tài)度，認真地加以考慮的問題。