5 Things John Learned Fighting Hackers of His App — A must-read for PM’s and CISO’s
Last updated
Last updated
John is the creator of a popular app BetterVision, for the blind and visually impaired. There is a good reason for the over 100K installations John’s creation has achieved. BetterVision can turn a phone’s camera into a powerful assistant easing a daily routine for disabled users worldwide. With success, however, soon came difficulties. John’s app suffered a cloning attack, and his In-App purchases got stolen.
At Talsec, we specialize in in-app security. We build RASP (Runtime Application Self-Protection) tools to protect apps against hacking — which, unfortunately, is growing in popularity. In this article, we interviewed Business Owner and senior Android developer John Smith whose app BetterVision got hacked. The interviewee has requested anonymity. We deliberately changed his name to “John Smith” and his brand name to “BetterVision”.
Do not release without protections in-place
Perform sensitive operations server-side whenever possible
Prevent reverse-engineering
Monitor user groups and APK mirroring sites to detect malicious clones
Warn users against using fake clones
My five tips are:
Using time-saving drop-in solutions like Talsec and not messing up security basics pays off. Otherwise, you have to accept losing some percentage of purchases due to hacked clones and take it into account — also financially. I remember an Android security survey that suggested that most apps lack even the most basic obfuscation.
It can sound silly, but the thing is that when you have to choose between delivering functionality and improving security, you should select the first and reckon with the risk. I have heard of companies focused on security so much that they could not develop the functionality needed for business.
My Firebase catches something already, but I would appreciate Talsec’s monitoring as it is more advanced. It would be great to see the collected statistics.
I had the warning screen displayed in hacked clones that exited the application only to realize users of clones began complaining and giving bad reviews. So, I later reverted it as it wasn’t worth it. However, I believe it’s good to have hidden logging, which can’t be disabled by a hacker easily. That’s what I finally ended up with. The hacked clones still report to my monitoring service as hackers apparently don’t care about that.
Yes, it would be necessary to add a lot of arbitrary fake reflection calls so that the important ones will be hidden between them. These could also serve as a kind of honey-pot. I would appreciate a plugin that would perform this transformation automatically.
Obfuscation is of great importance in hiding inner business logic. You can combine obfuscation with the reflection API to hide system calls. Hackers often head for them as these are usually placed close to sensitive operations. With reflection, you turn these calls into strings that are consequently obfuscated. Hackers will not be able to locate them using static analysis. Unfortunately, hackers are aware of this technique, and if you use it only on a few occasions, they can easily guess its meaning.
It’s a cat-and-mouse game. Hackers always find your protections, so you are forced to evolve your knowledge and update your app. For example, I spread those checks into many places in the app, so they are more likely to forget something untouched.
As I said, the first choice for me was the PiracyChecker as Talsec was not a thing back then. I have learned a lot from experienced Android developers on advanced forums. Things like decentralizing security checks, hiding secrets in a native code, rooting and tampering protection.
The common issue of established RASP libraries is that bypass for the majority of them is already publicly available. I feel the Talsec has a slight edge in this manner, at least for now.
I didn’t have the necessary knowledge at that time. I have added the popular PiracyChecker library (note: Talsec didn’t exist at that time), but hackers still could circumvent it. As I have learned more about protecting Android apps, I have added many protections myself later. Alas, the iOS version of my app still needs to enhance the protection, which falls behind the Android one.
RASP made by Talsec does come as a complete toolbox of security enhancements. Reverse engineering protection can protect your app with many invisible traps that give hackers a hard time. Malware detection, tapjacking prevention, E2E Encryption, mutual TLS setup, online client integrity checks (Attestation), On-line Risk Scoring, API protection, Strong Customer Authentication, embeddable security dashboard, and much more are covered in our enterprise security. Contact us for a private meeting!
It’s common to use native code for hiding valuable parts of an application as its decompilation of binary is a much more demanding task. I hide logging and security checks in various places. There’s a high probability a hacker will miss some parts, and you will be able to track malicious activities. A hacker only aims for the functional clone and doesn’t care about making it top-notch in the end.
Not necessarily; you can change a Proguard’s dictionary. The unfortunate side effect is that Google Play’s review process becomes more time-consuming. The regular one-day review process takes up to 10 days if you change the dictionary, as Google Play scanning is more thorough in such cases. If I need to push hotfixes quickly, I stick with the same dictionary as my previous build.
Finally, strip out any debugging lines. Popular library Timber has one crucial weakness regarding that. Although your Timber tree won’t log in the production build, your debugging code is still in place. A hacker can just turn debugging on for the app, and the logging will be visible again. Creating your logging scheme is also beneficial. Debug and verbose logs are dropped in production, informational logs are written into the local log, and finally, warnings and more severe events are logged to Firebase.
I highly recommend the string obfuscator Paranoid. It only takes a single annotation @Obfuscate above the class, and you are good to go.
I remember having issues with code obfuscation. In some cases, older versions of Proguard (code obfuscator) obfuscated method parameters but created annotations with original names above them. I haven’t noticed such issues with R8, which ships with Android Studio nowadays.
“A hacker only aims for the functional clone and doesn’t care about making it top-notch in the end.”
For example, there was a guy from India who even added his own payment system and he charged half the price of the original. He even went to great lengths in protection and used a DexGuard to protect it. We got a hold of his WhatsApp and phone number. We unsuccessfully tried to sue him, but he was out of our legal reach.
Although they don’t usually want to talk to us, there was a white-hat guy who appreciated our work and gave us a few hints as to what we might do better. Apart from that, they only care about adding their own ads and other nasty things.
Hackers are still active and create new clones. They can often release a clone just a few days after our updates. Unfortunately, we don’t have any way to disable those cracked versions.
There were also videos on YouTube that contained links to clones. Reporting to Google (Content ID claim) worked well. Google took down the incriminated video within a day. Reporting links to Google Drive with hacked versions was also successful.
Yes. The community was very supportive. Community members send us links to hacked versions. Fans are also sending in recordings of communications with the attackers. We’re tracking it, and we have a whole database full of it.
A common tool used for hacking is the app called Lucky Patcher. So I added a detection which caused the app to stop if the user had it installed. It turned out that many people have Lucky Patcher installed, and after an avalanche of complaints by angry users, I reverted this detection.
The first versions contained only basic functionality. In retrospect, I have to say that launching the app without protection was a big mistake. It was only in response to the hacking that the first protection was added, which was a signature check. This stopped cloners and amateurs from using automated repackaging tools for a while. A little later, I also added the string obfuscation.
If you find out that you have four times more users on Google Play than on the AppStore and your profits are four times less, something is fishy. Sideloading of cracked apps, simplicity of rooting, and APK modifications are significant drawbacks of the Android platform. iOS protects both users and developers better against such malicious activities. A profitability perspective is much better as users are better used to paying for apps.
Although we haven’t done the math, the financial losses are significant. Because hackers may have disabled the in-app tracking, the actual number of installed cracked clones cannot be determined. Although Android has four times as many users as iOS, profits are four times smaller because of cracked versions being still available.
It was a terrible feeling considering I used to develop it in my spare time for almost no profit initially. The application fee was only enough to cover the costs. Later, we invested a fair amount of money for performant Amazon servers used for machine learning.
I think that some users were resourceful and hacked the app themselves by removing Google Play Billing Library in-app purchases. As long as they were doing it for their own use, I didn’t even mind.
Users themselves reported finding illegal copies, which started popping up on Telegram and WhatsApp groups. Anyone could grab those APKs and install them. Paid users were upset.
“Although Android has four times as many users as iOS, profits are four times smaller because of cracked versions being still available.”
We immediately had positive feedback from users after the release. We were amazed that users even switched from a competing app to us. We made it into newspapers and TV in the homeland thanks to great help from local organizations. We recruited ambassadors from the ranks of users in foreign regions.
Getting early-stage traction was surprisingly easy thanks to the strong disabled communities in which our app quickly gained attention. Users recommended the app to each other, especially coaches for disabled people, who took the initiative and spread the word among clients.
Oftentimes, in reality, it is not possible to host valuable assets from the cloud safely, and you must put them into the app.
Finally, ease of use and accessibility required offline operation because users don’t always and everywhere have a good network connection. One of the cornerstones and our know-how are computer vision models using machine learning. These have to be a static part of the application since users might have issues if they were hosted on the cloud. It is one of the misconceptions many developers have. They believe they can secure everything by putting it server-side. Oftentimes, in reality, it is not possible to host valuable assets from the cloud safely, and you must put them into the app.
The idea wasn’t novel as there already were similar solutions by renowned companies. We kicked off with only basic features at the beginning focusing on accessibility. Not only we thoroughly tested eyes-free usage in the app but also accompanying web and brochures. I regularly tested it myself, covering my eyes with my hand.
The idea came from a disabled friend. Together we realized this is a widespread issue which many disabled people face. Similar solutions already existed but were insufficient (school projects) or with poor accessibility optimizations.
The idea came from a disabled friend. Together we realized this is a widespread issue which many disabled people face. Similar solutions already existed but were insufficient (school projects) or with poor accessibility optimizations.
The idea wasn’t novel as there already were similar solutions by renowned companies. We kicked off with only basic features at the beginning focusing on accessibility. Not only we thoroughly tested eyes-free usage in the app but also accompanying web and brochures. I regularly tested it myself, covering my eyes with my hand.
Finally, ease of use and accessibility required offline operation because users don’t always and everywhere have a good network connection. One of the cornerstones and our know-how are computer vision models using machine learning. These have to be a static part of the application since users might have issues if they were hosted on the cloud. It is one of the misconceptions many developers have. They believe they can secure everything by putting it server-side. Oftentimes, in reality, it is not possible to host valuable assets from the cloud safely, and you must put them into the app.
Oftentimes, in reality, it is not possible to host valuable assets from the cloud safely, and you must put them into the app.
Getting early-stage traction was surprisingly easy thanks to the strong disabled communities in which our app quickly gained attention. Users recommended the app to each other, especially coaches for disabled people, who took the initiative and spread the word among clients.
We immediately had positive feedback from users after the release. We were amazed that users even switched from a competing app to us. We made it into newspapers and TV in the homeland thanks to great help from local organizations. We recruited ambassadors from the ranks of users in foreign regions.
“Although Android has four times as many users as iOS, profits are four times smaller because of cracked versions being still available.”
Users themselves reported finding illegal copies, which started popping up on Telegram and WhatsApp groups. Anyone could grab those APKs and install them. Paid users were upset.
I think that some users were resourceful and hacked the app themselves by removing Google Play Billing Library in-app purchases. As long as they were doing it for their own use, I didn’t even mind.
It was a terrible feeling considering I used to develop it in my spare time for almost no profit initially. The application fee was only enough to cover the costs. Later, we invested a fair amount of money for performant Amazon servers used for machine learning.
Although we haven’t done the math, the financial losses are significant. Because hackers may have disabled the in-app tracking, the actual number of installed cracked clones cannot be determined. Although Android has four times as many users as iOS, profits are four times smaller because of cracked versions being still available.
If you find out that you have four times more users on Google Play than on the AppStore and your profits are four times less, something is fishy. Sideloading of cracked apps, simplicity of rooting, and APK modifications are significant drawbacks of the Android platform. iOS protects both users and developers better against such malicious activities. A profitability perspective is much better as users are better used to paying for apps.
The first versions contained only basic functionality. In retrospect, I have to say that launching the app without protection was a big mistake. It was only in response to the hacking that the first protection was added, which was a signature check. This stopped cloners and amateurs from using automated repackaging tools for a while. A little later, I also added the string obfuscation.
A common tool used for hacking is the app called Lucky Patcher. So I added a detection which caused the app to stop if the user had it installed. It turned out that many people have Lucky Patcher installed, and after an avalanche of complaints by angry users, I reverted this detection.
Yes. The community was very supportive. Community members send us links to hacked versions. Fans are also sending in recordings of communications with the attackers. We’re tracking it, and we have a whole database full of it.
There were also videos on YouTube that contained links to clones. Reporting to Google (Content ID claim) worked well. Google took down the incriminated video within a day. Reporting links to Google Drive with hacked versions was also successful.
Hackers are still active and create new clones. They can often release a clone just a few days after our updates. Unfortunately, we don’t have any way to disable those cracked versions.
Although they don’t usually want to talk to us, there was a white-hat guy who appreciated our work and gave us a few hints as to what we might do better. Apart from that, they only care about adding their own ads and other nasty things.
For example, there was a guy from India who even added his own payment system and he charged half the price of the original. He even went to great lengths in protection and used a DexGuard to protect it. We got a hold of his WhatsApp and phone number. We unsuccessfully tried to sue him, but he was out of our legal reach.
“A hacker only aims for the functional clone and doesn’t care about making it top-notch in the end.”
I remember having issues with code obfuscation. In some cases, older versions of Proguard (code obfuscator) obfuscated method parameters but created annotations with original names above them. I haven’t noticed such issues with R8, which ships with Android Studio nowadays.
I highly recommend the string obfuscator Paranoid. It only takes a single annotation @Obfuscate above the class, and you are good to go.
Finally, strip out any debugging lines. Popular library Timber has one crucial weakness regarding that. Although your Timber tree won’t log in the production build, your debugging code is still in place. A hacker can just turn debugging on for the app, and the logging will be visible again. Creating your logging scheme is also beneficial. Debug and verbose logs are dropped in production, informational logs are written into the local log, and finally, warnings and more severe events are logged to Firebase.
Not necessarily; you can change a Proguard’s dictionary. The unfortunate side effect is that Google Play’s review process becomes more time-consuming. The regular one-day review process takes up to 10 days if you change the dictionary, as Google Play scanning is more thorough in such cases. If I need to push hotfixes quickly, I stick with the same dictionary as my previous build.
It’s common to use native code for hiding valuable parts of an application as its decompilation of binary is a much more demanding task. I hide logging and security checks in various places. There’s a high probability a hacker will miss some parts, and you will be able to track malicious activities. A hacker only aims for the functional clone and doesn’t care about making it top-notch in the end.
RASP made by Talsec does come as a complete toolbox of security enhancements. Reverse engineering protection can protect your app with many invisible traps that give hackers a hard time. Malware detection, tapjacking prevention, E2E Encryption, mutual TLS setup, online client integrity checks (Attestation), On-line Risk Scoring, API protection, Strong Customer Authentication, embeddable security dashboard, and much more are covered in our enterprise security. Contact us for a private meeting!
Did you consider products like Talsec RASP or freeRASP?
I didn’t have the necessary knowledge at that time. I have added the popular PiracyChecker library (note: Talsec didn’t exist at that time), but hackers still could circumvent it. As I have learned more about protecting Android apps, I have added many protections myself later. Alas, the iOS version of my app still needs to enhance the protection, which falls behind the Android one.
The common issue of established RASP libraries is that bypass for the majority of them is already publicly available. I feel the Talsec has a slight edge in this manner, at least for now.
As I said, the first choice for me was the PiracyChecker as Talsec was not a thing back then. I have learned a lot from experienced Android developers on advanced forums. Things like decentralizing security checks, hiding secrets in a native code, rooting and tampering protection.
It’s a cat-and-mouse game. Hackers always find your protections, so you are forced to evolve your knowledge and update your app. For example, I spread those checks into many places in the app, so they are more likely to forget something untouched.
Obfuscation is of great importance in hiding inner business logic. You can combine obfuscation with the reflection API to hide system calls. Hackers often head for them as these are usually placed close to sensitive operations. With reflection, you turn these calls into strings that are consequently obfuscated. Hackers will not be able to locate them using static analysis. Unfortunately, hackers are aware of this technique, and if you use it only on a few occasions, they can easily guess its meaning. Agreed. The reflection is easily spotted in the code. Do you have any solution in mind?
Yes, it would be necessary to add a lot of arbitrary fake reflection calls so that the important ones will be hidden between them. These could also serve as a kind of honey-pot. I would appreciate a plugin that would perform this transformation automatically.
I had the warning screen displayed in hacked clones that exited the application only to realize users of clones began complaining and giving bad reviews. So, I later reverted it as it wasn’t worth it. However, I believe it’s good to have hidden logging, which can’t be disabled by a hacker easily. That’s what I finally ended up with. The hacked clones still report to my monitoring service as hackers apparently don’t care about that.
My Firebase catches something already, but I would appreciate Talsec’s monitoring as it is more advanced. It would be great to see the collected statistics.
It can sound silly, but the thing is that when you have to choose between delivering functionality and improving security, you should select the first and reckon with the risk. I have heard of companies focused on security so much that they could not develop the functionality needed for business.
Using time-saving drop-in solutions like Talsec and not messing up security basics pays off. Otherwise, you have to accept losing some percentage of purchases due to hacked clones and take it into account — also financially. I remember an Android security survey that suggested that most apps lack even the most basic obfuscation.
My five tips are:
Do not release without protections in-place
Perform sensitive operations server-side whenever possible
Prevent reverse-engineering
Monitor user groups and APK mirroring sites to detect malicious clones
Warn users against using fake clones
written by Tomáš Soukal, Mobile Dev and Security Consultant at Talsec
