Metody detekce „slepených“ souborů.

Záchrana dat

Mnozí možná slyšeli o souborech, jako je rarjpeg. Jedná se o speciální typ souboru, což je jpeg obrázek a rar archiv, které jsou těsně spojeny následující příkazy: UNIX:
kočka obrázek1.jpg archiv.rar > obrázek2.jpg WINDOWS:

kopie /b obrázek1.jpg+archiv.rar obrázek2.jpg

Nebo pokud máte hex editor.

Samozřejmě, abyste skryli skutečnost přenosu informací, můžete použít nejen formát JPEG, ale také mnoho dalších. Každý formát má své vlastní charakteristiky, díky kterým může, ale nemusí být vhodný pro roli kontejneru. Popíšu, jak můžete najít vložené soubory v nejoblíbenějších formátech nebo naznačit skutečnost lepení.

  1. Metody detekce sloučených souborů lze rozdělit do tří skupin:
  2. Metoda kontroly oblasti za značkou EOF. Mnoho populárních formátů souborů má takzvanou značku konce souboru, která je zodpovědná za zobrazení požadovaných dat. Prohlížeče fotografií například přečtou všechny bajty až po tuto značku, ale oblast za ní je ignorována. Tato metoda je ideální pro následující formáty: JPEG, PNG, GIF, ZIP, RAR, PDF.
  3. Metoda pro kontrolu velikosti souboru. Struktura některých formátů (audio a video kontejnery) umožňuje vypočítat skutečnou velikost souboru a porovnat ji s původní velikostí. Formáty: AVI, WAV, MP4, MOV.

Metoda pro kontrolu souborů CFB. CFB nebo Compound File Binary Format je formát dokumentu vyvinutý společností Microsoft, což je kontejner s vlastním systémem souborů. Tato metoda je založena na detekci anomálií v souboru.

Existuje život po skončení souboru?

JPEG

Abychom našli odpověď na tuto otázku, je nutné ponořit se do specifikací formátu, který je „předchůdcem“ sloučených souborů, a pochopit jeho strukturu. Jakýkoli JPEG začíná podpisem 0xFF 0xD8.

Za tímto podpisem následují servisní informace, volitelně ikona obrázku a nakonec samotný komprimovaný obrázek. V tomto formátu je konec obrázku označen dvoubajtovým podpisem 0xFF 0xD9.

PNG

Prvních osm bajtů souboru PNG je obsazeno následujícím podpisem: 0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A. End signature, který ukončí datový tok: 0x49, 0x45, 0x4E, 0x44, 0xAE, 0x42, 0x60, 0x82.

Společný podpis pro všechny archivy rar: 0x52 0x61 0x72 0x21 (Rar!). Poté následuje informace o verzi archivu a další související údaje. Experimentálně bylo zjištěno, že archiv končí signaturou 0x0A, 0x25, 0x25, 0x45, 0x4F, 0x46.

Tabulka formátů a jejich podpisů:
Algoritmus pro kontrolu lepení v těchto formátech je velmi jednoduchý:

  1. Najděte počáteční podpis;
  2. Najděte konečný podpis;
  3. Pokud po konečném podpisu nejsou žádná data, váš soubor je čistý a neobsahuje přílohy! V opačném případě je nutné po finálním podpisu hledat jiné formáty.

GIF a PDF

Dokument PDF může mít více než jednu značku EOF, například kvůli nesprávnému vygenerování dokumentu. Počet konečných podpisů v souboru GIF se rovná počtu snímků v něm. Na základě vlastností těchto formátů je možné vylepšit algoritmus pro kontrolu přítomnosti připojených souborů.
  1. Bod 1 se opakuje z předchozího algoritmu.
  2. Bod 2 se opakuje z předchozího algoritmu.
  3. Když najdete konečný podpis, zapamatujte si jeho umístění a hledejte dále;
  4. Pokud tímto způsobem dosáhnete poslední značky EOF, je soubor čistý.
  5. Pokud soubor nekončí podpisem konce, goto je umístění posledního nalezeného koncového podpisu.
Velký rozdíl mezi velikostí souboru a pozicí za posledním koncovým podpisem indikuje přítomnost lepivé přílohy. Rozdíl může být více než deset bajtů, i když lze nastavit jiné hodnoty.

ZIP

Zvláštností archivů ZIP je přítomnost tří různých podpisů: Struktura archivu je následující:
Záhlaví místního souboru 1
Data souboru 1
Deskriptor dat 1
Záhlaví místního souboru 2
Data souboru 2
Deskriptor dat 2
...
Záhlaví místního souboru
Data souboru č
Datový deskriptor č
Záhlaví dešifrování archivu
Archivujte další datový záznam
Centrální adresář
Nejzajímavější je centrální adresář, který obsahuje metadata o souborech v archivu. Centrální adresář vždy začíná podpisem 0x50 0x4b 0x01 0x02 a končí podpisem 0x50 0x4b 0x05 0x06, za nímž následuje 18 bajtů metadat. Zajímavé je, že prázdné archivy se skládají pouze z konečného podpisu a 18 nulových bajtů. Po 18 bytech přichází oblast komentářů k archivu, což je ideální kontejner pro skrytí souboru.

Chcete-li zkontrolovat archiv ZIP, musíte najít koncový podpis centrálního adresáře, přeskočit 18 bajtů a vyhledat podpisy známých formátů v oblasti komentářů. Velká velikost komentáře naznačuje i fakt lepení.

Na velikosti záleží

AVI

Struktura souboru AVI je následující: každý soubor začíná podpisem RIFF (0x52 0x49 0x46 0x46). Na byte 8 je podpis AVI, který určuje formát (0x41 0x56 0x49 0x20). Blok na offsetu 4, sestávající ze 4 bajtů, obsahuje počáteční velikost datového bloku (pořadí bajtů - little endian). Chcete-li zjistit číslo bloku obsahující další velikost, musíte přidat velikost záhlaví (8 bajtů) a velikost získanou v bloku 4-8 bajtů. Tím se vypočítá celková velikost souboru. Je přijatelné, že vypočítaná velikost může být menší než skutečná velikost souboru. Po vypočtené velikosti bude soubor obsahovat pouze nula bajtů (nutné k zarovnání hranice 1 kB).

Příklad výpočtu velikosti:


WAV

Stejně jako AVI začíná soubor WAV podpisem RIFF, ale tento soubor má podpis z bytu 8 - WAVE (0x57 0x41 0x56 0x45). Velikost souboru se počítá stejným způsobem jako u AVI. Skutečná velikost musí být přesně stejné jako vypočítané.

MP4

MP4 nebo MPEG-4 je formát mediálního kontejneru používaný k ukládání video a audio streamů, který také umožňuje ukládání titulků a obrázků.
Na offsetu 4 bajty jsou podpisy: typ souboru ftyp (66 74 79 70) (QuickTime Container File Type) a subtyp souboru mmp4 (6D 6D 70 34). Pro uznání skryté soubory, zajímá nás možnost vypočítat velikost souboru.

