XAPKDetector: identifying build tools and protectors in Android packages

What the tool actually reports

XAPKDetector is described as an Android, APK and DEX detector for Windows, Linux and macOS, and the second line of the description is the one that defines its output: it shows information about build tools, libraries and protection of APK and DEX files.

That is a narrower job than a scanner's reputation suggests. It is not looking for known bad signatures to produce a detection verdict, it is inventorying the toolkit that produced or protected a package. Which build system compiled it, which libraries are linked in, whether a commercial protector or an obfuscator wrapped the code, that is the output.

For an analyst this is the first triage step rather than the last one. Knowing that a sample is packed with a specific protector tells you which unpacking route to take, and knowing a build tool tells you the shape of the bytecode you are about to read. The repository's own topics list names the field plainly: android, apk, apk-parser, apktools, malware-analysis, malware-detection, malware-research and reverse-engineering, along with hacktoberfest entries from 2023.

The top-level directory list tells its own story about the codebase the tool is built from. That list is long, and it is the clearest evidence of what this tool grew out of: XArchive, XDEX, XDisasmView, XDemangle, XEntropyWidget, XExtractor, XHexEdit, XHashWidget, XPEID, XYara, XPDF, XCppfilt and an XInfoDB database, among many others.

The detection engine is a separate upstream project

The repository tree contains a Detect-It-Easy directory, and the presence of .gitmodules at the root tells you that the directory is a submodule rather than vendored source. The same pattern applies to the other tool directories that are clearly external in origin, such as XCapstone for the disassembly library, XQwt for the plotting widget set, XLLVMDemangler, XCppfilt and XPDF.

This matters for anyone planning to build or extend the tool. The signature database and the analysis engine live upstream, and XAPKDetector is the Android-facing layer on top of them. That is the sensible division of labour, because the upstream project can be updated independently of the Android-specific format handling, and it also means the two move at different speeds. A submodule pinned to an old commit is a plausible source of missing detections, and the .gitmodules file is where you would look to find out which commit is pinned.

The tree also carries directories that suggest the tool has grown well beyond APK files over time, or has absorbed sibling functionality: XDecompiler, XStaticUnpacker, XScanEngine, XDataConvertorWidget, XMemoryMapWidget and XRegionsWidget. StaticScan and XStaticUnpacker are worth noting for the security research use case, because static unpacking without execution is the safer first move when handling an untrusted sample.

A Qt GUI, not a library or a service

The build is a Qt project. The Dockerfile names the packages it installs: qt5-default, qtbase5-dev, qtscript5-dev and qttools5-dev-tools, alongside git and build-essential. The presence of qtscript5-dev is a hint about the scripting layer, and the directory names in the tree reinforce the GUI shape of the project, with widget directories such as XAboutWidget, XDemangleWidget, XDynStructsWidget, XEntropyWidget, XExtractorWidget, XHexView, XHashWidget, XMemoryMapWidget, XOptions, XPDF, XRegionsWidget, XShortcuts, XStyles, XSymbolsWidget, XUpdate, XVisualizationWidget and FormatDialogs.

This has a direct consequence for how you would use it. There is no Python binding, no documented API and no headless mode described in the project documentation, so integrating the detection output into a pipeline means driving the GUI or reading its output files, not calling a function. For an analyst working through samples one at a time that is not a problem. For a team that wants to classify a large corpus automatically it is a real limitation, and the alternative in that case is to work against the upstream Detect-It-Easy engine directly.

The build is also handled three ways in the tree, which reflects the three target platforms. There is a CMakeLists.txt at the root, a build_dpkg.sh script with a DEBIAN/ directory for Debian packaging, a build_lin64.sh script with a LINUX/ directory and a build_libs/ directory, plus build.pri for qmake, and a Dockerfile for a container build.

The container build is a Debian package assembly

The Dockerfile is short and it is a good indicator of how the project ships on Linux. It starts from an ubuntu:bionic base image, given as a build argument so it can be overridden, and declares two stages, source-internet and builder.

The builder stage installs the build dependencies and then clones the project with submodules:

