# SafeHash 3.3 user guide SafeHash checks, copies and monitors files locally on Windows. It combines checksums, manifests, ASC MHL, verified copies, background monitoring with silent-corruption detection and exportable reports. It is not a backup, antivirus or proof that a file is trustworthy. Support is provided by Codelliptica at **support@codelliptica.com**. The same guidance is available inside the app under **Help**. ## Before installing Try **SafeHash Free** first to check that SafeHash runs on your computer. The release targets Windows 11 x64 and uses the Microsoft Edge WebView2 runtime that is part of Windows 11. On a computer where WebView2 was removed, setup tells you and offers Microsoft's download page. The installers and executables are **not Authenticode-signed**. Windows can show *Windows protected your PC* or *Unknown publisher*. Check the download first: in PowerShell run `Get-FileHash .\SafeHash-Pro-3.3.1-Setup.exe` and compare the value with the included `.sha256.txt` file and with the checksum published on codelliptica.com. Then choose **More info → Run anyway** in the SmartScreen window. Smart App Control or your organization's policy can block unsigned apps; SafeHash does not ask you to disable security controls. Optional detached release signatures (`.sig`) are distinct from Windows code signing. ## Install 1. Run your edition's installer, for example `SafeHash-Pro-3.3.1-Setup.exe`, and accept the customer terms. Paid editions use `C:\Program Files\SafeHash`; SafeHash Free uses `C:\Program Files\SafeHash Free`. 2. Paid installers contain their edition's license and install it beside the app. **There is no key to type, no account and no activation server.** 3. Pro, Team and Enterprise setup starts the SafeHash background service and sets it to start with Windows, so monitoring is ready immediately. 4. Open SafeHash from the Start menu. To upgrade, run the higher edition's installer over the current one. Settings, baselines, audit records and reports are kept. If you received a license key separately, paste it in **Licensing → License key**; SafeHash always uses the highest valid edition it finds. For unattended installation, read the supplied terms, then run the installer with `/S /ACCEPTTERMS=YES` from an elevated session. `/S` alone does not accept the terms. The installer keeps the accepted text and a local receipt under `%ProgramData%\SafeHash\InstallReceipts` (administrator access required). | Edition | One-time price | Computers | Includes | |---|---:|---:|---| | Free | $0 | Any | Text and single-file checks with SHA-256, SHA-512, BLAKE3, xxHash, MD5 and SHA-1 | | Pro | $39 | 1 | Folders and batches, manifests, ASC MHL, verified copy, monitoring with bit-rot detection, reports, scheduling and CLI | | Team | $149 | 10 | Pro plus shared monitoring profiles, structured audit export and evidence ZIPs | | Enterprise | $399 | 25 | Team plus signed audit records, policy controls and hardware-token signing (beta) | A seat covers one primary Windows computer. Seats are not enforced technically; install a paid edition only on as many computers as you are licensed for. Paid editions do not expire. This is not a promise of unlimited new features, permanent compatibility or an SLA. MIT and third-party source rights remain governed by their own licenses, which are included with the app. ## Find your way around - **Verify**: check a file, text or (Pro and higher) a batch of files and folders. SHA-256, SHA-512, BLAKE3 and xxh64 are shown first; **More algorithms** holds the rest. Paste a publisher's value in **Compare a known checksum**. - **Manifests**: create a checksum inventory of a folder and verify it later. - **Reports**: fresh PDF or JSON reports of the Verify input; evidence ZIPs. - **Copy & Verify**: offload cards or folders to up to four destinations and prove every copy. - **ASC MHL**: create and verify ASC Media Hash List histories. - **Monitoring**: watch folders against an accepted baseline. - **Hardware Token**, **Performance**, **Settings**, **Licensing** and **Help** hold the remaining functions. Help includes **Check for updates** and support. Choosing an algorithm: SHA-256 is the standard; BLAKE3 is cryptographic and very fast; xxHash (xxh64, xxh3, xxh128) is the fastest and is standard for media offloads, but it detects accidental corruption rather than deliberate tampering. MD5 and SHA-1 are for matching legacy published values. ## Important migration from 3.1.0 and earlier Preserve your original files, old manifests and audit data before upgrading. Two earlier hashing paths were incorrect: - The old SafeHash **KangarooTwelve/K12** implementation substituted SHA3-256. SafeHash v1 manifests containing K12 are rejected with a regeneration message. - The old optimized path for files **larger than 50 MiB** could produce a digest of chunk digests instead of the named standard algorithm. Recompute affected values from trusted original files. Do not merely rename an old digest. 3.2.0 and later use genuine K12/KT128 with 32 output bytes and an empty customization string. BLAKE2b in SafeHash means **BLAKE2b-256**. Other algorithm parameters are identified in the app and manifests. Old monitoring snapshots are not automatically accepted as trusted baselines. After upgrading, inspect the current files and explicitly create a new baseline from known-good content. Starting the service or opening the app will not bless changed files. Existing unsigned audit history, if imported, is explicitly marked as a legacy prefix; adding a new signature does not authenticate its past origin. Setup stages the complete new app before replacing the old one. On upgrade it preserves the previous app directory beside the installed app, named `SafeHash.previous-` (or `SafeHash Free.previous-`). Upgrading from 3.2 archives its large bundled browser runtime with the previous app; delete that archive after checking the upgrade to recover the space. Keep your own backup of customer data too: this preserved directory is not a backup of your user folders or machine audit store. Before the new service starts, setup can restore the previous app after a failed replacement. Once it commits the new version, it retains that version even if the service cannot start, because new audit records may already use the new format. Do not manually run the old service against the updated audit store. If setup reports a recovery problem, preserve the named `.setup` and `.previous-` folders and contact support. Re-running the full installer can recover an interrupted replacement; do not delete its recovery files first. ## Hash text, files or folders Select the appropriate input mode, choose algorithms and run the check. For routine integrity checks, SHA-256 is a straightforward default. MD5 and SHA-1 are available for legacy compatibility and should not be relied on against deliberate collision attacks. The result identifies the source and algorithm. Batch processing is a Pro-and-up feature. Recursion applies only when selected. Repeated selections are not meant to duplicate the same file's results. A failed input is reported; do not treat a partial batch as a complete verification. Close applications actively writing a file before hashing it. On Windows, SafeHash obtains a stable read and refuses incompatible writers. For databases, virtual-machine disks and other live files, use an application-approved snapshot or backup rather than assuming an arbitrary live read is consistent. Long operations show progress. Byte counts refer to the **current file**, not a guessed percentage of a whole folder. Some operations cannot know their total in advance. **Cancel** requests cancellation; wait until the app confirms it has stopped. A completed export may already exist if cancellation was requested at the final publication or hardware-signing stage. ## Generate and verify manifests A manifest records a selected folder's file paths, algorithms and hashes. Generate it from known-good data and keep a trusted copy. New SafeHash manifests use format v2 and explicitly label every algorithm. The output manifest and its temporary staging file are excluded from their own calculation; ordinary files are not skipped just because their names contain "hash" or "manifest". Verification checks every record. Empty manifests, malformed lines, duplicates, unsafe paths, missing files and mismatched digests must be resolved. Select the correct base folder when verifying a moved copy. An entirely successful result requires actual file entries and matching results for all of them. ## Verified copy **Copy & Verify** (Pro and higher) copies files or whole folders to one to four destination folders or drives. 1. Add the sources (camera cards, folders or files) and the destinations. 2. Choose the checksums. xxh64 is fast and is what most DIT tools use; add SHA-256 when you also want a cryptographic record. 3. Keep **Write an ASC MHL history** on to add a *transfer* generation to each copied folder, then start the copy. SafeHash reads each source once while writing every destination, then reads every destination back and compares it with the source checksum. Files are written under a temporary `.safehash-partial` name and renamed only when complete. Existing destination files are never overwritten: an identical file is accepted after verification and a different file is reported. Modified times are kept. Links and special files are skipped and listed. A JSON report with every file's checksums, and a readable `.txt` summary, are saved under `%AppData%\SafeHash\exports\copy-reports`. ## ASC MHL ASC Media Hash List (ASC MHL) is the Academy's format for recording checksums of camera media and deliveries. Its history lives in an `ascmhl` folder inside the card or delivery folder, with one generation per copy or check and a chain file that detects edited generations. - **Create a generation** (Pro and higher): choose the folder and one or more formats (xxh64, xxh3, xxh128, md5, sha1 or c4). SafeHash hashes every file, verifies files recorded in earlier generations, writes directory and root hashes the same way as the reference `ascmhl` tool and appends to the chain. A generation is written even when problems are found, so the record is complete; the result lists every failed or missing file. - **Verify** is read-only. Choose a folder with an `ascmhl` history, or a standalone `.mhl` file (ASC MHL manifest or legacy MHL 1.1 with md5, sha1 or xxhash64be values). The result lists verified, changed, missing and unrecorded files and any edited generation. Histories written by Silverstack, ShotPut Pro, Hedge, YoYotta and the `ascmhl` tool can be verified and extended. Nested card histories inside a larger folder should be recorded card by card. The CLI offers the same operations: ``` safehash-cli copy --to E:\ --to F:\ --mhl -a xxh64,sha256 "D:\A001_CARD" safehash-cli mhl create --formats xxh64 "E:\A001_CARD" safehash-cli mhl verify "E:\A001_CARD" ``` `copy` and `mhl` return exit code 2 when a check finds problems. ## Configure background monitoring 1. Pro and higher installers start the service automatically. If it was stopped, open SafeHash as administrator and choose **Enable background service** in Licensing. 2. Choose the folders, algorithms, recursion and depth. Depth zero means unlimited recursion; turn recursion off to check only the selected directory level. 3. Save the configuration. Check the files, then explicitly establish the baseline you are accepting as known good. 4. Start monitoring. It performs a complete comparison on startup. Configure the optional schedule for subsequent full checks and autostart if required. 5. Read alerts and the last completed verification time. Use **Verify now** after restoring a file to the accepted contents. Changed, new, deleted, renamed and unreadable files are findings. Starting or restarting monitoring does not reset the baseline or make findings disappear. The monitor keeps unresolved findings across restarts. Restoring accepted bytes and verifying resolves the relevant finding; accepting a new complete baseline is a deliberate decision to trust the current state. After accepting a new baseline while monitoring is already running, use **Verify now** to complete a fresh comparison. Starting an already-running monitor does not itself perform that additional verification. "Protected" means the configured monitoring scope has an accepted baseline, a completed current verification and no unresolved findings or reported integrity errors. It is not a security verdict for the entire computer. A stopped service, missing baseline or incomplete scan must not be read as protection. Filesystem notifications alone are not exhaustive; reconciliation and scheduled checks are part of the workflow. Keep backups separately. Enterprise policy locking can restrict configuration changes and stopping monitoring through SafeHash. It is an application policy; a Windows administrator can still administer the computer and its services outside the app. In Settings, Team and Enterprise can prepare the saved monitoring settings as JSON, copy them to a local file, and load/apply that file on another machine. Review its paths first. Applying a shared profile replaces monitoring settings and requires an explicitly accepted new baseline. Unsupported legacy ignore or notification settings must be removed before applying; they are not silently ignored. Enterprise policy controls also appear in Settings. Unlock the existing policy before replacing its shared service license. Requiring monitoring needs autostart, a running monitor and an accepted baseline. A damaged policy blocks changes until an administrator repairs it. ### Possible corruption (bit rot) If a monitored file's content no longer matches the baseline but its size and modified time are exactly unchanged, SafeHash reports **Possible corruption** instead of an ordinary change. Normal editing always updates the modified time, so this pattern usually indicates silent data corruption from a failing drive, cable, controller or storage system, or a tool that deliberately restored the timestamp. Restore the file from a known-good backup and check the drive. Scheduled verification of archives, NAS shares and backup drives is the most effective way to find this early. ## Reports and signatures Choose **Text**, **File** or **Batch** as the report source, then PDF or JSON and an output location. Report generation recomputes the selected input at that time; it does not silently reuse an old on-screen result. Every source/algorithm pair is retained. A failed input prevents a successful complete report. PDF hashes wrap without being truncated. Unicode file names use reversible quoted escapes in PDFs to avoid silent missing glyphs; JSON keeps native Unicode. The report states its generation time and scope. **Show output in folder** reveals the saved file in Explorer without executing it. Enterprise's optional hardware signing is a beta feature. It can create detached report or manifest signatures using a compatible, configured token and certificate. On Windows, SafeHash uses compatible signing certificates available to this Windows account through a Windows smart-card provider. A compatible YubiKey also needs this provider and certificate setup; inserting the device alone does not make it available for signing. Configure the certificate for the Windows account running SafeHash, then use **Refresh** in **Hardware Token** and select the intended certificate. Physical-device compatibility still requires validation with your exact setup. The signed file is accompanied by `.sig` and `.crt` files. Keep all three together. Signing and cancellation are checked before publishing the new report or signed manifest. A signing failure preserves the previous files. A disk failure during the final publication can leave an incomplete set and is reported as an error; verify all three before use. Save signed manifests outside their source folder so their signature companions do not become inputs to the manifest being regenerated. A valid signature with the adjacent certificate proves consistency with that certificate's key. It does not identify the signer unless you obtain and compare the expected SHA-256 certificate fingerprint through an independent trusted channel. Certificate validity is checked against the current local clock; no independent signing timestamp or online revocation check is implied. Test your particular token, reader, provider and certificate before relying on this feature. Never place token PINs in support messages or shared command history. ## Audit and evidence packages Background service records and manual desktop records have separate scopes: - Service configuration, monitoring and service actions use the machine audit under `%ProgramData%\SafeHash\audit`. - Manual desktop exports and signing use the current user's audit under `%AppData%\SafeHash\audit`. **Export service audit** in Settings requires an administrator session connected to the background service. Local evidence exports can include the current user's audit without access to the machine audit. Review the indicated scope before sharing an export; one store does not include the other store's events. An export names its source store. Team structured activity exports are explicitly unsigned. Enterprise signed exports include a local Ed25519 signer, checkpoint and an explicit count of any unsigned legacy prefix. The Windows signing key is protected for its local account using DPAPI. Back up the complete store before machine changes; copying an encrypted key to another account does not make it usable there. Keep an independently trusted public-key fingerprint if you need to establish the export's signer. A valid old export can be replayed and does not prove freshness. Local timestamps are not independent timestamps. Removing a retained key/checkpoint or truncating a log is an error, not an invitation to silently reset its history. Contact support before changing a damaged audit store. An evidence ZIP includes the actual target files and attachments you selected, case/operator information and a complete SHA-256 inventory. It may include the scoped audit where the edition supports it. Missing attachments, incomplete signature pairs, unsafe paths and files that change during capture cause failure. Exported ZIP contents are independently checked after creation. Review the package before sharing: it contains file contents and can contain private paths or identifying case details. Inventory hashes establish content integrity. They do not establish origin against an attacker replacing both the files and inventory. Operator-entered custody information is a record you supply, not a guarantee of a complete legal chain of custody or court acceptance. ## CLI and repeatable work The bundled CLI is `safehash-cli.exe`. Run `safehash-cli.exe --help` for the current command list and add `--help` to a subcommand for its options. Automation features require Pro or higher; license management and Explorer hashing are also available to every paid edition. Prefer license-file import to placing a key in command history. Monitoring commands address the actual background service. Baseline and verify commands use jobs; job-status and cancel report the real operation. An interrupted client does not by itself prove that a server job stopped. Keep the job ID and check its final status. For independent audit or evidence checking, consult the CLI verification commands and supply trusted signer fingerprints where required. The Explorer **Hash with SafeHash** action opens a console that keeps its result or error visible until you press Enter. Ordinary CLI commands do not pause. Use the full offline installer to install or remove Explorer integration and the Windows service; old standalone integration/service setup commands are unsupported. ## Performance measurements Quick mode hashes 1 MiB and 10 MiB test files. Full mode adds larger sizes up to 1 GiB, so it takes longer and needs temporary disk space. Both use the selected canonical algorithms and a bounded iteration count. Values are measurements of this computer under its current load, storage and cache conditions; they are not portable performance guarantees. Memory measurements reflect process allocations during the benchmark and are not a precise peak-memory measurement of one hash. ## Troubleshooting and maintenance - **Unknown publisher or blocked app:** consult your Windows or organizational policy and verify the official download. Do not disable protections as a fix. - **Blank window or app will not start:** SafeHash uses the WebView2 runtime built into Windows 11. If it was removed, install Microsoft's Evergreen WebView2 Runtime and start SafeHash again. - **Service unavailable:** verify installation, enable the service from an administrator session and check the machine entitlement. Local manual work is separate from service availability. - **Locked or unreadable file:** close the writing application or choose a safe snapshot, and check the signed-in user's access. - **Baseline required:** review trusted files and explicitly establish a baseline. Repeatedly pressing Start does not accept one. - **Audit invalid:** preserve the complete files and contact support. Do not delete a checkpoint, signing key or old record to make a status indicator turn green. - **Signing unavailable:** check compatible hardware/provider/certificate setup. Mock-token tests do not demonstrate that a physical device works. Maintenance releases focus on defects and security. Use **Help → Check for updates** to see whether a newer version exists; SafeHash never checks on its own. Install updates by running the new installer. No continuous feature-update subscription or enterprise response-time guarantee is included. When requesting help, include the SafeHash version, Windows version, action and error. Remove confidential data from diagnostic excerpts. ## Uninstall and retained data Use Windows **Installed apps** or the SafeHash uninstaller. It removes the app, its edition license file, shortcuts, Explorer entry and service registration. Imported licenses, baselines, audits and saved exports are preserved to avoid accidental loss. Their usual locations are `%AppData%\SafeHash` for the signed-in user and `%ProgramData%\SafeHash` for the service. Exports may also be in locations you chose. Terms receipts and previous-installation archives are also preserved. Uninstall does not erase unrecognized files you placed in the app's top-level directory. After preserving anything you need and uninstalling, you can remove those exact SafeHash data folders manually; machine data requires administrator access. Deleting them can permanently remove evidence or the ability to verify/reuse local signing history. Other Windows users have their own separate user folders. After a successful upgrade and verification, an administrator may separately remove the exact previous-installation archive once any customer files in it have been backed up. Keep it while an upgrade or service problem is unresolved. Read `COMMERCIAL_TERMS.txt`, `PRIVACY_NOTICE.txt`, `LICENSE` and `THIRD_PARTY_LICENSES.md` for the associated customer terms and component rights.