Add verify strategy for ASLR exclusion step

[26zl]

This PR completes and corrects the ASLR exclusion step by implementing the missing verify and remove strategies.

While working on this, I found that RetrieveSecurityConfigurationFromRegistryByName does not correctly match entries when full file paths are used together with FilterFullPath and GUID-based IFEO subkeys. As a result, verification returned false even when exclusions were properly applied.

Verification now uses RetrieveSecurityConfigurationListFromRegistry with explicit full-path matching, checking that both ForceRelocateImages and OverrideForceRelocateImages are correctly configured via the API properties. When no incompatible files are currently detected by scanning, verification checks whether ASLRExclusions exists under HKLM\SOFTWARE\HardenSystemSecurity to preserve previously stored state.

The remove strategy follows the same identity-based logic. It reads stored paths from HKLM\SOFTWARE\HardenSystemSecurity, enumerates the corresponding IFEO GUID subkeys, and deletes only entries that match the exact FilterFullPath plus the expected mitigation signature (i.e., MitigationOptions where byte[1] == 0x06 and the remaining relevant bytes are unset). This prevents accidental removal of unrelated executables or interference with other mitigation settings. A two-pass approach is used to avoid modifying the registry collection during enumeration and to handle access limitations safely.

I tested the full apply → verify → remove cycle on clean Windows installations, both before and after installing the affected programs, including partial states and persistence across restarts. The behavior is consistent and limited to the intended exclusions.

I also simplified the MSYS2 reference (previously MSYS2/MinGW) and made minor improvements in BinarySecurityAnalyzer, including a PATH check, removal of duplicate recursive scanning logic, and optimized use of the existing Rust-based scanner.

I also noticed that the PSScriptAnalyzer badge in the README references powershell.yml, but that workflow file does not currently exist under .github/workflows. Just mentioning it in case you'd like to clean it up.

If you would prefer this separated into two PRs (lifecycle logic vs. scanning improvements), I can split it accordingly. Otherwise, please let me know if you would prefer any adjustments or a different approach.

Some screenshots of the testing part:

[HotCakeX]

Hi, thanks for the PR, i reviewed it.

I see the Apply part writes registry keys to the system under the app's name which is not ideal. The app should never use registry like legacy programs do to save persistent configurations. Even if we used the app's own registry hive or local cache, it would be removed from the system along with the app during uninstallations, rendering verification and removal steps relying on them impossible.

Maybe only implement the Verify step and leave the Remove step for the dedicated page i'll add to the app later on to keep things simpler :)

[26zl]

Hi, thank you for the detailed review and for clarifying the architectural direction. It makes complete sense to me.

You're absolutely right about avoiding persistent state under HKLM. I agree that storing app-managed configuration there introduces unnecessary coupling and complexity, especially if uninstall behavior or future restructuring changes underlying assumptions. My bad😅. Keeping this flow stateless is clearly the cleaner and more robust approach.

I've updated the PR accordingly. The ASLR step now implements Apply and Verify only. Apply continues to configure per-process exclusions with ForceRelocateImages=OFF and override enabled. Verify uses RetrieveSecurityConfigurationListFromRegistry with explicit full-path matching and validates both ForceRelocateImages=OFF and OverrideForceRelocateImages=true. When no incompatible executables are detected during scanning, Verify returns false, since nothing has been applied. I've removed Remove logic from this flow.

When I originally worked on the Remove step, I first explored a stateless approach based on iterating all IFEO entries and matching GUID subkeys by mitigation signature (byte[1]=0x06, all other bytes zero) combined with FilterFullPath presence. While it worked for entries created by our Apply step, the core limitation was that it could not reliably distinguish our entries from other entries that happen to share the same minimal signature. That case is rare, but still possible, so it could unintentionally remove exclusions set by other tools or manual configuration. Because of that limitation, I moved to a persistent-state approach that tracked applied paths under HKLM, which is what I originally pushed in this PR. I've since pushed the stateless implementation to a separate branch for reference: https://github.com/26zl/Harden-Windows-Security/commit/5d6198d687882526415b2d675a327f063f5776c7.

After your feedback, I now agree that neither approach belongs in this flow. Anything that modifies mitigation entries should be extremely conservative and ideally centralized in a dedicated UI context. I'm really looking forward to that page and your implementation approach!🤩

The BinarySecurityAnalyzer improvements are still included in this PR: duplicate recursive-scan fix, PATH-based MSYS2 discovery, and the EndsWith correction for GitHub Desktop git-root detection. If you prefer those isolated into a separate PR for review clarity, I'm happy to split them. Please let me know if you would prefer any adjustments or a different approach.

Thanks again for the guidance. And sorry for the hassle! I truly appreciate the direction and the review.

[HotCakeX]

Removed the unnecessary badge from the readme, thanks for catching that: https://github.com/HotCakeX/Harden-Windows-Security/commits/main/

[HotCakeX]

Also yes would you please remove the part that touches the BinarySecurityAnalyzer file? I wanna refactor it differently with some other changes later, let's keep this PR focused on implementing the Verify strategy. thank you!

[26zl]

Also yes would you please remove the part that touches the BinarySecurityAnalyzer file? I wanna refactor it differently with some other changes later, let's keep this PR focused on implementing the Verify strategy. thank you!

Ofc! Done👌 Hope the change to just MSYS2 in the UI is okay with you, as it makes more sense. Since MinGW is just one of many toolchains within it.

[HotCakeX]

Also yes would you please remove the part that touches the BinarySecurityAnalyzer file? I wanna refactor it differently with some other changes later, let's keep this PR focused on implementing the Verify strategy. thank you!

Ofc! Done👌 Hope the change to just MSYS2 in the UI is okay with you, as it makes more sense. Since MinGW is just one of many toolchains within it.

Awesome, thank you very much, tested and works correctly, merging now 😊

[26zl]

Also yes would you please remove the part that touches the BinarySecurityAnalyzer file? I wanna refactor it differently with some other changes later, let's keep this PR focused on implementing the Verify strategy. thank you!

Ofc! Done👌 Hope the change to just MSYS2 in the UI is okay with you, as it makes more sense. Since MinGW is just one of many toolchains within it.

Awesome, thank you very much, tested and works correctly, merging now 😊

Perfect! Glad to hear that, thanks!🤩