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.

Istnieją jeszcze trzy kody, które nie są werdyktami: 1 dla błędu użycia, 2, gdy nie udało się uruchomić celu albo wstrzyknąć, i 12, gdy cel zniknął w sposób sugerujący aplikację jednoinstancyjną, która oddała robotę już działającej kopii.

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 - podpięte, liczone i celowo zostawione mówiące prawdę. Licznik wysokiej rozdzielczości jest tu domyślnie, bo jego skalowanie destabilizowało renderowanie. Timery multimedialne są tu, bo ich skalowanie przesunęłoby timing audio i MIDI. Połączenia sieciowe i jedna ścieżka tworzenia procesu są tu, bo są dowodem, a nie zegarem.
• 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.