Skąd wiesz, że zadziałało?

Narzędzie do przesuwania czasu, które pominęło kanał, nie wywala się i nie ostrzega. Aplikacja po prostu czyta prawdziwą datę tą jedną funkcją, której nikt nie podpiął, i zachowuje się dokładnie tak, jak zachowałaby się w zwykłe popołudnie. Test świeci na zielono. Błąd trafia do klienta.

RunAsDate pisze o tym uczciwie we własnej dokumentacji - że „nie wpłynie na aplikacje, które biorą bieżącą datę i godzinę z innego źródła" - i zostawia cię z ustaleniem, czy twoja jest jedną z nich. To narzędzie traktuje to samo zdanie jako coś do zmierzenia.

Prawdziwe wyjście, z uruchomienia narzędzia na jednej z własnych sond tego projektu - takiej, która celowo otwiera połączenie sieciowe:

Dwa ostatnie bloki są sednem. Nic tu nie zawiodło - werdykt brzmi works - a raport i tak sam z siebie mówi, że ta aplikacja rozmawiała z siecią, zanim skończyła, więc lokalny hook może nie być całą historią. To zdanie jest różnicą między testem, któremu można ufać, a takim, któremu nie można.

Werdykt powstaje z wnętrza działającego procesu, zanim zaczniesz pracować, i jest zarazem kodem wyjścia narzędzia, więc potok może się na nim rozgałęzić.

Gdy werdykt brzmi „nie działa", proces jest natychmiast zatrzymywany, zanim zdążysz z nim cokolwiek zrobić. Werdykt nie może wyprzedzić uruchomienia, bo jedynym źródłem prawdy jest odczyt z wnętrza działającego procesu. Gwarantowane jest to, że poznasz prawdę, zanim zaczniesz pracować - a nie to, że skazana sesja nigdy nie wystartuje. Można to nadpisać i lecieć dalej, a sesja jest wtedy oznaczona jako nierzetelna wszędzie, gdzie się pojawia, łącznie z eksportowanym dowodem.

Pozostałe kody mówią, że zawiódł sam przebieg, a nie podmiana - błąd użycia, cel, którego nie dało się uruchomić, przebieg ucięty w połowie, inna sesja już działa - i żaden z nich nie jest werdyktem. Pełna tabela jest w dokumentacji wiersza poleceń.

Kanały dzielą się na trzy kubełki, a najciekawszy jest środkowy.

• Objęte - podpięte i podmienione. Aplikacja zapytała i dostała zegar sesji. Licznik mówi, ile razy.
• Obserwowane - przechwycone, policzone i celowo zostawione przy prawdzie. Są tu czekania na obiekty, bo skrócenie limitu czasu mogłoby udawać timeout na prawdziwym uchwycie, i timer multimedialny, bo jego skalowanie przesunęłoby dźwięk i MIDI - oba obserwowane, gdy sesja skaluje oś czasu trwania. Połączenia sieciowe i jedna ścieżka tworzenia procesów są tu w każdej sesji, bo to dowody, a nie zegary. Licznika wysokiej rozdzielczości w tej grupie nie ma: zostaje nietknięty, dopóki nie poprosisz o niego przez --scale-qpc, a wtedy jest objęty.
• Nieobjęte - kanał, który aplikacja czytała, a podmiana do niego nie dotarła. To właśnie zamienia werdykt w działa częściowo i jest wypisywane z nazwy, a nie zwijane do podsumowania.

Zero wywołań też jest informacją: kanał był podpięty, a aplikacja nigdy nie zapytała. Dlatego raport je wypisuje, zamiast chować.

Raport jest uczciwy co do pokrycia, co znaczy, że musi być uczciwy co do własnych granic. Te źródła są czytane bez żadnego wywołania funkcji do przechwycenia albo w ogóle poza procesem:

• bezpośrednie odczyty współdzielonej strony danych trybu użytkownika - wartość leży w pamięci, więc nie ma czego podpiąć. Rzadkie w zwykłych aplikacjach, częste w kodzie licencyjnym i antytamperowym
• bezpośrednie wywołania systemowe omijające standardowe eksporty - ten sam wzorzec
• czas pobierany poza procesem, przez WMI, pozaprocesowy serwer COM albo RPC
• czas z sieci - nagłówek HTTP Date, NTP, odpowiedź API albo własny zegar serwera bazy danych
• czas ze sterowników jądra

Przypadek sieciowy jest tym jednym, który audyt potrafi przynajmniej zauważyć, i stąd ostrzeżenie w raporcie powyżej. Dla reszty werdykt works znaczy, że kanały, które to narzędzie widzi, zostały objęte - a nie że żadna inna droga nie istnieje.

--json wypisuje te same fakty w formie maszynowej, --report zapisuje wersję dla człowieka do pliku, a sesja z werdyktem innym niż works prowadzi ten plik banerem o nierzetelnym dowodzie, zamiast chować go na dole.