Frida: Frida on android 8.0 Oreo

[madushan1000]

I've been trying to play around with some apps on my One Plus 3 and it was recently updated to Android 8.0(Didn't have this issue on 7.1.1)

Now, whenever I try to run something like frida-trace -U com.twitter.android it returns the following error and crashes the app.

Failed to attach: timed out while waiting for session to establish

frida-ps -U works fine. For what it's worth I tried to edit frida/__init__.py and increased the _get_device timeout to 10 but it didn't help.

Does anyone have a solution? Or can guide me through how to track down the problem?

frida server version: 10.6.26(on Android 8 Oreo)
frida tools version: 10.6.26(on OS X El Capitan)

[akiannillo]

Any log message?

[madushan1000]

I have no idea how to get a log message, there is no documentation on how to enable debug logs in Frida server. But I have a feeling issue #398 you filed has something to do with it.

[oleavr]

@madushan1000 There isn't any logging in Frida's code – I believe that logging (as a debugging mechanism, not for auditing) is an anti-pattern as there's always going to be a value one forgot to include in the logging or a function that doesn't log, or a bug in a format string that only applies to a particular log level, etc., and it slows things down and makes the code harder to read and maintain.

The easiest way to debug it is to build it yourself (Frida is easy to build), either using a debugger with breakpoints or adding temporary logging.

[oleavr]

Considering that this was working on 7.1.1, I'm guessing that this is a missing SELinux rule in Frida's logic that patches the running kernel's policy:
https://github.com/frida/frida-core/blob/616a03d470afe24487af8a7c79f8f99643cb732f/lib/selinux/src/patch.c#L46-L54

Did you check logcat for audit errors? The ones with permissive=1 are harmless, but hopefully you'll see some without that happened at the time you attach()ed.

[madushan1000]

Good point about logging. I was trying to debug this without building Frida by myself, but the lack of precompiled debug tools(strace, ltrace) for Android, especially for arm64 is making it harder. And to get a copy of them, I might have to build AOSP itself.
So the correct way of going about this is building the Frida server for Android and running it under an android gdbserver?

On the other point: I have tried setting selinux to permissive on my phone and even then Frida didn't work. I'm not an expert on selinux and I'm not sure it's behaving the same on Android. I didn't specifically look of selinux audit logs, I will hopefully have some time to spend on this, this week.

[oleavr]

Cool! Yeah, just grab NDK r15c (version is important) and build frida-server. It's worth noting that Frida's shared library injector on Linux relies on ptrace briefly during the injection, so having a debugger attached to the target process is going to make it fail. (Long-term we'll hopefully have an optional kernel driver that avoids this problem. We don't have this issue on the other OSes though – well, except QNX.) So adding a few temporary log statements at strategic points is often easier than getting remote debugging set up and not interfering.

[madushan1000]

