2.2.2.1 Web Compiler 1.67 
這種格式的電子書，因為其制作工具在國內出現(xiàn)得比較早，而且有非常徹底的漢化解密版，所以曾經比較流行，E書時空提供的很多電子書都是這種格式。不過也正因為它的流行，導致想反編譯它的人也多，引出了各種反編譯工具，所以現(xiàn)在用的人似乎已經不多了。 

反編譯工具里，收費的就不去說它了，國內RMH和Fbilo還聯(lián)合推出過免費的unwebcompiler，并且提供全套的Delphi源代碼，有需要的到google或百度搜索一下unwebcompiler就有了。不過可能國內大多數軟件網站的管理員都不是開發(fā)人員出身，對源代碼不感興趣，所以收藏的都是212 KB的EXE，有源代碼的不多，需要仔細找一下。 

在unwebcompiler的源代碼里，RMH和Fbilo對Web Compiler 1.67生成的電子書的文件格式進行了詳細描述，在這里我就不做無聊的重復，有興趣就自己去看吧。我做的UnEBook也使用了他們提供的源代碼，實現(xiàn)對Web Compiler 1.67生成的電子書的批量反編譯，不過被我將代碼從Delphi改成了C，似乎長度縮短了一些（原代碼中有一段在字符串和十六進制數之間轉換來、轉換去，看起來比較怪異，被我省了），不過LHA解壓縮部分改起來實在太麻煩，我直接在網上找了一段現(xiàn)成的C代碼來用。 

2.2.2.2 Caislabs eBook Pack Express 1.6 
這個電子書制作工具也出過漢化版，所以在國內也有一定影響，不過這種影響似乎還沒有大到足以使反編譯工具滿天飛的程度，嘿嘿…… 

在分析這種格式的電子書的時候，我沒有使用任何反匯編工具，用UltraEdit32和系統(tǒng)監(jiān)視工具就猜出來了： 

文件標識：以十六進制串 00 F8 03 00 結尾。這個似乎是一種慣例，差不多所有EXE格式的電子書都有自己特殊的文件結尾。  
目錄塊起始地址指針：0003F81C  
目錄塊中目錄項結構：以0字符結尾的文件名＋4字節(jié)起始地址，文件名起始字節(jié)為FF則目錄塊結束。  
如果文件存放在子目錄里，則文件名首字符：02＝../，01：第一個00變成/，直到遇到02。  
文件內容實際起始地址：目錄項里的4字節(jié)起始地址＋9  
文件內容長度：目錄項里4字節(jié)起始地址所指內容，DWORD。  
在分析出目錄結構后，我曾經想通過調試工具，分析文件加密算法，再反編譯出具體的文件內容，但是很快我就發(fā)現(xiàn)那樣干太累了，實在是得不償失。 

不過在經過幾次嘗試后，我還是找到了一個偷懶的辦法： 

通過安裝hook的方法，往電子書的進程空間注入一個DLL。  
在這個DLL里，用Windows標準的API函數URLDownloadToFile，就可以下載到指定的文件。文件的URL可以按前面說的方法，從目錄項得到相對路徑，再加上一個固定前綴（"file://Z:\\com_caislabs_ebk\\"）構成絕對路徑。  
UnEbook在批量反編譯這種格式的電子書的時候，就是按照上面的分析結果實現(xiàn)的。 

不過到了更高版本的Caislabs eBook Pack Express的時候，似乎Caislabs公司也開始意識到文件內容保護的重要性，因此不僅對文件內容采用更強的加密算法，杜絕了可以用URLDownloadToFile下載的漏洞，連目錄塊的加密強度都強到足夠使我不想去分析了。幸好這個時候我已經有了更好的反編譯思路－－與具體文件格式無關的，專門針對使用IE內核的電子書的通用反編譯思想。 

2.2.2.3 通用反編譯思路 
在分析過幾種電子書格式后，我開始領悟到一個真理：電子書內部文件結構的變化是無窮的，而我的時間和精力是有限的；把有限的時間和精力投入到對抗無窮的變數中去，早晚會有累死的一天。 

