午啪啪夜福利无码亚洲,亚洲欧美suv精品,欧洲尺码日本尺码专线美国,老狼影院成年女人大片

1、梆梆加固方案分析和破解 -論梆梆安全加固的不可靠一、梆梆安全加固方案技術(shù)分析2（1）APK包文獻(xiàn)特性2（2）dex文獻(xiàn)分析3（3）SO文獻(xiàn)分析3二、梆梆安全加固破解9一、梆梆安全加固方案技術(shù)分析樣例分析環(huán)境：APK包：齊魯銀行運(yùn)營(yíng)環(huán)境：安卓模擬器4.4.2CPU平臺(tái)：ARM平臺(tái)，（X86暫不分析）分析工具：JEB，APKIDE，IDA 6.6及HEX編輯工具等（1）APK包文獻(xiàn)特性圖1 齊魯銀行apk文獻(xiàn)結(jié)構(gòu)圖1可見(jiàn)classes.dex文獻(xiàn)極小。非應(yīng)用真正的dex文獻(xiàn)。圖2 assets/文獻(xiàn)目錄梆梆把SO文獻(xiàn)都放在assets中。圖2中比較重要文獻(xiàn)有：，4個(gè)so文獻(xiàn)以及一個(gè)jar文獻(xiàn)。（22、）dex文獻(xiàn)分析圖3 dex結(jié)構(gòu)代碼中能看到的so調(diào)用有2處：ACall中的libsecexe.so，以及ApplicationWrapper中的libDexHelper.so。初步總結(jié)：根據(jù)apk包文獻(xiàn)結(jié)構(gòu)以及dex逆向中可見(jiàn)的調(diào)用關(guān)系，大約可推斷出梆梆整體的保護(hù)策略：多層次，明暗集合。（3）SO文獻(xiàn)分析開(kāi)始具體分析梆梆的SO文獻(xiàn)。根據(jù)上面幾個(gè)方面的觀測(cè)，梆梆具有4個(gè)so文獻(xiàn)。2個(gè)為顯式調(diào)用，2個(gè)為隱式調(diào)用（調(diào)用代碼隱藏在so中）。1）四個(gè)so互相調(diào)用關(guān)系：本人的初步研究：一方面，Dex中的ACall調(diào)用libsecexe.so ，另一方面，調(diào)用libsecmain.so, 再次，Dex中的3、ApplicationWrapper調(diào)用libDexHelper.so，最后， libsecperload.so這個(gè)so文獻(xiàn)很奇怪，仿佛并沒(méi)有被調(diào)用過(guò)。2）四個(gè)so各自特性具體分析：* libsecexe.so文獻(xiàn)大小81KB，破壞參數(shù)ELF中的section節(jié)表信息，采用加殼保護(hù)-變種UPX殼（無(wú)法使用工具直接脫殼），函數(shù)和變量名都加入混淆解決。圖4僅存在段表，upx加殼(elf文獻(xiàn))特有段表結(jié)構(gòu)圖6功能性函數(shù)和變量名混淆圖7 so入口函數(shù)變形，ida無(wú)法辨認(rèn)圖8JNI_OnLoad函數(shù)加密字節(jié)特殊解決綜上所見(jiàn)：該SO文獻(xiàn)反映了梆梆加固機(jī)制的大量技術(shù)信息。但其核心技術(shù)只是國(guó)外開(kāi)源的UPX殼。4、在本文的最后會(huì)針對(duì)UPX殼逆向分析的情況進(jìn)行一些細(xì)節(jié)說(shuō)明。通過(guò)技術(shù)手段進(jìn)行手工脫殼，并dump出so 在內(nèi)存中的map并轉(zhuǎn)存二進(jìn)制文獻(xiàn)。因Dump出的二進(jìn)制文獻(xiàn)，自身無(wú)法修復(fù)elf段表和節(jié)表（手工修復(fù)工作量大），所以在分析過(guò)程中，結(jié)合了runtime動(dòng)態(tài)調(diào)試內(nèi)存技術(shù)。圖9-1 脫殼前的so在內(nèi)存中段布局圖9-2脫殼后的so在內(nèi)存中的段布局由于UPX為壓縮殼，所以原加載入內(nèi)存的elf各分段被動(dòng)態(tài)解壓到內(nèi)存中，如LOAD段下方的debug002實(shí)為L(zhǎng)OAD段解壓還原后的代碼及數(shù)據(jù)信息。其他各段類似。此處也可看出無(wú)法dump出完整elf的因素了。Upx解壓時(shí)，并沒(méi)有還原section和segment5、，實(shí)際也沒(méi)這個(gè)必要。圖10 相對(duì)圖7這才是真正的so入口點(diǎn).init_proc源碼，即upx脫殼代碼圖11 相對(duì)圖8這是解壓還原后的JNI_OnLoad函數(shù)（深藍(lán)色的函數(shù)名都是本人的分析標(biāo)注）圖12 JNI_OnLoad的一個(gè)sub函數(shù)至此libsecexe.so的啟動(dòng)代碼部分大約流程解析出來(lái)。其中功能性函數(shù)與dex有關(guān)的很多。本人搜索了一些關(guān)鍵詞。發(fā)現(xiàn)前面提到的一個(gè)bangcleclasses.jar這個(gè)jar包也在該so中解決。總結(jié)：該so的特點(diǎn)，加殼，名稱混淆，但未混淆函數(shù)實(shí)現(xiàn)。獲得dex修復(fù)功能，與classes.dex和bangcleclasses.jar通訊交互調(diào)用了一些功能函數(shù)。6、*libsecmain.so第二個(gè)核心so文獻(xiàn)。根據(jù)對(duì)libsecexe.so的研究。Libsecmain屬于隱式被調(diào)用者，調(diào)用者很也許就是classess.jar這個(gè)jar文獻(xiàn)（本人猜測(cè)）。文獻(xiàn)大小157KB，破壞ELF中的section節(jié)表信息，采用加殼保護(hù)-變種UPX殼（無(wú)法使用工具直接脫殼），函數(shù)和變量名都加入混淆解決。雖然本so與libsecexe.so的保護(hù)方式幾乎同樣（采用同樣技術(shù)的反復(fù)的圖就不截了）。初步分析后，發(fā)現(xiàn)它仍然有一些自己的獨(dú)特之處。（1） 無(wú)JNI_load函數(shù)，說(shuō)明該so 為純被調(diào)用者。被java或其他so調(diào)用。自身不會(huì)去積極調(diào)用java相關(guān)代碼，如：jar包，d7、ex文獻(xiàn)等。（2） 新增混淆IDA解析能力，偽造了一批函數(shù)。比如：把入口函數(shù).init_proc的代碼放在另一個(gè)函數(shù)內(nèi)部（對(duì)于elf文獻(xiàn)來(lái)說(shuō)關(guān)心的定位并不受影響，程序仍可以對(duì)的執(zhí)行）。且此類保護(hù)技術(shù)在該so中很多。本人尚未進(jìn)行更進(jìn)一步的研究。圖13可見(jiàn)B6EAA000是真正的入口點(diǎn)，由于隱藏在另一個(gè)函數(shù)內(nèi)，IDA無(wú)法按照單一獨(dú)立函數(shù)進(jìn)行解析（且母函數(shù)自身也不一定合法），導(dǎo)致解析能力明顯偏弱, 很多東西無(wú)法對(duì)的解析，靜態(tài)環(huán)境就需要手動(dòng)修復(fù)（關(guān)鍵是要重置函數(shù)上下界）。只要能動(dòng)態(tài)調(diào)試起來(lái)影響到是不太大。（3） 觀測(cè)該so中未混淆的函數(shù)so_main(dlopen打開(kāi)libdvm.so和libc.so8、 ,通過(guò)dlsym獲取多個(gè)進(jìn)程操作函數(shù)fork, ptrace, wait, kill, mprotect, waitpid，雙進(jìn)程反調(diào)試功能就在該so中，getpid)，該函數(shù)執(zhí)行結(jié)束后，進(jìn)程列表中將會(huì)有2個(gè).rytong.bankql.ql。mykill,init,libc_pread64 等。解決過(guò)程中多次申請(qǐng)動(dòng)態(tài)堆內(nèi)存，其目的還需進(jìn)一步研究。（4） 觀測(cè)了一些混淆的函數(shù)發(fā)現(xiàn)該so中有不少open 和fopen操作，可見(jiàn)有進(jìn)行讀寫文獻(xiàn)。綜上所述：該so的功能大約有2方面：1. 啟動(dòng)多進(jìn)程反調(diào)試保護(hù)，2.文獻(xiàn)恢復(fù)（極也許是生成classes.dex文獻(xiàn)，當(dāng)然生成一個(gè)半成品的dex文獻(xiàn)），由9、于時(shí)間問(wèn)題暫時(shí)動(dòng)態(tài)調(diào)試只進(jìn)行到多進(jìn)程保護(hù)部分就被卡住，后續(xù)準(zhǔn)備細(xì)致研究后后把多進(jìn)程防護(hù)功能關(guān)閉后，再繼續(xù)往下調(diào)試，以便獲得更多的信息。*libDexHelper.so文獻(xiàn)大小458KB，很明顯該so的核心功能就是修復(fù)dex文獻(xiàn)。libDexHelper.so啟動(dòng)前的內(nèi)存系統(tǒng)和文獻(xiàn)系統(tǒng)實(shí)時(shí)情況：圖14 內(nèi)存中進(jìn)程情況，可見(jiàn)，1197為核心進(jìn)程，1199為反調(diào)試子進(jìn)程圖15 執(zhí)行文獻(xiàn)夾內(nèi)的多了一個(gè)720KB的classes.dex顯而易見(jiàn)，通過(guò)classes.dex(24kb), classes.des, libsecexe.so, bangcle_classes.jar, classes.jar10、, 以及l(fā)ibsecmain.so等幾個(gè)模塊的前期解決，生成了一個(gè)待修復(fù)模版型的classes.dex（720kb）。通過(guò)測(cè)試，該classes.dex為非法不完整的dex文獻(xiàn)。到此classes.dex(24kb)中的ApplicationWrapper去加載libDexHelper.so進(jìn)行運(yùn)營(yíng)時(shí)修復(fù)classes.dex（720kb）。該so的特點(diǎn)：1 未加殼2 未破壞elf文獻(xiàn)segment和section表3 入口點(diǎn)為start函數(shù)（未加密，存放在自定義代碼段seg011中，大量code也在該段中）*libsecpreload.so文獻(xiàn)大小14KB，極小型。該so的特點(diǎn)：1 內(nèi)部?jī)H111、個(gè)函數(shù)：strlen, 感覺(jué)函數(shù)名與函數(shù)功能無(wú)關(guān)2 無(wú)JNI_onLoad函數(shù)3 未加殼4 未混淆圖17 strlen函數(shù)代碼Strlen函數(shù)一共就這幾行代碼。函數(shù)功能也極其簡(jiǎn)樸，從系統(tǒng)環(huán)境變量LD_PRELOAD_SECSO中獲取某個(gè)so庫(kù)名并dlopen打開(kāi)，在用dlsym獲取so庫(kù)中函數(shù)名為”p88c9ad42163050e20f808e0fdeb7988的函數(shù)指針，再?gòu)南到y(tǒng)環(huán)境變量LD_PRELOAD_ARGS中獲取函數(shù)相關(guān)參數(shù)信息，最終調(diào)用p88c9ad42163050e20f808e0fdeb7988函數(shù)。至此上面就是，梆梆加固保護(hù)機(jī)制分析結(jié)果。二、梆梆安全加固破解使用自主開(kāi)發(fā)的脫殼工具對(duì)梆梆加固的某銀行級(jí)別的應(yīng)用進(jìn)行脫殼。一方面在手機(jī)上安裝該銀行apk，然后運(yùn)營(yíng)apk。使用動(dòng)態(tài)脫殼工具指令進(jìn)行脫殼。會(huì)在/data/下面生成脫殼之后的smali文獻(xiàn)，截取部分內(nèi)容如下：通過(guò)我們解密解決之后，就會(huì)生成完整的smali代碼；在通過(guò)一定的解決之后，我們可以直接看到j(luò)ava代碼，證明經(jīng)該廠商加固后的應(yīng)用被完全破解。總的來(lái)說(shuō)，梆梆安全加固的安全加固方案還是基于國(guó)外的一些開(kāi)源項(xiàng)目，保護(hù)效果有限且所有被保護(hù)的應(yīng)用均能通過(guò)同樣的方式容易破解，相應(yīng)用的兼容性性能也有明顯的不良影響。