e) detekce "zajimavych" API z import table
a) pokus o rozbaleni packovanych (i cryptovanych?) souboru, v pripade uspechu skok na 1. fazi
v techto dvou fazich vidim nejvetsi problem, vim, ze samozrejme "bezny uzivatel" tezko bude menit hlavicky PE a hrat si s API ale ciste hypoteticky, je zcela bezne API cryptovat , maskovat atd (podivej na oblibene Conflictakovi vychytavky) - cili spousty jich po pouziti packeru
Jestli chces naznacit, ze je blbost toto zkouset, protoze to nebude 100%, pak se na to divas ze spatneho pohledu. Samozrejme, ze to nebude 100%, mozna to i bude velmi chabe, ale stale to bude krok dopredu. Zadny software, ktery nyni pouzivame (a vetsinou jde o pomerne drahe softwary), takto automatizovane zkoumat PE soubory neumi a bohuzel jsem ani nenasel zadny, ktery by neco takoveho vubec umel. Klidne bych ho i koupil (za nejakou rozumnou cenu), ale proste takovy program neznam.
Nejefektivnejsi by samozrejme bylo zkoumat kazdy soubor rucne, debuggerovat atd. Jenze to jde udelat u jednotek souboru, ne u tisicu ci desetitisicu. Pro nas jsou vzdy limitujici 2 faktory: deadline a budget. Tyto faktory maji navic protichudne dusledky. Abych se vlezl do terminu a stihnul udelat hodne prace, tak to mohu sice vyresit tak, ze praci rozlozim mezi vice lidi, jenze pak mi vzrostou naklady natolik, ze mi to nikdo nikdy nezaplati. Navic rozpocet je znam predem. Ilustrativni priklad: pred 10 lety zkoumal znalec 2 mesice datove nosice o celkove kapacite 1000 MB a inkasoval za to 50 tisic. Kc. Techto 50 tisic muze predstavovat v dnesnich penezich (s prihlednutim k rustu nakladu, inflaci apod.) rekneme 100 tis. Kc. Ovsem dnes za 100 tisic mame 2 mesice zkoumat napr. 1000 GB dat. Cili penize i doba zustaji stale stejne, ale objem dat se nam zvetsuje 1000 krat! Takze logicky se automatizuje vsechno, co jde, aby se to pocatecni kvantum dat zredukovalo na to skutecne minimum, ktere se pak da (byt stale ve spechu) mozna trochu zkoumat rucne.
Kdyz se podivas na nejaka computer forensics fora ve svete nebo se zeptas nejakych zahranicnich znalcu, nikdo nema cas (ani chut, pripadne znalosti) PE soubory zkoumat vic nez proste proti nim pustit automatizovane programy (ktere vyplivnou temer nic). Oni to beru jako realitu, se kterou nemohou nic udelat. Ja se snazim jit trochu dal, v metodach, v pouzitem softwaru (napr. dle ceskeho distributora firmy AccessData jsme jedini v republice, kdo si zatim koupil novou radu FTK), v hloubce analyz. No a co se tyce analyzy PE souboru, tak vzhledem k tomu, ze programuji nejakych 23 let (na te strance s knihovnou viru, co tady postnul NeptuN, jsem dokonce nasel svuj virus, ktery jsem napsal zacatkem 90. let), se snazim i trochu neco udelat v teto oblasti a vysledny software davam (alespon zatim) verejne k dispozici jako freeware. Nemel jsem zadna ocekavani, kdyz jsem tady napsal, ale to mnozstvi podnetu, ktere jsem tady dostal, je skutecne skvele. Myslim, ze se mi podari hodne z tech veci naimplementovat a co je nepodstatnejsi je, ze mi to realne pomuze v praci. Stale to vsak bude mit velmi velmi daleko k dostatecnosti, jak spravne podotykas. Ale co muzu delat vice? Nebo se na to vykaslat, protoze to "stejne neni dokonale"? Technik, jak zmast a zneefektivnit praci znalcu v tomto oboru je mnoho (google "anti-computer forensic") a znalec se vice a vice stava jen statistou. Velky problem vidim s tim exponencialne rostoucim mnozstvim dat - dnes lze bez obtizi do kazdeho jednoho pocitace vlozit 8 harddisku, coz muze byt 16 TB. Kolik takovych pocitacu muze mit organizovana skupina? V takove situaci uz ani ti kriminalnici nemusi nic sifrovat, staci, aby vsechna sva tajna data ukryly do .exe souboru, a nikdo to nema sanci najit.
Coz mne privadi k myslence, ze by stalo za to nejakym zpusobem kontrolovat, jestli k PE souboru nejsou pripojena "bezprizorni" data. Jakoze treba vezmu .zip soubor a prilepim ho ke konci .exe souboru. Jak by se neco takoveho pak dalo zjistit? Nesoulad mezi velikosti dle PE headeru a skutecnou velikosti?
