Když důkaz přeloží program, kterému soud nerozumí

Soudní síň na chvíli ztichne. Na obrazovce stojí tři položky: „Zpráva odeslána 14:32.“ „Poloha: X.“ „Kontakt: Y.“ Žalobce se o ně opře, obhájce si je poznamená, soudce se podívá do spisu. Tabulka nevypadá jako názor. Vypadá jako otevřený telefon, který se naučil mluvit úředním jazykem.

Jenže telefon takovou větu nejspíš nikde neuchovával. Nemusel v něm existovat text „odeslána“, jméno kontaktu ani čas napsaný ve formátu, který právě vidíme. Mohla v něm být čísla, vazby mezi tabulkami, časová hodnota bez viditelného pásma a příznak, jehož význam určuje konkrétní verze aplikace. Lidsky srozumitelná věta vznikla až cestou.

To samo o sobě není podezřelé. Přesně k tomu forenzní software slouží. Bez něj by vyšetřovatel předkládal soudu bloky binárních dat, nikoli komunikaci, časovou osu nebo mapu. NIST ve své rozsáhlé revizi označuje správně používané metody digitální forenziky za spolehlivé, zároveň však upozorňuje, že s proměnami operačních systémů a aplikací se může měnit i význam artefaktů.^[1]

Klíčová otázka tedy nezní: Lže program? Mnohem přesnější je: Co přesně program přečetl, co odvodil a co ještě přidal člověk?

Vezměme jediný řádek reportu a vydejme se opačným směrem. Ne od telefonu k soudu, ale od soudní věty zpět k původnímu zařízení. Na každém kroku lze ukázat, co bylo zjištěno — a co už bylo přeloženo.

Už samotné slovo „databáze“ může vytvářet dojem, že jsme dorazili k nezpochybnitelnému základu. Jenže databáze není neutrální sklad skutečnosti. Je to způsob, jakým konkrétní aplikace v konkrétní verzi organizovala svůj provoz. Některé tabulky popisují uživatelské objekty, jiné synchronizaci, frontu požadavků, stav rozhraní nebo dočasnou cache. Stejná událost může zanechat více stop; jedna stopa může přetrvat i poté, co už neodpovídá aktuálnímu stavu, který uživatel viděl.

Také rozhraní programu provádí rozhodnutí, byť vypadají pouze jako pomoc uživateli. Výchozí filtr může skrýt systémové záznamy, řazení může smíchat časy z různých zdrojů a sjednocené jméno kontaktu může překrýt několik identifikátorů. Export pak zpravidla nezachytí všechno, co analytik viděl v pracovním prostředí: například zdrojovou cestu, přesnost časové hodnoty, způsob odvození jména nebo varování o částečné podpoře. Report tedy není jen přepsaná databáze. Je to výběr z interpretace databáze.

Představme si čistě modelový záznam. Nejde o strukturu žádné konkrétní aplikace; právě naopak. Je abstraktní, aby bylo vidět, kolik významu musí teprve vzniknout:

msg_id       88421
peer_id      47
direction    1
created_at   1713184320000
state        3
source       messages.db / row 88421

Číslo 1713184320000 může program po správném určení jednotky převést na 15. dubna 2024 ve 12:32 UTC a následně na 14:32 ve středoevropském letním čase. Ale k výsledku se přidaly nejméně tři předpoklady: že jde o unixový čas, že hodnota je v milisekundách a že pro zobrazení má být použito pásmo Praha. Pokud databáze ukládala lokální čas, serverový čas nebo jinou epochu, stejná aritmetika by vytvořila přesný, ale chybný údaj.

Podobně direction = 1 není přirozeně „odesláno“. Je to jednička. Význam jí dává schéma aplikace a pravidlo parseru. peer_id = 47 není osoba; je to vazba. Jméno Y může být aktuální název kontaktu, jméno uložené v jiné tabulce, profilová hodnota ze synchronizace nebo popisek vytvořený analytikem. A položka může existovat současně v hlavní databázi, transakčním žurnálu, cache i záloze.

Poslední překlad provádí analytik. Rozhodne, který řádek vloží do zprávy, s čím jej spojí a jak přesně závěr formuluje. Poloha X mohla pocházet z jiného zdroje než zpráva; časová blízkost ještě nemusí znamenat společnou událost. Kontakt Y může být technický identifikátor přeložený na osobu, ale samotný záznam nemusí dokazovat, kdo zařízení v dané chvíli držel. Program vytváří čitelný artefakt. Až člověk z něj vytváří tvrzení o světě.

