Closed cpholguera closed 3 years ago
If no one is taking this one, I will take this one up :)
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.
@cpholguera It seems the blogpost is by my friend and I have asked him to directly contribute to this ticket. @darvincisec
thanks @su-vikas, that sounds great, thanks for asking him directly.
thanks @su-vikas. @cpholguera I will take this. Will provide a summary before the PR
Ticket assigned. Thanks @darvincisec, looking forward to it ;)
@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
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.
Hey @darvincisec, @su-vikas, any news on this? Looking forward to your PR ^^
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:
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.
Add recommendations about obfuscation for Android native code?
See: https://darvincitech.wordpress.com/2020/01/07/security-hardening-of-android-native-code/