Podívejme se na příklad. Velikost prvního bloku je v offsetu nula a je 28 (00 00 00 1C, pořadí bajtů Big Endian); také označuje posun, kde se nachází velikost druhého datového bloku. Na offsetu 28 najdeme velikost dalšího bloku rovnou 8 (00 00 00 08). Chcete-li najít velikost dalšího bloku, musíte přidat velikosti předchozích nalezených bloků. Velikost souboru se tedy vypočítá:

MOV

Tento široce používaný formát je také kontejner MPEG-4. MOV používá proprietární algoritmus komprese dat, má strukturu podobnou MP4 a používá se ke stejným účelům - pro ukládání audio a video dat, stejně jako souvisejících materiálů.
Stejně jako MP4 má jakýkoli soubor mov 4bajtovou signaturu ftyp na offsetu 4, avšak další signatura má hodnotu qt__ (71 74 20 20). Pravidlo pro výpočet velikosti souboru se nezměnilo: od začátku souboru počítáme velikost dalšího bloku a sečteme ji.

Metodou kontroly této skupiny formátů na přítomnost „sticky“ souborů je vypočítat velikost podle výše uvedených pravidel a porovnat ji s velikostí kontrolovaného souboru. Pokud je aktuální velikost souboru mnohem menší než vypočítaná, znamená to, že došlo k lepení. Při kontrole souborů AVI se akceptuje, že vypočítaná velikost může být menší než velikost souboru kvůli přítomnosti přidaných nul pro zarovnání okraje. V tomto případě je nutné zkontrolovat nuly po vypočítané velikosti souboru.

Kontrola binárního formátu složeného souboru

Tento formát souboru vyvinutý společností Microsoft je také známý jako OLE (Object Linking and Embedding) nebo COM (Component Object Model). soubory DOC, XLS, PPT patří do skupiny formátů CFB.

Soubor CFB se skládá z 512bajtové hlavičky a sektorů stejné délky, které ukládají datové toky nebo informace o službách. Každý sektor má své nezáporné číslo, s výjimkou speciálních čísel: „-1“ - očísluje volný sektor, „-2“ - očísluje sektor uzavírající řetězec. Všechny sektorové řetězce jsou definovány v tabulce FAT.

Předpokládejme, že útočník upravil určitý soubor .doc a na jeho konec vložil jiný soubor. Je jich několik různými způsoby detekovat nebo indikovat anomálii v dokumentu.

Abnormální velikost souboru

Jak bylo uvedeno výše, jakýkoli soubor CFB se skládá ze záhlaví a sektorů stejné délky. Chcete-li zjistit velikost sektoru, musíte přečíst dvoubajtové číslo s offsetem 30 od začátku souboru a zvýšit 2 na mocninu tohoto čísla. Toto číslo se musí rovnat buď 9 (0x0009) nebo 12 (0x000C), velikost sektoru souboru je 512 nebo 4096 bajtů. Po nalezení sektoru musíte zkontrolovat následující rovnost:

(Velikost souboru - 512) mod SectorSize = 0

Pokud tato rovnost není splněna, můžete poukázat na skutečnost lepení souborů. Tato metoda má však významnou nevýhodu. Pokud útočník zná velikost sektoru, pak stačí vložit svůj soubor a dalších n bajtů, aby velikost vložených dat byla násobkem velikosti sektoru.

Neznámý typ sektoru

Pokud útočník ví o metodě, jak obejít předchozí kontrolu, pak tato metoda dokáže detekovat přítomnost sektorů s nedefinovanými typy.

Definujme rovnost:

FileSize = 512 + CountReal * SectorSize, kde FileSize je velikost souboru, SectorSize je velikost sektoru, CountReal je počet sektorů.

Definujeme také následující proměnné:

  1. CountFat – počet sektorů FAT. Nachází se v offsetu 44 od začátku souboru (4 bajty);
  2. CountMiniFAT – počet sektorů MiniFAT. Nachází se v offsetu 64 od začátku souboru (4 bajty);
  3. CountDIFAT – počet sektorů DIFAT. Nachází se v offsetu 72 od začátku souboru (4 bajty);
  4. CountDE – počet sektorů Directory Entry. Chcete-li najít tuto proměnnou, musíte najít první sektor DE, který je na offsetu 48. Pak je potřeba získat kompletní zastoupení DE z FAT a spočítat počet DE sektorů;
  5. CountStreams – počet sektorů s datovými toky;
  6. CountFree – počet volných sektorů;
  7. CountClassified – počet sektorů s určitým typem;
CountClassified = CountFAT + CountMiniFAT + CountDIFAT + CountDE + CountStreams + CountFree

Je zřejmé, že pokud CountClassified a CountReal nejsou stejné, můžeme dojít k závěru, že soubory mohou být sloučeny.

koncept" Magické číslo"v programování má tři významy:

  • Podpis dat
  • Vybrané jedinečné hodnoty, které by neměly být stejné jako jiné hodnoty (například UUID)
  • Špatná praxe programování.

Podpis dat

Magické číslo nebo podpis, - celé číslo nebo textová konstanta používaná k jednoznačné identifikaci zdroje nebo dat. Takové číslo samo o sobě nemá žádný význam a může způsobit zmatek, pokud se objeví v programovém kódu bez příslušného kontextu nebo komentáře, zatímco pokus o jeho změnu na jiné, byť hodnotou blízké, může vést ke zcela nepředvídatelným následkům. Z tohoto důvodu byla taková čísla ironicky nazývána magická čísla. V současné době je tento název pevně zavedený jako pojem. Například jakákoli kompilovaná třída jazyka Java začíná hexadecimálním „magickým číslem“ 0xCAFEBABE. Druhým široce známým příkladem je jakýkoli spustitelný soubor OS Microsoft Windows s příponou .exe začíná posloupností bajtů 0x4D5A (což odpovídá ASCII znakům MZ - iniciály Marka Zbikowského, jednoho z tvůrců MS-DOS). Méně známým příkladem je neinicializovaný ukazatel v Microsoft Visual C++ (od verze Microsoft Visual Studio 2005), který má v režimu ladění adresu 0xDEADBEEF.

Ve stylu UNIX operační systémy Typ souboru je obvykle určen podpisem souboru bez ohledu na příponu jeho názvu. Poskytují standardní souborový nástroj pro interpretaci podpisu souboru.

Špatná praxe programování

Také „magická čísla“ jsou špatné programovací praktiky, pokud zdrojový text obsahuje číselná hodnota a není jasné, co to znamená. Například takový úryvek napsaný v Javě by byl špatný:

drawSprite(53, 320, 240);

final int SCREEN_WIDTH = 640 ;

final int SCREEN_HEIGHT = 480 ;

