April 18, 2023
Key Takeaways
- Unauthorized app modding is one of the prevalent mobile app security threats that can cause a significant impact on the bottom line and brand image of both large and small mobile app publishers.
- This type of mobile application attack is very difficult to detect because the changes are often small enough to not cause any significant behavior discrepancy that can be detected on the server side.
- Combining multiple layers of security mechanisms is the best way to prevent reverse engineering and tampering of your mobile apps.
A study estimates that 15% of all apps in Android app stores are modded and repackaged. These altered versions of the original apps are not only potentially malicious but might also have a significant negative impact on the app publisher - from brand damage, and compromised product integrity, all the way to impact on business revenue.
This blog is a companion blog to our “The Invisible Thief” webinar, where we explore what App modding is, how it works, how attackers benefit from it, how it impacts the publishers and developers of the apps, and what you can do to mitigate this type of attack.
What is app modding?
In short, app modding is the practice of modifying existing applications, usually from the official app marketplace like Apple App Store or Google Play store. Some modders do this with malicious intent, while others do this to “improve” the app experience (e.g. removing ads.) These improvements are one of the main reasons users download and use these modded apps instead of the original ones.
A widespread problem
Let’s look at an example of a free YouTube mod called YouTube Vanced. It gives you access to premium features such as no-ads playback, background playback, and Picture-in-Picture (PiP) playback, which are usually only available with a US$12 monthly YouTube Premium subscription. The mod also enables you to customize the look and feel of the app for free.
Fig. 1 Popular YouTube Mod
This problem is not exclusive to more popular apps like YouTube, WhatsApp, and Snapchat. Just because you have a small user base, it doesn’t mean modders will not target your apps. As long as your app is in demand, which usually is the goal of every developer, it will be on the modders’ radar. Many lesser-known apps are affected by reverse engineering, tampering, and repackaging problems.
Fig. 2 Lesser Known App Mods
What’s in it for the attackers?
From hobby to money
As surprising as it may sound, many modders do this type of attack just because they can. They find reverse engineering applications fun and rewarding. What starts as a personal project may end up becoming a successful and well-functioning mod. But there is more…
Fig. 3 Popular Pirate Stores Traffic (Source)
With visitor numbers ranging from hundreds of thousands to millions monthly, modded apps can drive huge advertising revenues to pirate stores. Due to the extra features and capabilities they offer, popular modded apps can be sold at a higher price than the original ones. Some modded popular mobile game apps sold for more than US$50 while the game itself is free-to-play.
Malicious intent
As malicious actors build their audience for the modded applications, they will start to gain control over a portion of your user base. This enables them to execute many other activities, such as phishing attacks, spying on users, or using the modded app as a launchpad for malware attacks. In fact, a researcher showed that more than 85% of malware is introduced through repackaged applications. There have been cases of modded instant messaging apps collecting sensitive data and selling it on the Dark Web.
Why should you care?
Impact on your bottom line
These modifications often disrupt your revenue stream by interfering with your monetization strategy. For example, a no-advertisement mod can easily disable all in-app ads or banners in free-to-play, ad-driven apps. On top of being widely popular, modders can very quickly implement and distribute easy-to-install mods that often do not require the user's device to be rooted or jailbroken.
As we can see from the examples above, modders' creativity in modifying the apps to their liking is virtually limitless. There are tens if not hundreds of thousands of modded apps freely available over the internet that allow you to unlock premium features, bypass payment subsystems, modify the look and feel of the apps, and even add different capabilities, to name a few. In other words, you are losing revenue generated from premium features and extra capabilities mods users get for free.
Impact on your reputation
Although app manufacturers are not legally liable for any damage done by users of modded apps, it doesn’t mean there’s no risk to your business. Next to the impact on your revenue, they can also impact your brand reputation.
Imagine a modded mobile game that allows players to get unlimited in-game currencies they can freely spend in the game. But, little do the players know, the mod also secretly harvests their sensitive data (eg. PII, credit card details) to be misused for the modders’ benefit (e.g. to be sold on the dark web). On top of the immediate impact on the game’s monetization, the data harvesting can be discovered, generating unwanted media reports and hitting the integrity of the game and your brand. What may have started as a simple mod of your game can result in a significant business impact.
How does it work?
In the most common scenario, the reverse engineers will download the original application from the official app store. In the case of Android apps, they can easily download the APK from a downloader website. For iOS apps, the process may not be as straightforward, but simple nonetheless. They would first install the app on a mobile device and extract it using a decryption tool like Clutch or Fouldecrypt. Once extracted, threat actors can start the reverse engineering process, make the desired modifications to the app, and then distribute it through pirate app stores. You can learn more about this process on our “The Four Phases of a Mobile Application Attack” blog.
Fig. 4 How Modding and Repackaging Attack Works Diagram
Invisibility problem
What’s interesting about these mods is that it is often almost impossible to detect them in the production environment. This is because these mods use a legitimate app as their basis, and the changes made are often too insignificant to cause behavior differences detectable on the server side. Consequently, it is very difficult for publishers to assess the true scale of the issue and mitigate the problem.
Versioning problem
Even when a new protected version of the app is released, in most cases, it will not solve the problem of the existence of older modded versions. It is difficult, if not impossible, to implement security countermeasures retroactively to unprotected older versions. Once published, you may no longer be able to prevent those versions from being used and misused.
This problem highlights the importance of putting security at the top of your priority list throughout your product development lifecycle. The sooner you incorporate security into your development criteria, the less cybersecurity debt you will have, making it easier to take the necessary actions when a threat is detected.
Automating the modding process
The initial process to complete a mod may take anywhere from a few hours to a few weeks. Once successful, attackers will usually automate the process. Therefore they will not have to go through the entire process for successive versions. In other words, once they managed to mod a release, new releases after that could be modded almost automatically. This is why new mods are often released mere hours after the official version hits the market. Even forcing a version upgrade may not resolve the problem.
What can you do?
Step 1: Evaluate Your Use Case
Before planning for any actions against such attacks, you need to determine whether the risk of modding and repackaging applies to you. Evaluate whether the story above speaks to you and your apps and whether the threat scenario applies to your business. These criteria are by no means the only reasons why you want to protect your app. You need to know your business' threat model to determine the best course of action.
Step 2: Threat Modeling
If the story above speaks to you and your business, the next major step is to develop a threat model specific to your business and app use case. Many threat modeling frameworks can help you do this, such as STRIDE, OWASP, PASTA, or CVSS. Additionally, you can leverage OWASP Mobile Top 10 and MASVS Security Standards to identify the most critical risks in your mobile apps.
Step 3: Implement Application Protection
Once you have familiarized yourself with your app and business threat landscape, you can start planning for possible courses of action. There are many approaches to protecting your mobile app from modding and repackaging attacks. One common way is by incorporating anti-tampering and anti-reverse engineering clauses in your terms and conditions. Although this clause will allow you to take the necessary legal action when needed, this reactive measure alone will not solve the modding and repackaging problems.
Fig. 5 How Guardsquare Prevents Modding Attacks Diagram
The most effective way to counter this problem is by preventing the attackers from being able to execute their attacks on your app in the first place. However, in a pure man-at-the-end attack scenario, no silver bullet can fully safeguard your apps from attacks. Attackers will continually try to find new ways to understand your app's inner workings, and it is impossible to fully predict all scenarios that your app would face once it's publicly available. You can make it as hard as possible for attackers to gain enough insights into your app and compromise it, by implementing many interlocking layers to defend against reverse engineering and tampering, using solutions like DexGuard and iXGuard.
Fig. 6 Multilayer protection
For instance, code obfuscation is a very good deterrent against static code analysis, but it may not be sufficient against dynamic code analysis. An attacker may use a runtime debugger to get insights into the app code while the app is running. Going through application logic step-by-step and setting breakpoints at important places helps attackers to easily understand what the application does - even with the code obfuscated. We can protect the code against this by inserting anti-debugging measures. Beyond debuggers, an attacker may also use hooking to observe the application behavior to help in reverse engineering and modifying the app. To mitigate this, we can apply a hooking detection in the code.
Step 4: Test and Validate Often
To stay ahead of the attackers, it is crucial for you and your team to continually test and validate your app’s security. While regular penetration testing might be the most common way to do this, it is not enough as its frequency is often too far and few in between. Additionally, the result could only show a snapshot of your security posture at that point in time and will quickly become invalid.
AppSweep can help you automatically test your app for security issues and dependencies much more frequently. This free mobile application security testing platform can provide you with actionable insights and recommendations on how to fix and mitigate the issues identified, before each new release of your app. Furthermore, our real-time threat monitoring solution, ThreatCast, can provide you insights into the threats that your DexGuard and iXGuard-protected apps face as they occur, allowing you to take the necessary action and determine whether or not you need to adjust your release frequency and strengthen your code protection.
Step 5: Rotate Your Protection Often
Another layer of security that you can implement to make it exponentially and significantly harder for attackers to understand your app code by resetting the attacker’s clock. You can achieve this by applying your application hardening measures differently for each build. Also known as polymorphism, this technique will force malicious actors to restart their efforts from scratch, as the knowledge they acquired from the previous attacks will no longer be relevant in the new release. DexGuard and iXGuard can do this for you automatically with each new release of your application.
Step 6: Deprecate Old Versions on Time
As we have covered earlier in this blog, once a user installs your app, in most cases, there is no way for you to actively control how they use your app. Similarly, there is no guaranteed way for you to have them update their app to a newer version. As a consequence, at any given time, multiple versions of your app will be in the wild. Some might be more secure than others, but some might also have critical security issues leaving your app at risk. Therefore, you need to deprecate the older versions of your app on time.
Summary
From what we have discussed above, we can conclude that it is impractical, or even impossible, to plan for all possible attack scenarios on your app in advance. It is best for you to develop a comprehensive threat model that takes into account the most critical scenarios for your app. Attackers will always try to find opportunities that allow them to reverse engineer parts of your code and create modded versions of your apps. Your best defense is to harden your code as much as possible, preventing reverse engineers from gaining any insights into the internal logic and behavior of your code.
This blog is a companion blog to our “The Invisible Thief” webinar which you can watch here >