有此認識后，我開始思考有沒有什么通用的方法，可以解決大部分電子書的反編譯問題（我還沒有幼稚到相信這世上會有萬能藥的程度）。按照慣例（不可救藥的職業(yè)?。?，第一步當然是市場調查、產品定位，結論是目前大多數電子書都是基于IE內核的，但是根據我在開發(fā)MyReader時對IE內核的了解，這里面明顯存在一個誤區(qū)：微軟以控件的形式提供IE內核，其目的就是希望通過控件接口的開放性、方便性，吸引更多的人加入微軟的標準陣營，如果想在此基礎上添加加密、保護等等內容，恐怕與微軟的初衷不合（我說的是當時，以后微軟改主意了也說不定）。因此我相信IE內核一定有后門可走！經過一番努力，果然沒有令我失望。 

1、基本原理 

針對IE內核電子書的通用破解技術實現(xiàn)起來可能需要一些技術和技巧，但是原理卻很簡單，幾句話就可以說清楚：不論電子書在存儲的時候如何對內容進行加密，在將內容傳遞給IE內核進行顯示的時候，一定要將內容轉換成IE內核能夠識別的標準格式－－HTML格式。而IE內核為了便于顯示、刷新，在對HTML代碼進行解析后，并不是立刻就把這些HTML代碼拋棄，而是在內存里保存了一份備份。因此只要將這份備份從IE內核里搞出來，就得到了解碼后的內容，也就是反編譯想得到的內容。 

至于網頁中的其它內容，包括圖片、css、js、Flash文件等，就更簡單了：模擬IE內核，直接找電子書要就好。如果電子書分辨不出請求是來自IE內核還是來自其它地方，自然會乖乖把我們需要的東西雙手奉上！ 

雖然反編譯的原理幾句話就可以說清，但是要加以實現(xiàn)，還需要經過艱苦的探索和試驗，我自己就經過了長期的努力，IE內核的源代碼都翻來覆去看了好幾遍（吹的，別當真！）。而我思想的發(fā)展也大概經歷了兩個階段：第一個階段是在得到某份傳說中的源代碼（沒錯，就是那份展開后近700MB，被國內主流媒體形容為噱頭、無足輕重、充滿無聊垃圾的東西）之前，完全立足于微軟公開的IE內核接口。當時我考慮將電子書內容按照HTML、圖像等分類，分別解決獲取問題。第二個階段是在得到那份源代碼之后，我突然發(fā)現(xiàn)其實對于所有文件，我都可以直接找電子書要，只要假裝是IE內核在要就行了。 

由于某些東西比較敏感，因此下面敘述的主要是我第一個階段的想法，其中有些屬于基礎性的東西。第二個階段的實現(xiàn)恕我不便奉告。 

2、獲取HTML源代碼的方法 

從IE內核獲取HTML源代碼的方法不僅我一個人在想，從國內到國外，從CSDN（CSDN的VC/MFC區(qū)有一個欄目專門討論IE內核編程）到MSDN，早就有很多人討論過了，歸納起來，一般認為可以通過下列步驟實現(xiàn)： 

不管是通過鼠標點擊也好，通過EnumChildWindow也好，總之先找到IE內核的顯示窗口，也就是電子書顯示網頁內容的那個窗口。  
通過這個窗口的句柄（HWND），取得這個窗口對應的IE內核文檔接口IHTMLDocument2的接口指針。取得的方法目前認為有兩種，我個人認為這兩種需要結合使用，否則總有一些電子書會搞不定：一個是通過MSAA，一個是通過WM_HTML_GETOBJECT消息。至于具體的實現(xiàn)代碼，在CSDN上都快被討論爛了，因此此處從略，有需要的自己到CSDN上找。不過這兩種方法都對平臺有要求：XP下是完全沒有問題，2000下可能需要裝IE 6，98/Me/NT就不要想了。  
在得到IHTMLDocument2接口指針后，按照這個接口提供的標準方法，即可獲得文檔的HTML代碼。具體實現(xiàn)代碼見CSDN中的例子。  
除了上面這種方法外，我自己還嘗試過一種方法：使用MIME Filter。 

對于搞過網頁在線翻譯、網頁內容過濾的人來說，MIME Filter可是吃飯的本錢，它的作用和實現(xiàn)機理應該早就爛熟于心，但是對于其它人來說，可能還不是很熟，所以這里簡單介紹一下：為了便于對IE內核的功能進行擴展，微軟規(guī)定在IE內核顯示某種標準格式（HTML、TEXT等）的內容之前，會先將要顯示的內容傳遞給這種格式的過濾器，即MIME Filter，由它先對內容進行預處理（如將英文翻譯成中文，將下流文字替換成星號等），然后再顯示。 

