不定期更新逆向的練習

0x01

拿到題先在模擬器上看一下。

JEB先進行Java層的逆向

看了一下compareTo方法，居然直接用明文進行比較。

輸入密碼就得到了結果

第一題沒想到這麼簡答，就當簽到題了。

0x02

拿到題先在模擬器上看一下，知道了程序的大致構成。

在JEB中進行分析，可以得出載入了plokm這個so文件，a按鈕負責驗證，要去b類里看看。

b類中存放著驗證的邏輯，我們只關心驗證成功的部分。調用了一個ID為2131034119的資源，還有一個getpl方法。

通過Java層ID找到字元串，將ID轉換為十六進位，在public.xml找到name，然後在string.xml中找到字元串。

確定用戶名之後我們再來確定密碼，看一下這個getpl方法，聲明了一個native方法，我們知道了載入的so文件和native方法，嘗試進行靜態分析so。

在導出表中找到方法，進入之後F5看一下，再還原一下JNI方法名，可以看到裡面的getpl方法很關鍵。

進去看一下，是個驗證方法，核心邏輯在下面，用j_strlen獲取長度，判斷字元串長度是否為39，再用j_strncmp進行比較，然後返回驗證結果。現在我們的目標有兩個，第一是跳過字元串長度的驗證，第二是得到v17的值。

先實現第一個目標，看一下native方法的彙編代碼，進入裡面的關鍵方法，切換一下流程視圖，根據判斷的流程和所用得到的函數找到驗證的那部分邏輯。

在切成彙編視圖，看看地址。與十六進位視圖同步之後打開看看，BNE對應的相反邏輯是BEQ，根據arm的操作碼BNE對應的是D1，而BEQ對應的是D0。我們知道了地址和要改的內容之後，在winHex中改一下保存，之後重新簽名一下就行。

第一個目標實現之後我們再來實現第二個目標，我們希望模擬程序運行，通過對內存進行監控得到這個值，所以要進行動態調試。準備開始調試前我們在計算一下方法的絕對地址。之後在跳轉過去。並在方法的第一條指令下斷點，運行過去。因為用戶名的判斷在前，所以我們必須要在輸入正確的用戶名的前提下才可以運行到我們的斷點處。

同時我們進入native方法的驗證方法中，在走過驗證方法中的判斷邏輯。

因為是函數的第一個參數，所以查看R0中的值，跳到對應的內存地址，就能看到我們要求的flag，保存下來即可。

SSCTF{oty3eaP$g986iwhw32j%OJ)g0o7J.CG:}

一個中規中矩的逆向題，只是要求逆向能力全面Java層native都要玩得轉，並沒有多深。

0x03

模擬器走一波，目的很明確要密碼。

JEB看一下，從彈窗、字元串入手。

確定ID之後找到代碼中具體調用的位置。

點擊這個方法，發現在這部分被調用，很明顯這部分負責判斷，要關注v4和v2。

繼續往上面找這兩個寄存器，分析一下基本就是v3得到我們輸入的值，v5和v4得到一個值，v2等於v5和v3傳入函數的返回值，過程中還有三個log。

居然自己有log那就省得我們注入了，adb logcat看一下，我們要讓enPassword等於pw。

看一下加密函數，就是對輸入進行操作之後找到table中對應的值。

輸入0-9測試一下，發現結果和pw對應。

密碼就出來了，581026，Java層要活用log和注入，沒必要硬去算演算法，讓結果自己吐出來。

推薦閱讀：

相关文章