逆向libbaiduprotect（三）- 移植python操作dalvik虚拟机c++函数，配合gdb控制程序运行流程

python编译移植到测试机，并且移植ctypes模块。利用ctypes代替c程序，利用dalvik内部c++函数，在运行过程中手动命令操控dalvik虚拟机，并结合gdb进行调试。绕过zygote和ASM去启动进程。

由于我使用手动创建虚拟机，而不是通过zygote去启动虚拟机，zygote会通过androidruntime::startVM去加载和初始化所有运行app的环境。所以我必须自行完成这些必要的工作。

不同于jvm，dalvik必须加载两种java运行时包，java runtime以及android runtime。并且不会自动加载native库去注册上面两个runtime的native实现方法。java.*和android.*都在sdk的platform/$(api-level)/android.jar，java.*被称为core library，我们必须编译这个core库成dex，在我们手动的创建的虚拟机中加载。

    system_load(jenv, "/system/lib/libjavacore.so")
    system_load(jenv, "/system/lib/libandroid.so")
    system_load(jenv, "/system/lib/libandroid_runtime.so")
    system_load(jenv, "/system/lib/libbinder.so")

    print "now start android runtime"
    ar = cdll.LoadLibrary("libandroid_runtime.so")
    callcxxF(ar, "android::AndroidRuntime::startReg", [jenv])

然后我们还要加载支持core库的native库。libjavacore.so这是对应java.*的native方法实现，libandroid_runtime.so这是对应android.*的native方法实现。我们手动创建的虚拟机必须手动去加载这两个库，libjavacore.so有JNI_OnLoad实现，会自动注册它的native方法。但是libandroid_runtime.so却没有JNI_OnLoad实现，我们必须使用objdump查看函数符号，找出它可能用于注册native方法的函数，并在加载它时调用这个函数去注册native方法。不然的话，你创建的虚拟机并不能使用android.*，尽管你已经加载了这些类，或者还加载了这个so，但是由于你没有注册android.*所依赖的native实现方法，所以不能使用。

之后就是去用jni初始化一些对象，这些对象都是你要调试的so库，它所依赖（或访问到）的java对象。另外就是你只想调试dex里面的某个类，而这个类所依赖（或访问到）的java对象。

通过dvm内部函数加载dex或odex，然后将类加载到虚拟机。

在运行调试过程中，可以使用python调用jni测试调试你想查询的信息，结合gdb可以操控所有线程的运行，并且利用gdb脚本，从虚拟机内部结构出发分析运行状态信息，使用断点（如 dvmCallMethodA）和断点命令日志，跟踪java层或jni调用的行为。gdb调试还可以手动构筑环境让程序在濒临信号崩溃之时得以继续运行下去。

在绕开了来自java层和c层的反调试监控后，让调试的程序运行下去，但是由于程序依赖ContextImpl，这个必须依赖于ASM去初始化的对象，因为脱离zygote和ASM，手动无法创建一个让程序满意的ContextImpl，这个对象关联了太多application运行依赖的服务和信息。

下面是实例，加载libbaiduprotect_x86.so后，libbaiduprotect_x86.so的行为被gdb跟踪监测：

由于程序不是由ASM启动的Application，所以ActivityThread.currentPackageName()返回空，在c层使用这个结果进行strlen时出错，这里还好，用gdb就可以填补过去。构建一个字符串就是了，让程序继续执行。

libbaiduprotect.so依赖了android/app/ContextImpl，抛出了异常，并且在下一次Jni调用时，dalvik主动检测pending异常，发现后对程序abort。

这里必须要注意，SIGSEGV不一定是内存访问出错，在上面的情况是abort发出的信号。