final int SCREEN_X_CENTER = SCREEN_WIDTH / 2 ;

  • final int SCREEN_Y_CENTER = SCREEN_HEIGHT / 2 ;
  • final int SPRITE_CROSSHAIR = 53 ;
  • ... drawSprite(SPRITE_CROSSHAIR, SCREEN_X_CENTER, SCREEN_Y_CENTER);
  • Nyní je to jasné: tento řádek zobrazuje sprite - zaměřovací kříž zaměřovače - uprostřed obrazovky. Ve většině programovacích jazyků budou všechny hodnoty použité pro takové konstanty vypočteny v době kompilace a nahrazeny místy, kde jsou hodnoty použity. Taková změna ve zdrojovém textu tedy nesníží výkon programu.

Kromě toho jsou magická čísla potenciálním zdrojem chyb v programu:

Pokud je stejné magické číslo v programu použito více než jednou (nebo by mohlo být potenciálně použito), pak jeho změna bude vyžadovat úpravy každého výskytu (místo pouze jedné úpravy hodnoty pojmenované konstanty). Pokud nejsou všechny výskyty opraveny, dojde alespoň k jedné chybě.

Alespoň v jednom z výskytů může být magické číslo zpočátku špatně napsáno, což je poměrně obtížné odhalit.

Magické číslo může záviset na implicitním parametru nebo jiném magickém čísle. Pokud tyto závislosti, které nejsou explicitně identifikovány, nejsou splněny, dojde alespoň k jedné chybě. Při úpravě výskytů jednoho magického čísla je možné omylem změnit jiné magické číslo, které je nezávislé, ale má stejnou číselnou hodnotu. Magická čísla a multiplatformní // nesprávné - předpokládá se, že délka je 4 bajty memset(a, 0, NUMBER_OF_ELEMENTS * sizeof(long)); // ne zcela správně - duplikace názvu typu (pokud se typ změní, budete ho muset změnit i zde) memset (a , 0 , NUMBER_OF_ELEMENTS * sizeof (a [ 0 ])); // správné, optimální pro dynamická pole nenulové velikosti memset(a, 0, sizeof(a)); // správné, optimální pro statická pole

Čísla, která nejsou kouzelná

Ne všechna čísla je nutné převádět na konstanty. Například kód pro

Funkční kód (FC) v hlavičce telegramu identifikuje typ telegramu, například telegram požadavku (požadavek nebo odeslání/žádost) a telegram potvrzení nebo odpovědi (rámec potvrzení, rámec odpovědi). Kromě toho kód funkce obsahuje aktuální funkci přenosu a řídicí informace, které zabraňují ztrátě a duplikaci zpráv, nebo typ stanice se stavem FDL.

7 6 5 4 3 2 1 0 FC: Žádost o kód funkce
1 Vyžádejte si telegram
X FCV = Alternativní bit zapnutý
X href=”http://profibus.felser.ch/en/funktionscode.htm#aufruffolgebit”>FCB = Alternativní bit (z počtu snímků)
1 0 (0x0) CV = hodnota hodin ()
1 ostatní Rezervováno
0 0 (0x0) TE = Časová událost (synchronizace hodin)
0 3 (0x3) SDA_LOW = Odeslání dat potvrzeno - nízká priorita
0 4 (0x4) SDN_LOW = Odeslání dat není potvrzeno - nízká priorita
0 5 (0x5) SDA_HIGH = Odeslání dat potvrzeno - vysoká priorita
0 6 (0x6) SDN_HIGH = Odeslání dat není potvrzeno
0 7 (0x7) MSRD = Odeslat data požadavku s odpovědí vícesměrového vysílání
0 9 (0x9) Vyžádejte si stav FDL
0 12 (0xC) SRD low = Odeslat a vyžádat si data
0 13 (0xD) SRD high = Odeslat a požadovat data
0 14 (0xE) Žádost Identifikujte s odpovědí
0 15 (0xF) Požádat o stav LSAP s odpovědí 1)
0 ostatní Rezervováno

1) tato hodnota není v poslední verzi standardu již definována, ale pouze vyhrazena

7 6 5 4 3 2 1 0 FC: Odpověď na kód funkce
0 Telegram s odpovědí
0 Rezervováno
0 0 Otrok
0 1 Mistr není připraven
1 0 Mistr připraven, bez žetonu
1 1 Mistr připraven, v prstenu
0 (0x0) OK
1 (0x1) UE = Chyba uživatele
2 (0x2) RR = Žádné zdroje
3 (0x3) RS = SAP není povolen
8 (0x8) DL = Data Low (normální případ s DP)
9 (0x9) NR = Nejsou připravena žádná data odezvy
10 (0xA) DH = Data High (Čeká se na diagnostiku DP)
12 (0xC) RDL = Data nebyla přijata a Data Low
13 (0xD) RDH = Data nebyla přijata a Data High
ostatní Rezervováno

Frame Count Bit Bit počtu rámců FCB (b5) zabraňuje duplikaci zprávy potvrzovací nebo odpovídající stanicí (odpovídající) a jakékoli ztrátě volající stanicí (iniciátorem). Z tohoto jsou vyloučeny požadavky bez potvrzení (SDN) a požadavky na stav FDL, identitu a stav LSAP.

Pro bezpečnostní sekvenci musí iniciátor nést FCB pro každý respondér. Když je telegram s požadavkem (Žádost nebo Odeslat/Požadavek) odeslán respondentovi poprvé nebo pokud je znovu odeslán odpovídacímu zařízení, které je aktuálně označeno jako nefunkční, musí být FCB nastaveno tak, jak je definováno v odpovídacím zařízení. Iniciátor toho dosáhne v telegramu požadavku s FCV=0 a FCB=1. Odpovídající musí vyhodnotit telegram tohoto druhu jako první cyklus zprávy a uložit FCB=1 spolu s adresou iniciátora (SA) (viz následující tabulka). Tento cyklus zpráv nebude iniciátor opakovat. V následujících telegramech požadavku stejnému respondentovi musí iniciátor nastavit FCV=1 a změnit FCB s každým novým telegramem požadavku. Každý respondent, který obdrží telegram s požadavkem adresovaný jemu s FCV=1, musí vyhodnotit FCB. Pokud se FCB ve srovnání s posledním telegramem požadavku od stejného iniciátora (stejný SA) změnil, je to platné potvrzení, že předchozí cyklus zpráv byl řádně uzavřen. Pokud telegram Požadavek pochází od jiného iniciátora (jiného SA), vyhodnocení FCB již není nutné. V obou případech musí respondent uložit FCB se zdrojovým SA, dokud neobdrží nový telegram, který je mu adresován. V případě ztraceného nebo narušeného potvrzovacího nebo odezvového telegramu nesmí iniciátor při opakování požadavku změnit FCB: to bude znamenat, že předchozí cyklus zpráv byl chybný. Pokud respondent obdrží telegram požadavku s FCV=1 a stejným FCB jako poslední telegram požadavku od stejného iniciátora (stejné SA), bude to znamenat opakování požadavku. Respondent musí následně znovu odeslat potvrzovací nebo odezvový telegram, který je připraven. Do výše uvedeného potvrzení nebo přijetí telegramu s jinou adresou (SA nebo DA), která není potvrzena (Odeslat data bez potvrzení, SDN), musí respondent ponechat poslední potvrzovací nebo odpovědní telegram připravený pro případný pokus o opakování požadavku. . V případě telegramů požadavku, které nejsou potvrzeny, a se stavem požadavku FDL, identifikací a stavem LSAP, FCV=0 a FCB=0; hodnocení respondentem již není nutné.

