ALPHA - DO NOT USE - v2026.10.15.0-alpha.1 (Refresh list button)

ALPHA - DO NOT USE

DO NOT USE THIS BUILD

This is an alpha prerelease containing an unfinished feature. It is published only
so the new feature can be looked at. Do not run it on a client PC.

Use the stable release instead: the release titled "USE THIS - Stable ..."
(currently v2026.10.14.3).

Both ZIPs here contain ALPHA-DO-NOT-USE.txt at the top level, and their program-1 window
title shows the alpha version, so an extracted copy cannot be mistaken for the stable kit.

What is new here (unproven)

Program 1 has a Refresh list button:

• It asks for confirmation, then rebuilds the Windows App Control signer list from
  lolrmm.io in one step (Build-RmmAppControl -IncludeOptional).
• It refuses cleanly on a PC that cannot build the policy (Windows Home, or no
  ConvertFrom-CIPolicy) and tells you to build it on a Pro PC.
• It says plainly that an already-installed policy keeps the old list until BLOCK or
  Test mode is pressed again, so the new list is not silently assumed to be live.
• It is disabled while work is running, like the other buttons.

Why it was added: the program list is baked into the shipped policy files and only changes
when a vendor changes its code-signing certificate. There was no way to refresh it from the
window, so an out-of-date kit had to be updated by hand from the repository.

What has been verified

• Windows PowerShell 5.1 and PowerShell 7 CI runs the real click handler with an
  injected confirmation answer and checks: declining does nothing, the build script is
  called once with -IncludeOptional, the success text tells the operator to press BLOCK,
  the buttons are re-enabled, and a PC that cannot build gets the clear message with no
  build attempt.
• The ZIPs are built from the exact commit below and downloaded back after upload with
  matching per-member hashes.

What has NOT been verified

• A real rebuild against live lolrmm.io from the button, and the on-screen confirmation
  dialog, have not been exercised on hardware.
• Program 2 (ESET website list) and the Windows-only kit are unchanged from the stable
  release apart from the version string.
• No owner live test has happened for this build.

Source commit: 8cddb9a1101dbde7d5907f965f96c2c0bbb35393.
Windows CI: https://github.com/pupontech/remote-access-tool-blocker/actions/runs/38552843359
Pull request (draft, deliberately not merged): #4

SHA-256 full-kit-eset-2026.10.15.0-alpha.1.zip: 753fb2c791b17e210f7adbbd3e791afb2d8ceaf29bfdead16b14a267a0bdbdfe

SHA-256 remote-tools-block-windows-2026.10.15.0-alpha.1.zip: e60980c618492c56ec4b6ee7168601c0e583ecc22c5ee7175049a70de1f538f8

USE THIS - Stable v2026.10.14.3 (full kit + Windows-only)

USE THIS - STABLE RELEASE

This is the stable release. Use these files:

• full-kit-eset-2026.10.14.3.zip - programs 1 (Windows blocker) and 2 (ESET website list)
• remote-tools-block-windows-2026.10.14.3.zip - Windows-only kit (no ESET)

An ALPHA build containing an unreleased experimental feature is published as a
separate prerelease. Do not use the alpha build - it is for testing only and
is not this stable release.

Verified on Windows PowerShell 5.1 and PowerShell 7: both ZIPs here were built
from the exact commit below and downloaded back after upload with matching
per-member hashes.

---

2026.10.14.3 - Open list button

• Add a third button, Open list, to program 2. It opens the existing import file in Notepad without rebuilding or changing the clipboard.
• Keep BUILD and Open the list folder alongside it; disable all three while building.
• If no list exists, show BUILD-first guidance without starting Notepad.
• Windows regression tests exercise the real click handler, check the exact quoted path, unchanged file bytes, missing-file handling and busy state.

Earlier in 2026.10.14.x: BUILD copies the import file path (verified) and opens the list in Notepad; one combined ESET list instead of two; TeamViewer / AnyDesk / Splashtop / RustDesk unticked by default in both programs; coloured logging fixed.

Validation limits: Windows CI verifies control and launch behavior with intercepted process starts; visible Notepad and the manual ESET import remain owner live checks.

Source commit: a92462d9a65efb400221f1326fc9ced9e3705512.
Windows CI: https://github.com/pupontech/remote-access-tool-blocker/actions/runs/38550688781

SHA-256 full-kit-eset-2026.10.14.3.zip: 307502a9c8e10fab8acee361f280a0840d533b6fb71aeaf08811230719f98da6

SHA-256 remote-tools-block-windows-2026.10.14.3.zip: 4bd7394b8c6899b9336e64c70748c5a1caf774b2e181545700919877f2db8ab6

