在應(yīng)用開發(fā)過程中，我們不僅僅需要完成正常的業(yè)務(wù)邏輯，考慮應(yīng)用性能、代碼健壯相關(guān)的問題，我們有時(shí)還需要考慮到應(yīng)用安全的問題。
那么應(yīng)用安全的問題涉及到很多方面。比如防止靜態(tài)分析的，代碼混淆、邏輯混淆；防止重簽名的，應(yīng)用ID檢測、甚至是代碼的HASH檢測等等。那么這篇文章我想聊聊關(guān)于代碼的注入檢測，因?yàn)榘l(fā)現(xiàn)隨著iOS系統(tǒng)的更新,我們防護(hù)的手段發(fā)生了一些變化。

代碼注入的方式

代碼注入的方式大致分為兩種

• 越獄注入：通過修改DYLD_INSERT_LIBRARIES 環(huán)境變量的值,來插入動(dòng)態(tài)庫并執(zhí)行
• 非越獄注入：
  • 直接將自定義的Framwork或者dylib庫打包進(jìn)入APP并重簽名。
  • 利用yololib修改MachO文件,添加庫路徑.在應(yīng)用啟動(dòng)時(shí),dyld會(huì)加載并執(zhí)行.

早期防護(hù)方式

在工程的Build Settings中找到Other Linker Flages 并添加字段
-Wl,-sectcreate,__RESTRICT,__raestrict,/dev/null
此操作的作用是在可執(zhí)行文件中添加一個(gè)Section.我們使用MachOView分析如下:

當(dāng)MachO文件中擁有這個(gè)字段,那么我們通過越獄環(huán)境插入動(dòng)態(tài)庫的方式就會(huì)失效.起到防護(hù)的作用.其原理在DYLD源碼中可以分析到.

dyld源碼分析

首先這里分析的DYLD源碼版本是519.2.2版本.
我們可以通過檢索DYLD_INSERT_LIBRARIES定位到_main函數(shù)加載插入動(dòng)態(tài)庫的代碼如下.

// load any inserted librariesif ( sEnv.DYLD_INSERT_LIBRARIES != NULL ) {for (const char* const* lib = sEnv.DYLD_INSERT_LIBRARIES; *lib != NULL; ++lib) loadInsertedDylib(*lib);}

但是早在這個(gè)環(huán)境變量判斷之前,dyld已經(jīng)做了一個(gè)判斷

if ( gLinkContext.processIsRestricted ) {pruneEnvironmentVariables(envp, &apple);// set again because envp and apple may have changed or movedsetContext(mainExecutableMH, argc, argv, envp, apple);}

如果判斷出進(jìn)程是restricted!也就是當(dāng)前進(jìn)程是限制插入動(dòng)態(tài)庫的!就會(huì)調(diào)用pruneEnvironmentVariables函數(shù)移除相關(guān)的環(huán)境變量.
那么我們的processIsRestricted值什么時(shí)候?yàn)閠rue呢?
繼續(xù)分析源碼可以發(fā)現(xiàn)兩個(gè)關(guān)鍵函數(shù)影響其值.其中 hasRestrictedSegment 函數(shù)專門檢測RESTRICT段

// any processes with setuid or setgid bit set or with __RESTRICT segment is restrictedif ( issetugid() || hasRestrictedSegment(mainExecutableMH) ) {gLinkContext.processIsRestricted = true;}

通過注釋也能發(fā)現(xiàn).任意進(jìn)程的__RESTRICT段設(shè)置為restricted動(dòng)態(tài)庫插入將被限制.
我們進(jìn)入到processIsRestricted函數(shù)內(nèi),實(shí)現(xiàn)如下.

#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 = &sectionsStart[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中設(shè)置RESTRICT段賦值為restricted可以用來防護(hù)越獄的代碼注入.
但是新版的dyld源碼中去掉了__RESTRICT檢測.從iOS10開始,這種防護(hù)手段已失效

DYLD_INSERT_LIBRARIES 檢測

那么既然dyld加載過程不再檢測__RESTRICT段了我們就手動(dòng)的檢測DYLD_INSERT_LIBRARIES環(huán)境變量.通過函數(shù)可查看當(dāng)前進(jìn)程環(huán)境變量的值.

char *env = getenv("DYLD_INSERT_LIBRARIES");NSLog(@"%s",env);

在沒有插入動(dòng)態(tài)庫時(shí),env為null.
那么一旦為自己的應(yīng)用寫入插件時(shí),我們就可以看到控制臺的輸出

2019-01-03 19:20:37.285 antiInject[7482:630392] /Library/MobileSubstrate/MobileSubstrate.dylib

白名單檢測

那么上面的檢測只可以檢測越獄環(huán)境中的代碼注入,在非越獄環(huán)境中,逆向工程師可以利用yololib工具注入動(dòng)態(tài)庫.所以我們可以檢索一下自己的應(yīng)用程序所加載的動(dòng)態(tài)庫是否是我們源程序所有

bool HKCheckWhitelist(){int count = _dyld_image_count();for (int i = 0; i < count; i++) {//遍歷拿到庫名稱！const char * imageName = _dyld_get_image_name(i);//判斷是否在白名單內(nèi),應(yīng)用本身的路徑是不確定的,所以要除外.if (!strstr(libraries, imageName)&&!strstr(imageName, "/var/mobile/Containers/Bundle/Application")) {printf("該庫非白名單之內(nèi)！！\n%s",imageName);return NO;}}return YES; }

其中l(wèi)ibraries變量是<q style="box-sizing: border-box;">白名單</q>.

轉(zhuǎn)載于:https://blog.51cto.com/14039500/2343380

總結(jié)

以上是生活随笔為你收集整理的iOS应用代码注入防护的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。