UglifyJS2 VS jadx

Minification involves removing unnecessary characters, whitespace, and comments from code files. It helps reduce HTML, CSS, JavaScript, etc., file sizes without compromising functionality. Removing redundant elements makes these HTML, JavaScript, and CSS files smaller. Since smaller code files need less internet traffic to transfer, they load faster. Utilizing tools like UglifyJS, Clean-CSS, and HTMLMinifier enhances this process of code reduction. They analyze the code, remove redundant code, and generate optimized files for deployment.

Example: You've got a main.js file that's as long as a Tolstoy novel. Fix: Use tools like UglifyJS or Terser to minify your code. They'll squeeze out all the unnecessary bits and give you a sleeker, faster-loading file.

Minification: UglifyJS, Terser

There are a bunch of libraries that do this, but my current go to is Uglify: https://www.npmjs.com/package/uglify-js

There are many minifiers such as terser and uglify. But, because minifying also require to parse the JS, it is actually possible to use esbuild and SWC to minify the code. Here's a benchmark of the main minifiers.

In my understanding, UglifyJS 3 is the most popular JavaScript minifier tool presently -- it has a very high weekly download too. And as per the official documentation, it supports ES6.

I'm thinking reverse-engineered uglified js code (https://github.com/mishoo/UglifyJS) is not as impenetrable as code from reversed engineered wasm binaries? The element of plausible deniability is much more potent though, for the nefarious actor on the other side.

Program: uglifyjs Arguments: $FileName$ -c -m -o $FileNameWithoutExtension$.min.js

Apart from terser, you can also use uglify-js to compress or minify javascript.

Uglify

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.

If you haven't tried Jadx [1], give it a shot. It's by far the easiest way to reverse Android APKs. I doesn't do patching or reassembly, but I used it for reversing the Delong'hi APK for longshot [2][3] and the quality of output was fantastic.

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

[2] https://github.com/mmastrac/longshot

[3] https://grack.com/blog/2022/12/02/hacking-bluetooth-to-brew-...

Smali is a low level language for Dalvik bytecode and it can be quite a headache to interpret it correctly and achieve what you want. That's why I recommend another tool called jadx which can mostly recover Java code from a dex file, but unfortunately the conversion is not 100% possible. Also, editing is not possible with jadx.