Android reversing overview

[Kulverstukas]

Revision 1, first release.

Greetings all. After a long wait I might finally finish this article. I'll try to keep it as an article, not a walkthrough because I hate that shit. I don't do this full time and only very rarely, so it won't be an advanced article
There are many "tutorials" written just about this, but hopefully mine will be a bit different
If you have suggestions, what to add, what to cover, maybe I missed or left something out, please tell me.

I will try to cover things like:

• Converting an APK into JAR and exploring the decompiled code, available viewers.
• Extracting resources (like XML styles, strings, icons, etc.) from an APK.
• What the flerp is an OBB file and extracting resources from it.
• Extracting APK files from your phone and how to download apps from GPlay without a phone.
• Doing changes and recompiling.
• What the flerp is SMALI?
• What is ProGuard and SQLCipher, how the flerp do they twerk and how to decrypt stuff.

1. Converting an APK into JAR

1.1. Converters and decompilers

To start doing anything you first need to convert an APK into a JAR file. That way we can easily see the code and whole structure. There are many viewers and converters, I'll just name a few here.
I noticed there are a lot of "tools" for reversing android, but most are simply bundle packages of command line tools for reversing, such as APKTool, Dex2Jar, ded and bunch of others, with a bigger interface and supposedly more functionality. I agree they make the job easier, but they also tend to fuck up a lot, so IMO it's better to just use the stand-alone tools and not these "epic haxor packages".

APKTool :
Great for many things, here is the program output:

Code: [Select]