To, že program přidal slovo, neznamená, že si je vymyslel. Znamená to, že zakódovaný význam rekonstruoval podle pravidel. Důkazní problém vzniká tehdy, když tato pravidla nejsou vidět, nejsou ověřena pro konkrétní verzi nebo se jejich výsledek začne vydávat za nezprostředkovaný obsah zařízení.

Nejzrádnější chyba nevypadá jako porucha. Program nespadne, report se nerozsype a řádek není označen červeně. Výstup je úplný, uhlazený a vnitřně konzistentní. Jen jedno pole bylo vyloženo podle starého schématu, jedna časová hodnota podle nesprávné jednotky nebo jedna tabulka nebyla v nové verzi aplikace rozpoznána.

Změna databázového schématu může přesunout význam do jiného sloupce. Neznámá verze aplikace může obsahovat strukturu, pro kterou parser používá pouze podobné pravidlo. Neúplná extrakce může dodat hlavní databázi, ale ne její žurnál; nebo naopak zobrazit fragment bez kontextu, který by vysvětlil jeho stav. Dvě reprezentace stejné události mohou vytvořit duplicitu, zatímco příliš agresivní deduplikace může skrýt, že údaje pocházely z různých zdrojů.

U smazaného artefaktu je situace ještě citlivější. Některá pole mohou zůstat, jiná už mohou být přepsána, a samotný způsob obnovy může spojit fragmenty s různou mírou jistoty. NIST výslovně upozorňuje, že obnova smazaných dat může zahrnovat nadbytečný materiál a že parser může při chybném rozpoznání struktury položky vynechat nebo zobrazit nesprávně.^[1]

Takové chyby bývají spíše systematické než náhodné. Jestliže pravidlo zamění význam určitého příznaku, nezmýlí se jednou z tisíce. Může se stejně zmýlit u každého záznamu, který splní tutéž podmínku. Konzistence pak paradoxně působí jako potvrzení správnosti.

Stejně důležité je rozlišovat „nenalezeno“, „neextrahováno“, „nepodporováno“ a „neexistuje“. Jestliže nástroj novou strukturu nezná, prázdná kategorie v reportu neprokazuje, že telefon příslušná data neobsahoval. Opačným směrem může obnovený či zastaralý záznam potvrzovat existenci datového fragmentu, ale ne nutně to, že položka byla v rozhodné chvíli aktivní, uživateli viditelná nebo jím vědomě vytvořená. Chybný závěr tak nemusí vzniknout nesprávným číslem. Stačí nesprávně pojmenovat jeho důkazní dosah.

Čím profesionálněji report vypadá, tím snazší je přehlédnout, že jeho přesnost může být přesností výpočtu — nikoli jistotou významu.

Odborná debata proto není obžalobou forenzních nástrojů. Literatura rozlišuje chybu nástroje, jeho známé omezení a chybu při použití či interpretaci — tři rozdílné problémy, které mohou v reportu vypadat podobně.^[9] Studie a testovací programy zároveň ukazují, že nástroje obvykle poskytují mimořádně užitečné výsledky. Smyslem testování je zjistit hranice: pro jaké vstupy a verze je funkce ověřená, v čem selhává a kdy je nutné doplnit jinou metodu.^[2][3]

V digitální forenzice má hash zásadní roli. Otisk zdrojového obrazu a pracovních kopií umožňuje doložit, že se analyzovaná posloupnost dat nezměnila. Je to kontrola integrity a jeden z pilířů řetězce nakládání s důkazem. Standardy pro identifikaci, sběr, akvizici a uchování digitálních důkazů stavějí právě na dokumentovaném původu a kontinuitě.^[6][8]

Hash ale neodpoví na otázku, zda byla extrakce úplná, zda parser rozpoznal správné schéma, zda se čas převedl ve správném pásmu ani zda daný záznam dokládá jednání konkrétní osoby. Může dokonale chránit nesprávnou interpretaci, protože potvrzuje neměnnost vstupu, nikoli správnost překladu.

Proto je vedle integrity důležitá auditní stopa: kdo a kdy zařízení převzal, jaký typ akvizice provedl, jaké nástroje a verze použil, s jakým nastavením, jaké mezivýstupy vznikly a odkud přesně pochází rozhodující artefakt. Když se později objeví nový parser nebo pochybnost o časové konverzi, musí být možné cestu zopakovat bez návratu k dojmům.

