The Verlintas/NOIR project has reached release 0.1.1. The repo holds 20 commits and three portable archives: noir-v0.1.1-macOS-portable.zip, noir-v0.1.1-Windows-portable.zip, noir-v0.1.1-Linux-portable.zip plus SHA256SUMS.txt. Each ships with its own JRE, so there's no need to install Java: unpack, click Start NOIR.command, Start NOIR.bat, or Start-NOIR.sh — and off you go.
Here's how it works. Over adb, the tool reads the package list and their permissions. URLs are pulled from dex right on the phone via unzip + strings — only kilobytes travel back to the computer, not the whole APK. It then parses the binary AndroidManifest.xml: looking for exported components without permissions, cleartext traffic, backup, debuggable, targetSdk. It separately flags shared UIDs like android.uid.system and shows which packages sit on the same permission set. The risk score is computed by vendor (Xiaomi, Google, Tencent, ) and category — telemetry, ads, location, keyboards. Permissions are translated into plain language: "can grab location/contacts/microphone," and "data → domain" pairs are consolidated into a single table.
First launch is a wizard with two or three y/n prompts. It checks adb (noir doctor outputs something like: platform Mac OS X aarch64 java 17.0.19 adb Version 37.0.1-15733141 device 178b0d2f), offers to download the missing pieces into ~/.noir/tools, and waits up to 180 seconds for a device. Then it asks about "these 19 safe actions" — and on y performs them, writing a rollback file. The deep command pulls a single APK locally and uses jadx to search for Runtime.exec, setApplicationEnabledSetting, DexClassLoader, MediaProjection.
System privacy dashboards have long shown who asked for the camera. They don't show where the data goes. That "permission → specific domain" link is exactly NOIR's niche. Our assessment: this isn't a replacement for Android settings, but a tool for those who sideload APKs and want to understand what they've signed up for.
The user benefit is simple: one run before installing a sketchy build, no root, no report sent anywhere — the README explicitly promises "no network, uploads nothing." Money: zero. But the risk score is a heuristic based on package name and domain. It errs in both directions, and I wouldn't uninstall an app just because the number is red.
Who loses out? Probably no one, seriously. The tool is local, won't go mainstream, and its existence won't reduce telemetry one bit. We believe the main value here isn't the scoring but the manifest layer and rollback: that's exactly what manual analysis via aapt lacks.
Accuracy is unknown. The README contains not a single false-positive measurement, and no risk-score formula has been published — only a list of factors. It's unclear whether strings catches addresses assembled at runtime (Remote Config, OkHttp interceptors). 20 commits — the project is very young, and there's been no third-party code audit. And yes, "these 19 safe actions" are worth reading with your own eyes before pressing y.
y on 19 automated actions in a tool with 20 commits and no external code review?Prediction: within a quarter, the project will either publish a description of its scoring methodology or get an issue thread dissecting false positives. That's the first question you ask any privacy auditor.
Source: GitHub / Verlintas/NOIR
Source: github.com · post in Telegram