一個抽獎應用的逆向解密全流程 - Android 台灣中文網

偶然見到一個應用內有抽獎的活動（應用具體名稱就不便告知），而且是每天都可以抽。同時抽獎之前也不需要用戶登錄什麼的，但限定了用戶一天（自然天）只能抽獎一次。那麼應用的服務端在用戶沒有登錄的情況下是依據什麼來判定目前用戶今天是否已抽過獎了呢？這當中判斷的依據是否可靠，能否被偽造然後實現一天多次抽獎呢？帶著這些問題，讓我們來剝開應用的層層外紗。

首先在PC端開啟LogCat，然後手機連接PC，最後手機上開啟該應用的抽獎界面。這時我們在LogCat中發現了該應用輸出的如下日誌：

draw_page_url_log.jpg (50.15 KB, 下載次數: 6)

下載附件保存到相冊

2016-3-24 14:01 上傳

裡面有onPageStart並且包含了被載入網頁的url。由此可以得出結論，抽獎頁是用WebView載入網頁實現的。那載入這個WebView的Activity又是什麼呢？

在PC端開啟Android DDMS,在程序列表中找到該應用包對應的程序（如下圖的程序ID為21641），然後查看Activity Manager State。

登錄/註冊後可看大圖

draw_ddms_step.jpg (44.44 KB, 下載次數: 5)

下載附件保存到相冊

2016-3-24 14:01 上傳

這時我們得到的Activity Stack就像這樣。

登錄/註冊後可看大圖

draw_activity_stack.jpg (108.58 KB, 下載次數: 6)

下載附件保存到相冊

2016-3-24 14:01 上傳

由此我們就可以大概知道它Java內部的實現結構是怎樣的了。首先建立的是ActivityToolsExplorer，然後在其中嵌入了一個名為FragmentToolsExplorer的Fragment，最後由FragmentToolsExplorer在onCreate裡實現WebView載入網頁的過程。

順水推舟

由上面我們知道了抽獎頁的Url。好了，我們首先在瀏覽器上開啟這個Url，看看它的抽獎是怎樣一步步實現的。

這個頁面開啟後，在頁面正中間有一個用來作抽獎操作的按鈕，嵌套樣式名為.lucky-btn .lucky-cell-conn。當然在瀏覽器上這個程式是執行不起來的，我們關心的只是開始抽獎這個動作是怎樣發起的。查看源碼開啟main.js。js檔案竟然沒有壓縮，就更方便我們逆向跟蹤了。我們找到對這個按鈕連結點擊事件的位置：

function init(info) {
...
var deviceID=info.deviceId;
checkDrawEnable(drawingObject,deviceID);
$(".lucky-btn .lucky-cell-conn").on("click",function(e){
...
window.setTimeout(function(){
..
getJSONP(BASE_URL+"draw/"+deviceID,function(data){
drawResult(drawingObject,data);
});
},Math.random()*1000+1000);
});
}

複製代碼

ok，在這裡我們就直接發現了，服務端用來判斷用戶當天已抽獎的依據是DeviceId（設備ID）。現在我們需要的是一步步逆向跟蹤，找到是誰調用了init函數並帶入的info參數是怎樣構成的，這樣似乎整個程式邏輯就會變得清晰起來。

這個網頁中bridge對像為java層注入的對象，而腳本中一些初始化訊息也是通過調用java方法獲得的。那麼我們要跟蹤整個代碼流程，就必須對java代碼也進行逆向分析。首先拿到應用的apk包，unzip後使用baksmali將classes.dex解為smali代碼包。結合腳本代碼，對代碼調用層次一步步追蹤，這個過程需要你對smali代碼也比較熟悉。最後得到如下圖所示的調用流程圖（具體追蹤過程就不在這展開）：

登錄/註冊後可看大圖

draw_code_reverse.jpg (79.03 KB, 下載次數: 3)

下載附件保存到相冊

2016-3-24 14:01 上傳