Dobrá forenzní praxe nestojí na přesvědčení, že „náš software se nemýlí“. Stojí na procesu, který počítá s možností chyby, dokáže ji hledat a umí popsat zbytkovou nejistotu. SWGDE doporučuje testované metody, znalost známých anomálií, dokumentaci, technický přezkum a kombinaci nástrojů či metod podle rizika konkrétního závěru.^[3][4]

Validace

Doložení, že metoda nebo funkce je vhodná pro zamýšlený účel. Jiný důkaz potřebujeme pro otázku „záznam existuje“ a jiný pro závěr „uživatel zprávu skutečně odeslal v tento okamžik“.

Verifikace

Kontrola, že konkrétní implementace, verze a prostředí pracují očekávaným způsobem — typicky na známých datech a s předem určeným výsledkem.

Reprodukovatelnost

Možnost, aby jiný kvalifikovaný odborník ze stejného zdroje a popsaného postupu dospěl k materiálně shodnému zjištění a dohledal jeho původ.

Peer review

Technický přezkum druhou kvalifikovanou osobou: nejen stylistická kontrola reportu, ale prověrka poznámek, dat, postupu, závěrů a limitů.

Nezávislý nástroj

Ověření artefaktu jiným parserem nebo metodou. Dva programy však nejsou automaticky nezávislé, pokud sdílejí knihovnu, dokumentaci nebo stejný předpoklad.

Manuální kontrola

Cílené ověření zdrojové tabulky, SQL dotazu, bajtů, časové konverze, schématu či kontrolního zařízení. Nejde o ruční čtení celého telefonu.

Rozdíl mezi validací a verifikací není ve všech oborech používán úplně stejně. Praktický smysl je ale jasný: nestačí vědět, že určitý typ nástroje obecně funguje. Je potřeba vědět, zda tato funkce v této verzi správně odpovídá na tuto otázku nad tímto druhem dat. SWGDE současně připomíná, že kvůli množství kombinací hardwaru a softwaru nelze otestovat každou situaci.^[2]

Druhý nástroj je cenný, ale není kouzelným razítkem. Shoda dvou výstupů zesiluje důvěru jen tehdy, pokud cesty nejsou ve skutečnosti totožné. Silnější může být trojúhelník: automatický parser, cílená kontrola zdrojové struktury a kontrolní experiment na stejné verzi aplikace. Ne každý artefakt potřebuje takovou hloubku. Rozhodující, neobvyklé nebo verzně citlivé závěry ano.

Zde vzniká právní asymetrie. Specialista může během minut vysvětlit, proč je určitý řádek zprávou, jak se počítá čas a odkud pochází identita kontaktu. Ostatní účastníci řízení často vidí až výsledek. Čím techničtější je mezivrstva, tím větší je riziko, že se přezkum změní v otázku osobní důvěry: věříme člověku, který obsluhuje nástroj?

Soudce nemusí umět napsat parser, stejně jako nemusí obsluhovat sekvenátor DNA. Musí však dostat dost informací, aby mohl hodnotit základ, logiku a limity odborného závěru. Český Ústavní soud opakovaně zdůraznil, že znalecký posudek nemá privilegovanou důkazní sílu a že je třeba prověřovat celý proces jeho vzniku — podklady, metodu i způsob vyvození závěrů.^[10]

Pro digitální důkaz to znamená, že přezkoumatelnost nemusí spočívat v tom, že každý člen senátu pochopí zdrojový kód komerčního programu. Měla by ale umožnit položit konkrétní otázky a dostat konkrétní odpovědi:

1. Jaký byl primární zdroj, typ akvizice a jeho hash? Co extrakce ze své povahy získat nemohla?
2. Jaký nástroj, verze, modul a nastavení vytvořily výstup? Byla podporována konkrétní verze aplikace?
3. Z jakého souboru, tabulky, záznamu či offsetu rozhodující položka pochází?
4. Které části jsou přímo uložené hodnoty a které jsou výsledkem mapování, spojení tabulek nebo normalizace?
5. Jak byl převeden čas: jednotka, epocha, UTC či lokální čas, časové pásmo a letní čas?
6. Jak program zacházel s duplicitami, žurnály, cache a smazanými či neúplnými záznamy?
7. Byl klíčový artefakt ověřen jinou metodou a jsou zaznamenány odchylky nebo známá omezení?