按照這個原理，如果實現(xiàn)一個針對HTML格式的MIME Filter，即可攔截到最原汁原味的HTML代碼。可惜，經過我的嘗試，這招對IE本身是靈的，對某些電子書也有效，但是對另一些無效。再加上使用IHTMLDocument2接口指針的方法要比這種方法簡單得多，也可靠得多，所以后來在我開發(fā)的反編譯工具KillEBook、IECracker和CtrlN里就沒有使用這種方法。不過這種方法也有一個好處：與平臺無關，我在98/Me/2000/XP下都試過，當然都是在虛擬機下試的啦。 

MIME Filter的作用機理、實現(xiàn)方法在MSDN里有詳細說明，并提供了詳細的實例代碼，有需要的可以到MSDN上搜“MIME Filter”。 

3、獲取圖像的方法 

與HTML代碼相似，IE內核對圖像的處理也有一個“下載->解碼->顯示”的過程?？紤]到顯示代碼的抽象性，原來各種各樣的圖像格式，包括JPG、GIF、PNG、TIFF等，在解碼后都被統(tǒng)一表示成位圖格式，而原有格式數據在解碼后即被從內存中釋放，只在IE的cache中留有文件備份。如果指定不允許保存本地cache，則連這個備份都沒有。在IE中通過右鍵菜單選“圖片另存為...”的時候，其實就是將cache中的文件備份拷貝一份出來，如果cache中已經沒有備份，就只能保存內存中的位圖（*.bmp）了。現(xiàn)在明白為什么有些圖片明明是jpg格式，但是用IE卻只能保存為“無標題.bmp”了吧？ 

因此，獲取圖像文件要比獲取HTML文件難得多。而且在MSDN里說得很清楚，用IHTMLDocument2接口只能得到圖像的鏈接，用MIME Filter也不能搞到網頁里的圖像數據，因此需要另想辦法。我想過、試過的包括： 

先將圖像復制到剪貼板，再從剪貼板里獲取圖像數據，然后根據圖像文件擴展名（可以從圖像元素的URL里解析），編碼成原始圖像格式，包括jpg、png、gif、tiff等。這個方法實現(xiàn)比較簡單，到MSDN KB里搜索Q293125，拷貝圖像到剪貼板的現(xiàn)成源代碼就有了，圖像編碼的源代碼則可以參考cximage，這個也是google一下就有的。不過這個方法遠非完美無缺：a). 對于png、gif等允許帶透明背景的格式，用這種方法處理后就不透明了。b). gif動畫處理后就動不起來了，只能顯示其中的某一幀。c). 對于jpg這樣的有損壓縮格式來說，每壓縮一次就損失一次，多壓縮幾次可能就沒法看了。d). 在電子書里，可以通過標準的Windows API函數，使剪貼板失效。  
將IE內核導航到圖片，然后通過IViewObject接口獲取圖片的拷貝。這個方法與上面的方法基本相同，不過不通過剪貼板，可以防止因為剪貼板被封鎖而搞不到圖像。  
使用IE圖像解碼插件。IE內核在下載到某種格式的圖像文件后，會調用對應的解碼器，對圖像進行解碼（類似于MIME Filter）。為了便于擴充，解碼器是做成插件形式的。如果自己做一個圖像解碼器插件，對解碼請求進行攔截，即可獲得解碼前的原始圖像格式數據。解碼器的接口、實現(xiàn)方法在微軟公開文檔中沒有任何蛛絲馬跡，但是在那份傳說中的源代碼里，不僅有詳細的接口規(guī)范，而且有好幾個內嵌圖像解碼器的實現(xiàn)代碼，可供借鑒。奇怪的是，雖然在MSDN中找不到，但是我在google上搜的時候，卻發(fā)現(xiàn)有一個日本人在自己的個人網站上，早就給出了詳細的圖像解碼器插件實現(xiàn)方法，一步一步說得很清楚，而且落款時間是2002年12月！看來這份源代碼的泄漏時間可能比想象的要早。當然這個日本人也可能本來就在微軟工作，或與微軟有合作關系，可以光明正大地查看解碼器源代碼也說不定。  
4、通用反編譯器的實現(xiàn) 