Apktool v1.4.3 - a tool for reengineering Android apk files
Copyright 2010 Ryszard Wi?niewski <brut.alll@gmail.com>
Apache License 2.0 (http://www.apache.org/licenses/LICENSE-2.0)

Usage: apktool [-q|--quiet OR -v|--verbose] COMMAND [...]

COMMANDs are:

    d[ecode] [OPTS] <file.apk> [<dir>]
        Decode <file.apk> to <dir>.

        OPTS:

        -s, --no-src
            Do not decode sources.
        -r, --no-res
            Do not decode resources.
        -d, --debug
            Decode in debug mode. Check project page for more info.
        -f, --force
            Force delete destination directory.
        -t <tag>, --frame-tag <tag>
            Try to use framework files tagged by <tag>.
        --keep-broken-res
            Use if there was an error and some resources were dropped, e.g.:
            "Invalid config flags detected. Dropping resources", but you
            want to decode them anyway, even with errors. You will have to
            fix them manually before building.
    b[uild] [OPTS] [<app_path>] [<out_file>]
        Build an apk from already decoded application located in <app_path>.

        It will automatically detect, whether files was changed and perform
        needed steps only.

        If you omit <app_path> then current directory will be used.
        If you omit <out_file> then <app_path>/dist/<name_of_original.apk>
        will be used.

        OPTS:

        -f, --force-all
            Skip changes detection and build all files.
        -d, --debug
            Build in debug mode. Check project page for more info.

    if|install-framework <framework.apk> [<tag>]
        Install framework file to your system.

For additional info, see: http://code.google.com/p/android-apktool/
The best thing it can do, and the one thing I use it for, is decompilation of resources, such as strings, styles, layouts, icons, anything. It also extracts the code in SMALI form (we'll get to SMALI later).

ART (Android Reverse Tools) :
It's basically a pretty GUI for command line tools. The package comes with those tools, and it can decompile, rebuild it and sign it. Not very useful tool unless you don't like the command line though. For this to work, it has to reside in a path without spaces, so it's best to put it in the root of some drive.
Since there is no original place to get it from, I uploaded a clean and working package for you: 9841106.zip

Dex2Jar :
Now this is the tool I use the most. As APKTool, it can do many things, but I use it for its ability to straight up convert an APK into a JAR file. It will omit resources and only bundle Java code, so it's not very recompilable, however it's the best thing to read the code and see a class structure.
Here's the help output:

Code: [Select]

convert dex to jar
usage: d2j-dex2jar [options] <file0> [file1 ... fileN]
options:
 -d,--debug-info              translate debug info
 -e,--exception-file <file>   detail exception file, default is
                              $current_dir/[file-name]-error.zip
 -f,--force                   force overwrite
 -h,--help                    Print this help message
 -n,--not-handle-exception    not handle any exception throwed by dex2jar
 -o,--output <out-jar-file>   output .jar file, default is
                              $current_dir/[file-name]-dex2jar.jar
 -os,--optmize-synchronized   optmize-synchronized
 -p,--print-ir                print ir to Syste.out
 -r,--reuse-reg               reuse regiter while generate java .class
                              file
 -s                           same with --topological-sort/-ts
 -ts,--topological-sort       sort block by topological, that will
                              generate more readable code
version: reader-1.14, translator-0.0.9.13, ir-1.11
AndroChef Java Decompiler :
A GUI based tool, one of the better ones. Half of what it does, APKTool can do as well, but this one has some more advanced features that you won't find in other tools.
I didn't find it that useful, because apktool was just fine, but then again I'm not a full-time cracker

DJ Java Decompiler :
This one is not free and limited to 10 uses, so I didn't really use it. Only noticed it has a variety of stuff that I only imagine what could do...

1.2. Viewers and explorers

When you have converted an APK, you will need to see the code, what the hell is going on in there. With these there is also a variety of tools to use, and I will just mention a few that I use.

JD-GUI :
The one and only, the infamous JD-GUI. You just drag and drop a JAR file onto it and start exploring. However I noticed it sometimes does not display some of the code, or shows empty packages when in fact there should be code in there, so I don't use it that often, but for a quick overview it is just perfect.
When you cannot see everything, there is an export function with which you can export Java files in a proper project tree. When exporting it seems to export everything properly, even the code it doesn't see.

Notepad++ :
While this being a text editor, I mentioned it here for the capability to view code in a convenient way. See it has this thing called a "Project workspace" (View -> Project -> Project Panel N). That option opens a simple workspace viewer where you can import whole folder with code, and this is where we can import the code we exported with JD-GUI. Once imported everything will be put a nice looking tree for fast navigation. However this is limited and very basic, but it's great for quick stuff.
Same can be done with Eclipse for full capabilities, such as moving files in the tree view etc.

AndroChef Java Decompiler :
Lets you view the decompiled code as well, but only when you decompile it with the program itself, viewer doesn't come as standalone.

JAD :
An obsolete tool to convert class files into readable java code. Internet claims it doesn't work properly, but it is still working to convert ones from android. Though it's not very practical, because it can only do single files, so it cannot process subfolders or a whole JAR.
It has a shitload of options though.

Code: [Select]

Jad v1.5.8g. Copyright 2001 Pavel Kouznetsov (jad@kpdus.com).
Usage:    jad [option(s)] <filename(s)>
Options: -a       - generate JVM instructions as comments (annotate)
         -af      - output fully qualified names when annotating
         -b       - generate redundant braces (braces)
         -clear   - clear all prefixes, including the default ones
         -d <dir> - directory for output files
         -dead    - try to decompile dead parts of code (if there are any)
         -dis     - disassembler only (disassembler)
         -f       - generate fully qualified names (fullnames)
         -ff      - output fields before methods (fieldsfirst)
         -i       - print default initializers for fields (definits)
         -l<num>  - split strings into pieces of max <num> chars (splitstr)
         -lnc     - output original line numbers as comments (lnc)
         -lradix<num>- display long integers using the specified radix
         -nl      - split strings on newline characters (splitstr)
         -noconv  - don't convert Java identifiers into valid ones (noconv)
         -nocast  - don't generate auxiliary casts
         -noclass - don't convert .class operators
         -nocode  - don't generate the source code for methods
         -noctor  - suppress the empty constructors
         -nodos   - turn off check for class files written in DOS mode
         -nofd    - don't disambiguate fields with the same names (nofldis)
         -noinner - turn off the support of inner classes
         -nolvt   - ignore Local Variable Table entries (nolvt)
         -nonlb   - don't insert a newline before opening brace (nonlb)
         -o       - overwrite output files without confirmation
         -p       - send all output to STDOUT (for piping)
         -pa <pfx>- prefix for all packages in generated source files
         -pc <pfx>- prefix for classes with numerical names (default: _cls)
         -pe <pfx>- prefix for unused exception names (default: _ex)
         -pf <pfx>- prefix for fields with numerical names (default: _fld)
         -pi<num> - pack imports into one line using .* (packimports)
         -pl <pfx>- prefix for locals with numerical names (default: _lcl)
         -pm <pfx>- prefix for methods with numerical names (default: _mth)
         -pp <pfx>- prefix for method parms with numerical names (default:_prm)
         -pv<num> - pack fields with the same types into one line (packfields)
         -r       - restore package directory structure
         -radix<num>- display integers using the specified radix (8, 10, or 16)
         -s <ext> - output file extension (default: .jad)
         -safe    - generate additional casts to disambiguate methods/fields
         -space   - output space between keyword (if, while, etc) and expression

         -stat    - show the total number of processed classes/methods/fields
         -t<num>  - use <num> spaces for indentation (default: 4)
         -t       - use tabs instead of spaces for indentation
         -v       - show method names while decompiling
         -8       - convert Unicode strings into ANSI strings (ansi)
         -&       - redirect STDERR to STDOUTSince it's now obsolete, you can't find it so easily. I uploaded a windows runnable for ya: 2072431.zip

2. Extracting resources

Doing this is very simple, and frankly this chapter won't be very long... because, well, you'll see.
Basically to do that you grab your apktool and

Code: [Select]

C:\apktool>apktool.bat d someapp.apk
I: Baksmaling...
I: Loading resource table...
I: Loaded.
I: Loading resource table from file: C:\Users\kulverstukas\apktool\framework\1.apk
I: Loaded.
I: Decoding file-resources...
I: Decoding values*/* XMLs...
I: Done.
I: Copying assets and libs...That's it. The reversed stuff will be in a separate folder. Libs, assets, manifest and code in SMALI form.

3. What the flerp is an OBB file and extracting resources from it

Opaque binary blob (OBB) is a term used in network engineering and computer science to refer to a sizeable piece of data, which looks like binary garbage from outside, by entities which do not know what that blob denotes or carries, but make sense to entities which have access permission and access functions to them.

Basically those are files used to transfer large data apart from the main APK, such as huge databases or game graphics...
The files can be simply opened with an archiver such as 7zip, once you copy them to your computer. OBB files usually reside in /storage/sdcard/Android/obb/app_package_name/*.obb

4. Extracting APK files from your phone and how to download apps from GPlay without a phone.

I'll teach you some magic in this chapter boys and girls! We all probably know that you can't simply go and download an app from GPlay without a phone. Oh no no no! but there are some things you can do get around this.

Rooted phone :
The most direct method if you have a rooted phone. Install "Root Explorer" and navigate to "/data/app" and simply copy the desired APK to external storage, connect through cable, transfer to your PC - done.

APK Downloader :
The best and most straight method tbh is this Chrome extension:

Code: [Select]

https://lekensteyn.nl/apk-downloader/It was working flawlessly before, but now it doesn't seem to. Maybe it works for others... but it was very convenient. However it can't download paid apps ofcourse, and it can't download expansion files either.

5. Doing changes and recompiling

This is a simple one. You will just need APKTool for this, and something to sign the recompiled APK. I had found a neat utility somewhere on XDA called "One click signer" which does just that - it signs your apk with a click
Download it here: 6974061.zip
Use the command

Code: [Select]

apktool.bat b apk_folderBuilding process will begin and after it completes, put the rebuilt APK into one click signer folder and click it, enter the apk name and done. Push that APK to your device and enjoy!

6. What the flerp is SMALI?

I won't expand on this because there are many great tutorials for it, but according to SMALI docs it's

smali/baksmali is an assembler/disassembler for the dex format used by dalvik, Android's Java VM implementation. The syntax is loosely based on Jasmin's/dedexer's syntax, and supports the full functionality of the dex format (annotations, debug info, line info, etc.)

In other words, SMALI code is the most exact representation of Android Java bytecode in human readable form.
If you want more, try this thread:

Code: [Select]

http://stackoverflow.com/questions/5656804/whats-the-best-way-to-learn-smali-and-how-when-to-use-dalvik-vm-opcodes

7. What is ProGuard and SQLCipher, how the flerp do they twerk and how to decrypt stuff

Android has some code and database protection methods to make reversing harder (but not impossible).

ProGuard : It's a separate Java code obfuscator, but it can do much more, like shrinking and  optimizing your code. It is implemented into ADK (Android Development Kit) by default, but not being used unless you comment a line in the project settings file.
When enabled, ProGuard will rename all your class names, variables, methods to something ambiguous, like single letters and split inner classes and whatnot into separate files. All that is done when you will export your app.
When exporting an app, ProGuard creates a few files to identify and keep track of variables. The most important one is called "mapping.txt". If you get a hold of that file, you can see what is renamed to what and that makes cracking much easier. The same file is also used when viewing the stacktrace which you would receive on GPlay. Stacktrack is obfuscated as well as the code, so you copy the stacktrace along with the mapping.txt and run the retrace utility in ADK's "tools/proguard/bin" folder.

SQLCipher : probably the best solution to hide contents of your database file. Free and opensource, however if you want the commercial edition or pre-compiled binaries, it'll cost you a shitload.
But it's easy to compile the source yourself, it took me some fiddling around to get it to compile and probably with some luck I was able to get it running. Once it compiled it's basically the same SQLite command line interface with big modifications to support encryption at the back.
I cannot remember what went wrong for me, because it was such a long time ago, but there was something with linking it against the OpenSSL crypto libs.
Now when you want to decrypt the database and export it as normal, plain SQLite DB, it is also easy. First you will need to find the passphrase in your APK. That should be easy, and that is a huge downside of such encryptions - the passphrase has to be stored in the code, might be somewhere in the DatabaseHelper class maybe?
Best thing a developer can do about this is make it harder to obtain (I might write about that one day too...).
So when you have the passphrase, you can just do

Code: [Select]

Taken from: http://sqlcipher.net/sqlcipher-api/

$ ./sqlite3 encrypted.db
sqlite> PRAGMA key = 'testkey';
sqlite> ATTACH DATABASE 'plaintext.db' AS plaintext KEY '';  -- empty key will disable encryption
sqlite> SELECT sqlcipher_export('plaintext');
sqlite> DETACH DATABASE plaintext;
And have the plain database

Ok, this just about wraps it up. I hope you learned something new and liked this write-up that is more like an overview
Also posted on my blog: http://9v.lt/blog/android-reversing-overview/

[nafuti]

For downloading apk files, i suggest we skip the extension part(i personally like to limit the extensions i have) and use an online service at http://apps.evozi.com/apk-downloader/
It is pretty proficient, but as always, it wont get the paid apps for you. Better to pay n download them on your phone then transfer them to your PC.

[Deque]

Good article and of course better than a step-by-step tutorial.
+1 for you, dear Kulver.