OWASP / owasp-mastg

The Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes the technical processes for verifying the controls listed in the OWASP Mobile Application Security Verification Standard (MASVS).
https://mas.owasp.org/
Creative Commons Attribution Share Alike 4.0 International
11.62k stars 2.3k forks source link

Obfuscation techniques for Android native code #1654

Closed cpholguera closed 3 years ago

cpholguera commented 4 years ago

Add recommendations about obfuscation for Android native code?

See: https://darvincitech.wordpress.com/2020/01/07/security-hardening-of-android-native-code/

All 3 mechanisms are applied on the github project created for Frida detection and the obfuscated APK is provided for interested reverse engineers to analyse. https://github.com/darvincisec/DetectFrida

su-vikas commented 4 years ago

If no one is taking this one, I will take this one up :)

cpholguera commented 4 years ago

Hi Vikas, thanks for taking this one. We're not sure if we're adding this or not. We'll have to discuss internally first. If could prepare a little summary before the PR itself, that'd help ;)

Also it would be interesting to know if the same techniques are applicable for iOS.

su-vikas commented 4 years ago

@cpholguera It seems the blogpost is by my friend and I have asked him to directly contribute to this ticket. @darvincisec

cpholguera commented 4 years ago

thanks @su-vikas, that sounds great, thanks for asking him directly.

darvincisec commented 4 years ago

thanks @su-vikas. @cpholguera I will take this. Will provide a summary before the PR

cpholguera commented 4 years ago

Ticket assigned. Thanks @darvincisec, looking forward to it ;)

darvincisec commented 3 years ago

@cpholguera Apologies for the delay..Here is a summary for this issue: Libc APIs offer a low hanging fruit for attackers to analyse the file, memory, string related operations done by the application.Most of the application protection mechanism rely on libc APIs, so an adversary can easily fake the files or string operations( for ex: root checks relying on presence of su files, hook detection relying on presence of specific framework by doing string compare, debugger detection based on verifying the presence of tracerpid in a file etc) thereby bypassing the runtime checks done by the App. Also memory operations done with cryptographic keys are vulnerable to hooking attacks.To mitigate the risk related to usage of libc APIs, syscalls can be used in place of file operations such as open, read,etc and custom implementation used in place of string and memory related operations.To mitigate the risk of identifying custom implementation equating to original APIs, developers can make use of obfuscation tool such as OLLVM(though not maintained by the community). Obfuscating the native code can complicate the control flow graphs thereby making it harder to be analysed with reverse engineering tools like IDA Pro, Ghidra etc.

Let me know if you think a PR can be raised

cpholguera commented 3 years ago

No worries, thanks for taking the time to write the summary. I really like the proposal, so please go ahead ;) I'd say 0x05j is the chapter for this, you should probably add the content across the different (sub)sections. What do you think? Whenever you have an outline of what you'll add, I can gladly take a look at it. If you have any questions please don't hesitate to contact us here or on Slack.

cpholguera commented 3 years ago

Hey @darvincisec, @su-vikas, any news on this? Looking forward to your PR ^^

cpholguera commented 3 years ago

This issue had a misleading title because the article is called Security Hardening, I've updated it. We're not talking about security hardening but rather obfuscation.

This should be the right place to put the new content:

https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05j-Testing-Resiliency-Against-Reverse-Engineering.md#testing-obfuscation-mstg-resilience-9

The thing is that probably there's not a lot to be written. The comment from Darvin (https://github.com/OWASP/owasp-mstg/issues/1654#issuecomment-696241099) pretty much covers this topic. We won't explain how to implement this types of protections but rather raise awareness that this might happening/could be found in some apps. There's probably less that the pentester can do about it anyway. Or do you have any more ideas on this?

In the other section, about resiliency against reverse engineering tools, 1-2 lines max. could be added linking to this section and indicating that the protections might be using these techniques.