Android逆向之旅---破解某支付軟體防Xposed等框架Hook功能檢測機制

最近想寫幾個某支付軟體的外掛，大家現在都知道現在外掛大部分都是基於Xposed的hook功能，包括之前寫了很多的某社交軟體的外掛，所以不多說就直接用Jadx開啟支付軟體之後然後找到想要hook的方法，可惜的是遇到這個錯誤：

這個軟體內部做了防止Xposed的hook功能檢測，當我們寫了對應了Xposed模組在開啟app的時候就會出現這樣的錯誤，其實吧這個錯誤網上之前有人寫過分析了，我們可以百度一下：

看到這些搜尋結果了吧，早在去年這個人就寫了這個分析，無獨有偶這個人就在我的編碼美麗小密圈裡，不過更可惜的是，這個方案現在已經不行了。

支付軟體做了另外的防護了，這才是本文的重點，但是不管怎麼樣還是先來回顧和了解一下先看看之前的防護策略吧：

第一、Xposed框架將Hook資訊儲存在欄位fieldCache，methodCache等中， 利用java 反射機制獲取這些資訊，檢測Hook資訊中是否含有支付寶App中敏感的方法，欄位，構造方法

第二、檢測程式中使用so名中包含關鍵"hack|inject|hook|call" 的資訊，這個主要是防止有的人不用這個Xposed框架，而是直接自己寫一個注入功能

第三、root檢測原理是：是否含有su程式和ro.secure是否為1

第四、防止被Hook的方式就是可以檢視XposedBridge這個類，有一個全域性的hook開關，所有有的應用在啟動的時候就用反射把這個值設定成true，這樣Xposed的hook功能就是失效了：

第五、如果應用被Xposed進行hook操作之後，丟擲的異常堆疊資訊中就會包含Xposed字樣，所以可以通過應用自身內部丟擲異常來檢測是否包含Xposed欄位來進行防護：

有的同學會好奇怎麼反射操作呀？因為Xposed的hook原理的就是在程式啟動都注入jar功能，所以安裝hook模組之後，每個應用內部都包含了這個Xposed功能jar，就相當於你的應用中有了Xposed的所有功能類，所以在應用中反射Xposed的類是可以成功的，當然前提是裝置裝了Xposed並且有相應的hook模組！而這些方案已經都是公開的，一些應用為了防止被hook做了很強的安全防護策略，大家感興趣可以去看看"一號店"應用，會發現hook他也是失敗的，並且很難找到相應的檢測機制！

其實除了上面的幾個還有很多策略，我們用Jadx去檢視支付app程式碼也發現他的確有這個功能：

就是在ScanAttack類中進行了很多檢測，這裡就不在截圖一一說明了，那麼我們直接hook這個類，然後把所有檢測都攔截掉不就可以了嗎？可惜的是沒有效果。

所以問題就變成了我們得重新去看看他的檢測邏輯到底在哪？這裡找突破口我們還是去上面的那個提示框，可以全域性搜那個提示資訊，可惜的是沒搜到。這個後面會解釋支付app中的常量字串全部進行加密了，沒法全域性搜尋字串來進行定位。那麼我們還有第二招就是UI介面分析：

這裡我們分析得到了這個對話方塊的大致佈局，找到展示訊息的TextView的id值，這裡我們先不去public.xml中找到對應的int值，可以先去jadx中搜尋R.id.message即可，要是搜不到在去找int值進行搜尋：

幸運的是我們在多個dex中都搜尋到了這個值，而且看上去也是一個對話方塊類，點進去進行檢視：

那麼確定是不是這些對話方塊很簡單，直接hook這些對話方塊的onCreate方法即可，可惜的是全部沒有走到也就是沒有效果，這裡我說的是一些也就是我把搜尋到的對話方塊都hook了一遍都是沒效果的。所以到這裡我們就陷入了沉思，哦不對是我陷入了沉思，這幾天我夜不能寐輾轉反側飯也吃不下水也喝不進去，就在我絕望之際那天我一個人孤獨的走在漆黑的小樹林裡，突然靈機一動想到一個絕妙的思路，那就是不管他是自定義的對話方塊還是用的系統對話方塊。那麼最終都會呼叫對話的show方法，那麼我們就直接乾脆點hook系統的對話方塊方法：

就這麼進行hook系統對話方塊的show方法，然後在內部進行異常丟擲來列印堆疊資訊可以更快的跟蹤程式碼呼叫邏輯，其實執行前心裡沒底因為感覺理論上應該差不多可能或許會成功：

哈哈哈，果然成功了我們定位到了程式碼關鍵點在CI這個類中彈出這個對話方塊的，檢視程式碼：

