本文博客地址：http://blog.csdn.net/qq1084283172/article/details/78212010
Android逆向分析的過程中免不了碰到Android so被加固的情況，要對被加固的Android so進行脫殼處理，就需要先了解Android so的加載流程，進而瞭解Android so的加固原理。學習Android so加固的思路和學習Android dex文件加固的思路是類似的，下面就以Android so加固的源頭System.loadLibrary函數爲入口點進行學習，這裏的源碼分析以Android 4.4.4 r1版本的源碼爲基礎。
1.System.loadLibrary函數和System.load函數的調用區別。
關於Android系統中System.loadLibrary函數和System.load函數的調用區別，可以參考System.loadLibrary函數和System.load函數的註釋說明。System.loadLibrary函數調用傳入的參數爲Android so庫文件的文件名稱的約定簡寫，而System.load函數調用傳入的參數爲Android so庫文件的文件全路徑，這就是調用的區別。
System.load函數的調用參數的說明：
System.loadLibrary函數的調用參數的說明：
2.System.loadLibrary函數和System.load函數僅僅在調用參數上有一些區別（java層的代碼實現上有一些差別），具體的底層函數實現是一樣的，System.loadLibrary函數和System.load函數最終底層都是調用的Native函數Runtime.nativeLoad來實現。
3.System.loadLibrary函數的java層代碼實現的調用流程圖，如下：
4.System.load函數的java層代碼實現的調用流程圖，如下：
5.System.loadLibrary函數是在Android 4.4.4 r1源碼的文件路徑 /libcore/luni/src/main/java/java/lang/System.java 中實現的，在System.loadLibrary函數實現中調用Runtime類的函數getRuntime獲取Runtime類的實例對象，調用類VMStack的Native函數getCallingClassLoader獲取當前進程調用者的class loader（類加載器），然後調用Runtime類的函數loadLibrary對so庫文件進行查找和加載。
http://androidxref.com/4.4.4_r1/xref/libcore/luni/src/main/java/java/lang/System.java
6.Runtime類的函數loadLibrary，在Android 4.4.4 r1源碼的文件路徑 /libcore/luni/src/main/java/java/lang/Runtime.java 中實現，比較深層的代碼原理分析可以參考老羅的博客《Dalvik虛擬機JNI方法的註冊過程分析》。Runtime類的函數loadLibrary實現中對於類加載器ClassLoader實例對象loader不爲null的情況，調用loader的成員函數findLibrary獲取需要加載so庫文件的絕對路徑，調用Runtime類的函數doLoad進行so庫文件的加載；當類加載器ClassLoader實例對象loader爲null的情況時，在Android系統預定義範圍lib文件目錄下進行so庫文件的查找，查找需要加載的so庫文件的名稱如：lib<name>.so，則調用Runtime類的函數doLoad進行so庫文件的加載；如果找不到該so庫文件所在的文件路徑再會拋出異常。
http://androidxref.com/4.4.4_r1/xref/libcore/luni/src/main/java/java/lang/Runtime.java
/*
* Searches for a library, then loads and links it without security checks.
*/
void loadLibrary(String libraryName, ClassLoader loader) {
if (loader != null) {
// 1. 類加載器ClassLoader不爲null的情況
// 調用類ClassLoader的類成員函數findLibraryg獲取so庫文件的全路徑
String filename = loader.findLibrary(libraryName);
// 檢查是否獲取so庫文件的絕對全路徑成功
if (filename == null) {
throw new UnsatisfiedLinkError("Couldn't load " + libraryName +
" from loader " + loader +
": findLibrary returned null");
}
// 調用Runtime類的成員函數doLoad進行so庫文件的加載
String error = doLoad(filename, loader);
if (error != null) {
throw new UnsatisfiedLinkError(error);
}
return;
}
// 2. 類加載器ClassLoader爲null的情況
// 在Android系統預定義的系統範圍lib目錄下查找so庫文件得到so庫文件的名稱
// 例如：lib<name>.so
String filename = System.mapLibraryName(libraryName);
// 保存so庫文件的絕對全路徑，供加載so庫文件
List<String> candidates = new ArrayList<String>();
String lastError = null;
for (String directory : mLibPaths) {
// 拼接字符串得到so庫文件的絕對全路徑
String candidate = directory + filename;
candidates.add(candidate);
// 判斷so庫文件的路徑是否可讀有效
if (IoUtils.canOpenReadOnly(candidate)) {
// 調用Runtime類的成員函數doLoad進行so庫文件的加載
String error = doLoad(candidate, loader);
if (error == null) {
return; // We successfully loaded the library. Job done.
}
lastError = error;
}
}
// so庫文件的文件路徑查找或者so庫文件加載出現錯誤的情況
if (lastError != null) {
throw new UnsatisfiedLinkError(lastError);
}
throw new UnsatisfiedLinkError("Library " + libraryName + " not found; tried " + candidates);
}7.Runtime類的函數loadLibrary最終調用Runtime類的成員函數doLoad實現so庫文件的加載，doLoad函數先調用ClassLoader的實例成員方法getLdLibraryPath獲取當前Android進程運行所需要加載的so庫文件的所有文件目錄路徑的環境變量列表（：隔開類似linux環境變量的字符串），並以此爲傳入參數之一調用Native函數nativeLoad對目標so庫文件進行加載。
private String doLoad(String name, ClassLoader loader) {
// Android apps are forked from the zygote, so they can't have a custom LD_LIBRARY_PATH,
// which means that by default an app's shared library directory isn't on LD_LIBRARY_PATH.
// The PathClassLoader set up by frameworks/base knows the appropriate path, so we can load
// libraries with no dependencies just fine, but an app that has multiple libraries that
// depend on each other needed to load them in most-dependent-first order.
// We added API to Android's dynamic linker so we can update the library path used for
// the currently-running process. We pull the desired path out of the ClassLoader here
// and pass it to nativeLoad so that it can call the private dynamic linker API.
// We didn't just change frameworks/base to update the LD_LIBRARY_PATH once at the
// beginning because multiple apks can run in the same process and third party code can
// use its own BaseDexClassLoader.
// We didn't just add a dlopen_with_custom_LD_LIBRARY_PATH call because we wanted any
// dlopen(3) calls made from a .so's JNI_OnLoad to work too.
// So, find out what the native library search path is for the ClassLoader in question...
String ldLibraryPath = null;
if (loader != null && loader instanceof BaseDexClassLoader) {
// 獲取當前Android進程運行dex文件需要加載的so庫文件所在文件目錄路徑的環境變量（: 隔開）
ldLibraryPath = ((BaseDexClassLoader) loader).getLdLibraryPath();
}
// nativeLoad should be synchronized so there's only one LD_LIBRARY_PATH in use regardless
// of how many ClassLoaders are in the system, but dalvik doesn't support synchronized
// internal natives.
synchronized (this) {
// 同步處理，調用native方法nativeLoad加載so庫文件name
return nativeLoad(name, loader, ldLibraryPath);
}
}8.類Runtime的成員方法nativeLoad是Native函數，最終調用NDK編寫的底層jni方法，並且當前Android進程所運行的虛擬機模式不同，Runtime.nativeLoad函數的實現也會有所差別。在Dalvik虛擬機模式下，Runtime.nativeLoad函數最終調用Android
4.4.4 r1 源碼文件 /dalvik/vm/native/java_lang_Runtime.cpp 中的函數Dalvik_java_lang_Runtime_nativeLoad；Art虛擬機模式下，Runtime.nativeLoad函數最終調用的是Android
4.4.4 r1 源碼文件 /art/runtime/native/java_lang_Runtime.cc 中的函數Runtime_nativeLoad。
http://androidxref.com/4.4.4_r1/xref/art/runtime/native/java_lang_Runtime.cc#95
Dalvik虛擬機模式下，Runtime.nativeLoad函數的Native層實現。
/*
* static String nativeLoad(String filename, ClassLoader loader, String ldLibraryPath)
*
* Load the specified full path as a dynamic library filled with
* JNI-compatible methods. Returns null on success, or a failure
* message on failure.
*/
static void Dalvik_java_lang_Runtime_nativeLoad(const u4* args,
JValue* pResult)
{
// 獲取需要加載的so庫文件的絕對路徑（Java層的String對象）
StringObject* fileNameObj = (StringObject*) args[0];
// 獲取當前Android進程的類加載器ClassLoader實例對象
Object* classLoader = (Object*) args[1];
// 獲取當前Android進程運行所依賴的so庫文件所在的so文件目錄路徑的環境變量字符串（: 隔開的）
StringObject* ldLibraryPathObj = (StringObject*) args[2];
assert(fileNameObj != NULL);
// 將java層的字符串轉換C語言類型的字符串
char* fileName = dvmCreateCstrFromString(fileNameObj);
// 判斷需要加載的依賴so庫文件的文件目錄路徑(lib庫文件夾的環境變量)是否爲空
if (ldLibraryPathObj != NULL) {
// 將java層的字符串轉換成爲c語言類型的字符串
char* ldLibraryPath = dvmCreateCstrFromString(ldLibraryPathObj);
// 獲取當前libdvm.so模塊的導出函數android_update_LD_LIBRARY_PATH的調用地址
void* sym = dlsym(RTLD_DEFAULT, "android_update_LD_LIBRARY_PATH");
if (sym != NULL) {
// 定義函數指針
typedef void (*Fn)(const char*);
// 進行函數指針類型的轉換
Fn android_update_LD_LIBRARY_PATH = reinterpret_cast<Fn>(sym);
// 調用導出函數android_update_LD_LIBRARY_PATH更新系統lib庫文件的文件目錄
(*android_update_LD_LIBRARY_PATH)(ldLibraryPath);
} else {
ALOGE("android_update_LD_LIBRARY_PATH not found; .so dependencies will not work!");
}
free(ldLibraryPath);
}
StringObject* result = NULL;
// 保存函數返回值
char* reason = NULL;
// 調用dvmLoadNativeCode函數加載目標so庫文件fileName
bool success = dvmLoadNativeCode(fileName, classLoader, &reason);
// 檢查目標so庫文件是否加載成功
if (!success) {
const char* msg = (reason != NULL) ? reason : "unknown failure";
result = dvmCreateStringFromCstr(msg);
dvmReleaseTrackedAlloc((Object*) result, NULL);
}
free(reason);
free(fileName);
// 設置函數返回值
RETURN_PTR(result);
}9.Android 4.4.4 r1 源碼文件 /dalvik/vm/native/java_lang_Runtime.cpp 中的函數Dalvik_java_lang_Runtime_nativeLoad，最終調用源碼文件 /dalvik/vm/Native.cpp 中的dvmLoadNativeCode函數，並函數dvmLoadNativeCode是libdvm.so庫文件中的導出函數。dvmLoadNativeCode函數主要實現是先調用dlopen函數加載目標so庫文件，然後調用目標so庫文件中的導出函數JNI_OnLoad，實現jni函數的註冊以及其他的初始化操作等。
http://androidxref.com/4.4.4_r1/xref/dalvik/vm/Native.cpp#318
typedef int (*OnLoadFunc)(JavaVM*, void*);
/*
* Load native code from the specified absolute pathname. Per the spec,
* if we've already loaded a library with the specified pathname, we
* return without doing anything.
*
* TODO? for better results we should absolutify the pathname. For fully
* correct results we should stat to get the inode and compare that. The
* existing implementation is fine so long as everybody is using
* System.loadLibrary.
*
* The library will be associated with the specified class loader. The JNI
* spec says we can't load the same library into more than one class loader.
*
* Returns "true" on success. On failure, sets *detail to a
* human-readable description of the error or NULL if no detail is
* available; ownership of the string is transferred to the caller.
*/
bool dvmLoadNativeCode(const char* pathName, Object* classLoader,
char** detail)
{
SharedLib* pEntry;
void* handle;
bool verbose;
/* reduce noise by not chattering about system libraries */
verbose = !!strncmp(pathName, "/system", sizeof("/system")-1);
verbose = verbose && !!strncmp(pathName, "/vendor", sizeof("/vendor")-1);
// 如果不是Android系統庫，打印log
if (verbose)
ALOGD("Trying to load lib %s %p", pathName, classLoader);
*detail = NULL;
/*
* See if we've already loaded it. If we have, and the class loader
* matches, return successfully without doing anything.
*/
// 通過hash查找，判斷當前目標so庫文件是否已經被加載過
pEntry = findSharedLibEntry(pathName);
if (pEntry != NULL) {
// 如果上次用來加載它的類加載器不等於當前所使用的類加載器，返回失敗
if (pEntry->classLoader != classLoader) {
ALOGW("Shared lib '%s' already opened by CL %p; can't open in %p",
pathName, pEntry->classLoader, classLoader);
return false;
}
if (verbose) {
ALOGD("Shared lib '%s' already loaded in same CL %p",
pathName, classLoader);
}
// 上次沒有加載so成功,返回失敗
if (!checkOnLoadResult(pEntry))
return false;
return true;
}
/*
* Open the shared library. Because we're using a full path, the system
* doesn't have to search through LD_LIBRARY_PATH. (It may do so to
* resolve this library's dependencies though.)
*
* Failures here are expected when java.library.path has several entries
* and we have to hunt for the lib.
*
* The current version of the dynamic linker prints detailed information
* about dlopen() failures. Some things to check if the message is
* cryptic:
* - make sure the library exists on the device
* - verify that the right path is being opened (the debug log message
* above can help with that)
* - check to see if the library is valid (e.g. not zero bytes long)
* - check config/prelink-linux-arm.map to ensure that the library
* is listed and is not being overrun by the previous entry (if
* loading suddenly stops working on a prelinked library, this is
* a good one to check)
* - write a trivial app that calls sleep() then dlopen(), attach
* to it with "strace -p <pid>" while it sleeps, and watch for
* attempts to open nonexistent dependent shared libs
*
* This can execute slowly for a large library on a busy system, so we
* want to switch from RUNNING to VMWAIT while it executes. This allows
* the GC to ignore us.
*/
// 獲取當前dalvik虛擬機線程的描述結構體
Thread* self = dvmThreadSelf();
// 設置dalvik虛擬機的線程狀態爲等待
ThreadStatus oldStatus = dvmChangeStatus(self, THREAD_VMWAIT);
// 調用dlopen函數動態加載目標so庫文件（重點）
handle = dlopen(pathName, RTLD_LAZY);
// 恢復dalvik虛擬機的線程狀態
dvmChangeStatus(self, oldStatus);
// 判斷目標so庫文件是否動態加載成功
if (handle == NULL) {
*detail = strdup(dlerror());
ALOGE("dlopen(\"%s\") failed: %s", pathName, *detail);
return false;
}
/* create a new entry */
SharedLib* pNewEntry;
// 創建一個新的SharedLib結構體對象描述目標so庫文件被加載的信息
pNewEntry = (SharedLib*) calloc(1, sizeof(SharedLib));
// 被加載目標so庫文件的絕對路徑
pNewEntry->pathName = strdup(pathName);
// 目標so庫文件被加載之後的基地址句柄
pNewEntry->handle = handle;
// 被加載的目標so庫文件所屬的ClassLoader類加載器
pNewEntry->classLoader = classLoader;
dvmInitMutex(&pNewEntry->onLoadLock);
pthread_cond_init(&pNewEntry->onLoadCond, NULL);
// 加載目標so庫文件的dalvik虛擬機的線程tid
pNewEntry->onLoadThreadId = self->threadId;
/* try to add it to the list */
// 添加SharedLib對象pNewEntry到gDvm.nativeLibs中保存起來，添加時會先在gDvm.nativeLibs中查詢
// 如果當前目標so庫文件，沒有被其他線程所加載則進行add的添加並返回當前的pNewEntry;
// 如果當前目標so庫文件已經被其他線程所加載，則返回其他線程對應的pNewEntry。
SharedLib* pActualEntry = addSharedLibEntry(pNewEntry);
// 判斷其他線程是否已經加載過當前目標so庫文件
if (pNewEntry != pActualEntry) {
ALOGI("WOW: we lost a race to add a shared lib (%s CL=%p)",
pathName, classLoader);
freeSharedLibEntry(pNewEntry);
return checkOnLoadResult(pActualEntry);
} else {
// 當前目標so庫文件沒有被別的dalvik線程所加載的情況
if (verbose)
ALOGD("Added shared lib %s %p", pathName, classLoader);
bool result = false;
void* vonLoad;
int version;
// 獲取當前目標so庫文件中的導出函數JNI_OnLoad的調用地址（重點）
vonLoad = dlsym(handle, "JNI_OnLoad");
// 檢查是否獲取導出函數JNI_OnLoad的調用地址成功
if (vonLoad == NULL) {
// 當前目標so庫文件中沒有實現JNI_OnLoad函數
ALOGD("No JNI_OnLoad found in %s %p, skipping init", pathName, classLoader);
result = true;
} else {
/*
* Call JNI_OnLoad. We have to override the current class
* loader, which will always be "null" since the stuff at the
* top of the stack is around Runtime.loadLibrary(). (See
* the comments in the JNI FindClass function.)
*/
// 進行函數指針類型的轉換
OnLoadFunc func = (OnLoadFunc)vonLoad;
// 保存當前線程原來的classLoaderOverride
Object* prevOverride = self->classLoaderOverride;
// 暫時修改當前dalvik線程的classLoaderOverride
self->classLoaderOverride = classLoader;
// 修改當前dalvik虛擬機線程的狀態
oldStatus = dvmChangeStatus(self, THREAD_NATIVE);
if (gDvm.verboseJni) {
ALOGI("[Calling JNI_OnLoad for \"%s\"]", pathName);
}
// 調用JNI_OnLoad函數進行jni函數的註冊等操作
version = (*func)(gDvmJni.jniVm, NULL);
// 恢復dalvik虛擬機線程的狀態
dvmChangeStatus(self, oldStatus);
// 恢復dalvik虛擬機的classLoaderOverride
self->classLoaderOverride = prevOverride;
// 檢查是否調用JNI_OnLoad函數成功
if (version == JNI_ERR) {
*detail = strdup(StringPrintf("JNI_ERR returned from JNI_OnLoad in \"%s\"",
pathName).c_str());
} else if (dvmIsBadJniVersion(version)) {
*detail = strdup(StringPrintf("Bad JNI version returned from JNI_OnLoad in \"%s\": %d",
pathName, version).c_str());
/*
* It's unwise to call dlclose() here, but we can mark it
* as bad and ensure that future load attempts will fail.
*
* We don't know how far JNI_OnLoad got, so there could
* be some partially-initialized stuff accessible through
* newly-registered native method calls. We could try to
* unregister them, but that doesn't seem worthwhile.
*/
} else {
// 調用成功，設置標記
result = true;
}
if (gDvm.verboseJni) {
ALOGI("[Returned %s from JNI_OnLoad for \"%s\"]",
(result ? "successfully" : "failure"), pathName);
}
}
// 根據JNI_OnLoad函數調用成功的結果，設置目標so庫文件是否加載成功的標記
if (result)
// 目標so庫文件動態加載成功（jni函數註冊成功等）
pNewEntry->onLoadResult = kOnLoadOkay;
else
pNewEntry->onLoadResult = kOnLoadFailed;
pNewEntry->onLoadThreadId = 0;
/*
* Broadcast a wakeup to anybody sleeping on the condition variable.
*/
// 狀態的恢復
dvmLockMutex(&pNewEntry->onLoadLock);
pthread_cond_broadcast(&pNewEntry->onLoadCond);
dvmUnlockMutex(&pNewEntry->onLoadLock);
return result;
}
}10.Dalvik模式下System.loadLibrary函數的執行流程基本分析完了，理解的不是很透徹，可以結合老羅的博客《Dalvik虛擬機JNI方法的註冊過程分析》進行深入的學習。System.loadLibrary函數的執行流程中還有兩個重點函數需要深入分析：dlopen函數動態加載so庫文件，JNI_OnLoad函數調用，實現jni函數的註冊，後面我再深入學習。