itthon › Tanácsot › Egyéni ismert fájltípus létrehozása az R-Studio számára. Fájl típusának meghatározása aláírással Mi az a fájl aláírás

Egyéni ismert fájltípus létrehozása az R-Studio számára. Fájl típusának meghatározása aláírással Mi az a fájl aláírás

A " fogalma varázslatos szám A programozásban három jelentése van:

Adataláírás
Megkülönböztetett egyedi értékek, amelyek nem lehetnek azonosak más értékekkel (például UUID)
Rossz programozási gyakorlat.

Adataláírás

varázslatos szám, vagy aláírás, egy egész szám vagy szövegkonstans, amely egy erőforrás vagy adat egyedi azonosítására szolgál. Egy ilyen szám önmagában nem hordoz semmilyen jelentést, és zavart okozhat, ha a megfelelő kontextus vagy megjegyzés nélkül fordul elő a programkódban, míg egy másik, akár közeli értékre történő megváltoztatási kísérlet abszolút beláthatatlan következményekkel járhat. Emiatt az ilyen számokat ironikusan mágikus számoknak nevezték. Jelenleg ez a név szilárdan beépült kifejezés. Például bármely lefordított Java nyelvosztály a 0xCAFEBABE hexadecimális "varázsszámmal" kezdődik. A második széles körben ismert példa bármelyik futtatható fájl OS Microsoft Windows az .exe kiterjesztéssel a 0x4D5A bájtszekvenciával kezdődik (amely az MZ ASCII karaktereknek felel meg - Mark Zbikowski, az MS-DOS egyik alkotójának kezdőbetűi). Egy kevésbé ismert példa a Microsoft Visual C++ (a Microsoft Visual Studio 2005-ös verziója óta) inicializálatlan mutatója, amely hibakeresési módban 0xDEADBEEF.

UNIX-szerűen operációs rendszer a fájl típusát általában a fájl aláírása határozza meg, függetlenül a fájl nevének kiterjesztésétől. Szabványos fájlsegédprogramot biztosítanak a fájl aláírásának értelmezéséhez.

Rossz programozási gyakorlat

Ezenkívül a „varázsszámok” rossz programozási gyakorlat, amikor a forrásszövegben numerikus érték szerepel, és nem egyértelmű, hogy ez mit jelent. Például egy ilyen Java nyelven írt részlet rossz lenne:

drawSprite(53, 320, 240);

végső int SCREEN_WIDTH = 640 ; végső int SCREEN_HEIGHT = 480 ; final int SCREEN_X_CENTER = SCREEN_WIDTH / 2 ; final int SCREEN_Y_CENTER = SCREEN_HEIGHT / 2 ; végső int SPRITE_CROSSHAIR = 53 ; ... drawSprite(SPRITE_CROSSHAIR , SCREEN_X_CENTER , SCREEN_Y_CENTER );

Most már világos: ez a vonal egy sprite-ot jelenít meg a képernyő közepén – a látvány szálkeresztjét. A legtöbb programozási nyelvben az ilyen állandókhoz használt összes értéket a fordításkor kiszámítják, és behelyettesítik azokra a helyekre, ahol az értékeket használják. Ezért a forrásszöveg ilyen változtatása nem rontja a program teljesítményét.

Ezenkívül a mágikus számok potenciális hibaforrások a programban:

Ha ugyanazt a bűvös számot egynél többször használjuk egy programban (vagy potenciálisan használható), akkor a megváltoztatásához minden egyes előfordulást szerkeszteni kell (a megnevezett állandó értékének szerkesztése helyett). Ha nem minden előfordulást javítanak ki, legalább egy hiba lép fel.
Legalább egy esetben előfordulhat, hogy a mágikus szám eleinte rosszul van írva, és ezt meglehetősen nehéz észlelni.
A mágikus szám függhet egy implicit paramétertől vagy egy másik varázsszámtól. Ha ezek a függőségek, amelyeket kifejezetten nem azonosítottak, nem teljesülnek, legalább egy hiba lép fel.
Egy mágikus szám előfordulásának módosításakor lehetséges egy másik, független, de azonos numerikus értékű varázsszám hibás megváltoztatása.

Mágikus számok és platformok közötti

Néha a mágikus számok bántják a többplatformos kódot. A helyzet az, hogy C-ben 32 bites és 64 bites operációs rendszerekben a char , short és long long típusok mérete garantált, míg az int , long , size_t és ptrdiff_t mérete változhat (az első kettőnél - a fordító fejlesztőinek preferenciáitól függően, az utolsó kettőnél - a célrendszer bitességétől függően). A régi vagy rosszul megírt kódban előfordulhatnak "bűvös számok", amelyek egy típus méretét jelzik – ha más bitességű gépekre költözünk, ezek finom hibákhoz vezethetnek.

Például:

const size_t ELEMEK SZÁMA = 10 ; hosszú a [ NUMBER_OF_ELEMENTS ]; memset(a , 0 , 10 * 4 ); // rossz - a long 4 bájtot feltételez, varázslatos számú elemet használunk memset(a , 0 , ELEMEK SZÁMA * 4 ); // rossz - a long 4 bájtot feltételez memset(a , 0 , NUMBER_OF_ELEMENTS * sizeof (hosszú )); // nem teljesen helyes - a típusnév megkettőzése (ha a típus megváltozik, itt is módosítani kell) memset (a , 0 , NUMBER_OF_ELEMENTS * sizeof (a [ 0 ])); // helyes, optimális a nullától eltérő méretű dinamikus tömbökhöz memset(a , 0 , sizeof(a )); // helyes, statikus tömbökhöz optimális

Számok, amelyek nem varázslatosak

Nem kell minden számot konstanssá konvertálni. Például a kódot

Az R-Studio adat-helyreállító segédprogramjának egyik leghatékonyabb módja az ismert típusú fájlok keresésének szkennelése (vagy ahogy szokták mondani, a fájlok aláírása alapján történő keresése). Egy adott aláírás használata lehetővé teszi bizonyos típusú fájlok visszaállítását abban az esetben, ha a könyvtárszerkezetre és a fájlnevekre vonatkozó információk részben vagy teljesen hiányoznak (sérültek).

Általában a lemezpartíciós táblát használják a fájlok helyének meghatározására. Ha összehasonlítunk egy lemezt egy könyvvel, akkor a partíciós tábla hasonló lesz a tartalomjegyzékéhez. Vizsgálatkor az R-Studio ismert típusú fájlokat keres a lemezpartíciós táblában bizonyos előre meghatározott aláírások alapján. Ez azért lehetséges, mert gyakorlatilag minden fájltípus egyedi aláírással vagy adatmintával rendelkezik. A fájlaláírások egy adott helyen a fájl elején találhatók, és sok esetben a fájl végén is. Szkenneléskor az R-Studio a talált adatokat az ismert típusú fájlok aláírásaival párosítja, ami lehetővé teszi azok azonosítását és adataik visszaállítását.

Az ismert típusú fájlok szkennelésének technológiájával az R-Studio lehetővé teszi az újraformázott lemezek adatainak helyreállítását, valamint a partíciós táblák felülírását. Ezenkívül, ha egy lemezpartíciót felülírnak, megsérülnek vagy törölnek, akkor az ismert fájltípusok vizsgálata az egyetlen lehetséges lehetőség.

De szinte mindennek és mindennek megvannak a maga hátrányai, és ez alól az R-Studioban használt ismert típusú fájlok sem kivételek. Tehát az ismert típusú fájlok vizsgálatakor az R-Studio csak a töredezett fájlok visszaállítását teszi lehetővé, de amint már említettük, a legtöbb esetben ez az utolsó lehetséges módszer.

