JNI proguard混淆

Question

我对混淆有问题。为了获得更好的想象力：

JAVA代码

class JniTest...

public void test()
{
    //some code
}

public void runJniCode()
{
    //here I call native code
}

本机代码

JNIEXPORT void JNICALL
Java_path_to_class_test(JNIEnv* env, jobject  obj)
{
    //here I call test method from Java

}

在我想发布一个混淆版本之前，一切都很好。这个类中的Java类（JniTest例如）和方法test的名称被proGuard重命名为“a”和“a（）”（这可能并不总是相同的），但在本机代码中，方法和类的原始名称保持不变，因为它被硬编码为字符串，如下所示：

jmethodID mid = env->GetMethodID(cls, "test", "someSignature");

...有没有办法动态设置方法名？

Answer 1

JNI支持两种绑定本机方法的方法。简单的一种是按名称完成的，不能用于混淆的类和方法名称。

另一种方法是从库中的JNI\u OnLoad（）调用RegisterNatives。必须为此技术的每个类准备一个本机方法表：

Java：

package a.b;

public class C {
    public native int nativeMethod();
}

C：

static jint cnm(JavaEnv*, jobject) {
    return 42;
}

JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) {
    JNIEnv *env; 
    if (vm->GetEnv(reinterpret_cast<void **>(&env), JNI_VERSION_1_6) != JNI_OK) {
        return JNI_FALSE;
    }

    std::string className = "a/b/C"; // may be changed by ProGuard
    std::string methodName = "nativeMethod"; // may be changed by ProGuard

    jclass cls = env->FindClass(className.c_str());

    if (env->ExceptionCheck()) {
        env->ExceptionDescribe();
        return JNI_ERR;
    }
    assert(cls);

    JNINativeMethod C_methods[] = {
      { methodName.c_str(), "()I", reinterpret_cast<void*>(&cnm) }
    };

    env->RegisterNatives(cls, C_methods, sizeof(C_methods)/sizeof(C_methods[0]);
    return JNI_VERSION_1_6;
}

这个小片段表明，您实际上可以用ProGuard生成的实际模糊名称替换这些名称。简单的方法是相信ProGuard混淆是确定性的，并在发布Java构建完成后手动从映射文件中复制名称。自动化可能需要调整gradle构建，因为通常C是在Java之前编译的，但这是可能的。

如果经过模糊处理的方法也引用了一些经过模糊处理的类，那么任务将变得更具挑战性。

用于混淆的RealsterNative（）的最大优势在于，它不仅允许您更改类和方法名称，而且本机方法实现在本机库之外也不可见。例如，在上面的示例中，cnm是静态并且不容易被发现。

Answer 2

基于AndrewJC的回答，如果您的应用程序是静态编程语言，您还可以使用@JvmName注释而不是使用包装器方法，例如：

object Native {
    @JvmName("a")
    private external fun rotateRGBA(rgb: Int, w: Int, h: Int): Int
}

// rotateRGBA
extern "C" int Java_mypackage_Native_a(JNIEnv *env, jclass, int rgb, int w, int h);

现在，您可以使用本机调用Kotlin中的JNI方法。rotateRGBA（0，200，400）但在编译时，Kotlin会自动将方法调用重命名为：本机。a 。

Answer 3

在研究这个完全相同的问题时，我遇到了一个我认为合理的解决方案。不幸的是，该解决方案不会按照要求自动混淆本机Java代码和JNI方法，但我仍然认为它值得分享。

引用来源：

我在这里介绍了一个简单的技巧，它允许混淆JNI层，在Java和本机端将方法名称重命名为无意义的名称，同时保持源代码相对可读和可维护，并且不影响性能。

让我们考虑一个示例，初始情况：

class Native {
    native static int rotateRGBA(int rgb, int w, int h);
}

extern "C" int Java_pakage_Native_rotateRGBA(JNIEnv *env, jclass, int rgb, int w, int h);

在上面的示例中，Proguard无法混淆方法名rotateRGBA，它在Java端和本机端仍然可见。

解决方案是在源代码中直接使用一个无意义的方法名称，同时注意尽量减少对代码可读性和可维护性的破坏。

class Native {
    private native static int a(int rgb, int w, int h); //rotateRGBA

    static int rotateRGBA(int rgb, int w, int h) {
        return a(rgb, w, h);
    }
}

// rotateRGBA
extern "C" int Java_pakage_Native_a(JNIEnv *env, jclass, int rgb, int w, int h);

JNI方法被重命名为无意义的a。但是Java端的调用被有意义的命名方法rotateRGBA包装。Java客户端继续调用本机。rotateRGBA（）与以前一样，完全不受重命名的影响。

有趣的是，新的Native.rotateRGBA方法不再是本机的，因此可以由ProGuard随意重命名。结果是，无论是在Dalvik还是本机方面，RotateRGBA这个名称都从混淆的代码中完全消失了。更重要的是，ProGuard优化了包装器方法，从而消除了包装本机调用对性能的（可以忽略不计的）影响。

结论：从混淆代码（Dalvik字节码和本机库）中消除了JNI方法名称，对易读性的影响最小，对性能没有影响。

来源：模糊JNI表层

我仍在寻找一种能够自动混淆本机Java代码和相关JNI的工具。