看到這個類方法之後，發現了一件驚天祕密就是這個支付應用內部為了防止被字串查詢，內部的字串資訊全部用Base64進行編碼，其實這個我在之前也說過了，現在有些應用為了保護自己應用內的常量字串資訊在編譯期做了防護編碼。後面會單獨出一篇文章解析這個操作的，我們可以把一個應用內部的字串常量全部加密。其實網上已經有這種外掛或者工具了，但是沒怎麼說原理。然後這裡我們看到他用的是AlertDialog對話方塊進行展示的，不過AlertDialog對話方塊是繼承Dialog類的，這裡看到為什麼我們hook這個Dialog類的show方法了吧，因為最終呼叫show方法都是呼叫Dialog的show方法。

我們繼續檢視邏輯程式碼，看到有一個按鈕是關閉的，直接看看內部程式碼：

然後看看點選事件：

在這裡就強制退出程式了，那麼到這裡我們繼續來看什麼時候彈出這個對話方塊的呢？我們檢視堆疊資訊：

有一個內部類中的run方法：

然後這裡做了一個判斷邏輯之後開始呼叫展示對話方塊邏輯：

這裡看到他在做檢測邏輯了，這些功能都還是在CI這個類中，其實到這裡有的同學會好奇上面的堆疊方法資訊到run就結束了，也沒看到他呼叫這個檢測方法呀？其實這裡有個遺憾就是沒法繼續跟蹤下去了，因為堆疊資訊斷了，而且我猜想支付應用內部還有什麼判斷邏輯而已。

但是用我們現有的結果完全可以搞定這個提示資訊了，有很多種方法，比如可以不展示這個對話方塊，也可以攔截那個自殺方法，也可以遮蔽對話方塊的點選事件都可以。這裡為了給大家介紹一個技巧就採用遮蔽對話方塊展示邏輯，這裡需要用到Xposed中的一個技術就是如何遮蔽原始方法，需要用到這個回撥介面：XC_MethodReplacement，比如這裡我們遮蔽那個展示對話方塊的a方法：

合理看到如果想遮蔽原始方法直接返回null即可，那如果還是想呼叫原始方法該怎麼辦呢？因為有時候我們可能需要判斷有一些情況需要遮蔽原始方法，有些情況是不需要的，那麼不遮蔽的方法就是直接返回 XposedBridge.invokeOriginalMethod 即可。下面就直接執行這個模組即可。

到這裡我們就解決掉了某支付軟體的方Xposed的hook功能檢測功能了，而在本文中我們得到兩個重要技術：

第一、在你絕望的時候一定要記得獨自一人去小樹林這樣才會迸發出靈感，在本文中軟體加密了字串我們通過id查詢突破口無望的時候，突然靈關閃現去hook系統的對話方塊show方法，因為以後以及現在在你hook無望的時候一定要記住另類思想，對話方塊展示最終都會呼叫系統對話方塊的show方法，那麼我們可以曲線救國去hook這個show方法就可以了，通過列印堆疊資訊更快的定位方法呼叫順序邏輯。

第二、在分析應用的時候發現他內部的常量字串全部都用Base64進行編碼了，這樣破解就很難找到突破口了，而且也發現他的string.xml中沒有幾個字串資訊的。所以這個支付軟體真的做了很多前期防護策略，但是這樣做有個弊端就是效率問題，因為原本只是去常量池中取字串，而這樣弄完之後每次都需要進行解碼字串。更重要的是這樣的混淆編碼一旦被破解了，那麼等於完全沒意義了，因為我們可以hook這個編碼方法：

既然這個方法是Base64編碼的，那麼攔截這個編碼方法列印原始字串資訊即可獲取所有原始沒有編碼的常量字串資訊了，即使不這麼做也可以自己寫一個程式進行編碼然後全域性搜尋這個Base64編碼字串資訊也是可以定位到的。那麼我們後面要做的是介紹如何把應用中的常量字串資訊全部編碼一下，至於什麼編碼加密可以自行定義。

嚴重說明

本文的目的只有一個就是學習逆向分析技巧，如果有人利用本文技術進行非法操作帶來的後果都是操作者自己全部承擔，和本文以及本文作者沒有任何關係，本文涉及到的程式碼可以去編碼美麗小密圈自取，歡迎加入小密圈一起學習探討技術！點選立即進入小密圈

那麼現在再來告訴大家，這個只是個開始，因為只有過了這個檢測，後面我們才好寫各種外掛，至於什麼外掛盡情期待，關注編碼美麗公眾號，放心我不會讓你們失望的，唯獨失望的是你們一定要看懂文章學到東西。

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

http://www.520monkey.com

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

360創始人周鴻禕、CSDN創始人蔣濤、看雪創始人段鋼聯袂推薦！ 點選檢視圖書詳情

長按下面