SUPERSEDED - v2026.10.14.2 - open the ESET website list in Notepad (use v2026.10.14.3)

2026.10.14.2 - open the website list in Notepad

• BUILD in program 2 now opens the generated eset-blocked-urls.txt in Notepad as well as opening the import instructions.
• Preserve Explorer selection, verified clipboard file path, combined list and unticked tool defaults.
• Keep Notepad launch failure non-blocking and open the list before optional undo-tool installation.
• Regression coverage invokes the actual build handler on Windows PowerShell 5.1 and pwsh and checks the exact quoted Notepad path.

Validation limits: Windows CI verifies launch arguments; visible Notepad and manual ESET import require owner live testing. Windows-only behavior is unchanged.

Source commit: 93cf635069e386750d68f787f8422c39529968d3.
Windows CI: https://github.com/pupontech/remote-access-tool-blocker/actions/runs/38550176348

SHA-256 remote-tools-block-windows-2026.10.14.2.zip: a1610d54abce77728a1fcef9018fed5b2a03b5388a61a168a9abbd1793a2349d

SHA-256 full-kit-eset-2026.10.14.2.zip: 77ab9f3e7bda7200769815f3b2c68cf0efcee5b578ec1357aac9bb0ea1f77f21

SUPERSEDED - v2026.10.14.1 - ESET import fixes and combined list (use v2026.10.14.3)

2026.10.14.1 - import workflow fixes

• Fix the program 1/2 log control: coloured output requires RichTextBox; cosmetic colour errors cannot abort the run.
• Program 2 copies and verifies the import file path, opens Explorer before optional undo-tool installation, and keeps the list usable if that installer fails.
• Produce one combined ESET import list; remove a stale optional list on rebuild. Retain optional-tier review metadata and warn about legitimate AV/SaaS/VPN services.
• All four tool checkboxes start unticked in programs 1 and 2. Preserve installed-policy choices in program 1.
• Add Windows PowerShell 5.1 and pwsh regression coverage for the real window, clipboard, Explorer arguments and combined generator.

Validation: Windows-runner regression tests pass; visible Explorer behavior and manual ESET import still require owner live testing. The Windows-only kit remains unchanged in behavior.

Changelog

All notable changes to this project. Dates are the versioning dates carried in the script filenames.

Source commit: 2eedb08badcdce53a34fc383cb468271d3735761.
Windows CI: https://github.com/pupontech/remote-access-tool-blocker/actions/runs/38545312783

SHA-256:

• remote-tools-block-windows-2026.10.14.1.zip: c4e5e18ea2c5765909fb7e5d54460cd5c679d8cdd2da194c51dcf9a5971fdd5d
• full-kit-eset-2026.10.14.1.zip: 8845cb8d175ae6743b29a465d390791371ea7baf96a719a346e2b70c18f4b8a4

v2026.10.11.7 - START-HERE.bat launchers (test release)

Test release — every launcher you double-click is now called START-HERE.bat.

What changed

The entry points were named after what they did, which left you to work out which file to open. Now the answer is
the same in every folder:

Folder	Double-click
1\	START-HERE.bat — blocks the remote-access programs (AnyDesk, TeamViewer, ScreenConnect …) with Windows App Control. Administrator. No antivirus.
2\	START-HERE.bat — builds the tools' website list and opens ESET + the paste guide. ESET installed. No admin.
the Windows-only kit	START-HERE.bat — the program blocker on its own.

The name is unambiguous because the two programs live in separate folders, so 1\START-HERE.bat and
2\START-HERE.bat are clearly different files.

The helper launchers that the code calls by name are unchanged (Run-RmmAppControl.bat, Run-Revert.bat,
Run-LolrmmUrlList.bat) — renaming those would break the scripts that invoke them. You never need to open them.

Also in this release

• The full kit is two separate programs in folders 1 and 2. Neither needs the other.
• Program 1 no longer hands out ESET removal steps. It previously installed an undo tool carrying the ESET
  guide, so a PC with no antivirus at all was told to go un-block something it had never blocked. It now
  installs an ESET-free undo tool; program 2 installs the ESET-aware one, and removes the other, so exactly one is
  ever present.

Verified

• All seven static gates pass on the hosted Windows runner, on both PowerShell 5.1 and pwsh 7.
• In the extracted release ZIP, each START-HERE.bat resolves its own window script
  (1\ → Block-The-Programs.v*.ps1, 2\ → Block-The-Websites.v*.ps1, windows-only → Remote-Tools-Block-Windows.v*.ps1).
• Program 2's installer was run for real: it writes the ESET-aware undo variant plus docs\eset-remove-guide.txt,
  and removes a previously installed ESET-free copy.
• Assets below were downloaded back from this release and byte-matched to the verified local build.

Still not verified on a PC

A live RustDesk block, Windows Home behaviour, the revert tool's removal path on real hardware, and the windows'
buttons being clicked by an automated test. The ESET paste is still a by-hand step a technician must do.

Which file do I want?

• remote-tools-block-windows-2026.10.11.zip — the program blocker alone, one window. Start here.
• full-kit-eset-2026.10.11.zip — both programs, as folders 1 and 2.

Extract anywhere, keep the folders together. Test in audit mode first: run 1\START-HERE.bat, press
Test mode, confirm you get [3076] events, then BLOCK.

v2026.10.11.6 - two separate programs, split undo tool (test release)

Test release — the full kit is two separate programs in folders 1 and 2, and the undo tool is split to match.

What changed

The full kit used to be one window doing two unrelated jobs, which forced the ESET steps and wording onto every
deployment — including PCs with no antivirus. It is now two independent programs:

Folder	Run this	What it does	Needs
1\	Block-The-Programs.bat	Blocks the remote-access programs — AnyDesk, TeamViewer, ScreenConnect and ~50 more — with Windows App Control	Administrator. No antivirus.
2\	Block-The-Websites.bat	Builds the tools' website list, copies it, and opens ESET + the paste guide	ESET installed. No admin needed.

Neither program needs the other.

Fixed: the undo tool was handing ESET steps to PCs with no antivirus

Splitting the programs exposed a real defect. Program 1 shipped the shared undo tool, and the installer picks the
ESET-aware variant whenever it is present — so a PC with no antivirus at all still had
docs\eset-remove-guide.txt copied into C:\RemoteAccessToolBlocker. That is the same bug already fixed once for
the Windows-only kit, on a new path.

The undo tool now follows the same line as the programs:

• Program 1 installs the ESET-free variant. No ESET steps, no guide.
• Program 2 installs the ESET-aware variant and the guide when it builds a list — the only moment an ESET
  layer actually exists. It removes the ESET-free copy at the same time, so exactly one variant is ever present and
  it always matches what was actually blocked.

Verified

• All seven static gates pass on the hosted Windows runner, on both PowerShell 5.1 and pwsh 7.
• The extracted release ZIP was tested as shipped: program 1 resolves to the ESET-free undo variant
  (winOnly=1, full=0); program 2's installer writes the ESET-aware variant plus docs\eset-remove-guide.txt, and
  removes a previously installed ESET-free copy — run for real against a synthetic install directory, not read.
• Program 2's real generator run from the extracted folder produced the full 406-entry list.
• The 1\/2\ layout is now produced by build/build-release.sh, which CI runs and asserts on the real ZIP, so
  the layout cannot drift from the docs.

Two defects found by running, not reading

• Install-ESET-Revert crashed writing its README.txt — $readme = @() is a fixed-size array, so .Add() threw
  "Collection was of a fixed size". Now a generic List[string].
• The launcher-contract check had duplicate hashtable keys, which PowerShell rejects. A Python simulation passed
  because dicts dedupe silently; only running the workflow's own PowerShell under pwsh caught it.

Still not verified on a PC

Unchanged: a live RustDesk block, Windows Home behaviour, the revert tool's removal path on real hardware, and the
windows' buttons being clicked by an automated test. The ESET paste is still a by-hand step a technician must do.

Which file do I want?

• remote-tools-block-windows-2026.10.11.zip — the program blocker only, one window. Start here.
• full-kit-eset-2026.10.11.zip — both programs, as folders 1 and 2.

Extract anywhere, keep the folders together. Test in audit mode first: program 1 → Test mode, confirm you get
[3076] events, then BLOCK.

v2026.10.11.5 - two separate programs (folders 1 and 2) (test release)

Test release — the full kit is now two separate programs, in folders 1 and 2.

What changed

The full kit used to be one window doing two unrelated jobs, which forced the ESET steps, the ESET guide and the
ESET wording onto every deployment — including the ones with no ESET installed. It is now two independent programs:

Folder	Run this	What it does	Needs
1\	Block-The-Programs.bat	Blocks the remote-access programs — AnyDesk, TeamViewer, ScreenConnect and ~50 more — with Windows App Control	Administrator. No antivirus.
2\	Block-The-Websites.bat	Builds the tools' website list, copies it, and opens ESET + the paste guide	ESET installed. No admin needed.

Neither program needs the other. Run either, or both.

• Program 1 never mentions ESET — its UNDO removes the program block only.
• Program 2 never touches App Control, needs no administrator rights, and cannot change what is blocked on the
  machine. It only writes a list file and opens windows.
• Each program has its own ticks, so a tool you leave out is left out of that program's job.
• The Windows-only ZIP (remote-tools-block-windows) is unchanged — it was already App Control only.

Verified

• All seven static gates pass on the hosted Windows runner, on both PowerShell 5.1 and pwsh 7 — including a
  new contract that fails the build if program 1 ever gains ESET behaviour, if program 2 ever gains an App
  Control reference, if either program loses its core, or if program 2's launcher starts requiring elevation.
• The extracted full-kit ZIP was tested as shipped: both folders resolve everything standalone (policy variants,
  install/build scripts, the URL generator, the guide), and the repo layout still resolves too. No path depends on
  the other program.
• Program 2's real generator was run from the extracted folder and produced the full 406-entry list.

Still not verified on a PC

Unchanged from before: a live RustDesk block, Windows Home behaviour, the revert tool's removal path on real
hardware, and the program windows' buttons being clicked by an automated test. The ESET paste is still a
by-hand step a technician must do.

Which file do I want?

• remote-tools-block-windows-2026.10.11.zip — the program blocker only, one window. Start here.
• full-kit-eset-2026.10.11.zip — both programs, as folders 1 and 2.

Extract anywhere, keep the folders together. Test in audit mode first: program 1 → Test mode, confirm you get
[3076] events, then BLOCK.

v2026.10.11.4 - Open the ESET list folder (test release)

Test release — the full kit can now take you straight to the ESET import file.

Added: an "Open the ESET list folder" button

The ESET paste is the one step that cannot be automated. Until now the window only printed the import file's path,
which left the operator to read it and navigate there by hand — and if the window scrolled, the path was gone.

The full-kit window now has a second button beside Refresh status: Open the ESET list folder. It opens
Explorer at

%USERPROFILE%\LOLRMM-UrlList\latest

with eset-blocked-urls.txt already selected, so it is one click from ESET's Import dialog. Pressed before a
list has been built it says so and names the path it will write, instead of opening nothing at all.

BLOCK also opens that folder for you now on the clipboard-failure path, since the file is the route that always
works. Opening a folder is harmless while work is running, so the button stays live during an install.

Verified

• The real generator was run the way the window invokes it, with -OutDir set to exactly that path:
  406 entries, no BOM, anydesk.com present, Splashtop correctly excluded — so the file the button selects is
  the file ESET imports.
• All five static gates pass on the hosted Windows runner for both engines (PowerShell 5.1 and pwsh 7):
  parse, encoding/ASCII/CRLF, launcher contract, revert-variant allocation, policy inventory.
• Every member of both ZIPs was verified byte-for-byte against the working tree; 32 policy variants intact.

Still not verified on a PC

• The button itself has not been clicked by an automated test (it needs no administrator rights and only opens a
  folder, but it was inspected, not clicked).
• Unchanged from v2026.10.11.3: a live RustDesk block, Windows Home behaviour, and the revert tool's removal path
  on real hardware.
• The ESET paste is still a by-hand step and a technician must still do it.

Which file do I want?

• remote-tools-block-windows-2026.10.11.zip — App Control only, no antivirus needed. Start here.
• full-kit-eset-2026.10.11.zip — the same, plus the ESET website list (and the new folder button).

Extract anywhere, keep the folders together, run the .bat, accept the administrator prompt.

Test in audit mode first — press Test mode, confirm you get [3076] events, then press BLOCK.

v2026.10.11.3 - ESET list delivery fix (test release)

Test release — fixes the ESET list not appearing, and spells out the by-hand step.

The generated ESET list now actually reaches you

Two separate defects made it look like the list was never created, or vanished somewhere unknown.

1. The window could die before it was ever drawn. The output-folder line ran at script scope before the window was
built, so on any PC where USERPROFILE is unset it threw and the window never opened — BLOCK appeared to do
nothing, and because the launcher starts the window hidden there was no visible error either. It now resolves
defensively and falls back to a folder beside the script.

2. The list was written where nobody was told, and the clipboard was assumed to work. The window said
"copied to the clipboard" without checking, and never said where the file was. Set-Clipboard returns nothing and
can fail — or write to a different session's clipboard — when the process runs elevated. The window now:

• always prints the import file path and entry count:

  IMPORT FILE: C:\Users\<you>\LOLRMM-UrlList\latest\eset-blocked-urls.txt
  (406 entries)
  

• reads the clipboard back and only claims success when the contents actually match;
• when the clipboard fails, says so and points at the file instead:

  -> could NOT copy to the clipboard. Use the IMPORT FILE above:
     in ESET choose Import and pick that eset-blocked-urls.txt file.
  

• reports each failure distinctly — generator not found (naming the folder it searched), generator failed, or ran
  but produced no file — instead of one vague "could not build the website list".

Either route works. The clipboard is faster; the file always works. The list is never lost: it is always on disk
at the path the window prints.

Also fixed: $env:USERPROFILE was unguarded in both ESET generators (Get-LolrmmUrlList, Get-LolrmmHipsList),
which threw on a default run without it.

The ESET paste is now labelled as a by-hand technician step

The README, docs/eset-import-guide.md, the on-PC HOW-TO-IMPORT.txt and the ESET removal guide all now state it
in bold: THIS STEP CANNOT BE AUTOMATED — A TECHNICIAN MUST DO IT BY HAND, with the full click-by-click
copy/paste walkthrough and a test (anydesk.com should show ESET's block page).

Verified

Ran the real generator exactly as the window invokes it: 406 entries written to the announced path, UTF-8
without BOM, anydesk.com present, an excluded tool genuinely absent, -OutDir honoured on repeat runs, and a
default run with USERPROFILE unset falling back instead of crashing.

Still not run on real hardware: the revert tool's policy removal, a RustDesk block, the window buttons by automated
test, Windows Home. See docs/testing.md.

Policy and list data derived from LOLRMM (Apache-2.0) — see NOTICE. Licensed Apache-2.0.

v2026.10.11.2 - Windows-only removal tool drops the ESET part (test release)

Test release — validate live before relying on it. Fixes the Windows-only removal tool and repairs the dry run.

The Windows-only kit's removal tool no longer has the ESET part

It previously opened ESET, printed ESET removal steps and shipped the ESET guide even on a deployment with no ESET
layer — telling you to un-block something that was never blocked. There are now two variants, generated from one
source so they cannot drift:

Kit you used	Variant installed	Behaviour
Windows-only	Revert-RemoteAccessBlock-WinOnly.v*.ps1	App Control removal only. No ESET window, no ESET steps, no guide, and it does not read the LOLRMM-UrlList folder at all.
Full (with ESET)	Revert-RemoteAccessBlock.v*.ps1	Removes the policy and walks you through taking the website list back out of ESET.

The installer picks the variant the kit ships and removes the other one if a previous install used it, so a PC
moved to Windows-only can never keep an ESET-capable script. Each variant writes a matching README.txt.

-WhatIf did not work at all — now it does

-WhatIf was documented everywhere but was not a parameter: [CmdletBinding()] alone does not add it to a
script, so it failed to bind with "A parameter cannot be found that matches parameter name 'WhatIf'". The one
guardrail that shows what a revert would do without changing anything was unusable. It is now an explicit switch
driving the same guard — nothing is written when it is set.

Three more defects surfaced only once the dry run actually ran:

• A crash on the dry-run path: Say '[dry run] would write a log line to ' $LogFile does not concatenate — the
  path bound to -ForegroundColor and died converting to System.ConsoleColor. Fixed at all three sites.
• $env:USERPROFILE unguarded in the ESET-only backup loop (null-Path crash). Only the full variant hit it,
  which is why the Windows-only copy ran clean.
• $env:windir unguarded, so the tool died at startup on a host without it; it now refuses with a specific
  message and exit code 9 instead of an error naming no useful line.

Assets

Asset	What it is
remote-tools-block-windows-2026.10.11.zip	Windows App Control only. No antivirus needed. Start here.
full-kit-eset-2026.10.11.zip	The same, plus the ESET website list generator and paste guide.

Both flat and self-contained: kit scripts beside the shared App Control scripts, the correct undo-tool variant, and
policy/ with all 32 prebuilt policies.

Verified / not verified

Verified by execution on this change: the installed Windows-only copy completes a full revert with zero ESET
actions (no ESET line in the output, no ESET-named file anywhere in the install, no docs\, no eset-lists\
backup) while the full copy still presents the ESET guide and steps; switching kits in both directions leaves
exactly one variant; the installer copies the right variant from both the repo layout and an extracted release ZIP;
-WhatIf runs clean on both variants and reaches neither removal call.

Verified earlier on a real PC: policy loads; audit logged AnyDesk, TeamViewer, ScreenConnect (3076); enforcement
blocked AnyDesk (3077); ESET URL import worked.

Not run on real hardware: the revert tool's policy removal (same code path as the already-verified
-Mode Remove); a RustDesk block; the window buttons by automated test; Windows Home. See
docs/testing.md.

Policy and list data derived from LOLRMM (Apache-2.0) — see NOTICE. Licensed Apache-2.0.