DEV Community: Nisse-Sec

Building a Safe Windows Hardening Tool: A Post-Mortem and Deep Dive

Nisse-Sec — Sat, 14 Nov 2026 12:25:34 +0000

I recently shared my free Windows hardening tool, WinSystemHarden, on Indie Hackers. This post is a post-mortem of that discussion.

There’s no shortage of one-size-fits-all PowerShell scripts floating around, and they often end up breaking local printers or network shares. My goal was to build a simple GUI tool with 29 core rules. It captures snapshots of the registry and ACL permissions before making any changes, with one-click rollback.

V1.3 is live right now. After posting, I got some incredibly sharp feedback from other engineers. A handful of comments laid out blind spots I hadn’t considered at all. This is my unfiltered take on what I missed, and how I plan to fix it.

Deep Dive 1: The "Half-Bricked" State on Crash

One person asked a really good question: what happens if the machine crashes or loses power mid-rule application? Does rollback still work?

Honest answer: in the current V1.3 build, snapshots only live in memory until all rules finish applying successfully. If power cuts out halfway through, that snapshot is gone. The system gets stuck in a dirty, partially hardened state.

The fix I’m working on: a session.lock workflow. I’ll write the snapshot to disk before running each rule and create a lock file. Next time the app opens and sees that lock, it prompts the user to roll back the interrupted session.

// Planned transaction logic
public void ApplyHardeningRule(Rule rule)
{
    CreateLockFile(); // Mark session as active
    SaveSnapshotToDisk(rule.CurrentState); // Persist state before making changes

    try
    {
        rule.Apply();
    }
    catch (Exception ex)
    {
        // Log error, lock remains so rollback can trigger on next launch
        LogError(ex);
    }
}

Deep Dive 2: The Edge Case That Leaves "Stray Keys"

Another question got me thinking: does rollback restore back to Windows defaults, or the exact state of the machine before hardening?

My approach is to back up the exact pre-hardening state with Registry.GetValue. It reverts to the user's original state, not a generic Windows baseline.

Then came the bug report. What if the registry key didn't exist at all before the change? My old rollback logic used reg add to write a fallback value, which creates a leftover key that wasn't there originally. That breaks clean snapshot restoration.

They were completely right. I'm adding null checks. If the snapshot value is null on restore, rollback deletes the key instead of writing a value.

// Old flawed logic: creates stray keys when original value is null
if (originalSnapshot == null)
{
    Registry.SetValue(keyPath, valueName, defaultValue);
}

// Fixed logic: delete the value if it didn't exist before
if (originalSnapshot == null)
{
    using (var baseKey = GetBaseKey(hive)) // e.g., LocalMachine or CurrentUser
    using (var key = baseKey.OpenSubKey(keyPath, true))
    {
        if (key != null && key.GetValue(valueName) != null)
        {
            key.DeleteValue(valueName); // Physically remove the stray key
        }
    }
}

Deep Dive 3: LSA Protection (RunAsPPL) and Legacy Drivers

Someone suggested adding LSA Protection (RunAsPPL) to block credential dumping from memory. But they flagged a big compatibility risk: it can break older antivirus software and smart card drivers.

I agree. If I ship this rule, it will live only under Deep mode, with a prominent warning in the UI. They also shared a neat trick: run Windows Audit mode in the background and watch Event IDs 3065/3066 to spot blocked drivers before locking in the setting.

Deep Dive 4: The Dilemma of Blocking Port 445 (SMB)

Blocking port 445 is a classic hardening step to stop ransomware lateral movement (like WannaCry). But here is the catch: many scripts just disable the LanmanServer service entirely to block it.

While this secures the machine, it immediately kills local file sharing. If you are in a small office with a NAS or a shared printer, your network is broken.

The fix: Instead of killing the service, WinSystemHarden takes a more surgical approach. It applies a specific firewall rule that blocks inbound SMB traffic from external networks, while leaving the local subnet traffic untouched. This gives you both security and functionality, but it's highly dependent on accurate ACL and firewall state restoration if things go wrong.

Deep Dive 5: "Might Break" Notes and UX Transparency

Another commenter liked the safety-first direction and suggested hover tooltips for risky rules, like disabling SMBv1.

