APKSec Pro：Android App 資安合規自動檢測系統

01問題：為什麼需要另一套工具

銀行、政府與醫療類 App 上架前須依 V4.0 送實驗室檢測，但檢測是一次性的，開發商在年度送測之間沒有低成本的自我檢查方式。既有開源工具（MobSF、QARK）能偵測一般性 Android 弱點，卻不對應 V4.0 條文，也不區分「工具能證明的」與「本質上需人工的」項目，常在證據不足時就輸出結論，造成自相矛盾的合規假象。

本專題把問題定義成四個研究問題：

1. 如何把 49 項條文轉成可辯護的判定規則，使自動判定不在弱證據下給出誤導性結論？
2. 以召回優先為原則的靜態分析，在真實上架 App 上是否真的不漏報？誤報是否可由人工快速撤銷？
3. 系統能否在真實世界找到可辯護、值得通報的高危漏洞？研究者應如何在不觸法的前提下確認漏洞為真？
4. 如何讓非資安背景者「丟一個 APK 就得到看得懂的報告」，並誠實呈現工具界線？

系統定位是「開發商平時自我檢查的最嚴格審查工具」，不取代實驗室的送測認證。

02判定合約：工具能證明什麼

每一項檢測的結果只會是四種之一：通過、不通過、不適用、需人工（附佐證）。四種狀態各有可操作的定義：

• 不通過必須附可定位的證據：具體字串、類別名、Manifest 屬性、設定檔內容、動態事件或封包紀錄；共現推論不算證據。
• 通過須在明確宣告的檢測範圍內，以可重現的方法查無違反；「查得防護程式碼存在」只算佐證，因為存在不等於有效。
• 不適用只依外部框架 API 引用缺席或 Manifest 組態自動判定。
• 只能證明一側者採單邊確定性：可證明側輸出判定，另一側交人工。

召回優先寧可多報一條可由人工快速撤銷的不通過，也不容許任何真實漏洞被判為通過。命中類別屬第三方程式庫時仍輸出不通過並標注套件歸屬；只有能確定不構成違反的型態（平台契約要求的標準 Intent 入口、框架固定查詢、RSA 這類本非儲存加密的轉換）才降為線索。

49 項合約以可讀文件與機器可讀對應表雙軌維護，由自動化測試鎖定同步；判定合規引擎與判定理由文字各集中在單一模組。各送測分級的應檢測項目數：L1 25 項、L2 31 項、L3 39 項、F 加測 9 項；可自動判定 36 項（其中 21 項為只證不通過的單邊判定）、需人工 13 項。

03三層證據

• 靜態分析：以 Androguard 為基礎，8 個模組、32 條規則，讀 Manifest、網路安全組態、DEX 位元碼與字串。證據綁到類別與呼叫引數：WebView 規則要讀到 setAllowUniversalAccessFromFileURLs 的引數為 true 才判不通過；TLS 規則要讀到 checkServerTrusted 方法本體為空實作、或 HostnameVerifier 恆回傳 true 才判不通過。
• 動態分析：模擬器上以 Frida 掛鉤 API、擷取 logcat 與被動側錄，26 個分析器（自動 UI 探索、注入機器人、登出後重放舊 token、殘留與寫檔掃描、畫面擷取檢查、同意時序觀測等），以擴充不通過側為主。
• LLM 輔助判讀：12 條規則只處理靠讀文字就能判的項目（隱私權政策、畫面文字、設定檔），設三道防護：判定由工具依結構化認定推導、LLM 不直接輸出判定；引文須逐字出現在工具存下的證據快照；送出前遮罩測試帳號並設費用上限。LLM 永不產出「通過」。
• 另有第三方函式庫 CVE 比對與伺服器憑證線上探測。

04驗證體系

所有判定邏輯的變更遵守「先改合約、經確認、再改程式、跑全套驗證」。驗證層次由內而外：

1. 自動化測試（v2.4.1 為 1,105 項），含對應表完整性與規則矩陣：每條可判不通過的規則至少一支真實正樣本與一支反樣本，純佐證規則永不非線索。
2. 多 APK 回歸：樣本 APK 的完整違反集合須與基準一致。
3. 公開漏洞交叉驗證：DIVA、InsecureBankv2、AndroGoat 等的已知漏洞條文不得被判通過或不適用。
4. 自建可重現的 demo APK（有漏洞版與安全版）作為第二層正反樣本與動態回歸的正控制。
5. 最外層：546 支上架 App 的全數獨立逆向比對，每次判定碼變更即以當前版本重掃全部語料、重產混淆矩陣，翻轉逐筆歸因。

