APKSec Pro 實證：400 支上架 App 的檢測與負責任揭露

研究問題與設計

本頁回答第三個研究問題：系統能否在真實世界找到可辯護、值得通報的高危漏洞？找到之後，研究者如何在不觸法、不越界的前提下確認漏洞為真？設計分兩部分：

統一檢測：以同一版本、同一分級檢測 400 支上架 App，描述不通過旗標在各 App 與各條文上的分布。
可回報分級：以 A-2 反編譯逐支確認的 584 筆 App 自有漏洞為母體，依攻擊者需要的前置條件分級，挑出可以直接通報廠商的問題。

兩部分共用同一條倫理界線：金鑰與權杖只辨識、定位、遮蔽記錄，不測試有效性、不用來連線。

語料與檢測設定

取得：原始清單 408 支，排除 8 支 Google 與系統元件後為 400 支第三方 App；安裝檔多數是在 Android 模擬器上經 Google Play 安裝後，以 adb 取出。
類別：銀行、券商、保險、政府、醫院、交通與生活類。
設定：全數以送測分級 L3（最嚴格的範圍，39 項）純靜態檢測，2026 年 9 月 16 日以 v2.2.0 統一重掃，不區分取得先後。
計數口徑：只計 L3 範圍內的 39 項；F 類加測項不在送測範圍，不計入。
這 400 支也全數在 546 支比對基準之內，其後各版判定碼的重掃與比對見 A-2。

整體結果

400 支中，368 支至少有一項不通過、32 支零不通過，合計 1,574 條不通過旗標，平均每支 3.9 條。每支的不通過項數介於 0 至 11，最常見的是 4 項（82 支），8 項以上者 20 支。

各條文的不通過支數如下，14 個條文合計 1,574 條：

條文	內容	不通過支數
4.1.2.3.12	IPC：匯出元件沒有足夠權限保護	255
4.1.2.5.3	分享時未限定 App（與上條同一組證據）	255
4.1.2.4.1	允許明文傳輸或設定弱 TLS 版本	230
4.1.2.3.6	儲存加密使用弱演算法	177
4.1.5.4.2	SQL 字串拼接	135
4.2.2.1.2	WebView 不安全設定	113
4.1.4.2.3	主機名稱驗證放寬	92
4.1.4.2.2	伺服器憑證驗證停用	80
4.1.2.3.14	允許系統備份且無排除規則	73
4.1.2.3.16	以日誌輸出敏感欄位	46
4.1.5.1.2	函式庫含 CVSS 7 以上的已知漏洞	44
4.1.5.3.1	同上，同一組 CVE 證據對應本條	44
4.1.2.3.7	以全域可讀寫模式開檔	22
4.1.2.3.8	內嵌結構自證的私鑰或權杖	8

怎麼讀這些數字

一條不通過是一個「待人工複核的旗標」，不等於一個可被入侵的洞。旗標多有兩個原因。第一，系統採召回優先（定義見 A-1）：命中第三方函式庫仍輸出不通過，只是在證據上標注套件歸屬，留給人工快速撤銷，而不是隱藏成通過。第二，部分條文的門檻本來就低：允許備份的預設值、自訂 action 的匯出、任一明文設定，成熟 App 幾乎都會中。零不通過代表在 L3 範圍內工具沒有找到可定位的違反證據，需人工的檢測項仍要由檢測員完成。

工具的價值因此不是「零人工」，而是把人工從「盲目逆向整支 App」降為「複核一份已定位、已分類、已標歸屬的清單」：證據直接指到類別、檔案與條文；結構自證的機密、可偵錯、允許備份、自訂 action 匯出等可由工具終判；標為第三方的命中可以很快撤銷，真正需要判斷的是少數 App 自有的可疑項。

可回報分級

584 筆「確認的漏洞」不等於 584 件「該通報的事」。分級的依據是攻擊者需要什麼前置條件；它是對外揭露的優先序，不是 V4.0 條文判定，也不影響系統的判定結果。

等級	判準	筆數	App 數
A　可直接通報	機密可直接從安裝檔取出（A1），或 App 自有的主要連線停用 TLS 驗證（A2）	70	64
A?　通報前補一步確認	型態已確認，但還須確認受影響的是什麼資料	116	93
B　需要前置條件	需要誘導使用者或其他前置條件才碰得到敏感功能	271	178
C　不通報	沒有敏感資料經過、實為公開識別碼，或為教學用的靶機 App	127	97

四級筆數合計 584；同一支 App 可以同時出現在多個等級。A 級 70 筆中，A1 有 30 筆、A2 有 40 筆；A 級含 2 支公開的教學靶機（刻意寫壞的教材，沒有揭露對象），扣除後列入通報規劃的是 62 支、68 筆。

分級流程由本人設計：多個 AI agent 依完整的反編譯證據文字分批初判，本人逐批驗收並裁決爭議。專題前期逐支確認的 9 支機密外洩，全數落在 A1 之內。

系統對 A 級的判定也驗證了合約的設計：A1 的 30 筆中，結構自證的機密由系統自動判不通過（11 筆），沒有固定格式的機密（例如寫死的帳密）附線索交人工確認（19 筆）；A2 的 40 筆中 39 筆自動判不通過、1 筆交人工；兩類都沒有任何一筆被判為通過。

在不觸法的前提下確認漏洞為真

以取得的金鑰登入、連線或解密屬於未經授權的存取，觸法且違反研究倫理。本專題的確認只做辨識與定位，全部在本機離線進行：

結構自證：只有結構本身就能證明是私密憑證的物件，才視為機密外洩；只有標頭的函式庫模板、公開的測試金鑰與示範金鑰都依型態排除。
一致性驗證：伺服器私鑰與同一安裝檔內的憑證，以數學關係確認互相對應，再解碼憑證確認其用途；排除測試用的配對。
反編譯定位：以 jadx 追到使用位置，確認是 App 自有的程式碼，以及問題所在的連線或功能是否為主要功能。
逐筆覆核：每一筆高危候選都逐筆反組譯覆核，覆核中發現的誤判型態寫回系統規則。

沒有做的事同樣明確：不登入、不連線、不解密任何流量、不測試金鑰的有效期與權限範圍；這些留給廠商查證，是負責任揭露的標準分工。

遮蔽與保密

報告：系統報告中的私鑰本體一律不輸出，權杖只保留前綴。
比對基準鏡像：入版本控制的是遮罩後的鏡像，憑證字串只保留足以回到安裝檔定位、不足以使用的片段，並在重建後以偵測器掃描確認沒有殘留的憑證本體。未遮罩的原件只留在本機。
版本控制：倉庫維持私有；真實 App 語料、未遮罩的證據、具名的可回報分級報告與真實測試帳號皆不入庫。
對外資料：本站與技術摘要只寫方法與整體統計，不寫 App 名稱、套件名、主機名或雲端專案識別；含受測 App 識別資訊的完整成果報告（31 頁）依負責任揭露原則，於通報完成前不對外提供。

負責任揭露流程

依 ISO/IEC 29147 的原則：研究者只辨識與定位、不實際利用；私下通報廠商，由廠商驗證並修補後才公開。本專題的規劃：

優先序：可直接取出的機密最優先，循 TWCERT/CC 或各廠商的資安聯絡管道通報，由廠商撤銷並更換；TLS 驗證停用屬 App 端修補。
通報前逐案再確認：分析結果綁定特定版本的安裝檔（以 SHA-256 記錄），廠商可能已在新版修正；通報前逐案確認現況。A? 級在補完確認之前不通報。
材料：依實際危害排序整理，分具名版（供通報）與代稱版（供對外說明），兩者皆不含機密字面。
決定權：通報對象與時程由指導教授與本人依上述原則共同決定。

研究倫理

語料只取自公開上架的安裝檔，分析在本機進行。
發現的機密不用於任何連線或存取，不嘗試驗證其權限，也不以任何方式利用漏洞。
對外只呈現方法與整體統計，不使用能把範圍縮到少數機構的描述。
研究結果只供教學與負責任揭露使用。