Reverse Engineering Android APKs: I Decompiled the White House App — Here's How [2026 Guide]

Somebody shipped a government app with a hardcoded API key and an Adobe analytics SDK that phones home user behavior. That somebody was the White House. When Android researcher Mishaal Rahman pulled apart the APK and published his findings, it kicked off a conversation about what reverse engineering Android apps can actually reveal — and why every security-conscious engineer should know how to do it.

I've been reverse engineering Android APKs on and off for over a decade, mostly to audit third-party SDKs our teams were considering integrating. The tools have gotten dramatically better. The apps have gotten dramatically worse. Here's how to do it yourself, using the White House app as a case study.

Why Reverse Engineering Android Apps Matters More Than Ever

Here's the uncomfortable truth about mobile apps in 2026: most of them are leaking data you never consented to share. According to research from the Synopsys Cybersecurity Research Center, 63% of mobile apps contain known security vulnerabilities, and a third of those are classified as critical. On the Android side specifically, the Statista Research Department found that 97.4% of all Android malware in Q1 2023 was classified as Trojans — apps that look legitimate on the surface but do something entirely different underneath.

Reverse engineering is how you find out what's really happening. It's not a fringe hacker skill. It's a core competency for anyone building or reviewing mobile software.

I've personally caught two third-party SDKs silently exfiltrating clipboard data during integration reviews. Both times, the vendor's documentation said nothing about it. The only way I found out was by decompiling the .aar and reading the actual code. If you're shipping mobile apps and not auditing your dependencies this way, you're trusting marketing materials over source code. That's a bad trade.

What Tools Do You Need to Reverse Engineer an APK?

The toolchain for reverse engineering Android apps has consolidated around a few excellent open-source projects. Here's what you actually need:

JADX is your starting point. It's a dex-to-Java decompiler with a clean GUI that lets you browse decompiled source code like you're reading a normal Android project. Point it at an APK file, and it reconstructs the Java (or Kotlin) source as closely as it can. For most analysis work — checking what SDKs are bundled, finding hardcoded secrets, understanding app architecture — JADX is all you need.

Ghidra is the heavy artillery. Developed by the NSA and released as open source, Ghidra is a full software reverse engineering framework that can analyze compiled native code. If the app you're investigating uses native libraries (.so files written in C or C++), JADX can't help you. Ghidra can disassemble and decompile those binaries. Steeper learning curve, but genuinely world-class software that costs nothing.

apktool handles the raw unpacking. It decodes the APK's resources, manifest, and smali (the human-readable form of Dalvik bytecode). You need it when you want to inspect the AndroidManifest.xml for permissions, intent filters, and service declarations.

You'll also want adb (Android Debug Bridge) for pulling APKs directly from devices, and optionally a service like APKMirror for downloading APKs of publicly available apps.

Four tools, all free, all open source. If you've built Android apps before — like I discussed in my review of Samsung DeX as a development environment — you probably already have adb set up.

How to Decompile an Android App Step by Step

Let me walk through the actual process, using the White House app analysis as a reference point.

Step 1: Obtain the APK. You can pull it from a physical device using adb shell pm list packages to find the package name, then adb pull to extract it. Alternatively, sites like APKMirror host verified copies of apps from the Play Store. For the White House app, the package was publicly available for download.

Step 2: Open it in JADX. Launch jadx-gui, open the APK file, and wait for the decompilation to finish. You'll see a familiar project structure: packages organized by namespace, resources, and the manifest. This is where the real investigation starts.

Step 3: Read the manifest first. The AndroidManifest.xml is your roadmap. It tells you every permission the app requests, every activity and service it declares, every broadcast receiver it listens for. If an app requests ACCESS_FINE_LOCATION but claims to be a news reader, that's your first red flag.

Step 4: Search for interesting strings. This is where hardcoded secrets live. Search across the decompiled source for patterns like api_key, secret, token, password, or specific domain names. In the White House app analysis, this is exactly how a hardcoded WordPress API key was discovered — just sitting there in the decompiled code. That particular key was for the public-facing WordPress REST API and wasn't a critical secret, but hardcoding any key is a signal of sloppy security hygiene.

Step 5: Identify third-party SDKs. Look at the package namespaces. When Mishaal Rahman, a well-known Android expert formerly of XDA Developers, analyzed the White House app through static analysis, he identified the Adobe Experience Manager SDK embedded in the application. That SDK includes analytics and tracking services — meaning the app was collecting behavioral data on users. Whether that's appropriate for a government app is a policy question. That it was discoverable through basic decompilation is just a fact.

