應對蘋果的 Bitcode 變更：利用 ARM 保護增強應用安全性

水平集

人盡皆知，這成了茶水間最熱門的話題。蘋果將在 Xcode 15 中移除嵌入式位元代碼。舊王已逝，新王萬歲！

嵌入式位碼最初似乎是為了允許開發者提交一個應用程序，使其能夠在所有蘋果產品上運行。位元碼可以有效解決處理不同處理器架構帶來的諸多難題。雖然蘋果早已明確計劃將其所有產品線標準化為 arm64 架構，但嵌入式位碼可以更輕鬆地實現跨平台支持，並賦予蘋果對 App Store 中應用程式編譯過程相當大的控制權。這項功能並未像蘋果預期的那樣廣泛應用，但其移除卻對整個蘋果的開發者生態系統產生了巨大影響。

安全社群中一些人曾提及蘋果將徹底放棄 LLVM，這種說法近乎危言聳聽。雖然這項變革確實略微降低了蘋果對 LLVM 的整體依賴，但這並不意味著蘋果打算讓 Swift 開源社群也放棄 LLVM。如果蘋果真的放棄 LLVM，那將是一個重大改變，甚至可能宣告建置時位程式碼保護機制的終結。 Swift 是蘋果官網上列出的第一個開源項目，其開發者也一直持續貢獻程式碼。他們最新的作業系統 xrOS（可以稱之為 iMask）已經加入了 LLVM 分支。儘管蘋果並不害怕做出重大變革，但目前沒有任何跡象表明他們會放棄 LLVM。雖然這種可能性存在，但這並非短期內會發生，任何相反的說法都顯得不夠真誠。目前依賴建置時位程式碼的解決方案不會消失，我們將繼續積極支援和開發針對蘋果產品的應用程式保護機制。也就是說，在建置時整合的保護工具整合起來要困難得多，而且在工具鏈發生變化時也很容易受到損害。

後期建構相對於建置時間的優勢

蘋果最初允許並將位元程式碼嵌入二進位檔案中，這一做法對位元程式碼保護工具而言意義重大。建置時整合不穩定，需要大量的 Xcode 相關維護，並且會為組織帶來許多麻煩。建置時保護工具往往會對組織變更或升級其建置系統的能力產生負面影響，甚至會阻礙其升級。建置後保護是未來的發展方向，但未來已不再需要位代碼。這就只剩下彙編級保護了。雖然彙編程式碼可能很複雜且難以修改，但最終結果是能夠提供更靈活的保護，不受特定工具鏈的限制，並提供更廣泛的保護功能。

位元程式碼相對於彙編語言的優勢

位元碼的主要優勢之一是其（基本）與處理器無關的表示方式。然而，隨著蘋果將所有產品標準化為基於 arm64 指令集，這一優勢如今已不再那麼重要。這種轉變使得所有基於蘋果的保護工具都能專注於 arm64 彙編。 arm64 指令集是一個強大且易於理解的標準，它允許我們採用更有針對性的方法來抵禦靜態和動態分析。雖然由於分析方法的不完善，對 Mach-O 二進位檔案應用保護措施更加困難，但最終的保護效果卻更加強大。我們基於 ARM 的保護工具能夠成功地將 IPA 和 Xcarchive 應用套件進行混淆，並添加動態環境保護。保護原生彙編程式碼能夠實現更全面的安全策略。應用程式包中的所有二進位檔案都可以透過一次呼叫進行保護。保護使用 Swift Package Manager 建置的框架也變得輕而易舉，不再像以前那樣複雜或不可能。

ARM彙編

arm64 指令集（特別是 armv8 版本）並不複雜，而且效率極高。在分析和混淆方面，它比 x86 彙編語言具有一些顯著優勢。最重要的是，所有 arm64 指令的長度都剛好為 4 個位元組。此外，程式碼中似乎很少使用資料（除了 switch 表）。這兩點大大簡化了二進制分析。正如那句老話所說：“全面的二進制分析是建立穩健混淆策略的第一步。”

我們用於規避靜態分析的一種更有效的混淆方法是程式碼拆分。將單一子程式分解成數百個片段並分散開來，可以極大地阻礙控制流分析。移動這些片段本身就很困難，而正確地連接它們則更加困難。我們內部將這些連結稱為「跳躍」；遺憾的是，並非所有跳躍都具有相同的效果。可預測性是安全性的敵人，因此充分利用各種類型的跳躍至關重要。例如，AB（分支）指令的範圍只有+/-128MB，而BR（跳到暫存器）指令的範圍則非常寬。但是，BR指令需要一個包含跳到位址的暫存器。並非所有暫存器都支援BR指令。 safe 在二進位檔案執行的任何階段都可以寫入，而有些二進位檔案（例如 x18）則永遠不會寫入。 safe 使用起來。所有控制流程指令都有其優缺點，要找到最適合的指令並非易事。一旦將 chopup 與數萬條指令替換混淆結合使用，攻擊者就必須像 Pogopalooza 世界冠軍一樣在 Ghidra 中四處跳躍，才能勉強讀取一個子程序。

啟用混合保護

混合應用領域本身就存在相當多的跳躍式開發，值得慶幸的是，彙編級保護也使得混合保護變得更加便捷和全面。 Flutter 應用程式無法利用位碼保護方案，因為 Flutter 的建置系統沒有存取位碼的路徑。同樣，微軟的 .NET 7+ 及其 MAUI 也限制了位元碼的輸出。然而，Flutter 和其他混合框架確實使用 AoT 編譯來建立 arm64 二進位。建置後的 ARM 保護可以像其他 iOS 應用程式一樣，對這些二進位檔案進行混淆並添加主動保護。保護措施幾乎適用於所有 iOS 應用程式套件。讓開發團隊只需一次呼叫即可保護應用程式包中的所有二進位文件，這才是真正的左移保護。

建置後如何整合到持續整合中

CI/CD DevSecOps 流水線如今已成為業界公認的標​​準，而調試管線中的建造時問題無疑是最令人沮喪的事情。在建置之後、測試之前，只需向 CI/CD 系統新增一次調用，即可輕鬆集成，並保持開發、測試和交付流程的順暢。 DevOps 團隊全速運轉。建造後保護可以成為常規 CI/CD 流水線的一部分。這意味著無需在每台開發人員機器上安裝和授權保護工具，也無需在每次開發建置期間執行。我們已經看到，即使在建構良好的 CI/CD 環境中，建置時保護也會導致無數問題。切換到建置後安全解決方案，可以讓團隊掌控並修改他們的建置流程，同時確保 CI/CD 運作順利，讓開發團隊滿意。我們的團隊喜歡綠色；畢竟，綠色就在我們的標誌上。最後，請始終記住：16 位元組對齊的堆疊指標可以避免 EXC_BAD_ACCESS 錯誤。

 

進一步探索 ARM 保護在 iOS 應用程式安全領域的未來發展及其作用。 safe請閱讀我們的部落格文章，了解如何保護您的應用程式免受不斷演變的威脅。隆重介紹 ARM 保護：iOS 應用安全領域的顛覆性變革