Frida on android 8.0 Oreo #394
Comments
|
Any log message? |
|
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. |
|
@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. |
|
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: Did you check logcat for audit errors? The ones with |
|
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. 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. |
|
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. |
|
@oleavr Is there a way to avoid building android-server for all the architectures? I tried setting Also, I have been facing the following issue while building Any idea what's causing this? I'm building from master. |
|
@madushan1000 Yes, look in $ make build/frida-android-arm64/lib/pkgconfig/frida-core-1.0.pc |
|
As for the |
|
Nice, I will try that. I'm trying with the latest python frida from pip for now. This is the output of 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. |
|
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.pcI'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. |
|
Hi @oleavr, |
|
@madushan1000 Thanks for digging into this! The Linux injector is explained in this talk: Cheers! |
|
@oleavr I wish I realized this before, but android apparently saves app crash dump to 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 |
|
I think this part would be helpful too, |
|
So, I found this and this. |
|
@madushan1000 Yay, nice catch! Yes this does indeed seem to be the issue! Should be easy to fix. |
|
@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. |
|
I've fixed this and another issue in frida-core master. Next up is this issue: |
|
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:
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.) 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. |
|
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. |
|
@madushan1000 did this work for you? I ran 10.6.30 instead of .28 and it still crashes the app upon frida-trace.... |
|
@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 large apps 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. |
|
hi @oleavr, It looks like the dlopen/dlsym still has issues in android 8.0. Take a look at the bellow tombstone. memory nead r3 section has the error. Should I open a new issue or re open this one? |
|
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. |
|
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 I noticed that it's different from something that works Apps crashe instantly if they have 32bit libraries. |
|
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. |
Please don't use |
Could you disassemble you 32-bit libart.so's |
|
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) |
|
@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 |
|
@oleavr Hi |
|
@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); |
|
@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. |
|
@madushan1000 Looks like it's crashing inside |
|
Hi @oleavr, Looks like it works. I created PR frida/frida-core#162 |
|
@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. |
|
Hi! Take a look at #1432 and frida/frida-core#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. |
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.androidit returns the following error and crashes the app.frida-ps -Uworks fine. For what it's worth I tried to editfrida/__init__.pyand increased the_get_devicetimeout 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)
The text was updated successfully, but these errors were encountered: