�ݺ�ߣ

PSCG
Ron Munitz
Founder & CEO - The PSCG
ron@thepscg.com
Voxxed Days
Vilnius
18 September 2015
@ronubo
Android Reverse
Engineering Lab
(Un)Build recipes
The slides are available online at:
thepscg.com/talks/

This work is licensed under the Creative Commons
Attribution-ShareAlike 4.0 International License.
To view a copy of this license, visit http://creativecommons.org/licenses/by-
sa/4.0/
© Copyright Ron Munitz 2015
PSCG

about://Ron Munitz
● Founder and CEO of the PSCG
○ The Premium Embedded/Android consulting and Training firm
● Android*, Linux*, Security* Trainer and Instructor
○ The PSCG, NewCircle and the Linux Foundation
● Senior Lecturer at Afeka College of Engineering and
Holon Institute of Technology
● Founder and (former) CTO of Nubo Software
○ The first Remote Android Workspace
● Always up for something new. Builder, Adviser.
● Building up on diverse engineering experience:
○ Distributed Fault Tolerant Avionic Systems
○ Highly distributed video routers
○ Real Time, Embedded, Server bringups
○ Operating Systems, very esoteric libraries, 0’s, 1’s and lots of them.
PSCG

Agenda: 50 minutes on fire
● This is an Android Reverse Engineering lab.
● That does not require profound knowledge in
Android
● Yet in order to understand unbuilding, we will
first explain the Android build process
● And then explain and show the unbuild process.
● The lab is Studio/Eclipse/Gradle/Studio
agnostic.
● If time permits (and it won’t), we’ll show Network
analysis using network packet interceptors.
PSCG

Agenda: 50 minutes on fire
● The slides are published in the URL in the
title slide
● But don’t (completely) rely on them. The only
thing you should really care about is the
terminal, and the spoken words.
● Feel free to record.
PSCG

Android Build Process
PSCG
Building an Android Application

Android Application Build Process
Traditional.
Pre-Lollipop, Pre-Marshmallow

● The Android Asset Packaging Tool (aapt) takes your
application resource files, such as the
AndroidManifest.xml file and the XML files for your
Activities, and compiles them. An R.java is also
produced so you can reference your resources from
your Java code.
● The aidl tool converts any .aidl interfaces that you
have into Java interfaces.
● All of your Java code, including the R.java and .aidl
files, are compiled by the Java compiler and .class
files are output.
● The dex tool converts the .class files to Dalvik byte
code. Any 3rd party libraries and .class files that you
have included in your project are also converted into
.dex files so that they can be packaged into the final
.apk file.
PSCG

● All non-compiled resources (such as images),
compiled resources, and the .dex files are sent to
the apkbuilder tool to be packaged into an .apk file.
● Once the .apk is built, it must be signed with either
a debug or release key before it can be installed to
a device.
● Finally, if the application is being signed in release
mode, you must align the .apk with the zipalign
tool. Aligning the final .apk decreases memory
usage when the application is running on a device.
PSCG

Application Signing
All Android applications must be signed. Application or
code signing is the process of digitally signing a given
application using a private key to:
● Identify the code's author
● Detect if the application has changed
● Establish trust between applications
Note: A popular attack surface.
PSCG

Odex, OBB, and the likes
● The picture listed before is incomplete, because there
are additional [optional] phases:
○ ODEX: Optimized DEX code, or more precisely a JIT
cache.
■ Can be generated on build time, on on runtime,
on the fly.
■ Relevant for both User and platform apps.
○ OBB: Opaque Binary Blobs - Binaries extending
APK files. Original purpose: APK size limitation.
■ Generated on Build time (if at all).
■ User apps only (Of course platform can just load
another file, etc.)

Odex, OBB, and the likes
● There are tools for obtaining information
from both
○ But don’t count on the OBB, as they are completely
arbitrary file formats. Usually used for some textures,
and other resources in Games and more.
● As long as an app is not Forward-Locked,
one can read entire APK’s via the
PackageManager
○ And read into the class files, use the classloader,
etc.
○ And also just “copy” the APK → App exporting apps.

Lollipop and Marshmallow.
We will concentrate on the AOSP master
branch, as per mid-September, 2015
PSCG

APK installation
● Packages can be installed as part of the ROM
(/system), as part of the initial /data/ partition of the
ROM, via the Play store, direct links, attachments, and
adb install.
● In either way, the PackageManager is responsible of
setting up the installation path and directories.
● On pre Lollipop (Dalvik based) versions, the APK’s were
installed, and then (possibly) JIT-ed
○ Or pre JIT-ed - DEX_PREOPT - Out of the scope of
this talk
● On Lollipop - another phase of LLVM compiling using
dex2oat happens n the device itself
○ Or: DEX_PREOPT...

