Skip to main content

The helper under Windows' security gates

SPART-Desk's Windows backend is one executable inside the npm package, native/spart-desk-host.exe (and its 32-bit build, spart-desk-host-x86.exe), which the engine starts as a child process. Nothing is installed beside the package, nothing is downloaded, and the engine never runs PowerShell (distribution.md). This page says what each of Windows' security gates does with that file, what npx spart-desk doctor tells you, and what an administrator allows.

GateWhat it does with the helperWhat to do
SmartScreenNothing: it checks files that carry the Mark of the Web when the shell starts them. npm writes the helper without that mark, and the engine starts it without the shell.Nothing.
Smart App Control (Windows 11, consumer and unmanaged machines)Lets a file run when its signature is valid and chains to Microsoft's root program; blocks an unsigned file it has no reputation for.Nothing: the helper in the published package is signed by Spartaficial.
App Control for Business (WDAC), AppLockerAllow or block by the rules the organisation wrote.Allow by publisher, from the signed file. Never by hash or thumbprint: the signing certificate rotates.
Microsoft Defender AntivirusScans the file when npm writes it and when it starts; holds an unknown file at its first start for a cloud verdict.Nothing, as a rule. A false positive: restore the file and report it; doctor says whether the helper runs.
Defender for Endpoint (attack surface reduction, indicators)Its "prevalence, age or trusted list" rule blocks every new release's file for a day; certificate indicators match the leaf certificate alone.Exclude the helper's path from that rule, or allow each release's file by its SHA-256 (Get-FileHash on the installed file, below), or allow by publisher in WDAC.

What doctor prints​

  helper    ok — …\node_modules\@spartaficial\spart-desk\native\spart-desk-host.exe (version 0.1.0)
  signature signed by CN=…

The helper line names the version of the package the helper was built for. The signature line is what the helper reports of its own file: signed by <subject> for the helper in the published package, which Spartaficial signs; invalid (0x…) for a file changed after it was signed or whose certificate chains to no root the machine trusts, which is also listed under Problems (reinstall the package). A machine that refuses the helper shows helper blocked: … instead, and every capability says so (troubleshooting.md).

A rule that allows a file by its hash takes the installed files' SHA-256 from PowerShell, in the project folder:

Get-FileHash -Algorithm SHA256 node_modules\@spartaficial\spart-desk\native\*.exe

SmartScreen​

SmartScreen's reputation check runs when the shell (Explorer, a browser's download bar) starts a file that carries the Mark of the Web, the Zone.Identifier stream a browser attaches to what it downloads. npm extracts a package with Node's file APIs, which attach no mark, and the engine starts the helper with child_process.spawn, which does not go through the shell. SmartScreen never sees the helper. The "reputation builds over time" caveat Microsoft gives for Azure Artifact Signing is about SmartScreen on downloaded installers, not about a file started this way.

Smart App Control​

Smart App Control is Windows 11's own application control for machines that are not managed by an organisation; it is on only when a clean installation stayed in its evaluation mode, and it cannot be turned on again once off (before 25H2). When it cannot predict a file's safety from the cloud, it checks the file's signature: a valid signature that chains to a root in Microsoft's Trusted Root Program lets the file run; an unsigned file, or one whose root the program does not hold, is blocked without a dialog ("An Application Control policy has blocked this file" in the event log). It evaluates DLLs as well as executables, which is why a native Node module would be no way around it.

The helper in the published package is signed by Spartaficial with Azure Artifact Signing, whose public-trust certificates chain to Microsoft's root, with a timestamp, so the signature stays valid after the short-lived certificate expires. A certificate made on the machine does not help, even when it was added to the machine's trusted roots.

In the Windows Sandbox guest​

Experimental

The Windows Sandbox runtime may change in minor versions until its prerequisites are validated against a live Windows Sandbox.

The Windows Sandbox guest enforces Smart App Control whatever the host has: the signed helper runs there as it is, and the sandbox runtime turns the policy off in the guest only when asked (guestAppControl: "off", runtime-windows-sandbox.md).

App Control for Business and AppLocker​

An organisation's policy allows the helper by publisher, from the signed file:

  • AppLocker: a Publisher rule from spart-desk-host.exe (and one from spart-desk-host-x86.exe, or a rule on the product). The rule's fields come from the signature and the file's properties: the publisher is the signing certificate's subject, the product SPART-Desk, the file name SPART-DESK-HOST.EXE, the file version the package's (0.1.0.0 and above, as the release notes say). doctor prints the signer's subject.
  • App Control for Business (WDAC): a Publisher-level rule from the signed file, with the App Control Wizard or New-CIPolicyRule -Level Publisher -DriverFilePath <path to spart-desk-host.exe>; the rule names the issuing certificate and the signer's name, and holds across releases.

Never a hash rule and never a certificate thumbprint: Azure Artifact Signing issues a new leaf certificate every few days, so a thumbprint stops matching with the next release, and a hash with every build. A policy that needs a hash allows each release's file by the SHA-256 of the installed file (Get-FileHash, above).

Windows Server has no Smart App Control, but an App Control policy there blocks the helper the same way.

Defender​

Defender Antivirus scans the helper when npm writes it and when it first starts, and may hold an unknown file for a cloud verdict before it runs ("block at first sight"); the engine retries a first start that was slow. What Defender's models weigh against an executable is what the helper does for a living: it sends input (SendInput, synthetic touch and pen), listens to raw input to notice a person's hand during an action, reads other processes' windows through UI Automation, takes pictures of the screen, and Studio's picker sets a low-level mouse hook. What speaks for it: the signature with a validated organisation, the file's properties (company Spartaficial, product SPART-Desk, the package's version), and the same two file names release after release.

A quarantined helper shows as helper blocked: … in doctor and as BackendError [helper_unavailable] on the first action. Restore the file (or reinstall the package) and report the detection to Microsoft with the file; doctor says whether it runs again.

In an organisation with Defender for Endpoint, two rules hit a new release whether it is signed or not:

  • The attack surface reduction rule "Block executable files from running unless they meet a prevalence, age, or trusted list criterion" blocks a file Microsoft's cloud has not seen on enough machines or for long enough. Every release is a new file. Exclude the helper's folder (node_modules\@spartaficial\spart-desk\native\) from that rule, or allow each release's file by its SHA-256 with a file indicator.
  • Certificate indicators allow files by their leaf certificate alone, so with a rotating leaf they hold for one release. A WDAC publisher rule, or a file indicator per release, is the durable allow.

Why an executable, not a Node module​

A native Node module is a DLL: Smart App Control, WDAC and Defender treat it like an executable, so a signature buys the same thing either way and the gates are unchanged. The executable is what the Windows Sandbox guest (experimental) runs as the engine's agent, what a 32-bit Java runtime and a 32-bit application's windows need, and what keeps UI Automation's hangs and the helper's process-wide state out of the test runner and the MCP server. It is built by the C# compiler of the .NET Framework that Windows has and runs on that framework, so neither a user nor a contributor installs anything.

Remote Desktop​

None of the gates above care where the session is. What matters for remote work is that UI Automation, real input and screen captures are per session: the engine runs inside the session where the windows are, over Remote Desktop as on a console (ci.md). From the client side of a Remote Desktop session only pixels exist, which read(), getByOcr, getByImage and getByVision (experimental) with real input into the client's window cover as screen-only (app-coverage.md).

Sources​