Android 安全系列之如何在 native 層保存關鍵信息

CarSharman 7年前發布 | 11K 次閱讀 JNI 安卓開發 Android開發 移動開發

相信大家在日常開發中都有安全層面的需求,最典型的莫過于加密。而apk是脆弱的,反編譯拿到你的源碼輕而易舉,這時候我們就需要更保險的手段來保存密鑰之類的關鍵信息。本文就細致地講解簡單卻實用的native手段,文中涉及部分jni的知識,但都有注釋,淺顯易懂,歡迎留言溝通。文末有示例代碼地址。

目前ndk開發有三種編譯手段:

  1. ndk-build。這是從eclipse時代就存在的一種編譯方式,ndk-build是ndk開發包中的一個可執行文件,在這里不贅述,因為目前Android Studio已經普及,新帶來的編譯方式十分便捷。
  2. gradle-experimental 。這是一款Android Gradle插件,跟我們常用的 classpath 'com.android.tools.build:gradle:2.3.0' 是同一個概念的東西,截至寫作時,已經發展到了 0.10.0 版本,以后可能取代現有的gradle插件。
  3. CMake。CMake是個開源的跨平臺的自動化構建系統,也是目前Studio默認集成的構建系統。 CMakeLists.txt 的配置這里不詳細講解了,在創建include c++的新項目時,Studio會幫你做好默認配置。

簡單的使用jni

首先我們要聲明一個本地方法,比如是一個獲取密鑰串的方法,如下:

package com.chenenyu.security;

public class Security {
    static { // 加載libsecurity.so,只要在方法調用前加載,放哪都行。
        System.loadLibrary("security");
    }
    public static native String getSecret();
}

這時候編譯器可能會警告,因為找不到對應jni函數。我們按照Studio的提示創建一個function即可,或者自己手動創建源文件和頭文件,這里我們采用靜態注冊方式(關于靜態注冊和動態注冊的區別,可以google一下),對應的頭文件和源文件中的函數如下:

### .h
#ifdef __cplusplus
extern "C" {
#endif

JNIEXPORT jstring JNICALL
Java_com_chenenyu_security_Security_getSecret(JNIEnv *env, jclass type);

#ifdef __cplusplus
}
#endif
### .cpp
jstring Java_com_chenenyu_security_Security_getSecret(JNIEnv *env, jclass type) {
    return env->NewStringUTF("Security str from native.");
}

這時我們在項目中調用 Security.getSecret() 就會得到這個字符串,這樣看起來是不是比直接寫在Java代碼里安全多了?

然而......并沒有!!!

直接使用jni的不足

jni是通過反射的方式來相互調用,也就是說,我們的native方法是不能混淆的,那么就可以反編譯拿到.so庫和同名的native方法,然后通過二次打包debug出這個密鑰串。所以我們需要一種預防debug的手段,這里我們采取驗證apk簽名的方式來達到目的,當發現apk簽名和我們自己的簽名不一致的時候,調用so庫直接崩潰即可。

如何對so進行保護

Java代碼獲取簽名

首先我們來看看如何通過Java代碼獲取簽名信息,

PackageManager pm = context.getPackageManager();
PackageInfo pi = pm.getPackageInfo(context.getPackageName(), PackageManager.GET_SIGNATURES);
Signature[] signatures = pi.signatures;
Signature signature0 = signatures[0];
signature0.toCharsString();

這里可以發現獲取簽名需要一個 Context 對象。

獲取Context對象

這里我們仿照java代碼獲取簽名的方式,首先我們是否需要傳遞一個 Context 對象到native中呢?答案是否定的。因為"壞人"可以通過重寫Context和PackageManager的方式來偽造簽名。那么不傳 Context 怎么獲取簽名呢,這里我們可以通過反射獲取一個 Context :

// 下面幾行代碼展示如何任意獲取Context對象,在jni中也可以使用這種方式
Class<?> activityThreadClz = Class.forName("android.app.ActivityThread");
Method currentApplication =  activityThreadClz.getMethod("currentApplication");
Application application = (Application) currentApplication.invoke(null);

所以在native中我們也可以通過這種方式來獲取 Context對象 ,相關代碼如下:

static jobject getApplication(JNIEnv *env) {
    jobject application = NULL;
    jclass activity_thread_clz = env->FindClass("android/app/ActivityThread");
    if (activity_thread_clz != NULL) {
        jmethodID currentApplication = env->GetStaticMethodID(
                activity_thread_clz, "currentApplication", "()Landroid/app/Application;");
        if (currentApplication != NULL) {
            application = env->CallStaticObjectMethod(activity_thread_clz, currentApplication);
        } else {
            LOGE("Cannot find method: currentApplication() in ActivityThread.");
        }
        env->DeleteLocalRef(activity_thread_clz);
    } else {
        LOGE("Cannot find class: android.app.ActivityThread");
    }

    return application;
}

