search

reveny / Android-Library-Remap-Hide

Remap a library to avoid detection
GNU General Public License v3.0
100 stars 33 forks source link

Crash Android 9 #1

Open Ezriral opened 4 months ago

Ezriral commented 4 months ago

I got an issue here.

Allocated at address 0x7fa21a321000 with size of 856064

=>

06-29 11:56:00.726 7293 7360 I gebug : Allocated at address 0x7fa21a321000 with size of 856064 06-29 11:56:00.728 7293 7360 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xdead0000 in tid 7360 (.fb.gam.gc), pid 7293 (.fb.gam.gc) 06-29 11:56:00.749 7545 7545 E cutils-trace: Error opening trace file: Permission denied (13) 06-29 11:56:00.773 7546 7546 I crash_dump64: performing dump of process 7293 (target tid = 7360) 06-29 11:56:00.778 7546 7546 F DEBUG : 06-29 11:56:00.778 7546 7546 F DEBUG : Build fingerprint: 'google/google/G011A:9/mv-dev103041042:user/release-keys' 06-29 11:56:00.778 7546 7546 F DEBUG : Revision: '0' 06-29 11:56:00.778 7546 7546 F DEBUG : ABI: 'x86_64' 06-29 11:56:00.778 7546 7546 F DEBUG : pid: 7293, tid: 7360, name: .fb.gam.gc >>> fb.gam.gc <<< 06-29 11:56:00.778 7546 7546 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xdead0000 06-29 11:56:00.778 7546 7546 F DEBUG : rax 00000000dead0000 rbx 000000000c39331c rcx de0fd3d49230ca87 rdx 00005650c8d163e0 06-29 11:56:00.778 7546 7546 F DEBUG : r8 0000000000000008 r9 0000000000000013 r10 0000000000000008 r11 0000000000000246 06-29 11:56:00.778 7546 7546 F DEBUG : r12 00007fa35dca53e0 r13 00007fa340778070 r14 00007fa35e02bb00 r15 00007fa340778410 06-29 11:56:00.778 7546 7546 F DEBUG : rdi 00005650c8d163f0 rsi 0000000000000004 06-29 11:56:00.778 7546 7546 F DEBUG : rbp 00007fa35e08ef80 rsp 00007fa33f4f9300 rip 00007fa35db7dab7 06-29 11:56:00.780 7546 7546 F DEBUG : 06-29 11:56:00.780 7546 7546 F DEBUG : backtrace: 06-29 11:56:00.780 7546 7546 F DEBUG : #00 pc 00000000002f1ab7 /system/lib64/libhoudini.so 06-29 11:56:00.780 7546 7546 F DEBUG : #01 pc 00000000001db250 /system/lib64/libhoudini.so 06-29 11:56:00.780 7546 7546 F DEBUG : #02 pc 00000000000f9f66 /system/lib64/libhoudini.so 06-29 11:56:00.781 7546 7546 F DEBUG : #03 pc 00000000002f6143 /system/lib64/libhoudini.so

any ideas, happen with all apps on Android 9 64bit Emulator.

reveny commented 4 months ago

First of all, please make sure that you do not remap the library this code runs in, that will not work. This might also be a problem with arm translation (libhoudini). I will do some testing around that.

hayate001 commented 4 months ago

First of all, please make sure that you do not remap the library this code runs in, that will not work. This might also be a problem with arm translation (libhoudini). I will do some testing around that.

for me with andorid 14 and LDplayer it still the same , it not calling libmenu . can you add this project for LGL

reveny commented 4 months ago

First of all, please make sure that you do not remap the library this code runs in, that will not work. This might also be a problem with arm translation (libhoudini). I will do some testing around that.

for me with andorid 14 and LDplayer it still the same , it not calling libmenu . can you add this project for LGL

I have already made a mod menu project implementing it, maybe have a look at that.

Ezriral commented 2 months ago

@reveny would you spare a few words and explain why it is not possible to remap it when it gets called from the library i want to hide? is their are conflict? would be nice if you could explain it to me. thank you btw for it.

reveny commented 2 months ago

@reveny would you spare a few words and explain why it is not possible to remap it when it gets called from the library i want to hide? is their are conflict? would be nice if you could explain it to me. thank you btw for it.

From my understanding, the linker makes sure that only one instance of a shared library, like liba.so, is in memory. When liba.so tries to remap itself using mremap, it’s essentially trying to reload itself into different memory regions while it’s still running. This self-reloading can mess up the existing library executing the remap and cause crashes. It may has to do something with the return address of the mremap call since it will return to the old address it was called from and the issue here being that the library has moved and thus the return address points to bad memory. At least that's my understanding but I’m not sure if that’s exactly correct.