RegisterNativeMethods | JNI_OnLoad method doesn't exist. It should be some tricks that obfuscate the symbol.

[behnamben]

Hi . i was trying to test the NativeFlowBenchmark with JN-SAF and all the results was as expected. but i saw this error in nativeDroid server and i wonder what caused this error? thanks

[xwlin-roy]

Hi,

What app did you use when it occurs this error?

This error means that there doesn't exist JNI_OnLoad symbol in your tested binary. Maybe you tested binary is obfuscated, which hides the JNI_OnLoad symbol.

[behnamben]

first, let me ask you what type of obfuscation could lead to false negatives in JN-SAF? i dont think the tested apk had any obfuscation. NativeFlowBenchmark/icc_javatonative and some other apks has the JNI_Onload error.

[xwlin-roy]

JNI generates native function names in two ways. One is the static way that flows the JNI specification, and the other way is dynamic that uses JNI_OnLoad and RegisterNatives to register native methods.

When Argus-SAF finds a JNI function in Java world, it first tries to generate the native method name by the JNI specification and looks up the corresponding symbol in the native world. If it can find the symbol, it'll begin analysis. Otherwise, it cannot find the symbol, it will change to the dynamic way to find the corresponding native symbol of the JNI method declared in Java world.

Finally, if both the static way and dynamic way can not resolve the JNI method. We can assume that the binary is obfuscated or some other tricks that hide the JNI_OnLoad symbol.

As for your issue, I'll take a look at the icc_javatonative test. And the other apks, can you reverse the apks that find the JNI methods declared in Java world, and generate the native method names with the JNI specification and see whether can you find the symbol in the binary. If you can find the symbol, but Argus-SAF reports the error, it'll be a bug of Argus-SAF. If not, and you cannot find the JNI_OnLoad symbol as well. I think the apks are obfuscated by some tricks.

[behnamben]

would this error rise, when we have a native activity in our App? i checked the icc_javatonative and realized that it leaks the data through a native activity. thank you for your responses. I am currently working to extend the JN-SAF and add some features to it. do you have any recommendation for me? what modules of JN-SAF you think can be extended?

[xwlin-roy]

Hi,

All tests in NativeFlowBench should be tested properly including the apps with the native activity. So it's not about the native activity issue, I'll take a look at it when I'm free.

Great to hear that you want to add features to JN-SAF. JN-SAF does have some limitations:

• Some of the JNI functions we haven't model them thoroughly and lack corresponding benchmarks, such as, the JNI functions operate the array(GetObjectArrayRegion). This limitation I think it's an engineering work.
• The data-flow engine of JN-SAF is based on the Annotation feature of angr. Here, we have a limitation that the granularity of our data-flow engine is too rough. JN-SAF only tracks the data flow in the JNI functions level(https://github.com/arguslab/Argus-SAF/blob/master/nativedroid/nativedroid/analyses/resolver/jni/jni_type/jni_native_interface.py). We haven't model the linux system/library call, such as memcpy that can effect the data flow. If you want, you can help to model these functions to make data-flow engine more thorough.
• Control/Data flow engine of JN-SAF is based on the symbolic execution, so JN-SAF will face the path/state exploration issue when it analyzes the big binaries. How to mitigate the state exploration issue is also a way that you can help.

[behnamben]

I am really enthusiastic to extend JN-SAF as my MS degree project . i will consider your mentioned limitations and try to fix them. thank you for your time .