The things you find in decompiled apps aren't bugs in your reverse engineering process. They're features the developers hoped you'd never look at.

Step 6: Analyze native libraries with Ghidra (if needed). If the app bundles .so files in its lib/ directory, those are compiled C/C++ libraries that JADX can't decompile. Open them in Ghidra for disassembly and analysis. This is common in apps that use custom encryption, DRM, or performance-critical code paths.

Can You Decompile an App That Uses ProGuard Obfuscation?

Yes, but it gets harder. ProGuard (and its successor R8) minifies and obfuscates Android bytecode by renaming classes, methods, and fields to meaningless single-letter identifiers. Instead of UserAuthenticationManager.validateToken(), you'll see a.b.c.a(). The logic is preserved, but readability is destroyed.

Here's the thing nobody tells you: obfuscation slows down analysis, but it doesn't stop it. The control flow is still there. String literals are often still readable. SDK package names from third-party libraries frequently survive obfuscation because the app needs to call them by their real names at runtime. In my experience, ProGuard buys maybe 2-3x more analysis time. It's not encryption. It's a speed bump.

Ghidra and JADX both handle obfuscated code reasonably well. JADX even has a deobfuscation mode that assigns more readable names based on usage patterns. If you're a defender wondering whether ProGuard is enough to protect your app's secrets: it is not. Never ship secrets in client-side code, obfuscated or otherwise.

This ties directly to something I wrote about when looking at how info-stealer malware extracts Chrome's saved passwords. Same pattern. If the secret has to be on the client to function, a sufficiently motivated attacker will find it.

Is It Legal to Reverse Engineer an Android App?

This is the question I get most often, and the answer is: it depends on your jurisdiction and your purpose, but in most cases, yes.

In the United States, the Computer Fraud and Abuse Act (CFAA) and the Digital Millennium Copyright Act (DMCA) are the relevant statutes. The DMCA includes exemptions for security research, and the Library of Congress has repeatedly renewed and expanded those exemptions. Reverse engineering for interoperability has legal protection under both US and EU law.

That said, I'm an engineer, not a lawyer. Here are the practical guidelines I follow:

• Don't redistribute the decompiled code or the original app
• Don't clone someone's product with what you find
• Follow responsible disclosure if you discover vulnerabilities. The Cybersecurity and Infrastructure Security Agency (CISA) defines this as reporting to the system owner and giving them time to fix things before you go public
• Document your intent. Security research is protected. Commercial theft is not.

For government apps specifically, there's a strong argument that citizens have a right to understand what software their government is deploying on their devices. The White House app analysis was a textbook case of responsible public interest research.

What's the Difference Between JADX and Ghidra?

This comes up constantly, and the answer is straightforward: they solve different problems.

JADX decompiles Dalvik bytecode (the Java/Kotlin layer of Android apps) back into readable Java source. It's fast, has a nice GUI, and for 90% of Android app analysis, it's the only tool you need. Purpose-built for Android.

Ghidra is a general-purpose reverse engineering framework that works on compiled binaries across dozens of architectures — x86, ARM, MIPS, you name it. For Android, you'd use Ghidra specifically to analyze native .so libraries that JADX can't touch. It also handles iOS binaries, desktop applications, firmware — essentially anything compiled.

Use JADX first. Reach for Ghidra when you hit native code or need deeper binary analysis. They complement each other well. This mirrors how security tools generally tend to layer — as I explored when looking at security risks with LLM agents getting OS-level control, the right tool always depends on what layer you're analyzing.

The Bigger Picture: Every App You Install Is Auditable

The White House app case study is interesting not because the findings were catastrophic. A public API key and an analytics SDK aren't exactly a data breach. It's interesting because it shows how trivially any Android app can be examined by anyone with free tools and a couple hours of patience.

If you're a defender, assume your app will be decompiled. Don't store secrets client-side. Use certificate pinning. Implement proper server-side authentication. Treat the APK as public source code, because functionally, it is.

If you're a researcher or a curious engineer, the barrier to entry for mobile security analysis has never been lower. JADX and Ghidra are free. The APKs are on your phone right now. The skills transfer directly to malware analysis, security auditing, and competitive intelligence.

After 14 years in this industry, I'm still surprised by what I find in production apps from companies that should know better. The White House app was the one that made headlines, but I promise you — the app from your bank, your health insurer, your kid's school — they're all just as inspectable. The question isn't whether someone will look. It's whether you've built your app assuming they will.

---

Originally published on kunalganglani.com