AppInfoScanner: asset inventory for Android, iOS and static web builds

What the scanner treats as an asset

AppInfoScanner is built for hw movements, red teams and penetration testers, and that audience decides what counts as a useful result. The tool is not an app store index, not a URL scanner and not a vulnerability scanner. It produces an inventory of things a target owns: URLs, IP addresses, protocol endpoints, credentials and personal data patterns, plus a limited amount of live metadata from hosts it discovers.

The scope is wide for a single Python program. One project covers Android, iOS, Web and H5 content, and it accepts raw binary artifacts rather than requiring a connected handset. The README lists DEX, APK, IPA, Mach-O, HTML, JS and Smali among the inputs it understands, and the command line takes a file, a directory or a download URL that the tool retrieves itself before scanning.

The output side is plainer and arguably more useful. Results are written as json, txt or xlsx, with a log directory that retains the twenty most recent files. That combination means an output can be dropped into a report, diffed between two builds of the same application, or opened in a spreadsheet without writing any glue code.

Three scan targets behind one input flag

Installation is the ordinary Python two-step, and the repository ships an English README alongside the Chinese original for anyone who needs it.

git clone https://github.com/kelvinBen/AppInfoScanner.git
cd AppInfoScanner
python -m pip install -r requirements.txt

After that, the interface reduces to three verbs, one for each platform family. The English forms of the three lines below appear in the usage section alongside their Chinese counterparts.

python app.py android -i <Your APK File or DEX File or APK Download Url or Save File Dir>
python app.py ios -i <Your IPA file or Mach-o File or IPA Download Url or Save File Dir>
python app.py web -i <Your Web file or Save Web Dir or Web Cache Url>

The type argument is not strict. The README notes that the tool corrects itself based on file extension, so passing ios with an .apk as the input still runs the Android path.

The option set is where the real behaviour lives. -i is mandatory and accepts the path or URL. -t sets thread concurrency, ten by default. -o chooses the output directory, which lands under the user's Documents folder by default and falls back to the home directory when Documents does not exist. -s turns off network sniffing, which is on by default, and -n ignores resource files, including the ones the sniffer would otherwise fetch, provided the relevant filters are configured in the workspace file. -a switches from a summary to printing every hit. -p restricts an Android scan to a specific Java package name, and it is the one option restricted to a single platform. -r takes a throwaway rule set for a single run instead of the workspace configuration.

A workspace on first run, with config.toml replacing config.py

The V1.0.10 release changed how the tool is configured in a way worth knowing about, because it affects anyone who already had the project checked out. On first run the tool now deploys a workspace into the AppInfoScanner directory under your Documents folder, and configuration moved from a Python file to config.toml. The release notes state that the old config.py is migrated automatically, which removes the most common way a local setup breaks after a pull.

Two consequences follow. First, the tool is now stateful outside the repository: your rules and settings live in a generated workspace rather than next to app.py, so a checkout can be deleted and replaced without losing configuration. Second, filtering, ignored resource files and sniffer rules all become editable TOML, which is a better format for a file people are expected to change.

The workspace also absorbs the toolchain. On macOS and Linux, missing Java, adb or frida are installed automatically; on Windows the repository ships binaries under tools/unpacker, along with apktool.jar and baksmali.jar. The README pins versions in a table rather than leaving them to chance, including frida 17.18.0, frida-tools 14.10.4, frida-dexdump 2.0.1, apktool 3.0.3 and baksmali 2.5.2-dev, with the note that the frida version on the host has to match the frida-server on the device. Python 3.11 or newer is the floor, with 3.14 recorded as verified.

For anyone extending the rules, the project also ships a unit test suite that runs with python3 -m unittest discover -s tests, which the V1.0.10 notes put at 59 tests.

What the V1.0.10 rule set actually covers

The bulk of the September release is detection coverage, and the counts are specific enough to be worth reading rather than paraphrasing. The credential module covers 24 rule sets for access keys and secrets across Alibaba Cloud, Tencent Cloud, AWS, Google, GitHub, GitLab, Slack, Stripe, JWT, private keys and passwords embedded in URLs. Personal and enterprise identifiers get 9 rule sets covering phone numbers, national identity numbers, email addresses, bank card numbers, vehicle plates, names and unified social credit codes, with the last two documented as carrying checksum validation.

