According to recent app security research conducted by Guardsquare, fewer than half of the top 3,000 financial services Android apps on the market use code obfuscation. Taking a deeper look, the same research reveals that less than 10% of them use additional code protection techniques. Given the fact that application reverse engineering and tampering risks are included in the OWASP mobile top 10, the application protection rate is very low.
One of the major reasons for the state of mobile application protection, despite serious security concerns such as the exposure of sensitive data and IP, is that without proper tools, it takes significant time and effort to develop and maintain a strong, diverse multi-layered security implementation. With the release of DexGuard 8.7, we made it easy to implement and maintain a diverse runtime application self-protection (RASP) check base.
RASP stands for runtime application self-protection. This technology is used to detect and prevent attacks on your mobile application when it is running.
If your mobile app is effectively obfuscated, it is already protected against static analysis and reverse engineering. However, at runtime there are many methods that attackers can use to tamper with your application.
Here are a few examples of what runtime attacks can achieve:
RASP makes your application resilient against such attack scenarios by preventing attackers from using debuggers, code tracing tools, or hooking frameworks.
Many mobile application protection tools on the market provide RASP functionality in the form of an SDK. The development team has to manually add calls to the RASP SDK throughout the application code to detect and prevent various runtime attacks. This approach gives a developer a lot of control; however, it leaves two important opportunities for improvement:
Alternatively, injecting RASP checks in the code automatically allows developers to easily maintain a large number of checks because it is the configuration and not source code that is impacted. In a real-world application, tens of thousands of RASP checks can be injected in the application and even in dependencies for which no source code is available. The checks are injected at different places automatically in every new build, effectively invalidating any prior analysis and reverse engineering effort.
When injecting RASP checks with DexGuard, you will need to consider both security sensitivity and performance sensitivity of the code.
By default, DexGuard uses a filter that will include the widest possible range of candidate classes. You can override this filter to provide exclusions, such as:
Using this approach, your RASP checks will be injected in an effective way. At the same time, your team will not have to write code to invoke every single check manually.
DexGuard has an option to automatically inject RASP checks into your application to protect them against runtime attacks. Automatic RASP injection makes application shielding more diverse and easier to maintain. Development teams simply switch injection on and configure the filter to define in which classes to inject RASP checks. DexGuard will take care of the rest, injecting multiple checks - and at a different location in every new build.