Az R-Studio már tartalmaz aláírásokat a leggyakoribb fájltípusokhoz (nézet teljes lista ismert fájltípusokat, lásd az R-Studio online súgóját.)

Ha szükséges, a felhasználó új típusú fájlokat adhat hozzá az R-Studióhoz. Például, ha egyedi típusú fájlokat kell találnia, vagy azokat, amelyeket az R-Studio utolsó kiadása után fejlesztettek ki, saját aláírásokat adhat hozzá az ismert típusú fájlokhoz. Erről a folyamatról a következőkben lesz szó.

Ismert típusú felhasználói fájlok
Az ismert típusú fájlok felhasználói aláírásai a következő helyen vannak tárolva XML fájl e megadva a Beállítások párbeszédpanelen. Az aláírás hozzáadása két részből áll:

A fájl elején és ha van, akkor a fájl végén található fájlaláírás meghatározása.
A fájl aláírását és a fájltípusra vonatkozó egyéb információkat tartalmazó XML-fájl létrehozása.

Mindez megtehető az R-Studióval. Ugyanakkor nem kell szakértőnek lennie az XML dokumentumok összeállításának (szerkesztésének) vagy a hexadecimális szerkesztésnek - ebben a kézikönyvben (cikkben), amely a felhasználónak szól. belépő szint, ennek a folyamatnak minden szakaszát részletesen megvizsgáljuk.

Példa: Aláírás hozzáadása MP4 fájlhoz (XDCam-EX Codec)
Fontolja meg a fájl aláírásának hozzáadását a Sony XDCAM-EX használatával létrehozott .MP4 fájl példájával. Használható például az SD-kártya olyan sérülése esetén, amelyre még nem sikerült menteni a számítógép merevlemezére.

Első lépés: A fájl aláírásának meghatározása
A fájl aláírásának meghatározásához vegyen példákat az azonos formátumú fájlokra.

Legyen ez négy videofájl a Sony XDCAM-EX-től:
ZRV-3364_01.MP4
ZRV-3365_01.MP4
ZRV-3366_01.MP4
ZRV-3367_01.MP4

A könnyebb átgondolás kedvéért legyen ezek kis fájlok. A nagyobb fájlokat nehezebb hexadecimálisan megjeleníteni.

1. Nyissa meg a fájlokat az R-Studioban. Ehhez kattintson a jobb gombbal az egyes fájlokra, és válassza a Nézet/Szerkesztés parancsot a helyi menüből.

2. Hasonlítsa össze a fájlokat. Mind a négy fájlban ugyanazt a mintát fogjuk keresni. Ő lesz fájl aláírása. A fájl aláírások általában a fájl elején, de néha a végén találhatók.

3. Határozza meg a fájl aláírását a fájl elején. Példánkban a fájl legelején található. Vegye figyelembe, hogy ez nem mindig van így – gyakran a fájl aláírása a fájl elején található, de nem az első sorban (eltolás).

Az alábbi képekből az következik, hogy mind a négy fájl tartalma eltérő, de mindegyik ugyanazzal a fájl aláírással kezdődik.

Kattintson a képre a nagyításhoz

Kattintson a képre a nagyításhoz

A képeken a kiválasztott terület egy fájl aláírás ebből a típusból fájlokat. Szövegben és hexadecimális formában is megjelenik.

Szöveges formában a fájl aláírásának formája a következő:
....ftypmp42....mp42.......ingyenes

A pontok (.) olyan karaktereket jelölnek, amelyek nem ábrázolhatók szövegként. Ezért a fájl aláírásának hexadecimális alakját is meg kell adni:
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. Ugyanígy definiáljuk a fájl aláírását, de a fájl legvégén. Lehet, hogy más a fájl aláírása, eltérő hosszúságú.

Az alábbi képek kiemelik a fájl végén található aláírást:

Kattintson a képre a nagyításhoz

Kattintson a képre a nagyításhoz

Vegye figyelembe, hogy a kijelölés előtti adatok (fájl aláírása) mind a négy fájlban azonosak. Ez technikai információ, amely nem egy fájl aláírása, hanem azt jelzi, hogy mind a négy kép (fájl) ugyanazzal a kamerával készült, azonos paraméterekkel. Általában meg lehet különböztetni a megfelelő mintákat a műszaki információkkal a fájl aláírásából. Példánkban a fájlaláírás kezdete előtti utolsó sorban a ‘RecordingMode type=”normal”’ szöveget látjuk, ami egyértelműen jelzi, hogy ez valamiféle fájlparaméter, nem pedig aláírás. Mindig nagyon figyeljen erre a sorra, hogy ne tévedjen bele technikai információ a fájl aláírásában.

Esetünkben a fájl aláírása a következő szöveg:
...
Emlékezzünk vissza, hogy a pontok olyan karaktereket jelölnek, amelyek nem ábrázolhatók szöveges formában.

Hexadecimális formában a fájl aláírása a következő:
3N 2F 4E 6F 6E 52 65 61 6N 54 69 6A 65 4A 65 74 61 3E 0D 0A 00
Kérjük, vegye figyelembe: az aláírás nem mindig a fájl végén lesz.

Második lépés: Hozzon létre egy XML-fájlt, amely leírja az ismert fájltípust
Most, miután meghatározta a fájl aláírását, létrehozhat egy XML-fájlt, és belefoglalhatja a megfelelő fájltípust az R-Studioba. Ezt kétféleképpen lehet megtenni:

2.1 A beépített használata grafikus szerkesztő fájl aláírások:
Válassza az Eszközök menü Beállítások menüpontját, a megnyíló Beállítások párbeszédpanelen kattintson az Ismert fájltípusok fülre, majd kattintson a Felhasználói fájltípusok szerkesztése gombra.

Kattintson a képre a nagyításhoz

Kattintson a Fájltípus létrehozása gombra a Felhasználói fájltípusok szerkesztése párbeszédpanelen.
Állítsa be a következő beállításokat:

Id – egyedi digitális azonosító. Adott számönkényesen választják ki; az egyetlen dolog, hogy nem egyezhet más fájltípus numerikus azonosítójával.
Csoportleírás – az a csoport, amelyben a talált fájlok az R-Studio-ban lesznek. Bármelyiket beállíthatja új csoport, vagy válasszon egyet a már létezők közül. Számunkra ez a „Multimédiás Videó (Multimédia: Videó)” csoport lesz.
Leírás- Rövid leírás fájltípus. Példánkban használhatja például a „Sony cam video, XDCam-EX” kifejezést.
Extension - ilyen típusú fájlkiterjesztés. A mi esetünkben - mp4.

A Features paraméter nem kötelező, esetünkben nem kell használnunk.

Kattintson a képre a nagyításhoz

Ezután meg kell adnia a kezdeti és a végső fájl aláírását. Ehhez válassza a Begin (Kezdés) lehetőséget, majd a be helyi menü az Aláírás hozzáadása parancsot.

Kattintson a képre a nagyításhoz

Ezután kattintson duplán a mezőre<пустая сигнатура> (), és írja be a megfelelő szöveget.

Kattintson a képre a nagyításhoz

Ezután hozza létre a végleges fájl aláírást. Ne felejtse el beírni a 21-et a Feladó oszlopba.

Kattintson a képre a nagyításhoz

Sikeresen létrehozta saját, ismert típusú fájlaláírását.