@oleavr Is there a way to avoid building android-server for all the architectures? I tried setting FRIDA_HOST to arm64, but it doesn't look like It's working as intended. It takes up quite a space (my SSD itn's that big :( ) and takes a considerable amount of time to rebuild.

Also, I have been facing the following issue while building install-macos

ninja: Entering directory `build/tmp-macos-x86/frida-gum'
ninja: error: '../../../frida-gum/tests/data/targetfunctions-darwin-x86.dylib', needed by 'tests/data/targetfunctions-darwin-x86.dylib', missing and no known rule to make it
make[1]: *** [build/frida-macos-x86/lib/pkgconfig/frida-gum-1.0.pc] Error 1
make: *** [install-macos] Error 2

Any idea what's causing this? I'm building from master.

[oleavr]

@madushan1000 Yes, look in Makefile.mac.mk or Makefile.linux.mk for the server-android target's dependencies (to the right of the :) and run make <one of them>, e.g.:

$ make build/frida-android-arm64/lib/pkgconfig/frida-core-1.0.pc

[oleavr]

As for the install-macos target, that seems to be broken. (PR welcome – I haven't used this target much myself but plan on adding proper install targets at some point.)

[madushan1000]

Nice, I will try that. I'm trying with the latest python frida from pip for now.

This is the output of dmesg | grep -E -i selinux

[35428.807710] selinux: avc:  denied  { set } for property=persist.vendor.camera.debug.logfile pid=1036 uid=1006 gid=1006 scontext=u:r:mm-qcamerad:s0 tcontext=u:object_r:default_prop:s0 tclass=property_service\x0a
[35439.447597] selinux: avc:  denied  { set } for property=persist.vendor.camera.debug.logfile pid=1036 uid=1006 gid=1006 scontext=u:r:mm-qcamerad:s0 tcontext=u:object_r:default_prop:s0 tclass=property_service\x0a
[36709.194204] [20171222_19:25:55.924908]@2 SELinux:  Context u:object_r:frida_file:s0 is not valid (left unmapped).
[36716.064064] [20171222_19:26:02.794769]@2 SELinux: security_load_policy, ss_initialized: 1
[36716.068928] [20171222_19:26:02.799618]@2 SELinux: 2048 avtab hash slots, 242638 rules.
[36717.450690] [20171222_19:26:04.181393]@2 SELinux: 2048 avtab hash slots, 242638 rules.
[36717.450716] [20171222_19:26:04.181424]@2 SELinux:  1 users, 4 roles, 2295 types, 0 bools, 1 sens, 1024 cats
[36717.450723] [20171222_19:26:04.181432]@2 SELinux:  91 classes, 242638 rules
[36717.454845] [20171222_19:26:04.185551]@2 SELinux:  Context u:object_r:frida_file:s0 became valid (mapped).
[36717.562320] [20171222_19:26:04.293023]@2 SELinux: security_load_policy, sidtab.shutdown: 0
[36721.932102] [20171222_19:26:08.662793]@2 selinux: SELinux: Loaded file_contexts\x0a
[36875.829826] [20171222_19:28:42.560533]@2 selinux: avc:  received policyload notice (seqno=3)\x0a
[37086.779257] [20171222_19:32:13.509960]@2 SELinux: security_load_policy, ss_initialized: 1
[37086.782891] [20171222_19:32:13.513596]@2 SELinux: 2048 avtab hash slots, 242638 rules.
[37088.126089] [20171222_19:32:14.856791]@3 SELinux: 2048 avtab hash slots, 242638 rules.
[37088.126124] [20171222_19:32:14.856831]@3 SELinux:  1 users, 4 roles, 2295 types, 0 bools, 1 sens, 1024 cats
[37088.126131] [20171222_19:32:14.856839]@3 SELinux:  91 classes, 242638 rules
[37088.240074] [20171222_19:32:14.970774]@3 SELinux: security_load_policy, sidtab.shutdown: 0
[37093.994991] [20171222_19:32:20.725678]@3 selinux: SELinux: Loaded file_contexts\x0a
[37187.111639] [20171222_19:33:53.842343]@2 selinux: avc:  received policyload notice (seqno=4)\x0a

Correct me if I'm wrong, but it doesn't seem like there are any selinux policy violations by frida.

I also noticed that sometimes the target app doesn't crash, but instead get very laggy, which seems to suggest the injection actually happen and then something goes wrong.

[madushan1000]

While trying to debug this, I got frida to compile with android ndk r16b, with some hackory.

cd ~/android-ndk-r16b/platforms/android-21/arch-arm64/usr
cp -rf ../../../../sysroot/usr/include .
cd include
mkdir asm
cp aarch64-linux-android/asm/* asm/
cd $FRIDA_HOME
ANDROID_NDK_ROOT=$HOME/android-ndk-r16b make -f Makefile.sdk.mk FRIDA_HOST=android-arm64
ANDROID_NDK_ROOT=$HOME/android-ndk-r16b make build/frida-android-arm64/lib/pkgconfig/frida-core-1.0.pc

I'm not sure why the unified headers are not picked up by frida build system(if failes while compiling efsutls), But it should probably go to a separate issue.

Unfortunately compiling with the new NDK didn't solve the original problem. I'll keep digging.

[madushan1000]

Hi @oleavr,
I did some debugging and it looks like the injected code doesn't start correctly. I think the injection happens fine though(_frida_helper_service_do_inject doesn't return 0). Frida server just times out waiting to receive something on the socket/fifo.
Is there any documentation I can read to get an understanding of how exactly the injection part happens?

[oleavr]

@madushan1000 Thanks for digging into this!

The Linux injector is explained in this talk:
https://www.youtube.com/watch?v=uc1mbN9EJKQ
But if you can verify that this function is reached:
https://github.com/frida/frida-core/blob/616a03d470afe24487af8a7c79f8f99643cb732f/lib/agent/agent-glue.c#L8
Then the injector is fine, and the issue must be in the transport:
https://github.com/frida/frida-core/blob/616a03d470afe24487af8a7c79f8f99643cb732f/lib/pipe/pipe-posix.c

Cheers!

[madushan1000]

@oleavr I wish I realized this before, but android apparently saves app crash dump to /data/tombstones. I took a look at the tombstone file related to one of the apps and noticed this section.

memory near x4:
    0000007c775ce928 00534c5420746365 542063696e6f6962  ect TLS.bionic T
    0000007c775ce938 616572687400534c 6c616e6769732064  LS.thread signal
    0000007c775ce948 74006b6361747320 6973206461657268   stack.thread si
    0000007c775ce958 617473206c616e67 6472617567206b63  gnal stack guard
    0000007c775ce968 7470006567617020 72635f6461657268   page.pthread_cr
    0000007c775ce978 6863732065746165 63737465735f6465  eate sched_setsc
    0000007c775ce988 2072656c75646568 696166206c6c6163  heduler call fai
    0000007c775ce998 007325203a64656c 5f64616572687470  led: %s.pthread_
    0000007c775ce9a8 6620657461657263 63203a64656c6961  create failed: c
    0000007c775ce9b8 69616620656e6f6c 007325203a64656c  lone failed: %s.
    0000007c775ce9c8 5f64616572687470 6620657461657263  pthread_create f
    0000007c775ce9d8 63203a64656c6961 2074276e646c756f  ailed: couldn't 
    0000007c775ce9e8 657461636f6c6c61 7479622d757a2520  allocate %zu-byt
    0000007c775ce9f8 657070616d207365 3a65636170732064  es mapped space:
    0000007c775cea08 7268747000732520 616572635f646165   %s.pthread_crea
    0000007c775cea18 656c696166206574 646c756f63203a64  te failed: could

And from it it looks like pthread_create failes. Or they maybe the symboles from the library. I'm not sure. I can't figure out a way to get a coredump style full memory dump on android to look into this further. If you're interested, I can send you the related tombstone file to inspect(I'm not posting here since I don't know if there anything I should not be posting public in it).

Also, do you know how can I link logcat lib to the frida-agent? I tried including <android/log.h> and adding -llog to by messing around with meson.build but It didn't work. I was probably doing it wrong.

[madushan1000]

I think this part would be helpful too,

Build fingerprint: 'OnePlus/OnePlus3/OnePlus3:8.0.0/OPR6.170623.013/10250816:user/release-keys'
Revision: '0'
ABI: 'arm64'
pid: 15656, tid: 15909, name: alogcatroot.app  >>> rs.pedjaapps.alogcatroot.app <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7c78f220c0
    x0   0000007c749fe360  x1   0000000000000001  x2   0000007c78f220c0  x3   0000007c77594f4c
    x4   0000007c775ce94f  x5   0000000000000000  x6   0000007c546fa4f0  x7   000000000007d882
    x8   0000000000000040  x9   8cd323293a1a4218  x10  8cd323293a1a4218  x11  0000007c546fa588
    x12  0000007c546fa500  x13  0000007c546fa4f0  x14  0000000000000100  x15  0000007c749ffcc8
    x16  0000007c775f3d88  x17  0000007c77594874  x18  0000000000000020  x19  0000000000000036
    x20  0000007c546fa4f0  x21  0000007c546fa4f0  x22  0000000000003d28  x23  0000007c749fe060
    x24  0000007c546fa570  x25  0000007c545fe000  x26  000000000000000b  x27  000000006f6b4ce8
    x28  000000006fce7ea0  x29  0000007c546fa4b0  x30  0000007c749fe0a0
    sp   0000007c546fa480  pc   0000007c78f220c0  pstate 0000000000000000
    v0   0000007c545fe0000000000000000000  v1   0000007ff36a76a00000007ff36a7710
    v2   00000000000000000000000000000004  v3   0000007c557920c00000007c557920b8
    v4   00000000000000000000000000000000  v5   0000000000000000000000003f800000
    v6   00000000000000003f80000000000000  v7   00000000000000000077006f0064006e
    v8   00000000000000000000000000000000  v9   00000000000000000000000000000000
    v10  00000000000000000000000000000000  v11  00000000000000000000000000000000
    v12  00000000000000000000000000000000  v13  00000000000000000000000000000000
    v14  00000000000000000000000000000000  v15  00000000000000000000000000000000
    v16  00000000000000000000000044d84000  v17  00000000000000000000000040000000
    v18  80200800000000008020000000000000  v19  00000000000000000000000000000000
    v20  00000000000000000000000000000000  v21  00000000000000000000000000000000
    v22  00000000000000000000000041600000  v23  00000000000000000000000000000000
    v24  0000000000000000000000003f800000  v25  0000000000000000000000003f800000
    v26  000000000000000000000000ebad808a  v27  000000000000000000000000ebad808b
    v28  000000000000000000000000ebad808c  v29  000000000000000000000000ebad808d
    v30  000000000000000000000000ebad808e  v31  00000000000000000000000000000001
    fpsr 00000013  fpcr 00000000

backtrace:
    #00 pc 00000000000010c0  [anon:linker_alloc:0000007c78f21000]
    #01 pc 000000000000009c  <anonymous:0000007c749fe000>

stack:
         0000007c546fa400  0077006f0064006e
         0000007c546fa408  0000000000000000
         0000007c546fa410  0000000000000000
         0000007c546fa418  0000007c775524e8  /system/lib64/libc.so (open)
         0000007c546fa420  0000000000001000
         0000007c546fa428  0000007c775ce94f  /system/lib64/libc.so
         0000007c546fa430  0000000000000000
         0000007c546fa438  0000007c546fa4f0
         0000007c546fa440  000000000007d882
         0000007c546fa448  0000000000000000
         0000007c546fa450  0000007c545fe000  [anon:thread stack guard page]
         0000007c546fa458  0000000000000000
         0000007c546fa460  0000007c6b60e000  [stack:15909]
         0000007c546fa468  8cd323293a1a4218
         0000007c546fa470  0000007c546fa4b0
         0000007c546fa478  0000007c749fe078
    #00  0000007c546fa480  0000007c546fa4f0
         ........  ........
    #01  0000007c546fa480  0000007c546fa4f0
         0000007c546fa488  0000007c546fa4f0
         0000007c546fa490  0000007c546fa4b0
         0000007c546fa498  0000007c775917a0  /system/lib64/libc.so (_ZL15__pthread_startPv+40)
         0000007c546fa4a0  0000007c77591778  /system/lib64/libc.so (_ZL15__pthread_startPv)
         0000007c546fa4a8  0000000000000000
         0000007c546fa4b0  0000007c546fa4e0
         0000007c546fa4b8  0000007c7754a2b8  /system/lib64/libc.so (__start_thread+72)
         0000007c546fa4c0  0000000000000000
         0000007c546fa4c8  0000000000000000
         0000007c546fa4d0  0000007c793a29b0
         0000007c546fa4d8  0000007c793a2a58
         0000007c546fa4e0  0000000000000000
         0000007c546fa4e8  0000000000000000
         0000007c546fa4f0  0000007c522894f0  [stack:15876]
         0000007c546fa4f8  0000000000000000

[madushan1000]

So, I found this and this.
Apparently android started enforcing mutually exclusive writable/executable pages in Android 8. But it looks like it's only applicable while loading libraries.
Can this be the issue? if so, can we use something like PTRACE_PEEKTEXT or somehow give up the writability of the allocated pages?

[oleavr]

@madushan1000 Yay, nice catch! Yes this does indeed seem to be the issue! Should be easy to fix.

[madushan1000]

@oleavr Any idea on how to fix this? Meanwhile, I'm trying to replicate the results with a small test program to see if codepage protection is actually enabled in the pages we allocate at runtime.

[oleavr]

I've fixed this and another issue in frida-core master. Next up is this issue:

E linker  : library "/data/local/tmp/re.frida.server/frida-agent-32.so"
("/data/local/tmp/re.frida.server/frida-agent-32.so")
needed or dlopened by "(unknown)" is not accessible for the namespace:
[
  name="(anonymous)",
  ld_library_paths="",
  default_library_paths="/data/app/com.android.chrome-2ElVtdOuGVdDMuA0sQzqIQ==/lib/arm:/data/app/com.android.chrome-2ElVtdOuGVdDMuA0sQzqIQ==/base.apk!/lib/armeabi-v7a",
  permitted_paths=""
]

[oleavr]

The next challenge is caused by a change starting with Android N, where the dynamic linker is now preventing apps from using private system libraries. To work around it we can either:

• Copy frida-agent-32/64.so into one of the app's own library directories. This is quite intrusive and not a nice solution.
• Make a copy of the .so in tmpfs by using memfd_create(), and loading that. This won't work on Android N, as this exception was added later.
• Call android_dlopen_ext() and provide a namespace. Seems tedious.
• Realizing that dlopen() is actually just a thin wrapper that tries to get the return address to identify the caller, e.g. on 32-bit ARM:

push {r7, lr}
mov r2, lr
bl #0xee55874d
pop {r7, pc}

(Meaning it calls an internal function that takes one additional argument: address of the caller.)
We can disassemble it at runtime to determine the inner function's address (0xee55874d in this example), and call that directly. By picking an address inside libc.so and passing that as the third argument we can pretend that libc.so is the one loading the library, so it looks like a system library is loading another system library, and we're good.

I think I will try to implement the last solution. It's a bit painful to need the architecture-specific bits, but it's trivial to parse this function so it's probably the least painful solution.

[oleavr]

Let's try this.

Releasing Frida 10.6.30 right now with these improvements. Tested successfully on a Nexus 5X running Android 8.1.0, on both 32- and 64-bit targets.

[thenak]

@madushan1000 did this work for you? I ran 10.6.30 instead of .28 and it still crashes the app upon frida-trace....

[madushan1000]

@thenak @oleavr Looks like It's working fine for some small targets (like aLogcat ROOT) but just crashes any bigger applications(like chrome or twitter). For medium-sized applications, there are different error messages.

medium sized apps

frida-trace -U -i open 17361
Failed to start tracing: script is destroyed

large apps

frida-trace -U -i open 4440
Failed to attach: timed out while waiting for session to establish

I'll try to get an idea of what's going on under the hood and file a different bug report when I have some time.

[madushan1000]

hi @oleavr, It looks like the dlopen/dlsym still has issues in android 8.0. Take a look at the bellow tombstone.

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'OnePlus/OnePlus3/OnePlus3:8.0.0/OPR6.170623.013/10250816:user/release-keys'
Revision: '0'
ABI: 'arm'
pid: 9845, tid: 1131, name: .android.chrome  >>> com.android.chrome <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
Cause: null pointer dereference
    r0 d6fe5360  r1 bd07f938  r2 00000000  r3 bd07fdf4
    r4 bd07f970  r5 00000000  r6 00000000  r7 000000aa
    r8 00002675  r9 00000000  sl d6fe4081  fp 0000000b
    ip 00000000  sp bd07f938  lr d6fe40c3  pc 00000000  cpsr 40010010
    d0  6166206d6c6c756e  d1  696c203a64656c69
    d2  6168207972617262  d3  20736920656c646e
    d4  7832634f4175497a  d5  335a75536d616468
    d6  657361622f3d3d67  d7  696c2f216b70612e
    d8  0000000000000000  d9  0000000000000000
    d10 0000000000000000  d11 0000000000000000
    d12 0000000000000000  d13 0000000000000000
    d14 0000000000000000  d15 0000000000000000
    d16 0000001100000021  d17 0000000000000000
    d18 0000000000000000  d19 000000000688d168
    d20 bc2c9d6f2871987b  d21 c000000000000000
    d22 3f90851a81e3a35f  d23 4008002200000000
    d24 4008000000000000  d25 3fdb6db6db6fabff
    d26 3fd55555518f264d  d27 3f80842100000000
    d28 0005c0000005c000  d29 0005c0000005c000
    d30 0000000000000000  d31 0000001700000017
    scr 2000001b

backtrace:
    #00 pc 00000000  <unknown>
    #01 pc 000000c1  <anonymous:d6fe4000>

stack:
         bd07f8f8  21ba20b0  /dev/ashmem/dalvik-main space (region space) (deleted)
         bd07f8fc  d6fe40b3
         bd07f900  00000000
         bd07f904  00000000
         bd07f908  00000000
         bd07f90c  00000000
         bd07f910  d6fe5260
         bd07f914  00000000
         bd07f918  00002675
         bd07f91c  f1b7749f  /system/bin/linker (__dl__Z10dlsym_implPvPKcS1_PKv+74)
         bd07f920  bd07f928
         bd07f924  f1b7742b  /system/bin/linker (__dl__ZL10dlopen_extPKciPK17android_dlextinfoPKv+70)
         bd07f928  00000000
         bd07f92c  bd07f970
         bd07f930  bd07f970
         bd07f934  00000000
    #00  bd07f938  00000000
         ........  ........
    #01  bd07f938  00000000
         bd07f93c  eeba3053  /system/lib/libdl.so (dlsym+8)
         bd07f940  000000aa
         bd07f944  d6fe40b3
         bd07f948  bd07f970
         bd07f94c  bd07f970
         bd07f950  00000078
         bd07f954  efd59401  /system/lib/libc.so (_ZL15__pthread_startPv+24)
         bd07f958  efd593e9  /system/lib/libc.so (_ZL15__pthread_startPv)
         bd07f95c  efd2c53f  /system/lib/libc.so (__start_thread+34)
         bd07f960  bd07f978
         bd07f964  efd593e9  /system/lib/libc.so (_ZL15__pthread_startPv)
         bd07f968  bd07f970
         bd07f96c  00000000
         bd07f970  be7af970  [stack:1100]
         bd07f974  c8676970  [stack:1177]

memory near r0:
    d6fe5340 00000000 00000000 00000000 00000000  ................
    d6fe5350 00000000 00000000 00000000 00000000  ................
    d6fe5360 65706970 6c6f723a 6c633d65 746e6569  pipe:role=client
    d6fe5370 7461702c 642f3d68 2f617461 61636f6c  ,path=/data/loca
    d6fe5380 6d742f6c 65722f70 6972662e 732e6164  l/tmp/re.frida.s
    d6fe5390 65767265 69702f72 652d6570 37346132  erver/pipe-e2a47
    d6fe53a0 36396436 37306432 62663034 61653737  6d962d0740fb77ea
    d6fe53b0 64623436 30623361 00326562 00000000  64bda3b0be2.....
    d6fe53c0 00000000 00000000 00000000 00000000  ................
    d6fe53d0 00000000 00000000 00000000 00000000  ................
    d6fe53e0 00000000 00000000 00000000 00000000  ................
    d6fe53f0 00000000 00000000 00000000 00000000  ................
    d6fe5400 00000000 00000000 00000000 00000000  ................
    d6fe5410 00000000 00000000 00000000 00000000  ................
    d6fe5420 00000000 00000000 00000000 00000000  ................
    d6fe5430 00000000 00000000 00000000 00000000  ................

memory near r1:
    bd07f918 00002675 f1b7749f bd07f928 f1b7742b  u&...t..(...+t..
    bd07f928 00000000 bd07f970 bd07f970 00000000  ....p...p.......
    bd07f938 00000000 eeba3053 000000aa d6fe40b3  ....S0.......@..
    bd07f948 bd07f970 bd07f970 00000078 efd59401  p...p...x.......
    bd07f958 efd593e9 efd2c53f bd07f978 efd593e9  ....?...x.......
    bd07f968 bd07f970 00000000 be7af970 c8676970  p.......p.z.pig.
    bd07f978 0000046b 00002675 00000000 bcf83000  k...u&.......0..
    bd07f988 000fc970 00001000 00000000 00000000  p...............
    bd07f998 00000003 00000000 d6fe4081 00000000  .........@......
    bd07f9a8 00000000 c39d9000 00000001 00000000  ................
    bd07f9b8 000fd000 00000000 bd07f9c0 bd07f970  ............p...
    bd07f9c8 00000016 00000000 00000000 21ba20b0  ............. .!
    bd07f9d8 bd07fdf4 00000000 00000000 00000000  ................
    bd07f9e8 00000000 00000000 00000000 00000000  ................
    bd07f9f8 00000000 00000001 00000000 00000000  ................
    bd07fa08 00000000 00000000 00000000 00000000  ................

memory near r3:
    bd07fdd4 00000000 00000000 00000000 00000000  ................
    bd07fde4 00000000 00000000 00000000 00000000  ................
    bd07fdf4 79736c64 6166206d 64656c69 696c203a  dlsym failed: li
    bd07fe04 72617262 61682079 656c646e 20736920  brary handle is 
    bd07fe14 6c6c756e 2f706d00 662e6572 61646972  null.mp/re.frida
    bd07fe24 7265732e 2f726576 64697266 67612d61  .server/frida-ag
    bd07fe34 2d746e65 732e3233 6e20226f 65646565  ent-32.so" neede
    bd07fe44 726f2064 6f6c6420 656e6570 79622064  d or dlopened by
    bd07fe54 75282220 6f6e6b6e 22296e77 20736920   "(unknown)" is 
    bd07fe64 20746f6e 65636361 62697373 6620656c  not accessible f
    bd07fe74 7420726f 6e206568 73656d61 65636170  or the namespace
    bd07fe84 61282220 796e6f6e 73756f6d 00002229   "(anonymous)"..
    bd07fe94 00000000 00000000 00000000 00000000  ................
    bd07fea4 00000000 00000000 00000000 00000000  ................
    bd07feb4 00000000 00000000 00000000 00000000  ................
    bd07fec4 00000000 00000000 00000000 00000000  ................

memory nead r3 section has the error. Should I open a new issue or re open this one?

[madushan1000]

Found this in the logcat. It looks like this only happens with 32bit processes. 64bit processes actually load the library but run into some other issue.

E linker  : library "/data/local/tmp/re.frida.server/frida-agent-32.so" ("/data/local/tmp/re.frida.server/frida-agent-32.so") needed or dlopened by "(unknown)" is not accessible for the namespace: [name="(anonymous)", ld_library_paths="", default_library_paths="/data/app/com.android.chrome-XXXXXXXX==/lib/arm:/data/app/com.android.chrome-XXXXXXXX==/base.apk!/lib/armeabi-v7a", permitted_paths=""]

[madushan1000]

I did some testing on 64bit targets, It looks like the scripts load fine on almost all 64bit targets except the twitter app. I'm not sure why. I checked and all of its jni libraries are 64bit objects.

Here is a snippet of printed messages from frida-agent around the crash for the twitter app. (command is frida-trace -U -i open ****)

on_connection_message: 
Type:    method-call
Flags:   none
Version: 0
Serial:  6
Headers:
  path -> objectpath '/re/frida/AgentSession/1'
  interface -> 're.frida.AgentSession10'
  member -> 'PostToScript'
  signature -> signature '(u)sbay'
Body: ((uint32 1,), '["frida:rpc", 1, "call", "resolve", [[["include", "function", "open"]]]]', false, @ay [])
UNIX File Descriptors:
  (none)

I noticed that it's different from something that works

on_connection_message Type:    method-call
Flags:   none
Version: 0
Serial:  10
Headers:
  path -> objectpath '/re/frida/AgentSession/1
  interface -> 're.frida.AgentSession10'
  member -> 'PostToScript'
  signature -> signature '(u)sbay'
  Body: ((uint32 2,), '["frida:rpc", 1, "call", "add", [[{"absolute_address": "0x77f7bb54e8", "handler": "/*\\n * Auto-generated by Frida. Please modify to match the signature of open.\\n * This stub is currently auto-generated from manpages when available.\\n *\\n * For full API reference, see: http://www.frida.re/docs/javascript-api/\\n */\\n\\n{\\n  /**\\n   * Called synchronously when about to call open.\\n   *\\n   * @this {object} - Object allowing you to store state for use in onLeave.\\n   * @param {function} log - Call this function with a string to be presented to the user.\\n   * @param {array} args - Function arguments represented as an array of NativePointer objects.\\n   * For example use Memory.readUtf8String(args[0]) if the first argument is a pointer to a C string encoded as UTF-8.\\n   * It is also possible to modify arguments by assigning a NativePointer object to an element of this array.\\n   * @param {object} state - Object allowing you to keep state across function calls.\\n   * Only one JavaScript function will execute at a time, so do not worry about race-conditions.\\n   * However, do not use this to store function arguments across onEnter/onLeave, but instead\\n   * use \\"this\\" which is an object for keeping state local to an invocation.\\n   */\\n  onEnter: function (log, args, state) {\\n    log(\\"open(\\" +\\n      \\"path=\\\\\\"\\" + Memory.readUtf8String(args[0]) + \\"\\\\\\"\\" +\\n      \\", oflag=\\" + args[1] +\\n    \\")\\");\\n  },\\n\\n  /**\\n   * Called synchronously when about to return from open.\\n   *\\n   * See onEnter for details.\\n   *\\n   * @this {object} - Object allowing you to access state stored in onEnter.\\n   * @param {function} log - Call this function with a string to be presented to the user.\\n   * @param {NativePointer} retval - Return value represented as a NativePointer object.\\n   * @param {object} state - Object allowing you to keep state across function calls.\\n   */\\n  onLeave: function (log, retval, state) {\\n  }\\n}\\n", "name": "open"}]]]', false, @ay [])
UNIX File Descriptors:
  (none)

Apps crashe instantly if they have 32bit libraries.

[madushan1000]

I'm not sure if this is correct but if frida is using 64bit libc return address to dlopen 32bit frida-agent, I think it can cause 32bit app crashing issue.

[oleavr]

@madushan1000

Looks like It's working fine for some small targets

Please don't use frida-trace -i open as the test-case – there's a known bug on Android where hooking open is problematic, and something we need to look into separately. Using the REPL with --no-pause should be a better test-case.

[oleavr]

@madushan1000

Found this in the logcat. It looks like this only happens with 32bit processes

Could you disassemble you 32-bit libart.so's dlopen implementation and paste it here? I suspect we're a bit too strict when trying to parse it here.

[madushan1000]

Looks like the REPL works fine with 64bit twitter app too. I didn't try to run any scripts though.

Here is the 32bit libart.so dlopen disassembly (from GDB)

Dump of assembler code for function dlopen@plt:
   0x000a6b9c <+0>:     add     r12, pc, #3145728       ; 0x300000
   0x000a6ba0 <+4>:     add     r12, r12, #569344       ; 0x8b000
   0x000a6ba4 <+8>:     ldr     pc, [r12, #4092]!       ; 0xffc
End of assembler dump.

[oleavr]

@madushan1000 Oops, sorry, I misspoke. I meant to say libdl.so, not libart.so. Could you try disassembling that? It should be a tiny function that calls another function with the same arguments plus one extra (that it gets from LR).

[madushan1000]

@oleavr Hi
this is from the libdl.so dlopen.

Dump of assembler code for function dlopen:
   0x00001038 <+0>: push    {r7, lr}
   0x0000103a <+2>: mov r2, lr
   0x0000103c <+4>: blx 0xe38 <__loader_dlopen@plt>
   0x00001040 <+8>: pop {r7, pc}
End of assembler dump.

[oleavr]

@madushan1000 Thanks! Could you try changing this line:

      insn[2].id == ARM_INS_BL &&

to:

      (insn[2].id == ARM_INS_BL || insn[2].id == ARM_INS_BLX) &&

And after the assignment here:

    impl = GSIZE_TO_POINTER (insn[2].detail->arm.operands[0].imm);

add another statement that sets the LSB in case of BLX:

    impl = GSIZE_TO_POINTER (insn[2].detail->arm.operands[0].imm);
    if (insn[2].id == ARM_INS_BLX)
      impl = GSIZE_TO_POINTER (GPOINTER_TO_SIZE (impl) | 1);

[madushan1000]

@oleavr Looks like the dlopen bug is gone, but now I'm getting a different crash due to improper open. I can't find where it's coming from. Here is the relevant section of the tombstone. Fault address is in libdl.so.

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'OnePlus/OnePlus3/OnePlus3:8.0.0/OPR6.170623.013/10250816:user/release-keys'
Revision: '0'
ABI: 'arm'
pid: 29053, tid: 29277, name: .android.chrome  >>> com.android.chrome <<<
signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 0xf6a80e38
    r0 ce127160  r1 00000001  r2 f58713d1  r3 00000000
    r4 c387f970  r5 c387f970  r6 c387f970  r7 000000c3
    r8 0000717d  r9 00000000  sl ce126081  fp 0000000b
    ip 000000c3  sp c387f948  lr ce1260a7  pc f6a80e38  cpsr 00070030
    d0  0000000001410004  d1  ffd1382800000004
    d2  ffd13828ffd138b0  d3  ffd13828cbb9510a
    d4  ffd13828ffd13868  d5  d63f689300000001
    d6  d5d77b41ffd138b0  d7  c49acbb0c49acbb0
    d8  0000000000000000  d9  0000000000000000
    d10 0000000000000000  d11 0000000000000000
    d12 0000000000000000  d13 0000000000000000
    d14 0000000000000000  d15 0000000000000000
    d16 c378300000000000  d17 00001000000fc970
    d18 0000000000000000  d19 00000000050ffb18
    d20 bbf4e12430fc073c  d21 c000000000000000
    d22 3f50863a98b18e3f  d23 4008002200000000
    d24 4008000000000000  d25 3fdb6db6db6fabff
    d26 3fd55555518f264d  d27 bf80842100000000
    d28 0005c0000005c000  d29 0005c0000005c000
    d30 00000000c3883268  d31 0000001700000017
    scr 2000001b

backtrace:
    #00 pc 00000e38  /system/lib/libdl.so
    #01 pc 000000a5  <anonymous:ce126000>

stack:
         c387f908  c387f970
         c387f90c  c387f970
         c387f910  00000078
         c387f914  f587601d  /system/lib/libc.so (mmap+28)
         c387f918  ffffffff
         c387f91c  00000000
         c387f920  ce11c000  [anon:thread signal stack guard page]
         c387f924  53564d41
         c387f928  00000000
         c387f92c  00000078
         c387f930  f58990c4  /system/lib/libc.so (_Z29__init_alternate_signal_stackP18pthread_internal_t+211)
         c387f934  cbb9510a  /dev/zero (deleted)
         c387f938  00000078
         c387f93c  ce12608d
         c387f940  ce11c000  [anon:thread signal stack guard page]
         c387f944  00001000
    #00  c387f948  c387f970
         ........  ........
    #01  c387f948  c387f970
         c387f94c  c387f970
         c387f950  00000078
         c387f954  f5899401  /system/lib/libc.so (_ZL15__pthread_startPv+24)
         c387f958  f58993e9  /system/lib/libc.so (_ZL15__pthread_startPv)
         c387f95c  f586c53f  /system/lib/libc.so (__start_thread+34)
         c387f960  c387f978
         c387f964  f58993e9  /system/lib/libc.so (_ZL15__pthread_startPv)
         c387f968  c387f970
         c387f96c  00000000
         c387f970  c3e7f970  [stack:29254]
         c387f974  00000000
         c387f978  0000725d
         c387f97c  0000717d
         c387f980  00000000
         c387f984  c3783000  [anon:thread stack guard page]

memory near r0:
    ce127140 00000000 00000000 00000000 00000000  ................
    ce127150 00000000 00000000 00000000 00000000  ................
    ce127160 7461642f 6f6c2f61 2f6c6163 2f706d74  /data/local/tmp/
    ce127170 662e6572 61646972 7265732e 2f726576  re.frida.server/
    ce127180 64697266 67612d61 2d746e65 732e3233  frida-agent-32.s
    ce127190 0000006f 00000000 00000000 00000000  o...............
    ce1271a0 00000000 00000000 00000000 00000000  ................
    ce1271b0 00000000 00000000 00000000 00000000  ................
    ce1271c0 00000000 00000000 00000000 00000000  ................
    ce1271d0 00000000 00000000 00000000 00000000  ................
    ce1271e0 00000000 00000000 00000000 00000000  ................
    ce1271f0 00000000 00000000 00000000 00000000  ................
    ce127200 00000000 00000000 00000000 00000000  ................
    ce127210 00000000 00000000 00000000 00000000  ................
    ce127220 00000000 00000000 00000000 00000000  ................
    ce127230 00000000 00000000 00000000 00000000  ................

memory near r2:
    f58713b0 b5804770 efcef7f4 60012109 30fff04f  pG.......!.`O..0
    f58713c0 b580bd80 f240460a f7f52141 bd80e812  [email protected]!......
    f58713d0 b580b082 4684b082 e9cd4813 f0112304  .......F.H...#..
    f58713e0 44780f40 68006800 d1019001 e0062300  @.xD.h.h.....#..
    f58713f0 9000a804 0004f040 f8bd9000 f4413010  [email protected].
    f5871400 f06f3200 46610063 ee04f7f5 9a014907  .2o.c.aF.....I..
    f5871410 68094479 1a896809 b002bf01 4080e8bd  yD.h.h.........@
    f5871420 4770b002 ef4ef7f4 0006ffde 0006ffb0  ..pG..N.........
    f5871430 f0114603 bf010f40 3200f441 0063f06f  [email protected].
    f5871440 23004619 f05cbf08 b580bb39 f7fea001  .F.#..\.9.......
    f5871450 bf00fe05 6e65706f 435f4f28 54414552  ....open(O_CREAT
    f5871460 63203a29 656c6c61 69772064 756f6874  ): called withou
    f5871470 70732074 66696365 676e6979 6d206120  t specifying a m
    f5871480 0065646f b580b081 f8dfb083 f012c04c  ode.........L...
    f5871490 93050f40 f8dc44fc f8dcc000 93023000  @....D.......0..
    f58714a0 2300d101 ab05e005 33049301 f8bd9301  ...#.......3....

--->f6a80000-f6a82fff r-x         0      3000  /system/lib/libdl.so (BuildId: 8e5717c0395ca45cb9f110425ae1463a)

[oleavr]

@madushan1000 Looks like it's crashing inside libdl.so, so we probably got the address of the inner dlopen() function wrong. Could you try the changes without the second statement that does | 1?

[madushan1000]

Hi @oleavr, Looks like it works. I created PR https://github.com/frida/frida-core/pull/162
Library actually loads and gives me a REPL when id do frida -U com.android.chrome --no-pause
But, `frida-trace -U -i com.android.chrome" still crash large applications(chrome, twitter).
I can look into what's wrong if you can point me where to look. Below are some of the tombstone content. I'll open a separate issue on frida-gum if it belongs there.

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'OnePlus/OnePlus3/OnePlus3:8.0.0/OPR6.170623.013/12041042:use
r/release-keys'
Revision: '0'
ABI: 'arm'
pid: 22913, tid: 23607, name: gum-js-loop  >>> com.android.chrome <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x10
ause: null pointer dereference
    r0 00000000  r1 00000000  r2 00000004  r3 00000000
    r4 c0ccc0b8  r5 000000df  r6 00000000  r7 bac90d90
    r8 00000000  r9 c0ccc0b8  sl c21165b8  fp bac90e58
    ip 00000000  sp bac90d38  lr b2f0ca04  pc b2a1c28e  cpsr 400b0030
    d0  0000000000000000  d1  0000000000000000
    d2  0000000000000000  d3  0000000000000000
    d4  67422d656d6f7268  d5  4f4175497a386464
    d6  536d616468783263  d7  622f3d3d67335a75
    d8  0000000000000000  d9  0000000000000000
    d10 0000000000000000  d11 0000000000000000
    d12 0000000000000000  d13 0000000000000000
    d14 0000000000000000  d15 0000000000000000
    d16 0000000000000000  d17 0000000000000000
    d18 000003c0000003c0  d19 000003c0000003c0
    d20 0000000800000008  d21 0000000800000008
    d22 0000000400000004  d23 0000000400000004
    d24 000023c1000003c1  d25 000063c1000043c1
    d26 000023c0000003c0  d27 000063c0000043c0
    d28 0005c0000005c000  d29 0005c0000005c000
    d30 0000000000f1ab76  d31 0000001700000017
    scr 6000009b

backtrace:
    #00 pc 0013728e  /data/local/tmp/re.frida.server/frida-agent-32.so

[BigFaceCat2017]

@oleavr Hi，i meet the same question. In your may, you invoke the inner function " __loader_dlopen(const char* filename, int flags, const void* caller_addr) ". and i call it with caller_addr is open address in my code, however, there is a error "dlopen failed: library "/data/local/tmp/libhello.so" needed or dlopened by "(unknown)" is not accessible for the namespace "(anonymous)". my phone is Pixel2, android 9.0.

[vogelfreiheit]

Hi! Take a look at https://github.com/frida/frida/issues/1432 and https://github.com/frida/frida-core/issues/339. Seems like a similar problem. I haven't put time into debugging it yet (swamped with work, this is part of it).

My speculative guess would be that the injector is failing somewhere to allocate memory. And a NULL ptr check is missing there. mmap() and co will happily do this and your luck depends on verifying the system call return code... malloc() will also happily return NULL for multiple scenarios.