在解決了HTML、頁面元素等的獲取方法后，通用反編譯器KillEBook的實現(xiàn)就很簡單了，其算法可以描述如下： 

打開電子書。  
定位電子書的顯示窗口。  
獲取當前顯示頁面的HTML代碼。  
解析頁面HTML代碼，得到其中的所有鏈接。  
獲取頁面上的所有元素內容，包括圖片等。  
引導IE內核依次加載HTML鏈接頁面。  
重復步驟3～6，直到所有頁面及其中的元素都已獲取到。  
5、進一步討論 

在完成KillEBook后，我發(fā)現(xiàn)其實對它擴展一下，就可以成為一種新的離線瀏覽器，解決傳統(tǒng)離線瀏覽器（Offline Explorer Pro、Webzip等）面臨的一個問題：傳統(tǒng)離線瀏覽器多半與IE內核沒什么瓜葛，因此在抓靜態(tài)網頁的時候都沒有什么問題，但是在抓用session維持的動態(tài)網頁時，都有點問題，更不用說抓需要PKI證書驗證的HTTPS網站。 

因此我考慮可以實現(xiàn)這樣一個離線瀏覽器： 

提供一個地址欄供用戶輸入起始URL。  
內嵌一個微軟web browser控件（IE內核），供用戶交互，包括在網頁上輸入用戶名/密碼、從IE證書庫中選擇證書。  
用戶登錄成功、進入需要開始抓取的網頁后，設定遞歸深度、URL過濾條件，點“開始”按鈕開始抓取。  
離線瀏覽器自動引導web browser進入每個頁面，每進入一個頁面，都通過web browser控件獲取客戶端HTML源代碼及頁面元素，包括圖片、css、js、flash等。  
采用這種方法實現(xiàn)的離線瀏覽器，由于使用web browser控件，因此可以維持客戶端session，抓取到動態(tài)網頁。雖然網頁抓取下來就成了靜態(tài)的，但是對離線瀏覽來說應該不成問題，對付收費的網上教育等網站正好合適。 

2.3 HLP格式 
這種格式出現(xiàn)得比較早，在16位Windows（Windows 95以前的各Windows版本）下曾是標準的幫助文件格式，因此大概也算是Windows下出現(xiàn)得最早的電子書格式之一了。 

由于這種格式比較流行，國外研究的也比較多，不過公開源代碼的我似乎只見過一個HELPDECO v2.1。這個軟件是一個控制臺程序，因此有人做了一個GUI外殼DuffOS對它進行封裝。國內有人對HELPDECO進行過漢化，到漢化新世紀搜索一下就可以找到，包括全部源代碼。 

在UnEBook中使用了HELPDECO的源代碼，實現(xiàn)對HLP文件的批量反編譯。不過從我使用的情況看，原版HELPDECO有一個小小的不足：反編譯出來的RTF文件沒有指定字符集。這對英文RTF來說沒有任何影響，但是對中文RTF來說，其影響足夠強到使您打開RTF后看到的是一堆亂碼。它的修正方法有兩個： 

用文本編輯器打開反編譯出來的RTF文件，手工指定中文字符集。這個是一種比較累的方法。  
修改HELPDECO源代碼，加上字符集修正，這個是一勞永逸的辦法。但是不知道為什么，在漢化新世紀推出的漢化版上，我看到的還是原版的HELPDECO。看來漢化者只是用它反編譯過英文HLP，沒有反編譯過中文HLP。  
另外這份源代碼還有一個不知道算不算是嚴重的問題：變量沒有統(tǒng)一初始化、釋放，因此不僅在程序退出的時候，VC++會報告有內存漏洞，而且就象當年的DOS內核一樣，幾乎沒有可重入性。我曾經試圖修復這個bug，但是在經過一個下午的奮斗后，有兩處泄漏死活找不到。最后我還是決定向DuffOS學習：將HELPDECO代碼封裝成一個獨立的DLL，每反編譯一個HLP文件，都動態(tài)加載、釋放一次DLL。這樣一方面可以利用Windows本身的DLL管理機制，彌補HELPDECO產生的內存漏洞，一方面解決不可重入問題。收費的“耶書制造”軟件提供的HLP反編譯功能也是用DLL文件實現(xiàn)的，因此我嚴重懷疑它的作者可能也曾遇到過相同的煩惱，嘿嘿嘿…… 

最新評論