Obhajoba potřebuje reálnou možnost závěr napadnout; soud potřebuje možnost zjistit, zda námitka míří na data, metodu, interpretaci nebo pouze na nesouhlas s výsledkem. To neznamená, že v každé věci musí být zveřejněn zdrojový kód nástroje nebo volně předán celý obsah zařízení. Mohou existovat důvody ochrany soukromí, bezpečnosti i práv třetích osob. Musí však existovat dostatečný technický podklad: identifikace zdroje, protokoly, verze, popis převodů, přístup k relevantním artefaktům za přiměřených podmínek a možnost odborné kontroly.

Samotný screenshot ani několikastránkový PDF export tuto možnost zpravidla nevytvoří. Na druhé straně ani předání terabajtového obrazu bez popisu nepředstavuje skutečnou transparentnost: příjemce dostane materiál, ale ne mapu k napadenému tvrzení. Přezkum je účinný tehdy, když lze propojit konkrétní závěr s konkrétním zdrojem a zopakovat rozhodující transformace. Jde o cílenou dohledatelnost, nikoli o zahlcení technickým objemem.

Standard ISO/IEC 27042 spojuje analýzu digitálních důkazů s kontinuitou, validitou, opakovatelností, reprodukovatelností a záznamem dostatečných informací pro nezávislé přezkoumání.^[5] Jinými slovy: odborník může provést složitý překlad, ale důkazní řízení nesmí být odkázáno pouze na jeho autoritu.

Je snadné sklouznout k opačnému extrému a tvrdit, že skutečným důkazem jsou pouze surové bajty. Nejsou. Bajt bez struktury je stejně málo srozumitelný jako písmeno bez jazyka. Moderní telefon obsahuje ohromné množství dat rozptýlených mezi databázemi, žurnály, kontejnery, systémovými službami, zálohami a cloudovými vazbami. Ruční zpracování každého prvku by bylo pomalé, náchylné k lidské chybě a v reálném vyšetřování prakticky nemožné.

Forenzní software opakuje rutinní operace, udržuje vazby, indexuje, převádí a umožňuje porovnat miliony položek. Jeho grafické rozhraní není kosmetika; je to nástroj myšlení. NIST provozuje CFTT právě proto, aby bylo možné funkce nástrojů testovat pomocí specifikací, známých dat a veřejných testovacích postupů.^[7]

Falešné dilema „člověk, nebo software“ proto nic neřeší. Člověk bez softwaru velkou část digitální reality neuvidí. Software bez člověka neví, na jakou právní otázku odpovídá, zda je artefakt podstatný a jakou míru jistoty závěr unese. Potřebujeme obojí — a mezi oběma částmi viditelnou kontrolní vazbu.

Přezkoumatelnost neznamená zahrnout soud stovkami stran hexadecimálních výpisů. Dobře navržený report může být jednoduchý. Rozdíl je v tom, zda pod jeho povrchem existuje dohledatelná cesta, po níž se lze v případě pochybnosti vrátit.

Takový report může místo kategorického „telefon prokazuje, že zpráva byla odeslána ve 14:32“ použít přesnější větu: „V databázi X byl v záznamu Y nalezen příznak, který parser verze Z pro podporované schéma interpretuje jako odchozí zprávu. Časová hodnota byla převedena z UTC na Europe/Prague; výsledek byl ověřen kontrolou zdrojového záznamu.“

Delší věta není vždy vhodná do hlavního přehledu. Musí však být dostupná v odborné části, protokolu nebo poznámkách. Čitelnost a přezkoumatelnost nejsou protiklady. Čitelný report je vrchol; přezkoumatelná dokumentace jsou jeho základy.

Na obrazovce zůstává stejný řádek. Zpráva odeslána ve 14:32. Poloha X. Kontakt Y. Po celé cestě zpět už ale nepůsobí jako věta, kterou telefon sám napsal pro soud. Je to odborné tvrzení vzniklé ze zachovaných dat, rozpoznané struktury, pravidel parseru, převodů rozhraní a lidského výběru.

Tím se důkaz automaticky neoslabuje. Naopak. Když známe jeho původ, můžeme zjistit, která část je pevná, která závisí na verzi, která byla ověřena a kde zůstává nejistota. Důvěra pak nestojí na logu programu ani na autoritě specialisty, ale na transparentní cestě, kterou lze znovu projít.

Největší paradox profesionálního reportu spočívá v tom, že čím lépe svou práci odvádí, tím méně jsou jeho překlady vidět. Přesně zarovnaná tabulka skrývá databázové vazby, časové konverze, deduplikaci, rozhodnutí parseru i úsudek analytika. Jednoduchost je zde výsledkem složitosti — nikoli její nepřítomností.