Comment by grishka | Hacker News Reader

Comment by grishka | Hacker News Reader

Parent Full thread

It would've probably been much less ugly if the author reverse engineered one of the mobile apps instead of the web version. Those must use a much saner API that actually feels like an API.

I myself reverse engineered and patched Instagram for Android once because I got fed up with ads in my feed, but there's a high probability that all Facebook apps use the same "proxygen" HTTP client library. This library is notable because it is written in C++, thus requiring JNI bindings on Android, and that part can't be obfuscated — so, easy to find and fully stable across versions.

So I just added some calls into my own code (java source -> javac -> dx -> baksmali -> copied to "classes" in apktool project directory) in the bytecode of those JNI bindings and started logging requests to see how the ads are returned. I then built a response rewriter to remove the ads. If you have a spare Android device, you could even avoid messing with the app entirely by injecting your own code into the unmodified app using Xposed Framework. Xposed is very underrated as a reverse engineering tool.

> Xposed is very underrated as a reverse engineering tool.

I fully agree, but on the off chance you don't know about it already, I highly suggest you look into Frida as well. It can do all the same things Xposed can (hook function, see or change output), but is a lot faster to iterate on since you don't need to compile anything and can even do some things in a REPL.

That, coupled with the new jadx-gui's "copy as frida/xposed" snippet and the usual suspects for network monitoring (mitmproxy/charles), is a crazy powerful Android reverse engineering workflow.

I heard about Frida but never tried it myself yet.

The thing with Xposed that makes iteration slow isn't even the fact that you need to compile your module. That part is fast. You also need to reboot the device to apply your changes, that's the slowest part.

I know Kotlin and Java. Can you point me to any resources on this?

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.

Sounds like app "Instander"

Reply on news.ycombinator.com