ideas for antilvl and new lesson

my discretionary time is limited lately but i have begun work on lesson 2 which will cover anti-cracking techniques. it will give examples of all anti-cracking methods i have seen in the wild. i will attempt to come up with some novel techniques as well, because that seems fun.

also thought of a possible feature for antilvl. one anti-cracking technique is signature checking. the apk compares the hashcode of its signature with a stored hashcode to see if the apk has been resigned, which would indicate tampering since all apks must be resigned if modified. antilvl could search for these uses, which rarely have any other purpose but to prevent cracking, and optionally disable them. it would then be possible to extend this to other common, easy to interpret anti-cracking techniques. just some thoughts.

sharing a good blog

found a nice blog about reversing and android cracking by Dan, who was kind enough to point out that the well-known site crackmes.de has some android crackmes (just search android).

his blog also introduced me to a tool called dex2jar that will sort of convert a classes.dex file into .java source. of course, it's not perfect and it's still new but it can be useful for getting a quick overview if the dalvik is too confusing.

here's Dan's article on android reversing: http://www.kizhakkinan.com/?p=39, check it out. it's got pictures!

AntiLVL 0.8.1

saw some new kinds of obfuscation right after i released 0.8 so i spent the past several hours rewriting everything and optimizing. i had been looking for a fun java project to get some practice, so this has been quite handy.

the detection was totally rethought and there is a much better chance of detecting new types of obfuscation and lvl files in very strange places. i'm only increasing the version to 0.8.1 from 0.8 until i get a lot more testing, but to do that i'll need to test many apks. best way to do that is just send me any that don't work. i will assume it is legal for you to do so.

tested with 7 different apps and 3 of them worked. one of them would not recompile, so it does not count. one of them required further modifications. one seems broken. your mileage will vary.

download it here.

AntiLVL 0.8

last week, i released the proof-of-concept version of anti lvl. it really only cracked the standard, unobfuscated android license verification. this version cracks license checks of more implementations and works even if code is obfuscated. it is also designed to be flexible and extensible to keep up with changing trends or any new types of implementations.

the new version is here:
https://sites.google.com/site/lohanplus/files/AntiLVL-0.8.zip?attredirects=0&d=1

there is a new page for antilvl so you don't have to always watch the blog here:
http://androidcracking.blogspot.com/p/antilvl.html

AntiLVL - android license verification subversion

update:
new version released. read about it here: http://androidcracking.blogspot.com/2010/11/anti-lvl-08.html


i've written previously about android market license verification here and here. i decided to write a tool for developers who want to protect their apps more by automating the entire process. here's a copy of the readme:

AntiLVL - Android License Verification Library Subversion

[ What is it? ]
This takes an .apk or apktool dump directory, attempts to subvert the market license verification library and recompiles, signs and zipaligns the modified code. The result is an .apk with the LVL check effectively removed. To the App, it appears the check was successful and no part of the application code is modified.

[ Who is it for? ]
Developers who wish to have more than Android LVL protection could devise and implement other types of protection. Then this tool could be used to simulate a crack attempt without the developer having to learn to use apktool, Dalvik and LVL cracking methods.

[ Usage ]
Usage: java -jar AntiLVL.jar [options] <smali dump path | Apk file>  [output Apk name]
Options:
-v:     Verbose output
-s:     Skip assembly
-h:     Show help

[ Known Problems ]
Any sort of LVL obfuscation will prevent this tool from working. It will be added if people want it.

here is the download link:
https://sites.google.com/site/lohanplus/files/AntiLVL-0.5.zip?attredirects=0&d=1

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.