Unsupported annotations by ART

[abdawoud]

First, thank you for all the great things you achieve here!

Starting from Android 8.1, new annotations have been introduced to speed up native JNI calls in Android middleware, one of these annotations is "CriticalNative" (e.g., see googlesource).

According to the documentation (documentation), "The @CriticalNative annotation provides {..} faster way to run native methods, with {..} restrictions."

Now, whenever I try to instrument a java native method that is annotated by @CriticalNative, ART crashes with the following error:

F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
F DEBUG : Build fingerprint: 'generic/aosp_cf_x86_phone/vsoc_x86:10/QQ1D.200205.002/eng.abdall.20200224.133142:userdebug/test-keys'
F DEBUG : Revision: '0'
F DEBUG : ABI: 'x86'
F DEBUG : Timestamp: 2020-03-05 12:21:23-0330
F DEBUG : pid: 13035, tid: 13051, name: Binder:13035_2 >>> system_server <<<
F DEBUG : uid: 1000
F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x88b1474
F DEBUG : eax 088b1474 ebx e97b9a74 ecx 8bd589cb edx da618684
F DEBUG : edi 00000004 esi 00000000
F DEBUG : ebp be3fae88 esp be3fae40 eip e93f7a36
F DEBUG :
F DEBUG : backtrace:
F DEBUG : #00 pc 002e3a36 /apex/com.android.runtime/lib/libart.so!libart.so (offset 0x1c3000) (art::IndirectReferenceTable::Dump(std::__1::basic_ostream<char, std::__1::char_traits>&) const+134) (BuildId: 354ca8e1c28a50e77c63f80311270dba)
F DEBUG : frida/frida#1 pc 002e3ca4 /apex/com.android.runtime/lib/libart.so!libart.so (offset 0x1c3000) (art::IndirectReferenceTable::EnsureFreeCapacity(unsigned int, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>)+404) (BuildId: 354ca8e1c28a50e77c63f80311270dba)
F DEBUG : frida/frida#2 pc 004573cc /apex/com.android.runtime/lib/libart.so!libart.so (offset 0x3f6000) (art::JNI::EnsureLocalCapacityInternal(art::ScopedObjectAccess&, int, char const)+92) (BuildId: 354ca8e1c28a50e77c63f80311270dba)
F DEBUG : frida/frida#3 pc 003f575a /apex/com.android.runtime/lib/libart.so!libart.so (offset 0x3f4000) (art::JNI::PushLocalFrame(_JNIEnv*, int)+810) (BuildId: 354ca8e1c28a50e77c63f80311270dba)
F DEBUG : frida/frida#4 pc 0010aa27 /data/local/tmp/re.frida.server/frida-agent-32.so
F DEBUG : frida/frida#5 pc 0010a724 /data/local/tmp/re.frida.server/frida-agent-32.so

The code snippet that causes this crash is:

Java.perform(function () {
    var clazz = Java.use("android.os.Binder");
    clazz.getCallingUid.implementation = function() {
        var ret = this.getCallingUid();
        console.log('getCallingUid', ret);
        return ret;
    }
});

Frida-server version is: 12.8.13
I run x86 Android version of API 29 and the process that I'm trying to instrument is system_server.

Does anybody know how to fix this? I believe modifications to frida-core are required but I don't know where/how to start. Any help would be appreciated.

[oleavr]

Thanks for reporting! The best place to start would be to write a test for this here in frida-java-bridge, and then fix it. (Use make develop for a quick feedback loop once the test is written and reproduces the problem.)

[abdawoud]

Thank you very much for the tip. I added a new test case inside MethodTest.java as following:

@Test
public void implementCriticalNativeMethodWorks() {
    loadScript("var Binder = Java.use('android.os.Binder');" +
            "Binder.getCallingUid.implementation = function() {" +
            "var uid = this.getCallingUid();" +
            "send(uid);" +
            "return uid;" +
            "}");
    assertEquals("0", script.getNextMessage());
}

and the test fails with:

There was 1 failure:

1. implementCriticalNativeMethodWorks(re.frida.MethodTest)
   java.lang.AssertionError: expected:<0> but was:<null>
   at org.junit.Assert.fail(Assert.java:88)
   at org.junit.Assert.failNotEquals(Assert.java:834)
   at org.junit.Assert.assertEquals(Assert.java:118)
   at org.junit.Assert.assertEquals(Assert.java:144)
   at re.frida.MethodTest.implementCriticalNativeMethodWorks(MethodTest.java:509)
   at java.lang.reflect.Method.invoke(Native Method)
   at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
   at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
   at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
   at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
   at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
   at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
   at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
   at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
   at org.junit.runners.Suite.runChild(Suite.java:128)
   at org.junit.runners.Suite.runChild(Suite.java:27)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
   at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
   at org.junit.runner.JUnitCore.runMain(JUnitCore.java:77)
   at org.junit.runner.JUnitCore.main(JUnitCore.java:36)
   at re.frida.TestRunner.main(TestRunner.java:26)

I would really appreciate any help regarding how to fix this. Thank you.

[abdawoud]

I spent some time trying to understand the code and fix the problem above. I think this bug is related to #1, namely the incorrect resolution of quick_generic_jni_trampoline.

[abdawoud]

@oleavr I know that you are overwhelmed by more important stuff, but any chance this issue would be solved soon?

[oleavr]

@abdawoud Afraid I have way too much on my plate. But I'm happy to guide you down the rabbithole.

1. Set up a playground: https://gist.github.com/oleavr/cae76c895eb7d227216ed3ffe9dbbeb3
2. Start experimenting: frida -U -n system_server -l _agent.js

Let's walk through the restrictions.

Methods must be static—no objects for parameters, return values, or an implicit this.

Ok, nothing special here.

Only primitive types are passed to the native method.

All good so far.

The native method does not use the JNIEnv and jclass parameters in its function definition.

• We do use the env argument here. So that needs to change.
• We don't use the jclass argument as we've got the classWrapper already – so we are good here.

So given that we can't use the passed env, and we won't be receiving objects or returning any object, we should also not do pushLocalFrame(), popLocalFrame(), and we shouldn't collect ownedObjects either... So I would probably just rename makeMethodImplementation to makeRegularMethodImplementation, and handleMethodInvocation to handleRegularMethodInvocation. And then make a copy of both of them, replacing Regular with Critical, and trimming all the logic that's not relevant. And then here we just need to call either makeRegularMethodImplementation or makeCriticalMethodImplementation depending on the type of method. I'm assuming the NativeCallback signature is the same, but if not that's easy to change right below that.

The method must be registered with RegisterNatives instead of relying on dynamic JNI linking.

Not a concern for us.

So what do you think, wanna take a stab at it? You can hit me up on Telegram any time if you have any questions: https://t.me/fridadotre

[oleavr]

@abdawoud Actually that doesn't look like much work. Let me take a quick stab at it.

[oleavr]

Yay, the solution that I mentioned did work, but I realized there's a much simpler way. We can just remove the kAccCriticalNative bit of our ArtMethod, and we're good.