iOS 安全探索：字符串加密

前言

一個項目中的明文字符串不可勝數，可是有一些是程序的敏感信息的話若是不進行加密和混淆處理，反編譯者就會很容易找到咱們的敏感信息。拿到這些敏感信息以後就很容易分析咱們的程序，業務邏輯進而作一些可能對咱們不是很友好的事情，因此一些敏感明文字符串仍是有必要作一下加密，讓敏感信息更加安全。特別是對於一些金融類的APP。

反編譯工具

這裏介紹幾個經常使用的：

1. class-dump

主要用來反編譯一個庫文件或者app的方法名、屬性等聲明（即.h文件，強大的是反編譯出來的.h不只僅包含頭文件中的聲明，.m中的function方法名稱也一樣可以反編譯出來）。

2. IDA

主要用來反編譯庫文件的實現（固然方法聲明一樣可以反編譯出來，用class-dump主要是更加形象，有針對性），這個反編譯工具很是強大可以將函數的實現及邏輯關係、流程通通顯示出來，弊端就是反編譯出來的內容爲彙編語言，須要必定彙編基礎的才能看懂。看起來比較頭疼。

3. Hopper Disassembler

與IDA功能類似，主要功能都是反編譯查看方法的實現，這個軟件的功能相對於IDA來講，可讀性要強不少，反編譯出來的內容相似於彙編與OC的運行時的結合體，相對比較容易看出方法的具體實現。本次也是採用此工具進行驗證。

代碼混淆

在探索明文字符串加密以前先來了解一下代碼混淆：

1. 方法名混淆（對關鍵的類、方法，命名成與真實意圖無關的名稱）

• 建立shell腳本
• 聲明要替換的方法名列表
• 生成對應的轉義以後的無序字符串

2. 邏輯混淆（添加無用又不影響邏輯的代碼片斷，迷糊逆向人員）
3. 類名方法名混淆（例如：ios-class-guard）

Warning!!! 前方高能

Guideline 2.3.1 - Performance We discovered that your app contains hidden features. Specifically, It would be appropriate to remove all code obfuscation and selector mangling or to explain in detail the purpose of its inclusion before resubmitting for review.

聽說從17年開始蘋果拒審代碼混淆的APP。因此項目總體代碼的混淆目前感受意義不大。

第三方加固

第三方的服務（例如：網易雲易盾）這類的加固成效如何不太清楚，這裏拿出來給個參考，畢竟沒用過，多是否選用要看公司的決策了。

第三方明確說明了加固中使用了代碼混淆，不知道是使用什麼黑科技混淆的，確定不是跑腳本的方式，好奇寶寶能夠研究一下～～

字符串加密調研和嘗試

對於被砸殼的二進制文件，逆向分析人員分析代碼有一條重要線索，也就是被硬編碼的明文字符串。好比說，你的app被人抓包了，某些數據請求接口也被人發現了，那麼很簡單，逆向人員能夠直接拷貝特徵比較明顯的字符串到hopper中搜索，經過查看該字符串被引用的地方，能夠很快的找到相應的邏輯代碼。對於這一步的防範，須要作的就是對硬編碼的明文進行加密。

使用靜態內連 C 函數

• inline函數避免了普通函數的,在彙編時必須調用call的缺點。
• 取消了函數的參數壓棧，減小了調用的開銷，提升效率。因此執行速度確比通常函數的執行速度要快。

定義：

UIKIT_STATIC_INLINE NSString *testScheme() {
    return @"testtesttesttest";
}

static inline NSString * testName() {
    return @"test";
}
複製代碼

使用：

@"appId": testRrd(),
@"scheme" : testScheme()
複製代碼

結果：

很明顯明文字符串仍是很容易暴露出來～～，方案被PASS！

Swift 安全性更高

• 越獄開源社區對反編譯Swift的支持也不是很即時。
• 一些反編譯工具並不支持反編譯含有Swift的二進制文件（例如:class-dump）。
• 可以反編譯Swift的工具也表現出Swift更安全的一面。

我對一樣邏輯的一樣代碼（只是語法不一樣）的OC和Swift 方法（方法中包含明文字符串）進行了測試：

上面對比明顯能夠看出OC通過反編譯以後暴露出來的信息更能多，而且明文字符串顯而易見。可是若是Swift方法添加了對OC的支持（@objc）也會使安全性下降。

目前來看純Swift代碼確實比純OC或者混編的代碼更安全一些。

UAObfuscatedString

有個開源代碼能夠用，UAObfuscatedString，這個開源混淆代碼寫出來的字符串是以點語法的方式鏈接起來。

語法：

@"url" : NSMutableString.string.w.w.w.dot.b.a.i.d.u.dot.c.o.m
複製代碼

測試混淆結果：

UAObfuscatedString 是經過Category和Extension來實現這種點語法拼接字符串，存在比較明顯的規律，外加它是開源的可能安全性不是很高，如單從加密的角度去使用這個開源庫感受意義不大。

使用異或加密

原理：經過位運算的^異或運算符把字符串與一個指定的值進行運算，從而改變字符串中每一個字符的值，這樣就能夠獲得一個加密後的字符串；當把加密後的字符串做爲程序輸入內容後，異或運算會把加密後的字符串還原爲原有字符串的值。

使用：

@"key" : testMethod()
複製代碼

// Key 能夠是0~255的Int
#define XORKEY 0xC9

static void XOREncrypt(unsigned char *str, unsigned char key) {
    unsigned char *p = str;
    while (((*p) ^= key) != '\0') {
        p++;
    }
}

static id testMethod(void) {
    unsigned char str[] = {(XORKEY ^ 'e'), (XORKEY ^ 'n'), (XORKEY ^ 'c'), (XORKEY ^ 'r'),
        (XORKEY ^ 'y'), (XORKEY ^ 'p'), (XORKEY ^ 't'), (XORKEY ^ '\0')};
    XOREncrypt(str, XORKEY);
    static unsigned char result[7];
    memcpy(result, str, 7);
    return [[NSString alloc] initWithFormat:@"%s", result];
}

複製代碼

這裏將字符用函數指針成員的形式存儲，反編譯後，只留下了地址，去掉了明文字符串直接暴露的風險。

參考連接

hopperapp

iOS安全攻防（二十三）：Objective-C代碼混淆

ios-class-guard

UAObfuscatedString

對 iOS app 進行安全加固