Ever shipped an Android app… then watched someone crack open your APK, skim your “secret sauce” in a decompiler, and toss it into a Telegram channel like it’s nothing? Yeah. Been there. That sting is exactly why I made Dex2C Tool.

The idea is simple: take selected logic out of DEX and push it into native code, right from your phone. No laptop.Yet wrestling with local SDK installs. Just you, an APK, and very specific parts of your app getting a lot harder to casually read.

Dex2C Tool is an Android app runs a full DEX → native C/C++ pipeline on-device using an embedded Termux environment. You still get tight control over what you protect, instead of doing the classic “protect everything and pray” move.

Key takeaways

Dex2C Tool converts chosen DEX methods into native C/C++, then compiles them with the Android NDK to make static analysis more annoying and expensive.
It’s built on the open-source dex2c and dcc engines. Think method-based AOT compilation.
Protection scope is controlled through whitelist and blacklist filters using regex-style rules, not an all-or-nothing switch.
The app automates the annoying stuff: toolchain setup, compilation, rebuild, and re-signing.
This is hardening, not wizardry. A motivated reverse engineer can still recover behavior, and sometimes even reconstruct smali.

What Dex2C Tool is… and what it isn’t

At a high level, Dex2C Tool converts DEX bytecode into native C/C++ to provide binary-level protection against reverse engineering. That’s the same way I describe it in the repo. It’s meant for developers who want to slow down decompilation and make analysis more costly, especially around licensing checks, API-secret handling, anti-tamper logic, and proprietary algorithms.

What it isn’t:

Not a guarantee your logic can’t be reverse engineered.
Not a replacement for server-side enforcement. If you can move a decision to the server, do it.
Not a “one-click secure app.” It’s one tool inside a defense-in-depth plan.

How it works: DEX → C/C++ → NDK → JNI

Android app code ships as DEX bytecode inside the APK. AOSP describes .dex files as structured binary containers holding class definitions and associated data like strings, method IDs, class defs, and so on. And if you’ve ever wondered why parsing DEX goes from “fine” to “why is my brain melting” so fast… yep, LEB128 variable-length integer encoding is everywhere.

Official reference: Dalvik executable format docs
https://source.android.com/docs/core/runtime/dex-format

Under the hood, Dex2C is a method-based AOT compiler. It can wrap Dalvik bytecode with JNI native code and translate it into C/C++. The upstream project is pretty explicit about this. It’s also inspired by amimo/dcc, and it automates processes that were manual in the original DCC.

Sources. Https://github.com/codehasan/dex2c
https://github.com/amimo/dcc

In real life, the flow is basically:

Pick targets using filter rules, methods, classes, packages, whatever you’re aiming at.
Translate those selected DEX methods into C/C++.
Build a native library using the Android NDK.
Patch the app so the original method body becomes a JNI call into the native library.
Rebuild and re-sign the APK so it installs normally.

The Dex2C blog claims this can “completely eliminate Java bytecode for protected methods” and compile native output with LLVM optimizations, depending on toolchain and build choices.
Source: https://dex2c.com/blog/how-dex2c-converts-java-to-native-cpp

A quick CLI mental model, even if you live in the GUI

Even though Dex2C Tool is GUI-first, I still keep the upstream CLI shape in my head. With dex2c, “protect an APK” looks like:

python3 dcc.py -a input.apk -o output.Yet

Source: https://github.com/codehasan/dex2c

That one line quietly implies a whole parade of work: decode APK, transform DEX, build NDK project, package, align, sign. My app is basically a phone-friendly wrapper around pipeline, plus actual UX for targeting and options.

Features I built on top of dex2c/dcc

From the README and the v1.0.0 release notes, here’s what I focused on:

On-device pipeline using embedded Termux, so setup, compilation, and re-signing happen inside the app.
An APK browser parses an APK and lets you browse packages, classes, methods in a trie-like structure.
A filter rule builder to craft whitelist and blacklist rules so you can scope protection precisely.
Advanced build options, including string obfuscation, dynamic JNI registration, skipping synthetic methods, custom loaders, and archives or “no signing” debug paths.
A resource monitor showing CPU, RAM, and disk usage while a protection run is happening.
History tracking with logs: what was protected, how long it took, terminal output.
Remote configuration for feature flags, version management, announcements, maintenance mode, rate limiting, a kill switch, and integrity checks.

Sources.
Repo. Https.//github.com/springmusk026/Dex2C-Tool/
Release notes: https://github.com/springmusk026/Dex2C-Tool/releases/tag/1.0.0

Using Dex2C Tool: filters and a realistic workflow

Start small. Seriously. Protect one package, make sure it still behaves, then expand. I’ve learned the hard way that “go big on the first run” is how you end up spending your weekend staring at logs.