Most meg kell mentenünk. Két módja van: vagy a Beállítások párbeszédpanel Fő lapján megadott alapértelmezett fájlba mentheti a Mentés gombra kattintva. Vagy kattintson a Mentés másként... gombra, és mentse az aláírást egy másik fájlba.

2.2 Ismert fájltípust leíró XML-fájl kézi létrehozása:
Az alkotáshoz adott fájl Használjunk XML 1.0-s verziót és UTF-8 kódolást. Ne essen kétségbe, ha nem tudja, mi az – egyszerűen nyissa ki bármelyiket szöveg szerkesztő(például Notepad.exe), és az első sorba írja be a következő szöveget:

Ezután létrehozunk egy XML címkét, amely meghatározza a fájl típusát (FileType). A korábban leírt attribútumok ismeretében az XML címke így néz ki:

Helyezze be közvetlenül utána

Ezután meghatározzuk a fájl aláírását (tag ). A kezdeti aláírás (a fájl elején) a címkén belül lesz attribútumok nélkül. Az aláírás szöveges formáját használjuk, de egyúttal hexadecimális karakterekkel helyettesítjük, amelyek nem ábrázolhatók szöveges formában. Minden hexadecimális karakter elé illessze be a "\x"-et. Így a címke fájlaláírással így nézne ki:

Ha van, meg kell határoznia a végső aláírást is (a fájl végén). Ehhez ugyanazt a címkét használják, de a "from" elemmel és az "end" attribútummal. Így fog kinézni:

Emlékezzünk vissza, hogy a végső fájlaláírásban nem voltak nem szöveges karakterek, de voltak perjelek és háromszög zárójelek. A félreértések és az XML-szintaxis hibáinak elkerülése érdekében a "/", "" karaktereket lecseréljük.<" и ">" hexadecimális értékeivel.

A végén, a fájl aláírása után, ott kell lennie a záró FileType és FileTypeList címkéknek:

Tehát az egész fájlnak így kell kinéznie:

\x00\x00\x00\x18ftypmp42\x00\x00\x00\x00mp42\x00\x00\x00\x00\x00\x00\x00\x08free
\x3C\x2FNonRealTimeMeta\x3E\x0D\x0A\x00

Ne feledje: az XML szintaxis megkülönbözteti a kis- és nagybetűket, tehát a megfelelő címke az , de nem .

Mentsük el a fájlt szöveges formátumban .xml kiterjesztéssel. Például: SonyCam.xml.

Sikeresen létrehoztuk egy ismert típusú fájl aláírásunkat. Ez a példa elegendő az egyéni fájltípus létrehozásának alapelveinek megértéséhez. A haladóbb felhasználók használhatják az XML 2.0-s verzióját. Erről bővebben az R-Studio online súgójában olvashat.

3. szakasz: Ismert fájltípust leíró fájl ellenőrzése és hozzáadása
A következő lépés az XML-fájl hozzáadása (feltöltése) az R-Studióhoz. Ezután automatikusan ellenőrzi.

Töltsük be az előző szakaszban létrehozott XML fájlt az R-Studióba. Ehhez válassza a Beállítások menüpontot az Eszközök menüből. A Beállítások párbeszédpanel Fő lapjának Felhasználói fájltípusok területén adja hozzá az általunk létrehozott XML-fájlt (SonyCam.xml). Kattintson az Alkalmaz gombra.

Kattintson a képre a nagyításhoz

2. Válaszoljon Igen (Igen) az új fájltípus feltöltésére vonatkozó kérelemre.

Kattintson a képre a nagyításhoz

3. A fájltípus sikeres betöltésének ellenőrzéséhez kattintson a Beállítások párbeszédpanel Ismert fájltípusok fülére. Emlékezzünk vissza, hogy hozzáadtuk a fájltípust a Multimédia videó csoporthoz (Multimédia: Videó). Ezt a csoportot (mappát) kibontva egy olyan elemet kell látnunk, amilyen leírást adtunk meg az XML fájl létrehozásakor: Sony cam video, XDCam-EX (.mp4).

Kattintson a képre a nagyításhoz

Kattintson a képre a nagyításhoz

Ha bármilyen hiba van a fájl szintaxisában, a megfelelő üzenetet fogja látni:

Kattintson a képre a nagyításhoz

Ebben az esetben ellenőrizze újra az XML-fájlt hibákért. Ne feledje, hogy az XML szintaxis megkülönbözteti a kis- és nagybetűket, és minden címke végén egy záró címkével kell rendelkeznie.

4. szakasz: Az ismert fájltípust leíró fájl tesztelése
Annak ellenőrzésére, hogy az általunk létrehozott egyéni fájltípus helyes-e, próbáljuk meg megkeresni az .mp4 fájljainkat egy cserélhető USB flash meghajtón.

1. Windows Vista vagy Windows 7 esetén hajtsa végre a lemez teljes (nem gyors) formázását, vagy használjon lemezterület-tisztító segédprogramot (például R-Wipe & Clean) teljes eltávolítása a lemezen lévő összes adatot. Hadd USB lemez FAT32-ben formázott (a szükséges fájlok mérete nem haladja meg a 2 GB-ot).

2. Visszamásolás tesztfájlokat lemezre, és indítsa újra a számítógépet, hogy a cache memória tartalma lemezre kerüljön. Ki is kapcsolhatja külső meghajtó majd csatlakoztassa újra.

3. Az operációs rendszerben a meghajtó például F:\ logikai meghajtóként lesz meghatározva.

4. Futtassa az R-Studio alkalmazást. Válassza ki a meghajtónkat (F:\), és kattintson a Beolvasás gombra

Kattintson a képre a nagyításhoz

5. A Beolvasás párbeszédpanel Fájlrendszer területén kattintson a Módosítás... gombra, és törölje az összes jelölőnégyzetet. Így letiltjuk a fájlrendszerek és fájlok keresését a partíciós tábla segítségével.
Kattintson a képre a nagyításhoz

6. Jelölje be az Ismert fájltípusok extra keresése jelölőnégyzetet. Ez lehetővé teszi az R-Studio számára az ismert fájltípusok keresését.

7. A szkennelés elindításához kattintson a Beolvasás gombra.

8. Várjon, amíg az R-Studio beolvassa a lemezt. A Szkennelési információk lapon a szkennelés folyamata látható.

Kattintson a képre a nagyításhoz

9. A szkennelés befejezése után válassza ki az Extra Found Files elemet, és kattintson rá duplán.

Kattintson a képre a nagyításhoz

10. Tesztfájljaink a Sony cam video, XDCam-EX mappában (vagy egy másik, a Második lépésben megadott fájltípusleírásnak megfelelő nevű mappában) találhatók.

Kattintson a képre a nagyításhoz

Láthatja, hogy a fájlnevek, dátumok és helyek (mappák) nem lettek visszaállítva, mert ez az információ fájlrendszerben tárolva. Ezért az R-Studio minden fájlt automatikusan új névvel jelenít meg.

Látható azonban, hogy a fájlok tartalma nem sérült. Ennek ellenőrzéséhez nyissa meg őket a megfelelő programban, például VLC médialejátszóban.

Kattintson a képre a nagyításhoz

Következtetés
Az R-Studio azon képessége, hogy ismert típusú fájlokat keressen, lehetővé teszi az adatok helyreállítását még olyan lemezről is, amelynek fájlrendszere vagy felül van írva. Meglehetősen hatékonyan kereshet fájlokat aláírásaik alapján, ami különösen hasznos, ha pontosan ismeri a helyreállított fájlok típusát, mint például a példánkban. Az egyéni fájltípusok létrehozásának lehetősége lehetővé teszi, hogy bármilyen fájlt felvegyen az ismert fájltípusok listájára, amely egy adott fájlaláírással rendelkezik.