由此，我們就知道deviceId串是主要就由Lcom/xx/util/e;->a(Landroid/content/Context;)Ljava/lang/String;方法負責生成。這個方法中獲取到AndroidID與DeviceId後用」_」符連接。

而Lcom/xx/util/e;->j(Landroid/content/Context;)Ljava/lang/String;就是獲取DeviceId的方法，具體的smali代碼為：

.method public static j(Landroid/content/Context;)Ljava/lang/String;
.registers 2
const-string v0, "phone"
invoke-virtual {p0, v0}, Landroid/content/Context;->getSystemService(Ljava/lang/String;)Ljava/lang/Object;
move-result-object v0
check-cast v0, Landroid/telephony/TelephonyManager;
invoke-virtual {v0}, Landroid/telephony/TelephonyManager;->getDeviceId()Ljava/lang/String;
move-result-object v0
return-object v0
.end method

複製代碼

至此找到獲取DeviceId真正的位置，我們就破案了。

偷梁換柱

上面我們知道了，服務端用來判斷用戶當天已抽獎的依據是DeviceId，同時我們也追蹤到了代碼中獲取DeviceId具體位置。這樣，程式每次獲取DeviceId時我們就可以偽造返回值（每次偽造的結果都不能相同），就實現一天無限次抽獎了。那怎樣偽造這樣的返回值呢，下面的簡單一句Java代碼就可以實現了。

return String.valueOf(System.currentTimeMillis() ^ 537400335373457L);

複製代碼

把上面这句翻译成smali代码后，替换掉j(Landroid/content/Context;)Ljava/lang/String;方法内原来的全部smali代码，偷梁换柱。

.registers 9
invoke-static {}, Ljava/lang/System;->currentTimeMillis()J
move-result-wide v0
const-wide v2, 0x1e8c344179491L
xor-long/2addr v0, v2
invoke-static {v0, v1}, Ljava/lang/String;->valueOf(J)Ljava/lang/String;
move-result-object v0
return-object v0

複製代碼

最後用smali.jar打包回去，簽名後安裝。執行起來後應用在抽獎頁面已經沒有了次數限制。

魔高一尺，道高一丈

學習破解的目的不是為了走更多的捷徑。有個道理大家都知道，最好的防守就是進攻。我們只有瞭解怎樣去破解一個應用，才知道應該如何去加固自己的應用。就比如這個應用中，有下面這些問題可以改進來加大各方面破解的難度：

Debug日誌不應該存在於發佈版本，Error日誌也盡量少暴露敏感訊息。
線上網頁的腳本代碼及樣式應該壓縮，壓縮後可以增加逆向時閱讀及追蹤上的難度。
不能以客戶端上任何固有參數作為服務端上的關鍵憑據，比如這裡的抽獎憑據依賴了客戶端的DeviceID。
Java代碼混淆還是需要的，雖然代碼仍可以被一步步逆向跟蹤，但語義上的隔離會加大追蹤的時間成本。

作者: zxx40414 時間: 2016-3-26 16:51
這種破解如果應用在線上手遊上的話能行嗎

作者: sehg5iu8 時間: 2016-3-27 05:55

zxx40414 發表於 2016-3-26 16:51
這種破解如果應用在線上手遊上的話能行嗎

也試試伺服器有驗證就不可能成功

作者: hale0506 時間: 2016-3-27 08:16
你有成為駭客的能力了，駭谷歌臉書蘋果成功跟它們總部說還有錢拿耶

作者: 混饭吃 時間: 2016-5-5 11:16
厉害，支持！

作者: nts 時間: 2016-5-6 07:59
真厲害，
我們這些連程式碼都看不懂了，何論去追蹤破解........

作者: GFON 時間: 2016-5-8 21:50
本帖最後由 GFON 於 2016-5-9 07:31 編輯

文章出自這裡
請發真正自己的作品比較好哦

歡迎光臨 Android 台灣中文網 (https://apk.tw/)