How app sharing services screen uploads

A service that turns any uploaded .apk or .ipa into a public install link has a problem every other file host has: some people will try to use it to pass on harmful apps. Fake banking apps, stolen paid apps with an extra payload, and spyware meant for someone else's phone all need a way onto a device, and a friendly install page is a good one. Screening is how a sharing service keeps that off its links. This guide explains the common methods, what each one catches, and the questions worth asking before you pick a service for your testers.

1. Malware signatures

The oldest method: run the file through an antivirus engine that compares it with signatures of known malware. Mobile packages are zip archives, so a useful engine opens the archive and checks the files inside, such as dex code, native libraries and resources.

What it catches: files that match a known family or a known sample. Where it stops: brand new malware with no signature yet, and very large files that an engine will not read to the end. Services that recheck recent uploads with fresh signatures narrow the first gap.

2. Hash lookups against malware databases

A file's SHA-256 hash is a fingerprint. Public databases of malware samples, such as MalwareBazaar from abuse.ch, answer whether a given hash belongs to a known sample. Only the hash needs to leave the service, never the file.

What it catches: exact copies of files already reported. Where it stops: one changed byte gives a new hash, so it works best next to a signature engine.

3. A list of removed files

When staff take down a build for abuse, the service keeps the hash of the file and refuses the same file if anyone uploads it again. It stops the same file from coming straight back under a new account.

4. App ID blocklists

Some bundle IDs and package names should never appear on a test link: big brand apps whose makers never share test builds this way (these are usually modified copies), and IDs already tied to abuse. Refusing them at upload is cheap and catches a lot of repackaged apps. It is a check of the ID, not of the code inside.

5. Permission based holds

An Android build that asks for a set of permissions typical of covert surveillance, such as reading SMS and the call log together with an accessibility service, is a strong signal. Parental control and device management apps ask for the same things, so a careful service holds such builds for a person to look at instead of refusing them outright.

6. Reports and human review

Every install page should have a way to report a build, and someone should read the reports. Asking for a reason makes reports useful. Holding a build after one report is fair for anonymous uploads but harsh for paying developers, so services set different thresholds.

What a match should do

Screening that deletes files on its own will sooner or later delete an honest developer's build. A better pattern is a hold: the link stays, installs stop, staff are alerted, the owner is told why, and a person releases or removes the build. Ask a service which pattern it uses.

Questions to ask any sharing service

• Which of the methods above run on every upload, and on which plans?
• Does the malware check open the archive, or only look at the outer file?
• Is my file sent to a third party, or only its hash?
• What happens to my link on a match: deleted, refused or held? Who decides, and how do I hear about it?
• Are recent uploads checked again with newer signatures?
• Where can I see the result: the dashboard, the API, the CLI?

How AppForShare does it

On AppForShare, every upload on every plan, guest uploads included, is checked for known malware right after the link is issued: ClamAV with archive scanning, plus a SHA-256 lookup at MalwareBazaar (only the hash leaves our servers). Live builds under 72 hours old are checked again daily. A match holds the build, staff are alerted, the account owner gets one email, and a person releases or removes it. Next to that, a file we removed for abuse cannot be uploaded again, big brand and known malware app IDs are refused, guest Android uploads with a surveillance style permission set are held for review, and every report needs a reason. Details: the malware check and how reports work.

Screening and your own security scan

Screening protects testers from other people's uploads. It tells you nothing about mistakes in your own app, such as a payment key left in the code. That is a different job, done by a security scan of your build. See upload screening and a security scan are different jobs.

Common questions

Is a hash lookup enough on its own?

No. It only finds exact copies of known samples. It works best together with a signature engine that opens the package.

Why hold a build instead of deleting it?

Because checks can be wrong, and a person can tell a parental control app from spyware. A hold stops installs at once without losing an honest build.

Should testers still be careful?

Yes. Install builds from people you work with, read the permissions an app asks for, and use the report button when something looks wrong.

To see screening and a security scan on your own build, make a free AppForShare account and upload it.