###
  • Programok
  • Biztonság
  • hírek
  • Érdekes
  • Tanácsot
  • hírek
  • Vélemények

    • Milyen aláírása van a txt fájlnak? Módszerek „ragasztott” fájlok észlelésére. Ismeretlen szektortípus

    07.01.2021 hírek

    A koncepció " Varázslatos szám"A programozásban három jelentése van:

    • Adat aláírás
    • Kiválasztott egyedi értékek, amelyek nem egyezhetnek meg más értékekkel (pl. UUID)
    • Rossz programozási gyakorlat.

    Adat aláírás

    Varázslatos szám, vagy aláírás, - egy erőforrás vagy adat egyedi azonosítására használt egész szám vagy szövegállandó. Egy ilyen számnak önmagában nincs jelentése, és zavart okozhat, ha megfelelő kontextus vagy megjegyzés nélkül jelenik meg a programkódban, míg egy másik, akár közeli értékűre való változtatási kísérlet teljesen 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 meghatározva van. 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 kiterjesztéssel .exe 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++ inicializálatlan mutatója (2005 óta Microsoft verziók Vizuális Stúdió), amelynek hibakeresési módban a címe 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 nevének kiterjesztésétől. A fájl aláírásának értelmezéséhez biztosítják szabványos segédprogram fájlt.

    Rossz programozási gyakorlat

    A „mágikus számoknak” is nevezett 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 - a célzó szálkeresztjét - jeleníti meg a képernyő közepén. 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 ez a változás forrásszöveg nem rontja a program teljesítményét.

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

    • Ha ugyanazt a bűvös számot egynél többször használjuk egy programban (vagy potenciálisan felhasználható), akkor a megváltoztatásához minden előforduláson szerkeszteni kell (a megnevezett állandó értékének egyetlen módosítása 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, hogy tévesen megváltoztatunk egy másik, független, de azonos számértékkel rendelkező varázsszámot.

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

    Néha a mágikus számok károsítják a többplatformos kódot. A helyzet az, hogy C-ben 32 és 64 bites operációs rendszereken 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ő esetében - a célrendszer bitkapacitásától függően). A régi vagy rosszul megírt kódban előfordulhatnak „varázsszámok”, amelyek a típus méretét jelzik – ha más bitkapacitású gépekre költözik, 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); // hibás - a long 4 byte-ot feltételez, varázslatos számú elemet használunk memset(a, 0, ELEMEK SZÁMA * 4); // hibás - a long 4 byte-ot feltételez memset(a, 0, NUMBER_OF_ELEMENTS * sizeof(long)); // 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 ismert típusú fájlok szkennelésével végzett keresés (vagy ahogy gyakran mondják, a fájlok keresése aláírás alapján) az egyik leghatékonyabb az R-Studio adat-helyreállító segédprogramjában. Egy adott aláírás használata lehetővé teszi bizonyos típusú fájlok visszaállítását olyan esetekben, amikor 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ít egy lemezt egy könyvvel, a partíciós tábla hasonló lesz a tartalomjegyzékéhez. Vizsgálatkor az R-Studio ismert fájltípusokat keres a lemezpartíciós táblában bizonyos meghatározott aláírások használatával. Ezt az a tény teszi lehetővé, hogy 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 és sok esetben a fájl végén is találhatók. Szkenneléskor az R-Studio a talált adatokat az ismert fájltípusok aláírásaival párosítja, ami lehetővé teszi azok azonosítását és az adatok helyreállítását.

    Az ismert fájltípusok vizsgálatára szolgáló technológiát használva az R-Studio lehetővé teszi az adatok helyreállítását az újraformázott lemezekről, amelyek partíciós tábláit felülírták. 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 lehetőség.

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

    Az R-Studio már tartalmazza a leggyakoribb fájltípusok aláírásait (nézet teljes lista Az ismert típusú fájlok az R-Studio online súgójában találhatók.)

    Ha szükséges, a felhasználó új fájltípusokat 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ási dátuma 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ú egyéni fájlok
    Az ismert fájltípusokhoz tartozó egyéni aláírások a Beállítások párbeszédpanelen megadott XML-fájlban tárolódnak. Az aláírás hozzáadása két részből áll:

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

    Mindez megtehető az R-Studio segítségével. Ugyanakkor nem kell szakértőnek lennie az XML dokumentumok összeállításában (szerkesztésében) vagy a hexadecimális szerkesztés területén - ebben az útmutatóban (cikkben), amely magának a felhasználónak szól. belépő szint, ennek a folyamatnak az összes szakaszát részletesen tárgyaljuk.

    Példa: Aláírás hozzáadása MP4 fájlhoz (XDCam-EX Codec)
    Nézzük meg a fájl aláírásának hozzáadását egy Sony XDCAM-EX segítségével létrehozott .MP4 fájl példáján. Használhatja például az SD-kártya sérülése esetén olyan fájlokhoz, amelyeket még nem sikerült mentenie 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ájlok nehezebben tekinthetők meg hexadecimálisan.

    1. Nyissa meg a fájlokat az R-Studio alkalmazásban. 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ítsuk össze a fájlokat. Mind a négy fájlban ugyanazt a mintát fogjuk keresni. Meg fog jelenni fájl aláírása. A fájlaláí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 történik meg – 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 úgy tűnik, hogy mind a négy fájl tartalma különbözik, 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


    Kattintson a képre a nagyításhoz


    Kattintson a képre a nagyításhoz

    A képek kiemelt területe egy fájl aláírás ebből a típusból fájlokat. Szöveges és hexadecimális formában is megjelenik.

    Szöveges formában a fájl aláírása így néz ki:
    ....ftypmp42....mp42.......ingyenes

    A pontok (.) olyan karaktereket jelölnek, amelyek nem ábrázolhatók szöveges formában. 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


    Kattintson a képre a nagyításhoz


    Kattintson a képre a nagyításhoz

    Felhívjuk figyelmét, hogy a kiválasztott terület előtti adatok (fájl aláírása) mind a négy fájlban megegyeznek. Ez egy olyan 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 fényképezőgéppel készült, azonos paraméterekkel. Általában meg lehet különböztetni a műszaki információkkal megegyező mintákat a fájl aláírásától. Példánkban a fájl aláírásának 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 fordítson különös figyelmet erre a sorra, hogy ne tévedjen bele technikai információ a fájl aláírásának része.

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

    Hexadecimálisan a fájl aláírása így néz ki:
    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: Ismert fájltípust leíró XML-fájl létrehozása
    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 elemé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ó. Ezt a számot véletlenszerűen választjuk ki; Az egyetlen dolog az, hogy nem egyezhet meg semmilyen más fájltípus digitális 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 „Multimedia Video (Multimedia: Video)” 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 - az ilyen típusú fájlok kiterjesztése. 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 fájl kezdő és záró aláírását. Ehhez válassza a Kezdés, majd a lehetőséget 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. Ügyeljen arra, hogy a Feladó oszlopban 21-et írjon be.

    Kattintson a képre a nagyításhoz

    Sikeresen létrehozta saját aláírását az ismert fájltípusokhoz.

    Most el kell mentenie. 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 manuális létrehozása:
    Az alkotáshoz ez a 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 írja be a következő szöveget az első sorba:

    Ezután létrehozunk egy XML címkét, amely meghatározza a fájl típusát (FileType). A korábban leírt XML-attribútumokat figyelembe véve a címke így fog kinézni:

    Helyezzük be rögtön 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 típusát használjuk, ugyanakkor helyettesítjük hexadecimális karakterekkel, amelyek nem ábrázolhatók szöveges formában. Minden hexadecimális karakter elé beszúrjuk a "\x"-et, így a címkét fájlaláírással így fog kinézni:

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

    Ne feledje, hogy a végső fájlaláírás nem tartalmazott nem szöveges karaktereket, de tartalmazott perjeleket és háromszög zárójeleket. A félreértések és az XML szintaxis hibáinak elkerülése érdekében az aláírásban kicseréljük a "/", " " karaktereket<" и ">" hexadecimális értékeik.

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

    Tehát a teljes 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 szintaxisa megkülönbözteti a kis- és nagybetűket, így a megfelelő címke az lenne , de nem .

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

    Sikeresen létrehoztuk saját aláírásunkat az ismert fájltípusokhoz. Ez a példa elég ahhoz, hogy megértsük az egyéni fájltípus létrehozásának alapelveit. Több tapasztalt felhasználók használhatja az XML 2.0-s verzióját. Erről bővebben az R-Studio online súgójában olvashat.

    3. lépés: 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. Ebben az esetben a rendszer 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üben. 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 igennel az új fájltípus letöltésére vonatkozó kérésre.

    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. Ne feledje, hogy a fájltípust hozzáadtuk a Multimédia videó csoporthoz (Multimédia: Videó). Ezt a csoportot (mappát) kibontva látnunk kell egy elemet a leírással, amelyet mikor adtunk meg XML létrehozása fájl: Sony kameravideó, 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, egy megfelelő üzenetet fog 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: Az XML szintaxisa 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. lépés: Ismert fájltípust leíró fájl tesztelése
    Az általunk létrehozott egyéni fájltípus helyességének ellenőrzéséhez próbáljuk meg megkeresni az .mp4 fájljainkat egy cserélhető USB flash meghajtón.

    1. OS alatt 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) a lemezen lévő összes adat teljes törléséhez. Hadd USB lemez FAT32 formátumban formázott (a keresett fájlok mérete nem haladja meg a 2 GB-ot).

    2. Másolja a tesztfájlokat a lemezre, és indítsa újra a számítógépet, hogy a cache memória tartalma a lemezre kerüljön. Le is tilthatja 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. Indítsuk el az R-Studio-t. 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 négyzet bejelölését. Így letiltjuk a fájlrendszerek és fájlok keresését a partíciós tábla használatával.
    Kattintson a képre a nagyításhoz

    6. Jelölje be az Extra keresés az ismert fájltípusokhoz jelölőnégyzetet. Ez lehetővé teszi az R-Studio számára, hogy szkennelés közben ismert fájltípusokat keressen.

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

    8. Várjuk meg, amíg az R-Studio megvizsgálja a lemezt. A Scan Information (Szkennelési információ) lapon megjelenik a szkennelés folyamata (haladás).


    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 a Második szakaszban megadott fájltípusleírásnak megfelelő más nevű mappában) találhatók.


    Kattintson a képre a nagyításhoz

    Látja, 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.

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


    Kattintson a képre a nagyításhoz

    Következtetés
    Az R-Studio ismert fájltípusok keresésének képessége lehetővé teszi az adatok helyreállítását még olyan lemezekről is, amelyek fájlrendszerét felülírták. Hatékonyan kereshet fájlokat aláírásaik segítségével, ami különösen akkor hasznos, ha pontosan ismeri a visszaállítandó fájlok típusát, mint 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.

    A távirat fejlécében található funkciókód (FC) azonosítja a távirat típusát, például kérés táviratot (Request vagy Send/Request) és nyugtázási vagy választáviratot (nyugtázási keret, válaszkeret). 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 Kérjen táviratot
    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 = Óraérték ()
    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) Ident kérés a 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álasz tá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 üzenet 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ározottak szerint 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 kérelem telegramjához 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és telegramot kap FCV=1 értékkel és ugyanazt az FCB-t, mint az utolsó kérés telegramot ugyanattól a kezdeményezőtől (ugyanaz az SA), ez egy kérés újrapróbálkozást jelez. 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 távirat beérkezéséig, amely nem kapott nyugtát (Adatok küldése nyugtázás nélkül, SDN), a válaszadónak meg kell őriznie az utolsó nyugtázási vagy választáviratot, hogy készen álljon az esetleges újrakérésre. . 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

    FCBM tárolt FCB a memóriában SAM tárolt SA a memóriában

    Sokan hallottak már olyan fájlokról, mint például a rarjpeg. Ez egy speciális fájltípus, amely egy jpeg kép és egy rar archívum szorosan összeragasztva. Kiváló konténer az információtovábbítás tényének elrejtésére. A rarjpeg-et a segítségével hozhatja létre a következő parancsokat:

    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ótovábbítá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 szerepére. Leírom, hogyan találhat beillesztett fájlokat a legnépszerűbb formátumokban, vagy jelezheti a ragasztás tényét.

    Az egyesített fájlok észlelésének módszerei három csoportra oszthatók:

    1. 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ézők az összes bájtot elolvassák a jelölőig, de az utána lévő területet figyelmen kívül hagyja. Ez a módszer ideális a következő formátumokhoz: JPEG, PNG, GIF, ZIP, RAR, PDF.
    2. A fájlméret ellenőrzésének módja. Egyes formátumok (audió- és videotárolók) szerkezete lehetővé teszi a tényleges fájlméret kiszámítását és összehasonlítását eredeti méret. Formátumok: AVI, WAV, MP4, MOV.
    3. 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 saját konténer fájlrendszer. Ez a módszer a fájl anomáliáinak észlelésén alapul.

    Van élet egy 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 az egyesített fájlok „őse”, és meg kell érteni annak szerkezetét. Bármely JPEG 0xFF 0xD8 aláírással kezdődik.

    Ezt az aláírást követően szervizinformációk, opcionálisan képikon és végül a tömörített kép. 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önnek az archív verzióról és egyéb kapcsolódó adatokról szóló információk. Kísérletileg megállapítottuk, 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ű:

    1. Keresse meg a kezdeti aláírást;
    2. Keresse meg a végső aláírást;
    3. Ha a végleges aláírás után nincs adat, akkor 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égső aláírások száma megegyezik a benne lévő képkockák számával. Ezen formátumok jellemzői alapján javítható a csatolt fájlok jelenlétének ellenőrzésére szolgáló algoritmus.
    1. Az 1. pont megismétlődik az előző algoritmusból.
    2. A 2. pont megismétlődik az előző algoritmusból.
    3. Amikor megtalálta a végső aláírást, emlékezzen a helyére, és nézzen tovább;
    4. Ha így éri el az utolsó EOF markert, a fájl tiszta.
    5. Ha a fájl nem végződik 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ívumok sajátossága a három különböző aláírás jelenléte: Az archívum felépítése 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
    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 nulla bájtból állnak. 18 bájt után jön az archív megjegyzés terület, amely ideális tároló a fájl elrejtéséhez.

    A ZIP-archívum ellenőrzéséhez meg kell találnia a központi könyvtár utolsó 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 megjegyzés a ragasztás tényét is jelzi.

    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 van egy AVI-aláírás, amely meghatározza a formátumot (0x41 0x56 0x49 0x20). A 4-es eltolásnál lévő, 4 bájtból álló blokk tartalmazza az adatblokk kezdeti méretét (byte order - little endian). A következő méretet tartalmazó blokkszám kiderítéséhez 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 teljes fájlméretet. Elfogadható, hogy a számított méret kisebb lehet, mint a tényleges fájlméret. A kiszámított méret után a fájl már csak nulla bájtot tartalmaz (az 1Kb-os határ igazításához szükséges).

    Példa a méret kiszámítására:


    WAV

    Az AVI-hoz hasonlóan a WAV-fájlok RIFF-aláírással kezdődnek, ennek a fájlnak azonban a 8. bájtból származó aláírása van - WAVE (0x57 0x41 0x56 0x45). A fájlméret kiszámítása ugyanúgy történik, mint az AVI. A tényleges méretnek teljesen 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 biztosítják.
    A 4 bájt eltolásánál aláírások találhatók: 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, érdekel minket a fájlméret kiszámításának lehetősége.

    Nézzü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-as 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 az 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 ugyanazokra a célokra szolgál - hang- és képadatok, 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 „ragadós” fájlok jelenlétének ellenőrzésének módszere a méret kiszámítása a fent meghatározott 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 a ragasztás tényét jelzi. Az AVI-fájlok ellenőrzésekor elfogadott, hogy a számított méret kisebb lehet, mint a fájlméret, mivel a szegély igazításához hozzáadott nullákat tartalmaz. Ebben az esetben a számított fájlméret után nullákat kell ellenőrizni.

    Összetett fájl bináris formátumának ellenőrzése

    Ez a Microsoft által kifejlesztett fájlformátum OLE (Object Linking and Embedding) vagy COM (Component Object Model) néven is ismert. DOC fájlok, XLS, PPT 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, „-2” – a láncot lezáró szektort jelöli. 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 beillesztett egy másik fájlt a végére. Van néhány különféle módokonészlelni, vagy anomáliát jelezni 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 megállapításához be kell olvasnia egy kétbájtos számot a fájl elejétől számított 30-as eltolásnál, és emelnie 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 rámutathat a fájlok ragasztásának tényére. Ennek a módszernek azonban van egy jelentős hátránya. Ha a támadó ismeri a szektor méretét, akkor csak be kell illesztenie a fájlját és további n bájtot, hogy a beillesztett 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:

    1. CountFat – a FAT szektorok száma. A fájl eleje 44-es eltolásánál található (4 bájt);
    2. CountMiniFAT – MiniFAT szektorok száma. A fájl eleje 64-es eltolásánál található (4 bájt);
    3. CountDIFAT – DIFAT szektorok száma. A fájl eleje 72-es eltolásánál található (4 bájt);
    4. 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-as eltolásnál van. Ezután meg kell szerezni a DE teljes reprezentációját a FAT-ból, és meg kell számolni a DE szektorok számát;
    5. CountStreams – adatfolyamokkal rendelkező szektorok száma;
    6. CountFree – szabad szektorok száma;
    7. CountClassified – 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öm egy meglehetősen érdekes feladatot adott nekem. Rövid időn belül írjon egy futtatható fájlelemzőt, amely képes lenne megtalálni a vírustörzseket az aláírások alapján, és meghatározni a használt csomagolót/titkosítót. A kész prototípus néhány órán belül megjelent.

    A szerző szava

    Aláírás-elemzés

    A rosszindulatú objektumok aláírások segítségével történő keresése minden vírusirtó képes. Általában az aláírás bizonyos jellemzők formalizált leírása, amelyek alapján megállapítható, hogy a vizsgált fájl vírus és jól meghatározott vírus.

    Különféle technikák vannak itt. Egy másik lehetőség egy rosszindulatú objektum N bájtjából álló aláírás használata. Ebben az esetben nem hülye összehasonlítást végezhet, hanem valamilyen maszk segítségével (például EB ?? ?? CD 13 bájtok keresése). Vagy kérdezz további feltételek mint például „ilyen és ilyen bájtoknak kell lenniük a program belépési pontján” és így tovább. A rosszindulatú program aláírása külön kérdés.

    Ugyanígy leírunk néhány jelet, amelyek alapján 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 már egy olyan eszközről, mint a PEiD, amely képes azonosítani a leggyakrabban használt csomagolókat, titkosítókat és fordítókat (az adatbázis nagyszámú aláírást tartalmaz) 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 projektnek nem lesz további fejlesztése. Kár, mert a PEiD képességei (főleg a plugin rendszert tekintve) nagyon hasznosak lehetnek számomra. Rövid elemzés után világossá vált, hogy erre nincs lehetőség. Ám az angol nyelvű blogok böngészése után gyorsan megtaláltam a számomra megfelelőt. YARA Project (code.google.com/p/yara-project).

    Mi az a YARA?

    Kezdettől fogva meg voltam győződve arról, hogy valahol az interneten már létezik egy nyílt forráskódú fejlesztés, amely egy bizonyos aláírás és a vizsgált fájl közötti megfelelést fogja felvállalni. 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 reálisabbnak 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ípusok rosszindulatú programok szöveges vagy bináris mintákat használva, 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 egy sor sorból és valamilyen logikai kifejezésből áll, amelyek alapján az analizátor kiváltó logikája meghatározásra kerül.

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

    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 a $a, $b, $c változókban leírt mintakarakterláncok közül legalább egyet tartalmaz, a silent_banker trójainak kell minősíteni. És ez egy nagyon egyszerű szabály. A valóságban a szabályok sokkal összetettebbek lehetnek (erről lentebb lesz szó).
    Még az ezt használó projektek listája is a YARA projekt tekintélyéről beszé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éshez, és egyszerűen egy végrehajtható fájlt, amellyel a YARA-t önálló alkalmazásként használhatja. Munkám részeként az első lehetőséget választottam, de az egyszerűség kedvéért ebben 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 a freeware-től és a PEiD csomagolóitól. De kezdjük a telepítéssel.

    Telepítés

    Ahogy már 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 a konzolban meghívjuk az alkalmazást, megkapjuk az indítás szabályait.

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

    Vagyis a program meghívásának formátuma a következő: először ott van a program neve, majd a lehetőségek listája, amely után megjelenik a fájl a szabályokkal, és a legvégén - a fájl neve vizsgált (vagy a fájlokat tartalmazó könyvtár), vagy a folyamat azonosítója. Most szeretném jól elmagyarázni, hogyan készülnek ezek a szabályok, de nem akarom azonnal száraz elmélettel terhelni. Ezért a dolgokat másként fogjuk megtenni, é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ű észlelését aláírások segítségével.

    Saját vírusirtó

    A legfontosabb kérdés: hol szerezhető be az aláírási adatbázis ismert vírusok? A víruskereső cégek aktívan megosztják egymással az ilyen adatbázisokat (egyesek bőkezűbben, mások kevésbé). Hogy őszinte legyek, eleinte még abban is kételkedtem, hogy valahol az interneten valaki nyíltan posztol ilyesmit. De mint kiderült, vannak jó emberek. A népszerű ClamAV vírusirtó megfelelő adatbázisa mindenki számára elérhető (clamav.net/lang/en). A „Legújabb stabil kiadás” részben talál egy hivatkozást a víruskereső termék legújabb verziójához, valamint a ClamAV vírusadatbázisok letöltéséhez. 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ő az aláírások fő adatbázisát tartalmazza, a második a legteljesebb adatbázist tartalmazza Ebben a pillanatban alap különféle kiegészítésekkel. A Daily.cvd, amely több mint 100 000 rosszindulatú programmegjelenítést tartalmaz, teljesen elegendő erre a célra. A ClamAV adatbázis azonban nem YARA adatbázis, ezért át kell alakítanunk szükséges formátum. De hogyan? Hiszen még semmit sem tudunk sem a ClamAV, 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ályok készletévé 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 a clamav.yara fájlban egy aláírási adatbázist kapunk, amely azonnal használatra kész lesz. Most próbáljuk ki a YARA és a ClamAV adatbá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. Ha volt vírustörzs a /pentest/msf3/data mappában (legalábbis azok, amelyek a ClamAV adatbázisban vannak), akkor a YARA azonnal jelenteni fogja ezt. Elvileg ez egy kész aláírás-szkenner. A nagyobb kényelem érdekében írtam egy egyszerű szkriptet, amely ellenőrizte a ClamAV adatbázis-frissítéseket, letöltötte az új aláírásokat és konvertálta azokat YARA formátumba. De ezek már részletek. A feladat egy része elkészült, most már megkezdheti a csomagolók/titkosítók azonosításának szabályait. De ehhez egy kicsit foglalkoznom kellett velük.

    Játssz a szabályok szerint

    Tehát egy szabály a program fő mechanizmusa, amely lehetővé teszi a hozzárendelést megadott fájl bármely kategóriába. A szabályok 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 BadBoy
    {
    húrok:
    $a = "win.exe"
    $b = "http://foo.com/badfi le1.exe"
    $c = "http://bar.com/badfi le2.exe"
    feltétel:
    $a és ($b vagy $c)
    }

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

    1. Minden szabály azzal kezdődik kulcsszó szabályt követi a szabályazonosító. Az azonosítók neve megegyezhet a C/C++ változóival, azaz állhat betűkből és számokból, és az első karakter nem lehet szám. Az azonosító név maximális hossza 128 karakter.

    2. A szabályok általában két részből állnak: egy definíciós szakaszból (karakterláncok) és egy feltétel szakaszból (feltétel). A karakterláncok szekció azokat az adatokat adja meg, amelyek alapján a feltétel szakasz eldönti, hogy egy adott fájl megfelel-e bizonyos feltételeknek.

    3. A string szekció minden sorának megvan a maga azonosítója, amely a $ jellel kezdődik – általában, mint egy változódeklaráció a PHP-ben. A YARA támogatja a bezárt normál karakterláncokat dupla idézőjelek("") és hexadecimális karakterláncok kapcsos zárójelek közé (()), 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 egy fájl vagy folyamat mikor felel meg a szabálynak. Ez a szakasz általában a korábban deklarált sorokra vonatkozik. A karakterlánc-azonosítót pedig logikai változóként kezeli, amely true értéket ad vissza, ha a karakterlánc megtalálható 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 bármilyen értékkel helyettesíthetők. Ezeket a „?” szimbólum jelzi:

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

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

    $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 adott eltolásban van-e egy fájl- vagy folyamatcímtérben, az at operátort használjuk:

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

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

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

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

    Példa szabálya1
    {
    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 meghatározott számú sort adna meg a 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 figyelembe kell venni, egy feltétel alkalmazása sok 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ést a rendszer kiértékeli a string_set minden egyes karakterláncára, és az ezekből származó kifejezéseknek True értéket kell adniuk. A továbbiakban ezt a konstrukciót vizsgáljuk meg egy konkrét példa segítségével.

    PEiD készítése

    Tehát, amikor minden többé-kevésbé világossá vált a szabályokkal kapcsolatban, elkezdhetjük a csomagolók és titkosítók detektorának megvalósítását projektünkben. Kezdetben forrásanyagként ismert csomagolók aláírásait kölcsönöztem ugyanattól a PEiD-től. A plugins mappában van egy userdb.txt fájl, amely tartalmazza azt, amire szükségünk van. 1850 aláírás volt az adatbázisomban.

    Elég sok, ezért a teljes importálás érdekében azt tanácsolom, hogy írjon valamilyen scriptet. Ennek az adatbázisnak a formátuma egyszerű - a szokásosat használják szöveges fájl, amely a következő rekordokat 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 = igaz

    Az első sor a csomagoló nevét adja meg, ami a PEiD-ben fog megjelenni, de számunkra ez lesz a szabályazonosító. A második maga az aláírás. A harmadik az ep_only jelző, amely jelzi, hogy egy adott sort csak a belépési pont címén kell-e keresni, vagy a teljes 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 szerepel az ASPack, és átvisszük őket 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 rekord ep_only jelzője igaz, azaz ezeknek a soroknak a belépési pont címén kell elhelyezkedniük. Ezért a következő feltételt írjuk: „bármelyikre: ($belépéskor)”.

    Így a megadott sorok legalább egyikének jelenléte a belépési pont címén azt jelenti, hogy a fájl tele van ASPack-kal. Kérjük, vegye figyelembe azt is, hogy a ezt a szabályt minden karakterlánc egyszerűen a $ jellel van megadva, azonosító nélkül. Ez azért lehetséges, mert a feltétel részben nem férünk hozzá konkrétan, hanem a teljes készletet használjuk.

    Az eredményül kapott rendszer működőképességének ellenőrzéséhez futtassa a parancsot a konzolon:

    $ yara -r packers.yara somefi le.exe

    Miután betápláltam néhány ASPack-kel csomagolt alkalmazást, meg voltam győződve 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 webadminot írni hozzá, és beállítani, hogy webszolgáltatásként működjön. 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. Kis frissítés alap, é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 főnökök pedig örömmel táncolnak!