標題：為macOS構建自定義Mach-O內存加載器

在上一篇文章中，我們介紹瞭如何修復dyld以恢復內存執行。這種方法的優點之一是，我們將加載Mach-O二進製文件的許多複雜工作委託給macOS。但如果我們在不使用dyld的情況下，創建我們自己的加載器呢？所有這些字節映射是如何工作的？

接下來，我們將介紹如何在不使用dyld的情況下在MacOS Ventura中為Mach-O包構建內存加載器，以及Mach-O文件的組成，dyld如何處理加載命令以將區域映射到內存中。

為了配合蘋果向ARM架構的遷移，這篇文章將重點介紹MacOS Ventura的AARCH64版本和針對MacOS 12.0及更高版本的XCode。

什麼是Mach-O文件？首先介紹一下Mach-O文件的架構，建議先閱讀一下Aidan Steele的Mach-O文件格式參考。

當我們在處理ARM版本的MacOS時，會假設正在查看的Mach-O沒有被封裝在Universal 2格式中，因此在文件開頭我們首先會遇到的是Mach_header_64：

要構造加載器，我們需要檢查以下幾個字段：

magic-此字段應包含MH_magic_64的值；

Cputype-對於M1，應為CPU_TYPE_ARM64。

filetype -我們將檢查這篇文章的MH_BUNDLE類型，但加載不同類型也應該很容易。

如果Mach-O是正常的，我們可以立即處理mach_header_64結構體後面的load命令。

加載命令顧名思義，load命令是一種數據結構，用於指示dyld如何加載Mach-O區域。

每個load命令由load_command結構表示：

cmd字段最終決定load_command實際表示的內容，以LC_UUID的一個非常簡單的load_command為例，該命令用於將UUID與二進制數據關聯起來。其結構如下：

如上所述，這與load_command結構重疊，這就是為什麼我們有匹配字段的原因。以下就是我們將看到的各種負載命令所支持的情況。

Mach-O段加載Mach-O時，我們要處理的第一個load_command是LC_SEGMENT_64。

segment命令告訴dyld如何將Mach-O的一個區域映射到虛擬內存中，它應該有多大，應該有什麼樣的保護，以及文件的內容在哪裡。讓我們來看看它的結構：

出於本文的目的，我們將關注：

segname -段的名稱，例如__TEXT；

vmaddr -應該加載段的虛擬地址。例如，如果它被設置為0x4000，那麼我們將在分配的內存基數+0x4000處加載段；

vmsize -要分配的虛擬內存的大小；

fileoff -從文件開始到應複製到虛擬內存的Mach-O內容的偏移量；

filesize -要從文件中復制的字節數；

maxprot-應分配給虛擬內存區域的最大內存保護值；

initprot -應分配給虛擬內存區域的初始內存保護；

nsects -遵循此段結構的節數。

要注意，雖然dyld依賴mmap將Mach-O的片段拉入內存，但如果我們的初始進程是作為一個加固進程執行的(並且沒有com.apple.security.cs. c . data . data之類的文件)。使用mmap是不可能的，除非我們提供的bundle是使用與代理應用程序相同的開發人員證書進行簽名的。此外，我們正在嘗試構建一個內存加載器，因此在這種情況下從磁盤拉二進製文件沒有多大意義。

為了解決這個問題，在此POC中，我們將預先分配我們的blob內存並複制它，例如：

與之前的dyld文章一樣，我們需要在主機二進製文件中使用正確的授權來允許無符號可執行內存。

節從上面的字段中可以看到，段加載命令中存在另一個引用，這就是一個節（section）。

由於節位於段中，雖然它將繼承其內存保護，但它有自己的大小和要加載的文件內容。每個段的數據結構附加到segment命令中，其結構為：

同樣，我們將只關注其中幾個字段，這些字段對於我們構建加載器的直接目的很有幫助：

sectname -節的名稱，例如__text；

segname -與此節關聯的段的名稱；

addr -用於此節的虛擬地址偏移量；

size -文件中(以及虛擬內存中的)節的大小；

offset - Mach-O文件中部分內容的偏移量；

flags - flags可以分配給一個節，這個節幫助確定reserved1,reserved2和reserved3中的值。

由於我們已經分配了每個段，所以加載器將遍歷每個段描述符，確保將正確的文件內容複製到虛擬內存中。需要注意的是，在復制時可能需要更新內存保護。 MacOS for ARM不允許讀/寫/執行內存頁(除非com.apple.security.cs. c。allow-jit授權與MAP_JIT一起使用)，因此我們需要在復制時適應這一點：

符號隨著我們的加載器開始成型，接下來需要看看如何處理符號（Symbol）。符號在Mach-O二進製文件的加載過程中扮演著重要的角色，它將名稱和序數關聯到內存區域，以供我們稍後參考。

符號是通過LC_SYMTAB的加載命令來處理的，如下所示：

同樣，我們將關注構建加載器所需的字段：

symoff -從文件開始到包含每個符號信息的nlist結構數組的偏移量；

