LVL found to be easy to crack

180 views
Skip to first unread message

Brad

unread,
Aug 23, 2010, 5:50:07 PM8/23/10
to Android Developers
Well, just as I was finishing adding LVL support to my apps, I come
across this article:

http://www.androidpolice.com/2010/08/23/exclusive-report-googles-android-market-license-verification-easily-circumvented-will-not-stop-pirates/

Of course we all knew that this new copy protection could be broken
(as is the case for all DRM), but I guess I had hoped that it would
take a little more effort. Looks like this will turn out to be a
"one-click" crack.

Will Google up the ante? Is it a lost cause on such an open platform?

Maps.Huge.Info (Maps API Guru)

unread,
Aug 23, 2010, 9:21:16 PM8/23/10
to Android Developers
We all knew this was going to be a problem. It's inherent in the
platform. That said, the steps required to fix an app so it will run
are way more complicated than they used to be with just forward
locking. The script kiddies will be dissuaded from trying to unlock
hundreds or even thousands of apps to the point that it will become
unprofitable for them to do so. It may appear to be a simple scan and
replace as shown in the article but for a complex app with lots of
code, it will be a lot more difficult and subject to errors.

I can see an easy way to thwart an automated patch. Just put about a
dozen fake functions in your app with that code. They don't have to do
anything but sit there. You could even put in a test to see if the app
was patched and cause it to fail or do something evil without a lot of
fuss. That way the pirates would not only have to look but would have
to analyze logic, something that's going to be beyond even the best
pirates.

The thing that makes these pirates able to function is to be able to
simply steal the app, load it on their site and sell it. If each one
requires a manual effort to patch, they will quickly lose interest.
There may be some that will continue to do this but the numbers will
drop precipitately.

-John Coryat

Moto