b5 b4 Bitová pozice
FCB FCV Stav Význam Akce
0 0 DA = TS/127 Žádost bez potvrzení
Vyžádejte si status FDL/Ident/stav LSAP
Smazat poslední potvrzení
0/1 0/1 DA#TS Požádejte jiného respondenta
1 0 DA = TS První žádost FCBM:= 1
SAM:=SA
Smazat poslední potvrzení / odpověď
0/1 1 DA = TS
SA = SAM
FCB#FCBM
Nová žádost Smazat poslední potvrzení / odpověď
FCBM:=FCB
Podržte potvrzení / odpověď v připravenosti k opakování
0/1 1 DA = TS
SA = SAM
FCB = FCBM
Opakovat požadavek FCBM:=FCB
Opakujte potvrzení / odpověď a pokračujte v pohotovosti
0/1 1 DA = TS
SA#SAM
Nový iniciátor FCBM:=FCB
SAM:= SA Podržet potvrzení / odpověď v připravenosti k opakování

FCBM uloženo FCB v paměti SAM uloženo SA v paměti

Vyhledávání při skenování souborů známých typů (nebo, jak se často říká, vyhledávání souborů podle podpisu) je jedním z nejúčinnějších používaných v nástroji pro obnovu dat R-Studio. Použití daného podpisu umožňuje obnovit soubory určitého typu v případech, kdy informace o struktuře adresářů a názvech souborů částečně nebo úplně chybí (poškozeny).

K určení umístění souborů se obvykle používá tabulka rozdělení disku. Pokud porovnáte disk s knihou, bude tabulka oddílů podobná jejímu obsahu. Při skenování hledá R-Studio známé typy souborů v tabulce rozdělení disku pomocí určitých specifikovaných signatur. To je umožněno tím, že prakticky každý typ souboru má jedinečný podpis nebo datový vzor. Podpisy souborů se nacházejí na konkrétním místě na začátku souboru a v mnoha případech také na konci souboru. Při skenování R-Studio porovnává nalezená data s podpisy známých typů souborů, což umožňuje jejich identifikaci a obnovu jejich dat.

Pomocí technologie pro skenování známých typů souborů vám R-Studio umožňuje obnovit data z disků, které byly přeformátovány a jejichž tabulky oddílů byly přepsány. Navíc, pokud je diskový oddíl přepsán, poškozen nebo odstraněn, pak je jedinou možností skenování známých typů souborů.

Ale téměř vše má své nevýhody a známé typy souborů používané v R-Studiu nejsou výjimkou. Při skenování známých typů souborů vám tedy R-Studio umožňuje obnovit pouze nefragmentované soubory, ale jak již bylo zmíněno, ve většině případů se jedná o nejnovější možný způsob.

R-Studio již obsahuje podpisy pro nejběžnější typy souborů (úplný seznam známých typů souborů si můžete prohlédnout v sekci online nápovědy R-Studio.)

V případě potřeby může uživatel do R-Studia přidat nové typy souborů. Pokud například potřebujete najít soubory jedinečného typu nebo soubory vytvořené po posledním datu vydání R-Studia, můžete k souborům známých typů přidat své vlastní podpisy. Tento proces bude dále diskutován.

Vlastní soubory známých typů
Vlastní podpisy pro známé typy souborů jsou uloženy v souboru XML zadaném v dialogovém okně Nastavení. Přidání podpisu se skládá ze dvou částí:

  1. Určení podpisu souboru umístěného na začátku souboru, a pokud existuje, na konci souboru.
  2. Vygenerujte soubor XML obsahující podpis souboru a další informace o typu souboru.

To vše lze provést pomocí R-Studio. Přitom nemusíte být specialistou v oblasti skládání (úprav) XML dokumentů ani v oblasti hexadecimálních úprav - v tento manuál(článek) zaměřený na samotného uživatele vstupní úroveň, všechny fáze tohoto procesu budou podrobně diskutovány.

Příklad: Přidání podpisu pro soubor MP4 (Kodek XDCam-EX)
Podívejme se na přidání podpisu souboru na příkladu souboru .MP4 vytvořeného pomocí Sony XDCAM-EX. Využijete ji například v případě poškození SD karty pro soubory, které se vám ještě nepodařilo uložit na pevný disk počítače.

První fáze: Určení podpisu souboru
Chcete-li určit podpis souboru, zvažte příklady souborů stejného formátu.

Nechť to jsou čtyři video soubory ze Sony XDCAM-EX:
ZRV-3364_01.MP4
ZRV-3365_01.MP4
ZRV-3366_01.MP4
ZRV-3367_01.MP4

Pro snazší zvážení nechť se jedná o malé soubory. Větší soubory je obtížnější zobrazit v šestnáctkové soustavě.

1. Otevřete soubory v R-Studio. Chcete-li to provést, klepněte pravým tlačítkem myši na každý soubor a z místní nabídky vyberte příkaz Zobrazit/Upravit.

2. Porovnejme soubory. Budeme hledat stejný vzor nalezený ve všech čtyřech souborech. On se objeví podpis souboru. Typicky se podpisy souborů nacházejí na začátku souboru, ale někdy i na konci.

3. Definujte podpis souboru na začátku souboru. V našem příkladu se nachází na samém začátku souboru. Všimněte si, že se to nestává vždy - podpis souboru je často na začátku souboru, ale ne na prvním řádku (offset).

Z obrázků níže se zdá, že obsah všech čtyř souborů je odlišný, ale všechny začínají stejným podpisem souboru.


Kliknutím na obrázek jej zvětšíte


Kliknutím na obrázek jej zvětšíte


Kliknutím na obrázek jej zvětšíte


Kliknutím na obrázek jej zvětšíte

Zvýrazněná oblast na obrázcích je podpis souboru tohoto typu soubory. Je prezentován v textovém i hexadecimálním formátu.

V textové podobě vypadá podpis souboru takto:
....ftypmp42....mp42........zdarma

Tečky (.“) označují znaky, které nelze znázornit v textové podobě. Proto je také nutné uvést hexadecimální formu podpisu souboru:
00 00 00 18 66 74 79 6D 70 34 32 00 00 00 00 6D 70 34 32 00 00 00 00 00 00 00 08 66 72 65 65

