感謝「一塊硬幣」同學投稿，也熱烈歡迎其他同學來投稿，分析是一種快樂，也是一種精神！

今日偶然看到一個還算熱門的遊戲，看到裡面有內購的方法。嘗試破解一下

1、拖入AK後重打包，一切順利安裝到手機上後發現黑屏了

2、然後安裝原版測試下，正常執行，那排除手機適配問題，應該就是有驗證了

3、既然這樣那我們為了確定到底驗證的哪裡，先只簽名測試下，重新安裝下，安裝手機後還是黑屏。到這裡我猜測十有八九是簽名驗證了

4、祭出四哥的工具，kstools拿出來一頓操作，然後自信滿滿的再次安裝到手機上。發現還是黑屏，這就尷尬了，看來應該不僅僅是簽名驗證了。這時候沒什麼捷徑可走了進程式碼分析吧

5、遊戲包太大，使用jadx單獨開啟dex檔案

6、然後使用Android Killer開啟apk。找到入口類後在jadx中開啟

這個類通過類名不難看出只是一個閃屏，我們要分析的應該不在這裡，所以不用太關注，大致看下程式碼就行

在oncreate最後執行了這個方法，看來是跳到了

定位到SplashScreen類中

看起來也是一個閃屏，但是裡面有一些初始化和載入so的操作，進入到MobileAuth.init(this);發現走進了這個native方法裡。

暫時先不管他了，繼續往下一個activity看。也就是OnyxActivity類；先看onCreate方法中：

也沒有什麼可以一看看出來的驗證方法。懵逼，因為遊戲並沒有閃退，只是黑屏，看異常看不出有哪裡出了問題，所以我在這些方法下面插入log，看執行到哪一個時候卡住了。

為了防止暫存器使用亂掉出錯，這裡直接在原來基礎上+2，增加兩個暫存器，增加自己的log程式碼

然後再次打包執行，發現卡在了10之後，11沒有被打印出來，而且前面的日誌重複輸出，說明一直迴圈卡死了。

invoke-virtual {v2, p0},Lcom/ubisoft/OnyxEngine/OurpalmChannel;->Init(Landroid/app/Activity;)V

進到這個方法看看

看著像是廣告和支付的初始化，這個方法裡有兩處初始化地方，在這兩處加完log資訊後發現卡在了

Ourpalm_Entry.getInstance(mActivity).Ourpalm_Init("2","1.0", "1.0", mListener);

進去之後我的內心是崩潰的，這麼多程式碼看的我頭大，真的不想再一個個列印了，還好猛地看到了RunSign這個jni方法，熟悉的味道，先看看這個方法

就是他

開啟IDA拖入so，方法在libourpalm_sdk_a.so內

到這兒幾乎一目瞭然了，是做了dex+簽名的效驗

在checksign這個函式內也發現了退出遊戲的程式碼位置，既然這樣我們直接選擇簡單的操作方式給兩個跳轉nop掉。

把上面的兩條改為：C0 46（也就是NOP）

改完後，再次重簽名，安裝，完美執行。

接下來定位支付位置：其實剛剛分析程式碼時候已經大致看到支付位置了。為了確定還是分析下。剛剛分析到OurpalmChannel類時候，可以看到這裡他自定義了一個 ourpalm.tools.android.logs.Logs類

點進去看下

這裡我們把isShowLog的賦值改下

這裡初始化時賦值改為true，再次打包運行遊戲，點選支付，成功列印日誌：

支付頁面，我們沒登入

log日誌頁面

下面這個pay方法也是這個類中

這就對上了，說明是這個支付方法。寫過支付的人應該都知道，支付的回撥一般在handler或者提供的介面中，這裡可以看出來他傳入了mListener這個回撥介面，我們看下這個介面初始化的地方

點進去OurpalmIAPListener中看下

這裡就能看到支付成功的位置了，就是

OurpalmChannel.PayResultCallBackNative(true);

和上面的支付失敗也就是true/false的區別。至於為什麼不是下面的那一堆。我看了下方法內部走到最後是一些統計的東西。然後我們在執行pay的那裡，執行這個成功方法就行了。

再次打包執行。點選購買，成功獲得

嚴重說明

本文的目的只有一個就是學習逆向分析技巧，如果有人利用本文技術進行非法操作帶來的後果都是操作者自己承擔，和本文以及本文作者沒有任何關係，本文涉及到的程式碼專案可以去編碼美麗小密圈自取，長按下方二維碼加入小密圈和作者一起學習探討技術

手機檢視文章不方便，可以網頁看

http://www.520monkey.com

《Android應用安全防護和逆向分析》

長按下面