unread,
Aug 23, 2010, 9:25:08 PM8/23/10
to Android Developers
Well it saved me a load on car insurance! :P It was good while it
lasted! let the race begin!
But being serious this kind of sucks... :( Poor market sells plus
pirating not nice....

On Aug 23, 9:21 pm, "Maps.Huge.Info (Maps API Guru)"

a1

unread,
Aug 24, 2010, 12:48:45 AM8/24/10
to Android Developers
It's really simple, if you use stock implementation of LVL your app
will be cracked in no time, otherwise (if you make the code
complicated enough and then obfuscate) it will take at least week or
two to crack it. If you use native code and put most of the antypiracy
code there you will be good for long time.

--
Regards,
Bart Janusz (Beepstreet)

On 23 Sie, 23:50, Brad <bradfull...@gmail.com> wrote:
> Well, just as I was finishing adding LVL support to my apps, I come
> across this article:
>
> http://www.androidpolice.com/2010/08/23/exclusive-report-googles-andr...

Hugo Visser

unread,
Aug 24, 2010, 2:34:00 AM8/24/10
to Android Developers
Even native code doesn't help you, the call to the native method can
also be decompiled and patched, without bothering with the native code
at all. Like John says, it's an inherit problem of a language that
runs on the vm: you can decompile the byte code. You can just make it
harder to find the point to patch in the decompiled code.
They will always be able to pirate your app, but it's not as easy as
copying the apk and putting it up on a website anymore. So in that
sense it helps.

Hugo

Jonas Larsson

unread,
Aug 23, 2010, 7:31:13 PM8/23/10
to Android Developers
An official response would great.

As I (and many others) see it the main reason for Android app
piracy is paid app unavailability in most countries. When most
users have the option of being honest and pay, most would.
Until Google enables the full Market in all countries the
incitement to crack and distribute apps remains.

When LVL was announced I played with it a bit to see how
easy it was to crack. The fact is; it's much easier than the
article on AndroidPolice shows. No need to analyze switch
statements etc. There is a much better place to modify the
disassembled code that makes it trivial to implement a generic
patcher using available open source tools and shell scripts.
As to where in the (potentially obfuscated code) I refer to
I leave that as an exercise for the crackers. Google surely knew
all this even before LVL was announced...

The official response, or lack thereof, will be interesting.

On Aug 23, 11:50 pm, Brad <bradfull...@gmail.com> wrote:
> Well, just as I was finishing adding LVL support to my apps, I come
> across this article:
>
> http://www.androidpolice.com/2010/08/23/exclusive-report-googles-andr...

Kostya Vasilyev

unread,
Aug 24, 2010, 3:31:37 AM8/24/10
to android-d...@googlegroups.com
The article states:

"Even when mangles in ProGuard the licensing library code is easily
found automatically. Since you compile the licensing library into your
own code you can make some changes to it to make it harder to find when
obfuscated though."

Perhaps it is possible for Google to re-implement LVL with more
attention to security, before it's widely rolled out?

Doing it as part of Market application, with only simple allow/deny
passed over RPC is probably more secure. Market app is signed with the
platform key, and the firmware checks the signature, right?

Various protection policies could be managed by the server, based on
settings in the developer console. I think having two basic ones (strict
and cached, with configurable frequency and number of checks) would
probably cover a vast majority of what's needed.

-- Kostya

24.08.2010 1:50, Brad пишет:


--
Kostya Vasilev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com

Trevor Johns

unread,
Aug 24, 2010, 3:38:16 AM8/24/10
to android-d...@googlegroups.com
So far, in all the cases of cracked apps we've seen, it's been because of the following:

1. The developer did not run a code obfuscating tool (such as ProGuard) on their application; and,
2. The developer implemented the LVL as a drop-in library, without making any modifications to the library code or API.

Let be clear here: the LVL is not a panacea. As shipped, it will protect against casual copying. However, if somebody is determined enough to take a decompiler to your APK, you have to be a bit more diligent about how you integrate it.

There's a reason that we ship the LVL as source code rather than as a JAR file. We encourage you to do things like change the entry/exit points, subtly tweak the logic in LicenseChecker and LicenseValidator, and even move all the entire library into your project's package. Think of the LVL as a framework for a license check mechanism: it's an excellent starting point, and all the tools (or rather, APIs) you need are there, but don't treat it as a black box.

And I *strongly* encourage you to run a code obfuscater, such as ProGuard. If you decompile an application and see symbols like allow(), dontAllow(), LICENSED, NOT_LICENSED, etc., it gives crackers a pretty good hint what they need to modify.

On top of that, pay attention to how you integrate the LVL in your application. For example, if your application displays a dialog on license failure, imagine what would happen if a cracker disabled the call to display your dialog (invoking a method is a single line of bytecode, not difficult to comment out). Will your application still terminate if the "Exit" button in that dialog never gets pressed?

And even with all of this, I need to be clear: This is a client-side license check. It's not bulletproof -- this is the nature of client-side code. However, implemented properly, it will make your application *difficult* to crack.

And as long as it's not possible to create an auto-crack that works on your application (which, if you follow the rules above, shouldn't be possible), then it's still an improvement over the old copy protection model, which only required a rooted phone to bypass.

And if you feel this still isn't enough protection: If your application has an online component to it (for example, a multiplayer game), it's entirely possible to upload the license response to your server and perform a server-side validation there. (Remember: License responses are cryptographically signed. Even if the application has been cracked, the actual license response data cannot be tampered with.) You could then refuse to serve the online component of your application. Since this is all happening on the server-side (read: trusted code), this would be absolutely secure against attack.

And yes, we'll be publishing some articles soon on how to use ProGuard and other techniques for securing your code against attack -- we do mention ProGuard in our documentation, but we should probably be more explicit about how to use it.

-- 
Trevor Johns
Google Developer Programs, Android


--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-d...@googlegroups.com
To unsubscribe from this group, send email to
android-develop...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en



--
Trevor Johns


Trevor Johns

unread,
Aug 24, 2010, 3:52:53 AM8/24/10
to android-d...@googlegroups.com
On Tue, Aug 24, 2010 at 12:31 AM, Kostya Vasilyev <kman...@gmail.com> wrote:
 The article states:

"Even when mangles in ProGuard the licensing library code is easily found automatically. Since you compile the licensing library into your own code you can make some changes to it to make it harder to find when obfuscated though."

Perhaps it is possible for Google to re-implement LVL with more attention to security, before it's widely rolled out?