Permissions and components are counted per platform: 49 sensitive Android permissions and 22 on iOS, plus component recognition for 20 Android and 22 iOS entries tied to published CVE and RCE advisories. Packener hardening detection draws on a single library covering 39 vendors, and the README describes three detection paths, covering application class names, file signatures and missing package names.

Network extraction was widened in the same release to multi-protocol, IPv4 with port, IPv6 and loopback services such as 127.0.0.1 with a port. The tool then generates an adb reverse capture suggestion, which turns the scan output into the next step rather than a dead end.

One fix in the notes is a good sign of how the code is exercised: shell detection was reported as false-positiving on Flutter applications, and the release corrects it. A second fix addresses common domain matching, now filtered through a 126 entry suffix table so a public domain does not drag internal addresses into the sniffer.

Three releases across five years, then one very large one

The release history is unusual and it changes how much weight to put on any single version number. V1.0.8 shipped on 2021-08-08, V1.0.9 on 2022-10-23, and then nothing until V1.0.10 on 2026-09-20. That last release is not a routine bump. Its notes list a new workspace system, a TOML configuration with migration, the entire credential and personal data rule set, the permission and component tables, the 39 vendor hardening library, the widened network extraction, structured reports, central task logging, automatic toolchain installation on macOS and Linux, bilingual output and the test suite. Fixes in the same release cover apktool 3.x failures, roughly 90 percent of strings being missed on macOS, a crash in directory level web scanning, race conditions in the scan thread queue and an exit call that bypassed exception handling during unpacking.

Read together, the history says this was a working tool with a long quiet stretch, then a substantial rewrite of configuration, detection and packaging rather than a series of small feature drops. The repository was last pushed on 2026-09-20, the same day as the release, so the code and the release line agree.

The README also explains the licensing posture plainly. The project is GPL-3.0, and it carries a disclaimer naming specific articles of Chinese criminal and cybersecurity law, stating that the techniques discussed are for private study and testing. Contributors are invited by email rather than through an issue tracker for feature work.

Three boxes still unticked, including fingerprinting

The feature list in the README keeps its checkboxes, and the unchecked entries matter more than the marketing-style description at the top of the project. The repository description says output includes fingerprint information, while the checklist leaves fingerprint recognition for web frameworks, CDNs, WAFs and CMS platforms unticked. Both statements come from the same README, and the honest reading is that basic network metadata is collected, since the feature list confirms status code, title, Server header, CDN and resolved IP sniffing, while automated fingerprint classification is not done.

Also unfinished: stronger unpacking automation, and parsing for ELF and .so files including Flutter's libapp.so, along with support for HarmonyOS and HyperOS packages. That last gap is worth stating in plain terms, because a large share of current Android applications ship as Flutter or contain native libraries, and the tool will not read inside them.

Everything else on the list is marked complete, from directory level batch scanning and custom request headers to magic byte repair for APK files and language-aware output driven by an environment variable. The tree backs this up with a clean separation: libs/core holds parsing, reporting, downloading, sniffing, i18n, toolchain provisioning and magic byte repair, while libs/task holds one scheduler per platform plus download and sniff jobs, coordinated by a single base_task dispatcher. app.py stays a thin entry point, and tools/ holds the jars and the Windows unpacker binaries.

Editorial conclusion

AppInfoScanner is worth installing if your work involves taking apart application builds you are allowed to examine and coming back with an inventory rather than a verdict. It reads the artifact directly, needs no device for the basic path, and writes results in shapes a report can consume. Its real limits are equally clear: fingerprinting is still unchecked on the feature list, ELF and Flutter binaries are out of scope, and unpacking stays a partial workflow. Point it at an APK with python app.py android -i, read the txt and xlsx output, and only then decide whether the rule set needs extending for the kind of application you actually face.

Frequently asked questions

Official sources

1. Issues
2. kelvinBen/AppInfoScanner on GitHub
3. License: GPL-3.0
4. README
5. Releases