nsyms -符號(或nlist結構)的數量；

stroff -符號查找所使用的字符串的文件偏移量。

顯然，接下來我們需要知道nlist是什麼：

此結構為我們提供了有關命名符號的信息：

n_strx -從符號字符串字段到該符號字符串的偏移量；

n_value -包含符號的值，例如地址。

因為我們稍後需要引用符號，所以我們的加載器需要存儲這些信息以備以後使用：

dylib’s接下來是LC_LOAD_DYLIB加載命令，該命令引用在運行時加載的額外dylib’s。

我們需要的項在dylib結構成員中找到，特別是dylib.name.offset，它是從這個加載命令的開頭到包含要加載的dylib的字符串的偏移量。

稍後，當涉及到重定位時，我們將需要這些信息，其中dylib’s的導入順序起著重要作用，因此我們將構建一個dylib’s數組，供以後使用：

遷移現在就要介紹Mach-O更複雜的部分——遷移。

Mach-O是用XCode構建的，目標是macOS 12.0和更高版本，使用LC_DYLD_CHAINED_FIXUPS的加載命令。關於這一切是如何工作的，沒有太多的文檔，但Noah Martin對iOS 15查找鏈的研究值得參考，我們還可以在這裡找到蘋果XNUrepo中使用的結構體的詳細信息。

Dyld’s的源代碼告訴我們，該加載命令以結構linkedit_data_command開始：

使用dataoff便能找到標頭：

我們需要做的第一件事是收集所有導入並構造一個稍後將引用的有序數組。為此，我們將使用以下字段：

symbols_offset -從該結構開始到導入所使用的符號字符串的偏移量；

imports_count -導入項的數量；

imports_format -任何導入符號的格式。

imports_offset -從該結構開始到導入表的偏移量。

每個導入項的數據結構都依賴於imports_format字段，但通常我看到的是DYLD_CHAINED_IMPORT格式：

可以看出這是一個32位數組項，有lib_ordinal字段，它是我們之前從LC_LOAD_DYLIB加載命令構建的有序dylib數組的索引。索引從1開始，而不是0，這意味著第一個索引是1，然後是2……

如果索引值為0或253，則該項引用this-image(當前正在執行的二進製文件)。這就是我們之前構造符號字典的原因，因為現在我們可以簡單地將自己二進製文件中引用的符號名稱解析為其地址：

name_offset是從dyld_chained_fixups_header收集的symbols_offset字符串的偏移量。

使用這些信息，我們需要構建一個有序的導入數組，因為我們需要馬上引用這個有序數組。

構建了一個導入列表後，將開始鍊式啟動，這可以從dyld_chained_fixups_header結構的starts_offset標頭字段中找到。

鍊式啟動的結構是:

為了導航，我們需要遍歷seg_info_offset中的每個項，這為我們提供了指向dyld_chained_starts_in_segment的指針列表：

首先要注意這個結構，有時segment_offset是0，但不知道為什麼，看起來dyld也識別了這個，只是忽略了它們。

我們需要找到每個reloc鏈的開始位置的字段如下：

pointer_format-鏈使用的DYLD_CHAINED_PTR_結構的類型；

segment_offset-段起始地址在內存中的絕對偏移量；

page_count-page_start成員數組中的頁數；

page_start-從頁面到鏈開始的偏移量。

當我們在一個段中有一個有效的偏移量時，我們可以開始遵循reloc鏈。遍歷每個項，我們需要檢查第一位，以確定該項是一個rebase(設置為0)還是一個bind(設置為1)：

在rebase的情況下，將該項轉換為dyld_chained_ptr_64_rebase，並使用目標偏移量更新該項到已分配內存的基數。

在綁定的情況下，我們使用dyld_chained_ptr_64_bind，序數字段是我們前面構建的導入數組的偏移量。

然後，我們需要移動到下一個bind或rebase，這是通過執行next*4（4字節是步長）來完成的。我們重複此操作，直到下一個字段為0，表示鏈已結束。

構建加載器現在一切就緒，開始構建加載器。步驟如下：

1.分配內存區域；

2.根據LC_SEGMENT_64命令將每個段加載到虛擬內存中；

3.將每個節加載到每個段中；

4.從LC_LOAD_DYLIB命令構建dylib的有序集合；

5.從LC_SYMTAB命令構建一個符號集合。

6.遍歷LC_DYLD_CHAINED_FIXUPS鏈並對每個reloc進行bind或rebase。

一旦完成，我們就可以使用LC_SYMTAB中的數據來引用我們想要輸入的符號並傳遞執行。如果一切順利，我們將看到Mach-O被加載到內存中並開始執行：

這個POC的所有代碼都已添加到Dyld-DeNeuralyzer項目。

雖然你可以使用其中的代碼加載C/c++包，但如果你嘗試加載Objective-C包，你會看到如下的內容：

這是因為在加載Objective-C Mach-O時dyld中發生了一些事情，具體原因我們下一部分再講。