APK Installation: Why should one
care about JIT/OAT?
● Well, in theory they shouldn’t care much for
Lollipop/Marshmallow because the base
APK is redundant for installed apps.
● However, Prebaked (ROM) and pre
optimized ODEX/OAT files are not
redundant to the APK, but rather split
⇒ No ODEX == No code.
● Note: in Lollipop and Marshmallow all
DEX/ODEX files are really OAT files. That’s
extremely confusing, but that’s the way it is.

Finding your files
Without getting into too many details:
● Application data files go into:
○ /data/user/<userno>/<packagename>
○ /sdcard/Android/data/user/<userno>/<packagename>
● Application itself (apk) goes into $ADIR:
○ ADIR is /data/app, /data/priv-app, system/app ,
/system/priv-app, …
● Android Runtime OAT files go into $ODIR
● We will not discuss DSO’s, OBB’s, and
forward locked apps at the moment.
○ There are ways to extract them, and except for the FL
PSCG

ADIR ? ODIR?
● These are names I made up, because the
folder hierarchy changes between versions.
● For example: the OAT files (which will have
a misleading .dex extension) will be in the
following locations:
○ Marshmallow: Pretty much where the APK is:
■ /data/app/<package>/<ARCH>/base.odex
○ Lollipop: In /data/dalvik-cache/<ARCH>/
■ data@app@<package>@base.apk@classes.dex
■ system@<...>@ …
● Our examples will be on Marshmallow.

Android Unbuild Process
PSCG
Unbuilding an Android Application

Reverse Engineering an App
● In life, it is hard to build and easy to destroy
● In Software it can be the same
● But it doesn’t have to.
● Reverse Engineering is the process of
unbuilding. Decompiling. Extracting
information out of compiled programs
● It is a fascinating domain
● That can have disastrous outcomes

Android rev-eng Tools
● apktool
○ Decodes resources to nearly original form and rebuild them after making
some modifications; it makes possible to debug smali code step by step.
● dex2jar
○ dex2jar is a tool for converting Android's .dex format to Java's .class
format. just one binary format to another binary format, not to source.
● JD-Project - jd-gui/jd-plugin
○ The “Java Decompiler project” aims to develop tools in order to decompile
and analyze Java 5 “byte code” and the later versions.
● Custom “oat2dex” tools
○ Cut the DEX code out of the OAT code, so that the processed file would
be able to serve as input to the aforementioned tools.
PSCG

Android rev-eng tools
● smali
○ Assembler/disassembler for the dex format used by dalvik, Android's Java VM
implementation. Supports the full functionality of the dex format (annotations,
debug info, line info, etc.)
○ Many time it’s MUCH EASIER to work on the smali level - especially when one
wants to modify and repackage an APK.
● androguard
○ Androguard is mainly a tool written in python to play with :
■ Dex/Odex (Dalvik virtual machine) (.dex) (disassemble, decompilation),
■ APK (Android application) (.apk)
● There are more. Commercial and non commercial
● Most of the GUI tools just build on the most popular
command line tools - so we will concentrate on them.
● When there is a will there is a way
● There is a will. Code, data, behavioral attacks, IP.
PSCG

Reverse Engineering an App
● apktool takes your signed or
unsigned application apk and
retrieves
○ readable AndroidMenifest.xml
○ All its resources.
○ .dex/.odex files as .smali files
which are dex disassembly.
● dex2jar tool creates jars that contain .
class files of the application by
converting .dex files.
● A Java Decompiler (*jd*) can then be
applied.
○ The source code can be retrieved
automatically by installing jd-
plugin on Eclipse and opening .
class files.
Signed Apk
Resources
apktool
.dex files Manifest
.class files Java files
dex2jar
jd-plugin
PSCG

Ahead Of Time Compiling (ART)
● Experimental support before Lollipop
● Default Runtime since Lollipop
● AOT is a next generation JIT
○ In “plain Italian”: Your Java runs as native code.
● It essentially compiles your DEX code, into
completely native code.
○ Seems like problem solved right?
○ Well not really.
■ Observe: oatdump --oat-file=<some file..>

$ oatdump --oat-file=system@priv-app@Settings.apk@classes.dex ### Excerpts
MAGIC:
oat
042
CHECKSUM:
0x48675513
INSTRUCTION SET:
X86_64
INSTRUCTION SET FEATURES:
none
DEX FILE COUNT:
1
…...

KEY VALUE STORE:
dex2oat-cmdline = --runtime-arg -Xms64m --runtime-arg -Xmx512m --boot-
image=out/target/product/generic_x86_64/dex_bootjars/system/framework/boot.art --dex-
file=out/target/product/generic_x86_64/obj/APPS/Settings_intermediates/x86_64/packag
e.odex.input --dex-location=/system/priv-app/Settings.apk --oat-
file=out/target/product/generic_x86_64/obj/APPS/Settings_intermediates/x86_64/packag
e.odex --android-root=out/target/product/generic_x86_64/system --instruction-set=x86_64
--instruction-set-features=default --include-patch-information --runtime-arg -Xnorelocate --
no-include-debug-symbols
dex2oat-host = X86_64
image-location =
out/target/product/generic_x86_64/dex_bootjars/system/framework/x86_64/boot.art
SIZE:
3975604
….