Sokan hallottak már olyan fájlokról, mint például a rarjpeg "és. Ez egy speciális fajta fájl, amely egy jpeg kép és egy rar archívum szorosan összeragasztva. Kiváló tároló az információátvitel tényének elrejtésére. A rarjpeg fájlt a következő parancsokkal hozhatja létre:

UNIX: macska kép1.jpg archívum.rar > kép2.jpg
ABLAKOK: másolja /b image1.jpg+archive.rar image2.jpg

Vagy ha van hexadecimális szerkesztőd.

Természetesen az információátadás tényének elrejtéséhez nemcsak a JPEG formátumot használhatja, hanem sok mást is. Minden formátumnak megvannak a maga sajátosságai, amelyek miatt lehet, hogy alkalmas vagy nem a konténer szerepkörre. Leírom, hogyan találhat ragasztott fájlokat a legnépszerűbb formátumokban, vagy rámutat a ragasztás tényére.

A ragasztott fájlok észlelésének módszerei három csoportra oszthatók:

Az EOF marker utáni terület ellenőrzésének módszere. Sok népszerű fájlformátum rendelkezik úgynevezett fájlvég-jelölővel, amely a kívánt adatok megjelenítéséért felelős. Például a fotónézegetők az összes bájtot elolvassák a jelölőig, de az utána lévő terület figyelmen kívül marad. Ez a módszer ideális a következő formátumokhoz: JPEG, PNG, GIF, ZIP, RAR, PDF.
A fájlméret ellenőrzésének módja. Egyes formátumok (audio- és videotárolók) szerkezete lehetővé teszi a tényleges fájlméret kiszámítását és az eredeti mérettel való összehasonlítását. Formátumok: AVI, WAV, MP4, MOV.
A CFB fájlok ellenőrzésének módja. A CFB vagy összetett fájl bináris formátum a Microsoft által kifejlesztett dokumentumformátum, amely egy tároló saját fájlrendszerrel. Ez a módszer a fájl anomáliáinak észlelésén alapul.

Van élet a fájl vége után?

JPEG

A kérdésre adott válasz megtalálásához el kell mélyedni a formátum specifikációiban, amely a ragasztott fájlok "őse", és meg kell érteni a szerkezetét. Bármely JPEG 0xFF 0xD8 aláírással kezdődik.

Ezt az aláírást követően szolgáltatási információk, opcionálisan képikon és végül maga a tömörített kép található. Ebben a formátumban a kép vége kétbájtos aláírással van jelölve: 0xFF 0xD9.

PNG

A PNG-fájl első nyolc bájtját a következő aláírás foglalja el: 0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A. Az adatfolyamot lezáró aláírás: 0x49, 0x45, 0x4E, 0x44, 0xAE, 0x42, 0x60, 0x82.

RAR

Közös aláírás minden rar archívumhoz: 0x52 0x61 0x72 0x21 (Rar!). Utána jön az archívum verziójával kapcsolatos információk és egyéb kapcsolódó adatok. Empirikusan azt találtuk, hogy az archívum a 0x0A, 0x25, 0x25, 0x45, 0x4F, 0x46 aláírással végződik.

A formátumok és aláírásaik táblázata:
Az ilyen formátumok ragasztásának ellenőrzésére szolgáló algoritmus rendkívül egyszerű:

Keresse meg a kezdeti aláírást;
Keresse meg a végső aláírást;
Ha a végső aláírás után nincs adat - a fájl tiszta és nem tartalmaz mellékleteket! Ellenkező esetben a végső aláírás után más formátumokat kell keresni.

GIF és PDF

Egy PDF-dokumentum egynél több EOF-jelölőt tartalmazhat, például a nem megfelelő dokumentumgenerálás miatt. A GIF-fájlban lévő végaláírások száma megegyezik a benne lévő képkockák számával. Ezen formátumok jellemzői alapján lehetőség van a csatolt fájlok ellenőrzésének algoritmusának javítására.

Az 1. tétel megismétlődik az előző algoritmusból.
A 2. tétel megismétlődik az előző algoritmusból.
Amikor megtalálja a végső aláírást, emlékezzen a helyére, és keressen tovább;
Ha így éri el az utolsó EOF markert, akkor a fájl tiszta.
Ha a fájl nem végződik a végaláírással, akkor a goto az utoljára talált végaláírás helye.

A fájl mérete és az utolsó aláírás utáni pozíció közötti nagy eltérés ragadós melléklet jelenlétét jelzi. A különbség több mint tíz bájt lehet, bár más értékek is beállíthatók.

postai irányítószám

A ZIP archívum egyik jellemzője három különböző aláírás jelenléte: Az archívum szerkezete a következő:

Helyi fájl fejléc 1

Fájladatok 1

1. adatleíró

Helyi fájl fejléc 2

Fájladatok 2

2. adatleíró

...

Helyi fájl fejléc n

Fájl adatok n

Adatleíró n

Archívum dekódolási fejléc

Extra adatrekord archiválása

Központi címtár

A legérdekesebb a központi könyvtár, amely metaadatokat tartalmaz az archívum fájljairól. A központi könyvtár mindig a 0x50 0x4b 0x01 0x02 aláírással kezdődik, és a 0x50 0x4b 0x05 0x06 aláírással végződik, amelyet 18 bájt metaadat követ. Érdekes módon az üres archívumok csak a végső aláírásból és 18 null bájtból állnak. 18 bájt után jön az archív megjegyzés terület, amely tökéletes tároló egy fájl elrejtéséhez.

A ZIP archívum ellenőrzéséhez meg kell találnia a központi könyvtár végső aláírását, ki kell hagynia 18 bájtot, és meg kell keresnie az ismert formátumú aláírásokat a megjegyzés területen. Nagy méretű A kommentár is a ragasztás tényéről tanúskodik.

A méret számít

AVI

Az AVI fájl szerkezete a következő: minden fájl RIFF aláírással kezdődik (0x52 0x49 0x46 0x46). A 8. bájton egy AVI-aláírás található, amely meghatározza a formátumot (0x41 0x56 0x49 0x20). A 4. eltolásnál lévő, 4 bájtból álló blokk tartalmazza az adatblokk kezdeti méretét (a bájtsorrend kicsi). A következő méretet tartalmazó blokk számának megállapításához hozzá kell adni a fejléc méretét (8 bájt) és a 4-8 bájtos blokkban kapott méretet. Ez kiszámítja a fájl teljes méretét. Lehetséges, hogy a számított méret kisebb, mint a tényleges fájlméret. A kiszámított méret után a fájl csak nulla bájtot tartalmaz (az 1Kb-os határ igazításához szükséges).

Méretszámítási példa:

WAV

Az AVI-hoz hasonlóan a WAV-fájlok is a RIFF aláírással kezdődnek, azonban ez a fájl 8 bájtos aláírással rendelkezik - WAVE (0x57 0x41 0x56 0x45). A fájl méretét az AVI-hoz hasonlóan számítják ki. A tényleges méretnek pontosan meg kell egyeznie a számított mérettel.

MP4

