The .so file is a compiled library, in most cases from C or C++ source code. .so stands for Shared Object, it doesn't have anything to do with obfusation, it just means someone wrote parts of the app in C.
In some cases, there is existing C code and it's just easier for the programmer to build a JNI interface to call the library from java; in other cases, ...
It's not only possible but has been done already, and not just once. Here's three I know about, and there may be more.
Kivlad by Cody Brocious
DAD by Zost (Androguard project):
JEB by Nicolas Falliere (commercial)
Then there are ...
There are many tools, some are more low-level and some build on top of the low-level tools to make nicer and more complete tools.
Here are my favorites:
JADX - GUI (and Command line) to produce Java source code from Android Dex and Apk files https://github.com/skylot/jadx
Android MultiTool - decompile/recompile and sign applications + jar framework ...
Besides Guntram's suggestions, check out the retargetable decompiler aka retdec. It can decompile the binary to Python or C code. At least for me, it reads easier than pure assembly (and it works for ARM binaries).
It works very well for sketching you the rough workings of the shared object.
A plugin for select IDA versions exists, but the main limitation ...
Not hard enough!
First of all, if you save the key as a non-encrypted string, a simple strings command will find it and IDA x-ref will even show the reverser where it's used.
If you save the key encrypted, a simple breakpoint will let them see the decrypted password. (or understanding the decryption algorithm).
I use apktool for this purpose, and a short little pair of shell scripts for decompiling and recompiling APKs:
if ! [ "$1" ]; then
echo "usage: $0 <file.apk>"
apktool d -f "$target_apk" -o smali
if ! [ "$1" ]; then
After a little bit more work and some more careful re-reading, I figured out my mistake: the files in /data/app-asec/ are the encrypted containers. They're actually dm-crypt volumes, which then get mounted at /mnt/asec/[app_id]. The pkg.apk in that directory is the unencrypted apk that can be analyzed using any of the fine tools in this answer.
Oracle Java Virtual Machine
Tracing the execution of a Java program can be done through the Java Platform Debugger Architecture (JPDA). This framework allow you to get a full control of an execution within the JVM (without having to modify the original code). See this tutorial for a more in depth view of this framework.
If you want to implement it by ...
To debug an APK without the source code, you need to perform the following:
Enable debug mode in the APK (use apktool to achieve this)
Sign the APK (use keytool and jarsigner)
Install the app and identify the debug port of the app using Android Debug Monitor or DDMS
Use an IDE with support for JDWP like NetBeans pointing to the project with the decompiled ...
A plain text string like this will be visible by looking at the file in a hex editor (like hte or a viewer like xxd or od) or with the Sysinternals strings command or with strings(1) on a Linux/FreeBSD etc, for example. Most reverse engineering tools have a separate view for strings, because those are usually exceptionally useful to reverse engineers. Amirag ...
Basic steps to analyse an android APK
Analysing a APK is like any reverse engineering process. If there is no-prior knowledge I do assume you know Java and like to puzzle. Lets have a look at the most basic steps of reversing an APK.
The first and most important rule in Reverse Engineering is, you want to know what makes it tick. This requires research, ...
You can also try a dynamic approach by hooking APIs and observing arguments and return values. This will allow you to look at data going into crypto APIs, which may help a lot when dealing with network protocols. Check out the Frida instrumentation toolkit for an open source cross-platform solution (Android, iOS, Windows, Mac and Linux). There's a tutorial ...
this is not entirely true. Dalvik bytecode will also be verified on the device, but this happens during installation time, not runtime. A verified and optimized version of the dex file will be stored on the system, protected by file system permission (you cannot change it afterwards unless you have rooted your device).
The trick that was used in the blog ...
Android also contains bytecode verification but this step is moved from class loading on the device to the dex compiler (as it is similarily done in J2ME).
Alter dexing your class files (and before packaging to an .apk file) you can modify the files and introduce the referenced obfuscation.
So at loading time no further verifcation is done.
Use Xposed. Learn the API, is the way you should hook & manipulate Android apps.
Xposed + JustTrustMe
Xposed module (thx Fuzion24). The method calls you're looking for are in the below source file:
After you learn Xposed, move ...
There're two broad ways in which you can declare JNI functions.
The first is the more obvious way in which the JNI function has to follow a specific naming convention like JNIEXPORT void JNICALL Java_com_app_foo_bar. You can easily identify such functions using readelf.
The other not so obvious way is to use RegisterNatives. Here your functions can have ...
In order to get this to work I had to use a combination of the comments left on my original post. As I mentioned in the topic the issue looks like it being and issue with resource bundles not being included properly. My best guess is the original compilation settings were such that the default resource bundle is different than what's documented here. Whether ...
ELF itself doesn't specify any kind of checksum. Your link error is likely due to an incorrect edit which changed some offsets within the file. If you don't adjust the offsets, you have to replace a string with a string that is no longer than the original, and you cannot add new fields unless you have a known amount of slack space available.
Use readelf -a ...
Use android-ndk, https://developer.android.com/ndk/downloads/index.html.
You can use the toolchains inside the ndk to perform the type of disassembling you want to. For e.g. if I decompile an apk and get a .so library out of it, I will do :
./android-ndk-r15b/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-objdump -T "...
The difference between a debug apk and a release apk is that a debug apk is signed by a particular key which is provided with the SDK, whereas a release apk is signed by some other key. There's nothing to reverse engineer: all you have to do to make a release apk and sign it.
Nobody but you can create an apk signed by you. But anyone can make their own ...
According to documentation the first one is base object destructor and the second one is deleting destructor.
Constructors and destructors are simply special cases of <unqualified-name>, where the final <unqualified-name> of a nested name is replaced by one of the following:
<ctor-dtor-name> ::= C1 # complete object constructor
As you need just 2 more bytes, you don't need a large code cave. Out of the box, there are four things you can try:
It's very likely you have a function or 2 in your text segment that are present in some source code, but never called. Look for loc_XXXX labels that have the standard function prefix (push ....,LR) and the suffix (pop ....,PC) a few dozen ...
I did this with a lot of Android apps so I'll share what I have learned.
When thinking of sniffing traffic, the first thing that comes to mind is "I'll just root the Android device, run tcpdump on it and I'm done". That works for simple things, but it gets really messy really fast. And if the app uses SSL (like 99% of what's out there) it's even worse.
I spent the last 3 or 4 days
spending the majority of my day analysing Smali code making almost no
I know it feels like you've made "no progress", but I'd encourage you to not look at it that way. You spent 3 or 4 days figuring out which approaches don't work, which is in itself progress. And you also built up 3 or 4 days of reverse ...
If your application can decrypt the files, then you should assume that anyone sufficiently interested can do so as well. End of story.
Obfuscation can slow people down, but it won't stop everyone, and it probably won't be as effective as you think it will be.
Single player games most frequently do contain all the information hard coded in the APK.
Multiplayer games usually require more work such as packet analysis and more black box work but may contain some of the mechanics hard-coded.
It depends on the app, usually, most single player games don't require any online verifications other ...
You can instrument Java by using an agent, that will manipulate the bytecode of the loaded file (using Asm is recommented for bytecode manipulation).
You might want to use Eclipse's Bytecode Outline plugin to debug execution.
This is a good tutorial on the topic.
I think it should be possible even with current Java decompilers, by patching their code. They have at least one big difference - while JVM is stack-based, Dalvik is register-based. This difference could be handled with not so much code. Second difference - bytecode format. So you need use code, which is able to disassemble Dalvik bytecode format.
ida pro + hexrays for arm.
IDAPro is best disassembler tool for many processors and file types.
HexRays ARM - plugin for IDAPro (doesn't work separately), which trying to decompile assembler to C-like source code
both not free
See this. You can unzip the classes.dex from your apk file on the mac, and dex2jar should work on a mac as well.
The last part, jd, is a windows program, but they have an online demo on their project site - click "live demo" in the header, then drag and drop your jar file on the input files box.
I just noticed there are download links for jd on mac ...