AntiLVL

AntiLVL - Android License Verification Library Subversion

[ What is it? ]
AntiLVL's purpose is to subvert standard license protection methods such
as the Android License Verification Library (LVL), Amazon Appstore DRM
and Verizon DRM. It also disables many anti-cracking and anti-tampering
protection methods. Because every implementation of the LVL is
potentially (and often is) quite different, it's not possible to
automate patching in every case. It will not always work. However, it
has been designed to get around obfuscation and to apply many
variations.

[ Who is it for? ]
* Android developers that wish to test their protection methods against
common types of attacks. The fact that the tool exist may encourage
developers to either give up on protection and focus on making better
Apps or, on the other extreme, to develop a robust protection mechanism
that will detour all but the most adamant crackers.

* Those wishing to automate the task of patching Apk files for whatever reason.

* The curious that wish to know more about Android cracking. AntiLVL is an easy way to understand several typical techniques.

If the App fails to work properly after processing (ex: force closes),
it could be the app uses a hooked method in an unpredicted way. Play
with the --lvl-only, and --fpexclude options to prevent AntiLVL from
hooking those methods. You can use --fplist to see all of the
fingerprints. Anything that starts with "Hook" is a likely candidate for
exclusion.

I assume you know how to install / uninstall Apps. My preferred method
is with adb. If you need to uninstall first, AntiLVL will give you the
package name when it first starts if it knows.

This package includes two binaries: aapt and zipalign. Aapt is for
getting package information and zipalign is for optimizing performance
of the Apk. They must be in the same directory as AntiLVL or in your
path. For more information on how zipalign works, check out:
http://developer.android.com/guide/developing/tools/zipalign.html

If you are using Linux, you may need to set execute permissions on them. For example:
chmod 755 aapt
chmod 755 zipalign

[ AntiLVL Hacking ]
Included is an Apk called TestTarget. It's used as a test for AntiLVL
before release. It contains examples of all the protection methods
AntiLVL knows how to defeat. It's included with the Eclipse project
source. If you want to develop your own fingerprints, you can use
TestTarget to test it afterward. It mainly tests just the anti-cracking
and anti-tamper methods, not the LVL or market-specific DRM.

To add your own custom fingerprints, open the AntiLVL jar with a zip
archive viewer, such as 7zip and browse to /fingerprints. Check out
fingerprints.xml for documentation and examples, and also look at the
others to get a good idea of how stuff works. You can add your rules to
any of the XML files, but custom.xml is empty and just for you! The XML
specification is _way_ overkill for what is needed for just some simple
patching, so it should be flexible enough to do all kinds of weird
stuff.

If you find AntiLVL is making false positives or incorrectly modifying a
file, you can score yourself some bonus points by fixing it yourself in
the fingerprint definitions, and super bonus points for sending in the
fix.

[ Caveats ]
AntiLVL will not work well against any type of bizzare custom
protection. It understands some trivial license checks but any sort of
advanced non-LVL protection will not work. If this happens, your best
bet is to use AntiLVL as a means of detecting anti-cracking code. Just
run it normally using --skip-cleanup and modify the resulting Smali dump
by hand until satisfied. Reassemble with --assemble-only with the
previously created *-antilvl.apk as target.

If you have any questions, comments, suggestions or if AntiLVL does not
work and you are reasonably sure the App is using Market LVL, Amazon or
Verizon DRM, contact me. :D