1: Landroid/support/v13/app/FragmentCompat$BaseFragmentCompatImpl; (offset=0x001524d8)
(type_idx=383) (StatusInitialized) (OatClassAllCompiled)
0: void android.support.v13.app.FragmentCompat$BaseFragmentCompatImpl.<init>()
(dex_method_idx=1724)
DEX CODE:
0x0000: invoke-direct {v0}, void java.lang.Object.<init>() // method@11019
0x0003: return-void
…..
OatQuickMethodHeader (offset=0x001c0000)
...
QuickMethodFrameInfo
...
vr_stack_locations:
ins: v0[sp + #52]
method*: v1[sp + #0]
outs: v0[sp + #4]
CODE: (code_offset=0x001c0018 size_offset=0x001c0014 size=88)...
0x001c0018: 85842400E0FFFF test eax, [rsp + -8192]
suspend point dex PC: 0x0000
GC map objects: v0 (r3)
0x001c001f: 4883EC28 subq rsp, 40
0x001c0023: 48895C2418 movq [rsp + 24], rbx
0x001c0028: 48896C2420 movq [rsp + 32], rbp
0x001c002d: 488BEF movq rbp, rdi

In other words the OAT files provide you with:
● A full mapping from Native code to DEX byte
code
● A full mapping from both to Java functions.
● So you can apply the same techniques
for .dex file decompiling.
○ More tools: oat2dex, ...

How to “oat2dex”?
● Search for the DEX_FILE_MAGIC
○ { 0x64 0x65 0x78 0x0a 0x30 0x33 0x35 0x00 }
○ "dexn0350"
● Get rid of everything before it, and
everything after the DEX code
● Then use the “Traditional” tools on the
resulting file
● For a Python implementation see:
https://github.com/jakev/oat2dex-python

Repackaging
● Reverse Engineering is one thing. Modifying
an APK is another.
● Sometimes it is easy to rebuild from Java
sources - after complete decompilation.
● Most of the times it’s not ⇒ Fallback to .
smali
○ apktool d ⇒ modify ⇒ apktool b
○ baksmali ⇒ modify ⇒ smali
● Anyway, one has to resign the applications
after modifications (and re-zipalign) using
jarsigner.

Protecting Your Code
● There are no 100% bullet-proof protections
● There are however effective hardening methods
such as
○ Obfuscation
○ String Encryption
○ Asset Encryption
○ Tamper Detection
○ And more
● The tools exist at all levels: Java/ C/C++,
assembly, Javascript.
○ For more information - book a training
○ For just a teaser -look at some of my “Ultimate
Android Security Checklist” talks (always updating)
PSCG

Follow up:
● Android Security workshop
○ Public class in Tel-Aviv - October 18-20, 2015.
○ training@thepscg.com
○ Discount Code: VoxxedDays1809
● Private/Public classes in Lithuania?
○ Contact me - training@thepscg.com

Reversing Showcase
PSCG
Some screenshots of a trivial application
reversal, presented for future reference. We’
ll do something more meaningful on the
terminal

Reversing Showcase
● For resources we will
use apktool
○ Which are usually
available in the .
apk without charge
○ But in a binary
forms (i.e. XML’s)
PSCG

Reversing Showcase
● After using
apktool, we get the
resources in the
expected folder
PSCG

Reversing Showcase
● This tool will serve
us to get the .class
files
PSCG

Reversing Showcase
● After running
dex2jar, we get jar
file containing the .
class files.
PSCG

Reversing Showcase
● This tool will help
us open .class files
without source
code
● In this case we
install JD-Project
as plugin to
eclipse
● There is also a
standalone version
PSCG

Reversing Showcase
● In order for JD-
Project to work, we
need to have the
jar in .classpath
● For that we will
add jar file as
external
PSCG

Reversing Showcase
● There we have it.
Snake app reverse
engineered.
PSCG

Reversing Showcase
● But what if I don’t have Eclipse?
○ Use jd-gui (my current choice)
○ Use JEB
○ Use other commercials or non commercials tools
● There is also a plugin for Android Studio, but
it is not yet considered stable.
PSCG

Thank You
PSCG
Consulting/Training requests:
ron@thepscg.com

�ݺ�ߣ

Voxxed days Vilnius 2015 - Android Reverse Engineering Lab

More Related Content

Voxxed days Vilnius 2015 - Android Reverse Engineering Lab