無論目標是竊取知識產權、獲取敏感用戶信息,還是訪問後端伺服器上的任何內容,許多定向攻擊都始於對客戶端應用程式進行逆向工程,以了解其結構並識別薄弱環節。即使最終攻擊發生在後端,分析客戶端對應部分通常也能揭示其 API 和身份驗證機制的關鍵資訊。
因此,我們認為代碼加固是 對於任何使用原創演算法或處理敏感資料的應用程式而言,這是不可協商的。.
2023年,OWASP定義了其第二版安全協定。 電話 Application Security 驗證標準(MASVS)它為試圖保護其行動應用程式的應用程式開發人員以及試圖尋找其中漏洞的安全測試人員提供了一套指導方針。它還提供 Application Security 像產品供應商這樣的 Digital.ai 一個用於思考當今應用安全情勢的框架。 OWASP MASVS-韌性 控制方式與方法完美契合 Digital.ai (以及之前的 Arxan)都考慮到了代碼加固和防篡改:
- MASVS-RESILIENCE-1該應用程式驗證平台的完整性。
- MASVS-RESILIENCE-2該應用程式實現了防篡改機制。
- MASVS-RESILIENCE-3該應用程式實現了防靜電分析機制。
- MASVS-RESILIENCE-4該應用程式實現了反動態分析技術。
雖然防篡改和防動態分析能夠確保平台的完整性,但如果沒有防靜態分析,它們很容易被高階攻擊者發現並消除。
考慮到這一點,我們首先來評估一下如今的應用程式實現以下功能的一般程度: MASVS-RESILIENCE-3 為了進行控制,我們審查了 Google Play 上 40 款熱門免費應用程式,尋找程式碼混淆的明顯跡象。
我們發現了什麼
為了充分理解我們的發現,我們首先需要描述我們的方法。像 Java 和 Kotlin 這樣的基於字節碼的語言通常會保留類別名稱和方法名稱。即使程式碼經過混淆處理,這些識別碼仍然可以為逆向工程師提供足夠的線索,幫助他們理解應用程式的架構並發動攻擊。重新命名(或名稱混淆)會從程式碼中移除這些識別資訊。由於重新命名(即缺少可讀標識符)的存在非常直觀且易於識別,因此我們將其作為本次分析的標準之一。
在反編譯目標應用程式後,我們根據重命名覆蓋率將其分為 3 類:
- 禁止重命名應用程式中沒有任何內容被重新命名,這表示安全性不存在或很弱。
- 本地重命名:只有應用程式的某些特定部分被重新命名,這可能表示使用了執行時間應用程式自我保護 (RASP) 程式庫來確保安全,或是一種低成本的配置。
- 全球重命名大部分程式碼都已重新命名,顯示採用了全面的安全解決方案和周全的配置。
在選定的應用程式中,37% 完全沒有保護,28% 只重命名了少數幾個類,其餘 35% 的大多數類都進行了重命名。
需要注意的是,僅重命名某些元件(佔分析應用程式總數的 28%)實際上可以使這些部分更加顯眼,因為這樣做會突出顯示攻擊者可以重點關注並移除的最敏感邏輯或安全控制。相反,在整個程式碼庫中更統一地應用重新命名(佔分析應用程式總數的 35%)則會隱藏這些訊號,使識別有價值的目標變得更加困難。這使得解構受保護的程式碼變得更加困難,並顯著增加了應用程式逆向工程所需的時間(這才是攻擊者真正最重要且最有限的資源)。在許多情況下,僅此一項增加的複雜性就足以阻止進一步的攻擊嘗試。

這些結果表明,相當一部分應用程式開發者至少在保護應用程式安全方面進行了一些思考,但至少有三分之一備受關注的應用程式仍然帶著可以輕鬆被檢查、修改和重新打包的程式碼推向市場。
這是什麼意思?
這一點至關重要,因為未受保護或保護措施薄弱的應用程式更容易遭受逆向工程和篡改。對於大多數應用程式而言,這可能意味著智慧財產權洩露、API金鑰暴露或業務邏輯洩露,從而被攻擊者利用。對於遊戲而言,這會導致作弊、修改或克隆版本發布,直接影響收入和品牌聲譽。目前的分佈情況表明,雖然一些團隊重視安全,但許多團隊仍然將大量程式碼庫暴露在外。
顯而易見,即使在備受矚目的應用程式中,基本的客戶端保護也尚未成為通用標準,因此亟需提高一致性和安全性意識。本系列的下一篇文章將深入探討,與完全缺乏保護或僅提供少量保護的應用相比,分析一個安全措施完善的應用究竟有多大的難度。