Choosing between DexGuard and ProGuard in Android development

Introduction

Application security, performance, and application size are crucial quality attributes that are frequently overshadowed by functionality, primarily due to additional time and costs. However, these attributes will play a decisive role in determining the success of your application.

Recent decades have witnessed numerous corporate financial losses and scandals following a data or security breach (see this HBR article on the devastating business impacts of a cyber breach). This has elevated security to a top priority for many organizations.

However, as VasonBourne’s survey highlights, there’s still significant potential for enhancing security programs and protocols to safeguard public-facing mobile apps against basic attacks and their repercussions. Remarkably, “96% of respondents depend to some degree, if not entirely, on end users’ mobile operating systems for app security.”

Current trends in mobile applications are compelling developers to not only acknowledge the possibility of improvement – a positive step in itself – but also to fully integrate security throughout the development lifecycle, going beyond mere awareness.

So, what are our options?

Although numerous options exist to enhance mobile app security, such as libraries, processes, and algorithms, this discussion will center on two widely-used libraries: ProGuard and DexGuard.

ProGuard

Going back a few years, right after joining my first Android project, I noticed a couple of files whose purpose wasn’t immediately clear to me; some magical set of files which included the word proguard on them. I soon realized just what they meant and what exactly they did on my project. They belong to the configuration of ProGuard – but keep in mind that they can be used with another similar tool named R8. ProGuard is, mainly, an open-source Java bytecode shrinker with some security features which follow the next steps per its manual:

 

• Shrink: detects and removes unused classes, fields, methods, and attributes.
• Optimize: optimizes bytecode and removes unused instructions.
• Obfuscate: renames the remaining classes, fields, and methods using short meaningless names.
• Preverify: adds preverification information to the classes, which is required for Java Micro edition and for Java 6 and higher.

 

The Obfuscate step is the most important, where the library provides a layer of security against reverse engineering, where ill-intentioned users can use disassemblers/decompilers to easily obtain the source code of our applications. With our classes, fields and methods being renamed to meaningless names, static reverse engineering (or the inspection/parsing of code when it isn’t executing) becomes a harder task. While this is not a perfect solution since it doesn’t counter dynamic reverse engineering, it’s still better to have it than not.

As Android developers, we must aim to deliver smaller application sizes to our users. Large applications are burdensome to compile and build, and they may be unfeasible for end-users to download if their storage capacity is limited. Every developer should eliminate superfluous code and ideally incorporate a shrinker/optimizer in their projects.

Some known limitations include:

• The optimization algorithms assume that the code never intentionally throws an exception to achieve something and will remove code which does. Optimization should be turned off to avoid its removal.
• The optimization algorithms also assume that the code never creates busy-waiting loops without a volatile field, and will remove said loops. Again, optimization should be turned off in order to avoid its removal.

DexGuard

Upon researching ProGuard, you’ll inevitably come across DexGuard, a subscription-based, paid library from Guardsquare, the creators of ProGuard. It builds upon its predecessor’s capabilities, adding the following features according to their documentation (also see these articles: ProGuard vs. DexGuard: An Overview and Mobile Runtime Application Self-Protection (RASP)):

 

• Polymorphic protection: each build has a different obfuscation configuration.

• Code virtualization: transforms method implementations into instructions for randomly generated virtual machines.

• Arithmetic obfuscation: changes simple arithmetic and logical expressions into complex equivalents.

• Control flow obfuscation: modifies the logical structure of the code.

• Encryption: encrypts classes, fields, resource files, native libraries, etc.

• Runtime Application Self-Protection (RASP): protection against dynamic analysis via monitoring for suspicious behavior at runtime. Here you can detect emulated, rooted/jailbroken devices and hooks as two examples.

 

We can very easily upgrade from ProGuard to DexGuard as you can use the former’s configuration files with the latter. The main caveat is that DexGuard, being a commercial product, requires a paid subscription. This might seem like a big issue until you take into account that the cost of proper security measures is way less than that of fixing a vulnerability or dealing with a leak of information. With your subscription you also gain access to personalized support (which works on two tiers based on needs) with implementation, bugs, configuration optimization, and project-specific support.

Some known limitations include:

• False positives when flagging lesser known devices as rooted.
  • This isn’t particularly common but I have seen it happen. This was fixed by a newer release of the library.
• As it is based on ProGuard, some useful code can be deleted leading to bugs.

Which should we use?

Having compared DexGuard and ProGuard, now we can tackle the main question: which should I use in my project? A couple of questions should be answered before choosing one:

• Would my application benefit from a shrinker or optimizer?
  • Most likely answer to this question is yes. While optimizations should be a priority, they are not always included in the scope of a project nor covered by budget. Should this be the only question answered affirmatively, ProGuard should be enough.
• Would sensitive information, resources, critical functionalities be compromised by static or dynamic reverse engineering of the application?
  • If the answer is yes, DexGuard is the way to go. Even though ProGuard does some code obfuscation, it will only hinder static analysis up to a certain degree and dynamic analysis will still be available. 

 

Sources and further reading

1. Companies’ Stock Value Dropped 7.5% after Data Breaches. Kacy Zurkus. Info Security Magazine. 15 May 2019 https://www.infosecurity-magazine.com/news/companies-stock-value-dropped-1/
2. The Devastating Business Impacts of a Cyber Breach. Keman Huang, Xiaoqing Wang, William Wei, and Stuart Madnick. Harvard Business Review. 4 May 2023 https://hbr.org/2023/05/the-devastating-business-impacts-of-a-cyber-breach
3. Mobile Apps Aren’t Secure Enough, Despite Dev Teams’ Priorities. Vason Bourne, GuardSquare. (Available for download after subscription through this link https://www.guardsquare.com/state-of-mobile-application-security-report)
4. ProGuard Manual https://www.guardsquare.com/manual/home
5. ProGuard https://www.guardsquare.com/proguard
6. ProGuard vs. DexGuard: An Overview. https://www.guardsquare.com/blog/dexguard-vs.-proguard
7. DexGuard https://www.guardsquare.com/dexguard
8. Mobile Runtime Application Self-Protection (RASP) https://www.guardsquare.com/runtime-application-self-protection-rasp
9. ProGuard manual. Troubleshooting – Limitations https://www.guardsquare.com/manual/troubleshooting/limitations