Repository navigation
Releases: ryanportfolio/SecureWall
Release list
SecureWall v0.4.1
SecureWall v0.4.1
Website: https://secwall.org/
This is an unsigned alpha prerelease for exploratory testing. It fixes the service crash that made every v0.4.0 install fail with MSI error 1722, shows the logs when setup fails, and replaces the setup pages. It is not signed or end-to-end verified. The changes below were checked with unit tests, builds, installer checks and code review only; none of them has been tested on a live installation yet.
Changes
Service start fix
- v0.4.0's service stopped every time it started, so the install rolled back with MSI error 1722. It set a Windows Filtering Platform option through its dynamic session, which Windows refuses (
FWP_E_DYNAMIC_SESSION_IN_PROGRESS). The service now sets that option through a short-lived ordinary session. - That option (collect network events for inbound broadcast and multicast) is shared with other programs and survives reboots. The service now tries to put back the value it found when it stops normally; if that fails, the value it set stays.
- Firewall engine errors now include the Windows error text along with the code.
When setup fails
- The failure page has two buttons: Open SecureWall log opens
%ProgramData%\SecureWall\logs\installer.log, and Open setup log opens the Windows Installer log. Every SecureWall setup now writes that log to%TEMP%(MSI*.LOG). Each opens in your default text viewer, so Ctrl+A and Ctrl+C copy the whole log for a report. - When the SecureWall service fails to install or start,
installer.logalso holds the service's status and exit codes and theservice.logentries written during that attempt. Before this it said only that the service did not start in time. Setup can also stop earlier, for example when TinyWall is still installed or SecureWall rejects its data folder; then the reason is in the setup log, in an earlier message, or in the Windows Application event log under sourceSecureWall.
Setup pages
- Setup shows its own pages: welcome, before you install, ready to install, progress, finished, cancelled and failed. They replace the main wizard pages inherited from TinyWall and WiX, including the "Remote Installations" page. Standard Windows Installer prompts (preparing, files in use, out of disk space, error messages) remain.
- The license page no longer asks you to accept the GNU GPL v3; the license itself says acceptance is not required to receive or run the program. The ready page shows the notice and a View license button.
- The cancelled page says that a rollback step can fail and leave external traffic blocked, and points to the recovery section of the README.
Other changes
- New icon set drawn for SecureWall, replacing the third-party icons inherited from TinyWall. A grey "?" shield marks the Unknown state (service unreachable).
- The Settings GitHub button and the About link open the SecureWall repository instead of upstream TinyWall.
Downloads and installation
Use SecureWall_x64.msi on Intel/AMD 64-bit Windows, SecureWall_arm64.msi on Windows on ARM, or SecureWall_x86.msi on 32-bit Windows. Verify the download against SHA256SUMS.txt. All installers are unsigned. Keep local console access and recovery installers available offline. Service loss can leave external networking blocked, including DNS and DHCP.
Upgrading. In-place upgrades and repair are still unsupported. If an earlier SecureWall is installed, remove it from Settings > Apps, then install v0.4.1. If a v0.4.0 install failed and its rollback finished, nothing needs removing. If setup then says that SecureWall service deletion is pending, or that an existing SecureWall service must be removed, rollback did not finish its cleanup: close Services and other service-management tools and restart Windows, then try again. If that does not help, follow failed first-install rollback at the local console. The existing %ProgramData%\SecureWall folder is reused if it passes validation. If v0.3.0 is installed, read the upgrade notes in v0.4.0 first.
Switching from TinyWall. Follow before switching first. Uninstall TinyWall with its own uninstaller and reboot before installing SecureWall; setup refuses to run while TinyWall or its firewall provider is still registered. To go back to TinyWall later, uninstall SecureWall first and follow rolling back to TinyWall.
Collect a diagnostic report
Read the live testing guide and coverage map. Download the source archive for this tag to obtain tools/diagnostics, or use a checkout of this tag. Run the collector with Windows PowerShell 5.1 as described in its README. It creates a local report and does not upload it.
Logs record software outcomes and observed filtering decisions. They do not prove packet delivery, absence of boot/crash leakage, installer rollback, hostile filesystem resistance or power-loss durability. The bundled blocklists do not automatically update. Review normal-use logs before drawing conclusions about live behavior.
SecureWall v0.4.0 (alpha, unsigned installers)
SecureWall v0.4.0
Website: https://secwall.org/
This is an unsigned alpha prerelease for exploratory testing. It adds fixes ported from upstream TinyWall, the fixes from a pre-switch security review, and the removal of Learning mode and the TinyWall update code. It is not signed or end-to-end verified. The changes below were checked with unit tests, builds and code review only; none of them has been tested on a live installation yet.
Changes
Fixes ported from upstream TinyWall
- Password storage uses a stronger format (random 16-byte salt, SHA-256, 200,000 iterations) and a constant-time comparison. A password set by an earlier build still works and is converted to the new format the next time you unlock. The password file is readable only by SYSTEM and Administrators.
SecureWall.exe /uninstallno longer fails in the password dialog while SecureWall is locked.- The tray icon comes back when Explorer restarts while the controller runs elevated.
- Network Activity shows why a connection was blocked, and its context menu has Copy path and Open folder. Open folder selects the file in Explorer and never runs it.
- The Windows Defender special exception includes
MpCmdRun.exe, Defender's command-line tool, which is used for signature updates. - Dark-mode contrast, icon, focus and context menu fixes; Escape closes the Application Finder; the dead "Search on ProcessLibrary" item is gone.
- Several firewall-engine cleanup paths release their handles correctly after an error.
Security review fixes
- A failed automatic reload no longer stops the service for good and leaves the PC offline until someone restarts it or reboots. When nothing the committed policy relies on has changed, that policy stays in force and the service retries up to three times. Otherwise, including a failed rule expiry or a failed network adapter check, SecureWall withdraws its runtime permissions at once: external traffic is blocked, including DNS and DHCP, while the running service rebuilds its policy. After five failed rebuilds the service exits with an error and Windows restarts it after 5, 30 and 60 seconds. Windows applies the restart setting after the next reboot following installation.
- The always-on deny baseline is no longer registered under the service's name, so it should still load at boot when the service is disabled or set to manual (for example after a failed install). Microsoft's documentation is inconsistent on this point, and it has not been checked on a VM yet.
- If SecureWall rejects its own data folder as unsafe, removing this version from Settings > Apps now works: a SYSTEM-only emergency release stops and disables the service, restores Windows Firewall and audit settings, and deletes only SecureWall's firewall objects. The rejected folder is left in place as evidence.
- A failed first install rolls back without leaving the PC more open than before, and removes the service registration that used to make the next install fail. If the service cannot be stopped, rollback stops before cleanup and the registration stays. If Windows Firewall's rules cannot be restored, or SecureWall's firewall objects cannot be removed, the deny baseline stays and external traffic stays blocked until you fix the cause from the local console, as described in SECURITY.md.
- Optional startup checks (a leftover TinyWall service found after startup, a missing or locked hosts file, WSL adapter permits) are logged and reported instead of taking the firewall offline. Install and service start still refuse to run next to TinyWall.
- SecureWall uses its own firewall sublayers instead of TinyWall's and refuses to install or start when TinyWall's firewall provider or another program's filters are in its sublayers. The error names each object and how to remove it.
- The blocked-connection popup: Enter no longer allows; Allow stays disabled until the popup has been visible and unmoved for about a second and its risk checks have finished. Clicking Allow while locked asks for the password, then relocks afterward, including after a cancel or wrong password. A popup timing out no longer keeps SecureWall unlocked longer.
- Allowing a program no longer removes a "local network only" restriction from an existing rule for it, and a rule for one Windows service no longer replaces a rule covering all of
svchost.exe. - For a Windows service that has no service SID of its own, the popup disables Allow and explains how to give it one, instead of saving a rule that can never match. One unreadable service registration no longer disables Allow for every program.
- The optional AI lookup works without a manual exception for
SecureWall.exe. While it is turned on, SecureWall adds a permit forSecureWall.exelimited to outbound TCP port 443, to any destination, from signed-in accounts; the SYSTEM service cannot use it. Endpoints on other ports are rejected. AI answers are size-limited and labeled as AI-generated. - Address-scoped rules (local subnet, gateway, DNS) keep matching when rebuilding their address lists fails partway.
- Guard and maintenance failures are written to the Windows Application event log (event IDs 1000 and 1001).
service.logandinstaller.logare rotated to.old.loginstead of being cleared. - Reinstalling delivers the shipped application database and blocklist: install replaces
profiles.jsonandhosts.bckwhen they differ from the shipped copies. Your configuration, password and recovery files are not touched.
Removed
- The TinyWall update feed and update client are removed, not just disabled. SecureWall never contacts TinyWall's update server. Install new versions from a trusted MSI. An old
AutoUpdateChecksetting in saved settings or an imported.twsfile is ignored. - Learning (Autolearn) mode is removed; blocked-connection prompts replace it. A saved configuration or imported TinyWall
.twsfile that starts in Learning mode loads in Normal mode. Rules learned by earlier builds stay until you delete them.
Emergency release logging
If the emergency release run during removal fails, each failed step now writes one Error event 1001 from source SecureWall to the Windows Application event log, followed by one summary event with the exit code. Before this, a failed removal showed only MSI error 1722 with nothing naming the step.
Downloads and installation
Use SecureWall_x64.msi on Intel/AMD 64-bit Windows, SecureWall_arm64.msi on Windows on ARM, or SecureWall_x86.msi on 32-bit Windows. Verify the download against SHA256SUMS.txt. All installers are unsigned. Keep local console access and recovery installers available offline. Service loss can leave external networking blocked, including DNS and DHCP.
Upgrading from v0.3.0. In-place upgrades and repair are still unsupported. Remove v0.3.0 from Settings > Apps, then install v0.4.0. The existing %ProgramData%\SecureWall folder is reused if it passes validation: your configuration and password carry over, and profiles.json and hosts.bck are replaced with the shipped copies. After upgrading, review your exception list. Earlier builds could learn an svchost.exe rule that allows all TCP and UDP ports for every hosted service; it is not removed automatically. v0.3.0 used TinyWall's sublayer GUIDs; if any of those sublayers are left behind and still belong to SecureWall, the v0.4.0 install or a later uninstall removes them. If the v0.4.0 installer fails with a generic error, check the Application event log for an Error from source SecureWall and stop there; do not change folder permissions to force the install. Removing v0.3.0 runs v0.3.0's own uninstaller, which has neither the emergency release nor the event log entries described above. If v0.3.0 rejects its data folder, its removal fails, the deny baseline stays, and nothing is written to the event log from source SecureWall (Windows Installer still logs the failed removal under its own source). In that case stop at the local console, keep %ProgramData%\SecureWall as it is, do not change its permissions, and follow legacy data and controller recovery.
Switching from TinyWall. Follow before switching first: export your TinyWall settings to a .tws file, copy %ProgramData%\TinyWall outside ProgramData, and save the SecureWall MSI and its hash offline. Uninstall TinyWall with its own uninstaller and reboot before installing SecureWall. This version also refuses to install if TinyWall's firewall provider (66CA412C-4453-4F1E-A973-C16E433E34D0) is still registered. If that happens, reinstall TinyWall, uninstall it again, reboot, and confirm netsh wfp show state no longer contains 66CA412C. To go back to TinyWall later, uninstall SecureWall first and follow rolling back to TinyWall.
Collect a diagnostic report
Read the live testing guide and coverage map. Download the source archive for this tag to obtain tools/diagnostics, or use a checkout of this tag. Run the collector with Windows PowerShell 5.1 as described in its README. It creates a local report and does not upload it.
Logs record software outcomes and observed filtering decisions. They do not prove packet delivery, absence of boot/crash leakage, installer rollback, hostile filesystem resistance or power-loss durability. The bundled blocklists do not automatically update. Review normal-use logs before drawing conclusions about live behavior.
SecureWall v0.3.0 (alpha, unsigned installers)
SecureWall v0.3.0
This is an unsigned alpha prerelease for exploratory testing. It includes the firewall hardening and optional diagnostics added since v0.2.0. It is not signed or end-to-end verified.
Changes
- Strict external blocking during service loss and startup, with hardened policy recovery, service validation and protected machine-data handling.
- A saved Enable diagnostic logging checkbox under Settings > General, off by default.
- Detailed service, policy, blocklist, hosts backup/restoration, DNS, audit, attribution and recovery observations. The read-only collector reports missing evidence, incomplete operations and recorded failures.
- Removed the inactive automatic-update checkbox and global hotkeys. Manual exception editing remains available.
- TinyWall
.twsimport remains available. Import loads the whole saved configuration, including allow/block rules and other settings. Enable diagnostics after importing an older export.
Downloads and installation
Use SecureWall_x64.msi on Intel/AMD 64-bit Windows, SecureWall_arm64.msi on Windows on ARM, or SecureWall_x86.msi on 32-bit Windows. Verify the download against SHA256SUMS.txt. All installers are unsigned.
Remove TinyWall and reboot before installing SecureWall. Existing SecureWall installations require full removal before installing this version; in-place upgrades and repair are unsupported. Keep local console access and recovery installers available offline. Service loss can leave external networking blocked, including DNS and DHCP.
Collect a diagnostic report
Read the live testing guide and coverage map. Download the source archive for this tag to obtain tools/diagnostics, or use a checkout of this tag. Run the collector with Windows PowerShell 5.1 as described in its README. It creates a local report and does not upload it.
Logs record software outcomes and observed filtering decisions. They do not prove packet delivery, absence of boot/crash leakage, installer rollback, hostile filesystem resistance or power-loss durability. The bundled blocklists do not automatically update. Review normal-use logs before drawing conclusions about live behavior.
SecureWall v0.2.0 (alpha, unsigned installers)
Warning
This is an unsigned alpha prerelease. The real-WFP, reboot, upgrade, and uninstall VM matrix in docs/HARDENING-VALIDATION.md has not been run against this build. Use only on a machine you can recover locally.
SecureWall v0.2.0 is the hardening release that followed a first-principles review of v0.1.1. It installs over v0.1.1.
Security fixes
- Bounded appId read in the WFP net-event callback. The previous unbounded read fed the path that becomes an Allow rule. Backported from upstream TinyWall 62b088f.
- Native callback handlers and the service net-event callback catch every managed exception, so a throw no longer unwinds into FWPUClnt and kills the SYSTEM service. Upstream issue #128.
- Password salt now comes from
RandomNumberGeneratorinstead ofSystem.Random. Upstream 3448b6b. - Hosts file and database updates write through a temp file and
File.Replace; the hosts lock is restored on every path. Update downloads decompress and hash in memory.
Behaviour changes
- The audit-policy lease journals the original "Filtering Platform Connection" setting to
HKLM\SOFTWARE\SecureWall\AuditRecoverybefore changing it, and restores it on service start,/uninstall, and/msi-cleanup. A crash no longer leaves failure auditing enabled machine-wide. - The block prompt warns when the executable is unsigned (WinVerifyTrust plus catalog lookup), sits in a user-writable directory, or changed in the last 24 hours. Allow rechecks that the file still exists and refuses with a logged reason when it is gone.
- The persistent recovery baseline permits DHCP and DNS (eight rules: DHCPv4/v6 request and reply, DNS UDP and TCP over v4 and v6). A stopped or crashed service no longer strands the machine without an address or name resolution. These permits sit below every runtime filter, so Normal, BlockAll, and user blocks still win while the service runs.
Known limits
- The local pipe authorization model is unchanged: image-path check, Authenticated Users pipe DACL, password lock as the only gate. See
docs/SECURITY.md, "Local IPC boundary". - Baseline DHCP and DNS permits are not scoped by process or address while the service is down.
- Upstream b741831, 3146d95, and the WFP wrapper fixes are not backported.
UPSTREAM.mdlists them.
Installers
Choose one:
SecureWall_x64.msi: Intel/AMD 64-bit WindowsSecureWall_arm64.msi: Windows on ARMSecureWall_x86.msi: 32-bit Windows
Verify the SHA-256 hash against SHA256SUMS.txt before running. Windows shows an unknown-publisher warning because these alpha installers are not code-signed. GitHub Actions builds them from this tag with pinned WiX 3.14.1, MSI ICE validation, the pure security test suite, and the installer package-contract checks.
SecureWall remains GPL-3.0 software derived from TinyWall; source and attribution are included in this repository.
SecureWall v0.1.1 (alpha, unsigned installers)
Warning
This is an unsigned alpha prerelease. It is not production-ready and has not completed the real-WFP/reboot/upgrade/uninstall VM matrix. Use only on a machine you can recover locally.
SecureWall v0.1.1 adds standard per-machine Windows installers that install and start the SecureWall LocalSystem service and tray controller.
Choose one installer:
SecureWall_x64.msi— normal Intel/AMD 64-bit Windows PCsSecureWall_arm64.msi— Windows on ARMSecureWall_x86.msi— 32-bit Windows only
Before running:
- Download the matching MSI and
SHA256SUMS.txt. - Verify the MSI's SHA-256 hash.
- Keep a local recovery path. Do not test remotely.
- When ready, uninstall TinyWall and reboot. The SecureWall installer deliberately refuses to proceed while TinyWall is installed.
Windows will show an unknown-publisher warning because these alpha installers are not code-signed. The installers are built by GitHub Actions from this tag with pinned WiX 3.14.1, full MSI ICE validation, security tests, IPC self-tests, package-contract checks, and a generated hash manifest.
SecureWall remains GPL-3.0 software derived from TinyWall; source and attribution are included in this repository.
SecureWall v0.1.0 (alpha, unsigned test build)
Alpha, unsigned, source-only. Not production-ready. Do not deploy on a machine you cannot recover.
SecureWall is a default-deny Windows firewall — a GPLv3 fork of TinyWall 3.5.1 (pinned upstream 1df71b1). In Normal mode it blocks non-loopback inbound and outbound traffic by default and prompts, per app, when something is blocked. Enforcement runs in a LocalSystem service via the Windows Filtering Platform.
What's in v0.1.0
- Default-deny (fail-closed) firewall with per-app block prompts.
- Optional, opt-in AI "what is this?" helper on the prompt (bring your own OpenAI-compatible API key; off by default; advisory only — never changes the allow/block decision).
Read before using
- No installer attached. This environment cannot build the MSIs. Build from source with Visual Studio Build Tools (MSBuild) + WiX 3.14; installers are unsigned test artifacts, not signed production packages.
- Not independently verified end-to-end. The privileged install / boot-time-filter / audit-policy / live-network matrix in
docs/TESTING.mdhas not been fully validated. The pure-logic unit tests pass (PromptWall.Core.Tests), but that is not a substitute for real-machine testing. - Some newer code is uncompiled in CI. Build locally and verify before relying on it.
- Requires an expendable Windows 10/11 VM or spare PC with local console, Administrator, a snapshot/recovery path, and any existing TinyWall removed first.
License / attribution
GPLv3. Original TinyWall © Károly Pados; SecureWall modifications © 2026 contributors. Not endorsed by TinyWall's author.