Hot answers tagged

24

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


17

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


11

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


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


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


7

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

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


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


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


5

Here's how I would approach it. Which isn't necessarily the best approach. The first step is to find out what kind of obfuscation the app is using by looking around with your favorite decompiler. Most apps actually aren't obfuscated, or only have name obfuscation. If the names are obfuscated, it will still be annoying to RE, but the code is at least intact. ...


5

Without the proguard mapping, this is not possible. That information is simply no longer contained in the dex file. The best you could do would be to manually rename the methods, etc. with your own names.


4

I think the solution is a very simple one, with one small tweak. To decrypt the file, XOR the encrypted data with the bytes 0xFCC6DC7FDCC7DFE0 and you will get the unencrypted file. You can see this pattern by looking at the encrypted file and a valid dll. You can see a repeating pattern that is easy to pick out if you find areas that are supposed to be ...


4

You can't debug an apk on a user build of Android, unless the app has the android:debuggable="true" attribute in the manifest However, if you have a phone you can flash, you can flash a version of Android that allows debugging of any app. userdebug builds allow this, for example. I believe it's the "ro.debuggable" system attribute that controls this. ...


4

On desktop You can try Antimony's answer. Also check this comment(which states using dex2jar on .dex file and JD-GUI on jar file): If you want to decompile an apk directly on your phone, show java can be a good option. You can just select an apk file and wait. Then you can get rhe java source code of the app. Though it has much rooms for improvement, its ...


4

Disclaimer: I took a different approach to find your solution. I don't use Fiddler, it has many adwares. You may use Fiddler and may find same result as I did. Does anyone know how to unpack/decrypt APK file downloaded by modern Google Play Store version? No, Google doesn't encrypt the APK, at least I didn't found it to be encrypted. First install ...


3

Run apktool on the APK. I got a few XML files, including the AndroidManifest, but no source. Apparently this is because there is no classes.dex in the package. That's because these are odexed apps: when an app is odexed, the classes.dex is extracted from the apk. I tried an earlier version of baksmali 2.0.8 which doesn't have the limitation, but I ...


3

The first 16 bytes are unknown (likely some kind of private data). After that, a regular PNG file follows, but the first 128 bytes have been XORed with the value 234. The rest of the file is unchanged. My reason for suspecting a simple XOR was the series of 0xEA bytes near the start; typically there would be zeroes there. Applying the XOR in a hex viewer ...


3

We are using a C library in our application, however. We are using a .so file of this library compiled for the ARM architecture. We use the SWIG interface from our application's main Java code to interact with this library. I am wondering if I can store the private keys in this library's source code and then access these keys via SWIG binding functions. I'm ...


3

Hiding the keys anywhere in the apk (including .so files) is definitely not enough to keep the keys secret for the long time. The code that can be executed definitely can be reverse engineered, and the key could be extracted - even without having fancy decompiler and knowing ARM architecture well (by the way, there is a non-commercial decompiler for arm32). ...


3

If the API key is a string then just running strings would reveal it w/o grep as you do in your example. There might be some other strings but longer ones seems to stand out so it should be clearly visible that this is something meaningful. Having that API key I would probably go and use regular disassembler tools to see where and how it is used. You can't ...


3

The encryption key is stored in the variable f4800b. It comes out to the following byte array. 43, 57, 97, -68, -63, -61, -40, 9, 50, 87, -104, 101, 63, 34, -78, 60 The cipher algorithm used is Triple-DES in ECB mode. It can be decrypted by the following snippet. Note that it requires the BouncyCastle Crypto provider for Java. import java.security.*; ...


2

After playing with smali/baksmali I got it working. I think you didn't use the recursive flag when zipping. This caused the res folder to be empty which caused the crash. Also I run zipalign after signing the apk. Steps: Unzip $ unzip test.apk Baksmali $ baksmali classes.dex -o smaliClasses Smali $ smali smaliClasses -o classes.dex Zip -r $ zip -r test.apk ...


2

(Copy of an answer I gave on Stack Overflow) You could try injecting code into the Android app to sniff and dump SSL traffic. Take a look at https://github.com/5alt/ssl_logger (5alt's fork works with Android). Note that you need root for this. This works by hooking functions inside OpenSSL so that the raw traffic can be dumped before encryption/after ...


2

iSEC Partner's Android SSL TrustKiller utilizes hooks that Cydia substrate can provide in order to defeat certificate pinning.


2

I believe most versions of dalvik and art will reject the dex file and refuse to load it.


2

No, native code isn't in classes.dex. If an android apk file has native code, the apk itself, when unzipping, should have a lib subdirectory, which may have architecture-dependent subdirectories armeabi. armeabi-v7a. x86 and possibly others, and those will contain the native code objects. Sometimes, shared objects may be in other directories as well, ...


2

Use apktool to disassemble it into smali, edit the smali, then reassemble with apktool. I've done it tons of times, and it's easy. You could also manually edit the dex file in simple cases, but this is a HUGE pain. I generally only resort to it in cases where smali itself can't handle something properly. Note that dex files are much harder to manually edit ...


2

If I understand your question correctly, you want to change the parameter, v, inside the inner function. Right? If that's the case, you would already have access to the v argument inside your inner function. So what you can do is something like this: Java.perform(function () { // Function to hook is defined here var SpeedometerView = Java.use('adL'); // ...


2

There could be multiple reasons for such a behavior to occur. Without more thorough investigation on your end and a more detailed description it's impossible to provide a good answer. Please take the Tour to learn how good questions are structured. However, what you're experiencing could be some kind of anti-patching protection, and the network related ...


Only top voted, non community-wiki answers of a minimum length are eligible