Az MP4 vagy MPEG-4 egy médiatároló formátum, amelyet video- és hangfolyamok tárolására használnak, valamint feliratok és képek tárolását is lehetővé teszik.
Az eltolásnál 4 bájt az aláírások: ftyp fájltípus (66 74 79 70) (QuickTime Container File Type) és mmp4 fájl altípus (6D 6D 70 34). Az elismerésért rejtett fájlok, a fájlméret kiszámításának lehetősége érdekel bennünket.

Vegyünk egy példát. Az első blokk mérete nulla eltolásnál van, és 28 (00 00 00 1C, Big Endian byte sorrend); jelzi azt az eltolást is, ahol a második adatblokk mérete található. A 28. eltolásnál a következő blokkméretet 8-al (00 00 00 08) találjuk. A következő blokkméret megtalálásához hozzá kell adnia a talált előző blokkok méreteit. Így a fájlméret kiszámítása:

MOV

Ez a széles körben használt formátum egyben MPEG-4 tároló is. A MOV szabadalmaztatott adattömörítési algoritmust használ, az MP4-hez hasonló felépítésű, és ugyanarra a célra szolgál - hang- és videoadatok, valamint kapcsolódó anyagok tárolására.
Az MP4-hez hasonlóan minden mov fájl 4 bájtos ftyp aláírással rendelkezik a 4 eltolásnál, azonban a következő aláírás értéke qt__ (71 74 20 20). A fájlméret kiszámításának szabálya nem változott: a fájl elejétől kezdve kiszámítjuk a következő blokk méretét, és összeadjuk.

Ennek a formátumcsoportnak a "csatolt" fájlok jelenlétének ellenőrzésének módszere a méret kiszámítása a fenti szabályok szerint, és összehasonlítása az ellenőrzött fájl méretével. Ha az aktuális fájlméret sokkal kisebb, mint a számított, akkor ez az összevonás tényét jelzi. Az AVI-fájlok ellenőrzésekor megengedett, hogy a számított méret kisebb legyen, mint a fájlméret a szegélyigazításhoz hozzáadott nullák jelenléte miatt. Ilyen esetben a számított fájlméret után nullákat kell ellenőrizni.

Ellenőrizze az összetett fájl bináris formátumát

Ez a Microsoft által kifejlesztett fájlformátum OLE (Object Linking and Embedding) vagy COM (Component Object Model) néven is ismert. A DOC, XLS, PPT fájlok a CFB formátumok csoportjába tartoznak.

A CFB fájl egy 512 bájtos fejlécből és azonos hosszúságú szektorokból áll, amelyek adatfolyamokat vagy szolgáltatási információkat tárolnak. Minden szektornak megvan a maga nemnegatív száma, a speciális számok kivételével: "-1" - a szabad szektort jelöli, "-2" - a láncot lezáró szektort. Minden szektorlánc definiálva van a FAT táblában.

Tegyük fel, hogy egy támadó módosított egy bizonyos doc fájlt, és egy másik fájlt illesztett be a végébe. Van néhány különböző módokonészleli, vagy mutasson rá egy anomáliára a dokumentumban.

Rendellenes fájlméret

Mint fentebb említettük, minden CFB fájl egy fejlécből és egyenlő hosszúságú szektorokból áll. A szektor méretének megtudásához be kell olvasni a két bájtos számot a fájl elejétől számított 30. eltolásnál, és emelni kell a 2-t ennek a számnak a hatványára. Ennek a számnak 9 (0x0009) vagy 12 (0x000C) kell lennie, a fájlszektor mérete 512 vagy 4096 bájt. A szektor megtalálása után ellenőriznie kell a következő egyenlőséget:

(FileSize - 512) mod SectorSize = 0

Ha ez az egyenlőség nem teljesül, akkor jelezheti a fájlok egyesítésének tényét. Ennek a módszernek azonban van egy jelentős hátránya. Ha a támadó ismeri a szektor méretét, akkor elég neki ragasztani a fájlját és még n bájtot, hogy az összeragasztott adatok mérete többszöröse legyen a szektor méretének.

Ismeretlen szektortípus

Ha a támadó tud olyan módszerről, amellyel megkerülheti az előző ellenőrzést, akkor ez a módszer képes érzékelni a nem definiált típusú szektorok jelenlétét.

Határozzuk meg az egyenlőséget:

FileSize = 512 + CountReal * SectorSize, ahol a FileSize a fájl mérete, a SectorSize a szektor mérete, a CountReal a szektorok száma.

A következő változókat is meghatározzuk:

CountFat - a FAT szektorok száma. A fájl eleje 44-es eltolásánál található (4 bájt);
CountMiniFAT - a MiniFAT szektorok száma. A fájl eleje 64-es eltolásánál található (4 bájt);
CountDIFAT – DIFAT szektorok száma. A fájl eleje 72-es eltolásánál található (4 bájt);
A CountDE a címtárbejegyzési szektorok száma. Ennek a változónak a megtalálásához meg kell találnia az első DE szektort, amely a 48. eltolásnál található. Ezután be kell szereznie a DE teljes reprezentációját a FAT-ból, és meg kell számolnia a DE szektorok számát;
CountStreams – adatfolyamokkal rendelkező szektorok száma;
CountFree - a szabad szektorok száma;
CountClassified - egy bizonyos típusú szektorok száma;

CountClassified = CountFAT + CountMiniFAT + CountDIFAT + CountDE + CountStreams + CountFree

Nyilvánvaló, hogy ha a CountClassified és a CountReal nem egyenlő, akkor arra a következtetésre juthatunk, hogy a fájlok összevonhatók.

A főnök meglehetősen érdekes feladatot állított elém. Rövid időn belül írjon egy futtatható fájlelemzőt, amely képes lesz megtalálni a vírustörzseket aláírások alapján, és meghatározni a használt csomagolót / titkosítót. A kész prototípus pár óra alatt megjelent.

A szerző szava

aláírás elemzése

A rosszindulatú objektumok aláírások alapján történő keresésére minden vírusirtó képes. Általános esetben az aláírás néhány jel formalizált leírása, amely alapján megállapítható, hogy a vizsgált fájl vírus, és a vírus meglehetősen specifikus.

Itt különféle módszerek léteznek. Alternatív megoldásként használjon egy rosszindulatú objektum N bájtjából álló aláírást. Ebben az esetben nem hülye összehasonlítást lehet végezni, hanem valamilyen maszkkal való összehasonlítást (például EB ?? ?? CD 13 bájtok keresése). Vagy állítson be további feltételeket, például "az ilyen bájtoknak a program belépési pontján kell lenniük" és így tovább. A Malvari aláírása különlegesség.

Ugyanígy leírunk néhány jelet, amelyek segítségével megállapítható, hogy a végrehajtható fájl egy vagy másik titkosítóval vagy csomagolóval van csomagolva (például a banális ASPack). Ha figyelmesen elolvasta magazinunkat, akkor biztosan hallott egy olyan eszközről, mint a PEiD, amely képes meghatározni a leggyakrabban használt csomagolókat, titkosítókat és fordítókat (nagyszámú aláírás található az adatbázisban) a hozzá továbbított PE-fájlhoz. Sajnos a program új verziói már régóta nem jelentek meg, és nemrégiben megjelent egy üzenet a hivatalos weboldalon, hogy a projekt nem fog tovább fejlődni. Kár, mert a PEiD szolgáltatásai (főleg a plugin rendszer miatt) nagyon hasznosak lehetnek számomra. Rövid elemzés után világossá vált, hogy erre nincs lehetőség. De miután kutakodtam az angol nyelvű blogok között, gyorsan megtaláltam a számomra megfelelőt. YARA projekt (code.google.com/p/yara-project).

