How to read signing info for security & compliance
- Step 1Hash first for custody — Before anything, run Checksum Generator on the artifact and record the SHA-256. This binds the later signing report to a specific, verifiable file.
- Step 2Open the detector — Go to /archive-tools/archive-signing-info on a Pro (or higher) account. Nothing about the file transits the network.
- Step 3Drop the artifact — Read one file at a time — the evidence JAR/APK or the candidate release. The tool extracts it locally and scans for signing footprints.
- Step 4Capture the findings — Download
<name>-signing.json. Itsfindingslist states whether a manifest, signing files, and/or an APK Signing Block were detected. - Step 5Verify when a verdict is required — For a defensible "valid signature" claim, run
apksigner verify --print-certsorjarsigner -verify -certs. The browser report establishes presence; the CLI establishes validity and signer. - Step 6File the evidence bundle — Attach the SHA-256, the
<name>-signing.jsonreport, and any CLI verification output together so the chain from hash → presence → verdict is intact.
Compliance question → right tool
Read Signing Info answers exactly one column. Map each compliance question to the tool that actually answers it to avoid over-claiming in a finding.
| Compliance question | Answered by Read Signing Info? | Authoritative tool |
|---|---|---|
| Does the artifact carry signing files? | Yes — detects and lists them | Read Signing Info |
| Is there an APK Signing Block? | Yes — magic-byte detection | Read Signing Info |
| Is the signature cryptographically valid? | No | apksigner verify / jarsigner -verify |
| Who is the signer (cert subject/fingerprint)? | No | apksigner --print-certs / keytool |
| Has the artifact been tampered with? | No | Checksum vs known-good + signature verify |
| Is the file the one we received? | No (use the hash) | Checksum Generator |
Tier limits for compliance-scale artifacts
Read Signing Info needs a Pro tier minimum. Watch the per-archive entry cap as well as size — security artifacts (forensic ZIPs, fat APKs) can be entry-heavy.
| Tier | Max size | Max entries | Typical fit |
|---|---|---|---|
| Free | n/a | n/a | Tool not available below Pro |
| Pro | 500 MB | 50,000 | Most JARs, APKs, single evidence ZIPs |
| Pro-Media | 2 GB | 500,000 | Large device-image extracts, fat archives |
| Developer | 2 GB | 500,000 | Same caps, unlimited batch elsewhere |
| Enterprise | unlimited | unlimited | No caps |
Cookbook
Evidence-style reports an analyst would attach to a case. Filenames anonymised; the JSON shape is the tool's real output.
Suspect APK pulled from a device image
An analyst triaging a sideloaded APK. The block is present, so the app claims a v2/v3 signature — but presence alone does not establish a trusted signer. Note this in the finding and follow with apksigner.
evidence-sample-7f2-signing.json
{
"filename": "evidence-sample-7f2.apk",
"findings": [
"Found META-INF/MANIFEST.MF — JAR-style archive.",
"Signing files: META-INF/CERT.SF, META-INF/CERT.RSA",
"APK Signing Block detected (Android v2/v3 signature)."
]
}
Finding: signing artifacts present; validity & signer NOT established by this tool.Vendor JAR submitted for review
A library a third party wants approved. The report shows a manifest but no signing files — so the vendor's "it's signed" claim is not supported by the artifact.
vendor-lib-2.3-signing.json
{
"filename": "vendor-lib-2.3.jar",
"findings": [
"Found META-INF/MANIFEST.MF — JAR-style archive."
]
}
Finding: NOT signed (manifest only, no .SF/.RSA). Reject vendor's signed-artifact claim.Release candidate pre-gate check
Release engineering confirming an artifact carries signing files before the CI verification gate. A quick smoke test, not the gate itself.
release-candidate-signing.json
{
"filename": "product-1.8.0.apk",
"findings": [
"APK Signing Block detected (Android v2/v3 signature)."
]
}
Next: CI runs `apksigner verify --print-certs` as the authoritative gate.Unsigned distribution ZIP
A plain ZIP that should be unsigned. Confirming the negative is a legitimate compliance result — it documents that no signing artifacts exist.
data-export-q2-signing.json
{
"filename": "data-export-q2.zip",
"findings": [
"No digital signature found."
]
}
Finding: no signing artifacts present (expected for a data export).Custody binding: hash + signing report
How the report is made defensible. The SHA-256 (from Checksum Generator) binds the finding to a specific file so the report cannot be re-attached to a different artifact later.
Chain-of-custody bundle: 1. checksum: product-1.8.0.apk SHA-256 = 9c41...e0 2. signing: product-1.8.0-signing.json (APK Signing Block detected) 3. verdict: apksigner verify --print-certs → Verified, Signer SHA-256 3a1f...d2 All three stored together; the hash links report to file.
Edge cases and what actually happens
Reporting presence as "verified"
Finding errorWriting "signature verified" based on this tool overstates the evidence. The correct finding is "signing artifacts present". Validity requires apksigner/jarsigner — record that separately.
Encrypted evidence ZIP
Extraction failedThe tool passes no password to the extractor, so password-protected evidence will not extract. Confirm encryption with Encrypted Archive Detector and decrypt in your forensic workflow first.
Tampered file, intact signing files
Not detectedModifying a signed archive's payload without re-signing leaves the .SF/.RSA files in place — this tool would still list them. Only digest verification (CLI) or a checksum mismatch catches tampering.
Forensic ZIP over the entry cap
Tier limit exceededDevice-image extracts can exceed 50,000 entries (Pro). Use Pro-Media/Developer (500,000) or carve out the artifact of interest before scanning.
Renamed evidence (.bin that is a ZIP)
SupportedDetection is magic-byte based, so a mislabelled artifact is still routed correctly. Document the true format from Auto-Format Detector in the finding.
Manifest present but stripped signature
By designAn attacker can remove .SF/.RSA and leave the manifest. The tool correctly reports manifest-only, which a reviewer should read as "not signed", not "signing removed" — note the distinction.
No checksum recorded first
Custody gapWithout a hash binding the report to the file, the <name>-signing.json could be re-attached to a different artifact. Always hash first with Checksum Generator.
Regulated-data handling sign-off
SupportedBecause nothing transits a network, processing stays inside your boundary — equivalent to a local CLI. Confirm with your compliance owner that local in-browser processing matches policy; most do.
APK signed only with v2/v3, no META-INF
SupportedPure v2/v3 APKs may have no JAR-style files. The APK-block check still fires, so the artifact is correctly flagged as carrying a signing block.
Frequently asked questions
Is this tool a signature verifier?
No. It detects the presence and filenames of signing artifacts and the APK Signing Block. It does not verify validity, parse certificates, or check digests. Use apksigner/jarsigner for the verdict.
Can I use it on sensitive evidence?
Yes — the archive is read from disk and processed in-browser with no upload, so it stays inside your boundary. Confirm local browser processing fits your data-handling policy with your compliance owner.
How do I make a finding defensible?
Hash the artifact first with Checksum Generator, then attach the <name>-signing.json and any CLI verification output together so the file → presence → verdict chain is intact.
Does a positive finding prove the artifact is trusted?
No. "APK Signing Block detected" means a block exists, not that it is from a trusted key or valid. Never write "verified" off this tool alone.
Can it detect a tampered-but-still-signed file?
No. If the payload changed but signing files remain, this tool still lists them. Tampering is caught by digest verification (CLI) or a checksum mismatch against a known-good hash.
What tier do compliance teams need?
Pro minimum (500 MB / 50,000 entries). For large forensic extracts, Pro-Media or Developer raise caps to 2 GB / 500,000 entries.
Can multiple analysts run it at once?
Yes. Each browser tab is an independent local instance with no shared server state. Tier limits apply per session.
Does it work in air-gapped / restricted environments?
After the page and WASM chunks load it runs locally. In a fully air-gapped setup, ensure the libarchive WASM chunk is cached before disconnecting if you need 7z/rar/bz2/xz support.
What about HIPAA / PCI / FedRAMP boundaries?
Because nothing transits a network, using the tool does not move your regulated boundary — it is equivalent to a local utility. Confirm with your compliance team as you would for any local tool.
Can it list the signer's certificate for the case file?
No — it never parses certificates. Pull the signer details with apksigner --print-certs or keytool -printcert and attach that alongside the signing report.
Is the detection deterministic?
Yes. It is fixed byte-level logic (filename patterns and magic bytes), so the same file always yields the same findings — important for repeatable, defensible results.
What if the evidence is a tar or 7z holding the artifact?
The tool scans the outer container's top-level entries. A JAR/APK nested inside a tar is an entry, not the scanned container — extract it first, then scan the JAR/APK directly.
Privacy first
Every JAD Archive tool runs entirely in your browser using fflate, @zip.js/zip.js, and the libarchive WASM bridge. Your archives never leave your device — verified by zero outbound network requests during processing.