Native代碼獲取簽名

有了 Context 對象,我們就可以通過native調用java的方式來獲取簽名了:

// Application object
jobject application = getApplication(env);
if (application == NULL) {
    return JNI_ERR;
}
// Context(ContextWrapper) class
jclass context_clz = env->GetObjectClass(application);
// getPackageManager()方法
jmethodID getPackageManager = env->GetMethodID(context_clz, "getPackageManager", "()Landroid/content/pm/PackageManager;");
// 獲取PackageManager實例
jobject package_manager = env->CallObjectMethod(application, getPackageManager);
// PackageManager class
jclass package_manager_clz = env->GetObjectClass(package_manager);
// getPackageInfo()方法
jmethodID getPackageInfo = env->GetMethodID(package_manager_clz, "getPackageInfo", "(Ljava/lang/String;I)Landroid/content/pm/PackageInfo;");
// getPackageName()方法
jmethodID getPackageName = env->GetMethodID(context_clz, "getPackageName", "()Ljava/lang/String;");
// 調用getPackageName()
jstring package_name = (jstring) (env->CallObjectMethod(application, getPackageName));
// PackageInfo實例
jobject package_info = env->CallObjectMethod(package_manager, getPackageInfo, package_name, 64);
// PackageInfo class
jclass package_info_clz = env->GetObjectClass(package_info);
// signatures字段
jfieldID signatures_field = env->GetFieldID(package_info_clz, "signatures", "[Landroid/content/pm/Signature;");
jobject signatures = env->GetObjectField(package_info, signatures_field);
jobjectArray signatures_array = (jobjectArray) signatures;
jobject signature0 = env->GetObjectArrayElement(signatures_array, 0);
// Signature class
jclass signature_clz = env->GetObjectClass(signature0);
// toCharsString()方法
jmethodID toCharsString = env->GetMethodID(signature_clz, "toCharsString", "()Ljava/lang/String;");
// 調用toCharsString()
jstring signature_str = (jstring) (env->CallObjectMethod(signature0, toCharsString));
// 最終的簽名串
const char *sign = env->GetStringUTFChars(signature_str, NULL);

可以看到這個過程是很繁瑣的,但是都是class、object、method、field等的來回調用,沒什么難點。

使用完之后記得要釋放內存哦

// release memory
env->DeleteLocalRef(application);
env->DeleteLocalRef(context_clz);
env->DeleteLocalRef(package_manager);
env->DeleteLocalRef(package_manager_clz);
env->DeleteLocalRef(package_name);
env->DeleteLocalRef(package_info);
env->DeleteLocalRef(package_info_clz);
env->DeleteLocalRef(signatures);
env->DeleteLocalRef(signature0);
env->DeleteLocalRef(signature_clz);
...

獲取到簽名之后,要和我們內置的簽名串進行對比:

int result = strcmp(sign, "內置的簽名串,可以通過上文的Java代碼提前獲取");
env->ReleaseStringUTFChars(signature_str, sign);
env->DeleteLocalRef(signature_str);
if (result == 0) { // 簽名一致
    return JNI_OK;
}
return JNI_ERR;

何時校驗so庫

前面我們講了怎樣通過簽名校驗so調用的合法性,但是應該在何時校驗呢?每次調用共享庫中的方法都校驗嗎?這顯然是不合理的,對性能也是一種無端消耗。這里我們要用到 JNI_OnLoad() 函數,該函數會在so庫加載的時候自動調用,在加載時我們先驗證一下apk的簽名,不一致就直接崩潰,讓“壞人”無可奈何~

jint JNI_OnLoad(JavaVM *vm, void *reserved) {
    JNIEnv *env = NULL;
    if (vm->GetEnv((void **) &env, JNI_VERSION_1_4) != JNI_OK) {
        return JNI_ERR;
    }
    if (verifySign(env) == JNI_OK) {
        return JNI_VERSION_1_4;
    }
    LOGE("簽名不一致!");
    return JNI_ERR;
}

結語

至此,一個簡單而有效地native安全庫就完成了。請注意,沒有絕對的安全,我們能做的,就是盡量提高破解難度。光保證客戶端的安全是沒有用的,我們還要保證傳輸過程的安全,比如杜絕明文傳輸, 對關鍵信息進行(非)對稱加密 ,不要用Base64或者MD5這種自欺欺人的方式!還有 使用https代替http ,這才是保險的安全手段。

 

 

來自:http://www.jianshu.com/p/2576d064baf1

 

 本文由用戶 CarSharman 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!