4. Stejným způsobem definujeme podpis souboru, ale na samém konci souboru. Může to být jiný podpis souboru, jiná délka.

Níže uvedené obrázky zvýrazňují podpis souboru na konci souboru:


Kliknutím na obrázek jej zvětšíte


Kliknutím na obrázek jej zvětšíte


Kliknutím na obrázek jej zvětšíte


Kliknutím na obrázek jej zvětšíte

Upozorňujeme, že data před vybranou oblastí (podpis souboru) jsou ve všech čtyřech souborech stejná. Toto je technická informace, která není podpisem souboru, ale naznačuje, že všechny čtyři snímky (soubory) byly pořízeny stejným fotoaparátem se stejnými parametry. Obvykle je možné rozlišit odpovídající vzory s technickými informacemi od podpisu souboru. V našem příkladu v posledním řádku před začátkem podpisu souboru vidíme text ‚RecordingMode type=”normal”‘, což jasně naznačuje, že se jedná o nějaký parametr souboru, nikoli podpis. Vždy věnujte zvláštní pozornost tomuto řádku, abyste jej omylem nezahrnuli technické informacečást podpisu souboru.

V našem případě je podpis souboru následující text:
...
Připomeňme, že tečky označují znaky, které nelze znázornit v textové podobě.

V šestnáctkové soustavě vypadá podpis souboru takto:
3N 2F 4E 6F 6E 52 65 61 6N 54 69 6A 65 4A 65 74 61 3E 0D 0A 00
Poznámka: podpis nebude vždy na konci souboru.

Druhá fáze: Vytvoření souboru XML popisujícího známý typ souboru
Nyní, po definování podpisu souboru, můžete vytvořit soubor XML a zahrnout odpovídající typ souboru do R-Studia. To lze provést dvěma způsoby:

2.1 Použití vestavěného editoru podpisu grafického souboru:
Vyberte položku Nastavení z nabídky Nástroje, v dialogovém okně Nastavení, které se otevře, klikněte na kartu Známé typy souborů a poté klikněte na tlačítko Upravit typy souborů uživatele.

Kliknutím na obrázek jej zvětšíte

Klepněte na tlačítko Vytvořit typ souboru v dialogovém okně Upravit typy souborů uživatele.
Nastavte následující možnosti:

  • Id – jedinečný digitální identifikátor. Toto číslo bude vybráno náhodně; Jediná věc je, že by se neměl shodovat s digitálním identifikátorem jiného typu souboru.
  • Popis skupiny – skupina, ve které budou nalezené soubory v R-Studiu umístěny. Můžete nastavit buď nová skupina nebo vyberte jednu z těch, které již existují. Pro nás to bude skupina „Multimediální video (Multimedia: Video)“.
  • Popis - stručný popis typ souboru. V našem příkladu můžete použít například „Sony cam video, XDCam-EX“.
  • Přípona - přípona souborů tohoto typu. V našem případě - mp4.

Parametr Features je volitelný, v našem případě jej nemusíme používat.

Kliknutím na obrázek jej zvětšíte

Dále musíte zadat podpis počátečního a koncového souboru. Chcete-li to provést, vyberte možnost Začít a poté kontextové menu příkaz Přidat podpis.

Kliknutím na obrázek jej zvětšíte

Poté dvakrát klikněte na pole<пустая сигнатура> () a zadejte příslušný text.

Kliknutím na obrázek jej zvětšíte

Poté vytvořte podpis konečného souboru. Nezapomeňte zadat 21 do sloupce Od.

Kliknutím na obrázek jej zvětšíte

Úspěšně jste vytvořili svůj vlastní podpis pro známé typy souborů.

Nyní jej musíte uložit. Existují dva způsoby: buď jej můžete uložit do výchozího souboru určeného na kartě Hlavní v dialogovém okně Nastavení kliknutím na tlačítko Uložit. Nebo klikněte na tlačítko Uložit jako... a uložte podpis do jiného souboru.

2.2 Ruční vytvoření souboru XML popisujícího známý typ souboru:
K vytvoření tohoto souboru Použijme XML verze 1.0 a kódování UTF-8. Pokud nevíte, co to je, nezoufejte – stačí otevřít jakýkoli textový editor(například Notepad.exe) a do prvního řádku zadejte následující text:

Dále vytvoříme XML tag, který definuje typ souboru (FileType). S ohledem na dříve popsané atributy XML bude značka vypadat takto:

Vložíme to hned poté

Dále definujeme podpis souboru (tag ). Počáteční podpis (na začátku souboru) bude uvnitř značky bez jakýchkoliv atributů. Používáme textový typ podpisu, ale zároveň nahrazujeme hexadecimálními znaky, které nelze znázornit v textové podobě. Před každý hexadecimální znak vložíme "\x" Tedy značku s podpisem souboru bude vypadat takto:

Pokud existuje, musíte také definovat koncový podpis (na konci souboru). Používá stejnou značku, ale s prvkem „from“ a atributem „end“. Bude to vypadat takto:

Pamatujte, že podpis konečného souboru neobsahoval netextové znaky, ale obsahoval lomítka a trojúhelníkové závorky. Aby se předešlo zmatkům a chybám v syntaxi XML, nahradíme v podpisu znaky "/", "<" и ">“ jejich hexadecimální hodnoty.

Na konci po podpisech souborů musí být uzavírací značky FileType a FileTypeList:

Celý soubor by tedy měl vypadat takto:


\x00\x00\x00\x18ftypmp42\x00\x00\x00\x00mp42\x00\x00\x00\x00\x00\x00\x00\x08 zdarma
\x3C\x2FNonRealTimeMeta\x3E\x0D\x0A\x00

Pamatujte: Syntaxe XML rozlišuje velká a malá písmena, takže správný tag by byl , ne .

Uložme soubor v textovém formátu s příponou .xml. Například: SonyCam.xml.

Úspěšně jsme vytvořili vlastní podpis pro známé typy souborů. Tento příklad je zcela dostačující k pochopení základních principů vytváření vlastního typu souboru. Zkušenější uživatelé mohou použít XML verze 2.0. Více se o tom můžete dočíst v sekci online nápovědy R-Studio.

Krok 3: Kontrola a přidání souboru popisujícího známý typ souboru
Dalším krokem je přidání (nahrání) vašeho XML souboru do R-Studia. V tomto případě bude automaticky zkontrolován.

Načteme soubor XML vytvořený v předchozí fázi do R-Studia. Chcete-li to provést, vyberte položku Nastavení v nabídce Nástroje. V oblasti Typy souborů uživatele na kartě Hlavní v dialogovém okně Nastavení přidejte soubor XML, který jsme vytvořili (SonyCam.xml). Klepněte na tlačítko Použít.

