finished antilvl 1.1. it's kind of scary how well it's working. now that the anti-cracking methods are added in, it should be able to crack the android license verification library and any type of protection i have ever seen, including a few i haven't.

the number of modifications done to an app has increased a bit, so there may be some mix up. let me know how it works for you.

here's the main gist of the changes:

introduced many anti-cracking bypassing methods. it's better than me!

improved --sign-only behavior, though it still errors every other time

Wednesday, January 26, 2011

to facilitate the eye-pleasing posting of smali on blogs and html and such, here is a brush for syntaxhighlighter. i'm in the process of converting my previous tutorials to html and they use this instead of screen shots of code or simple green coloring. it looks much nicer.

the problem could be non-standard resource qualifiers. it affects current versions of apktool (1.3.2), but may be fixed in a later version. the solution is to decomile using --keep-broken-res and fix the xml file manually. for an explanation of how to do this, read this issue by the developer himself: http://code.google.com/p/android-apktool/issues/detail?id=128#c1

this is because access to google's stuff requires an api key, stored in xml as a resource or perhaps in code, that is linked with the certificate of the app. if you modified and resigned it, the certificate is different and will not match the api key. you will have to get a valid key for the signature you are using.

you should already have your own certificate you sign everything with. this way if you release an updated version of the app, users of your previous modified version can update without needing to uninstall the old one first. if you don't already have your own certificate, follow the directions here: Signing Your Applications | Android Developers. you will need to use keytool and examples are given in the link.

Sunday, January 23, 2011

there are only a handful of anti-cracking techniques for android, at least that i know of. this seems to be because of how android apps must behave. they must operate inside their own virtual machine and are not allowed to store permenent data. when they are uninstalled, they must remove all traces of themselves. this makes things like timed trials difficult to implement because a simple reinstall will reset timers.

if an app wants to prevent cracking, it only has a few options. it can check file properties of the apk such as file size, last modified date and signature. it could also check the installer package name to test if it was installed via market. a cracker or pirate would install via adb, not market. antilvl can already hook and subvert signature checks. file size, last modified and installer package hooking are in the works. :D

but there's another way to perform any check in a more clever way that makes detection more difficult... by using java reflection. instead of calling the method directly, the app could use reflection to store the method in a variable and call it later indirectly. this makes searching for the direct method call difficult. it also allows the method name to be obfuscated since it is just a strong. let me show you in code what it may look like:

const-class v1, Landroid/content/pm/PackageManager;
# do not assume this will not always be a plain text
# it could be put together in a much more complicated way such as building character by character using ascii codes
# you'll have to hook reflection methods to test the name or figure it out manually
const-string v2, "getInstallerPackageName"
# make array of size 1
const/4 v3, 0x1
new-array v3, v3, [Ljava/lang/Class;
const/4 v4, 0x0
const-class v5, Ljava/lang/String;
# store String class in array v3, at index v4 (0)
aput-object v5, v3, v4
# get method of name v2 ("getInstallerPackageName") and move to v0
# http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Class.html#getMethod(java.lang.String, java.lang.Class...)
invoke-virtual {v1, v2, v3}, Ljava/lang/Class;->getMethod(Ljava/lang/String;[Ljava/lang/Class;)Ljava/lang/reflect/Method;
move-result-object v0
# do something with v0, like store in class variable
# ....
# and then sometime later, somewhere else in code
# get the package manager and store in v1
invoke-virtual {p0}, Lcom/clever/app/Main;->getPackageManager()Landroid/content/pm/PackageManager;
move-result-object v1
const/4 v2, 0x1
new-array v2, v2, [Ljava/lang/Object;
const/4 v3, 0x0
invoke-virtual {p0}, Lcom/clever/app/Main;->getPackageName()Ljava/lang/String;
move-result-object v4
# put package name in array v2 at index v3 (0)
aput-object v4, v2, v3
# actually call "getInstallerPackageName" with the array we built as parameters
# which contains this package name
# http://download.oracle.com/javase/1.5.0/docs/api/java/lang/reflect/Method.html#invoke%28java.lang.Object,(java.lang.Object...)
invoke-virtual {v0, v1, v2}, Ljava/lang/reflect/Method;->invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
move-result-object v0
check-cast v0, Ljava/lang/String;
# clever to not use any type of full string, just "goog"
# remember the full string is expected to be "com.google.android.feedback"
const-string v1, "goog"
invoke-virtual {v0, v1}, Ljava/lang/String;->indexOf(Ljava/lang/String;)I
move-result v0
# check to see if v0 has the correct value. if not... error :D

the next lesson in way of the android cracker will cover all anti-cracking techniques i know in detail, and antilvl will support these types of checks soon, but this is enough for anyone to figure it out. :D

Monday, January 10, 2011

it's been a while since my last update, so i figure i should say something about progress on antilvl 1.0.

i wanted to learn all kinds of best practices in java, so i spent a lot of time designing classes while trying to avoid coupling and other oop pitfalls. even threw in some unit testing. i also want antilvl to be able to be able to learn how to subvert any implementation of the lvl, and do it without having pages and pages of complicated regex code.

to accomplish this, antilvl's code will be more like an engine, with all file identification patterns and code modification information written in xml with a specification of my own design. it will be mature enough to have in-place dynamic variables and definable search patterns. the result will be almost any apk modification could be cleverly constructed inside the xml without touching the code in about 10-20 lines.

i must stress i'm not doing this for piracy. i'm doing it because it's a challenge. no one else has done it. it's really fun for me. if i was trying to be a pirate, i would not explain how the cracks work. if you're a developer and you insist on protection, you will have to roll your own and heavily modify the official lvl so known methods will not work. use antilvl to help you figure out if it's well protected.

most people don't mind paying a few euros for a program on what amounts to their main computing device. the benefit from spending many hours on increased protection may not be worth it unless your App is very expensive. or perhaps your and android master and just really get off to having wonderfully insane levels of protection.

Monday, January 3, 2011

many people find this blog by searching for smali syntax examples and finding a previous post on example smali syntax. since i originally hastily wrote it, i have learned more so i updated it as best i could for now. more helpfully, i worked out a syntax highlighter for smali using syntaxhighlighter. i'll upload it somewhere official when i'm finished so others can use it. because i know there are throngs of people just itching to have highlighted smali code!