92
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, ...
28
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 ...
24
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 ...
20
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).
19
I use apktool for this purpose, and a short little pair of shell scripts for decompiling and recompiling APKs:
decompile-apk
#!/bin/bash -e
if ! [ "$1" ]; then
echo "usage: $0 <file.apk>"
exit -1
fi
fn=${1%.apk}
target_apk=$fn.apk
apktool d -f "$target_apk" -o smali
echo "Done."
compile-apk
#!/bin/bash -e
if ! [ "$1" ]; then
echo "...
15
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 ...
13
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, ...
13
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 ...
12
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 ...
11
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 ...
11
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 "...
9
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.
Specification ...
9
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:
https://github.com/Fuzion24/JustTrustMe/blob/master/app/src/main/java/just/trust/me/Main.java
Frida (http://www.frida.re)
After you learn Xposed, move ...
9
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 ...
8
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 ...
8
I spent the last 3 or 4 days
spending the majority of my day analysing Smali code making almost no
progress.
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 ...
7
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
...
7
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 ...
7
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.
Use ...
7
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.
7
Short answer
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.
Generally
It depends on the app, usually, most single player games don't require any online verifications other ...
7
In fact, the behavior you are describing is coming from the usual behavior of the GOT/PLT sections. They are used to dynamically link the program calls to shared libraries functions at runtime.
In fact, a shared library can be loaded at any place in the process memory, there is no way to predict statically where it will pop up. So, the GOT/PLT load the ...
6
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
https://www.hex-rays.com/index.shtml
6
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.
Edit
I just noticed there are download links for jd on mac ...
6
Your instructions shown by Ida are Thumb-mode instructions. The easiest way to verify this is by checking the addresses - each instruction has 2 bytes. Gdb doesn't know this however, and assumes 4 byte arm instructions. When an object has a symbol table, gdb can detect the instruction mode from that, but will fallback to a default mode when it can't. You can ...
6
Unfortunately it is not enough code to say exactly what it is, but,
as @0xec said, it looks very much like control flow flattening.
Usually such kind of code transformations are done automatically with obfuscators.
There are some obfuscating compilers, and one of them does CFG flattening. As far as I know this compiler is not one-of-a-kind, there are a ...
6
You want to look at the definitions of the methods being called. The definition of the decryptString method will contain the native access flag, similar to it's corresponding java declaration. e.g. Something like:
.method public native decryptString(Ljava/lang/String;)Ljava/lang/String
Additionally, you can look for calls to System.loadLibrary as an ...
6
var ret = this.fn();
var buffer = Java.array('byte', ret);
console.log(buffer.length);
var result = "";
for(var i = 0; i < buffer.length; ++i){
result+= (String.fromCharCode(buffer[i]));
}
console.log(result);
6
If you want to modify code, then the only real option I know of is bak/smali, which apktool provides a helpful wrapper for.
If you merely want to understand the code, there's lots of options. For example, you could use Enjarify or dex2jar to translate it to a jar file and then use any Java bytecode tools or decompilers. There's also a few decompilers with ...
6
To answer your question, let us first set a solid ground in terms of entities and definitions.
ELF stands for "Executable and Linkable format".
That is, it defines the structure and shape of two types of files:
Executables (Shared Objects *.so and stand-alone executables)
Linkables (Object files *.o)
Let us focus on executables.
Dependencies resolution ...
Only top voted, non community-wiki answers of a minimum length are eligible