崩潰日誌和混淆：速成課程

調試運行時崩潰可能是一個痛苦的過程。 iOS 應用程式在實際使用上崩潰設備僅包含崩潰時運行進程的記憶體位址和偏移量資訊。這些資訊以堆疊追蹤的形式呈現，堆疊追蹤是一系列按最近執行順序排列的方法呼叫列表，指向崩潰發生的位置。堆疊追蹤的詳細程度各不相同，並且已有相應的機制幫助開發人員充分利用這些堆疊追蹤資訊。 

然而，安全工程師普遍存在一個誤解，認為強化後的應用程式會破壞常用的現場偵錯工具（例如 Firebase Crashlytics），使理解應用程式崩潰變得更加困難。但事實並非如此；應用程式可以兼具強大的安全性和可操作、相關的崩潰日誌。那麼，我們該如何做到這一點呢？ 

為了幫助開發者取得易於理解的 iOS 應用程式崩潰日誌，他們可以使用 dSYM 檔案。 dSYM 檔案包含用於偵錯的符號訊息，可以在 Xcode 建置過程中產生。我們將介紹這些文件的內容、用途以及使用方法。 Digital.ai Application Security 產品與此機制集成，使調試安全應用程式成為可能。 

讓我們透過一個使用我們開源軟體的例子來完成這項工作。 工作調度員 iOS 應用程序。  

dSYM 包包含什麼？ 

dSYM（調試符號的縮寫）套件包含有關您的 iOS/tvOS/macOS 應用程式的符號和原始程式碼行資訊。當您使用的建置配置的「偵錯資訊格式」設定為「DWARF with dSYM File」時，Xcode 會產生這些檔案：

你可能會問：為什麼要把所有符號檔案放在一個單獨的檔案中，而不是直接放在應用程式內部？主要原因是為了方便調試和移植。你可以建立一個應用程序，然後在另一台機器上進行調試，而無需使用建置時使用的目標檔案。 dSYM 還允許你調試應用程式的發布版本，這可以節省大量時間。  

現在我們已經介紹了 dSYM 是什麼，以及為什麼它很重要，讓我們打開剛剛建立的 .xcarchive，看看下面的「Job Dispatcher.app.dSYM」套件。

Job Dispatcher 只有一個主應用程式包，但如果您的專案在建置過程中建置了其他程式庫或框架，則可以產生更多套件。 

那麼，dSYM 包裡到底包含什麼呢？如果我們右鍵單擊該包並選擇“顯示包內容”，就可以看到以下內容：

T他 '訊息.plist' 文件 只是 包含 met關於 b 的數據自行解開 不 很有用. B另一個“約伯記‬ Dispatcher.yml' 文件和“工作調度員 馬赫 - O 偵錯 文件 包含 符號 名稱和地點 以及我們所關心的. 讓我們 打開 ''約伯記‬ Dispatcher.yml' 文件 （圖片已截斷以簡潔顯示）:

在這裡，我們可以看到二進位檔案中每個符號的屬性清單。例如，“大小” 與指標的大小相關（所有這些都是 64 位元符號），'符號名稱' 對應符號的名稱，'symBinAddr' 是符號在二進位代碼中存在的位置，且'symSize' 這是函數或資料物件的大小。此文件主要關注重定位訊息，這是 AArch64 架構的重要組成部分，但我們在此不做深入探討。  

現在我們來看看 DWARF 資料夾中名為「Job Dispatcher」的檔案。這個二進位檔案包含了我們建立的應用程式中所有符號的詳細偵錯資訊（如您所見，DWARF 檔案和應用程式的名稱相同）。我們可以執行「dwarfdump」指令來取得該檔案中資訊的易讀轉儲。讓我們來看看… 認證 符號：

其中幾個值得注意的特性是： DW_AT_decl_file 以及 DW_AT_decl_line這告訴我們， 認證 此函數定義於「LoginFunc.m」檔案的第13行。另一個屬性是 DW_AT_型這會告訴我們函數的類型（在本例中是布林值）。每個符號在 DWARF 檔案中都有一個類似的部分，其中包含解釋其含義、定義位置等資訊。 

雖然 dSYM 套件的內容解析起來可能相當複雜，但並非每個人都需要了解這些才能實際使用它。接下來，我們將探討在即時調試崩潰問題時，dSYM 究竟能為我們做些什麼。 

dSYM 的實際應用 

讓我們透過強制 Job Dispatcher 崩潰來看看 dSYM 的強大之處。我們可以透過在程式碼的第 14 行和第 15 行給空指標賦值來實現這一點。 認證 功能：

日期 我們運行應用程式時出去 a聯繫 dSYM應用程式崩潰了, 以及 我們得到如下堆疊追蹤資訊：

現在, 這是 當然可以調試應用程式。 利用這些資訊. 每 堆疊幀包含有關崩潰地址的信息 以及偏移量 來自 (沒什麼幫助) 崩潰發生的符號名稱。 然而，你理解此堆疊追蹤需要s 對二進制的深入分析 本身和 提供 幾乎沒有 洞察 加到 是原始碼的哪一部分導致了這個問題. 將此結果與崩潰日誌進行比較 dSYM 資訊／最新消息 可用的:

每個堆疊幀仍然包含應用程式崩潰的地址，但符號資訊更加完整。我們可以看到崩潰發生在… _認證 崩潰發生在「LoginFunc.m」檔案的第15行（也就是我們在原始碼中觸發崩潰的位置）。所有崩潰報告工具（例如Firebase Crashlytics、BugSnag、Instabug等）的目標都是重現這種易於理解的堆疊追蹤訊息，因此這些工具要求您上傳dSYM套件才能實現此功能。 

應用程式安全在這一切中扮演什麼角色？ 

我們目前討論的關於 dSYM 的所有內容都基於這樣一個前提：我們使用 Xcode 建立的應用程式完全未被修改。如果我們想在將應用程式提交到應用程式商店之前保護它免受惡意攻擊者的侵害，該怎麼辦？ 

在加密保護期間，二進位檔案的順序會被打亂，導致新混淆的符號位置與 dSYM 套件中的資訊不再相符。如果我們嘗試使用未加密應用程式的 dSYM 套件來對受保護應用程式的崩潰進行符號化，結果將毫無意義。有什麼辦法可以解決這個問題嗎？ 

後期建造保護與內建保護 

我們的 行動裝置應用程式保護：ARM 該產品是一種無需任何配置即可使用的建置後保護解決方案。這使得保護應用程式免受威脅變得更加容易，並且開發人員在測試受保護的應用程式時可以獲得更好的回饋，因為它只需建置一次。但是，如前所述，這存在一個缺點，即原始的 dSYM 套件與受保護的應用程式不相容。開發人員必須在保護後重新編寫 dSYM 文件，以應對程式碼變更並標記潛在的當機。 

另一方面，我們無需重新編寫 Xcode 生成的 dSYM 檔案即可保護應用程式。我們的 Apple Native 應用程式保護產品具備此功能，因為它是內建保護解決方案。應用程式在編譯和連結時，會啟用各種安全功能，並與原始原始碼一起運行。這使得對受保護應用程式進行符號化成為可能，因為生成的 dSYM 檔案結構能夠涵蓋建置中指定的所有內容。缺點是，建置時保護需要開發人員進行更多配置，隨著應用程式規模的增加和複雜性的增加，配置難度也會增加。 

包裝東西 

希望這能讓大家對 dSYM 套件的重要性、其內部結構、使用方法以及現有的解決方案有所了解，從而確保注重安全的工程師不必為了使用簡化 iOS 應用程式調試的工具而做出任何犧牲。