more android license validation

in a previous post i mentioned a method of cracking the android market license validation library (lvl). there are apparently multiple ways of deploying the android license verification library. most of the time i see com/android/LicenseChecker.smali, com/android/LicenseValidator.smali, etc. recently i found an app that only used ILicensingService and ILicenseResultListener and my normal method of cracking could not be applied.

after about 30 minutes of illuminating reading over binders and parcels work on the android developer site, i came up with this solution: inside ILicenseResultListener$Stub.smali, in the method onTransact(ILandroid/os/Parcel;Landroid/os/Parcel;I)Z simply return true at the top, like this:

.method public onTransact(ILandroid/os/Parcel;Landroid/os/Parcel;I)Z
    .locals 6
    .parameter "code"
    .parameter "data"
    .parameter "reply"
    .parameter "flags"
    .annotation system Ldalvik/annotation/Throws;
        value = {
            Landroid/os/RemoteException;
        }
    .end annotation

    .prologue
    const/4 v4, 0x1

    # lnote: never do binder.ontransact
    # just always return true :)
    return v4

if you want to try to improve on this solution, it help to look at the actual java source here:
http://code.google.com/p/marketlicensing/source/browse/library/src/com/android/vending/licensing/

string obfuscation

a common practice in pc apps is string encryption. when a program is compiled all literal strings are replaced with function calls with a parameter that retrieve that specific string. the result is when the program is decompiled it is not possible to simply search for strings. string searching makes finding interesting locations in code much easier so preventing this makes cracking more difficult for more people. recently, i came across some string obfuscation. this is the first time i have seen it "in the wild". proguard does not do it because it necessarily requires more work from the processor and may slow things down slightly.

how can we defeat it? it is difficult to analyze dalvik code and perform the encryption process in reverse without damaging other code (at least for me), but it is very simple to merely call the function for every possible string. here is an example: StringDumper.smali

StringDumper will output decrypted strings to the log file. the encrypted strings in my case were held inside StringHolder.smali and were retrieved using getString(I)Ljava/lang/String. there were only 0x15 strings, but if you run into this specific type of encryption there may be more or less.

it is not likely you will see this exact, specific encrypter implementation since i suspect it was developed in-house and is not open source. at least you will have a general idea of how to defeat such protection.

crackme submissions

there are several websites that host crackmes but none of them have android sections. i'll continue to look but if anyone knows of a site that is open to them, let me know.

i want to see how people are doing the crackmes in the tutorials so if you send me a cracked version and a little explanation of how you did it i can add some points to your name.

way of the android cracker 1

lesson 1 is finished. it covers debugging methods such as log statements and smalidebugging with apktool and netbeans. it also features crackme1 which is still somewhat easy but more difficult and realistic. download here:
https://sites.google.com/site/lohanplus/files/WayoftheAndroidCracker1.zip?attredirects=0&d=1

lesson 0 has been renovated to include screen shots, a few fixes and an updated crackme0.
https://sites.google.com/site/lohanplus/files/WayoftheAndroidCracker0.zip?attredirects=0&d=1

hope you learn something. good luck.

progress on second lesson

i am about half-way finished with the second lesson. while doing it i had many ideas for improving the first lesson. i have gone back and updated, tweaked and fixed the first lesson and will upload it when i am finished with the second.

the next crackme is only slightly more complex but it will include signature verification, a common anti-cracking technique. it is still quite easy but illuminating. actually it is about as easy as many actual android apps. the next lesson will include an obfuscated crackme, an additional anti-cracking technique and perhaps killer robots that stalk you in your sleep, but i may only have time two of those three.

cracking android license code is such a straightforward process that i have started work on a program that will do all of the work for you (baksmali, patch, recompile, resign). i'm not sure if others will find it useful so it does not get much attention.

unexplainable problems after recompilation with apktool

something i have seen many times is when a program is recompiled it has strange errors. perhaps a progress bar is not showing up correctly, the layout is somehow distorted or there are strange force closes that happen. in my experience the reason for this is almost always apktool's handling of resources.

if you are having trouble, try simply dumping and building without changing anything with apktool. if there is a problem, then apktool is the culprit. i suggest making an issue on apktool's page here: http://code.google.com/p/android-apktool/issues/entry

you don't have to go into detail about what you're using apktool for. there are lots of legitimate reasons such as adding localization. it should suffice to mention in the report that simply dumping/building results in a distorted .apk.

if you are merely modifying smali code and don't need to modify the resources, try using the --no-res option, or you could just use smali/baksmali. if you are trying to modify an .xml resource then you might have to do it manually.

working with smali means working with the classes.dex file in the apk, and not the apk itself. you will also have to handle resigning and zipaligning (optional) yourself

android market license validation

there are more and more apps using a new official license validation mechanism. it seems very well made and robust but unfortunately it is trivial to overcome in at least every instance where i have seen it.

for more information on how it works, there is lots of good information here:
http://developer.android.com/guide/publishing/licensing.html

update: all known (by me) license verification library cracking methods have been implemented in an automated tool here: http://androidcracking.blogspot.com/p/antilvl.html

if you are interested in seeing how easy it is to defeat, read on.

open com/android/vending/licensing/LicenseValidator.smali and look at handleResponse() you'll see something like:

iget-object v0, p0, Lcom/android/vending/licensing/LicenseValidator;->mPolicy:Lcom/android/vending/licensing/Policy;

# this function returns true/false depending on if we should allow access 
invoke-interface {v0}, Lcom/android/vending/licensing/Policy;->allowAccess()Z

move-result v0

# comment out this jump and protection is gone.
# you can also make allowAccess() always return 0x1 (true)
#if-eqz v0, :cond_0

also there is an updated version of the smali syntax highlight file available here:
http://androidcracking.blogspot.com/2010/09/smali-syntax-highlighting-for-ultraedit.html