A practical workflow I recommend:

Load the APK into Dex2C Tool.
Use the APK browser to find high-value code, licensing checks, crypto wrappers, request signing.
Add whitelist rules for only those packages or methods.
Run protection with conservative options first. Skip the heavy obfuscation at the start.
Install and smoke test. Startup, login, payments, deep links, background jobs. The stuff breaks in weird ways.
Then turn on extra hardening options once you trust the baseline.

Filter rules in Dex2C Tool, same concept as upstream dex2c

Upstream dex2c uses regex-like rules to match class paths and methods. A leading ! means blacklist. Straight from dex2c docs:

# protect all methods under a package
com/some/package/.*;.*

# blacklist a specific method
!com/some/class.some_methodreturn_type

Source: https://github.com/codehasan/dex2c

That “protect a little, blacklist exceptions” rhythm is basically the only sane way to keep build times and risk from going off the rails.

Termux + NDK setup: what the tool hides for you

One reason I went PC-free is simple: toolchain setup is where people bail.

Upstream dex2c expects Python 3.8+, apktool, an NDK path, and platform tools like zipalign and a JDK depending on where you run it.
Source: https://github.com/codehasan/dex2c

On Termux, setup scripts usually install packages, fetch an NDK build, and wire apktool into the right spot.
Source: https://gist.github.com/AbhiTheModder/1b9ace3d565c6a752ad7b15081a83413

Dex2C Tool automates that bootstrapping. The repo lists requirements:

Android 7.0, API 24+
Around ~500 MB storage for toolchain pieces like Python, NDK, dependencies

Source: https://github.com/springmusk026/Dex2C-Tool/

Signing matters, and it’s easy to mess up

When you rebuild an APK, you sign it again. And there’s a classic footgun: if you align after signing, you break the signature. Painful lesson.

Android’s docs are clear. zipalign before signing, because any changes after signing invalidate the signature.
Reference: https://developer.android.com/tools/apksigner

Dex2C Tool handles the rebuild → align → sign ordering automatically. Still, it’s worth knowing why a tiny “harmless” change can make installs fail.

Limitations and threat model

Two realities you should keep in your head while using this.

1) Large APKs can hurt

There’s a known issue documented. large APKs with high class counts may crash during analysis or protection due to memory pressure and deep traversal. Workarounds are tighter filter rules and splitting runs into smaller chunks.
Source: https://github.com/springmusk026/Dex2C-Tool/

2) Native doesn’t mean “unrecoverable”

A determined reverse engineer can still step through native code, hook JNI, dump memory, or reconstruct logic from behavior. There’s even content showing attempts to “recover smali from native” after Dex2C-style protection.
Source: https://www.youtube.com/watch?v=DcArD4SPBAU

So I treat Dex2C Tool as a way to raise the cost of static analysis, reduce clean Java decompile visibility for selected methods, and buy time. Sometimes buying time is the whole game.

Closing thoughts

Dex2C Tool exists because I wanted practical DEX-to-native hardening runs on a phone, with targeting controls, build options, and a workflow that doesn’t demand a full desktop setup. Under the hood it leans on solid open-source work from dex2c and dcc, then focuses on usability: browsing APK structure, building filters, and automating the build and signing pipeline.

If you try it, start with one small package, keep filters tight, and test like you don’t trust your own tooling. Because… you shouldn’t. And if you hit edge cases, especially large APK crashes, drop an issue with logs.

Sources

springmusk026, Dex2C-Tool repository README. Https.//github.com/springmusk026/Dex2C-Tool/
springmusk026, Dex2C Tool v1.0.0 release notes. Https.//github.com/springmusk026/Dex2C-Tool/releases/tag/1.0.0
codehasan, dex2c (AOT compiler. Filters, usage, installation notes). Https.//github.com/codehasan/dex2c
amimo, dcc (Dex-to-C Compiler). Https.//github.com/amimo/dcc
AOSP, Dalvik executable (DEX) format documentation. Https.//source.android.com/docs/core/runtime/dex-format
Android Developers, apksigner documentation. Https.//developer.android.com/tools/apksigner
AbhiTheModder, Setup Dex2C Termux (installation gist). Https.//gist.github.com/AbhiTheModder/1b9ace3d565c6a752ad7b15081a83413
Dex2C Blog, How Dex2C Converts Java to Native C++ (technical deep dive). Https.//dex2c.com/blog/how-dex2c-converts-java-to-native-cpp
YouTube, Reverse Engineering Dex2C || Recovering smali from native: https://www.youtube.com/watch?v=DcArD4SPBAU

Basanta Sapkota

i made Dex2C Tool: on-device DEX-to-C++ protection