No. Again, this is client-side code. We could spend an eternity trying to strengthen it, and it would still be vulnerable to these kinds of attacks. Remember: We publish the source code. Anything that Google does is also visible to crackers. (Application developers have an advantage here: You can modify the LVL in unique ways and *not* publish your source code.)

On top of that, once one person figured out how to crack the library, they could write an auto-crack that would work on all applications.

The only way this works effectively is if you have heterogeneity in the license check code between applications. 

(Also: This isn't to say that there won't be future releases of the LVL where we improve the security of the code. I'm just saying that there's no point in completely re-implementing the LVL to magically solve all of these issues. That's impossible. It also implies that we didn't pay attention to security when the LVL was released -- this isn't true.)

Doing it as part of Market application, with only simple allow/deny passed over RPC is probably more secure. Market app is signed with the platform key, and the firmware checks the signature, right?

Unless you have an Android Dev Phone which allows loading custom firmware images.
Or a Nexus One which can have it's firmware unlocked by running 'fastboot oem unlock'.
Or you have a phone that's normally firmware-locked but somebody figured out how to root it anyway.

And once that's done, you could modify Android Market to return an ALLOW response for all applications -- which would be very bad.

And on top of that, you're vulnerable to somebody decompiling the APK and removing the code that performs the RPC check.

And you've removed the ability to perform a server-side license check if you want.

No, this is worse idea in every way.

a1

unread,
Aug 24, 2010, 4:39:31 AM8/24/10
to Android Developers
If you put antipiracy check (eg. CRC checking to detect package
modification) in native code along with some other vital routines, one
will have to patch native implementation, it's of course doable, but
will take more time.

--
Bart Janusz (Beepstreet)

nation-x

unread,
Aug 24, 2010, 9:55:57 AM8/24/10
to Android Developers
I am always amazed at how people always blame everyone else for their
problems... this is something I never see from any Google Developer...
I don't see excuses. What has the world come to when everyone always
has this expectation of entitlement. Noone is forcing you to develop
for Android or any other platform for that matter. If you spend a
little time using your brain you can easily figure out how to deal
with pirates and Trevor outlined a solution that merits investigation
and consideration. I have been selling software for over 10 years...
let me just mention Zend Encoder that costs $1000 and 99% of the
applications that were encoded with it can be decoded to the original
source code in minutes now... THAT is something to be upset about...
Google provides LVL for FREE! How much do you think it cost them to
develop? Don't you think we are all in the same boat really? Stop
blaming Google and take some responsibility for your own product...
overcoming the shortcomings of licensing apps that run on the VM is a
challenge... not an excuse. I see way too much whining when that same
energy can be spent on a solution. The platform is not the issue...
the thieves are the issue. That is where the responsibility lies.
Piracy is never going to go away. You can either accept that fact or
continue to live in a fantasy world where everyone else is to blame.
Try using your brain and not your emotions and you can probably limit
it's impact...

Android Workz

On Aug 24, 3:52 am, Trevor Johns <trevorjo...@google.com> wrote:

Hugo Visser

unread,
Aug 24, 2010, 10:15:34 AM8/24/10
to Android Developers
No, that won't do it, since the entry point is always Java / Dalvik
byte code. Since you can decompile and patch that with relative ease,
you can just make the native calls to the crc check library no-ops or
whatever and you're done without patching any native lib.

Only obfuscation will help to some extend, making it harder to find
what to patch, IMHO of course :)

Hugo

Chris Stratton

unread,
Aug 24, 2010, 10:45:29 AM8/24/10
to Android Developers
I think the suggeston was that the same call to native code accomplish
the antipiracy check and some critical part of application
functionality.

But I'm not sure that native code is any harder to patch, and there
are still identifiable syscalls or calls back up to java for i/o to
show where it tries to accomplish verification.

Kostya Vasilyev

unread,
Aug 24, 2010, 10:49:34 AM8/24/10
to android-d...@googlegroups.com
24.08.2010 17:55, nation-x пишет:

> Try using your brain and not your emotions and you can probably limit
> it's impact...
Gee, thanks.

Wish I had one [ looks at himself in the mirror, does not see any sign
of having a brain ]

:)

a1

unread,
Aug 24, 2010, 11:23:34 AM8/24/10
to Android Developers


