淺談IOS如何對(duì)app進(jìn)行安全加固
通常來(lái)說(shuō)，我們要分析一個(gè) app，最開始一般是砸殼，
$ DYLD_INSERT_LIBRARIES=dumpdecrypted.dylib /path/to/XXX.app/XXX
然后將解密之后的二進(jìn)制文件扔給類似 hopper 這樣的反編譯器處理。直接將沒(méi)有砸殼的二進(jìn)制文件扔個(gè) hopper 反編譯出來(lái)的內(nèi)容是無(wú)法閱讀的（被蘋果加密了）。所以說(shuō)砸殼是破解分析 app 的第一步。對(duì)于這一步的防范，有兩種方式。
1.限制二進(jìn)制文件頭內(nèi)的段通過(guò)在 Xcode 里面工程配置 build setting 選項(xiàng)中將
-Wl,-sectcreate,__RESTRICT,__restrict,/dev/null
添加到 'Other Linker Flags'（注意這里我在項(xiàng)目中碰到了一個(gè) 問(wèn)題，在 iPod touch iOS 9.3 的設(shè)備上，使用了 swift 的項(xiàng)目會(huì)導(dǎo)致莫名奇妙的 swift 標(biāo)準(zhǔn)庫(kù)無(wú)法找到，而在 iOS 10 的設(shè)備上沒(méi)有這個(gè)問(wèn)題。之前并沒(méi)有以為是因?yàn)樘砑恿诉@個(gè)的原因，直到網(wǎng)上搜了所有解決方案，比如這個(gè) SO Post 都沒(méi)有效果的時(shí)候，我才發(fā)現(xiàn)是這個(gè)設(shè)置的原因）
2.setuid 和 setgidApple 不接受調(diào)用這兩個(gè)函數(shù)的 app，因?yàn)樗梢酝ㄟ^(guò)查看符號(hào)表來(lái)判斷您的二進(jìn)制運(yùn)行文件是否包含這兩個(gè)函數(shù)
檢測(cè)越獄設(shè)備上是否有針對(duì)性 tweak一般來(lái)說(shuō)在越獄手機(jī)上，我們會(huì)使用 TheOS 創(chuàng)建 tweak 類型的工程。然后針對(duì)我們要分析的類，使用提供的 logify.pl 命令生成的 mk 文件來(lái)打印該類所有方法的入?yún)⒑统鰠ⅰ＿@對(duì)分析 app 的運(yùn)行方式有很大的幫助。當(dāng)然，我們也可以自己創(chuàng)建某個(gè)類的 mk，來(lái) hook 某個(gè)函數(shù)，讓它以我們想要的方式運(yùn)行，比如說(shuō)對(duì)于一些做了證書綁定的 app，如果它用的框架是 AFNetWorking 的話，那么我們可以創(chuàng)建一個(gè) mk 文件，hook AFSecurityPolicy 類的下列方法：
- (BOOL)evaluateServerTrust:(SecTrustRef)serverTrust forDomain:(NSString *)domain
讓這個(gè)方法永遠(yuǎn)返回 YES，那么大多數(shù)的應(yīng)用所做的證書綁定也就失效了。用過(guò) TheOS 的 tweak 模版的話，你會(huì)發(fā)現(xiàn)這種方式相當(dāng)簡(jiǎn)單快速。
對(duì)于這一步的防范，可以在工程的 main 函數(shù)里面加入一層判斷，首先讀取 /Library/MobileSubstrate/DynamicLibraries 下所有的 plist 文件的內(nèi)容，查看是否某個(gè) plist 含有你的 app 的 bundle id，是的話，可以判定有人想利用 tweak 攻擊你的 app，這時(shí)候你可以采取比如說(shuō)將 app 給 crash 掉，或者限制某些功能等方式來(lái)應(yīng)對(duì)。
具體原理可以查看參考資料4，簡(jiǎn)單來(lái)說(shuō)，就是 MobileSubstrate 在 app 加載到內(nèi)存的時(shí)候會(huì)先去檢查 /Library/MobileSubstrate/DynamicLibraries 下面是否有需要加載的 tweak，有的話就加載，怎么判斷有沒(méi)有？就是根據(jù) plist 里面的 bundle ID 判斷的。
代碼參考如下
static __inline__ __attribute__((always_inline)) int anti_tweak(){ uint8_t lmb[] = {’S’, ’u’, ’b’, ’s’, ’t’, ’r’, ’a’, ’t’, ’e’, ’/’, ’D’, ’y’, ’n’, ’a’, ’m’, ’i’, ’c’, 0, }; NSString *dir = [NSString stringWithFormat:@'/%@/%@%s%@', @'Library', @'Mobile', lmb, @'Libraries']; NSArray *dirFiles = [[NSFileManager defaultManager] contentsOfDirectoryAtPath:dir error:nil]; NSArray *plistFiles = [dirFiles filteredArrayUsingPredicate: [NSPredicate predicateWithFormat: [NSString stringWithFormat:@'%@ %@%@ ’.%@%@’',@'self', @'EN', @'DSWITH', @'pli', @'st']]]; int cnt = 0; for (NSString *file in plistFiles) {NSString *filePath = [dir stringByAppendingPathComponent:file];NSString *fileContent = [NSString stringWithContentsOfFile:filePath encoding:NSUTF8StringEncoding error:nil];if (fileContent && [fileContent rangeOfString:[[NSBundle mainBundle] bundleIdentifier]].location != NSNotFound) { cnt ++;} } // 返回有針對(duì)本 app 的 tweak 數(shù)量，為 0 說(shuō)明沒(méi)有 return cnt;}防 http 抓包
通常破解一個(gè) app，我們會(huì)抓包。這樣的話，我們的 app 所有接口，接口數(shù)據(jù)都會(huì)暴露在逆向人員的眼皮底下。這時(shí)候，我們可以限制 http 抓包。方式很簡(jiǎn)單，就是將 NSURLSessionConfiguration 的 connectionProxyDictionary 設(shè)置成空的字典，因?yàn)檫@個(gè)屬性就是用來(lái)控制會(huì)話的可用代理的。可用參見官方文檔，也就是參考資料5。下面是對(duì)于 AFNetWorking 的使用方法：
// 繼承 AFHTTPSessionManager，重寫下列方法- (instancetype)initWithServerHost:(PDLServerHost*)serverHost {#ifdef DEBUG // debug 版本的包仍然能夠正常抓包 self = [super initWithBaseURL:serverHost.baseURL];#else// 由于使用 ephemeralSessionConfiguration session 發(fā)起的請(qǐng)求不帶 cookie 和使用緩存等 NSURLSessionConfiguration *conf = [NSURLSessionConfiguration ephemeralSessionConfiguration]; conf.connectionProxyDictionary = @{}; self = [super initWithBaseURL:serverHost.baseURL sessionConfiguration:conf];#endif return self;}
但是由于 OC 方法很容易被 hook，避免抓包是不可能的，所以，個(gè)人認(rèn)為最好的方式是對(duì)請(qǐng)求參數(shù)進(jìn)行加密（最好是非對(duì)稱加密，比如 RSA）
混淆（或者加密）硬編碼的明文字符串對(duì)于被砸殼的二進(jìn)制文件，逆向分析人員分析代碼有一條重要線索，也就是被硬編碼的明文字符串。比如說(shuō)，你的 app 被人抓包了，某些數(shù)據(jù)請(qǐng)求接口也被人發(fā)現(xiàn)了，那么很簡(jiǎn)單，逆向人員可以直接拷貝特征比較明顯的字符串到 hopper 中搜索，通過(guò)查看該字符串被引用的地方，可以很快的找到相應(yīng)的邏輯代碼。
對(duì)于這一步的防范，需要做的就是對(duì)硬編碼的明文進(jìn)行加密或混淆。 有個(gè)開源代碼可以用，UAObfuscatedString，但是這個(gè)開源混淆代碼寫出來(lái)的字符串是相當(dāng)長(zhǎng)的（也就是麻煩），同時(shí)不支持加密。最近我寫了一個(gè)工具，可以在編譯期間加密所有代碼中的明文字符串，在 app 運(yùn)行的時(shí)候解密字符串。這個(gè)工具的特點(diǎn)如下：
1.簡(jiǎn)單，開發(fā)人員可以硬編碼明文字符串，所有的加密會(huì)在編譯開始時(shí)自動(dòng)處理
2.可以自定義加密或者混淆方式，（為了不影響 app 運(yùn)行效率，需要提供一個(gè)簡(jiǎn)單快速的加密或混淆方式）提高解密難度
使用 Swift 開發(fā)Swift 是目前比較新的開發(fā) iOS 語(yǔ)言，由于 Swift 目前還不是很穩(wěn)定，越獄開源社區(qū)對(duì)這個(gè)的支持也不是很即時(shí)，比如說(shuō) class-dump 工具目前就不支持含有 Swift 的二進(jìn)制文件。 TheOS 也是最近才開始支持 Swift，但是還沒(méi)有加到主分支上（可以參見Features）。所以目前來(lái)看，至少 Swift 可能比純 OC 的工程要安全一點(diǎn)點(diǎn)。當(dāng)然，等 Swift 日趨穩(wěn)定，以及越獄開源社區(qū)的逐漸支持，這一點(diǎn)優(yōu)勢(shì)可能就不明顯了。
使用靜態(tài)內(nèi)連 C 函數(shù)由于 OC 語(yǔ)言的動(dòng)態(tài)性，導(dǎo)致 OC 的代碼是最容易被破解分析的。在安全性上，更推薦使用 C 語(yǔ)言寫成的函數(shù)。但是 C 語(yǔ)言的函數(shù)也是可以被 hook 的，主要有3種方式：
1.使用 Facebook 開源的fishhook
2.使用 MobileSubstrate 提供的 hook C 語(yǔ)言函數(shù)的方法
void MSHookFunction(void* function, void* replacement, void** p_original);
3.使用 mach_override，關(guān)于mach_override 和 fishhook的區(qū)別請(qǐng)看 mach_override 和 fishhook 區(qū)別
由于上面這三種方式可以 hook C 函數(shù)。要想不被 hook 解決方法是使用靜態(tài)內(nèi)聯(lián)函數(shù)，這樣的話需要被 hook 的函數(shù)沒(méi)有統(tǒng)一的入口，逆向人員想要破解只能去理解該函數(shù)的邏輯。
使用 block嚴(yán)格來(lái)說(shuō)使用 block 并不能很大程度提高安全性，因?yàn)槟嫦蛉藛T只要找到使用該 block 的方法，一般來(lái)說(shuō)在其附近就會(huì)有 block 內(nèi)代碼的邏輯。
但是個(gè)人認(rèn)為使用 block 的安全性是比直接使用 oc 方法是要高的。在我的逆向分析 app 的經(jīng)驗(yàn)中，對(duì)于使用了 block 的方法，目前我還不知道到怎么 hook （有知道的話，可以在 blog 上提個(gè) issue 告訴我，先謝過(guò)）同時(shí)對(duì)于含有嵌套的 block 或者是作為參數(shù)傳遞的 block，處理起來(lái)就更加復(fù)雜了。所以，如果能將內(nèi)斂 C 函數(shù)，嵌套 block ， block 類型參數(shù)組合起來(lái)的話，安全性應(yīng)該是會(huì)有一定提升。
代碼混淆代碼混淆的方式有幾種：
添加無(wú)用又不影響邏輯的代碼片段，迷糊逆向人員
對(duì)關(guān)鍵的類、方法，命名成與真實(shí)意圖無(wú)關(guān)的名稱
個(gè)人認(rèn)為最好的一個(gè)加密混淆工具是ios-class-guard，不過(guò)目前這個(gè)項(xiàng)目已經(jīng)停止維護(hù)了。但是這種方式的混淆我覺(jué)得才是最終極的方案。
其他方法比如 ptrace 反調(diào)試等（不過(guò)據(jù)說(shuō)已經(jīng)可以很容易被繞過(guò)）
// see http://iphonedevwiki.net/index.php/Crack_prevention for detailstatic force_inline void disable_gdb() {#ifndef DEBUG typedef int (*ptrace_ptr_t)(int _request, pid_t _pid, caddr_t _addr, int _data);#ifndef PT_DENY_ATTACH#define PT_DENY_ATTACH 31#endif // this trick can be worked around, // see http://stackoverflow.com/questions/7034321/implementing-the-pt-deny-attach-anti-piracy-code void* handle = dlopen(0, RTLD_GLOBAL | RTLD_NOW); ptrace_ptr_t ptrace_ptr = dlsym(handle, [@''.p.t.r.a.c.e UTF8String]); ptrace_ptr(PT_DENY_ATTACH, 0, 0, 0); dlclose(handle);#endif}注意事項(xiàng)
通過(guò)了解 OC 的運(yùn)行時(shí)特性和 mach-o 二進(jìn)制文件的結(jié)構(gòu)，借助現(xiàn)有的工具，你會(huì)發(fā)現(xiàn) hook 方法 是很簡(jiǎn)單就能完成的。雖然上面我提到了一些提高安全性的幾個(gè)方案，但是，所有這些方式只是增加了逆向人員的逆向難度，并不能讓 app 變的堅(jiān)不可摧。不過(guò)采取一定的措施肯定比什么措施都不采取來(lái)的安全。
以上就是淺談IOS如何對(duì)app進(jìn)行安全加固的詳細(xì)內(nèi)容，更多關(guān)于IOS如何對(duì)app進(jìn)行安全加固的資料請(qǐng)關(guān)注好吧啦網(wǎng)其它相關(guān)文章！
相關(guān)文章：
網(wǎng)公網(wǎng)安備