Apktool VS jadx

App tampering and repackaging can be performed by using reverse engineering or tampering tools, such as Apktool, dex2jar, etc.

Apktool made by iBotPeaches, this uses v2.9.1

Can someone clarify what "PP tools" are, and provide a link to them? I came across this link (https://apktool.org/) but I'm not sure if it's the right tool.

Apktool is all you need most of the time.

But it'll still be editable and we can make something good out of it. One of the famous ones, that I'm planning to use is ApkTool(https://ibotpeaches.github.io/Apktool/).

I did a dissection of twitter apk (got from apk pure) with apktool, and I found permission :

Not sure. I started reverse engineering Java apps very early in my life — initially it was J2ME games. Decompilers of the time sucked but that didn't stop me from modding Gravity Defied :P

I honestly don't know what's a good way of getting started on reverse engineering. There's a bunch of everything about Windows executables in particular, including "crackmes", but native machine code is a level up from JVM bytecode. Java classes and Android dex files can be decompiled back to sensible source with a good chance that you get something that can be compiled again. No such luck for native code — C/C++ compilation is a lossy process by its nature, especially the optimizations. Ghidra does a decent job but still requires a non-zero amount of manual assistance. Flash games also were good to hone one's reverse engineering skills since ActionScript decompilers did a pretty darn good job.

Anyway. To decompile dex to Java source, there's jadx: https://github.com/skylot/jadx

Since decompilation is sometimes lossy, there's apktool for when you want to put the app back together after tinkering with it: https://github.com/iBotPeaches/Apktool

It goes without saying that you also need a JDK and the Android SDK. In particular, you need apksigner form the SDK to sign the unsigned apks generated by apktool. You can also automate things a bit and use adb to deploy them to your device.

What I usually do is get a high-level overview of the app in jadx, and then modify the smali (dalvik bytecode in text form, very assembly-like) files generated by apktool.

I am not game or android app dev, but you might first need to de-compile apk using tools like https://ibotpeaches.github.io/Apktool/

Suspicious of the request, our colleague forwarded the APK to me, knowing my expertise in software development and cybersecurity. My investigation began by downloading and extracting the contents of the APK. Inside, I found several dex files, which I knew contained the app's compiled source code. Using a tool called jadx, (jadx -d extractedapkfile) I decompiled the APK to inspect its source code.

The best way is to just start practicing. I would say pick some simple apps on your (Android) phone and dig straight in.

The great thing about Android applications is that often they generally decompile quite nice into human readable Java soo the barrier of entry can be quite low to start reversing.

Grab a copy of JADX[1] - it will decompress and decompile the APK files. If you don't have an Android handset, use an emulator and/or grab APKs from apkpure[2]

Dynamic analysis is a bit more challenging. In my blog post I use Frida[3] extensively.

If you get started on something and get stuck/looking for support, feel free to DM me on Twitter[4], more then happy to help.

[1] https://github.com/skylot/jadx

[2] https://frida.re/docs/android/

[3] https://m.apkpure.com/

[4] https://twitter.com/haxrob

This may be overkill but you can use an oscilloscope to manually calculate the baudrate, i.e. like this. It looks like it could be UART serial data, but this is a good resource to reference. Sometimes http is used as a means for communicating, and not necessarily directly to a browser see here. This is pretty common in embedded applications actually. You can try using dirbuster to see what hidden endpoints there are that may be used for video. If there's an RC, you can try and do what you were doing before on the drone for that (see what dmesg says when plugged in, check any open ports, etc). If it's a phone you connect to, you can RE the mobile app. I like using jadx for APKs to get a lay of the land. If you don't want to pop the SPI flash like i suggested earlier (and I suggest don't do that except for last resort), you can grep for firmware urls in the mobile app to see if it does OTA updates, and see if you can directly download it and analyze it with a disassembler like Ghidra. Since it's WiFi, you can also MiTM the traffic from an AP you control like your computer. I'm guessing video is probably going to be something like RTSP at an IP address, so you can grep in the mobile app for that, and that might be good enough to get your video feed honestly.

Jadx - skylot/jadx: Dex to Java decompiler (github.com) - Used for decompiling the apk - make the code readable

I realized when app is decompiled using JADX class names are recreated as shown in this screenshot of sample app

Not sure. I started reverse engineering Java apps very early in my life — initially it was J2ME games. Decompilers of the time sucked but that didn't stop me from modding Gravity Defied :P

I honestly don't know what's a good way of getting started on reverse engineering. There's a bunch of everything about Windows executables in particular, including "crackmes", but native machine code is a level up from JVM bytecode. Java classes and Android dex files can be decompiled back to sensible source with a good chance that you get something that can be compiled again. No such luck for native code — C/C++ compilation is a lossy process by its nature, especially the optimizations. Ghidra does a decent job but still requires a non-zero amount of manual assistance. Flash games also were good to hone one's reverse engineering skills since ActionScript decompilers did a pretty darn good job.

Anyway. To decompile dex to Java source, there's jadx: https://github.com/skylot/jadx

Since decompilation is sometimes lossy, there's apktool for when you want to put the app back together after tinkering with it: https://github.com/iBotPeaches/Apktool

It goes without saying that you also need a JDK and the Android SDK. In particular, you need apksigner form the SDK to sign the unsigned apks generated by apktool. You can also automate things a bit and use adb to deploy them to your device.

What I usually do is get a high-level overview of the app in jadx, and then modify the smali (dalvik bytecode in text form, very assembly-like) files generated by apktool.

A week ago I purchased a bluetooth device that takes some measurements. You require an Android or iOS application. The first thing the iOS app did was request permission for your location. Immediate fired up MITMproxy [1] running in transparent `--mode wireguard` and installed it's certificate in the iOS trust store. It was sending a whole bunch of data to China and HK. Since I don't have a jailbroken iPhone, it's off to Android.

For BLE scanning, Android does require permissions for location, but this application is using a Chinese branded tracking SDK and sending encrypted (within already encrypted TLS). So it's time to start reversing and instrumenting the runtime.

Well - not so easy, they used a commercial packer that encrypts their compiled bytecode and decrypts and runs it within a C++ library. I managed to bull the Dalvik out of memory using Frida[2], covert it to java bytecode with dex2jar[3] then into decompiled java with jadx [3].

Since the developer relied on the packer to hide/obfuscate their software, it's quite easy to follow. The libraries that do the location tracking on the otherhand are obfuscated so now I'm at the stage of identifying where to hook before the encrypted blobs are sent to servers in China.

I've sunk about 8 hours into this so far. The message here is that to understand what some applications on your phone does you need to really invest time and effort. The developers increase the cost to the consumer to know what their application is doing by obfuscation, encryption and packing. It's asymmetric.

[1] https://mitmproxy.org/posts/wireguard-mode/

[2] https://frida.re/docs/android/

[3] https://github.com/skylot/jadx

[3] https://github.com/pxb1988/dex2jar

jadx: View the generated Java code for an app. This tool tries to recreate Java code from the smali bytecode, but keep in mind that sometimes it may not work because Java -> Smali conversion is not fully backwards compatible.