我第一次正式用 Inspeckage是在給一個運(yùn)動打卡類 App 做上線前自查的時候。那會兒我需要確認(rèn)三件事本地存儲有沒有泄露用戶字段、網(wǎng)絡(luò)請求有沒有做加密與簽名、以及系統(tǒng)版本升級之后這些接口行為會不會變。傳統(tǒng)抓包工具只能回答“流量側(cè)”的問題但我想知道某個請求的數(shù)據(jù)到底從哪段代碼、哪個配置里拼出來這就需要動態(tài)分析工具介入。Inspeckage 是一個基于 Xposed 框架的安卓動態(tài)分析模塊特點(diǎn)是能讓你在瀏覽器里看一個 App 運(yùn)行時的網(wǎng)絡(luò)請求、文件讀寫、數(shù)據(jù)庫操作和加解密調(diào)用。和 Burp Suite 這類中間人代理配合起來基本能描出一張很完整的“App 行為地圖”。這篇實(shí)錄我會以“某運(yùn)動打卡類應(yīng)用”作為分析案例完整走一遍從環(huán)境搭建、抓包取數(shù)、到定位關(guān)鍵邏輯的過程。適合剛?cè)腴T安卓逆向的測試人員也適合想對自己 App 做安全自查的開發(fā)者。我們不討論任何惡意破解和作弊改數(shù)據(jù)重點(diǎn)是把“看懂一個 App 怎么工作”這件事講明白。1. 先從需求說起這類分析到底要解決什么問題1.1 抓包、逆向和動態(tài)調(diào)試邊界怎么畫很多人把“抓包”和“逆向”混成一個概念但實(shí)際上它們解決的是不同層的問題。抓包解決的是“客戶端和服務(wù)端之間發(fā)生了什么”它站在網(wǎng)絡(luò)鏈路的角度能看到請求頭、請求體、返回數(shù)據(jù)、狀態(tài)碼這些信息。逆向工程則更底層它要解決的是“客戶端內(nèi)部是怎么實(shí)現(xiàn)的”比如某個字段是從哪一段邏輯里生成的某個加密密鑰又是寫在哪里的。動態(tài)調(diào)試則介于兩者之間。它通過 Hook 或者斷點(diǎn)的方式在程序運(yùn)行過程中去觀察內(nèi)存、篡改函數(shù)返回值、或者記錄調(diào)用棧。Inspeckage 本質(zhì)上就是把 Hook 的輸出整理成了可視化面板雖然不叫調(diào)試器但思路是一脈相承的。在一個完整的分析項(xiàng)目里最好是抓包先定性再用代碼定位來驗(yàn)證。我在實(shí)際工作中經(jīng)常碰到這樣的情況請求里的某個參數(shù)加密了抓包只能看到一串密文這時候你就得反編譯出來看加密邏輯、找密鑰位置再把動態(tài) Hook 的結(jié)果和靜態(tài)代碼互相印證。所以標(biāo)題里“抓包”和“逆向”是順序關(guān)系不是并列關(guān)系。1.2 為什么拿打卡類應(yīng)用當(dāng)案例選“運(yùn)動打卡類應(yīng)用”作為案例一是因?yàn)樗婕岸ㄎ?、軌跡、時間上報這類典型敏感數(shù)據(jù)拿來講隱私合規(guī)問題很有代表性二是因?yàn)檫@類應(yīng)用通常會做簽名校驗(yàn)和參數(shù)防篡改分析的過程能覆蓋比較多的常見技術(shù)點(diǎn)。這類 App 的通信模型中有幾個幾乎必然出現(xiàn)的接口登錄鑒權(quán)接口、用戶信息查詢接口、打卡或者運(yùn)動記錄上報接口。上報接口一般會攜帶經(jīng)緯度、運(yùn)動速度、路線點(diǎn)集、時間戳這類字段。當(dāng)我們看到這類字段以明文或者可辨識形式出現(xiàn)在流量里時就要思考是否合理是否過度采集這是合規(guī)審計中很重要的一步。當(dāng)然我說的是在你有授權(quán)的前提下進(jìn)行分析。本文所有操作都應(yīng)該在自己擁有或者已獲得明確授權(quán)的 App 上完成不要用于繞過業(yè)務(wù)規(guī)則、虛假打卡這類行為。2. 認(rèn)識 Inspeckage功能拆解與分工邊界2.1 它到底能看什么Inspeckage 本質(zhì)上是 Xposed 模塊。Xposed 的工作原理是在應(yīng)用進(jìn)程啟動時把一段代碼插入到系統(tǒng)進(jìn)程的入口里這樣 App 在運(yùn)行過程中調(diào)用一些關(guān)鍵函數(shù)時就會被“鉤住”被鉤住的函數(shù)可以在調(diào)用前、調(diào)用后插入我們自己的邏輯。Inspeckage 利用這個機(jī)制自動在很多關(guān)鍵的系統(tǒng)函數(shù)上布了監(jiān)控點(diǎn)。啟動后它會在手機(jī)本地開一個 Web 服務(wù)默認(rèn)端口是 8008你通過瀏覽器打開http://localhost:8008如果是模擬器則通過 adb 把端口映射到宿主機(jī)就能看到下面的信息模塊。Network網(wǎng)絡(luò)模塊記錄 Hook 到的 HTTP 請求和響應(yīng)包括 URL、Header、請求體和返回的 JSON 結(jié)構(gòu)。這塊和代理抓包有部分重合但優(yōu)勢在于它能看到一些通過非標(biāo)準(zhǔn)網(wǎng)絡(luò)庫發(fā)出的流量以及混淆 App 中自定義網(wǎng)絡(luò)層的請求內(nèi)容。SharedPreferences偏好設(shè)置實(shí)時展示應(yīng)用寫入的鍵值對配置。很多 App 會把登錄 Token、用戶信息、設(shè)備標(biāo)識臨時存到這里分析這個模塊能快速定位鑒權(quán)信息是如何緩存與刷新的。你在界面上點(diǎn)幾次按鈕這里可能就多出幾條新記錄對應(yīng)關(guān)系非常直觀。Files文件模塊列出應(yīng)用內(nèi)部存儲中正在被讀取或者寫入的文件并提供文件內(nèi)容查看。這里常常能找到數(shù)據(jù)庫文件、日志文件、或者緩存的配置 JSON。有一次我在這個模塊里直接看到一個應(yīng)用的加密密鑰被寫進(jìn)了調(diào)試日志這種問題靠純黑盒測試很難發(fā)現(xiàn)。Databases數(shù)據(jù)庫模塊監(jiān)控 SQLite 的打開、查詢和寫入操作。當(dāng) App 做了本地數(shù)據(jù)緩沖時可以在這里直接查看表結(jié)構(gòu)和記錄省去了把數(shù)據(jù)庫文件 pull 出來再查的流程效率會明顯高一些。IPC進(jìn)程間通信展示 App 與其他組件之間通過 Binder、Intent 等機(jī)制傳遞的數(shù)據(jù)可以用來評估組件暴露風(fēng)險比如有沒有可以被外部任意調(diào)用的 Activity 或 Service。運(yùn)動類應(yīng)用經(jīng)常要接收系統(tǒng)廣播、后臺切換消息這里很容易看出組件間的數(shù)據(jù)流向。Crypto加密模塊Hook 常見的 MD5、SHA、AES、RSA 等加密接口調(diào)用記錄輸入的明文字符串、算法參數(shù)和輸出的密文。對分析帶加密的通信非常關(guān)鍵能直接看到密鑰和 IV 在調(diào)用時的具體值。簡單說代理抓包看到的是“加密后的結(jié)果”Crypto 模塊看到的是“加密前的原料和鑰匙”。這些模塊疊加起來已經(jīng)覆蓋了一個 App 在運(yùn)行時大部分的敏感操作面。相比單獨(dú)去看數(shù)據(jù)庫文件、單獨(dú)抓包Inspeckage 是把“運(yùn)行中的事實(shí)”整合到了一起這是它的核心價值。2.2 和 Charles、Burp Suite 這類工具怎么分工有一類非常典型的誤區(qū)裝了 Inspeckage 就不再需要代理抓包只用它一個工具就夠。這不現(xiàn)實(shí)原因有三個。第一Inspeckage 的 Network 模塊依賴 Hook 成功率。如果目標(biāo) App 自己實(shí)現(xiàn)了加密通道或者用了 WebSocket、TCP 私有協(xié)議它的記錄可能不完整。而 Burp Suite 這類代理工具處在網(wǎng)絡(luò)層它看到的是真實(shí)離開設(shè)備的字節(jié)流不受應(yīng)用內(nèi)部實(shí)現(xiàn)的干擾。第二TLS 解密能力不同。代理工具可以在安裝 CA 證書之后解密大部分 HTTPS 流量但沒法處理那些不走系統(tǒng)證書鏈的請求。而 Inspeckage 能拿到請求組裝階段的明文天然不受證書信任策略影響。兩者配合正好互補(bǔ)。第三使用場景不同。日常調(diào)試的時候我更常用 Charles因?yàn)樗p量、夠用。但是當(dāng)我需要看“某個請求是由哪段代碼發(fā)起的”“某個加密函數(shù)的輸入到底是什么”的時候就會切到 Inspeckage。如果你只想知道接口長什么樣代理就夠了如果你想從本地行為倒推代碼邏輯就得靠 Inspeckage。最理想的狀態(tài)是讓代理工具負(fù)責(zé)“全量流量證據(jù)”Inspeckage 負(fù)責(zé)“本地動態(tài)行為證據(jù)”兩邊一對照整個分析畫面基本就閉環(huán)了。3. 實(shí)驗(yàn)環(huán)境搭建從模擬器到證書信任鏈3.1 設(shè)備與系統(tǒng)選型Inspeckage 需要 Xposed 框架支持經(jīng)典的原版 Xposed 只支持到 Android 7 左右這就直接影響了實(shí)驗(yàn)環(huán)境的選擇。如果你的目標(biāo)主要圍繞低版本兼容性分析那選一臺 Android 6.0 或者 7.0 的模擬器是最省事的。Xposed 安裝包在模擬器上很容易找而且很多 x86 鏡像自帶 root 權(quán)限省去刷機(jī)步驟。如果被分析的應(yīng)用要求高版本系統(tǒng)才能運(yùn)行越來越常見你可以考慮 Android 8.0 以上的環(huán)境配合 LSPosed。LSPosed 是 Xposed 的社區(qū)分支支持新版 Android對 Inspeckage 的兼容性也維護(hù)得不錯。安裝方式一般是通過 Magisk 刷模塊宿主環(huán)境只要提供 root就能跑起來。模擬器選擇上我比較推薦 Genymotion 直接跑低版本系統(tǒng)或者自己用官方鏡像創(chuàng)建一個 Android 7 x86 的模擬器。如果你更喜歡命令行風(fēng)格用 Level 23 的 AVD 鏡像也行不過需要額外手動裝相關(guān)組件。真機(jī)如果需要使用可以找一臺可以自由刷機(jī)的舊機(jī)型成本和門檻會高一些。真機(jī)和模擬器的區(qū)別主要在兩點(diǎn)。一是傳感器模擬運(yùn)動打卡類 App 常常會檢查定位和傳感器模擬器上往往需要手動注入 GPS 坐標(biāo)真機(jī)直接具備 GPS 與環(huán)境傳感器。二是架構(gòu)差異模擬器大多是 x86 架構(gòu)一些只編譯了 arm 庫的 App 運(yùn)行起來會有兼容性問題遇到這種情況也只能切到真機(jī)。3.2 安裝 Xposed/LSPosed 與 Inspeckage以 Android 7 模擬器上安裝原版 Xposed 的流程為例啟動模擬器確認(rèn) root 權(quán)限可用。Genymotion 自帶AVD 需要先刷入 userdebug 鏡像再執(zhí)行adb root。下載對應(yīng)架構(gòu)的安裝器 APK 并安裝安裝器會自動檢測系統(tǒng)版本。打開安裝器點(diǎn)擊“Install”重啟模擬器。安裝 Inspeckage APK再次進(jìn)入 Xposed 的“模塊”界面勾選 Inspeckage然后重啟系統(tǒng)讓模塊真正加載。需要注意Xposed 安裝失敗最常見的原因是系統(tǒng)鏡像的 ramdisk 沒有解鎖。很多模擬器鏡像默認(rèn)的分區(qū)校驗(yàn)會阻止修改系統(tǒng)分區(qū)所以先確認(rèn)能不能正常把文件寫入再執(zhí)行安裝流程。如果使用 LSPosed流程邏輯類似先裝 Magisk再刷入 LSPosed然后在 LSPosed 列表里啟用 Inspeckage。啟用后同樣需要重啟應(yīng)用或整個系統(tǒng)Hook 才能生效。區(qū)別只在于新版系統(tǒng)的分區(qū)結(jié)構(gòu)更復(fù)雜刷模塊時要留意 Magisk 版本和系統(tǒng)架構(gòu)是否匹配。3.3 配置 HTTP 代理與 CA 證書有了 Inspeckage代理抓包依然值得配好因?yàn)樗俏覀兡玫骄W(wǎng)絡(luò)傳輸原始內(nèi)容的第一視角。這里以 Burp Suite 為例把電腦上的代理監(jiān)聽地址設(shè)為0.0.0.0:8080允許來自局域網(wǎng)的連接。在模擬器里打開 WiFi 設(shè)置修改當(dāng)前網(wǎng)絡(luò)的代理為電腦 IP 加端口。更省事的做法是用 adbadb shell settings put global http_proxy 電腦IP:8080這樣所有走系統(tǒng)代理的應(yīng)用都會經(jīng)過 Burp。接下來是證書信任的問題。Burp 默認(rèn)生成一個自己的 CA 證書應(yīng)用在 HTTPS 握手時會對它做簽名校驗(yàn)。Android 7 之前把證書裝進(jìn)“用戶憑據(jù)”就可以被信任Android 7 之后系統(tǒng)默認(rèn)不信任用戶證書只有裝到系統(tǒng)證書目錄才算數(shù)。這就是很多人對高版本系統(tǒng)抓包失敗的根本原因。把 Burp 的證書轉(zhuǎn)成系統(tǒng)證書的基本流程是openssl x509 -inform der -in cacert.der -out cacert.pem mv cacert.pem $(openssl x509 -inform PEM -subject_hash_old -in cacert.pem | head -1).0 adb root adb remount adb push hash.0 /system/etc/security/cacerts/ adb shell chmod 644 /system/etc/security/cacerts/hash.0執(zhí)行完這幾步之后再重啟模擬器HTTPS 流量就應(yīng)該能被 Burp 解密查看。如果遇到重啟后證書被復(fù)位的情況多半是系統(tǒng)分區(qū)沒有真正可寫需要先關(guān)閉動態(tài)校驗(yàn)或者以讀寫方式重新掛載。3.4 高版本 Android 的證書適配如果必須分析的是 Android 9 以上的 App除了證書問題還有另一個很常見的阻礙目標(biāo)應(yīng)用在targetSdk 28及以上時默認(rèn)不信任明文 HTTP 流量甚至部分帶安全配置的版本還會限制信任的 CA。此時你的代理抓包經(jīng)常能看到連接被斷開的情況這就是系統(tǒng)層面的兼容性策略所致。解決思路上有幾個選擇如果 App 自帶網(wǎng)絡(luò)安全配置可以在其中增加信任 CA但這只對你自己維護(hù)的測試包有效。對第三方分析的場景更多是用動態(tài) Hook 的方式去注入證書信任邏輯。這條路需要一定的腳本開發(fā)知識適合熟悉動態(tài)調(diào)試后進(jìn)階本文不展開具體代碼。如果是自己公司的應(yīng)用最省事的方案是在構(gòu)建配置里臨時去掉網(wǎng)絡(luò)限制用 debug 包做分析基本零成本。我個人的經(jīng)驗(yàn)是生產(chǎn)環(huán)境 App 的證書鎖定邏輯千奇百怪靠加裝證書一種方式解決不了所有問題把“系統(tǒng)證書配置”和“動態(tài) Hook”兩條路線都掌握是比較穩(wěn)妥的狀態(tài)。4. 實(shí)操全記錄Inspeckage 抓包分析打卡類 App4.1 啟動服務(wù)并選定目標(biāo)應(yīng)用環(huán)境搭建好之后打開 Inspeckage 的應(yīng)用界面。第一次啟動會列出設(shè)備里的應(yīng)用列表你直接找到要分析的應(yīng)用包名。如果是一個第三方 App可以通過adb shell pm list packages | grep 關(guān)鍵詞先找到包名再在 Inspeckage 里選中它。選中后點(diǎn)擊“Start”按鈕Inspeckage 會在本地 8008 端口啟動服務(wù)。然后執(zhí)行adb forward tcp:8008 tcp:8008把端口映射到宿主機(jī)電腦瀏覽器打開http://localhost:8008就能看到控制臺面板。面板右上角會顯示當(dāng)前分析的包名下方是按模塊分類的頁簽。啟動觀察之后再去手動操作一遍 App 的核心功能讓 App 跑一遍真實(shí)的業(yè)務(wù)流程同時盯住面板上的日志變化。這一步的操作順序很重要先啟動監(jiān)控再操作 App否則關(guān)鍵請求很容易被漏掉。4.2 網(wǎng)絡(luò)模塊把請求參數(shù)和行為對上號以打卡類 App 的日常流程為例正常應(yīng)該是登錄進(jìn)入首頁拉取任務(wù)信息開始某項(xiàng)運(yùn)動時上報軌跡點(diǎn)結(jié)束后提交整段記錄。每一步都會產(chǎn)生流量但網(wǎng)絡(luò)模塊里最值得關(guān)注的不是那些圖片加載、廣告請求而是和業(yè)務(wù)強(qiáng)相關(guān)的接口。在一次完整記錄里你大概率會看到類似下面的請求結(jié)構(gòu)POST/api/v1/user/login參數(shù)里有account、pass、device_id、app_version。GET/api/v1/task/list返回當(dāng)天可參與的任務(wù)列表。POST/api/v1/track/upload請求體是一大段 JSON包含track_points數(shù)組每個點(diǎn)有l(wèi)on、lat、timestamp、speed。POST/api/v1/track/report最終提交運(yùn)動里程、總時長、平均速度。看到這些字段之后建議把每個參數(shù)和一個數(shù)據(jù)來源對應(yīng)上。比如speed來自定位模塊計算出的瞬時速度timestamp來自系統(tǒng)時鐘device_id來自持久化存儲或硬件信息合成。這樣你才能判斷哪些數(shù)據(jù)是客戶端本地合成的哪些依賴服務(wù)端下發(fā)。有一點(diǎn)要提醒參數(shù)加密很常見。如果pass在請求里是密文先別慌切到 Inspeckage 的 Crypto 模塊往往能直接看到對應(yīng)的加密輸入與密鑰。這也是我為什么強(qiáng)調(diào)它是網(wǎng)絡(luò)分析的關(guān)鍵補(bǔ)充代理看明文Inspeckage 看生成明文的地方。4.3 本地存儲模塊從配置到數(shù)據(jù)庫的信息拼圖請求參數(shù)來源問題實(shí)際上就是本地存儲來源問題。在 Inspeckage 的 SharedPreferences 里你能看到類似user_info、device_info這類鍵值文件數(shù)據(jù)庫模塊里則能看到用戶表、緩存表、軌跡表的寫入記錄。實(shí)際分析時我通常用下面這個順序先看 SharedPreferences 里存了什么。如果token和user_id直接以明文形式躺在配置里說明 App 在鑒權(quán)信息本地化處理上比較簡單若要評估風(fēng)險需要考慮是否能被其他應(yīng)用讀取以及有沒有做加密。再看數(shù)據(jù)庫表結(jié)構(gòu)。數(shù)據(jù)庫往往存儲著最近幾十條歷史記錄可以進(jìn)一步觀察服務(wù)端下發(fā)的數(shù)據(jù)結(jié)構(gòu)。最后看文件讀取列表。結(jié)合文件內(nèi)容可以知道有沒有把緩存 JSON 寫到磁盤日志文件是否攜帶敏感參數(shù)。這個過程最大的好處是你不需要反復(fù)反編譯代碼去猜邏輯所有現(xiàn)場都有記錄。比如你看到數(shù)據(jù)庫模塊里有一條軌跡插入記錄那你大概就能猜出前端保存數(shù)據(jù)是以什么形式和粒度存的后續(xù)代碼分析時心里就有底了。4.4 靜態(tài)分析配合用 jadx 從代碼層面去印證動態(tài)看到的東西最終還是要落到代碼上去印證。比如你在流量里發(fā)現(xiàn)pass參數(shù)是加密值但具體密鑰是怎么來的是硬編碼、配置文件還是服務(wù)端下發(fā)這一步靠動態(tài)工具看不全需要把 APK 解包看。我常用的流程是jadx -d out com.example.testapk.apk反編譯之后先在代碼目錄里搜關(guān)鍵詞比如api_key、secret、AES、encrypt再用grep去搜索前一步抓到的接口路徑比如track/upload然后順著調(diào)用鏈往回找。以 track/upload 為例反編譯后看到的代碼輪廓大概是這樣public void uploadReport(ListTrackPoint points) { String data gson.toJson(points); String encrypted CryptoUtil.aesEncrypt(data, getSecret()); OkHttpClient client new OkHttpClient(); Request req new Request.Builder() .url(https://api.example.com/v1/track/upload) .addHeader(sign, md5(data getSecret())) .post(RequestBody.create(encrypted)) .build(); }這個片段里可以看到兩層信息一是數(shù)據(jù)做了 AES 加密二是還加了一個sign頭做參數(shù)校驗(yàn)。如果你在抓包時習(xí)慣只看返回 JSON很容易忽略這類請求頭里的簽名字段但它在整個安全評估里恰恰是最值得關(guān)注的一環(huán)。靜態(tài)分析真正的價值是能回答這樣的問題這個參數(shù)是怎么生成的這個加密用的什么算法這個接口調(diào)用由什么觸發(fā)只要你能把這三件事說清楚整個分析基本就完整了。反過來如果靜態(tài)代碼里看到的行為和動態(tài)抓到的行為不一致那就要警惕 App 是不是做了多重邏輯替換把關(guān)鍵請求偽裝成了普通流量。5. 常見問題與排查技巧5.1 快速排查表癥狀常見原因排查思路Inspeckage 面板打開沒有數(shù)據(jù)Xposed 模塊未啟用或未重啟回 Xposed 檢查模塊勾選狀態(tài)重啟后重試代理下所有 HTTPS 流量都無法解密用戶證書在 Android 7 上不被信任將 CA 裝入系統(tǒng)證書目錄并確認(rèn)沒有證書固定邏輯只有部分接口能看到其他看不到App 使用自定義網(wǎng)絡(luò)庫或私有協(xié)議以本地存儲分析為主重點(diǎn)關(guān)注請求組裝階段的日志記錄請求能看到明文接口但關(guān)鍵參數(shù)是密文應(yīng)用在客戶端做了加密去 Crypto 模塊查看算法與密鑰使用模擬器運(yùn)行 App 閃退只支持 arm 原生庫或檢測模擬器更換 arm 鏡像或改用真機(jī)安裝 Xposed 后開機(jī)卡循環(huán)系統(tǒng)分區(qū)校驗(yàn)未解鎖用解鎖補(bǔ)丁重新掛載再重裝模塊表格里的每一種情況我都實(shí)際遇到過尤其是前兩種占了至少六成的問題。如果你剛搭好環(huán)境就遇到連不上代理的情況先從證書信任查起往往能省掉一大半折騰時間。5.2 三個容易忽略的細(xì)節(jié)第一個細(xì)節(jié)一定要把系統(tǒng)時鐘校準(zhǔn)。App 在做簽名校驗(yàn)的時候經(jīng)常會把當(dāng)前時間和服務(wù)端時間做對比如果模擬器的時區(qū)不對請求會出現(xiàn)在簽名計算上失敗進(jìn)而返回 401。很多人排查了半天請求邏輯最后發(fā)現(xiàn)是時間戳的問題。第二個細(xì)節(jié)區(qū)分“應(yīng)用自己發(fā)的請求”和“第三方 SDK 發(fā)的請求”。現(xiàn)在絕大多數(shù) App 都集成了推送、統(tǒng)計、地圖等第三方 SDK網(wǎng)絡(luò)模塊里的大體量流量其實(shí)來自這些 SDK。如果一開始就對著所有域名挨個看很容易暈。我建議先只關(guān)注主業(yè)務(wù)域名再做下一步精細(xì)分析。第三個細(xì)節(jié)使用 Inspeckage 時盡量做到“最小操作”。每次只操作一個核心業(yè)務(wù)動作然后立刻去面板看日志避免多個線程同時發(fā)起大量請求不然 Hook 日志會刷得非?？礻P(guān)鍵信息反而被淹沒。5.3 一次最典型的排查過程我拿一次實(shí)際適配過程講講。當(dāng)時我們在 Android 14 真機(jī)上跑 LSPosed代理也配好了證書也裝進(jìn)系統(tǒng)目錄了可是代理上看到的全是連接記錄完全沒有應(yīng)用層的明文。反復(fù)折騰半小時后才發(fā)現(xiàn)目標(biāo) App 的targetSdk比較高并且在網(wǎng)絡(luò)安全配置里只信任指定證書把系統(tǒng)證書目錄整個排除了。代理不可能在握手階段取得它信任。這種情況只能用動態(tài) Hook 繞不展開具體腳本。但排查思路很關(guān)鍵先確認(rèn)是不是“系統(tǒng)證書不信任”的問題。方法很簡單抓一個該手機(jī)上瀏覽器的 HTTPS如果能解密說明證書鏈路沒問題如果只有目標(biāo) App 失敗說明它自己做了一層限制要么是證書固定要么是網(wǎng)絡(luò)安全配置的信任規(guī)則。把邊界判斷清楚方向就對了。實(shí)操心得這類問題最忌諱一上來就懷疑工具出了問題。我見過太多人反復(fù)重裝 Xposed、反復(fù)清緩存最后才發(fā)現(xiàn)只是目標(biāo) App 的證書策略特殊。先做橫向?qū)Ρ葴y試永遠(yuǎn)比反復(fù)折騰單一變量要快。6. 踩了這么多坑之后說說我的體會我常對剛?cè)胄械呐笥颜f抓包工具安裝起來不難但對分析尺度的把握需要積累。第一先學(xué)會看完整閉環(huán)再做細(xì)致拆解。切忌上來就反編譯全部代碼應(yīng)該先從一次完整的業(yè)務(wù)請求入手把“從打開 App 到產(chǎn)生一次行為”的整個鏈路看明白。很多新人一上來就對著某個加密函數(shù)猛沖結(jié)果問他在哪個業(yè)務(wù)場景觸發(fā)、請求前后依賴是什么完全答不上來這就本末倒置了。第二動態(tài)和靜態(tài)互相印證。動態(tài)分析告訴你“發(fā)生了什么”靜態(tài)分析告訴你“為什么會發(fā)生”兩者缺一不可。沒有動態(tài)依據(jù)的代碼分析容易停留在想象沒有靜態(tài)依據(jù)的動態(tài)日志容易淪為現(xiàn)象堆砌。我在實(shí)戰(zhàn)中最爽快的時刻基本都是先在 Inspeckage 里看到一條加密調(diào)用記錄然后在反編譯代碼里找到同一處邏輯兩邊嚴(yán)絲合縫對上。第三高版本兼容是常態(tài)。還在把 Android 7 當(dāng)標(biāo)配的人會越來越吃力早點(diǎn)熟悉 LSPosed 和動態(tài) Hook 這一類新框架比反復(fù)折騰老系統(tǒng)更劃算。技術(shù)棧會過時但分析思路不會永遠(yuǎn)從“數(shù)據(jù)從哪里來、到哪里去、經(jīng)過了什么變換”這條主線出發(fā)就不會被工具版本牽著走。最后再分享一個小技巧。很多 App 的敏感邏輯分布在多個代碼分支里裝好工具后最省心的方式是先整體跑一遍核心場景再通過 Inspeckage 按模塊分組導(dǎo)出日志再切到 jadx 里逐層下鉆。這樣你既能保證不遺漏外層流量也不會被大量日志干擾。長期下來你會慢慢建立一套屬于自己的“App 行為分析地圖”遇到再陌生的目標(biāo)也會知道自己第一步該看哪里第二步該查什么。