Tool
DexKit
C++ DEX parsing library with Kotlin and Java APIs that loads an APK, DEX bytes or an app’s class loader and finds classes, methods and fields by their characteristics rather than their obfuscated names. Matchers combine package scope, modifiers and raw access flags, field, parameter and return types, annotations, the strings and numeric constants a method uses and the methods it calls, while batch queries locate many targets from strings at once; results expose opcodes, callers, invoked methods and fields used. Its guides centre on keeping Xposed hook points working across obfuscated app versions, and the same queries serve as a fast, scriptable search over an app’s bytecode.
- Targets
- App
- Category
- Android tools
- Relationship
- Foundation tool
- Sources reviewed
Requirements & limits
- Latest release at review: 2.3.0, published 2026-09-22 with no attached files, which added numeric-literal reading and raw DEX access-flag matching and optimized caching and string queries. The reviewed master commit of 2026-10-10 is two core fixes ahead of that tag. Packages are published on Maven Central as org.luckypray:dexkit; the artifact ID changed from DexKit with 2.0.
- Android projects need JDK 11+, Kotlin 1.5+, AGP 4.2+ and minSdkVersion 21+, with 23+ recommended because libdexkit.so may not load from compressed APK libraries on older settings. Since 1.1.0 it also runs on Windows, Linux and macOS from a source checkout built with gcc or clang, CMake and Ninja or Make, using MSYS2 on Windows, and CI builds the native libraries on all three. The APK, DEX data or class loader to query comes from the user; the repository’s only app is its own demo.
- The guides present DexKit as a tool for Xposed module developers, and the README examples run inside an Xposed hook; this record covers its querying and inspection of DEX code. Matches depend on the conditions the user writes, so they identify candidate classes and members rather than recover original names. Unit tests with smali fixtures are in the repository, but the reviewed workflows only build the native libraries and packages, and this review built and ran nothing.
- Everything outside Core/ is Apache-2.0, while the native code in Core/ is LGPL-3.0, although the README’s license badge links only to the LGPL. The README credits AOSP’s slicer, ThreadPool and parallel-hashmap as third-party sources. Apps analysed with it keep their own terms, and the reviewed sources establish no REA connection.
About this entry
The description was reviewed against primary sources. This does not establish runtime testing, security auditing or verified compatibility.
Primary sources
- README.md GitHub · LuckyPray/DexKit · Revision f86a036
- doc-source/src/en/guide/home.md GitHub · LuckyPray/DexKit · Revision f86a036
- doc-source/src/en/guide/quick-start.md GitHub · LuckyPray/DexKit · Revision f86a036
- doc-source/src/en/guide/run-on-desktop.md GitHub · LuckyPray/DexKit · Revision f86a036
- dexkit/src/main/java/org/luckypray/dexkit/DexKitBridge.kt GitHub · LuckyPray/DexKit · Revision f86a036
- .github/workflows/build-native.yml GitHub · LuckyPray/DexKit · Revision f86a036
- dexkit/src/test GitHub · LuckyPray/DexKit · Revision f86a036
- LICENSE GitHub · LuckyPray/DexKit · Revision f86a036
- Core/LICENSE GitHub · LuckyPray/DexKit · Revision f86a036
- https://github.com/LuckyPray/DexKit/releases/tag/2.3.0
More in Apps
- Aegis: trace a login-code calculation · Case study
- Notion: trace the clipboard bridge · Case study
- PicoPrint: LX-D02 printer investigation · Case study
- ReaCut: video-editor reconstruction · Case study
- CF632BLE: a local client from scale-protocol research · Case study
- zee-rp: reconstructing supported Axure RP 11 document operations · Case study