v0.6.4.1

This hotfix makes updates and Windows joins from 0.6.4 and earlier finish properly, and say so clearly when they don't. It changes vhir (now 0.6.4.1), the Windows installer (wintools-mcp) and setup-sift.sh (sift-mcp).

What was wrong in 0.6.4

• vhir update could look finished when it wasn't. The update runs the steps of the version you start from. Steps added in the new release were skipped, and the run still ended with "Updated to …". Your controls, settings and gateway could be left partly on the old release.
• vhir setup join-code refused on a stock SIFT VM. It stopped with "Accounts also come from sss … which can't all be listed".
• vhir setup join-code printed a join code even when the case share or the firewall setup failed. The Windows install then failed, far from the real cause.
• The Windows installer kept going on old code. If its update download failed, it said "Using existing code" and carried on. When the update did bring a new installer, that run still used the old installer's steps.
• The Windows line from vhir setup join-code didn't run on a default Windows 10 or 11 machine. PowerShell refused the installer with "running scripts is disabled on this system". The line now allows scripts for that window first.
• The Windows installer could leave wintools without auto-start. It gave the newly started server about 8 seconds to answer. A slower start (in testing, about 16 seconds when the SIFT share couldn't be reached) skipped the start-at-boot task, so after a reboot wintools didn't come back. It now waits up to 90 seconds and says it is waiting.

On SIFT

1. Run vhir update.
2. Run vhir update once more. The first run, from 0.6.4 or earlier, still uses your old version's steps and ends with a normal "Updated to …" line. The second run finishes the update with the new code. If you skip it, your next vhir command shows UPDATE INCOMPLETE: run vhir update again. (Measured with this release on both SIFT forms, 0.6.4 → 0.6.4.1: the SANS OVA and a 22.04 SIFT built with SANS's installer. Updating from 0.6.1 was measured on both with an earlier build of this release.)

Why you may need two runs: the update from 0.6.4 or earlier still runs your old version's steps. The new version notices afterwards and tells you. From this release on, a single vhir update is enough. When an update brings new code, it carries on with that code by itself ("Continuing the update with the new code..."). If it can't, or if it stops partway, it says so and the warning stays until an update finishes.

A gateway that takes more than a minute to restart, but does come up, no longer stops vhir update partway.

On Windows

After updating SIFT, join again with the current installer:

1. On SIFT, run vhir setup join-code.
2. Copy the one-line command it prints into PowerShell, run as Administrator, on the Windows machine. That line downloads the current installer and runs it with your join code. Your old installer copy is not used. If the download fails, nothing runs.

If you update with setup-windows.ps1 -Update: in PowerShell as Administrator, first run Set-ExecutionPolicy -Scope Process Bypass -Force (default Windows 10 and 11 block scripts otherwise). Then run it from the installed copy (<install folder>\wintools-mcp\scripts\setup-windows.ps1), then run it a second time. The first run fetches the new installer but still runs the old one's steps. The second run uses the new installer.

What the new installer does by itself next time:

• If an update brings a newer installer, it restarts itself once with the same options. You don't run it twice again.
• If the update download fails, it stops instead of carrying on with old code. A re-run of the installer shows git's error. To set up the code already there anyway, answer "y" or add -ContinueWithoutUpdate. -Update stops with "Could not reach GitHub. Check your network connection."

Your own folder (where you cloned or unzipped wintools-mcp) is never updated by the installer. Use the line vhir setup join-code prints, or the installed copy, not an old copy in your own folder.

Changes to vhir setup join-code

• The Windows line it prints now starts with Set-ExecutionPolicy -Scope Process Bypass -Force;. Before, on a default Windows 10 or 11 machine the line stopped with "running scripts is disabled on this system" before the installer ran. The setting applies to that PowerShell window only and changes nothing permanently. If Group Policy sets the execution policy, it still decides.

• When the case share or the firewall setup fails, no join code is shown. You get the reason and how to fix it, then run vhir setup join-code again. The firewall command it prints for doing this by hand now works as printed (before, ufw rejected it).

• If it can't check the firewall (for example, sudo is refused), it stops instead of assuming there is no firewall.

• Stock SIFT VMs whose accounts also come from sss are no longer refused. The check of the examiner's own group still runs.

• setup-sift.sh --remote now shows why, when it can't make a join code. Before, it only said "Could not generate join code".

Known issue: --remote installs (fixes are coming in 0.6.5)

• On a SIFT installed with ./setup-sift.sh --remote, Claude Code run on the SIFT box itself can't connect to the gateway (certificate error), and the Windows setup script can't join that SIFT (it ends "Not finished: the join with SIFT didn't happen"). The default install isn't affected. Until 0.6.5, use the default install (./setup-sift.sh, then vhir setup join-code for Windows), or run the AI client from another machine as --remote intends.

Known issue: memory analysis and Hayabusa on the SANS SIFT OVA (April 2026 image)

• The current SANS OVA ships Volatility 3 2.27.0, which cannot save the symbols it downloads when run as a normal user, so memory analysis fails. The memory ingest still reports "complete", with no results, so check for this before relying on an empty memory result. It also has no Hayabusa, so event-log detections are skipped. Fix: run sudo cast install teamdfir/sift on the OVA (in testing about 13 minutes; if it reports failed states, run it again, since a download outage can cause them; the retry took about 5 minutes), then re-run ./setup-sift.sh. In testing, a SIFT installed on Ubuntu 22.04 with SANS's installer (cast) had both. 0.6.5 will check for this and say so.

Known issue: a large triage folder can sit at "starting" for a long time (a fix is coming in 0.6.5)

• Before it ingests a folder, Valhuntir checks every file against the case's file-identity log. In 0.6.4 and 0.6.4.1 it re-reads that whole log once per file. On a case that already holds a lot of hashed evidence, a triage folder of about 12,000 files can stay at "starting", with nothing indexed, for a long time. In testing it was still at "starting" after 36 minutes, and at the measured 1 s per file (with a 23,600-row log) it would take about 3.5 hours. Until 0.6.5, ingest large triage folders early in a case, or ingest their subfolders separately.

Known issues: two ingest failures with unclear messages (fixes are coming in 0.6.5)

• On a SIFT where sudo asks for a password, ingesting a disk image fails, and the run's status says only "process_died_unexpectedly". The cause is that mounting the image needs sudo with no password prompt. Mount the image yourself (read-only), link the mount into the case's evidence/ folder, register that link as evidence, and ingest the mounted folder. On the SANS SIFT VM, sudo needs no password (checked on the stock VM), so this failure isn't expected there.
• A memory ingest can stop partway with "read timeout" while it creates an index. Run the memory ingest again for the artifacts that are missing. In testing, re-running the 4 missing ones completed them.