15

In my folder assets/data, there are a lot of XML files containing static data for my app.

It's really easy for someone to retrieve an APK, modify a part of it and install on a device.

I would like to prevent users to alter my static data by checking the integrity of my assets/data folder.

Initially I was considering to use MD5 checksum, but it will probably be too slow for the amount of files I gonna have (50-100).

Do you have any suggestion?

Edit:

This app is a game with an XML file describing each level.

Community
  • 1
  • 1
Hartok
  • 2,147
  • 20
  • 37

4 Answers4

6

I'll describe how you can effectively protect against modification and repackaging, not how you can protect the assets on their own, although you could ultimately apply the same technique to encrypting them. It's imperfect, but you can make modification significantly more difficult.

You sign the application with a certificate. Although they can remove yours, noone else can produce the same certificate when putting it back together. You can therefore check the signature of the application at runtime, to make sure it's what you expect.

Here's some cheap and nasty code to do this:

   PackageManager pm = context.getPackageManager();

   PackageInfo info = pm.getPackageInfo( context.getPackageName(), PackageManager.GET_SIGNATURES );

   if ( info.signatures[ 0 ].toCharsString().equals( YOUR_SIGNATURE ) )
   {
     //signature is OK
   }

where YOUR_SIGNATURE is a constant, obtained from running this code on the signed app.

Now, there are two remaining problems that you have already hinted at:

  1. how can you stop someone just modifying the constant in the source code to match their certificate, then repackaging and re-signing the app?

  2. how can you stop someone finding the check method and removing it?

Answer to both: you can't, not absolutely, but you can do a pretty good job through obfuscation. The free Proguard, but more usefully the commercial Dexguard, are tools for doing this. You may baulk at the current €350 cost of the latter; on the other hand, I have tried to reverse engineer apps that are protected like this, and unless the stakes were very high, it isn't worth the trouble.

To an extent, you could also do the obfuscation for (1) yourself; have the signature 'constant' assembled at runtime through some complicated programmatic method that makes it difficult to find and replace.

(2) is really a software design issue; making it sufficiently complicated or annoying to remove the check. Obfuscation just makes it more difficult to find in the first place.

As a further note, you might want to look at whether stuff like Google Licensing gives you any protection in this area. I don't have any experience of it though, so you're on your own there.

Rob Pridham
  • 4,780
  • 1
  • 26
  • 38
  • 1
    Whatever you do, NEVER put your signing key in your code! This would allow someone with a will to unpack your apk, and repackage it with your same signing key. – Phil Feb 06 '13 at 14:56
  • Please re-read the code. It's NOT the signing key, it's the signature of it. If it were possible to obtain the signing key from the certificate, we would all have bigger problems. I have edited the answer's wording for clarity. – Rob Pridham Feb 06 '13 at 14:58
  • Gotcha. I un-downvoted. Could allowing a hacker to view the signature (in the event they went through all the obfuscated code) be beneficial to resign, or republish the app? – Phil Feb 06 '13 at 15:04
  • No, because the certificate security comes from the private key used to produce it, which is never exposed. You could run the above code against any app and obtain a useless signature. The only obvious vulnerability here is that you might manage to produce a collision attack, i.e. produce a different cert with the same signature. I'd hope the chances of that are sufficiently slim! – Rob Pridham Feb 06 '13 at 15:09
  • +1 You have certainly though this through, and know your stuff! – Phil Feb 06 '13 at 15:19
  • My app will probably be free. Google Licensing is not appropriate in this case. – Hartok Feb 07 '13 at 17:11
2

Sort of an answer although it is in the negative.

If the person has your apk and has decoded it, then even if you used a checksum, they can just update the code portion with the new checksum. I don't think you can win this one. You can put a great deal of effort into protecting it but if you assume somebody can obtain and modify the apk, then they can also undo the protection. On my commercial stuff, I just try to make the decoding non-obvious but not bullet proof. I know anything more is not worth the effort or even possible.

DrC
  • 7,528
  • 1
  • 22
  • 37
  • I know that there's no complete solution. However, it's possible to modify an XML file in assets directly in the APK file. This is what I want to prevent. Modify the code is really more complicated for the moment. – Hartok Jan 29 '13 at 04:36
  • 3
    I just wanted to keep somebody from spending too much time on the topic. – DrC Jan 29 '13 at 04:40
  • Yes, I abandoned this idea twice before asking the community. I just want to be sure not to miss a brilliant solution. – Hartok Jan 29 '13 at 04:55
1

Perhaps you could zip up the xml files and put it in the assets/data folder; and then do a checksum on that .zip. On the first run, you could unzip the files to get the .xml layouts. See Unzip file from zip archive of multiple files using ZipFile class for unzipping an archive.

Community
  • 1
  • 1
Vino
  • 1,544
  • 1
  • 18
  • 26
0

Probably the most reliable way would be for the level XML data to be downloaded from a server when the app is started with a check of the time stamp and sizes of the level files. That also lets you provide updates to level data over time. Of course this means you have the added expense of a server to host which may be another problem.

Douglas Jones
  • 2,522
  • 1
  • 23
  • 27