0

I'm working on an Android application with few millions of users. The app has some financial|payment features. We have some public APIs and some authenticated ones (OAuth2). As a part of enhancing our security, we are currently using "Certificate Pinning".

The problem is, our app gets repackaged by some people to disable its advertisements, and unfortunately, some (unignorable number of) users install them.

We decided to reject the requests coming from these repackaged apps (not solely because of ads problem). I searched and came onto "Mobile Attestation" and SafetyNet feature in Android, but this one needs Google Play Services which rules it out.

I'm wondering whether sending the SHA256 of APK signature (using PackageManager methods) as an HTTP header and rejecting the requests with unmatched HASHs is enough for this situation? Has anyone had similar experiences? What pitfalls and gotchas could exist? We are currently only on Android but Web/iOS clients are on the plan. Could this solution be extended to them?

Improve this question
13
  • 1
    "I'm wondering whether sending the SHA256 of APK signature (using PackageManager methods) as an HTTP header and rejecting the requests with unmatched HASHs is enough for this situation? " -- all they need to do is obtain the value from an unmodified version of the app, then use that in their own requests.
    – CommonsWare
    Feb 19, 2021 at 17:25
  • 1
    A tampered app will lie about its hash. You need to have it audited from a perspective of third party system app which is Google Play Services in all GMS certified android devices. I don't think there's any other way. OEMs don't develop their own system app that offers attestation API like SafetyNet. If your app is on Play Store, why are you ruling out SafetyNet?
    – defalt
    Feb 19, 2021 at 17:36
  • 1
    what if they simply blocked requests to your ad networks on the network level? Then even if you had a perfect advertisement enforcing app, the ads still wouldnt be served. Are these modified versions actually having a significant impact on ad revenue? If theres minimal impact to your revenue, it seems pointless. We need more companies that care less about flooding the internet with advertisements, and more companies that care about security and privacy of their users information.
    – john doe
    Feb 19, 2021 at 20:17
  • 2
    Huawei Mobile Services app also has attestation API. You can use that. Only system app should attest the device otherwise it could be tampered.
    – defalt
    Feb 19, 2021 at 20:35
  • 1
    have you considered adding an option in your settings to disable ads, and if the user chooses to, reminding them that at least some of your income is dependent on ad revenue? you might then offer those users the option to make a one time or recurring payment ... ??
    – brynk
    Feb 20, 2021 at 1:59

2 Answers 2

Reset to default
2

TL;DR: You cannot win.

What you want is called DRM, and that proved time and time again to be ineffective against dedicated users (or abusers). It increases the development cost, adds complexity, and don't solve the problem in the long run.

If you cannot rely on SafetyNet, there's no way. As defalt pointed on his comment, a tainted application will lie about its hash, because it's very easy to inspect the unmodified version and grab the hash there. You can obfuscate code to make analysis harder, but it's not possible to protect code running on the client when the client have incentives to break the protection.

Improve this answer
2
  • You're absolutely right and I know there's no silver bullet in security. Our intention is not securing the app against dedicated hackers, these low effort repackages are created by some forums to grab some clicks/views. I think they don't go further than searching for some afterwork URLs, changing them and repacking the app. To break what I described, they need to find and change the networking code in a obfuscated code.
    – Alireza Farahani
    Feb 19, 2021 at 20:02
  • Or use SafeNet...
    – ThoriumBR
    Feb 19, 2021 at 20:23
1

I propose a strategy whereby you systematically reduce the reasons for your users to turn to re-packagers, thereby reducing your requirement to field service requests from unofficial versions of your client software:

  1. produce your own apk's for non-Play users, and publish these along with signature(s) generated by a tightly controlled private key
  2. offer an 'ads-free' version for some nominal fee, so that users with hearts of gold can 'throw you a bone'
  3. offer a no cost 'ads-free' version that you build from the ground up to use a different service endpoint, that you can tune the service responsiveness to (ie. lower priority) in times of high demand
  4. for all of the above, provide a mechanism to communicate updated versions and critical flaws (ensure this channel is also verified with signature/s)

OPINIONATED RANT Yes, I realise Play store et.al. does all of this - so does F-Droid without 'strings attached', which has led to a beautiful ecosystem and a wealth of alternatives springing up around FOSS/ Libre/ minimal intrusion spysoftware. Many developers also field requests for the apk being made available directly from their website (though often they forget about signatures) - combined this is usually good enough from my (minority) perspective, given that my 'daily driver' runs a trimmed LineageOS and no Play store. I find myself quite disappointed when developers insist on distribution only through the established channels of the big players. Many others must be of the same mind because these repackagers actually exist and, despite significant risks Huang et.al. 2013, they are still quite popular.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .