淺談PHP源代碼保護(hù)方案&受保護(hù)PHP代碼の解密還原
當(dāng)前位置:點(diǎn)晴教程→知識管理交流
→『 技術(shù)文檔交流 』
前言php是一種解釋型腳本語言,與編譯型語言不同,php源代碼不是直接翻譯成機(jī)器語言,而是翻譯成中間代碼(OPCODE) ,再由解釋器(ZEND引擎)對中間代碼進(jìn)行解釋運(yùn)行。 在php源代碼的保護(hù)在原理可以分為3大類:
在部署上可以分為2大類:
下面分析下各種加密方案的實(shí)現(xiàn)方法。 PHP 加密方案分析無擴(kuò)展方案源代碼混淆無擴(kuò)展的加密在一些小開發(fā)者比較常見。 這種源代碼保護(hù)方式侵入性小,無需對服務(wù)器做額外的配置,兼容性較強(qiáng)。 這種情況混淆后的源代碼還原非常簡單,可完全還原出源代碼。 有時(shí)連注釋都會(huì)保留 (x 我覺得這種混淆都不能稱之為加密)。 基本流程 壓縮代碼->混淆變量函數(shù)類名->使用簡單函數(shù)和方法進(jìn)行編碼加密 例:base64 異或。
手工解密看到這種的php不要慌 這種處理后的文件 解密流程的變量和函數(shù)名使用了大量的非打印字符 按照正常的流程就可以 ctrl+alt+l 快捷鍵 格式化代碼 (這里使用的PhpStorm 其他IDE 格式化遇到特殊符號可能出問題 這里提前調(diào)整好了文件編碼)。
這里有一個(gè)php的特性 php中的base64遇到非base64表中字符會(huì)直接忽略 不會(huì)影響解碼。 注: PHP7 遇到空字符可能會(huì)拋出error 可以使用php5.6執(zhí)行 (這里有一個(gè)兼容性問題 )。 遇到這種加密最簡單的方法就是找文件中最后一步執(zhí)行的函數(shù) 直接把內(nèi)容打印出來。 這種編碼方法最后一步肯定要使用eval執(zhí)行還原后的php代碼 所以打印最后一個(gè)函數(shù)基本上php代碼就會(huì)全部出來 (x 前面操作一大頓毫無卵用)。 注: 有保護(hù)方案也使用了call_user_func或call_user_func_array間接調(diào)用eval。
成功還原源代碼 <?php phpinfo();?> 自動(dòng)化通用解密PHP提供了強(qiáng)大的擴(kuò)展功能 可以直接通過編寫php擴(kuò)展hook eval相關(guān)函數(shù) 獲取執(zhí)行的源代碼。 HOOK php zend引擎的 zend_compile_string zend_include_or_eval 函數(shù)達(dá)到目的。 這里演示的是 hook zend_compile_string 函數(shù)。
成功還原源代碼 PHP擴(kuò)展方案源代碼混淆使用php擴(kuò)展的代碼混淆和無擴(kuò)展代碼混淆比較相似,只不過是把代碼還原過程從php代碼轉(zhuǎn)到了php擴(kuò)展。 同樣是使用aes des 異或等加密方法直接加密php代碼,HOOK翻譯php的函數(shù)在翻譯PHP文件前對文件進(jìn)行解密操作。這種方案也可以完全還原出源代碼。在無其他混淆和壓縮時(shí)甚至還會(huì)保留注釋。 典型開源項(xiàng)目:php-beast tonyenc screw-plus 手工解密這里以beast為例: 首先在php的擴(kuò)展目錄下找到beast.so。 beast的加密方案會(huì)把加密key編譯進(jìn)擴(kuò)展中,我們只需要尋找key就可以完成解密。 beast由于是開源項(xiàng)目,有現(xiàn)成的符號表和源碼這使得反編譯尋找key變得非常簡單。 但這樣有點(diǎn)太簡單了,所以這里演示的是在沒有源碼的情況下使用IDA分析解密流程。
首先在導(dǎo)入表找到zend_compile_file。 這個(gè)函數(shù)會(huì)將php文件翻譯成opcode。 因此大部分php加密擴(kuò)展都需要hook這個(gè)函數(shù)達(dá)到攔截php文件載入和替換php文件的功能。
繼續(xù)跟入,發(fā)現(xiàn)有兩個(gè)函數(shù)。 一般在這種php加密擴(kuò)展設(shè)計(jì)時(shí)會(huì)對這個(gè)函數(shù)有兩次操作: 一個(gè)是在啟動(dòng)時(shí)hook 這個(gè)函數(shù),一個(gè)是在停止時(shí)恢復(fù)這個(gè)函數(shù)。 繼續(xù)跟入啟動(dòng)hook。 顯然文件處理邏輯在cgi_compile_file內(nèi)。
跟蹤文件句柄 decrypt_file函數(shù)的參數(shù)存在文件句柄 所以這個(gè)函數(shù)應(yīng)該就是文件解密函數(shù)
根據(jù)代碼可以看出beast 加密文件的結(jié)構(gòu) | encrypt_file_header_sign 文件頭標(biāo)記(不固定 可修改)| reallen文件長度 int 4字節(jié) | expire 到期時(shí)間 int 4字節(jié)| entype 加密方式 int 4字節(jié)| 加密后文件|
分析文件頭發(fā)現(xiàn)該文件加密方式為 02
跟入beast_get_encrypt_algo
2對應(yīng)的是 aes_handler_ops
使用了AES 128 ECB加密模式 直接提取key參數(shù)內(nèi)容 長度剛好16位
到這一步就成功拿到了加密秘鑰
使用拿到的KEY就可以解密PHP文件 自動(dòng)化通用解密編寫php擴(kuò)展 HOOK zend_compile_file函數(shù)
beast的加密不會(huì)對php文件做額外的操作 解密文件與加密前原文件完全一致,php注釋和原格式都會(huì)保留。 注意: 這里擴(kuò)展加載順序問題,建議直接修改php源碼。 opcodephp會(huì)將源代碼翻譯成類似匯編的二進(jìn)制中間操作碼再交給zend引擎執(zhí)行。 之前的介紹的都是編譯之前對php源代碼的直接操作。這里是對opcode的操作,跳過翻譯過程,直接把現(xiàn)成的opcode交給zend引擎執(zhí)行(不同版本PHP引擎編譯出的opcode可能會(huì)有兼容性問題)。 這種php代碼防護(hù)方法 只能hook zend_execute 拿到opcode。 不可能直接得到原本的源碼,只能通過反編譯盡可能的還原源代碼。 大部分商業(yè)php保護(hù)方案都使用這種可靠的方案為基礎(chǔ) _ZendGuard(zend) _SourceGuardian(SG) IonCube (IC) Swoole Compiler 上面的方案有的還對zend引擎進(jìn)行了魔改,使翻譯出的opcode只能在修改后的引擎執(zhí)行,進(jìn)一步增強(qiáng)了安全性。 還原代碼hook zend_execute 拿到opcode 使用對應(yīng)版本的php操作碼反推php代碼 太菜了不會(huì)反編譯) 附錄PHP擴(kuò)展編譯docker run -it --rm -v /mnt/hgfs/tmpssd/php-eval-hook/:/ext/ php:5.6 /bin/bash apt-get update apt install libtool phpize phpize 生成Makefile
./configure --enable-evalhook 配置編譯選項(xiàng) 啟用擴(kuò)展 最后執(zhí)行make 編譯擴(kuò)展 編譯好的擴(kuò)展會(huì)放在./modules/ 目錄下 使用擴(kuò)展 php -d extension=擴(kuò)展位置 -f 文件 可以重復(fù)使用-d extension 加載多個(gè)擴(kuò)展 總結(jié)在選用PHP源碼保護(hù)方案時(shí),盡量選擇opcode或虛擬機(jī)方案。 源代碼混淆類只能對源代碼獲取和閱讀增加一點(diǎn)困難,在加密擴(kuò)展可被攻擊者獲取到時(shí)并不能起到保護(hù)作用。 參考php內(nèi)核剖析 該文章在 2024/7/2 9:25:45 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |