滲透測試Android 應用程序:工具和分步說明(上)
解決UnCrackable Apps 挑戰我們將向您展示如何解決兩個OWASP MSTG CrackMe 挑戰:Android 級別1 的UnCrackable 應用程序和Android 級別2 的UnCrackable 應用程序。這些應用程序專門設計為逆向工程挑戰,代碼中隱藏著秘密。我們的任務就是找到這些秘密。在解決這些挑戰時,我們將使用靜態分析來分析反編譯代碼,並使用動態分析來修改一些應用程序參數。
解決UnCrackable App for Android Level 1首先,我們需要查看我們的培訓應用程序。一個普通的Android 應用程序實際上是一個正確打包的APK 文件,其中包含應用程序正常運行所需的所有數據。
要從內部審視應用程序並解決這一挑戰,我們需要:
adb 用於與我們的移動設備和培訓應用程序通信
用於將我們的培訓應用程序的APK 文件反彙編為單獨的.smali 類的Apktool
jdb 用於調試我們的訓練應用程序
dex2jar 用於將APK 文件轉換為JAR 格式
用於處理JAR 文件的JD-GUI
現在讓我們繼續解決第一個挑戰。
我們將首先使用以下命令在我們的設備或模擬器上安裝UnCrackable-Level1.apk:
我們將在jdb 工具的幫助下解決這個挑戰並調試Release Android 應用程序。繼續尋找隱藏的秘密。
1. 解壓應用程序並使用Apktool 解碼清單文件:
2. 使用文本編輯器,通過更改清單文件並將應用程序設置為android:debuggable:將應用程序置於調試模式'true':
XML
applicationandroid:allowBackup='true'android:debuggable='true'android:icon='@mipmap/ic_launcher'android:label='@string/app_name'android:theme='@style/AppTheme'3.使用Apktool重新打包APK文件:
4.退出新創建的APK文件。您可以使用bash 腳本來執行此操作以重新註冊Android 應用程序。
5. 使用以下命令在您的設備或模擬器上安裝新的APK 文件:
此時,我們面臨第一個大挑戰。 UnCrackable App 旨在抵抗調試模式。因此,當我們啟用它時,應用程序會簡單地關閉。
您將看到帶有警告的模態對話框。可以通過點擊確定關閉對話框,但這將是應用程序終止前的最後一個操作。
滲透測試android 1
幸運的是,有一種方法可以解決這個問題。
6. 在等待調試器模式下在您的設備或模擬器上啟動應用程序。此模式允許您在應用程序運行其檢測機制之前將調試器連接到目標應用程序。因此,應用程序不會停用調試模式。
使用以下命令在等待調試器模式下運行應用程序:
您將看到以下對話窗口:
滲透測試android 2
7. 現在顯示連接設備上運行的所有進程的進程ID (PID):
8. 並且只列出可調試的進程:
9. 在您的主機上打開一個監聽套接字並將其傳入的TCP 連接轉發到所選可調試進程的JDWP 傳輸:
10. 請注意,附加調試器(在我們的例子中是jdb)將導致應用程序從掛起狀態恢復,我們不希望這樣。我們需要暫停該應用程序一段時間以對其進行詳細探索。為防止進程恢復,將suspend命令通過管道傳輸到jdb:
11. 現在我們需要繞過點擊確定後應用程序在運行時崩潰的那一刻。使用dex2jar 和JD-GUI 反編譯APK 文件以查看應用程序代碼:
1)使用dex2jar工具將原始APK文件轉為JAR文件:
2)使用JD-GUI工具,打開新建的JAR文件:
查看代碼後,您會看到MainActivity.a方法顯示消息:
'This is unacceptable.'
MainActivity.a方法創建一個警告對話框並為onClick 事件設置一個偵聽器類。偵聽器類有一個回調方法,當用戶點擊OK 按鈕時,該方法會關閉應用程序。為防止用戶取消對話框,系統調用setCancelable方法。
在這一點上,我們最好的情況是將應用程序暫停在我們正在尋找的秘密字符串存儲在明文變量中的狀態。不幸的是,除非您能弄清楚應用程序如何檢測root 和篡改,否則這是不可能的。
12. 嘗試稍微修改運行時以繞過應用程序終止。 android.app.Dialog.setCancelable在應用程序仍處於暫停狀態時設置方法斷點,然後恢復應用程序:
13. 應用程序在第一個setCancelable方法指令處暫停。您可以使用該locals命令打印傳遞給setCancelable方法的參數:
正如您在上面的代碼中看到的,系統調用了setCancelable(true)方法,所以這不是我們需要的調用。讓我們用resume命令恢復這個過程:
我們已經通過參數調用了setCancelablefalse方法。此時,我們需要使用set命令將變量更改為true並恢復應用程序:
每次到達斷點時繼續設置,flag直到最終顯示警報窗口。 true您可能需要嘗試五六次才能看到此窗口。此時,您應該能夠在不導致應用程序終止的情況下取消應用程序——只需點擊對話框窗口旁邊的屏幕,它就會關閉。
滲透測試android 3
14. 最後,是提取秘密字符串的時候了。再次查看應用程序代碼。您會注意到我們正在尋找的字符串是使用高級加密標準解密的,並與用戶在消息框中輸入的字符串進行比較。應用程序使用java.lang.String類的equals方法來確定字符串輸入是否與秘密字符串匹配。
現在在java.lang.String.equals上設置一個方法斷點,在編輯字段中輸入隨機文本,然後點擊VERIFY。 locals到達斷點後,您可以使用命令讀取方法參數:
答對了!我們的秘訣是“我想相信”。您可以通過在消息框中輸入此短語並單擊“驗證”按鈕來輕鬆檢查是否正確。
滲透測試android 4
做得好!現在我們可以開始解決第二個挑戰了。
解決UnCrackable App for Android Level 2與之前的任務一樣,在這個訓練應用程序的代碼中某處隱藏著一個秘密字符串,我們的目標是找到它。然而,在這種情況下,我們的秘密字符串可能有一些本地代碼的痕跡。
為了解決這個挑戰,我們將使用以下工具:
adb 用於與我們的移動設備通信
用於反彙編APK 文件的Apktool
用於處理庫的切割器
gbd 用於分析應用程序代碼
用於編輯二進制數據的Hex Workshop Editor
dex2jar 用於將APK 文件轉換為JAR 格式
用於處理JAR 文件的JD-GUI
讓我們直接解決這個挑戰:
1.使用dex2jar和JD-GUI,分析UnCrackable-Level2.apk文件。
1)首先,使用dex2jar將APK文件轉換為JAR文件:
2) 然後用JD-GUI打開轉換後的文件。從MainActivity類開始:
系統加載本機foo 庫。然後我們在MainActivity類的onInit方法中調用原生的init函數。
接下來,CodeCheck類從bar 庫中導入一個函數:
CodeCheck的一個方法(很可能被混淆了)使用這個函數來驗證密碼。
2.使用Apktool提取foo庫,然後用Cutter反編譯成機器碼:
在temp/lib 文件夾中,查找擴展名為.so 的文件。應該有針對不同類型處理器架構的文件:arm64-v8a、armeabi-v7a、x86 和x86_64。選擇與您正在使用的設備或模擬器的處理器架構相匹配的庫。您可以使用CPU-Z應用程序檢查設備的架構。
使用Cutter 分析所選庫。首先檢查功能選項卡以了解庫的功能。
例如:
pthread_create和pthread_exit函數表明函數庫使用線程。
滲透測試android 5
如果您看到strncmp字符串比較器,它可能用於驗證傳遞的密碼。如果幸運的話,我們正在尋找的字符串是硬編碼的,輸入的密碼會與它進行比較。然而,根據線程的使用判斷,我們可以假設庫在運行時計算秘密字符串。
滲透測試android 6
我們來分析一下strncmp函數。使用Cutter 找到strncmp函數的地址(0xffb)。
滲透測試android 7
ptrace是用於調試的Linux 系統調用。然而,在我們的例子中,它被用作一種反調試技術。
滲透測試android 8
讓我們分析一下ptrace的功能。這個調用被使用了兩次:第一次是在0x777,然後是0x7a7。在第一種情況下,它是當前進程的PID,在第二種情況下,它是PTRACE_ATTACH 標誌,0x10。
ptrace函數調用將一個Android 進程附加到自身。但是,一個Android 進程只能附加一個進程。這意味著目前我們無法將gdb 附加到Android 進程。
滲透測試android 9
3. 附加gdb 的問題可以通過NOP-ing 兩個ptrace 系統調用來解決。您可以使用Hex Workshop Editor 更改字節。將ptrace函數的地址插入工具的轉到字段並更改值:
滲透測試android 10
4. 打開原始APK 文件作為zip 存檔並將原始libfoo.so 庫替換為更改後的庫。
5. 使用與上一個挑戰相同的腳本退出修改後的APK 文件。
6. 在root 設備上安裝應用程序:
現在,當您啟動該應用程序時,您會看到一條警告,提示您無法使用該應用程序,因為設備已獲得root 權限。
滲透測試android 11
7.從應用程序代碼中刪除root 和調試器檢測。為此,請在反編譯的APK 文件中找到MainActivity.smali 文件並刪除a方法的所有內容。
當檢測到問題時調用a方法。它向用戶顯示一個警告對話框,然後退出應用程序。為了防止我們的應用程序出現此類行為,我們需要修補a方法。
這是刪除a方法內容後MainActivity.smali 文件的樣子:
8. 現在用修改後的MainActivity.smali文件重新打包APK 文件:
9. 接下來,打開UnCrackable-Level2_resigned.apk 文件作為ZIP 存檔,並將其中的classes.dex 文件替換為我們重新打包的APK 文件中的補丁文件。
10. 退出初始的UnCrackable-Level2.apk 文件。在這一步,我們的APK 文件有兩個替換的補丁文件:來自第8 步的MainActivity.smali 和來自第4 步的libfoo.so。
11. 在您的設備上安裝重新安裝的APK 文件:
這一次,我們的應用程序啟動時沒有任何警告消息。
滲透測試android 12
接下來,我們需要將gdb 附加到Android 進程。首先在您的設備或模擬器上設置gdb 服務器。
12. 在您的設備上打開root shell:
13. 使用計算機上的命令行界面,將gdb 服務器複製到/data/local/tmp/gdb-server 文件夾中:
Recommended Comments