APK在PC上面就被看作一個壓縮格式文件,在手機上面它就算一個可執行格式文件。兩種格式對它的讀取要求也有區別,所以說利用這個區別來實現偽加密。對PC端來講偽加密的APK沒法被解包無法被反編譯,但是對android系統來說它完全不會影響正常的安裝運行(對4.2以前的系統)。
偽加密的原理:讀取APK的位元組,找到連續4位位元組標記為」PK0102」的後第5位位元組,如果是0表示不加密,如果是1就表示加密(偽加密就強行改成1反偽加密就是把1改成0就可以了)。
偽加密前和偽加密後的對比圖如下:
偽加密前:
2. app加密,app可以加密嗎app加密是什麼技術
可以加密。先來說一下一些常用的加密方法:
偽加密
偽加密是Android4.2.x系統發布前的加密方式之一,通過java代碼對APK(壓縮文件)進行偽加密,其修改原理是修改連續4位位元組標記為」P K 01 02」的後第5位位元組,奇數表示不加密偶數表示加密。
雖然偽加密可以起到一定防破解作用,但也會出現問題,首先使用偽加密對其APK加密後市場無法對其進行安全檢測,導致部分市場會拒絕這類APK上傳;其次,偽加密的加密方式和解密方式也早已公布導致它的安全程度也大大降低;再次,Android4.2.x系統無法安裝偽加密的APK;最後偽加密只是對APK做簡單保護,在java層源碼加殼保護、核心so庫、資源文件、主配文件、第三方架包方面卻沒有任何保護處理。注意:高版本不支持這樣的方法,所以還是不要嘗試使用這樣的加密方式了。
混淆保護
把原來有具體含義的類名,變數名,方法名,修改成讓人看不懂的名字,例如方法名getUserName編程了方法名
破解:耐心
運行時驗證
運行時驗證,主要是指在代碼啟動的時候本地獲取簽名信息然後對簽名信息進行檢驗來判斷自己的應用是否是正版,如果簽名信息不是正版則提示盜版或者直接崩潰。當然你可以把必要的數據放在伺服器端。
破解:找到smali文件中,判斷是否相等的部分。改為常量true,即失效。
總之,反編譯一些apk之後,只要是java代碼寫的總會有smil文件。對於smil文件,如果耐心讀的話,還是可以查看到一些關鍵代碼的。
相較於應用來說,游戲apk因為採用cocos2d-x 或者 unity3D,採用的是c++ 和c# 編寫的跨平台程序,在apk採用JNI的方式。所以沒有smali,可以防止靜態被破解apk包。
當然游戲包apk 在運行的時候,會把.*so載入到內存中。動態也是可以在內存中抓取相應的數據。只不NDK 相對於smali破解來說,根部不是一個層級的關系。
3. ROM簽名加密問題
這是一種對zip頭部進行偽加密方法,在Windows下提示需要解壓密碼,在手機上面可以正常使用,zip和apk全部可以做偽加密處理,下載附件使用下面命令,解密命令java -jar ZipCenOp.jar r xxxx.zip或xxxx.apk,加密命令java -jar ZipCenOp.jar e xxxx.zip或xxxx.apk,解密或加密後的文件會覆蓋原文件