[android-developers] Re: Using APK Signature to detect .apk tampering (Attn: Dianne??)
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.
Re: [android-developers] Re: Using APK Signature to detect .apk tampering (Attn: Dianne??)
By the way: this doesn't belong on android-developers, it belongs on android-security-discuss. You'll probably get more publicity there from people who know things about Android security (into which this conversation has delved). Kris On Tue, Jan 15, 2013 at 1:05 PM, Kristopher Micinski wrote: > Hopefully you understand how to write such a tool: it seems that most > people who try to write these tools do not, and security by obscurity > sounds good until you get someone who pulls out a decompiler on your > app. > > To be clear: the way to circumvent this will entail some degree of > static analysis, so for your tool to succeed you will have to "trick > up" any kind of static analysis that an attacker is using (this > generally requires a good degree of static analysis). > > I don't see how key signature code has anything to do with this "magic > mechanism" to cause static analysis to fail. Generally the way to > circumvent this idea is to: > > - Look at common ways a static analysis tool would defeat your > technique (in this case, it would look at problematic paths that do > the verification and then try to separate them out of the program, > perhaps using program slicing or some other means). > - Try to trip up (make the static analysis hard) the tool that would > do the stripping. > - Hope that it all goes well. > > And remember, even though this is "static analysis" it would > presumably be done by a human with a tool for bytecode inspection: > these are not too hard to cook up. The way to do this is basically to > make your code really confusing and hard to follow, but any "compiler > like" obfuscation mechanism (in the nature of proguard, for example) > doesn't really work because good crackers know the patterns. > > In the end, your mechanism probably *can* be broken, but breaking it > probably isn't worth the effort if you put enough in. But still, > that's far from being able to say that the app is "uncrackable." > > Kris > > On Tue, Jan 15, 2013 at 12:54 PM, btschumy wrote: >> >> >> On Tuesday, January 15, 2013 2:56:20 AM UTC-7, b0b wrote: >>> >>> Note that this is not super useful to do that, as all automated cracking >>> tools will detect your call with PackageManager.GET_SIGNATURES, and patch it >>> out. >> >> >> We think we have a mechanism that makes this fairly difficult. It is >> unlikely any automated tool will succeed. However, time will tell. >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Android Developers" group. >> To post to this group, send email to android-developers@googlegroups.com >> To unsubscribe from this group, send email to >> android-developers+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Using APK Signature to detect .apk tampering (Attn: Dianne??)
Hopefully you understand how to write such a tool: it seems that most people who try to write these tools do not, and security by obscurity sounds good until you get someone who pulls out a decompiler on your app. To be clear: the way to circumvent this will entail some degree of static analysis, so for your tool to succeed you will have to "trick up" any kind of static analysis that an attacker is using (this generally requires a good degree of static analysis). I don't see how key signature code has anything to do with this "magic mechanism" to cause static analysis to fail. Generally the way to circumvent this idea is to: - Look at common ways a static analysis tool would defeat your technique (in this case, it would look at problematic paths that do the verification and then try to separate them out of the program, perhaps using program slicing or some other means). - Try to trip up (make the static analysis hard) the tool that would do the stripping. - Hope that it all goes well. And remember, even though this is "static analysis" it would presumably be done by a human with a tool for bytecode inspection: these are not too hard to cook up. The way to do this is basically to make your code really confusing and hard to follow, but any "compiler like" obfuscation mechanism (in the nature of proguard, for example) doesn't really work because good crackers know the patterns. In the end, your mechanism probably *can* be broken, but breaking it probably isn't worth the effort if you put enough in. But still, that's far from being able to say that the app is "uncrackable." Kris On Tue, Jan 15, 2013 at 12:54 PM, btschumy wrote: > > > On Tuesday, January 15, 2013 2:56:20 AM UTC-7, b0b wrote: >> >> Note that this is not super useful to do that, as all automated cracking >> tools will detect your call with PackageManager.GET_SIGNATURES, and patch it >> out. > > > We think we have a mechanism that makes this fairly difficult. It is > unlikely any automated tool will succeed. However, time will tell. > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Using APK Signature to detect .apk tampering (Attn: Dianne??)
On Tuesday, January 15, 2013 2:56:20 AM UTC-7, b0b wrote: > > Note that this is not super useful to do that, as all automated cracking > tools will detect your call with PackageManager.GET_SIGNATURES, and patch > it out. > We think we have a mechanism that makes this fairly difficult. It is unlikely any automated tool will succeed. However, time will tell. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Using APK Signature to detect .apk tampering (Attn: Dianne??)
>
>
> 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
> }
>
> Note that this is not super useful to do that, as all automated cracking
tools will detect your call with PackageManager.GET_SIGNATURES, and patch
it out.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
