ASL X-Ray — Source library
Public documentation snapshot: 2026-09-08
See inside an app before you install it
Read what an Android app can do before you install it, without ever running it.
See inside an app before you install it
Built for: The one person at a small company who gets asked "is this app safe to put on the work phones?" · An IT or security reviewer handed a sideloaded app by a vendor, a contractor, or an employee · An investigator or advocate looking at a phone where an app may have been installed by someone else · A developer vetting a third-party build before it ships inside their own product
ASL X-Ray exists because of this.
Someone hands you an Android app. A vendor's direct install link, a build from a contractor, a file a colleague forwarded, or an app already sitting on a phone you are responsible for. You have to decide whether it goes on the device, and there is almost nothing to decide with. The store listing is marketing copy. The permission screen tells you what the app is allowed to do, not what it does with that permission or why it wanted it. And the app has not run yet, so there is no behaviour to watch. Every way out of that is bad. Install it and see what happens, and now it is on a real device next to real data and real accounts. Set up a contained environment to detonate it in, and that is a day of work and a lot of trust in the containment holding. Push it through a scanner that returns one word and a detection count, and you learn nothing about what the app actually reaches for, and you get told "clean" for anything new enough that no signature exists yet. Read the code yourself, and that is hours of work, assuming you can read a decompiled Android app at all. So the decision gets made on instinct, and instinct is exactly what the dangerous apps are built to survive. The ones that matter are not obvious on a permission list. An app that reads your screen, records while you are not looking, hides its own icon after install, and quietly reads every notification so it can lift your one-time login codes does not look different from a flashlight app when you read its permissions one at a time. It looks different in the combinations. Nobody has time to spot combinations by hand, on every app, every time.
ASL X-Ray exists because of this.
It explains rather than classifies. Most scanners return a verdict; this returns what the app can do, the order it probably does it in, why that combination matters, and where in the file to look.
ASL X-Ray exists because of this.
A known-malware match does not stop the work. Analysis continues to the end, so you get the full capability picture instead of a single word.
ASL X-Ray exists because of this.
Coverage is a first-class part of the report. It counts what it could not read, names the blind spot, and refuses to let a low score be mistaken for a clean bill of health.
ASL X-Ray exists because of this.
The phone scanner's offline promise is enforced by the phone, not by policy. It declares no platform permissions at all, and anyone can verify that from the app file itself.
ASL X-Ray exists because of this.
One behaviour, one name. The hosted service and the offline Windows suite ship the identical forty-eight-rule catalog under identical rule names, so findings from different places can be cited together in the same report.
ASL X-Ray exists because of this.
The uploaded app is deleted at the end of the job and reports expire on their own within a day. Nothing is kept to build a collection.
ASL X-Ray exists because of this.
Ten of the rules exist purely to connect other findings into named attack chains, which is where real malware actually becomes visible.
How ASL X-Ray works, start to finish.
ASL X-Ray takes an Android app apart and reads it without ever running it. You hand it an app file. That file is never installed, never launched, never emulated, and never given a way to reach the network. A few minutes later you get a report that says what the app appears able to do, how it appears to work, why each behaviour was flagged, exactly where in the file the evidence sits, and how much of the app could actually be read. It does not trust a single reading. The original file is first checked against a known-malware signature set. Then the app is recovered three separate ways: readable source, the decoded manifest and resource structure, and a raw inventory of everything the package actually contains. Three independent recoveries of the same file catch different things, and where they disagree that disagreement is itself information. The results are correlated into one story rather than three lists, covering permissions, components, the parts of the system the app reaches for, how it survives a reboot, what it collects, what it can execute, where it talks to, and how it behaves when it thinks it is being watched. The catalog behind that is 48 behaviour rules, and ten of them are attack-chain rules. This is the part that matters. A single capability almost never means anything on its own. An app drawing over other windows is ordinary. An app drawing over other windows while reading the content of those windows is the standard construction for stealing a banking password, and X-Ray names it as that rather than listing two permissions and leaving you to connect them. The same logic covers dropper behaviour, ransomware shape, remote control, command-and-control, and credential theft. A rule identifies a behaviour, not the tool that found it, so a finding raised on your phone, a finding raised by the hosted service and a finding raised by the offline Windows suite carry the same name and can be cited together in one write-up. It is honest about where it stops, and that honesty is built into the output rather than buried in a footnote. Every report states its coverage. If the app ships compiled native libraries, the report counts them and tells you their machine code was not read, so the score only covers the parts it could see. If a known-malware signature matches, the result is pinned at the top of the scale immediately, and no later finding can talk it back down. But the analysis keeps running anyway, because "this is malware" is far less useful to you than "this is malware, and here is what it collects, how it survives a reboot, and where it sends things." Every report carries a line in plain words saying static analysis cannot prove an app is safe, so a low score is never presented as a clean bill of health. There are three ways to use it, and they suit different situations. ASL X-Ray Lite is a phone app that scans an app on the device itself, applying seventeen of the rules locally. It needs no account, carries no advertising, and declares no platform permissions at all, so it is not that it chooses not to send your data anywhere, it is that the phone will not let it. The hosted service is the deep version: you sign in, upload an app, and get the full three-way recovery and the complete rule catalog back as a report you can download and keep, through a browser or through the paired phone app. And for people who work with the actual devices, there is a separate Windows workstation suite that runs entirely offline with 12 modules and 24 operations, covering package inspection, version comparison, connected-device inspection, guarded recovery, and hash-verified incident evidence export. That suite is the one part of the product that can touch a live device, and every operation that could change one is gated behind naming the exact device and typing a confirmation out in full.
Everything in the current release.
Each of these is built and working today. Nothing on this list is a roadmap item.
A verdict written in sentences, not a detection ratio
The report opens with a risk score out of 100, a plain-language verdict, and what the app most likely exists to do. Then it explains what the app appears capable of, how it appears to work, and why each behaviour was flagged. It is written to be handed to somebody who has to make a decision, not to somebody who already reads decompiled Android for a living.
Three independent readings of the same file
The app is recovered three different ways: readable source, the decoded manifest and resource structure, and a raw inventory of every entry in the package. Each runs separately with its own limits, and one of them failing does not throw away the other two. A partial recovery that a naive tool would discard is kept and labelled as partial, so thousands of readable files are not lost to a single nonzero exit code.
Attack chains, not a list of permissions
Ten of the forty-eight rules exist only to connect other findings into recognisable shapes: credential theft, dropper, ransomware, remote control, command-and-control, persistent control, screen surveillance, message exfiltration. An overlay is unremarkable on its own; an overlay plus screen reading plus persistence is a named pattern with a known purpose. This is the difference between a permission list and an actual finding.
A known-malware hit does not end the analysis
The original bytes are checked against a known-malware signature set before anything else happens. If it matches, the result goes straight to the top of the risk scale and stays there. The analysis keeps running anyway, because knowing an app is malicious is far less useful than knowing what it collects, how it persists, and where it sends things.
Coverage is stated on every report, every time
Every report says how much of the app could actually be read. If the app ships compiled native libraries, the report counts them and states that their machine code was not read. Obfuscation, code downloaded after install, and any recovery warning all mark coverage partial and are listed by name. A low score is never presented as proof of safety, and the report says so in words rather than in a disclaimer nobody reads.
The uploaded app is never executed
In the hosted service and in the on-device scanner, nothing is installed, launched, emulated, or executed at any point. The part of the hosted service that opens your file is a separate process with no route to the internet, so an app cannot call home while it is being examined and cannot be triggered by being looked at. That separation is structural rather than a setting somebody could leave switched off. Only the separate Windows workstation suite can touch a live device, and only through operations you deliberately choose.
Reports you can keep, in three formats
Every finished hosted scan produces a machine-readable report, a written report, and a self-contained page you can open in a browser and forward to somebody else. Every value is escaped on the way in, so a report carries no active content and no host paths, and reports arrive as named file downloads. They carry file hashes and evidence locations, so a second reviewer can find exactly what you found. The on-device scanner saves its own findings as a web page or plain text, wherever you choose to put them.
The uploaded app is deleted when the job ends
The file you upload and everything recovered from it are removed as soon as the job reaches a final state, whether it finished, failed, or you cancelled it. The stripped-down report is kept for 24 hours by default and then expires on its own. This is a scanner, not an archive, and it is deliberately not built to accumulate other people's software.
Scans are private to you, and to your own administrators
A normal account sees its own jobs and nobody else's, and a request for a job that is not yours is answered exactly the same way as a request for a job that does not exist, so the system will not even confirm it exists. Ownership is recorded as a one-way identifier rather than your name, your email, or your login details, and your sign-in credentials are never stored against a job. Accounts holding an administrator role can see all jobs, which is worth knowing before you upload something sensitive.
A phone app that physically cannot send anything anywhere
ASL X-Ray Lite scans an app on the phone itself and declares no platform permissions whatsoever, including no internet permission. That is not a promise in a privacy policy: Android will not open a connection for it, you can check that yourself in Settings, and a reviewer can verify it independently from the app file with standard Android tooling. It needs no account and carries no advertising code.
The same finding has the same name everywhere
A behaviour gets one identifier no matter which part of the product found it. The hosted service and the offline Windows suite carry the identical forty-eight-rule catalog under identical names, and the seventeen rules the phone app runs on-device use those same names. So a finding raised on a phone and the equivalent finding raised by the hosted service can be cited together in the same document. Reports also record which rule set and scoring version produced them, so an old report can still be read correctly later.
Limits that fail closed instead of falling over
Uploads stop at 250 MiB. Archives that try to escape their own folder, point at themselves, hide symbolic links, or expand out of all proportion are rejected outright rather than partially processed. There are ceilings on how much a scan may produce, how long it may run, how many scans you may have going at once, and how much storage the service may use. A scan that breaks one of them publishes nothing rather than handing you something half-finished.
An offline Windows suite for people who touch the devices
ASL Android Security Lab is a separate Windows product that runs entirely offline with no account, no upload, and no telemetry, and it carries everything it needs inside the installer so nothing else has to be installed first. Twelve modules cover 24 operations: package decompiling and auditing, package and bundle inspection, version comparison, connected-device inspection, guarded recovery work, and hash-verified incident evidence export. Anything that could change a device requires the exact device to be named and a confirmation typed out in full.
Findings that tell you what to actually do
Every finding carries a recommendation, not just a label. Device-administrator rights come with the instruction to revoke them in Settings before you try to remove the app; a notification reader comes with a warning that your two-factor codes are exposed and the account should be treated as reachable. The phone app ships in English and Spanish, with every user-facing string translated and the wording taken from the analysis engine itself rather than rewritten separately.
Numbers we can stand behind.
Every figure below comes from the product's own release record or test suite, not from a marketing estimate.
Numbers we can stand behind.
There is an offline Windows workstation edition for people who cannot or will not upload a file anywhere, and it is the only part of the product that ever touches a live device.
Surfaces and status.
Status as of September 6, 2026. The hosted service responds on version 1.0.6 and its sign-in association is published. New Lite and Pro 1.0.2 phone candidates are unsigned and have not been promoted to public Play release. The original signing identity, store configuration and signed-device acceptance still need verification; Pro also needs its authenticated upload-to-report workflow verified. The earlier signed 1.0.0 files are retained as historical releases. Windows remains early access with private distribution.
Worth more together.
Products on this platform share one sign-in, one support queue, and one engineering standard. These pair naturally with ASL X-Ray.
ASL Scan
X-Ray tells you what one app can do. ASL Scan looks at the systems and services that app would sit next to, so you are not securing the phone and ignoring everything it connects to.
Network Sentinel
Static analysis says where an app appears able to reach. Network Sentinel watches what actually leaves the network afterwards, which is the natural next step when a report flags an endpoint you did not expect.
ASL Timestamp Anchor
If a scan report is going to support a decision somebody may question later, pairing it with a timestamp fixes what the report said and when, before anything changes.
ASL Vault
Reports can contain endpoints, code structure, and occasionally secrets the app's own author left inside. Vault gives those findings somewhere controlled to live instead of a shared drive.
ASL Shredder
When a review is finished, the working copies of an app and its report should not linger. Shredder handles the clean-up end of the same job.
What does this cost?
The new X-Ray Lite candidate is designed to be free, with no account or ads and an optional donation to AutoSecureLogin. It is still awaiting signed release and store verification. Pricing and access for the Pro service and Windows suite are not confirmed here; contact us before making a purchase decision.
We already use an antivirus scanner. Why would we add this?
A scanner tells you whether something matches a known signature. That is genuinely useful, and X-Ray does it too, as the first step. But it says "clean" for anything new enough that no signature exists yet, and even when it says "malware" it does not tell you what the app collects, how it persists, or where it sends things. X-Ray keeps analysing after a match precisely so you get the explanation, and it finds dangerous capability combinations in apps no signature has ever seen.
Is my uploaded app kept, shared, or used to train anything?
No. The file you upload and everything recovered from it are deleted as soon as the job reaches a final state, whether it completed, failed, or you cancelled it. The report is kept for 24 hours by default and then expires on its own. Your scans are visible to you and to accounts holding an administrator role on the service, and to nobody else, and the scan record identifies you by a one-way identifier rather than by your name or email.
Could analysing a malicious app cause it to do something?
The app is never installed, launched, emulated, or executed at any stage by the hosted service or the phone scanner. It is only read. The part of the hosted service that opens your file is a separate process with no route to the network, so an app cannot contact anything while it is being examined. That separation is structural rather than a setting, and hostile packages that try to escape their own folder or expand out of all proportion are rejected outright instead of being partially processed. The one place the product can touch a live device is the separate offline Windows suite, and only through operations you deliberately choose.
Is this ready to use, or is it still being built?
The hosted service is running release 1.0.6. X-Ray Lite and Pro now have unsigned 1.0.2 candidates. Earlier signed 1.0.0 packages remain historical releases. The current phone candidates still need their original signing identity, authenticated store reconciliation and signed-device acceptance. Pro also requires a verified authenticated upload, completion, cancellation and report-download workflow. The product remains early access.
What happens if we stop paying, or you stop offering it?
Everything the product gives you is a file you already have. Reports download as a machine-readable file, a written report, and a self-contained page, and they record their own rule set and scoring version so they can still be read correctly years later. There is no store of your data to be held hostage; reports expire within a day by design, so the only lasting copies are the ones you saved. The Windows suite runs entirely offline on your own machine and keeps working regardless.
Is there any migration or setup work to do?
None for the phone app: install it and scan. For the hosted service you sign in with the same Auto Secure Login account you use elsewhere on the platform, and someone grants your account scanning access. There is nothing to import, no agent to deploy, and nothing to configure on your devices. The Windows suite is a single installer that carries everything it needs, so you do not have to install other tooling first.
Can this tell me an app is definitely safe?
No, and it will not pretend otherwise. It reads the code and declarations shipped inside the app; it cannot see encrypted payloads, code downloaded after installation, or behaviour a server turns on later, and it counts compiled native libraries without reading their machine code. Every report states how much of the app it could actually read, and says in plain words that a low score is not a promise of safety. Any product that tells you an app is definitively safe is claiming something no static analysis can support.
We cannot let files leave our building. Is there an option for us?
Yes, two. The phone app scans on the device itself and declares no platform permissions at all, so nothing can leave. The Windows workstation suite runs entirely offline with no account, no upload, and no telemetry, and carries all the tooling it needs inside the installer, so evidence stays on your machine unless you move it. Two things to know up front: the Windows installer is handed over on request rather than downloaded from a public page, and it is not signed with a publisher certificate, so Windows will warn about an unknown publisher. Verify it against the published checksum.
How long does a scan take, and how many can we run?
Most apps come back within a few minutes. The hosted service deliberately runs one analysis at a time so each scan gets the whole machine, and each recovery stage is capped at ten minutes, so you should not assume a result inside 35 minutes for a large or awkward app. Each account can have two scans active at once and start ten in a rolling 24 hours.
Who is this actually for? Are we too small for it?
The opposite. Large security teams already own contained environments and staff who read decompiled Android for a living. This is built for the person who does not have that: the one technical person at a small company, an IT reviewer, an investigator, or someone checking a phone they are responsible for. The report is written to be read and acted on by that person, and to be handed to someone else as the justification for a decision.
Which parts have actually been tested, and by whom?
September 6, 2026: both phone apps have new 1.0.2 candidates. Lite passed 40 unit tests, six Android tests and optimized emulator scan, export, rotation and large-text checks; one optional malware-sample check could not run. Pro passed 20 unit tests and three Android tests, with offline readiness, help and example screens reviewed on the emulator. Its original-signature live gate and authenticated phone-to-server scan workflow remain open. The hosted service passed 26 local automated tests and its live 1.0.6 health endpoint is responding. These checks do not establish a public Play release or independent security certification. Earlier Windows acceptance records remain historical and were not repeated in this Android audit.
What should I know before I rely on it?
We would rather you hear this from us than discover it later. As of 2026-09-02:
What should I know before I rely on it?
Static analysis cannot prove an app is safe. "No finding" and a low score mean the analysis did not see anything, not that there is nothing to see. Every report says this explicitly.
What should I know before I rely on it?
Obfuscated code, encrypted payloads, code the app downloads after installation, and behaviour a server switches on later are blind spots. The report names them when it detects them, but it cannot see through them.
What should I know before I rely on it?
Compiled native libraries are counted but their machine code is not read. Where an app ships them, the report states that the score covers only the parts it could read.
What should I know before I rely on it?
The app is never executed by the hosted service or the phone scanner, so nothing there proves what happens at runtime, what data is really transmitted, or whether a weakness is exploitable. A report is evidence for a human to review, not a conclusion.
What should I know before I rely on it?
The analysis tools read hostile input by design. Our own security record says the controls around that reduce the impact of a parser flaw but do not eliminate it, and we do not claim otherwise.
What should I know before I rely on it?
The release record still lists an authenticated end-to-end analysis of a real app through the deployed service as an open gate, so no completed production scan is claimed. The service is deployed and answering; that particular proof is not yet written down.
What should I know before I rely on it?
Access to the hosted service is granted per account. Creating an account does not by itself grant scanning access.
What should I know before I rely on it?
The hosted service runs one scan at a time. A large or awkward app can take a while, and you should not assume a result inside 35 minutes.
What should I know before I rely on it?
Reports expire automatically after 24 hours by default. Download anything you need to keep. Deleting a report early is currently a request rather than a button.
What should I know before I rely on it?
Accounts holding an administrator role on the service can see every job, not only their own. Normal accounts see only their own.
See inside an app before you install it
Prefer email? contact@autosecurelogin.com