On 24 Sie, 16:15, Hugo Visser <botte...@gmail.com> wrote:
> No, that won't do it, since the entry point is always Java / Dalvik
> byte code. Since you can decompile and patch that with relative ease,
> you can just make the native calls to the crc check library no-ops or
> whatever and you're done without patching any native lib.

No, if the native call do something else((and viable) you'll have to
patch native.
Consider following scenario:

JAVA:
void onCreate() {
...
boolean isValid = nativeInit();
}

NATIVE:
jboolean nativeInit() {
// initialize internal structures here, eg. alloc some object etc

return performValidityCheck()
}

sure entry point is in bytecode but removing entire call will cause
crash.

--
Bart Janusz (Beepstreet)

a1

unread,
Aug 24, 2010, 11:26:13 AM8/24/10
to Android Developers
> But I'm not sure that native code is any harder to patch, and there
> are still identifiable syscalls or calls back up to java for i/o to
> show where it tries to accomplish verification.

First of all it's much harder to bypass especially if you are dealing
with optimized code and you will have to do it at least twice (for arm
abi and armv7 abi). Event toolchain setup is more complicated.

--
Bart Janusz (Beepstreet)

Trevor Johns

unread,
Aug 24, 2010, 2:16:14 PM8/24/10
to android-d...@googlegroups.com
FYI: We have a blog post up on this topic. It covers many of the points I made earlier, but I figured it's worth pointing out.


-- 
Trevor Johns
Google Developer Programs, Android

Hugo Visser

unread,
Aug 25, 2010, 2:40:52 AM8/25/10
to Android Developers
OK, I see your point, that could slow them down, but it would slow me
down for sure, maintaining a native and a Java project. Not the
mention the bugs you can get from native code...
But agreed, it's an option.

Hugo

OldSkoolMark

unread,
Aug 25, 2010, 6:09:18 PM8/25/10
to Android Developers
I'm hoping for Eclipse integration of Proguard.
> Google Developer Programs, Androidhttp://developer.android.com
> > android-develop...@googlegroups.com<android-developers%2Bunsu...@googlegroups.com>

Jose

unread,
Oct 22, 2010, 1:50:07 AM10/22/10
to Android Developers
I think that an easy way to tamper-proof apk would be:

1) Android Market computes a checksum for the apk when the apk is
uploaded
2) In the License Response (eg. in one extra), Android Market send
this value
3) The aplication computes the same checsum of itself. If the values
don`t match, just finis()

This could be very easy to do for Android Market developers...

Regards,
Jose

On Aug 24, 8:16 pm, Trevor Johns <trevorjo...@google.com> wrote:
> FYI: We have a blog post up on this topic. It covers many of the points I
> made earlier, but I figured it's worth pointing out.
>
> http://android-developers.blogspot.com/2010/08/licensing-server-news....
>
> --
> Trevor Johns
> Google Developer Programs, Androidhttp://developer.android.com
> <http://android-developers.blogspot.com/2010/08/licensing-server-news....>
>
> On Tue, Aug 24, 2010 at 8:26 AM, a1 <arco...@gmail.com> wrote:
> > > But I'm not sure that native code is any harder to patch, and there
> > > are still identifiable syscalls or calls back up to java for i/o to
> > > show where it tries to accomplish verification.
>
> > First of all it's much harder to bypass especially if you are dealing
> > with optimized code and you will have to do it at least twice (for arm
> > abi and armv7 abi). Event toolchain setup is more complicated.
>
> > --
> > Bart Janusz (Beepstreet)
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" group.
> > To post to this group, send email to android-d...@googlegroups.com
> > To unsubscribe from this group, send email to
> > android-develop...@googlegroups.com<android-developers%2Bunsu...@googlegroups.com>

noriato

unread,
Oct 22, 2010, 3:18:43 AM10/22/10
to Android Developers
So then the check for the checksum could be removed... same problem.
Peter
> > > android-develop...@googlegroups.com<android-developers%2Bunsubs cr...@googlegroups.com>

Jose

unread,
Oct 22, 2010, 4:30:34 AM10/22/10
to Android Developers
But you can check for the checksum in dozens of differents places in
your (ofuscated of course) code. It´s very easy and very fast
This will raising the bar for piracy one step more

Kostya Vasilyev

unread,
Oct 22, 2010, 8:49:16 AM10/22/10
to android-d...@googlegroups.com
The server-side LVL could verify the application signature instead,
since anyone (pirates) changing the code would have to re-sign the
package. The signature is (I think) available to Market application on
the phone, and to the LVL back-end on the server.

Android Market's communication with the server and the application are
encrypted, and Market is signed with the platform key, which means it
can't be tampered with.

Don't know if there any vulnerabilities with this (other than rooted
phones), but then, I don't work for Google and shouldn't discuss
something I know nothing about :)

-- Kostya

22.10.2010 12:30, Jose пишет:


--
Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com

Leigh McRae

unread,
Oct 22, 2010, 10:31:42 AM10/22/10
to android-d...@googlegroups.com
I don't think that you will ever have a solution that will prevent the
pirates from stealing. The question is, does LVL prevent the average
person from being able to steal the app?

For example, on some stores someone can simply forward the email with
the download link to the app they just purchased to one or more
friends. That is really easy for people to do. I added a simple
license check to stop this kind of stealing. I'm sure hardcore pirates
could steal my apps but at least I have prevented the common case that
just about everyone can figure out.

Unfortunately I'm not a big Android expert so I don't know how easy it
is to even copy an app on Android. Does the average person have the
means share/steal an app they purchased off the market if it doesn't use
LVL?

--
Leigh McRae
www.lonedwarfgames.com

Chris Stratton

unread,
Oct 22, 2010, 10:53:11 AM10/22/10
to Android Developers
On Aug 24, 3:31 am, Kostya Vasilyev <kmans...@gmail.com> wrote:

> Doing it as part of Market application, with only simple allow/deny
> passed over RPC is probably more secure. Market app is signed with the
> platform key, and the firmware checks the signature, right?

How many seconds do you think it would take someone to patch out the
RPC call?

The only way something like LVL will hold up in the long run is if the
license checking functionality is intimately and multiply intertwined
with the application functionality, such that disentangling the two is
more trouble than its worth.

Chris Stratton

unread,
Oct 22, 2010, 11:00:29 AM10/22/10
to Android Developers
On Oct 22, 8:49 am, Kostya Vasilyev <kmans...@gmail.com> wrote:
> Android Market's communication with the server and the application are
> encrypted, and Market is signed with the platform key, which means it
> can't be tampered with.
>
> Don't know if there any vulnerabilities with this (other than rooted
> phones), but then, I don't work for Google and shouldn't discuss
> something I know nothing about :)

A patched and pirated application would likely have no interaction
with the Market application whatsoever (any previous interaction being
removed), so Market can't really do anything about it.

Or are you suggesting that future devices should only be able to
install applications sourced from Market? If so, there's a mobile
platform for you, and it isn't Android ;-)

Mark Murphy

unread,
Oct 22, 2010, 11:04:44 AM10/22/10
to android-d...@googlegroups.com
On Fri, Oct 22, 2010 at 10:53 AM, Chris Stratton <cs0...@gmail.com> wrote:
> The only way something like LVL will hold up in the long run is if the
> license checking functionality is intimately and multiply intertwined
> with the application functionality, such that disentangling the two is
> more trouble than its worth.

Now, now, it's not the *only* way.

If an attempt to run a cracked app resulted in electrocution, piracy
would stop in a jiffy.

Of course, there's a *slight* liability issue...

:-)

--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

_The Busy Coder's Guide to Android Development_ Version 3.1 Available!

Kostya Vasilyev

unread,
Oct 22, 2010, 11:21:13 AM10/22/10
to android-d...@googlegroups.com
22.10.2010 19:04, Mark Murphy пишет:

> Now, now, it's not the *only* way.
> If an attempt to run a cracked app resulted in electrocution, piracy
> would stop in a jiffy.
>
> Of course, there's a *slight* liability issue...
>
> :-)

I hear Google has good lawyers, they could lobby for some kind of
Android Licensing Bill, making this legal...

:)

--
Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com


Reply all
Reply to author
Forward
0 new messages