移動安全之修改加密帶sig簽名的APP資料包
阿新 • • 發佈：2019-02-06
現在越來越多的app應用都採取了加sig簽名的方法來防止自身的資料包在傳輸中被修改所以有時要測一個APP是否有邏輯問題,有時可能會變得棘手.因為每個APP的實現的sig演算法都不盡相同,要想成功的修改資料包再重新簽名,你可能會要先反編譯它,然後在找到sig演算法,有時可能運氣好sig的演算法就寫在java程式碼裡,那就很容易的可以直接利用或還原成其他語言,但一般sig都會寫到so檔案,arm的彙編程式碼相信很多人都看不下去.先不談加固的情況,像一些安全性要求較高的app,一般都會有檢查apk自身簽名,並在執行時傳送到伺服器做校驗,一旦簽名不一致就直接退出,在這種情況下如果app採用隨機key或者非對稱加密來加密資料,就算知曉加密的過程,在不能修改app的情況下,是無法解密出加密的資料.那麼有沒有其他的方便便一些的方法來實現改包呢,先來說說我的一些思路.
其實要想減少工作量,主要就是在於分析演算法,那麼有什麼方法可以減少分析演算法或者直接略過演算法分析的過程了,想到的就是通過HOOK注入.
我說一下簡單流程:
首先抓包分析下資料,然後反編譯dex檔案找到呼叫sig函式的函式(有點繞)hook之,在其被呼叫前將其引數(一般就是要修改的明文資料)通過socket轉發出來,然後本地修改完之後再發送回去,最後hook程式將引數重新賦值.
我這裡以手機裡某(han)某(ting)酒店APP來舉個例子:
1.首先通過抓包簡單分析下資料包
其實原理很簡單,簡單說下,只要呼叫findAndHookMethod方法寫入需要hook的函式名注意引數不要寫錯,然後在beforeHookedMethod中取得要引數(即要修改的明文資料包)將其傳入新的子執行緒中,主執行緒會一直等待(主介面會暫時定住),子執行緒會將資料轉發到pc機的指定埠,可以用nc監聽,修改完再發送,主執行緒會一直等待到pc返回了資料,最後將引數重新賦值
先安裝寫好的外掛
截獲下登陸的資料包
截獲成功修改後直接傳送就可以了
這種改包方式有個好處就是可以不要考慮傳輸方式是什麼,因為已經在傳輸前改完了包.
還有個思路說下,就是hook目標程式然後向裡面注入一個HttpServer,然後本機將通過代理截獲的資料修改重新發送到目標程式利用反射的方式呼叫加解密函式,這樣有個好處就是可以截獲並重組完整的資料包.
其實要想減少工作量,主要就是在於分析演算法,那麼有什麼方法可以減少分析演算法或者直接略過演算法分析的過程了,想到的就是通過HOOK注入.
我說一下簡單流程:
首先抓包分析下資料,然後反編譯dex檔案找到呼叫sig函式的函式(有點繞)hook之,在其被呼叫前將其引數(一般就是要修改的明文資料)通過socket轉發出來,然後本地修改完之後再發送回去,最後hook程式將引數重新賦值.
我這裡以手機裡某(han)某(ting)酒店APP來舉個例子:
1.首先通過抓包簡單分析下資料包
通過截獲的資料來看資料包已經被加密而且加了簽名
2.接下來就是解壓apk包,反編譯裡面dex檔案,開啟一看有兩個,不管先反編譯了先,然後通過資料包裡的特徵值快速定位到呼叫sig演算法的函式檔案,目測就是它了com.htinns.biz.HttpUtils.packParams
hook它應該就可以了
3.既然找到了函式那接下就是hook了,這裡就用比較出名的xposed神器來試試(具體用法可以自己網上搜索 )其實原理很簡單,簡單說下,只要呼叫findAndHookMethod方法寫入需要hook的函式名注意引數不要寫錯,然後在beforeHookedMethod中取得要引數(即要修改的明文資料包)將其傳入新的子執行緒中,主執行緒會一直等待(主介面會暫時定住),子執行緒會將資料轉發到pc機的指定埠,可以用nc監聽,修改完再發送,主執行緒會一直等待到pc返回了資料,最後將引數重新賦值
先安裝寫好的外掛
截獲下登陸的資料包
截獲成功修改後直接傳送就可以了
這種改包方式有個好處就是可以不要考慮傳輸方式是什麼,因為已經在傳輸前改完了包.
還有個思路說下,就是hook目標程式然後向裡面注入一個HttpServer,然後本機將通過代理截獲的資料修改重新發送到目標程式利用反射的方式呼叫加解密函式,這樣有個好處就是可以截獲並重組完整的資料包.