RUN git clone --recursive https://github.com/horsicq/XAPKDetector.git

The recursive flag is what pulls in the Detect-It-Easy and other submodule dependencies, and the next line runs the packaging script and then the install script:

RUN cd XAPKDetector &&  bash -x build_dpkg.sh && bash -x install.sh

So the container image is not a runtime image with the tool copied in. It is a build of the Debian package, which means the image contains the build toolchain and the packaging machinery rather than a slim production layer. That is a deliberate trade for a build environment rather than a deployment artefact, and it also means the image is a convenient way to get the build working without installing a Qt toolchain on your own machine.

The stage names are a little confusing at first, since source-internet appears to do nothing except exist. It exists so that the clone happens in a stage that has network access, separate from the later install stage, which is a pattern that keeps network-dependent steps out of the final layers.

The releases are old and the commits are not

The tagged releases are 0.03 from 2022-03-14, 0.02 from 2021-08-01 and 0.02b from 2021-06-23. The last push to the repository was on 2026-10-19, and the project is not archived.

Those two facts together are the maintenance picture, and they are different facts. The source tree has been worked on recently, but no new tagged release has been published since 2022. The badge in the README points to the GitHub releases page for the latest SemVer tag, so someone landing on the project will see the version numbers they can actually download, and they are from four years ago.

The changelog is a file in the repository, changelog.txt, rather than a GitHub release note, which is consistent with a project that keeps its release history in the tree. The documentation is split the same way, with docs/RUN.md for how to run the tool, docs/BUILD.md for how to build it, and numbered screenshots in docs/ for the interface.

What this means for a user is concrete. If you want a binary, you take release 0.03 and its detection coverage is what it was in March 2022. If you want current coverage, you build from source, and you accept the burden of a Qt toolchain and of submodule versions you have to check yourself. There is no third option where a fresh binary exists.

The licence is MIT, and the project also asks for help with translations through a separate XTranslation repository, which is how the interface gets localised.

A desktop tool for people who open samples by hand

The intended user is visible in the repository structure rather than stated anywhere. Somebody opens a package, wants to know what made it and what is wrapped around it, and then decides what to do with it. The screenshots, the mascot, the widget set and the docs page numbering all point at an interactive tool rather than a batch scanner.

For that user the appeal is speed of triage. Instead of guessing whether a DEX is packed, or which obfuscation pipeline produced an APK, you open it and read a list. The XInfoDB directory is the information database behind those lists, and XExtractor and XStaticUnpacker are the extraction-side tools sitting in the same application, which means the workflow of identify then extract happens inside one program rather than across a set of utilities.

The real alternative, and it is worth naming plainly, is to use the upstream Detect-It-Easy engine with its own command line and signature database, and handle the Android format yourself, or to use a dedicated Android reverse engineering toolchain such as apktool. The difference in approach is where the knowledge lives. XAPKDetector is an Android-focused front end over a general binary analysis engine, so it gives you an integrated desktop workspace with Android formats already wired in. apktool goes deeper into the package structure, decompiling resources and smali rather than identifying what is inside. Neither replaces the other, and the choice depends on whether your question is what is this package made of or what does this code do.

The project also carries a donation badge and a link to PELock Software Protection and Reverse Engineering under special thanks.

Editorial conclusion

Adopt XAPKDetector if you triage Android packages as part of reverse engineering or malware research and you want a fast read on which build tools, libraries and protectors are present before you unpack anything else. Do not adopt it as a malware verdict, because it reports indicators of tooling and packing rather than malicious behaviour, and do not build automation on it without checking the version you get, since the last tagged release is 0.03 from 2022 while the source tree has moved on. Before you commit, read docs/RUN.md for how to run the released binaries and docs/BUILD.md for the build path, and check the Detect-It-Easy directory in the tree, since the detection engine behind the tool is a separate upstream project that the repository pulls in as a submodule.

Frequently asked questions

Official sources

1. horsicq/XAPKDetector on GitHub
2. License: MIT
3. Project website
4. README
5. Releases