search

chame1eon / jnitrace

A Frida based tool that traces usage of the JNI API in Android apps.
MIT License
1.62k stars 259 forks source link

" -m attach" can't trace and " -m spawn" trace error #12

Closed vmtest888 closed 4 years ago

vmtest888 commented 4 years ago

apk download link: http://dl.pddpic.com/android_dev/2020-04-28/d6b12f09b516007981b0ae328f700747.apk

Test command line 1: jnitrace -l libPddSecure.so -i Call.* -m attach com.xunmeng.pinduoduo

There is no output Tracing. Press any key to quit...

Test command line 2: jnitrace -l libPddSecure.so -i Call.* com.xunmeng.pinduoduo Output error

` 39302 ms [+] JNIEnv->CallObjectMethod 39302 ms |- JNIEnv* : 0xd4ed33e0 39302 ms |- jobject : 0x79 { android/util/DisplayMetrics } 39302 ms |- jmethodID : 0x6f7bafc4 { getPublicKey()Ljava/security/PublicKey; } 39302 ms |= jobject : 0x91 { java/security/PublicKey }

` DisplayMetric has no method named getPublicKey

chame1eon commented 4 years ago

Hi,

Thanks very much for your bug notification!

I have had a look at both issues and think I understand why both were happening.

Issue 1, using attach rather than spawn will often lead to missing trace data. This is because jnitrace has to intercept all references to the JNIEnv to trace correctly. In many cases apps, like this one, will load method references during library load. When using attach jnitrace will not be able to intercept those initial load calls and so will miss all future JNI calls via those methods.

Issue 2, jnitrace was not tracking DeleteLocalRefs correctly, this led to it not deleting names of objects it keeps a mapping of. When jnitrace spotted future arguments or return values with the same reference ID, it was reusing the previous name for it rather than the latest.

I have pushed a fix for Issue 2 to GitHub and PyPi, version 3.0.7. Please can you test and let me know if that fixes the issue?

Thanks!

chame1eon commented 4 years ago

Closing this as no response in over a week.