How does your anti-piracy mechanism deal with people who just copy the APK around but don't actually modify it?
This seems like it would be the most common case anyhow. On Monday, January 14, 2013 12:28:23 PM UTC-6, btschumy wrote: > > We've recently implemented anti-piracy code in the latest version of our > app. It checks the digital signature of the APK against our own (known) > signature to see if the app has been tampered with. This is based on a > suggestion made in this post: > https://groups.google.com/forum/?fromgroups=#!topic/android-developers/fPtdt6zDzns > . > > Here is the call we're using to obtain the APK's digital signature. As > Dianne Hackborn explained in the thread, the "signature" is really the > signing certificate's (i.e. our) public key, and this will not change from > build to build: > > PackageManager pm = context.getPackageManager(); > try > { > PackageInfo info = pm.getPackageInfo( "xxx.xxx.xxx.xxx", > PackageManager.GET_SIGNATURES ); > Signature[] sig = info.signatures; > String sigstring = new String( sig[0].toChars() ); > > // Compare this signature with what we signed it with > } > > On startup, our app now compares the public key returned by this function > to an internal copy of our correct, known public key. If the comparison > fails, the app posts a notification to our server, then quits. The > notification contains a copy of the incorrect public key. > > Our anti-piracy code has been tripped twice. We've gotten the > notification twice. Strangely, the first time was minutes after we > uploaded our new APK to Google Play, before we made the new version public. > In the 10 days since we uploaded this version, our app update has been > downloaded and run thousands of times, with no further notifications. > > Then, on friday Jan 11th, we got another notification that our anti-piracy > check has been triggered. In both cases, the incorrect public key was as > follows: > > > 308204a830820390a003020102020900b3998086d056cffa300d06092a864886f70d0101040500308194310b3009060355040613025553311330110603550408130a43616c69666f726e6961311630140603550407130d4d6f756e7461696e20566965773110300e060355040a1307416e64726f69643110300e060355040b1307416e64726f69643110300e06035504031307416e64726f69643122302006092a864886f70d0109011613616e64726f696440616e64726f69642e636f6d301e170d3038303431353232343035305a170d3335303930313232343035305a308194310b3009060355040613025553311330110603550408130a43616c69666f726e6961311630140603550407130d4d6f756e7461696e20566965773110300e060355040a1307416e64726f69643110300e060355040b1307416e64726f69643110300e06035504031307416e64726f69643122302006092a864886f70d0109011613616e64726f696440616e64726f69642e636f6d30820120300d06092a864886f70d01010105000382010d003082010802820101009c780592ac0d5d381cdeaa65ecc8a6006e36480c6d7207b12011be50863aabe2b55d009adf7146d6f2202280c7cd4d7bdb26243b8a806c26b34b137523a49268224904dc01493e7c0acf1a05c874f69b037b60309d9074d24280e16bad2a8734361951eaf72a482d09b204b1875e12ac98c1aa773d6800b9eafde56d58bed8e8da16f9a360099c37a834a6dfedb7b6b44a049e07a269fccf2c5496f2cf36d64df90a3b8d8f34a3baab4cf53371ab27719b3ba58754ad0c53fc14e1db45d51e234fbbe93c9ba4edf9ce54261350ec535607bf69a2ff4aa07db5f7ea200d09a6c1b49e21402f89ed1190893aab5a9180f152e82f85a45753cf5fc19071c5eec827020103a381fc3081f9301d0603551d0e041604144fe4a0b3dd9cba29f71d7287c4e7c38f2086c2993081c90603551d230481c13081be80144fe4a0b3dd9cba29f71d7287c4e7c38f2086c299a1819aa48197308194310b3009060355040613025553311330110603550408130a43616c69666f726e6961311630140603550407130d4d6f756e7461696e20566965773110300e060355040a1307416e64726f69643110300e060355040b1307416e64726f69643110300e06035504031307416e64726f69643122302006092a864886f70d0109011613616e64726f696440616e64726f69642e636f6d820900b3998086d056cffa300c0603551d13040530030101ff300d06092a864886f70d01010405000382010100572551b8d93a1f73de0f6d469f86dad6701400293c88a0cd7cd778b73d > > I won't post a copy of our own (correct) public key here, but it is very > different from the one above. > > We also collect the Android ID of the device being run on. The ID for the > first trip detection (immediately after uploading the .apk) matches the ID > of the detection we go on Friday. > > Our conclusion is that some internal Google Play process must be be > repackaging our APK, for whatever reason, then running the repackaged > version. Google Play must clearly be distributing our original, unaltered > APK to end users; otherwise we would get this notification constantly (and > all of our users would be complaining that the app quits on startup!) > > But we're mystified as to why we got this notification so soon after > uploading the APK to google play. We can only assume it must be the result > of some internal Google Play process. We can find no other explanation, > especially since the first notification happened immediately after we > uploaded the APK to google play, before we even made it public. > > Can anyone confirm whether such a repackaging is part of google play's > normal process for newly-uploaded APKs? If so, this would greatly help put > our minds at ease. If not, can anyone suggest any other possible > explanation for the notification to have been sent? > > Once again - the only times our public-key-comparison-failed notification > has been sent are 1) immediately after we uploaded the APK to google, and > 2) again on Friday Jan 11th. In both cases the incorrect public key was > the same. Although many thousands of users have downloaded the app update > from Google Play, these are the only two instances in which our anti-piracy > code has notified us that the public-key comparison has failed. > > We'd greatly appreciate any explanation anyone can provide. > > Bill > > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
