APKSec Pro 代表發現：真實上架 App 的高風險型態

負責任揭露：以下只呈現問題型態、發現方式與可能後果，供理解檢測能力之用。受影響 App 的名稱、套件名、主機名與機密內容，在通報完成前一律不公開；描述刻意保持在型態與產業大類，不縮到可指認的單一機構。分級依據與完整流程見 A-3 實證與負責任揭露。

這些發現是什麼

工具對 400 支上架 App 以最嚴格的分級統一檢測，再把經反編譯逐支審查、判定為 App 自有的不通過（584 筆）依攻擊者所需的前置條件分級。其中「可直接通報」的 A 級有 68 筆、62 支 App（扣除公開教學靶機）。

把這些問題歸納，最具代表性的是以下四個型態。每一型都不是單一個案，而是在多支不同 App、橫跨金融、醫療、政府與交通、生活等類別反覆出現的結構性問題。筆數取自 A-3 的可回報分級。

這是最高優先、也最能說明問題的一類：機密直接被打包進公開可下載的安裝檔，任何人解包即得。

型態APK 內含結構自證的私密憑證，例如雲端服務帳戶（service account）的金鑰、後端伺服器 TLS 憑證對應的私鑰，或可直接使用的存取權杖。這類物件的格式本身就足以證明是真憑證，而非函式庫樣板或公開的測試金鑰。

怎麼發現靜態反編譯後定位到金鑰物件，再以密碼學函式庫離線確認：結構自證者依格式與指紋判別；伺服器私鑰則與同一安裝檔內的憑證以數學關係確認互相對應，並解碼憑證確認用途，排除測試用的配對。

可能後果取得這類金鑰者，可冒用該 App 後端的雲端或伺服器身分、存取其資源或解密其連線。因為機密就在安裝檔裡，攻擊者不需任何前置條件，所以列為可直接通報的最高優先。

研究倫理只辨識、定位並遮蔽記錄；不以任何金鑰登入、連線或解密，不測試其權限與有效期，這些都留給廠商查證。專題前期逐支人工確認的機密外洩案例，全部落在這一類之內。

憑證驗證是 App 與伺服器之間防止被竊聽、被竄改的基礎；這一類把它關掉了。

型態App 自有、且用於主要連線的憑證驗證形同虛設：TrustManager 空實作（接受任何憑證）、主機名稱驗證恆真，或網路安全組態信任使用者自行安裝的 CA。

怎麼發現靜態分析位元碼中的信任判斷實作，確認是 App 自有的程式碼、且掛在主要連線上，而非測試或第三方函式庫的預設。

可能後果與使用者處於同一網段的攻擊者，可攔截、解密並竄改該 App 的加密流量，包含登入憑證與個人資料；信任使用者 CA 者，只要裝置裝了一張憑證即可全量攔截。

研究倫理僅以靜態分析判定，未實際對任何連線進行攔截或中間人測試。

有些 App 想保護敏感欄位，卻用了解包後就能還原的方式。

型態以安裝檔內硬編碼的固定金鑰，搭配弱模式（ECB、或固定不變的 IV／nonce），加密密碼、帳單參數或權杖等敏感欄位。

怎麼發現反編譯取得金鑰常數與加密演算法，確認模式與金鑰來源。

可能後果任何人取得安裝檔即可離線算出金鑰，解密或偽造受保護的資料；固定 IV 還會讓相同明文產生相同密文，可跨使用者比對、洩漏結構。

研究倫理僅靜態判定，未解密任何實際流量。

把網頁內容接進 App 的原生能力時，若邊界沒守好，網頁端的問題會變成 App 的問題。

型態WebView 開啟 JavaScript 並掛上原生橋接（addJavascriptInterface），而載入的網址可由外部指定（例如經匯出元件或 deep link），或同一 WebView 的憑證驗證可被繞過。

怎麼發現靜態追蹤橋接方法、載入來源與憑證處理，確認外部可控的輸入能走到具原生能力的 WebView。

可能後果被誘導開啟、或被中間人竄改的頁面，其 JavaScript 可呼叫 App 的原生橋接，取用存取權杖、通訊錄等能力；實際衝擊視橋接暴露的方法而定。

研究倫理僅靜態判定橋接面與可達性，未實際注入或執行任何攻擊。

這四個型態共同說明了 APKSec Pro 的設計目標：把人工從「盲目逆向整支 App」降為「覆核一份已定位、分類並標好歸屬的清單」。結構自證的機密、停用的 TLS 驗證等可由工具直接終判；有訊號但需判斷的附線索交人工。真正要人做的，是少數 App 自有的可疑項，而不是每一支都從頭讀起。

完整的檢測方法見 A-1 系統與判定方法，零漏報的驗證見 A-2 驗證體系，分級與負責任揭露流程見 A-3 實證與揭露。