Free EXE Lock 8.1.0 - independent verification notes
Prepared: 2026-10-20

ENTRY POINT (run after FINAL_READY and all signing is complete)

  & .\work\exe-lock-release\FINAL-VERIFY.ps1 `
      -Payload 'C:\absolute\path\to\final\payload' `
      -ReportPath 'C:\absolute\path\outside\payload\final-verify.json'

Use a new ReportPath for each run. Existing evidence files are not overwritten.
The default expected signer is FB6A90690D343D997543CDE09534602FBE6C3B3E.
An intentional certificate change requires -ExpectedSignerThumbprint.

The script performs these gates in sequence:
1. Reject missing/empty payload, drive root and all payload reparse points.
2. SHA-256 manifest of every final payload file.
3. FreeExeLock.exe and FreeExeLock.dll: Authenticode Valid, timestamp present,
   exact expected signer. No signing, packaging or product execution occurs.
4. Existing Defender state must be Normal, service/antivirus/realtime enabled.
5. Select newest Microsoft-signed Valid MpCmdRun from official platform paths,
   with ProgramFiles\Windows Defender fallback; record its signature and hash.
6. Custom scan of exactly Payload using -DisableRemediation. This per-scan
   diagnostic option ignores existing file exclusions and does not quarantine
   the payload. It does not disable real-time protection or alter any setting.
7. Retain complete stdout/stderr in JSON and sibling text files, process exit,
   scan times, before/after Defender status, and payload-only threat history
   from the last 24 hours. Positive threat output independently fails even if
   process exit is 0. Any recent payload threat history also fails for review.
8. Recheck both signatures and the complete file manifest after the scan.
   Any changed/missing/added file fails. A detected file removed by realtime
   protection therefore cannot accidentally produce a passing release gate.

No exclusion, security-policy, ACL, service or cloud-submission command is used.
The installed engine's existing cloud/automatic submission policy is unchanged;
this verifier does not claim an offline-only engine or disable cloud features.
A PASS concerns only these exact hashes at the recorded engine/signature/time.
It is not a guarantee of no future false positives or a SmartScreen reputation.

Microsoft reference:
https://learn.microsoft.com/en-us/defender-endpoint/command-line-arguments-microsoft-defender-antivirus
https://learn.microsoft.com/en-us/powershell/module/defender/get-mpcomputerstatus
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/get-authenticodesignature

PREPARATION CHECKS ALREADY RUN (no product scan)
- PowerShell AST syntax parse: no errors.
- Missing-payload guard: FAIL at ValidatePayload, Scan=null; evidence saved in
  guard-missing-payload.json.
- Seven pure-function self-checks: English clean/positive/zero/positive count,
  Chinese clean/positive, and payload-only threat-history filtering. Results in
  verifier-selfcheck.json. The Defender cmdlet was mocked for the filter check.
- Final product scan is pending FINAL_READY.

READ-ONLY CORE REVIEW
Reviewed Contracts.cs, LockerStore.cs and NativeFileSecurity.cs as they existed
on 2026-10-20 while the engine agent continued development.

Positive design evidence:
- PendingLock recovery metadata is saved durably before changing target DACL.
- Both original and locked DACLs are retained; exceptions attempt rollback and
  retain recovery information when a change might have occurred.
- Target permissions use a retained file handle; volume+file index are checked
  during recovery. Equal SHA on a different file does not authorize restoration.
- Hard links and reparse points are rejected. Existing external DACL changes are
  not silently overwritten. Original executable bytes are not written.
- AES-GCM authenticates vault metadata; password key uses PBKDF2-SHA256 600,000
  iterations with random salt. Password changes atomically save the new vault.

Issue communicated directly to engine agent and root:
- Restore reused the new-lock target blacklist. A valid original locked file
  moved into a directory now matching that blacklist (or a future new app
  installation directory) could become un-restorable through the UI despite
  matching the saved identity. Engine agent accepted separate forRestore path
  validation and an additional moved-file QA case. Verify that final version
  retains NTFS/link/identity protections while permitting saved-DACL recovery.

Other scope/behavior notes for final documentation:
- ACL protection applies to the current Windows SID and persists after exit.
  It is not file-content encryption; administrator/owner access is not a strong
  secret boundary. Other copies of a program and other Windows users are outside
  this lock's scope.
- Running-process detection is best effort. This lock does not terminate apps.
- Recovery export exists in Contracts but an import operation did not exist at
  review time. Any exported-backup feature must explain the restoration method
  and that a backup covers only its saved point in time.

This review did not mutate Core, UI, App, protected user files or Defender state.

FINAL CORE RE-REVIEW (2026-10-20)
- Latest read-only QA evidence: work/exe-lock-engine-qa/Runs/
  20261020-043734-f4c3dc/Engine-QA.json: 66 passed, 0 failed.
- Restore path validation now separates new-lock restrictions from restoration
  while retaining local NTFS, no links, and same original file identity.
- Locked DACLs protect an explicit effective snapshot so parent changes cannot
  silently modify the lock. Originally protected DACLs restore exactly;
  originally inherited DACLs restore explicit ACEs/inheritance policy and let
  Windows regenerate current-folder inherited permissions. This distinction is
  communicated in RestoreResult and is covered by real-file QA.
- Inherited Deny entries are now conservatively rejected before changing any
  target ACL. During review, a pure in-memory ACL example showed that converting
  inherited Deny to explicit can make the ACL noncanonical; .NET already refused
  that example before a target write. No harmful target mutation was reproduced.
  The explicit front-door rejection removes the ambiguity. Evidence:
  acl-order-review.json (pure memory only; no filesystem ACL changes).
- ENGINE_QA guards both fault-injection field and invocation. Production project
  and ancestor Directory.Build configuration do not define ENGINE_QA. The QA
  project defines it explicitly for durable-write fault injection only.
- Source review found no original-EXE byte write, no equal-SHA/different-FileID
  restoration, or silent overwrite of changed third-party explicit ACEs.
- Freeze recommendation communicated to root and engine: proceed to final build,
  signing and final payload verification. Do not broaden ACL compatibility now.
