欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

常見電子書格式及其反編譯思路分析第2/3頁

 更新時間:2008年07月17日 23:41:04   作者:  
本文僅僅從技術角度討論電子書反編譯問題,請勿將之用于侵犯版權等等非法目的,或損害他人利益。如果您對此感到失望,請勿繼續(xù)閱讀。

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)的,因此我嚴重懷疑它的作者可能也曾遇到過相同的煩惱,嘿嘿嘿…… 

相關文章

最新評論