Kliknutím na obrázek jej zvětšíte

2. Odpovězte Ano na žádost o stažení nového typu souboru.

Kliknutím na obrázek jej zvětšíte

3. Chcete-li ověřit, zda byl typ souboru úspěšně načten, klepněte na kartu Známé typy souborů v dialogovém okně Nastavení. Nezapomeňte, že jsme přidali typ souboru do skupiny Multimediální video. Po rozbalení této skupiny (složky) bychom měli vidět prvek s popisem, který jsme kdy zadali vytváření XML soubor: Sony cam video, XDCam-EX (.mp4).

Kliknutím na obrázek jej zvětšíte


Kliknutím na obrázek jej zvětšíte

Pokud jsou v syntaxi souboru nějaké chyby, zobrazí se odpovídající zpráva:

Kliknutím na obrázek jej zvětšíte

V takovém případě znovu zkontrolujte, zda váš soubor XML neobsahuje chyby. Pamatujte: Syntaxe XML rozlišuje velká a malá písmena a každá značka musí mít na konci uzavírací značku.

Krok 4: Testování souboru popisujícího známý typ souboru
Chcete-li zkontrolovat správnost vlastního typu souboru, který jsme vytvořili, zkusme najít naše soubory .mp4 na vyměnitelném USB flash disku.

1. V systému Windows Vista nebo Windows 7 proveďte úplné (nikoli rychlé) naformátování disku nebo použijte nástroj pro čištění místa na disku (například R-Wipe & Clean) úplné odstranění všechna data dostupná na disku. Nechat USB disk naformátovaný na FAT32 (velikost hledaných souborů nepřesahuje 2 GB).

2. Zkopírujte testovací soubory na disk a restartujte počítač, aby byl obsah mezipaměti uložen na disk. Můžete také zakázat externí disk a poté jej znovu připojte.

3. V OS bude disk definován jako např. logický pohon F:\.

4. Spustíme R-Studio. Vyberte náš disk (F:\) a klikněte na tlačítko Skenovat

Kliknutím na obrázek jej zvětšíte

5. V dialogovém okně Skenovat v oblasti ( Systém souborů) klikněte na tlačítko Změnit... a zrušte zaškrtnutí všech políček. Tímto způsobem zakážeme vyhledávání souborových systémů a souborů pomocí tabulky oddílů.
Kliknutím na obrázek jej zvětšíte

6. Zaškrtněte políčko Extra hledání známých typů souborů. To umožní R-Studio při skenování vyhledávat známé typy souborů.

7. Chcete-li zahájit skenování, klepněte na tlačítko Skenovat.

8. Počkáme, než R-Studio prohledá disk. Na kartě Informace o skenování se zobrazí průběh (průběh) skenování.


Kliknutím na obrázek jej zvětšíte

9. Po dokončení skenování vyberte prvek Extra Found Files a poklepejte na něj.


Kliknutím na obrázek jej zvětšíte

10. Naše testovací soubory budou umístěny ve složce Sony cam video, XDCam-EX (nebo ve složce s jiným názvem, který odpovídá popisu typu souboru uvedenému ve druhé fázi).


Kliknutím na obrázek jej zvětšíte

Vidíte, že názvy souborů, data a umístění (složky) nebyly obnoveny, protože tyto informace uloženy v souborový systém. R-Studio proto automaticky zobrazí každý soubor s novým názvem.

Je však zřejmé, že obsah souborů není poškozen. Chcete-li to ověřit, otevřete je v příslušném programu, například VLC media player.


Kliknutím na obrázek jej zvětšíte

Závěr
Schopnost R-Studio vyhledávat známé typy souborů umožňuje obnovit data i z disku, jehož systémy souborů byly buď přepsány. Soubory můžete poměrně efektivně vyhledávat pomocí jejich podpisů, což se hodí zejména v případě, že přesně znáte typ obnovovaných souborů, jako v našem příkladu. Schopnost vytvářet vlastní typy souborů vám umožňuje přidat jakýkoli soubor, který má specifický podpis souboru, do seznamu známých typů souborů.

Můj šéf mi dal docela zajímavý úkol. V krátké době napište analyzátor spustitelných souborů, který by byl schopen najít těla virů na základě signatur a určit použitý packer/cryptor. Hotový prototyp se objevil během několika hodin.

Slovo autora

Analýza podpisu

Hledání škodlivého objektu pomocí signatur je něco, co umí každý antivirus. V obecný případ podpis je formalizovaný popis určitých charakteristik, podle kterých lze určit, že kontrolovaný soubor je virus a dobře definovaný virus.

Jsou zde různé techniky. Alternativou je použití podpisu složeného z N bajtů škodlivého objektu. V tomto případě nelze provést hloupé srovnání, ale srovnání pomocí určité masky (jako hledání bytů EB ??? CD 13). Nebo se zeptejte dodatečné podmínky jako „takové a takové bajty by měly být na vstupním bodu programu“ a tak dále. Podpis malwaru je zvláštní záležitostí.

Stejným způsobem jsou popsány některé znaky, podle kterých lze určit, že spustitelný soubor je zabalen do jednoho nebo jiného kryptoru nebo packeru (například banální ASPack). Pokud pozorně čtete náš časopis, pak jste určitě slyšeli o takovém nástroji, jako je PEiD, který je schopen identifikovat nejčastěji používané packery, kryptory a kompilátory (databáze má velké množství podpisů) pro do něj přenesený PE soubor . Bohužel, nové verze programu již dlouho nevycházejí a nedávno se na oficiálních stránkách objevila zpráva, že projekt nebude mít další vývoj. Je to škoda, protože možnosti PEiD (zejména vzhledem k systému pluginů) by se mi mohly velmi hodit. Po krátké analýze bylo jasné, že tato možnost není. Ale po prohrabání anglicky psaných blogů jsem rychle našel to, co mi vyhovovalo. Projekt YARA (code.google.com/p/yara-project).

Co je YARA?

Od samého začátku jsem byl přesvědčen, že někde na internetu již existuje open source vývoj, který si vezme za úkol určit shodu mezi určitým podpisem a zkoumaným souborem. Pokud bych takový projekt našel, mohl by se snadno umístit na koleje webové aplikace, přidat tam různé podpisy a získat to, co se ode mě požaduje. Plán se mi začal zdát ještě reálnější, když jsem si přečetl popis projektu YARA.

Sami vývojáři jej umisťují jako nástroj, který pomáhá výzkumníkům malwaru identifikovat a klasifikovat škodlivé vzorky. Výzkumník může vytvářet popisy pro různé typy malware pomocí textu nebo binárních vzorů, které popisují formalizované vlastnosti malwaru. Takto se získávají podpisy. Ve skutečnosti se každý popis skládá ze sady řádků a nějakého logického výrazu, na jehož základě je určena spouštěcí logika analyzátoru.