05546 支比對基準與混淆矩陣

語料為 546 支唯一 APK，含 400 支經 Google Play 安裝的臺灣上架 App。比對基準分兩層建置：

• 獨立判定引擎只讀 APK 原文、不呼叫系統規則層，對 11 條可靜態獨立判定的條文逐支判定，分「高信心」與「候選」兩級。
• 以 jadx 反編譯逐支審查 App 自有程式碼，每筆發現由「歸屬與型態」「可達性與可利用性」兩個對抗式視角覆核，須附可定位的反編譯證據，由本人驗收；共確認 584 筆 App 自有漏洞（294 支）。

高信心不通過 1,121 筆全數命中，無漏報亦無疑似誤報；584 筆確認的漏洞無一筆被判為通過，交人工的 262 筆集中於 WebView 設定、無固定格式的硬編碼機密與注入三類，皆附線索供檢測員複核。比對結果回饋至判定邏輯：據以校正解析與偵測規則，每次修改後重掃 546 支，26,754 個判定中的翻轉逐筆歸因，無非預期變動；加殼 App（語料中 47 支）宣告元件過半不在可見程式碼時，不給出通過。

06400 支上架 App 的實證

以最嚴格的送測分級（L3）對 400 支真實上架的臺灣 App（銀行、券商、政府、醫院、交通與生活）統一靜態檢測。

總覽368 支至少一項不通過、32 支零不通過，合計 1,574 條不通過旗標（每支平均 3.9 條）。最常見者為匯出元件、明文傳輸或弱 TLS、儲存加密弱演算法與注入防護，多屬強化不足或第三方程式庫殘留。零不通過的 32 支多為防護完善的銀行與金融 App，反證系統具鑑別力。一條不通過是一個待人工複核的旗標，不等於一個可被入侵的洞。

高危發現584 筆確認漏洞依攻擊者所需前置條件分四級，A 級（可直接通報）70 筆、64 支：

• A1 可直接取出的機密（29 支）：安裝檔內嵌雲端服務的服務帳戶私鑰、TLS 伺服器私鑰或管理員金鑰。代表案例包括一家軌道運輸業者 App 的雲端資料庫管理員金鑰、一家證券商 App 的 TLS 伺服器私鑰（以私鑰與憑證的 modulus 相等作數學確認）、一所醫學中心掛號 App 由公信憑證機構簽發之伺服器私鑰與寫死的金鑰庫密碼。
• A2 主要連線停用 TLS 驗證（40 支）：App 自行實作信任所有憑證的 TrustManager 或恆回傳 true 的 HostnameVerifier，並掛在登入、下單、掛號、繳費等主要連線；券商 15 支（多來自同一代工下單元件）、醫療 6 支、交通與政府 5 支、銀行 4 支、電信影音零售 8 支。

每一筆皆以靜態方法確認為真（結構自證、憑證數學配對、反編譯定位），全程未以任何金鑰或憑證連線測試；所有金鑰與權杖只辨識、定位、遮蔽記錄。機密值與 App 名稱不公開，通報對象與時程由指導教授與本人依 ISO/IEC 29147 負責任揭露原則決定。

07報告與使用方式

輸出 PDF、互動式 HTML 與 JSON 報告，以及需人工工作單。每項不通過附證據位置與修正建議，依風險排序產生優先處理清單；線索一律帶說明前綴，使沒有資安背景的人也能讀懂結論與工具界線。桌面介面分四頁：掃描設定、送測資料、掃描與結果、需人工工作單。

08下一階段

以 agent 自動操作 App 擴大動態測試覆蓋；以可達性與污點分析縮減需人工項目；以 LLM 讀取「可疑字串與其反編譯使用位置」並維持引文逐字核對；以動態脫殼或執行期 DEX 擷取涵蓋加殼 App；對 400 支語料每季重掃，建立臺灣上架 App 合規狀態的時間軸；依負責任揭露原則進行廠商通報並追蹤修補。

09文件

• 專題成果技術摘要（匿名版，5 頁 PDF）：研究問題、方法、實證設計、結果與未來工作。
• 完整成果報告（31 頁）含受測 App 之識別資訊，依負責任揭露原則於通報完成前不對外提供；審查委員如需查閱可另行聯絡。
• 開發過程以 AI 程式助理在本人訂定的規格、審查與測試門檻下協助實作；問題定義、49 項合約、驗證設計與最終驗收由本人完成。