I'm on board with this. If a user doesn't know disabling a service will take out their home NAS or shared printer, they'll easily assume the tool is harmful. I'm adding these warnings now.

Deep Dive 6: The Demand for Enterprise CIS Audits

One MSP pointed out that many IT providers would want CIS control ID export logs, to show clients proof of hardening.

It's a solid feature idea, but I'm holding off for the free version. Implementing it requires hitting the Windows Event Log extensively and correlating it with specific CIS control IDs, which is a massive performance hit. I don't want to bloat the free tool. This will likely land in a future Pro / Enterprise release.

Final Thoughts

For me, the best part of posting on IH wasn't traffic. It was getting a blunt, high-quality code review from people who actually work in this space.

These bugs and UX gaps aren't discouraging. They lay out exactly what I need to build next.

WinSystemHarden is a free tool. You can grab the current build here: https://www.nisse-sec.com/free-tools.html

How MSIX Package Isolation Broke My Windows Anti-Ransomware Tool (And How I Fixed It)

Nisse-Sec — Wed, 28 Oct 2026 06:41:28 +0000

Hey everyone,

I recently got my Windows anti-ransomware tool, WinRansomProtect, approved and published on the Microsoft Store. I assumed the review would be a standard malware scan. But the MSIX packaging model ended up forcing me to completely rework core parts of my architecture.

If you’re shipping desktop apps to the Store (especially security tools that need elevation), these are the 3 biggest roadblocks I hit, and the workarounds I landed on.

1. The In-App Update Deadlock

My tool is 100% offline. Originally, I let users click "Check Update" to fetch the newest .exe directly from my server.

Microsoft rejected this right away. The reasoning makes sense: MSIX packages cannot download and launch arbitrary external binaries for updates. If they could, the whole Store signing model would be pointless.

The fix: I rewrote the flow. When a user clicks "Check Update", it just opens my product webpage where they can download the new release manually.

2. Registry Virtualization Broke My Licensing Backup

My standalone EXE uses two places to store licensing state: a local file + a global HKLM\Software registry key as a backup. If the local file is deleted, it restores from the registry.

With MSIX, any writes to HKLM\Software get redirected into a private, isolated hive. The standalone EXE can't even see it. That broke my dual-backup design.

For the Store release, licensing state now lives only in a local file inside the package. If a user deletes it, there's no secondary backup and the trial resets. It's a real tradeoff: you get Store isolation, but lose that cross-build resilience.

3. The Ghost UI Deadlock

After passing review, I tested it on 1 physical machine + 3 VMs. It worked fine on 3 of them. But on one specific VM, it was totally unresponsive: tray icon showed, but clicking did nothing.

These edge cases are brutal. I captured a memory dump and saw the main thread was stuck. The root cause was a WMI call. I used Win32_ComputerSystemProduct to pull data for my machine-bound license. Inside MSIX on that VM, the WMI query hung indefinitely and blocked the UI thread.

The fix: I removed WMI entirely. Switched to NetworkInterface APIs and P/Invoking kernel32.dll GetVolumeInformation to generate the ID. Solved it instantly.

A few frustrating days of debugging, but it runs flawlessly now. If you're migrating a desktop app to MSIX for the Microsoft Store, hopefully this saves you some hours staring at crash dumps.

If you want to see the final result in action, here are the links:

Microsoft Store: Get WinRansomProtect
Direct Download (EXE): WinRansomProtect Setup V2.1

Building a Safe Windows Hardening Tool: ACL Backups and WOW64 Traps

Nisse-Sec — Thu, 22 Oct 2026 09:19:17 +0000

This is a technical deep-dive based on a post I originally wrote on my company blog. I wanted to share the C# implementation details here for fellow Windows devs.

We’ve all seen them. IT admins grab a popular one-click Windows hardening script off the web and push it across a fleet of office PCs, just to tick boxes for a security audit.

The intent is reasonable enough. The outcome, more often than not, is a mess.

A few days later, finance is complaining that their network printer stopped working, and an old internal ERP client can no longer talk to its database. The worst part? Most of these scripts only know how to disable and block. They ship with no real rollback logic at all. The admin ends up manually rebuilding Windows on affected machines.

