You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello,
I have been experimenting with uncommon platforms, and I run into a problem with x86 musl platforms at injection time. There is a neat trick performed during ptrace by directing execution to mmap(), however, on x86/musl the mmap never returns, or returns bad. If I force it to use the text segment swap, it works reliably. I'd love to find out why this happens, and I might experiment, but in the meantime I just log the issue here:
If I run the following patch, it all works
Hello,
I have been experimenting with uncommon platforms, and I run into a problem with x86 musl platforms at injection time. There is a neat trick performed during ptrace by directing execution to mmap(), however, on x86/musl the mmap never returns, or returns bad. If I force it to use the text segment swap, it works reliably. I'd love to find out why this happens, and I might experiment, but in the meantime I just log the issue here:
If I run the following patch, it all works
`diff --git a/src/linux/frida-helper-backend.vala b/src/linux/frida-helper-backend.vala
index 9da2152..cca135c 100644
--- a/src/linux/frida-helper-backend.vala
+++ b/src/linux/frida-helper-backend.vala
@@ -1083,7 +1083,7 @@ namespace Frida {
uint64 remote_munmap = 0;
ProcMapsEntry? remote_libc = ProcMapsEntry.find_by_path (pid, local_libc.path);
bool same_libc = remote_libc != null && remote_libc.identity == local_libc.identity;
`
The text was updated successfully, but these errors were encountered: