AndroScanner 論文閱讀分析：很多 mobile App 真正先出事的，不是 APK 本身，而是背後那排被忽略的 API

本文由 AI 產生、整理與撰寫。

論文基本資訊

• 論文標題：AndroScanner: Automated Backend Vulnerability Detection for Android Applications
• 作者：Harini Dandu
• 年份：2026
• 來源：arXiv:2604.14431
• 論文連結：https://arxiv.org/abs/2604.14431
• DOI：10.48550/arXiv.2604.14431
• 主題：Android Security、Mobile App Security、API Security、Backend Security、Static Analysis、Dynamic Analysis

這篇論文最值得看的，不是它又做出一個 Android 掃描工具，而是它把很多行動 App 安全裡最常被低估的盲點講得很直白：很多 App 真正先出事的，不是 APK 本身，而是它背後那一排開發者其實沒真正盤清楚、也沒被持續稽核的 backend APIs。

我們平常談 mobile security，常把注意力放在 client side：權限、混淆、憑證保護、local storage、反逆向、甚至 supply chain。但真實世界很多高衝擊事故，最後都是從 backend 這條線炸開：資料過度曝露、弱驗證、錯誤的 access control、沒處理好的第三方服務整合、或一條被 App 埋得很深的 API endpoint 被直接打穿。

AndroScanner 的價值就在這裡：它不是再去問 APK 裡有沒有明文 secret 而已，而是把問題往後推一步，直接問這個 App 實際在跟哪些 API 溝通、參數長什麼樣、這些端點對 OWASP API Security Top 10 來說到底暴露了什麼風險。

這篇在解什麼問題？

作者想處理的，是一個很實務、但又很常被工具鏈切碎的問題：行動 App 開發者往往無法完整掌握自己的 backend attack surface。

原因很多：

• App 會串很多第三方 SDK、analytics、廣告、crash reporting 與雲端服務；
• 即使開發者很重視 client 端安全，也未必看得見所有 server-side / API-side 互動；
• 只做 static analysis 常抓不到 runtime 才會出現的實際 API call 與參數；
• 只做單點 fuzzing，又常缺少從 APK 逆回 endpoint 與上下文的能力。

所以這篇的核心問題不是「Android app 有沒有洞」這麼籠統，而是：

能不能從一個 APK 出發，半自動把它背後真正用到的 API 面盤出來，再用可落地的方式去驗它暴露了哪些 backend 風險？

我覺得這個 framing 很對，因為它把 mobile AppSec 從純 client review 拉回 mobile-to-backend trust chain。很多團隊前端保護做得不錯，但後面那條 API 線其實長年是黑盒。

方法設計：不是只反編譯 APK，而是把 static、dynamic、API fuzzing 接起來

AndroScanner 的 pipeline 分三段：

• API extraction：先從 APK 裡找出 App 實際會打哪些 API；
• API vetting：把抓到的 API 丟去做弱點檢查；
• reporting：把結果整理成開發者可以接手的漏洞報告。

這篇最合理的地方，是作者沒有把希望全押在單一分析技術上，而是混了幾層工具：

• apktool：解 APK、看 manifest 與資源；
• Androguard：做靜態分析與 call graph 輔助；
• APIKey Extractor：從 string resources、manifest metadata、Java / native code 裡挖 API key；
• Frida：在 runtime hook Android Framework entry points，抓真正被呼叫的 API 與參數；
• LibScout：幫忙辨識 external libraries / external APIs；
• APIFuzzer：把抽出的 API 定義送去做漏洞測試，對照 OWASP API Security Top 10。

這裡的重點不是每個工具都新，而是作者把它們串成一條能從 APK 一路走到 backend risk 的工作流。這比很多只停在「我能抓到 endpoint 字串」的工具成熟一截。

為什麼一定要 dynamic analysis？

這篇一個很實際的觀察是：只靠 static analysis 不夠。

很多 App 的 API call 不會乖乖把所有 endpoint 明明白白放在那裡。你可能會遇到：

• runtime 才拼接出來的 URL；
• 透過 library wrapper 間接送出的 request；
• 參數在 execution path 中才變具體；
• client 端只有部分 clue，真正有用的是 runtime 呼叫時的上下文。

AndroScanner 用 Frida 去 hook Android Framework 的 network-related entry points，目的就是把這些 runtime signal 抓出來。這件事很重要，因為 AppSec 真正有價值的，不只是知道「可能有 HTTP client」，而是知道到底呼叫了哪個 endpoint、送了哪些參數、哪些是 internal API、哪些是第三方 external API。

作者也很坦白：這套方法目前仍依賴 curated Android Framework entry points，所以如果 App 用了很多自訂封裝或客製加密函式，覆蓋率就會受限。這反而讓我更相信結果，因為它沒有把工具吹成萬能。

實驗怎麼做？

作者拿兩個 Android app 來測：

• 一個刻意脆弱的 bank app，用來驗證工具能否抓到已知問題；
• Hirect 招募 App，一個實際上架、Google Play 上有超過 50,000 downloads 的 production app。

這個組合其實很合理。前者可以看工具是否有基本辨識能力，後者才是比較像實務場景的 proof point。

關鍵結果：24 個 API、5 個漏洞，還抓到 production app 的未通報問題

論文裡最值得記住的數字有幾個：

• Across 兩個 App，總共抽出 24 個 APIs；
• 其中 bank app 抽到 4 個 APIs，Hirect 抽到 20 個 APIs；
• 兩者合計找出 5 個 vulnerabilities；
• 其中 bank app 有 4 個，Hirect 有 1 個。

真正有意思的是後面這個 production case。作者在 Hirect 的 seekermsg endpoint 上發現了 Excessive Data Exposure，而且這個問題在 OWASP API Security Top 10 中排名第 3。論文描述該端點會洩露 message timestamps，攻擊者可以利用這類資訊去組裝更可信的社交工程訊息，偽裝成 recruiter 對求職者下手。

這裡我覺得作者做對的一點，是沒有把漏洞價值只停在「欸有個 endpoint 多回了一欄資料」。Excessive data exposure 的危險，常常不在單筆欄位本身，而在它能不能成為下一步詐騙、枚舉、社工、關聯分析或帳號活動側錄的素材。

這篇真正重要的，不只是找到洞，而是把 mobile backend review 變成可以規模化的流程

如果只看 headline，這篇像是在講 Android backend 掃描器；但我覺得它更深一層的價值是：它把 mobile App 的 backend review 重新表述成一條可複製的 AppSec pipeline。

很多團隊現在的流程是這樣：

• 做 APK review；
• 做 SAST / dependency check；
• 有空才人工 proxy / 攔封包看 API；
• server-side security 常由另一組人接，彼此上下文不通。

AndroScanner 想做的是把這條線接起來：從 APK 萃出 API surface，接著直接餵進 API fuzzing，再產生開發者能理解的 remediation context。這其實很像在把 mobile app backend assessment 從高手手工活，推向pre-production 可持續執行的 security gate。

作者自己也承認了幾個限制，這反而是好事

論文沒有把工具講成完美。作者清楚列了幾個限制：

• 只支援 Android / Java-based APK，不支援 iOS；
• 若參數經過客製加密，Frida hook 不一定能自動還原；
• 目前主要是 CLI workflow，對一般開發者可用性有限；
• 對於自定義網路函式與非標準封裝，偵測能力仍受 entry-point coverage 影響。

另外有個細節我很喜歡：作者找了實際 Android 開發者 review 工具，對方認為這套方法大概能抽到 80% 的 API calls，但也直接指出報告還不夠好懂、需要更好的 GUI 與 patch guidance。這種 feedback 很務實，因為很多安全工具真正死掉的地方，不是 finding 不存在，而是沒被開發團隊成功接住。

我的看法

我覺得這篇最有價值的提醒是：

很多 mobile App 真正缺的，不是再多一輪 client-side hardening，而是先把它背後那張 API 地圖和風險地圖畫出來。

這也是為什麼 AndroScanner 雖然技術上不算華麗，卻很有落地味。它不是再做一個泛泛的「AI 幫你找洞」故事，而是把 static reverse engineering、runtime observation 與 API security testing 接成一條很像真實 AppSec 流程的 pipeline。

如果要挑它的弱點，我會說目前對 custom network stack、加密參數、iOS 與規模化部署的支援都還早期；另外 APIFuzzer 這條線本身也繼承了 API definition quality 與 fuzz coverage 的限制。但這些都不改變它指出的核心事實：手機上的 attack surface，很多時候其實只是 backend attack surface 的入口頁。

重點整理

• AndroScanner 處理的是 Android App 背後 backend API 的自動化漏洞盤點，而不只是 APK 本身的 client-side 弱點掃描。
• 核心 workflow 結合 apktool、Androguard、APIKey Extractor、Frida、LibScout 與 APIFuzzer，把 static analysis、dynamic instrumentation 與 API fuzzing 串成同一條流程。
• 方法的關鍵在於：先從 APK 與 runtime 抓出真實 API surface，再對照 OWASP API Security Top 10 做弱點檢測。
• 評估使用兩個 app：一個 purposely vulnerable bank app，以及一個 Google Play 上有 50,000+ downloads 的實際招募 App Hirect。
• Across 兩個案例共抽出 24 個 APIs，其中 bank app 4 個、Hirect 20 個。
• 總共找到 5 個漏洞：bank app 4 個、Hirect 1 個。
• Hirect 的 seekermsg endpoint 存在 Excessive Data Exposure，會暴露 message timestamps；作者已於論文發表前做 responsible disclosure。
• 實際開發者 review 認為工具大約能覆蓋 80% API calls，但報告可讀性、GUI 與 remediation guidance 仍需加強。
• 這篇真正重要的訊號是：mobile AppSec 不該只看 APK，本質上還要把 backend API surface 一起拉進 security review。

Takeaway

這篇論文真正提醒我們的，是行動 App 的安全邊界從來不只在手機裡，而是一路延伸到它所依賴的 backend、第三方服務與 API 生態。

如果你的 AppSec 流程還主要停在 APK reverse engineering、權限檢查或單點 SAST，那 AndroScanner 至少提供了一個很實際的方向：從 App 反推出 backend attack surface，再把它做成可持續執行的 API security review pipeline。

對做 mobile security、API security、Android reverse engineering 或 pre-release security review 的人來說，這篇值得看，因為它抓到了一個很常見但常被流程切斷的現實：很多產品真正先漏出去的，不是 App 自己，而是 App 背後那組你以為已經有人顧的 API。