Daniel sent us this one — he wants to talk about the foundational tools and programs for software reverse engineering, specifically for bundled Android APKs when you're building unofficial integrations. He's asking about the popular tools, the security ramifications, and where the ethical boundaries actually sit. And look, I think the thing that makes this worth digging into right now is that the battleground has shifted. Five years ago, reverse engineering an APK meant decompiling Java. Today, you unpack a modern app and you're staring at a fifty-megabyte native library with no symbols and three layers of obfuscation. The old playbook doesn't work anymore.
That shift is the whole story. I pulled apart a rideshare app last month just to see how it structures its API calls, and the Java layer was essentially a hollow shell — maybe twelve classes, all of them thin wrappers that hand off to a single monolithic dot so file. The real logic lives in ARM64 instructions now, and that changes everything about the toolchain you need. So what Daniel's asking lands at exactly the right moment.
What does that stack actually look like? Let's break down the three layers you'll encounter.
Layer one is the APK itself — which is just a zip file. You rename the extension, unzip it, and you've got the manifest, resources, and a classes dot dex file. That's the easy part. Layer two is what's inside that dex — and this is where people get tripped up by the biggest misconception in this space. Decompiling does not give you original source code. You get functionally equivalent bytecode with all the variable names stripped out, control flow potentially restructured by ProGuard or R8, and if the developer used something like DexGuard, entire methods might be replaced with intentionally misleading logic. I've seen decompiled methods that decompile to a switch statement with forty-seven cases, nine of which actually do anything, and the rest are dead branches designed to exhaust a human analyst.
It's less like peeling the label off a bottle and more like receiving a transcript of a conversation where someone's shuffled all the sentences and replaced every noun with a serial number.
That's exactly the image. And layer three is where it gets genuinely difficult — native code compiled to ARM64 shared objects. React Native bundles its JavaScript engine into a dot so file. Flutter compiles Dart to native. Unity games ship entire C-sharp runtimes as native libraries. The tool that handles this layer is Ghidra, which the NSA released as open source in March twenty nineteen under the Apache two point oh license. And I have to say, for something the National Security Agency built for internal use and then decided to share with the world, it's remarkably approachable.
The NSA's reverse engineering framework. Released to the public. Under Apache two point oh.
And here's why it matters for what Daniel's asking about. When you load a dot so file into Ghidra, it disassembles the ARM64 instructions and then lifts them into an intermediate representation called P-code. From there, it produces a pseudo-C decompilation. It's not the original C or C-plus-plus — variable names are gone, replaced with labels like local underscore c8 — but the control flow is readable. The real trick is using Ghidra's Symbol Tree to find JNI functions. Those are the bridge points between Java and native code, and they follow a predictable naming convention — Java underscore package underscore class underscore method. Even with obfuscation, those symbol names often survive because the JNI specification requires them to be exported. So your entry point into a fifty-megabyte binary is often right there in the symbol tree, plainly labeled.
Even when everything else is scrambled, the handshake between Java and native code leaves fingerprints.
And once you've found a JNI function — say, one that takes a string and returns a string — you can trace backward through the decompiled code looking for string constants. API base URLs, endpoint paths, parameter names. They have to exist somewhere in the binary, and Ghidra's string search across the whole program is how you find them. I once spent four hours tracing a banking app's native library only to find the entire API base URL sitting in a string table in plain text, three megabytes from where I started looking.
Four hours to find an unencrypted string in a string table. That's the glamour of reverse engineering.
That's the job. But let me pull us into the second major tool, because Ghidra is static analysis — you're reading the code without running it. The other half of the equation is dynamic analysis, and that's where Frida and Objection come in. Objection is a toolkit built on top of Frida, maintained by the team at SensePost, and it does something that still feels like magic to me. You connect it to a running app on a device — either rooted or using a Frida-injected patched APK — and you type "android sslpinning disable." And just like that, the app's certificate pinning is gone. You can intercept all its HTTPS traffic in Burp Suite or mitmproxy.
How does that actually work under the hood? Because "disable SSL pinning" sounds like it should require modifying the app's code on disk, and you're saying it doesn't.
It doesn't. This is the mechanism I find elegant. Frida uses a component called frida-gum, which is its inline hooking engine. When you tell Objection to disable SSL pinning, Frida locates the specific method in the running process's memory — typically something in the OkHttp or TrustManager chain — and overwrites the function prologue with a trampoline. That trampoline redirects execution to a small piece of JavaScript you've injected, which simply accepts any certificate and returns. The original bytes on disk are untouched. The APK's signature is unchanged. You're modifying the process's memory image while it's running.
You're not breaking into the house. You're intercepting the mail carrier and swapping the envelope while they're walking.
That's the image. And it's why dynamic analysis is so powerful for what Daniel's describing — building unofficial integrations. You don't need to fully understand the app's internal logic if you can observe what it actually sends over the wire. A simple Frida script that hooks something like okhttp3 dot Request dollar Builder dot url will log every URL the app constructs before it encrypts the connection. You get the full API surface just by watching the app use it.
Let me write that one down mentally. Hook the URL builder, not the network socket, and you catch the request before TLS wraps it.
And you can get more surgical. Say the app has a method that signs requests with an HMAC. You can hook that method, log its inputs and outputs, and now you know the signing algorithm without ever decompiling the native library that implements it. The method signature is your Rosetta Stone. This is the critical distinction between static and dynamic analysis — Ghidra tells you what the code says it does. Frida tells you what it actually does when it runs. Those are not always the same thing, especially with obfuscated control flow.
You've got the technical capability. Now comes the harder question: should you use it?
This is where I want to be careful, because the legal landscape is murky and I'm not a lawyer. But there are some landmarks worth knowing. The DMCA's anti-circumvention clause — section twelve oh one of title seventeen — prohibits bypassing technological protection measures that control access to copyrighted works. The question is whether SSL pinning counts as such a measure when your goal is interoperability. The Library of Congress renewed an exemption for software interoperability in October twenty twenty-four, which explicitly allows reverse engineering for the purpose of making software work with other software. That exemption covers a lot of what we're talking about.
Where's the line between "I'm making my own client talk to this service" and "I'm bypassing access controls"?
That line has been drawn and redrawn by courts, and the case worth knowing is HiQ Labs versus LinkedIn from the Ninth Circuit in twenty twenty-two. The court ruled that scraping publicly accessible data does not violate the Computer Fraud and Abuse Act. But — and this is the crucial but — the ruling explicitly does not cover bypassing technical barriers. If LinkedIn had required authentication and HiQ had circumvented it, the outcome would have been different. SSL pinning is arguably a technical barrier. So if you disable it to access an API that requires authentication, you're in legally grayer territory than if you're just observing traffic from an app you've already logged into.
The act of logging in with your own credentials might be the thing that keeps you on the right side of the line.
That's my read, and it's a principle I follow. I never send credentials I didn't legitimately obtain. I never escalate privileges. I only access endpoints that the official client accesses under normal operation. That's the distinction between reading the API contract and exploiting the API. Reading the contract means you understand what endpoints exist, what parameters they accept, and what responses they return — all things the official client does. Exploiting means you're sending crafted payloads the official client never sends, or accessing endpoints that are gated behind server-side checks the client doesn't normally trigger. The former is reverse engineering for integration. The latter is vulnerability research, and it carries different legal and ethical obligations.
If you stumble into a vulnerability while doing the former? You're tracing API calls and you find a hardcoded AWS secret key sitting in a string table?
Then you have a responsibility. I'm not saying you have a legal obligation — though in some jurisdictions you might — but ethically, you've just found a loaded weapon in someone else's house. Coordinated disclosure is the standard. You contact the company, give them a reasonable window to fix it, and you don't publish a proof of concept until they've patched. Publishing immediately for clout is how you burn goodwill and potentially face legal action. There's a reason most security researchers have a disclosure policy linked in their Twitter bio.
Let's map the spectrum here, because I think Daniel's question about ethical boundaries benefits from being concrete. You mentioned three zones.
Green zone — wrapping a public web interface that happens to be mobile-only. Instagram's private API is the classic example. Third-party scheduling tools have used it for years. The data is yours, you're authenticated with your own account, and you're automating actions you could perform manually. The ToS might technically prohibit it, but enforcement is rare and the legal exposure is low.
Reversing an app that explicitly bans automation and actively detects unauthorized clients. Snapchat is the poster child here. Their client sends device fingerprints, request timing signatures, and a cascade of integrity checks. If you build a third-party client that trips their detection, they will ban your account and potentially send a cease and desist. The legal exposure is real but usually civil, not criminal. You're violating a contract, not a statute — assuming you haven't bypassed DRM.
The red zone.
Extracting cryptographic keys, bypassing rate limiting, or accessing data that belongs to other users. This crosses from "I'm building an alternative client" into "I'm compromising the service's security model." If you extract an API key that the app uses to authenticate to its own backend and then use that key to make requests the app wouldn't make, you're not integrating — you're impersonating. That's Computer Fraud and Abuse Act territory, and people have gone to prison for it.
That's a useful map. Green is "I'm automating myself." Yellow is "the service doesn't want me here but I'm not breaking anything." Red is "I'm pretending to be something I'm not.
The thing about the yellow zone is that it's where most of the interesting unofficial integrations live. The Twitter API price hike in twenty twenty-three killed off most third-party clients, and within weeks, developers had reversed the mobile API and built new clients that worked. Almost all of them received cease and desist letters within a month. Contrast that with Signal — their terms of service explicitly allow third-party clients, and there's a whole ecosystem of unofficial desktop clients that have operated for years without legal friction. The difference isn't technical capability. It's permission.
The ethical boundary isn't really about what you can do. It's about whether the service provider has drawn a line and whether you're respecting it.
Whether you're transparent about what you're doing. I keep a log of every app I reverse, what I was looking for, and what I found. If I'm building an integration, I document that I only accessed data the official client accesses under normal use. That log is my first line of defense if I ever get a legal inquiry. It shows good faith — that I was doing interoperability work, not probing for vulnerabilities to exploit.
That's the kind of practical hygiene that never makes it into the tutorials. "Keep a log" doesn't sound exciting, but it's probably the most important thing you said in the last five minutes.
It's the least glamorous advice and the most protective. Alright, let me pull us back to the technical side, because I want to talk about a case study that illustrates why the toolchain matters. There's a banking app I looked at — and I'm going to keep the name out of this — that uses Obfuscator-LLVM to protect its native code. Obfuscator-LLVM, or O-LLVM, is a compiler extension that applies transformations at the LLVM intermediate representation level. It flattens control flow, substitutes instructions with functionally equivalent but harder-to-read sequences, and inserts bogus control flow that never executes. The result is a binary where every function looks like spaghetti.
Ghidra can still chew through that?
It can, but you have to work differently. The decompiler recovers the control flow, but the variable names are meaningless, and the logic is spread across dozens of basic blocks connected by indirect jumps. You can't read it top to bottom. What you do instead is trace constants. You find a string reference — say, an API endpoint path — and you work backward through the cross-references to find every function that touches that string. Eventually you find the function that constructs the full URL, and from there you can trace the parameters that feed into it. It's archaeological. You're not reading code; you're excavating intent from the layers of obfuscation.
Archaeological reverse engineering. That's a good phrase for what this actually feels like.
It's why dynamic analysis is so complementary. I spent three hours in Ghidra tracing constants through that banking app's native library, and at the end I had a theory about how it constructed its authentication headers. I wrote a ten-line Frida script to hook the method I'd identified, ran the app, and within thirty seconds I could see the exact header value being passed to the HTTP client. The static analysis gave me the target. The dynamic analysis confirmed it. Neither alone would have been sufficient.
The workflow isn't "pick one tool." It's a pipeline, and skipping steps costs you time.
Let's turn all of that into a concrete workflow you can apply tonight. Step one — apktool d app dot apk. This unpacks the APK into smali code, resources, and the manifest. You can read the manifest to understand permissions, exported components, and any interesting intent filters. Step two — jadx-gui. Point it at the APK and it decompiles the dex bytecode into Java. This is where you'll spot the app's package structure and any unobfuscated class names. If the app uses React Native or Flutter, you'll see thin Java wrappers that load a native library — that's your signal to move to step three.
Step three is Ghidra.
Ghidra for the native libraries. Load every dot so file you find in the lib directory. Check the symbol tree for JNI exports. Run a string search for anything that looks like a URL, an API key, or a header name. Cross-reference those strings to find the functions that use them. Step four is where it gets interactive — Frida or Objection on a live device. Start with Objection's sslpinning disable so you can see the traffic. Then write a small Frida script to hook the method you identified in Ghidra. Log its arguments. Confirm your theory.
If you don't have a rooted device?
You can patch the APK to include the Frida gadget. Apktool unpacks it, you add the frida-gadget dot so to the lib directory, modify the manifest or a smali file to load it at startup, repack with apktool, and sign with a debug keystore. It's more work than just running Objection on a rooted phone, but it's doable. This is where our episode on rooting becomes relevant — having a dedicated test device with Magisk installed saves you hours of patching and repacking.
There's a whole community around this. You mentioned the REAndroid Telegram group.
REAndroid on Telegram is where the Objection maintainers and a lot of the Frida community post updates. The Mobile Reverse Engineering subreddit is also active. These are the places where new obfuscation bypasses get shared, and if you're serious about this, you want to be in those spaces. The tooling moves fast — a new version of an app might break your Frida script overnight, and someone in those groups has probably already figured out the fix.
There's an arms-race quality to this. Every app update is potentially a new obfuscation technique, and the tooling races to catch up.
That brings me to the forward-looking question I've been turning over. We're entering an era where AI-generated code is becoming common. On one hand, that could make reverse engineering harder — AI-written code is often weirdly structured in ways that don't match human patterns, which could function as obfuscation by default. On the other hand, AI is also getting better at decompilation and symbol recovery. There are already research projects using large language models to rename decompiled variables with semantically meaningful names — turning local underscore c8 into userAuthToken. If that matures, the bottleneck shifts from "can I read this code" to "do I have permission to use what I learn from it.
That's the interesting tension. The technical barrier drops, and the ethical and legal barriers become the real gatekeepers. Which is probably where they should have been all along.
On that note, if you want to try this yourself, start with something simple. A weather app with no obfuscation. Run the workflow — apktool, jadx, see if you can find its API endpoint. Don't publish a client. Don't distribute anything. Just prove to yourself that you can trace the data flow from button press to network request. That alone will teach you more than any tutorial.
Now: Hilbert's daily fun fact.
Hilbert: The Korean honorific suffix "nim" can be applied to inanimate objects in certain professional contexts, such as referring to a particularly important document as "munseo-nim" — a practice that linguists describe as grammatically elevating the object's social status through an optical metaphor of raising something into clearer view. During the Cold War, Soviet linguists studying Korean speech levels from listening posts in Kamchatka initially classified this usage as a transmission error, believing their equipment was mishearing the honorific particle.
...right.
Soviet linguists in Kamchatka thought their radios were broken because Korean speakers were being polite to paperwork.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop. If you enjoyed this episode, check out our episode on sideloading and the Play Integrity API — it covers what happens before you even get the APK onto your device. Find that and everything else at my weird prompts dot com. We'll be back soon.