[ Changes ]
October 18th, 2011 - 1.4.0
- Complete rewrite (because no developer is happy until it's been rewritten _at least_ 3 times)
- Added --sign-pass, --sign-key and --sign-cert options to sign with your own signatures
- Added support for patching Verizon DRM
- Added support for patching / stripping Amazon DRM (thanks zart!)
. Stripping is the default, patching can be enabled in place of stripping with --fpexclude "Amazon DRM Strip"
- Added file permission checks for aapt and zipalign
- Added --fpinclude, --fpexclude and --fplist
. They are case insensitive and will work with regex.
Ex: To exclude all Hooks, --fpexclude Hook.*
- Added --getpi option to determine how hook handles getting PackageInfo
- Major changes to SmaliHook
. Split up into multiple sections so they can be included as needed
. Added recursive method invocation hook
Instead of hard coding hooks, use script vars of the form %!Hook:hook_name.methodName%"
- Changed how afterOP and beforeOP are handled so they work as you would think
It only really applied to inserts and replaces, but now they work for finds/matches
- All fingerprint operation types can be defined with :#, ex: type="insert:3" where 3
is the limit on the number of times it will attempt that operation.
- Properly implemented multiple fingerprint region support
- TestTarget updated with cool icon, more info and new anti-cracking / anti-antilvl checks

February 6th, 2011 - 1.1.2
- Fixed --skip-nonlvl, -n option
- Fixed improper instances of packages being unnecessarily detected as installed
Though this may hinder some key / pro / unlock checks
- Improved accuracy of a few checks
- Added two anti-cracking hooks
- Added limited support for API key replacement
Full support requires resource decoding/building which is planned for 1.2
- Improved signature spoofing
- Now creates output Apk path if it does not exist

January 30th, 2011 - 1.1
- Introduced many anti-cracking bypassing methods. It's better than me!
- Improved --sign-only behavior, though it still errors every other time
- Fixed issue with modification's sometimes being done improperly
- Several under the hood improvements for future features

In antilvl 1.1.5 there is an option to generate a random device id (--spoof id 1). It seems the option does not work at all. Instead, when i put a hard device id it's ok i can test my apk with another id.Did you see that bug ? Is it possible to correct it and (re)implement this option in the last version of antiLVL

Hey lohan+.I'm pretty sure lots of people use it for evil, but I needed to use it for a less evilish purpose. There is this point and click game for PC and Android which I translated when it came out for PC. Now I wanted to port my translation to the Android version but unfortunately I am unable to test it since the apk seems to check the obb file for changes or CRC signature. I tried AntiLVL v1.4 with the app and it did find a few checks and successfully patched them, the thing is that the app just shows a blank white screen after patching. Nevertheless it is different than the non-patched version which attempts to re-download the obb file. If the obb is the original content then it works as good as the non-patched version. Could you give me a little hand here? Thanks man.

"i think too many people use it for evil" - assuming you are an intelligent person, this must be a joke. What did you expect? Hope you know you are responsible for this "evil" because your tool is used for this. Plus lots of hours of work of your fellow developers all around the world who now have to protect their software against your tool.

I think that this is an amazing utility! as an at home developer I enjoy seeing what holes is put into my app from the software i'm developing with. Also, a few other fellow developers and myself use this to make our apps that much harder to crack. Thank you so much for your hard work on this!

(also, I use this to inform other people of their exploitable points in their apps). I'm very impressed. thank you again for your hard work. it is too bad that people use this to steal. I don't have a developer account and I don't officially publish apps as my apps I would prefer to have sideloaded. (keeps my audience smaller). Keep up the great work good sir!

Whether the authers intentions are right or wrong, if he didn't develop this amazing piece of software someone else would have. I think he's was kind enough to make known to both sides of the arena. Its like throwing a piece of meat to two hungry wolves. Right or wrong who cares, you all should know how this "game" will change in a short time and there will be new readmes to waist your time and opinions, complaining or complementing someone on thier labors. I would like to finish my waisted time and opinion and say "well played guy". Its not checkmate though so all you developers....develops better!!!

I agree that developer should have a copy protection software to avoid other people from copying their software/codes whether it's a mobile app or system software. I also think this kind of cracking system you're referring to will help developers test their system's protection. But if it lands in the wrong hands then I think they can use it to steal codes to the weak app protection.

This is the best thing I recently found on Internet. Thank you! Not because I can crack 90% of appz up there now, but... I finally can run application I bought without setting internet connection and google account! Thank you once again!