本發(fā)明涉及智能終端安全技術領域，具體涉及基于Hook技術的動態(tài)加載方法。

背景技術：

近年來，智能手機在全球范圍內迅速普及，據最新智能終端銷量統(tǒng)計，在中國Android系統(tǒng)目前已占據移動端73％以上的市場份額，大量的用戶帶來潛在的安全壓力，APK應用作為智能設備與用戶的唯一交互入口，涉及的業(yè)務越來越廣，涵蓋了娛樂、支付、生活等各個領域。移動互聯在給大眾消費者帶來便捷的同時，也附著各種安全隱患。相對于系統(tǒng)安全來說，Android應用程序級數式的增長過程中面臨的安全問題嚴峻很多。惡意應用層出不窮，熱門應用被簡單的二次打包、篡改、惡意注入，成為黑客手中斂財的利器。

APK應用實際上是一個Zip壓縮文件，該文件結構如下表1所示，其中的Dex文件是核心java代碼，包含了應用的關鍵算法、實現邏輯等，是APK的關鍵部分，一旦其被反編譯，整個應用的源代碼將被暴露，破壞者可以向其中注入惡意代碼，使其成為一個攜帶惡意代碼的Apk文件。因此，Dex文件是加固產品重點保護的對象，但是現有的加固方法大多存在一些缺陷，主要表現在加固后的APK脫殼加載運行時，Dex動態(tài)加載類提供的接口必須要求解密后的源程序短暫地保存在文件系統(tǒng)中，這就極大地增加了Dex文件被泄露的風險。

表1

技術實現要素：

本發(fā)明克服了現有技術的不足，提供一種基于Hook技術的動態(tài)加載方法。

為解決上述的技術問題，本發(fā)明采用以下技術方案：

基于Hook技術的動態(tài)加載方法，它包括以下步驟：

步驟1，對已經加固處理的APK文件進行解壓，得到經過加密處理的原始APK文件中的DEX文件，將DEX文件進行存儲；

步驟2，通過DEX類加載器將步驟1中的DEX文件加載到ART虛擬機；

步驟3，采用API Hook方法Hook掉ibart.so庫和libc.so庫中與DEX文件加載相關的函數；

步驟4，重寫被Hook的函數。

更進一步的技術方案是，所述步驟3中需要Hook的函數包括libart.so庫中的execv函數和libc.so庫中的read函數、mmap函數和munmap函數。

更進一步的技術方案是，所述步驟4具體包括：

步驟4.1，重寫execv函數，在重寫的execv函數中判斷如果處理的文件為加密后的DEX文件，則讓系統(tǒng)退出調用dex2oat的進程，加快Dex文件的啟動時間；

步驟4.2，重寫read函數，在重寫的read函數中判斷如果處理的文件為加密后的DEX文件，則將DEX文件頭標志賦值給系統(tǒng)校驗變量，讓加密后的DEX文件通過系統(tǒng)的文件類型校驗；

步驟4.3，重寫mmap函數，將加密后的DEX文件映射進內存，在重寫的mmap函數中判斷如果處理的文件為加密后的DEX文件，則調用解密算法對加密的DEX文件進行解密，并返回解密的DEX文件給系統(tǒng)解析加載，進而完成加密DEX文件的加載；

步驟4.4，重寫munmap函數，在重寫的munmap函數中將hook_mmap中申請的內存釋放掉。

更進一步的技術方案是，所述步驟2中的DEX類加載器為Android API提供的Dexclassloder類。

更進一步的技術方案是，所述步驟3中的API Hook方法包括Inline hook方法和Got hook方法。

本技術方案中一方面，通過Hook execv函數讓系統(tǒng)退出調用dex2oat的進程，可以加速加殼APK的啟動時間；另一方面，在內存中對加密DEX文件進行解密，使得DEX文件難以被獲取，克服了使用Dexclassloader類加載DEX文件必須將DEX文件以文件形式明文存放在存儲設備上的缺點，大大降低了加殼APK被反編譯的風險，保證了APK核心代碼DEX文件的安全。

與現有技術相比，本發(fā)明的有益效果是：

本發(fā)明在內存中對加密的Dex文件進行解密保存，增加了反編譯的難度，極大程度地提高了APK文件的安全性。本發(fā)明適用于Android系統(tǒng)Art模式下軟件加殼保護。

附圖說明

圖1為本發(fā)明一種實施例的基于Hook技術的動態(tài)加載方法流程框圖。

具體實施方式

下面結合附圖對本發(fā)明作進一步闡述。

如圖1所示的基于Hook技術的動態(tài)加載方法，它主要包括如下步驟：

對已作加固處理的APK文件進行解壓，得到經過加密處理后的原始APK中的DEX文件另行存儲；

在native層使用API Hook技術Hook DEX文件加載相關函數，包括libart.so庫中的execv函數和libc.so庫中的read函數、mmap函數和munmap函數；

execv函數Hook成功后，重寫execv函數，在重寫的execv函數中判斷所處理的文件是否為加密后的DEX文件，如果是，則讓系統(tǒng)退出調用dex2oat的進程，加快DEX文件的啟動時間；

read函數Hook成功后，重寫read函數，在重寫的read函數中判斷處理的文件是否為加密后的DEX文件，如果是，則直接將DEX文件頭標志賦值給系統(tǒng)校驗變量，讓加密后的DEX文件通過系統(tǒng)的文件類型校驗；

mmap函數Hook成功后，重寫mmap函數，將加密后的DEX文件映射進內存，在重寫的mmap函數中判斷處理的文件是否為加密后的DEX文件，如果是，則在hook_mmap中調用解密算法對加密DEX文件進行解密，并返回解密后的DEX文件；

munmap函數Hook成功后，重寫munmap函數，在重寫的munmap函數中使用將hook_mmap中申請的內存釋放掉。

以上具體實施方式對本發(fā)明的實質進行詳細說明，但并不能對本發(fā)明的保護范圍進行限制，顯而易見地，在本發(fā)明的啟示下，本技術領域普通技術人員還可以進行許多改進和修飾，需要注意的是，這些改進和修飾都落在本發(fā)明的權利要求保護范圍之內。