Mi az a YARA?

Kezdettől fogva meg voltam győződve arról, hogy valahol a weben már léteznek olyan fejlesztések, amelyek azt a feladatot vállalnák, hogy meghatározzák az aláírás és a vizsgált fájl közötti megfelelést. Ha találnék egy ilyen projektet, akkor könnyen rákerülhetne egy webalkalmazás síneire, és ott különböző aláírásokat adhatnék hozzá, és megkaphatnám, amit tőlem kellett. A terv kezdett még valóságosabbnak tűnni, amikor elolvastam a YARA projekt leírását.

Maguk a fejlesztők olyan eszközként pozicionálják, amely segít a rosszindulatú programok kutatóinak azonosítani és osztályozni a rosszindulatú mintákat. A kutató leírásokat készíthet a különböző típusú rosszindulatú programok szöveges vagy bináris minták használatával, amelyek leírják a rosszindulatú programok formalizált jellemzőit. Így szerzik be az aláírásokat. Valójában minden leírás sorok halmazából és valamilyen logikai kifejezésből áll, amelyek alapján meghatározzák az analizátor működésének logikáját.

Ha valamelyik szabály feltételei teljesülnek a vizsgált aktánál, akkor ennek megfelelően kerül meghatározásra (például féreg ilyen és olyan). Egy egyszerű példa egy szabályra, hogy megértsük, mi a tét:

szabály silent_banker: bankár
{
meta:
description = "Ez csak egy példa"
szál_szint = 3
in_the_wild = igaz
húrok:
$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"
feltétel:
$a vagy $b vagy $c
}

Ebben a szabályban azt mondjuk a YARA-nak, hogy minden olyan fájlt, amely az $a, $b, $c változókban leírt minta karakterláncok közül legalább egyet tartalmaz, a silent_banker trójainak kell minősíteni. És ez egy nagyon egyszerű szabály. Valójában a kerekek sokkal bonyolultabbak lehetnek (erről az alábbiakban fogunk beszélni).
Még az ezt használó projektek listája is beszél a YARA projekt tekintélyéről, és ez:

VirusTotal Malware Intelligence Services (vt-mis.com);
jsunpack-n (jsunpack.jeek.org);
Figyeljük webhelyét (wewatchyourwebsite.com).

Az összes kód Pythonban van írva, és a felhasználó számára felajánlja magát a modult a fejlesztéseikhez, és csak egy végrehajtható fájlt a YARA önálló alkalmazásként való használatához. Munkám részeként az első lehetőséget választottam, de az egyszerűség kedvéért a cikkben az elemzőt egyszerűen konzolalkalmazásként fogjuk használni.

Némi ásás után gyorsan rájöttem, hogyan írjak szabályokat a YARA-hoz, valamint hogyan csatolhatok hozzá vírusszignatúrákat egy ingyenes aver-től és a PEiD-ből csomagolókat. De kezdjük a telepítéssel.

Telepítés

Mint mondtam, a projekt Python nyelven íródott, így könnyen telepíthető Linuxra, Windowsra és Macre. Először csak a binárist veheti át. Ha meghívjuk az alkalmazást a konzolban, akkor futni fogjuk a szabályokat.

$yara
használat: yara ... ... FÁJL | PID

Vagyis a programhívás formátuma a következő: először jön a program neve, majd a lehetőségek listája, amely után megjelenik a szabályokat tartalmazó fájl, a legvégén pedig a vizsgált fájl neve (vagy a fájlokat tartalmazó könyvtár), vagy a folyamatazonosító. Jó lenne most elmagyarázni, hogyan készülnek ezek a szabályok, de nem akarom azonnal száraz elmélettel terhelni. Ezért másként fogunk eljárni, és kölcsönkérjük mások aláírásait, hogy a YARA végrehajthassa az általunk meghatározott feladatok egyikét - a vírusok teljes körű azonosítását aláírások segítségével.

A vírusirtód

A legfontosabb kérdés: honnan szerezhető be az ismert vírusok aláírási adatbázisa? A vírusirtó cégek aktívan megosztják egymás között az ilyen adatbázisokat (van aki bőkezűbben, van aki kevésbé). Hogy őszinte legyek, eleinte még abban is kételkedtem, hogy valahol a weben valaki nyíltan posztol ilyesmit. De mint kiderült, vannak jó emberek. A népszerű ClamAV vírusirtó megfelelő alapja mindenki számára elérhető (clamav.net/lang/en). A „Legfrissebb stabil kiadás” részben talál egy hivatkozást legújabb verzió víruskereső termék, valamint a ClamAV vírusadatbázisok letöltésére szolgáló hivatkozások. Elsősorban a main.cvd (db.local.clamav.net/main.cvd) és a daily.cvd (db.local.clamav.net/daily.cvd) fájlokra leszünk kíváncsiak.

Az első tartalmazza az aláírások fő adatbázisát, a második - a legteljesebb Ebben a pillanatban alap különféle kiegészítésekkel. Erre a célra elég a daily.cvd, amely több mint 100 000 malware castot tartalmaz. A ClamAV alap azonban nem YARA alap, ezért át kell alakítanunk a megfelelő formátumra. De hogyan? Végül is még mindig nem tudunk semmit sem a ClamAV formátumról, sem a Yara formátumról. Ezt a problémát már megoldottuk előttünk egy kis szkript elkészítésével, amely a ClamAV vírusaláírási adatbázisát YARA szabálykészletté alakítja. A szkript neve clamav_to_yara.py, és Matthew Richard írta (bit.ly/ij5HVs). Töltse le a szkriptet és konvertálja az adatbázisokat:

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

Ennek eredményeként egy aláírási alapot kapunk a clamav.yara fájlban, amely azonnal használatra kész lesz. Most próbáljuk ki a YARA és a ClamAV bázis kombinációját működés közben. Egy mappa aláírással történő vizsgálata egyetlen paranccsal történik:

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

Az -r kapcsoló megadja, hogy a vizsgálatot rekurzívan kell végrehajtani az aktuális mappa összes almappáján keresztül. Ha volt vírustörzs a /pentest/msf3/data mappában (legalábbis a ClamAV adatbázisban lévők), akkor a YARA azonnal jelenteni fogja ezt. Elvileg ez egy kész aláírás-szkenner. A nagyobb kényelem kedvéért írtam egy egyszerű szkriptet, amely ellenőrizte a ClamAV adatbázis-frissítéseket, új aláírásokat töltött fel és konvertálta azokat YARA formátumba. De ezek csak részletek. A feladat egy része elkészült, most elkezdhetjük szabályokat írni a csomagolók/kriptorok meghatározásához. De ehhez egy kicsit foglalkozni kellett velük.

Játék a szabályok szerint

Tehát a szabály a program fő mechanizmusa, amely lehetővé teszi, hogy egy adott fájlt bármely kategóriához rendeljen. A szabályok egy külön fájlban (vagy fájlokban) vannak leírva, és megjelenésükben nagyon hasonlítanak a C/C++ nyelv struct() konstrukciójához.

szabály Rosszfiú
{
húrok:
$a = "win.exe"
$b = "http://foo.com/badfile1.exe"
$c = "http://bar.com/badfile2.exe"
feltétel:
$a és ($b vagy $c)
}

A szabályok megírásában elvileg nincs semmi bonyolult. A cikk keretein belül csak a főbb pontokat érintettem, a részleteket a kézikönyvben találja meg. Egyelőre a tíz legfontosabb pont a következő:

1. Minden szabály a szabály kulcsszóval kezdődik, amelyet a szabály azonosítója követ. Az azonosítók neve megegyezhet a C/C++ változóival, azaz állhat betűkből és számjegyekből, és az első karakter nem lehet számjegy. Maximális hossz azonosító név - 128 karakter.

2. A szabályok jellemzően két részből állnak: egy definíciós szakaszból (karakterláncok) és egy feltétel szakaszból. A karakterláncok szekció olyan adatokat tartalmaz, amelyek alapján a feltétel rovatban döntés születik arról, hogy a megadott fájl megfelel-e bizonyos feltételeknek.

3. A karakterláncok szakaszban minden sornak megvan a maga azonosítója, amely egy $ jellel kezdődik – általában, mint a php változódeklarációja. A YARA támogatja a bezárt normál karakterláncokat dupla idézőjelek(" ") és hexadecimális karakterláncok közé zárva kapcsos zárójel(()), valamint reguláris kifejezések:

$my_text_string = "szöveg itt"
$my_hex_string = ( E2 34 A1 C8 23 FB )

4. A feltétel szakasz tartalmazza a szabály összes logikáját. Ennek a szakasznak tartalmaznia kell egy logikai kifejezést, amely meghatározza, hogy a fájl vagy folyamat mikor felel meg a szabálynak. Ez a szakasz általában a korábban deklarált karakterláncokra vonatkozik. A sorazonosítót pedig logikai változóként kezeli, amely true értéket ad vissza, ha a sort megtalálta a fájlban vagy a folyamatmemóriában, és hamis értéket ad vissza. A fenti szabály előírja, hogy a win.exe karakterláncot és a két URL egyikét tartalmazó fájlokat és folyamatokat BadBoy kategóriába kell sorolni (a szabály neve alapján).

5. A hexadecimális karakterláncok három konstrukciót tesznek lehetővé, amelyek rugalmasabbá teszik őket: helyettesítő karakterek, ugrások és alternatívák. A helyettesítések olyan helyek egy karakterláncban, amelyek ismeretlenek, és tetszőleges értékűek lehetnek. Ezeket a "?" szimbólum jelöli:

$hex_karakterlánc = ( E2 34 ?? C8 A? FB )

Ez a megközelítés nagyon hasznos olyan karakterláncok megadásakor, amelyek hossza ismert, de tartalma változhat. Ha a karakterlánc egy része különböző hosszúságú lehet, kényelmes a tartományok használata:

$hex_karakterlánc = ( F4 23 62 B4 )

Ez a bejegyzés azt jelenti, hogy a sor közepén 4-6 különböző bájt lehet. Alternatív választást is végrehajthat:

$hex_karakterlánc = ( F4 23 (62 B4 | 56) 45 )

Ez azt jelenti, hogy a harmadik bájt helyén 62 B4 vagy 56 lehet, egy ilyen bejegyzés az F42362B445 vagy F4235645 soroknak felel meg.

6. Annak ellenőrzésére, hogy egy adott karakterlánc egy bizonyos eltolásban van-e egy fájlban vagy folyamatcímtérben, használja az at utasítást:

$a 100-nál és $b 200-nál

Ha a karakterlánc egy bizonyos címtartományon belül lehet, az in operátort használjuk:

$a in (0..100) és $b in (100..fi méret)

Néha vannak olyan helyzetek, amikor jelezni kell, hogy a fájlnak tartalmaznia kell egy bizonyos számot egy adott halmazból. Ez a operátor használatával történik:

1. példa szabálya
{
húrok:
$foo1 = "dummy1"
$foo2 = "dummy2"
$foo3 = "dummy3"
feltétel:
2 / ($foo1,$foo2,$foo3)
}

A fenti szabály megköveteli, hogy a fájl tartalmazzon bármely két sort a halmazból ($foo1,$foo2,$foo3). Ahelyett, hogy egy adott sorszámot adna meg egy fájlban, használhatja a tetszőleges (legalább egy sor egy adott halmazból) és az összes (egy adott halmaz összes sora) változókat.

7. Nos, az utolsó érdekes lehetőség, amelyet meg kell fontolni, egy feltétel alkalmazása több sorra. Ez a funkció nagyon hasonlít az of operátorhoz, csak erősebb a for..of operátor:

a string_set kifejezéséhez: (boolean_expression)

Ezt a bejegyzést a következőképpen kell olvasni: a string_setben megadott karakterláncok közül legalább a kifejezésdaraboknak meg kell felelniük a logikai_kifejezés feltételnek. Vagy más szavakkal: a logikai_kifejezés kiértékelésre kerül a string_set minden egyes karakterláncára, és az ezekből származó kifejezésnek True értéket kell adnia. Ezután ezt a konstrukciót egy konkrét példán vizsgáljuk meg.

PEiD készítése

Tehát, amikor a szabályokkal nagyjából minden világossá vált, megkezdhetjük a csomagolók és titkosítók detektorának megvalósítását projektünkben. Kiindulási anyagként eleinte ugyanattól a PEiD-től kölcsönztem ismert csomagolók aláírásait. A plugins mappa tartalmazza a userdb.txt fájlt, amely tartalmazza azt, amire szükségünk van. 1850 aláírás volt az adatbázisomban.

Nagyon sok, ezért a teljes importálás érdekében azt tanácsolom, hogy írjon valamilyen scriptet. Ennek az alapnak a formátuma egyszerű - a szokásos szöveges fájl, amely a következő űrlap rekordjait tárolja:

aláírás = 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

Az első sor a PEiD-ben megjelenő csomagoló nevét adja meg, de számunkra ez lesz a szabályazonosító. A második maga az aláírás. A harmadik az ep_only jelző, amely megadja, hogy az adott sort csak a belépési pont címén kell-e keresni, vagy az egész fájlban.

Nos, próbáljunk meg létrehozni egy szabályt, mondjuk az ASPack számára? Mint kiderült, ebben nincs semmi bonyolult. Először hozzunk létre egy fájlt a szabályok tárolására, és nevezzük el, például packers.yara. Ezután megkeressük a PEiD adatbázisban az összes olyan aláírást, amelyek nevében ASPack található, és átvisszük a szabályba:

szabály ASPack
{
húrok:
$ = ( 60 E8 ?? ?? ?? ?? 5D 81 ED ?? ?? (43 | 44) ?? B8 ??
$ = ( 60 EB ?? 5D EB ?? FF ?? ?? ??? ?? E9 )
[.. vágja..]
$ = ( 60 E8 03 00 00 00 E9 EB 04 5D 45 55 C3 E8 01 )
feltétel:
bármelyikhez: ($ belépési pontnál)
}

Minden talált bejegyzésnél az ep_only jelző igazra van állítva, vagyis ezeknek a soroknak a belépési pont címén kell elhelyezkedniük. Tehát a következő feltételt írjuk: "bármelyikre: ($ belépési pontnál)".

Így a megadott karakterláncok legalább egyikének jelenléte a belépési pont címén azt jelenti, hogy a fájl ASPack csomagban van. Vegye figyelembe azt is, hogy ebben a szabályban minden karakterlánc egyszerűen $ jellel van megadva, azonosító nélkül. Ez lehetséges, hiszen a feltétel részben nem hivatkozunk ezek egyikére sem, hanem a teljes készletet használjuk.

A fogadott rendszer működőképességének ellenőrzéséhez elegendő végrehajtani a parancsot a konzolon:

$ yara -r packers.yara somefi le.exe

Miután betápláltam néhány ASPack-kel csomagolt alkalmazást, megbizonyosodtam arról, hogy minden működik!

Kész prototípus

A YARA rendkívül világos és átlátható eszköznek bizonyult. Nem volt nehéz webadmin-t írni hozzá és beállítani webszolgáltatásként. Egy kis kreativitással az elemző száraz eredményei már különböző színekkel színeződnek, jelezve az észlelt kártevő veszélyességi fokát. Az adatbázis kis frissítése, és sok titkosítóhoz elérhető egy rövid leírás, és néha még a kicsomagolási utasítások is. A prototípus elkészült és tökéletesen működik, a hatóságok pedig táncolnak az örömtől!

A távirat fejlécében található funkciókód (FC) azonosítja a távirat típusát, mint például a Kérés távirat (Kérés vagy Küldés/Kérés) és Nyugtázás vagy Válasz távirat (Nyugtázó keret, Válasz keret). Ezenkívül a funkciókód tartalmazza az aktuális átviteli funkciót és vezérlő információkat, amelyek megakadályozzák az üzenetek elvesztését és megkettőzését, vagy az FDL állapotú állomástípust.

7	6	5	4	3	2	1	0	FC: Funkciókód kérés
	1							Telegramm kérése
			x					FCV = Váltakozó bit bekapcsolva
		x						href="http://profibus.felser.ch/en/funktionscode.htm#aufruffolgebit">FCB = Váltakozó bit (a keretszámból)
1				0 (0x0)				CV = ClockValue()
1				Egyéb				Fenntartott
0				0 (0x0)				TE = Idő esemény (óra szinkronizálás)
0				3 (0x3)				SDA_LOW = Adatküldés nyugtázva – alacsony prioritás
0				4 (0x4)				SDN_LOW = Adatküldés Nem nyugtázva – alacsony prioritás
0				5 (0x5)				SDA_HIGH = Adatküldés nyugtázva – magas prioritású
0				6 (0x6)				SDN_HIGH = Adatküldés Nem nyugtázva
0				7 (0x7)				MSRD = Kérési adatok küldése csoportos küldéssel
0				9 (0x9)				FDL állapot kérése
0				12(0xC)				SRD low = Adatok küldése és kérése
0				13(0xD)				SRD high = Adatok küldése és kérése
0				14(0xE)				Azonosítás kérése válasszal
0				15 (0xF)				LSAP állapot kérése válaszul 1)
0				Egyéb				Fenntartott

1) ez az érték a szabvány utolsó verziójában már nincs definiálva, csak fenntartva

7	6	5	4	3	2	1	0	FC: Funkciókód válasz
	0							választávirat
0								Fenntartott
		0	0					rabszolga
		0	1					A mester nem áll készen
		1	0					Mester készen, token nélkül
		1	1					Mester készen áll, token ringben
				0 (0x0)				rendben
				1 (0x1)				UE = Felhasználói hiba
				2 (0x2)				RR = Nincs erőforrás
				3 (0x3)				RS = SAP nincs engedélyezve
				8 (0x8)				DL = alacsony adat (normál eset DP-vel)
				9 (0x9)				NR = Nincs kész válaszadat
				10(0xA)				DH = magas adat (DP diagnózis függőben)
				12(0xC)				RDL = Adat nem érkezett és alacsony az adat
				13(0xD)				RDH = Adat nem érkezett és adat magas
				Egyéb				Fenntartott

Keretszámláló bit Az FCB (b5) keretszámláló bit megakadályozza az üzenetek megkettőzését a nyugtázó vagy válaszoló állomás (válaszadó) által, valamint a hívó állomás (kezdeményező) általi elvesztését. Nem tartoznak ide a nyugtázás nélküli kérések (SDN), valamint az FDL állapot, az azonosító és az LSAP állapot kérések.

A biztonsági sorozathoz a kezdeményezőnek minden válaszadóhoz FCB-t kell hordoznia. Amikor először küldik el a kérés táviratot (Kérés vagy Küldés/Kérés) egy válaszolónak, vagy ha újraküldik egy jelenleg nem működőként megjelölt válaszadónak, az FCB-t a válaszadóban meghatározott módon kell beállítani. A kezdeményező ezt egy Request telegramban éri el, ahol FCV=0 és FCB=1. A válaszadónak egy ilyen típusú táviratot első üzenetciklusként kell értékelnie, és el kell tárolnia az FCB=1 értéket a kezdeményező címével (SA) együtt (lásd a következő táblázatot). Ezt az üzenetciklust a kezdeményező nem fogja megismételni. Az ugyanannak a válaszadónak küldött további kérés-telegramokban a kezdeményezőnek FCV=1-et kell állítania, és minden új kérés telegrammal meg kell változtatnia az FCB-t. Bármelyik válaszadónak, aki az FCV=1-gyel címzett Request telegramot kapja, ki kell értékelnie az FCB-t. Ha az FCB megváltozott az ugyanattól a kezdeményezőtől (azonos SA-tól) érkezett legutóbbi Request telegramhoz képest, ez érvényes megerősítés, hogy az előző üzenetciklus megfelelően zárult le. Ha a Request telegram egy másik kezdeményezőtől (másik SA) származik, az FCB értékelésére már nincs szükség. A válaszadónak mindkét esetben el kell mentenie az FCB-t a forrás SA-val, amíg új táviratot nem kap. Elveszett vagy meghibásodott nyugtázási vagy választávirat esetén a kezdeményezőnek nem szabad megváltoztatnia az FCB-t a kérés újrapróbálásakor: ez azt jelzi, hogy az előző üzenetciklus hibás volt. Ha a válaszoló egy kérési telegramot kap FCV=1 értékkel és ugyanazt az FCB-t, mint a legutóbbi kérés telegramot ugyanattól a kezdeményezőtől (ugyanaz az SA), ez egy kérés újrapróbálkozását jelzi. A válaszadónak viszont újra el kell küldenie a készenlétben tartott nyugtát vagy választáviratot. A fent említett visszaigazolásig vagy egy másik címmel (SA vagy DA) küldött, nem nyugtázott távirat (Send Data with No Acknowledge, SDN) kézhezvételéig a válaszadónak készen kell tartania az utolsó nyugtázást vagy választáviratot, hogy készen álljon az esetleges újrakérésekre. A nem nyugtázott Request táviratok esetében a Request FDL Status, Ident és LSAP Status, FCV=0 és FCB=0; a válaszadó értékelésére már nincs szükség.

b5	b4	bit pozíció
FCB	FCV	Feltétel	Jelentése	akció
0	0	DA=TS/127	Kérés visszaigazolás nélkül FDL állapot/azonosító/LSAP állapot kérése	Az utolsó nyugtázás törlése
0/1	0/1	DA#TS	Kérés egy másik válaszolóhoz
1	0	DA=TS	Első kérés	FCBM: = 1 SAM:=SA Az utolsó nyugtázás/válasz törlése
0/1	1	DA=TS SA=SAM FCB#FCBM	Új kérés	Az utolsó nyugtázás/válasz törlése FCBM:= FCB Tartsa a nyugtát/választ készen az újrapróbálkozásra
0/1	1	DA=TS SA=SAM FCB=FCBM	Kérelem újrapróbálkozása	FCBM:= FCB Ismételje meg a nyugtázást/választ, és továbbra is tartsa készenlétben
0/1	1	DA=TS SA#SAM	Új kezdeményező	FCBM:= FCB SAM:= SA Nyugtázás/válasz tartása készenlétben az újrapróbálkozásra