Pokud jsou u zkoumaného souboru splněny podmínky některého z pravidel, je podle toho určen (například takový a takový červ). Jednoduchý příklad pravidla, abyste pochopili, o čem mluvíme:

pravidlo silent_banker: bankéř
{
meta:
description = "Toto je jen příklad"
úroveň_vlákna = 3
in_the_wild = pravda
řetězce:
$a = (6A 40 68 00 30 00 00 6A 14 8D 91)
$b = (8D 4D B0 2B C1 83 C0 27 99 6A 4E 59 F7 F9)
$c = "UVODFRYSIHLNWPEJXQZAKCBGMT"
stav:
$a nebo $b nebo $c
}

V tomto pravidle říkáme YARA, že jakýkoli soubor, který obsahuje alespoň jeden ze vzorových řetězců popsaných v proměnných $a, $b, $c, by měl být klasifikován jako silent_banker trojan. A to je velmi jednoduché pravidlo. Ve skutečnosti mohou být pravidla mnohem složitější (o tom si povíme níže).
O autoritě projektu YARA hovoří i seznam projektů, které jej využívají, a to:

  • VirusTotal Malware Intelligence Services (vt-mis.com);
  • jsunpack-n (jsunpack.jeek.org);
  • Sledujeme váš web (wewatchyourwebsite.com).

Veškerý kód je napsán v Pythonu a uživateli je nabídnut jak samotný modul pro použití při jejich vývoji, tak jednoduše spustitelný soubor pro použití YARA jako samostatné aplikace. V rámci své práce jsem zvolil první možnost, ale pro jednoduchost v tomto článku použijeme analyzátor jednoduše jako konzolovou aplikaci.

Po nějakém kopání jsem rychle přišel na to, jak napsat pravidla pro YARA a také jak k němu připojit virové signatury z freewaru a packery z PEiD. Začneme ale instalací.

Instalace

Jak jsem již řekl, projekt je napsán v Pythonu, takže jej lze snadno nainstalovat na Linux, Windows a Mac. Zpočátku si můžete vzít jen binární. Pokud aplikaci zavoláme v konzoli, získáme pravidla pro spuštění.

$yara
použití: yara ... ... SOUBOR | PID

To znamená, že formát pro volání programu je následující: nejprve je název programu, poté seznam možností, po kterém je uveden soubor s pravidly, a na samém konci - název souboru, který je prozkoumaný (nebo adresář obsahující soubory) nebo identifikátor procesu. Nyní bych rád vysvětlil, jak jsou tato pravidla koncipována, ale nechci vás hned zatěžovat suchou teorií. Proto budeme dělat věci jinak a půjčíme si podpisy jiných lidí, aby YARA mohla splnit jeden z úkolů, který jsme si stanovili – plnohodnotnou detekci virů pomocí podpisů.

Váš vlastní antivirus

Nejdůležitější otázka: kde získat databázi signatur známých virů? Antivirové společnosti takové databáze mezi sebou aktivně sdílejí (některé velkoryse, jiné méně). Abych byl upřímný, zpočátku jsem vůbec pochyboval, že někde na internetu někdo takové věci otevřeně zveřejní. Ale jak se ukázalo, existují dobří lidé. Vhodná základna z populární antivirus ClamAV je k dispozici všem (clamav.net/lang/en). V sekci "Nejnovější stabilní vydání" najdete odkaz na nejnovější verzi antivirový produkt, stejně jako odkazy na stažení virových databází ClamAV. Nás budou zajímat především soubory main.cvd (db.local.clamav.net/main.cvd) a daily.cvd (db.local.clamav.net/daily.cvd).

První obsahuje hlavní databázi podpisů, druhá obsahuje aktuálně nejúplnější databázi s různými doplňky. Pro tento účel zcela postačí Daily.cvd, který obsahuje více než 100 000 zobrazení malwaru. Databáze ClamAV však není databáze YARA, takže ji musíme převést na požadovaný formát. Ale jak? Koneckonců, zatím nevíme nic ani o formátu ClamAV, ani o formátu Yara. Tento problém byl již před námi vyřešen přípravou malého skriptu, který převede virovou databázi ClamAV na sadu pravidel YARA. Skript se jmenuje clamav_to_yara.py a napsal ho Matthew Richard (bit.ly/ij5HVs). Stáhněte si skript a převeďte databáze:

$ python clamav_to_yara.py -f daily.cvd -o clamav.yara

Výsledkem je, že v souboru clamav.yara obdržíme databázi podpisů, která bude okamžitě připravena k použití. Pojďme si nyní kombinaci YARA a databáze ClamAV vyzkoušet v akci. Skenování složky pomocí podpisu se provádí jediným příkazem:

$ yara -r clamav.yara /pentest/msf3/data

Volba -r určuje, že kontrola by měla být provedena rekurzivně ve všech podsložkách aktuální složky. Pokud byla ve složce /pentest/msf3/data nějaká virová těla (alespoň ta, která jsou v databázi ClamAV), pak to YARA okamžitě oznámí. V principu se jedná o hotový skener podpisů. Pro větší pohodlí jsem napsal jednoduchý skript, který zkontroloval aktualizace databáze ClamAV, stáhl nové signatury a převedl je do formátu YARA. Ale to už jsou detaily. Jedna část úkolu je dokončena, nyní můžete začít sestavovat pravidla pro identifikaci packerů/kryptorů. Ale abych to udělal, musel jsem se s nimi trochu vypořádat.

Hrajte podle pravidel

Pravidlo je tedy hlavním mechanismem programu, který umožňuje přiřadit daný soubor do určité kategorie. Pravidla jsou popsána v samostatném souboru (nebo souborech) a vzhledem jsou velmi podobná konstrukci struct() z jazyka C/C++.

vládnout BadBoy
{
řetězce:
$a = "win.exe"
$b = "http://foo.com/badfi le1.exe"
$c = "http://bar.com/badfi le2.exe"
stav:
$a a ($b nebo $c)
}

V zásadě není na psaní pravidel nic složitého. V tomto článku jsem se dotkl pouze hlavních bodů a podrobnosti najdete v návodu. Prozatím deset nejdůležitějších bodů:

1. Každé pravidlo začíná klíčové slovo pravidlo následované identifikátorem pravidla. Identifikátory mohou mít stejná jména jako proměnné v C/C++, to znamená, že se mohou skládat z písmen a číslic a první znak nemůže být číslo. Maximální délka názvu identifikátoru je 128 znaků.

2. Pravidla se obvykle skládají ze dvou částí: části definice (řetězce) a části podmínky (podmínka). Sekce strings specifikuje data, na základě kterých sekce podmínky rozhodne, zda daný soubor splňuje určité podmínky.

3. Každý řádek v sekci strings má svůj vlastní identifikátor, který začíná znakem $ – obecně jako deklarace proměnné v PHP. YARA podporuje běžné řetězce uzavřené v uvozovkách ("") a hexadecimální řetězce uzavřené ve složených závorkách (()), stejně jako regulární výrazy:

