Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

False positive when run on x86 architecture #31

Open
flikkr opened this issue Dec 27, 2022 · 7 comments
Open

False positive when run on x86 architecture #31

flikkr opened this issue Dec 27, 2022 · 7 comments

Comments

@flikkr
Copy link

flikkr commented Dec 27, 2022

Firstly, thanks for the repo. I wanted to try and get this sample project to run on 32-bit architecture since it would just crash on older devices, so I added x86 to the list of valid ABIs in build.gradle.

...
ndk {
     abiFilters 'arm64-v8a', 'armeabi-v7a', 'x86_64', 'x86'
}
...

Because of that, all system calls using the my_ prefix are broken once we try to run in x86. After removing all the my_ prefixes from the system calls, the sample app seems to be working as expected except for the check in the detect_frida_memdiskcompare function. The logs indicate that the libc library has a mismatching checksum despite the device being clean. I encountered this issue when running the app on a Pixel 4 emulator on x86 ABI with API version 30. This checksum mismatch did not occur on different x86 emulator running on API 29. Any idea what could be causing this?

Logcat

2022-12-27 18:10:33.630 7534-7561/com.darvin.security V/DetectFrida: Map [b9c26000-b9c29000 r-xp 00000000 fd:05 49183                              /data/app/~~CdhyIBdGvW9M9-2j_yxpNg==/com.darvin.security-HX80p3_DA5ykyXtiMkYaKQ==/lib/x86/libnative-lib.so]
2022-12-27 18:10:33.630 7534-7561/com.darvin.security V/DetectFrida: Checksum:[44199][44199]
2022-12-27 18:10:33.630 7534-7561/com.darvin.security V/DetectFrida: Checksum:[494221][494221]
2022-12-27 18:10:33.630 7534-7561/com.darvin.security V/DetectFrida: Map [b9c29000-b9c2a000 r--p 00002000 fd:05 49183                              /data/app/~~CdhyIBdGvW9M9-2j_yxpNg==/com.darvin.security-HX80p3_DA5ykyXtiMkYaKQ==/lib/x86/libnative-lib.so]
2022-12-27 18:10:33.630 7534-7561/com.darvin.security V/DetectFrida: Map [b9c2a000-b9c2b000 rw-p 00003000 fd:05 49183                              /data/app/~~CdhyIBdGvW9M9-2j_yxpNg==/com.darvin.security-HX80p3_DA5ykyXtiMkYaKQ==/lib/x86/libnative-lib.so]
2022-12-27 18:10:33.806 7534-7561/com.darvin.security V/DetectFrida: Map [e5e61000-e5ea3000 r--p 00000000 07:60 17                                 /apex/com.android.runtime/lib/bionic/libc.so]
2022-12-27 18:10:33.806 7534-7561/com.darvin.security V/DetectFrida: Map [e5ea3000-e5f4f000 r-xp 00041000 07:60 17                                 /apex/com.android.runtime/lib/bionic/libc.so]
2022-12-27 18:10:33.808 7534-7561/com.darvin.security V/DetectFrida: Checksum:[67333658][67435579]
2022-12-27 18:10:33.808 7534-7561/com.darvin.security V/DetectFrida: Executable Section Manipulated, maybe due to Frida or other hooking framework.Act Now!!!
2022-12-27 18:10:33.808 7534-7561/com.darvin.security V/DetectFrida: Checksum:[1008449][1051236]
2022-12-27 18:10:33.809 7534-7561/com.darvin.security V/DetectFrida: Executable Section Manipulated, maybe due to Frida or other hooking framework.Act Now!!!
2022-12-27 18:10:33.809 7534-7561/com.darvin.security V/DetectFrida: Map [e5f4f000-e5f52000 r--p 000ec000 07:60 17                                 /apex/com.android.runtime/lib/bionic/libc.so]
2022-12-27 18:10:33.809 7534-7561/com.darvin.security V/DetectFrida: Map [e5f52000-e5f54000 rw-p 000ee000 07:60 17                                 /apex/com.android.runtime/lib/bionic/libc.so]
@darvincisec
Copy link
Owner

Hi,
This needs to be investigated. Do you see a false positive on arm32 device as well ?

@flikkr
Copy link
Author

flikkr commented Feb 3, 2023

Hi @darvincisec, sorry for the delayed response. I tried running on arm32 device and no false positives occured. It seems like it only happens on this one emulator configuration. Tried recreating a fresh emulator with the same configuration and still getting the "Executable Section Manipulated" message.

@flikkr flikkr mentioned this issue Feb 3, 2023
Open
@jhlee8804 jhlee8804 mentioned this issue Mar 1, 2023
Open
@flikkr
Copy link
Author

flikkr commented Mar 2, 2023

Hi @darvincisec, do you have any additional information or insights to share regarding this issue? I'm open to working on it but not sure where to start.

@sektr63a
Copy link

@flikkr Hi. Did you find a solution?

@flikkr
Copy link
Author

flikkr commented Jan 23, 2024

@sektr63a unfortunately no

@Nastya1808
Copy link

Nastya1808 commented Jun 7, 2024 •
edited
Loading

Unfortunately this happens not only on a specific emulator. This check does not work on a wide range of devices according to our logging information. Needs to be investigated for sure.

@Nastya1808
Copy link

Nastya1808 commented Jun 10, 2024 •
edited
Loading

I have the same problem. We implemented the detect_frida_memdiskcompare check in our app and are now receiving approximately 12 million log events per week.
Top device model affected: 23028RNCAG, RMX3690, 2305EPCC4G, RMX3581, SM-A135F, RMX3231, 220733SFG, 23129RN51X, SM-A032F, SM-A105F. Most of these devices run on Cortex-A55, A57, or A53 CPUs, which are based on ARMv8.x architecture and support both aarch64 and aarch32.

I personally checked on a Samsung A13 (where the bug is reproduced), and it appears to use a 32-bit libc.so. This is the only noticeable difference compared to other devices.

I also debugged the function and the reason is that checksum of the executable section is not matching as mentioned in the connected issues. I suppose it may be connected with the system's architecture of CPUs like Cortex-A55 and A57.

Update: The process runs in a 32-bit environment too, so now I don't know. I only see that something goes wrong with the executable section range; it occurs before the beginning of the section start:
((unsigned long) buffer + pElfSectArr->offset[i]) < start.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@sektr63a @Nastya1808 @flikkr @darvincisec