If your hardening tool does not include a reliable, tested rollback mechanism, it is not really a security tool. It’s a liability waiting to break production.

Why Most Open-Source Hardening Scripts Are Risky

Windows hardening touches deep OS internals: registry keys, filesystem ACLs, system services, and firewall rules.

Most open-source scripts are little more than a long sequence of reg add and sc config commands. They may successfully close a known attack surface, but they ignore a simple reality: every endpoint runs a unique environment.

The script disables SMBv1, but the site still has an older network printer that relies on the SMBv1 protocol. It locks down a critical registry path, and suddenly Windows Update or a line-of-business application crashes.

The Hard Truth About Rollbacks

When building WinSystemHarden, we spent nearly half our development time on the rollback engine alone.

Rollback is not as simple as flipping a toggle back. Here is what it actually requires:

1. Registry & Services (the simpler part)

If we disable the Remote Registry service, rolling back means restoring its original startup state and starting it again. We log every original value and the exact reverse command for each change we make.

2. Firewall Rules (requires precision)

When we add rules to block ports like 445 or 135, rollback cannot just flush the entire firewall policy. We target and delete only the specific rules our tool created, by name.

3. ACL Permissions (the highest-risk area)

This is where many tools break systems. To block tampering, we can restrict write access on sensitive paths such as C:\Windows\System32\config or the hosts file.

If a naive rollback tries to fix permissions by blindly adding Everyone:(W) via icacls, it can destroy the original permission inheritance — and in the worst case, leave Windows unbootable.

Our approach avoids ad-hoc permission commands entirely. Before applying any hardening change, the tool captures the full ACL tree and saves it as an XML snapshot. On rollback, we import that snapshot and restore permissions exactly as they were.

Here is the actual C# logic we use to back up the ACLs via PowerShell:

private string BackupAcl(string targetPath, string backupFileName)
{
    string backupPath = Path.Combine(_aclBackupDir, backupFileName);
    string safeTargetPath = targetPath.Replace("'", "''");
    string safeBackupPath = backupPath.Replace("'", "''");

    string psCmd = 
        $"$acl = Get-Acl -LiteralPath '{safeTargetPath}'; " +
        $"$acl | Export-Clixml -LiteralPath '{safeBackupPath}' -Force";

    int exitCode = RunPowerShell(psCmd, 60);
    return (exitCode == 0 && File.Exists(backupPath)) ? backupPath : "";
}

And to restore it, we simply reverse the process using Import-Clixml and Set-Acl. This is the only safe way we’ve found to guarantee that a rollback won't break the OS.

4. The bcdedit WOW64 Trap

Configuring DEP requires bcdedit.exe. But if your app is 32-bit running on 64-bit Windows, accessing System32\bcdedit.exe triggers file system redirection. The OS silently reroutes the call to SysWOW64, where bcdedit.exe does not exist, and the command fails.

Our tool detects this condition and explicitly calls C:\Windows\SysNative\bcdedit.exe to bypass the redirection:

if (Environment.Is64BitOperatingSystem && !Environment.Is64BitProcess)
{
    string sysNative = Path.Combine(systemRoot, "SysNative");
    string sysNativePath = Path.Combine(sysNative, "bcdedit.exe");
    if (File.Exists(sysNativePath)) return sysNativePath;
}
// Fallback to default System32 path if needed

Skip this check, and users click Harden while nothing actually takes effect.

Time-Point Rollbacks — Not Just Single Undo Actions

Many tools only let you undo one isolated setting. WinSystemHarden works with batch, time-stamped rollback snapshots.

Every hardening run creates a snapshot tagged with a timestamp. When a user finds that a hardening session broke their workflow, they do not need to comb through lengthy logs to revert individual tweaks. They just select the snapshot from the earlier run and trigger rollback. The tool reverses every change from that session, in the correct reverse order.

Try a Hardening Tool That Won’t Break Your PCs

We built WinSystemHarden to make local Windows hardening safer. It is completely free, with no feature limits.

No accounts required, no cloud telemetry or sync. It includes 29 practical hardening rules aligned with CIS and NSA security guidance. And if something breaks your workflow, the one-click rollback is always available.

👉 Download WinSystemHarden free