目錄
App安全檢測實踐基礎——使用者端程式安全
註明:影響範圍 Android所有版本
1、描述
每個Android應用程式想要安裝執行,必須經過簽名.所以開發者在釋出安裝包時,必須對安裝包進行簽名.簽名資訊中包含的組織資訊,將便於使用者識別安裝包的真偽.部分手機防毒軟體也是基於簽名資訊進行查殺的.因此一個完整詳細的簽名資訊,有助於提高使用者分辨真偽安裝包.
2、過程
jarsigner -verify -verbose -certs xxx.apk
檢測發現如下資訊——不符合規定要求。
3、建議
1、描述
Android應用程式是使用Java進行開發,執行於Java虛擬機器器(Dalvik)的應用程式.通過反編譯工具可以很方便地得到Dalvik虛擬機器器所執行的Smali程式碼和Java程式碼.便可對Android應用程式進行分析,修改,重打包.若沒有任何加固保護措施,應用程式的邏輯將完完整整地暴露給分析者.
2、過程
經過檢測發現情況如下:
程式碼沒有經過混淆或者加固,攻擊人員可以通過攻擊反編譯.直接在原始碼層次進行攻擊.
3、建議
1、描述
由於Android系統固有的缺陷,Android應用分發渠道管理機制等問題,導致Android使用者端程式很容易被反編譯篡改/二次打包,經任意簽名後可在各個渠道或論壇中釋出,這不僅損害了開發者的智慧財產權,更可能威脅到使用者的敏感資訊及財產安全,因此對使用者端自身進行完整性校驗尤為必要.
2、過程
apktool d apk
apktool b dir -o out.apk
重簽名apk
如果app沒有對dex或者簽名進行校驗的話,可以隨意修改smali程式碼和資原始檔.比如可以修改圖示.下圖展示了把某證券類應用圖片替換為手電筒應用.
更改之前:
更改之後:
發現變成其他頭像了;還是可以開啟的;
改過之後,進行簽名設定
執行命令:java -jar signapk.jartestkey.x509.pem testkey.pk8 原apk檔名 新apk檔名
安裝APK;
若沒有進行自校驗,則可以正常開啟軟體,則測試不通過,說明存在漏洞風險
若應用進行了自校驗,則無法啟動軟體,測試通過;不存在;
3、建議
1、描述
當在AndroidManifest.xml檔案中設定android:debuggable="true"時,應用程式可以以偵錯模式啟動,並被任意偵錯程式附加偵錯.
2、過程
如果使用者端把android:debuggable屬性設定為true.可以試用adb命令對使用者端進行偵錯,方便進行逆向分析;存在漏洞風險
3、建議
1、描述
當在AndroidManifest.xml檔案中未設定android:allowBackup屬性值或,設定android:allowBackup="true"時,可對應用程式私有目錄下的所有資料進行備份.
2、過程
通過檢測發現AndroidManifest.xml中存在備份的設定為真;
3、建議
1、描述
Android apk中的資源主要分為assets資源和res資源兩類.Assets資源存放在APP的assets目錄下,該類檔案是一些原始檔案,APP打包時並不會對其進行編譯,而是直接打包到APP中,對於這一類資原始檔的存取,應用層程式碼需要通過檔名對其進行存取.Res資源則存放在APP的res目錄下,該類資源在APP打包時大多會被編譯,變成二進位制檔案,並會為每個該類檔案賦予一個resource id.對於該類資源的存取,應用層程式碼則是通過resource id進行存取的.Android apk開發過程中公司大都提倡命名規範化,因此通過檔名稱非常容易理解其含義,這樣有利於開發者理解和維護應用,但是同時也給應用破解者提供了方便,破解者通過這些命名很容易便可找到他們需要的檔案位置,並理解這些檔案的意圖.
2、過程
普通app沒有經過資源保護的res資料夾如下:
經過混淆後的res資料夾如下
還可以通過——隱藏的方式對資原始檔進行保護.經過加固隱藏後的res資料夾
隱藏了一些比較重要的檔案
經過混淆後的res資料夾如下
資料夾中有各種的字尾做混淆:如:.a .iso .d .conf 等
普通app沒有經過資源保護的assets資料夾
如果程式碼經過混淆,或者有加殼措施,不能完整恢復原始碼的,都可以認為此項安 全。
3、建議
參考連結:
https://www.cnblogs.com/ffrs/p/11352485.html
https://blog.csdn.net/ssjjtt1997/article/details/98947034