Download Chrono Mock
Two builds of the same engine: a window for exploring, a command line for CI. Unzip either one anywhere and run it - there is no installer, nothing is written to the registry, and no administrator rights are needed.
| File | What it is | Size |
|---|---|---|
ChronoMock-win-x64.zip |
The desktop application, self-contained - no .NET install needed | ~69 MB |
chrono-cli-win.zip |
Just the command-line tool, for CI and scripts | ~1.6 MB |
What you need
- Windows 10 or Windows 11. There is no macOS or Linux build - on Linux, libfaketime already covers this well.
- Nothing else. The desktop build carries its own runtime, and the command-line build carries nothing at all.
- Both 32-bit and 64-bit applications are supported. The package ships both, and picks the one matching the application you point it at.
ARM64 is out of scope through version 1.0, and packaged Store applications (UWP and MSIX) are not supported - their launch model does not allow it.
Running it
Unzip, then run ChronoMock.exe for the window or
chrono.exe for the command line. A first session is three
decisions: which application, which moment, and how fast the clock should run.
# Run an application as if it were the last second of 2027 chrono run "C:\apps\test.exe" --at 2027-12-31T23:59:59 # The same thing, with the clock running a day per minute chrono run "C:\apps\test.exe" --at 2027-12-31T23:59:59 --mode x1440
Two things to read first
Back up the application's data directory before your first future-dated session.
An application running in 2028 writes 2028 dates wherever it stores data: its database, its configuration, its cache, its licence file. Those values stay there after you return to real time. For software with licence protection this can be permanent - "clock rollback detected, licence invalidated" is a standard industry pattern, and it will do exactly what it was designed to do.
Chrono Mock cleans up after itself. It cannot clean up after the application you tested.
Your antivirus may flag it, and that is expected.
Time is shifted by injecting a small library into the target process. That is a legitimate, documented Windows technique - and it is also one that malware uses, so Microsoft Defender and others may flag the injected library or block the injection outright. It is a false positive triggered by the technique.
If a session refuses to start and Defender reports a threat, exclude the library
rather than the folder: choose File in Windows Security and give
the full path to chrono_hook.dll. A folder exclusion would stop
anything being scanned in the very directory the tool injects from. Or run it on a
machine where you are permitted to do so. The injected library is built from the
code in this repository under GPL-3.0 - you can rebuild it yourself. The Chromium
and Electron mode does not inject at all and is unaffected.
What it leaves behind
Nothing in your system: no persistent hooks, no registry entries, and nothing
outside its own folder except three things it will name for you - the session
history and the diagnostics log, which move to
%LOCALAPPDATA%\ChronoMock\ when the tool's own folder is not writable,
and, for an Electron or Chromium target, a throwaway browser profile under
%TEMP% that is deleted when the session ends and reported in the
session summary if it could not be.
It never talks to the internet, keeps no account and sends no telemetry.