iOS應用代碼註入防護
那麽應用安全的問題涉及到很多方面。比如防止靜態分析的,代碼混淆、邏輯混淆;防止重簽名的,應用ID檢測、甚至是代碼的HASH檢測等等。那麽這篇文章我想聊聊關於代碼的註入檢測,因為發現隨著iOS系統的更新,我們防護的手段發生了一些變化。
代碼註入的方式
代碼註入的方式大致分為兩種
- 越獄註入:通過修改
DYLD_INSERT_LIBRARIES
環境變量的值,來插入動態庫並執行 - 非越獄註入:
- 直接將自定義的Framwork或者dylib庫打包進入APP並重簽名。
- 利用yololib修改MachO文件,添加庫路徑.在應用啟動時,dyld會加載並執行.
早期防護方式
在工程的Build Settings中找到Other Linker Flages 並添加字段-Wl,-sectcreate,__RESTRICT,__raestrict,/dev/null
此操作的作用是在可執行文件中添加一個Section.我們使用MachOView分析如下:
當MachO文件中擁有這個字段,那麽我們通過越獄環境插入動態庫的方式就會失效.起到防護的作用.其原理在DYLD源碼中可以分析到.
dyld源碼分析
首先這裏分析的DYLD源碼版本是519.2.2版本.
我們可以通過檢索DYLD_INSERT_LIBRARIES定位到_main函數加載插入動態庫的代碼如下.
// load any inserted libraries
if ( sEnv.DYLD_INSERT_LIBRARIES != NULL ) {
for (const char* const* lib = sEnv.DYLD_INSERT_LIBRARIES; *lib != NULL; ++lib)
loadInsertedDylib(*lib);
}
但是早在這個環境變量判斷之前,dyld已經做了一個判斷
if ( gLinkContext.processIsRestricted ) { pruneEnvironmentVariables(envp, &apple); // set again because envp and apple may have changed or moved setContext(mainExecutableMH, argc, argv, envp, apple); }
如果判斷出進程是restricted!也就是當前進程是限制插入動態庫的!就會調用pruneEnvironmentVariables函數移除相關的環境變量.
那麽我們的processIsRestricted值什麽時候為true呢?
繼續分析源碼可以發現兩個關鍵函數影響其值.其中 hasRestrictedSegment 函數專門檢測RESTRICT段
// any processes with setuid or setgid bit set or with __RESTRICT segment is restricted
if ( issetugid() || hasRestrictedSegment(mainExecutableMH) ) {
gLinkContext.processIsRestricted = true;
}
通過註釋也能發現.任意進程的__RESTRICT段設置為restricted動態庫插入將被限制.
我們進入到processIsRestricted函數內,實現如下.
#if __MAC_OS_X_VERSION_MIN_REQUIRED
static bool hasRestrictedSegment(const macho_header* mh)
{
const uint32_t cmd_count = mh->ncmds;
const struct load_command* const cmds = (struct load_command*)(((char*)mh)+sizeof(macho_header));
const struct load_command* cmd = cmds;
for (uint32_t i = 0; i < cmd_count; ++i) {
switch (cmd->cmd) {
case LC_SEGMENT_COMMAND:
{
const struct macho_segment_command* seg = (struct macho_segment_command*)cmd;
//dyld::log("seg name: %s\n", seg->segname);
if (strcmp(seg->segname, "__RESTRICT") == 0) {
const struct macho_section* const sectionsStart = (struct macho_section*)((char*)seg + sizeof(struct macho_segment_command));
const struct macho_section* const sectionsEnd = §ionsStart[seg->nsects];
for (const struct macho_section* sect=sectionsStart; sect < sectionsEnd; ++sect) {
if (strcmp(sect->sectname, "__restrict") == 0)
return true;
}
}
}
break;
}
cmd = (const struct load_command*)(((char*)cmd)+cmd->cmdsize);
}
return false;
}
所以通過添加Other Linker Flags 在MachO中設置RESTRICT段賦值為restricted可以用來防護越獄的代碼註入.
但是新版的dyld源碼中去掉了__RESTRICT檢測.從iOS10開始,這種防護手段已失效
DYLD_INSERT_LIBRARIES 檢測
那麽既然dyld加載過程不再檢測__RESTRICT段了我們就手動的檢測DYLD_INSERT_LIBRARIES
環境變量.通過函數可查看當前進程環境變量的值.
char *env = getenv("DYLD_INSERT_LIBRARIES");
NSLog(@"%s",env);
在沒有插入動態庫時,env為null.
那麽一旦為自己的應用寫入插件時,我們就可以看到控制臺的輸出
2019-01-03 19:20:37.285 antiInject[7482:630392] /Library/MobileSubstrate/MobileSubstrate.dylib
白名單檢測
那麽上面的檢測只可以檢測越獄環境中的代碼註入,在非越獄環境中,逆向工程師可以利用yololib工具註入動態庫.所以我們可以檢索一下自己的應用程序所加載的動態庫是否是我們源程序所有
bool HKCheckWhitelist(){
int count = _dyld_image_count();
for (int i = 0; i < count; i++) {
//遍歷拿到庫名稱!
const char * imageName = _dyld_get_image_name(i);
//判斷是否在白名單內,應用本身的路徑是不確定的,所以要除外.
if (!strstr(libraries, imageName)&&!strstr(imageName, "/var/mobile/Containers/Bundle/Application")) {
printf("該庫非白名單之內!!\n%s",imageName);
return NO;
}
}
return YES;
}
其中libraries變量是<q style="box-sizing: border-box;">白名單</q>.
iOS應用代碼註入防護