Editorial review: 4 October 2026 UTC. This guide reviews publisher documentation and a practical verification workflow. No suspicious-site visit, malware analysis, antivirus scan or installer execution was performed for this review.
Quick check: our download site checker compares a public address with the publisher hosts and cited reports in its list. It can also show a name-similarity hint or say that it has no data. It does not visit the pasted address, check a file or decide that every unlisted site is fake. An official-host match is only the start of verification.
What should I do with the checker result?
Choose the result you saw. These next steps work with the checker’s limited list; they do not replace a publisher source check, file inspection or your security software. Paste public addresses only, without credentials, private tokens or account links. Open the checker itself rather than putting a pasted address in its URL.
It matches a listed official host
Go back to the established publisher page and follow its download link. Check the exact release, platform, architecture and package. A URL can have a listed host while its path is made up or while its download route needs further verification. Then compare the file’s SHA-256 with the appropriate reference and inspect its Windows signing certificate where applicable. None of those steps is a general safety guarantee.
It resembles a listed name but is not verified
Do not turn a similarity hint into an accusation. A publisher may use a separate subdomain or CDN that this list does not contain. Follow the link from the established project page to that exact location. A familiar word, logo or HTTPS lock is not a substitute for that source chain.
It is not in the list, including a GitHub address
The checker has no classification for this host; it has not approved or condemned the file. Establish the publisher independently. On GitHub, compare the owner and repository name against the project’s own link, not just the github.com host or an app name in the path. A public repository can belong to another person.
It matches a domain covered by a cited report
Read the linked source, classification and date. A historical report is not a fresh malware analysis of this domain or your file. Use the established publisher’s route instead. If you already downloaded or ran a file, use the separate guidance below; do not execute it just to test the warning.
Six inputs we actually checked
Scoped workflow check — 12 October 2026 UTC: we entered the following strings into the live browser-local checker and read its output. These are observed UI results, not a safety ranking. The made-up path and repository are labelled test strings; the warning domain is not clickable.
| Input string | Observed classification | What this establishes |
|---|---|---|
https://www.videolan.org/vlc/ |
Listed official host | The listed VideoLAN host matched. Select the file by following the publisher’s own download route; a host match alone is not a file verdict. See our VLC file-choice guide and three measured Windows ZIP examples. |
https://www.videolan.org/not-a-verified-download |
Listed official host (hypothetical path) | The result was the same host match. We made up this path and did not request it. The checker did not verify that the path exists or contains a download. |
https://downloads.videolan.org/ |
Name-similarity hint | This subdomain was not verified in the checker’s list. The similarity result does not establish impersonation; confirm any subdomain from the publisher’s linked route. |
https://downloads.example.org/app.exe |
Not in the list | This is a reserved example-domain test string. An unknown result supplies no evidence for either safety or malware. |
7zip[.]com (entered as a public URL) |
Cited historical report | The result cited Malwarebytes and its 9 February 2026 report. We did not open this domain or scan a current file. |
https://github.com/example/OrcaSlicer |
Not in the list (shared host) | This is a hypothetical owner/repository test string. The result did not establish the owner or repository. Follow the project’s own repository link and compare both parts. |
The warning example points to Malwarebytes’ dated 7-Zip investigation; use 7-zip.org as the project source. We did not retrieve or execute the reported installer. Read our dated input/output record and test limits for the six observations.
This check does not revalidate every old source anchor or listing in the article or tool. The earlier documentation review remains dated 4 October 2026. It adds no installer, antivirus, network-capture or phone-test result.
Search results can place an advertisement, a mirror or a lookalike site beside a project’s real download page. A familiar logo, HTTPS lock or exact-match domain does not establish who published a file. First establish the project’s identity, then verify the exact release and file you want.
A five-step official-source check
- Establish identity: start from a developer page or repository already linked by the project. Compare the full domain and the GitHub owner/repository pair. A repository named after the app can still belong to somebody else.
- Follow the project’s own download link: prefer its vendor downloads or release page. A publisher-approved CDN or mirror can be legitimate; what matters is the chain from the project’s page to the specific asset.
- Choose the exact file: record version, release channel, operating system, architecture and whether it is an installer, portable archive, AppImage or source archive. “Latest” can include a preview release, and source code is not necessarily a ready-to-run package.
- Record provenance: save the release-page URL, filename, publisher checksum if available, and date. File size and a project logo are useful identifying details, but neither establishes safety.
- Check integrity and signature before execution: compare the exact file with its publisher digest and inspect any signing certificate. Keep antivirus and browser protections enabled. A mismatch needs investigation before you run the file.
Do not run download-and-execute commands copied from a search snippet or a third-party post. A shell command that immediately executes downloaded content removes the opportunity to inspect the saved file first.
Real source examples, with attributed warnings
| Project | Source to start from | What the evidence establishes |
|---|---|---|
| 7-Zip | 7-zip.org | The project’s download page. A similar name or domain is not a substitute for this source. |
| Rufus | rufus.ie | The official page links release downloads. Choose the appropriate architecture and package. |
| Flyoobe | builtbybel/Flyoobe | The project README warns that flyoobe[.]com and the GitHub account github[.]com/flyoobe are unaffiliated. It identifies its own repository as the release source. |
| OrcaSlicer | OrcaSlicer/OrcaSlicer | The project README identifies www.orcaslicer.com as its official website and warns about orca-slicer[.]com and orcaslicer[.]net. |
| Windhawk | windhawk.net and ramensoftware/windhawk | A repository discussion reports a lookalike domain. The report says its link led to the real release at that time; this is not a malware-analysis result. |
These warnings are attributed to the linked projects or discussion participants. We did not retrieve files from the lookalike sites or determine their current contents. Warning domains are deliberately shown as non-clickable text. A site not endorsed by the project is a provenance problem; calling its file malware requires separate evidence.
For the Flyoobe release and its source-publication limitations, see the Flyoobe verification guide. For OrcaSlicer sources and the exact retained Windows file we previously inspected, see the OrcaSlicer download guide. Do not transfer a test result from one version, platform or package to another.
Compare SHA-256 without running the installer
On Windows, Microsoft’s Get-FileHash documentation describes hashing the file you already saved. Replace this example path with that exact file:
Get-FileHash -LiteralPath 'C:\Downloads\installer.exe' -Algorithm SHA256This is a documentation example, not output from a downloaded sample. Compare all 64 hexadecimal characters with the digest supplied for the same asset, not a different language, architecture or portable version. GitHub’s release-asset digest announcement describes SHA-256 values exposed in release pages and APIs. If no digest is available for the selected asset, record that limitation; do not substitute a checksum from an unrelated build.
A matching digest establishes that your bytes match the referenced digest. It does not establish that the software is harmless, that the publisher account was uncompromised, or that your chosen source was authentic. A checksum supplied by the same impostor who supplied the file cannot solve the identity problem.
A mismatch can also arise from comparing different official files. The two-official-installers case study demonstrates why filenames and packaging must be checked before declaring a mismatch malicious. You can use our SHA-256 file checker or the command above; neither is an antivirus scan.
Inspect the Windows signing certificate separately
Use Properties → Digital Signatures when that tab is present, or Microsoft’s Get-AuthenticodeSignature command:
Get-AuthenticodeSignature -LiteralPath 'C:\Downloads\installer.exe' | Format-List Status,StatusMessage,SignerCertificateInspect the actual certificate subject and status, not just a “signed” badge on a webpage. A valid signature binds a file to a signer under the signing system; it is not a general safety guarantee. An unsigned open-source executable is not automatically malicious either. A signature attached to a Git commit or release tag is separate from an Authenticode signature on the downloaded executable.
Read our certificate inspection guide for interpretation. Our earlier static-file records cover their exact named assets and dates only. This article adds no new download, signing, installation or runtime test result.
If you already downloaded a suspicious file
If it was not run: do not execute it to “see whether it works.” Record its source and filename, compare against the real release, and scan the saved file with your configured antivirus if needed. Re-download from the established publisher if provenance remains uncertain. Do not bypass SmartScreen or add an antivirus exclusion just to make it launch.
If it was run: downloading from an unendorsed source alone does not prove compromise, but execution increases the need to investigate. Microsoft’s Windows Security guidance provides full, custom and Microsoft Defender Offline scans under Virus & threat protection → Scan options. Offline scanning restarts the PC; save your work first, then review Protection history. Use your security product’s own instructions if another antivirus is active.
If security tools identify compromise or there are concrete signs of account theft, stop using the affected device for sensitive sign-ins, use a trusted device for recovery and seek appropriate incident-response help. Removing the visible application or obtaining one clean scan does not prove every change has been reversed. Keep detection details rather than guessing which program caused them.
A record you can keep with each download
- Official project page and owner/repository pair.
- Release version, stable/preview channel and published asset URL.
- Exact filename, OS/architecture and file size.
- Publisher digest and independently measured SHA-256, or an explicit missing-digest note.
- Signature status and signer for the executable, where applicable.
- Date and scope: downloaded only, statically inspected, or actually installed and tested.
Keep those scopes separate. A record of a hash comparison is useful evidence about bytes; it cannot honestly be labelled “tested safe.” For boot-media choices see the USB-tool decision guide, and for project-specific injection/mod behavior see Windhawk’s source and mod checks.
