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.

Under the hood, AntiLVL is a configurable Smali code patcher with rules defined in user-modifiable XML files stored inside the jar called fingerprints. Brief summary of how it works:
* Decompiles the Apk
* Perform  regular expression matching
* Carrie out defined modifications
* Recompile, update classes.dex
* Resign and zipalign


[ 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.


[ Usage ]Typical usage:
  java -jar antilvl.jar sample-lvl-app.apk

This will create sample-lvl-all-antilvl.apk.


Usage: java -jar AntiLVL.jar [options] <Apktool/Baksmali dump | Apk file> [Output Apk]
Options:
  -f, --force           Allow overwriting of any existent file
  -s, --skip-assembly   Decompile and modify but do not rebuild
  -d, --detect-only     Detect protection information only
  -n, --lvl-only        Skip all protections except Android Market LVL
  --sign-only           Sign Apk file then exit
  --info-only           Get App info then exit
  --assemble-only       Assemble dump, update Output Apk, sign, zipalign, exit
  --skip-cleanup        Do not delete dump directory after running
  --sign-key            PK8 key to sign with (requires --sign-cert)
  --sign-cert           PEM certificate to sign with (reqires --sign-key)
  --sign-pass           Password to use with signature
  --fplist              List installed fingerprints
  --fpexclude           Comma-separated list of fingerprints to exclude
  --fpinclude           Comma-separated list of fingerprints to include
  -v#, --verbose#       Verbose level (1-3)
  -h, --help            Show this friendly message

Specific DRM Options:
  --amazon-only         Skip Non Amazon App Store DRM subversion
  --verizon-only        Skip Non Verizon App Store DRM subversion

Advanced Hook Parameters:
  --chksigs #           Check signatures behavior
    0 - *default* only match signatures if installed
    1 - always return signature match
  --getpi #             Get PackageInfo behavior
    0 - *default* spoof key/pro/full Apps if not installed
    1 - do not spoof apps not installed

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.

To uninstall:    adb uninstall sample.package.name
To install:        adb install sample-lvl-app-antilvl.apk

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


[ Contact ]
lohan.plus (at) g m a i l (dot) com
http://androidcracking.blogspot.com



[ 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

 
April 18th, 2011 - 1.1.5
  - Tweaked (hopefully improved) LVL detection (Thanks Notion and SuRViVe!)
  - Added hooks for app is debuggable and debugger connected checks

April 8th, 2011 - 1.1.4
  - Added Amazon DRM subversion
  - Fingerprint improvements
    . Fixed some LVL detection
    . Fixed problem with start of method not always being correctly found
    . Removed the possibility for several unnecessary checks, increasing speed
  - Several SmaliHook improvements, including more informative log messages
  - Updated documentation in fingerprints.xml but it's wise to also look at examples.
  - Added notifications for suspicious behavior
    . Getting the installed apk path - reason: usually a file size check
       Apps usually want to look at themselves to check for tampering (md5 hash, file size, etc.)
    . Getting device id, wireless mac, bluetooth mac, sim serial number - reason: unique identifiers
       Some services use these as unique identifiers for your device and they must be spoofed to avoid bans
  - Added spoof-id option for device / android_id spoofing
  - Included TestTarget.apk as a demo / educational resource
 
February 13th, 2011 - 1.1.3
  - Added --fplist, --fpexclude options (for warezhka), so you can exclude certain
      changes that you think might be breaking your Apk
  - Fixed several possible problems with hooks (thanks SuRViVe)
  - Major refactoring to create reusable libraries I'll release when they're not so ugly
 
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
 
January 21st, 2011 - 1.0
  - Complete rewrite of previous versions
  - Acts more like an engine, with modification information stored in fingerprints.xml
  - Many, many more Apk files can be decompiled and recompiled
  - Handles several new types of protection methods
  - Signature checking, a common anti-tampering technique, is subverted
  - File size / last modification checks are more accurately detected
  - Pro / Full unlock app protection is correctly handled sometimes
  - Much more compact / optimized java byte code, --clever option :D

Download (current version 1.4.0):



Older versions:

21 comments :

  1. Hooray. Less drm is more better. I detest having my resources abused by software I have PAID to license!!

    ReplyDelete
  2. dubious, adds permissions to manifest file without informing us... what says the author?

    ReplyDelete
  3. 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

    ReplyDelete
  4. Anonymous, it doesn't add permissions to the manifest. that feature would be a pain to write, and i don't remember writing it so, if you see otherwise let me know.

    Anonymous, i'm not highly motivated to update antilvl. it's kind of depressing. i think too many people use it for evil. if enough legit users complain, i got maybe one more update left in me.

    ReplyDelete
    Replies
    1. 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.

      Delete
  5. Thks for your answer lohan+.

    ReplyDelete
  6. "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.

    ReplyDelete
  7. this is evil genius.

    ReplyDelete
  8. not sure what to say, so i'll say this instead:
    i know no one ever reads the readme, but i know for sure no one has diff'ed the readmes

    ReplyDelete
  9. hello
    i wanna ask you how to launch it ?

    ReplyDelete
  10. If you really wanted to help developers then you would remove the link and only release it to people with developer accounts and published apps.

    Idiot.

    ReplyDelete
    Replies
    1. So you prefer people not knowing that this kind of app exist ?
      Security by obscurity will never be secure.

      Delete
  11. 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!

    ReplyDelete
  12. 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!!!

    ReplyDelete
  13. This comment has been removed by the author.

    ReplyDelete
  14. 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.

    ReplyDelete
  15. 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!

    ReplyDelete
    Replies
    1. You should buy the apps whenever possible and support the devs.

      Delete
  16. Awesome Lohan, great work, very helpful.

    ReplyDelete
  17. Lohan, i have been reading a lot of your posts and am wondering, are you available for hire? And what rate?

    ReplyDelete
  18. Urgent update is needed after three years

    ReplyDelete

Do NOT post about or link to specific apps!