$my_text_string = "text zde"
$my_hex_string = ( E2 34 A1 C8 23 FB )

4. Část podmínky obsahuje veškerou logiku pravidla. Tato sekce by měla obsahovat logický výraz, který určuje, kdy soubor nebo proces odpovídá pravidlu. Tato část obvykle odkazuje na dříve deklarované řádky. A s identifikátorem řetězce se zachází jako s booleovskou proměnnou, která vrací hodnotu true, pokud byl řetězec nalezen v paměti souboru nebo procesu, a v opačném případě vrací hodnotu false. Výše uvedené pravidlo určuje, že soubory a procesy obsahující řetězec win.exe a jednu ze dvou adres URL by měly být kategorizovány jako BadBoy (podle názvu pravidla).

5. Hexadecimální řetězce umožňují tři konstrukce, díky nimž jsou flexibilnější: zástupné znaky, skoky a alternativy. Substituce jsou místa v řetězci, která jsou neznámá a lze je nahradit libovolnou hodnotou. Jsou označeny symbolem „?“:

$hex_string = ( E2 34 ?? C8 A? FB )

Tento přístup je velmi vhodný při zadávání řetězců, jejichž délka je známá, ale obsah se může lišit. Pokud část řetězce může mít různé délky, je vhodné použít rozsahy:

$hex_string = ( F4 23 62 B4 )

Tento záznam znamená, že uprostřed řádku může být 4 až 6 různých bajtů. Můžete také implementovat alternativní volbu:

$hex_string = ( F4 23 (62 B4 | 56) 45 )

To znamená, že místo třetího bajtu může být 62 B4 nebo 56, takový záznam odpovídá řádkům F42362B445 nebo F4235645.

6. Chcete-li zkontrolovat, zda je daný řetězec na určitém offsetu v adresovém prostoru souboru nebo procesu, používá se operátor at:

$a při 100 a $b při 200

Pokud může být řetězec v určitém rozsahu adres, použije se operátor in:

$a in (0..100) a $b in (100..fi velikost)

Někdy nastanou situace, kdy potřebujete určit, že soubor má obsahovat určité číslo z dané sady. To se provádí pomocí operátoru of:

pravidlo Příklad1
{
řetězce:
$foo1 = "figurína1"
$foo2 = "figurína2"
$foo3 = "figurína3"
stav:
2 z ($foo1,$foo2,$foo3)
}

Výše uvedené pravidlo vyžaduje, aby soubor obsahoval libovolné dva řádky ze sady ($foo1,$foo2,$foo3). Místo zadání konkrétního počtu řádků v souboru můžete použít proměnné any (alespoň jeden řádek z dané množiny) a všechny (všechny řádky z dané množiny).

7. Poslední zajímavou možností, kterou je třeba zvážit, je použití jedné podmínky na mnoho řádků. Tato funkce je velmi podobná funkci operátora, pouze výkonnější je operátor for..of:

pro výraz string_set: (booleovský_výraz)

Tento záznam by se měl číst takto: z řetězců uvedených v sadě string_set musí alespoň části výrazu splňovat podmínku boolean_expression. Nebo jinými slovy: booleovský_výraz se vyhodnotí pro každý řetězec v sadě stringů a výrazy z nich musí vrátit hodnotu True. Dále se na tuto konstrukci podíváme na konkrétním příkladu.

Vytváření PEiD

Takže, když je vše víceméně jasné s pravidly, můžeme začít implementovat detektor packerů a kryptorů do našeho projektu. Nejprve jsem si jako zdrojový materiál vypůjčil podpisy známých baličů ze stejného PEiD. Ve složce plugins je soubor userdb.txt, který obsahuje to, co potřebujeme. V mé databázi bylo 1850 podpisů.

Docela hodně, takže abyste je mohli plně importovat, doporučuji vám napsat nějaký skript. Formát této databáze je jednoduchý - používá se obvyklý textový soubor, který ukládá záznamy jako:


podpis = 50 E8 ?? ?? ?? ?? 58 25 ?? F0 FF FF 8B C8 83 C1 60 51 83 C0 40 83 EA 06 52 FF 20 9D C3
ep_only = true

První řádek specifikuje jméno packeru, které se bude zobrazovat v PEiD, ale pro nás to bude identifikátor pravidla. Druhým je samotný podpis. Třetím je příznak ep_only, který označuje, zda se má daný řádek hledat pouze na adrese vstupního bodu, nebo v celém souboru.

No, zkusíme vytvořit pravidlo, řekněme, pro ASPack? Jak se ukazuje, na tom není nic složitého. Nejprve si vytvořte soubor pro uložení pravidel a nazvěme jej například packers.yara. Poté v databázi PEiD vyhledáme všechny podpisy, které obsahují ASPack ve svých názvech, a přeneseme je do pravidla:

pravidlo ASPack
{
řetězce:
$ = ( 60 E8 ??? ??? ??? 5D 81 ED ??? (43 | 44) ?? B8 ???
$ = ( 60 EB ?? 5D EB ?? FF ??? ???? ???? E9 )
[.. řez..]
$ = ( 60 E8 03 00 00 00 E9 EB 04 5D 45 55 C3 E8 01 )
stav:
pro kteroukoli z nich: ($at entrypoint)
}

Všechny nalezené záznamy mají příznak ep_only nastavený na true, to znamená, že tyto řádky musí být umístěny na adrese vstupního bodu. Proto napíšeme následující podmínku: “pro kteroukoli z nich: ($at entrypoint)”.

Tedy přítomnost alespoň jednoho z dané struny na adrese vstupního bodu bude znamenat, že soubor je zabalen s ASPack. Upozorňujeme také, že v toto pravidlo všechny řetězce jsou specifikovány jednoduše pomocí znaku $, bez identifikátoru. Je to možné, protože v sekci podmínky nepřistupujeme k žádné konkrétní, ale používáme celou sadu.

Chcete-li zkontrolovat funkčnost výsledného systému, stačí spustit příkaz v konzole:

$ yara -r packers.yara somefi le.exe

Když jsem tam nakrmil několik aplikací zabalených s ASPack, byl jsem přesvědčen, že vše funguje!

Hotový prototyp

YARA se ukázala jako extrémně jasný a transparentní nástroj. Nebylo pro mě těžké napsat pro to webadmina a nastavit to tak, aby fungovalo jako webová služba. S trochou kreativity jsou suché výsledky analyzátoru již obarveny různými barvami, což naznačuje stupeň nebezpečnosti detekovaného malwaru. K dispozici je malá aktualizace databáze a pro mnoho kryptorů krátký popis a někdy i pokyny k rozbalení. Prototyp byl vytvořen a funguje perfektně a šéfové tančí radostí!