jadx VS Apktool

JADX - for discovering code in Java

> I remember something like dex2jar also, which gave you a jar you could use in any java decompiler, like jdgui, procyon etc.

https://github.com/skylot/jadx is very handy for that nowadays. It also supports interactive variable/method/class name renaming to make the decomplied code easier to read. The decompiler isn't perfect, but I guess all available Java decompilers have their limitations with more complex bytecode…

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.

I'd be curious if anyone has tried this for Android and what kind of stuff it's checking for. Sideloaded APKs can often contain malicious stuff, but it's nearly impossible to know if it's doing anything suspicious unless you open it up with a tool like Apktool [1] or run it on Triage [2] as it supports Android and watch what it's doing. Most antivirus for Android is pretty much a joke, as far as I'm concerned.

[1] https://github.com/iBotPeaches/Apktool?tab=readme-ov-file

[2] https://tria.ge/

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/