R-Studio pielāgota zināma faila veida izveide. Faila tipa noteikšana pēc paraksta Kas ir faila paraksts

Koncepts " Maģiskais skaitlis Programmēšanā ir trīs nozīmes:

  • Datu paraksts
  • Atlasīts unikālas vērtības, kam nevajadzētu būt tādam pašam kā citām vērtībām (piemēram, UUID)
  • Slikta programmēšanas prakse.

Datu paraksts

Maģiskais skaitlis, vai parakstu, - vesels skaitlis vai teksta konstante, ko izmanto, lai unikāli identificētu resursu vai datus. Šādam skaitlim pašam par sevi nav nekādas nozīmes un tas var radīt apjukumu, ja tas parādās programmas kodā bez atbilstoša konteksta vai komentāra, savukārt mēģinājums to mainīt uz citu, kaut vai tuvu vērtībām, var radīt pilnīgi neparedzamas sekas. Šī iemesla dēļ šādus skaitļus ironiski sauca par maģiskiem skaitļiem. Pašlaik šis nosaukums ir stingri nostiprināts kā termins. Piemēram, jebkura kompilētā Java valodas klase sākas ar heksadecimālo "maģisko skaitli" 0xCAFEBABE. Otrs plaši pazīstams piemērs ir jebkurš izpildāmais fails OS Microsoft Windows ar paplašinājumu .exe sākas ar baitu secību 0x4D5A (kas atbilst ASCII rakstzīmēm MZ - viena no MS-DOS radītājiem Marka Zbikovska iniciāļiem). Mazāk zināms piemērs ir neinicializēts rādītājs programmā Microsoft Visual C++ (kopš Microsoft Visual Studio 2005. gada versijas), kura adrese ir 0xDEADBEEF atkļūdošanas režīmā.

UNIX formātā operētājsistēmas Faila tipu parasti nosaka faila paraksts neatkarīgi no tā nosaukuma paplašinājuma. Tie nodrošina standarta failu utilītu, lai interpretētu faila parakstu.

Slikta programmēšanas prakse

To sauc arī par "maģiskiem cipariem" ir slikta programmēšanas prakse, ja avota tekstā ir skaitliska vērtība un nav skaidrs, ko tā nozīmē. Piemēram, šāds fragments, kas rakstīts Java valodā, būtu slikts:

DrawSprite(53, 320, 240);

gala int SCREEN_WIDTH = 640 ; gala int EKRĀNA_AUGSTUMS = 480 ; gala int SCREEN_X_CENTER = SCREEN_WIDTH / 2 ; gala int SCREEN_Y_CENTER = EKRĀNA_AUGSTUMS / 2 ; gala int SPRITE_CROSSHAIR = 53 ; ... drawSprite(SPRITE_CROSSHAIR, SCREEN_X_CENTER, SCREEN_Y_CENTER);

Tagad tas ir skaidrs: šī līnija parāda spraitu — tēmēekļa krustpunktu — ekrāna centrā. Lielākajā daļā programmēšanas valodu visas šādām konstantēm izmantotās vērtības tiks aprēķinātas kompilēšanas laikā un aizstātas ar vietām, kur vērtības tiek izmantotas. Tāpēc šādas izmaiņas avota tekstā nepazemina programmas veiktspēju.

Turklāt maģiski skaitļi ir potenciāls kļūdu avots programmā:

  • Ja viens un tas pats maģiskais skaitlis programmā tiek izmantots vairāk nekā vienu reizi (vai potenciāli varētu tikt izmantots), tad, lai to mainītu, būs jārediģē katrs gadījums (nevis tikai viens rediģēts nosauktās konstantes vērtība). Ja netiek novērsti visi gadījumi, radīsies vismaz viena kļūda.
  • Vismaz vienā no gadījumiem maģiskais skaitlis sākotnēji var būt nepareizi uzrakstīts, un to ir diezgan grūti noteikt.
  • Maģiskais skaitlis var būt atkarīgs no netieša parametra vai cita maģiskā skaitļa. Ja šīs atkarības, kas nav skaidri identificētas, nav izpildītas, radīsies vismaz viena kļūda.
  • Pārveidojot viena maģiskā skaitļa gadījumus, ir iespējams kļūdaini mainīt citu maģisko skaitli, kas ir neatkarīgs, bet kuram ir tāda pati skaitliskā vērtība.

Burvju skaitļi un starpplatformu

Dažreiz maģiski skaitļi kaitē starpplatformu kodam. Fakts ir tāds, ka C versijā 32 un 64 bitu operētājsistēmās tiek garantēts char , short un long long tipa lielums, savukārt int , long , size_t un ptrdiff_t lielums var mainīties (pirmajiem diviem, atkarībā no kompilatoru izstrādātāju vēlmēm, pēdējiem diviem - atkarībā no mērķa sistēmas bitu jaudas). Vecā vai slikti uzrakstītā kodā var būt “maģiski skaitļi”, kas norāda tipa lielumu - pārejot uz mašīnām ar atšķirīgu bitu ietilpību, tie var radīt smalkas kļūdas.

Piemēram:

const size_t SKAITS_OF_ELEMENTI = 10 ; garš a[NUMBER_OF_ELEMENTS]; memset(a, 0, 10 * 4); // nepareizi - tiek pieņemts, ka garums ir 4 baiti, tiek izmantots maģiskais elementu skaits memset(a, 0, NUMBER_OF_ELEMENTS * 4); // nepareizi - tiek pieņemts, ka garums ir 4 baiti memset(a, 0, NUMBER_OF_ELEMENTS * izmērs(garš)); // nav gluži pareizi - tipa nosaukuma dublēšana (ja tips mainīsies, tas būs jāmaina arī šeit) memset (a , 0 , NUMBER_OF_ELEMENTS * sizeof (a [ 0 ])); // pareizi, optimāli dinamiskiem masīviem, kuru lielums nav nulle memset(a, 0, sizeof(a)); // pareizi, optimāli statiskiem masīviem

Skaitļi, kas nav maģiski

Ne visi skaitļi ir jāpārvērš konstantēs. Piemēram, kods

Meklēšana, skenējot zināmu veidu failus (vai, kā mēdz teikt, failu meklēšana pēc paraksta) ir viena no efektīvākajām R-Studio datu atkopšanas utilīta izmantotajām metodēm. Dotā paraksta izmantošana ļauj atjaunot noteikta veida failus gadījumos, kad informācija par direktoriju struktūru un failu nosaukumiem daļēji vai pilnībā trūkst (bojāta).

Parasti diska nodalījuma tabulu izmanto, lai noteiktu failu atrašanās vietu. Ja salīdzināsiet disku ar grāmatu, nodalījuma tabula būs līdzīga tās satura rādītājam. Skenējot, R-Studio meklē zināmos failu tipus diska nodalījuma tabulā, izmantojot noteiktus norādītos parakstus. To padara iespējamu fakts, ka praktiski katram faila tipam ir unikāls paraksts vai datu modelis. Failu paraksti ir atrodami noteiktā vietā faila sākumā un daudzos gadījumos arī faila beigās. Skenējot, R-Studio saskaņo atrastos datus ar zināmu failu tipu parakstiem, kas ļauj tos identificēt un to datus atgūt.

Izmantojot zināmo failu tipu skenēšanas tehnoloģiju, R-Studio ļauj atgūt datus no diskiem, kas ir pārformatēti un kuru nodalījumu tabulas ir pārrakstītas. Turklāt, ja diska nodalījums tiek pārrakstīts, bojāts vai izdzēsts, vienīgā iespēja ir skenēt zināmos failu tipus.

Taču gandrīz visam ir savi trūkumi, un zināmie R-Studio izmantotie failu tipi nav izņēmums. Tātad, skenējot zināmos failu tipus, R-Studio ļauj atgūt tikai nesadrumstalotus failus, taču, kā jau minēts, vairumā gadījumu šī ir jaunākā iespējamā metode.

R-Studio jau ir iekļauti visizplatītāko failu tipu paraksti (skat pilns saraksts zināmu veidu failus var atrast R-Studio tiešsaistes palīdzības sadaļā.)

Ja nepieciešams, lietotājs R-Studio var pievienot jaunus failu tipus. Piemēram, ja jums ir jāatrod unikāla tipa faili vai tie, kas izstrādāti pēc pēdējā R-Studio izlaišanas datuma, varat pievienot savus parakstus zināmo tipu failiem. Šis process tiks apspriests tālāk.

Zināmu veidu pielāgoti faili
Tiek glabāti zināmu failu tipu pielāgotie failu paraksti XML fails e norādīts dialoglodziņā Iestatījumi. Paraksta pievienošana sastāv no divām daļām:

  1. Faila paraksta noteikšana, kas atrodas faila sākumā un, ja tāds ir, faila beigās.
  2. Ģenerējiet XML failu, kas satur faila parakstu un citu informāciju par faila tipu.

To visu var izdarīt, izmantojot R-Studio. Tajā pašā laikā jums nav jābūt ekspertam XML dokumentu sastādīšanas (rediģēšanas) vai heksadecimālās rediģēšanas jomā - šajā rokasgrāmatā (rakstā), kas ir paredzēts pašam lietotājam sākuma līmenis, visi šī procesa posmi tiks apspriesti detalizēti.

Piemērs: paraksta pievienošana MP4 failam (XDCam-EX Codec)
Apskatīsim faila paraksta pievienošanu, izmantojot .MP4 faila piemēru, kas izveidots, izmantojot Sony XDCAM-EX. Varat to izmantot, piemēram, SD kartes bojājumu gadījumā failiem, kurus vēl neesat paspējis saglabāt datora cietajā diskā.

Pirmais posms: faila paraksta noteikšana
Lai noteiktu faila parakstu, apsveriet tāda paša formāta failu piemērus.

Lai tie būtu četri video faili no Sony XDCAM-EX:
ZRV-3364_01.MP4
ZRV-3365_01.MP4
ZRV-3366_01.MP4
ZRV-3367_01.MP4

Apsvēršanas atvieglošanai ļaujiet tiem būt maziem failiem. Lielākus failus ir grūtāk skatīt heksadecimālā formātā.

1. Atveriet failus programmā R-Studio. Lai to izdarītu, ar peles labo pogu noklikšķiniet uz katra faila un konteksta izvēlnē atlasiet Skatīt/rediģēt.

2. Salīdzināsim failus. Mēs meklēsim to pašu modeli, kas atrodams visos četros failos. Viņš parādīsies faila paraksts. Parasti faila paraksti tiek atrasti faila sākumā, bet dažreiz arī beigās.

3. Faila sākumā definējiet faila parakstu. Mūsu piemērā tas atrodas faila pašā sākumā. Ņemiet vērā, ka tas ne vienmēr notiek - bieži faila paraksts atrodas faila sākumā, bet ne pirmajā rindā (nobīde).

No tālāk redzamajiem attēliem šķiet, ka visu četru failu saturs ir atšķirīgs, taču tie visi sākas ar vienu un to pašu faila parakstu.


Noklikšķiniet uz attēla, lai to palielinātu


Noklikšķiniet uz attēla, lai to palielinātu


Noklikšķiniet uz attēla, lai to palielinātu


Noklikšķiniet uz attēla, lai to palielinātu

Izceltais apgabals attēlos ir faila paraksts šāda veida failus. Tas tiek parādīts gan teksta, gan heksadecimālā formātā.

Teksta formā faila paraksts izskatās šādi:
....ftypmp42....mp42.......bezmaksas

Punkti (.) norāda rakstzīmes, kuras nevar attēlot teksta formā. Tāpēc ir jānorāda arī faila paraksta heksadecimālā forma:
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. Tādā pašā veidā mēs definējam faila parakstu, bet pašā faila beigās. Tas var būt atšķirīgs faila paraksts, atšķirīgs garums.

Zemāk esošie attēli izceļ faila parakstu faila beigās:


Noklikšķiniet uz attēla, lai to palielinātu


Noklikšķiniet uz attēla, lai to palielinātu


Noklikšķiniet uz attēla, lai to palielinātu


Noklikšķiniet uz attēla, lai to palielinātu

Lūdzu, ņemiet vērā, ka dati pirms atlasītā apgabala (faila paraksts) ir vienādi visos četros failos. Šī ir tehniska informācija, kas nav faila paraksts, bet norāda, ka visi četri attēli (faili) ir uzņemti, izmantojot vienu un to pašu kameru ar vienādiem parametriem. Parasti no faila paraksta ir iespējams atšķirt atbilstības modeļus ar tehnisko informāciju. Mūsu piemērā pēdējā rindā pirms faila paraksta sākuma mēs redzam tekstu ‘RecordingMode type=”normal”’, kas skaidri norāda, ka tas ir kaut kāds faila parametrs, nevis paraksts. Vienmēr pievērsiet īpašu uzmanību šai līnijai, lai kļūdaini neiekļautu tehniskā informācija daļa no faila paraksta.

Mūsu gadījumā faila paraksts ir šāds teksts:
...
Atgādināsim, ka punkti norāda rakstzīmes, kuras nevar attēlot teksta formā.

Heksadecimālā faila paraksts izskatās šādi:
3N 2F 4E 6F 6E 52 65 61 6N 54 69 6A 65 4A 65 74 61 3E 0D 0A 00
Lūdzu, ņemiet vērā: paraksts ne vienmēr būs faila beigās.

Otrais posms: XML faila izveide, kas apraksta zināmu faila tipu
Tagad, definējot faila parakstu, varat izveidot XML failu un iekļaut atbilstošo faila tipu programmā R-Studio. To var izdarīt divos veidos:

2.1 Izmantojot iebūvēto grafiskais redaktors failu paraksti:
Izvēlnē Rīki atlasiet vienumu Iestatījumi, atvērtajā dialoglodziņā Iestatījumi noklikšķiniet uz cilnes Zināmie failu tipi un pēc tam noklikšķiniet uz pogas Rediģēt lietotāja failu tipus.

Noklikšķiniet uz attēla, lai to palielinātu

Dialoglodziņā Rediģēt lietotāja failu tipus noklikšķiniet uz pogas Izveidot faila tipu.
Iestatiet šādas opcijas:

  • Id — unikāls digitālais identifikators. Šis numurs tiks izvēlēti nejauši; Vienīgais ir tas, ka tam nevajadzētu atbilst cita veida faila digitālajam identifikatoram.
  • Grupas apraksts - grupa, kurā atrastie faili atradīsies R-Studio. Varat iestatīt vai nu jauna grupa, vai izvēlieties kādu no jau esošajiem. Mums tā būs grupa “Multimedia Video (Multimedia: Video)”.
  • Apraksts - Īss apraksts faila tips. Mūsu piemērā varat izmantot, piemēram, "Sony cam video, XDCam-EX".
  • Paplašinājums - šāda veida failu paplašinājums. Mūsu gadījumā - mp4.

Funkcijas parametrs nav obligāts, mūsu gadījumā tas nav jāizmanto.

Noklikšķiniet uz attēla, lai to palielinātu

Tālāk jums jāievada sākuma un beigu faila paraksts. Lai to izdarītu, atlasiet Sākt un pēc tam konteksta izvēlne komandu Pievienot parakstu.

Noklikšķiniet uz attēla, lai to palielinātu

Pēc tam veiciet dubultklikšķi uz lauka<пустая сигнатура> () un ievadiet atbilstošo tekstu.

Noklikšķiniet uz attēla, lai to palielinātu

Pēc tam izveidojiet galīgo faila parakstu. Noteikti ievadiet 21 kolonnā No.

Noklikšķiniet uz attēla, lai to palielinātu

Jūs esat veiksmīgi izveidojis savu parakstu zināmiem failu tipiem.

Tagad jums tas ir jāsaglabā. Ir divi veidi: varat to saglabāt noklusējuma failā, kas norādīts dialoglodziņa Iestatījumi cilnē Galvenā, noklikšķinot uz pogas Saglabāt. Vai arī noklikšķiniet uz pogas Saglabāt kā... un saglabājiet parakstu kādā citā failā.

2.2. Manuāla XML faila izveide, kas apraksta zināmu faila tipu:
Par radīšanu šo failu Izmantosim XML versiju 1.0 un UTF-8 kodējumu. Nekrītiet izmisumā, ja nezināt, kas tas ir – vienkārši atveriet jebkuru teksta redaktors(piemēram, Notepad.exe) un pirmajā rindā ievadiet šādu tekstu:

Tālāk mēs izveidosim XML tagu, kas definē faila tipu (FileType). Ņemot vērā iepriekš aprakstītos XML atribūtus, tags izskatīsies šādi:

Ievietosim to uzreiz pēc tam

Tālāk mēs definējam faila parakstu (tag ). Sākotnējais paraksts (faila sākumā) atradīsies taga iekšpusē bez jebkādiem atribūtiem. Mēs izmantojam paraksta teksta veidu, bet tajā pašā laikā aizstājam heksadecimālās rakstzīmes, kuras nevar attēlot teksta formā. Pirms katras heksadecimālās rakstzīmes ievietojam "\x" Tādējādi tagu ar faila parakstu izskatīsies šādi:

Ja tāds ir, ir jādefinē arī beigu paraksts (faila beigās). Tas izmanto to pašu tagu, bet ar elementu "from" un atribūtu "end". Tas izskatīsies šādi:

Atcerieties, ka galīgajā faila parakstā nebija rakstzīmju, kas nav teksta rakstzīmes, bet gan bija slīpsvītras un trīsstūrveida iekavas. Lai izvairītos no pārpratumiem un kļūdām XML sintaksē, parakstā aizstāsim rakstzīmes "/", "<" и ">" to heksadecimālās vērtības.

Beigās pēc faila parakstiem ir jābūt beigu tagiem FileType un FileTypeList:

Tātad visam failam vajadzētu izskatīties šādi:


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

Atcerieties: XML sintakse ir reģistrjutīga, tāpēc pareizais tags būtu , bet ne .

Saglabāsim failu teksta formātā ar paplašinājumu .xml. Piemēram: SonyCam.xml.

Mēs esam veiksmīgi izveidojuši savu parakstu zināmiem failu tipiem. Šis piemērs ir pilnīgi pietiekams, lai izprastu pielāgota faila tipa izveides pamatprincipus. Pieredzējuši lietotāji var izmantot XML versiju 2.0. Vairāk par to varat lasīt R-Studio tiešsaistes palīdzības sadaļā.

3. darbība: pārbaudiet un pievienojiet failu, kas apraksta zināmu faila tipu
Nākamais solis ir pievienot (augšupielādēt) savu XML failu R-Studio. Šajā gadījumā tas tiks automātiski pārbaudīts.

Ielādēsim R-Studio iepriekšējā posmā izveidoto XML failu. Lai to izdarītu, izvēlnē Rīki atlasiet vienumu Iestatījumi. Dialoglodziņa Iestatījumi cilnes Galvenā apgabalā Lietotāja failu tipi pievienojiet mūsu izveidoto XML failu (SonyCam.xml). Noklikšķiniet uz pogas Lietot.

Noklikšķiniet uz attēla, lai to palielinātu

2. Atbildiet Jā uz pieprasījumu lejupielādēt jaunu faila tipu.

Noklikšķiniet uz attēla, lai to palielinātu

3. Lai pārbaudītu, vai faila tips ir veiksmīgi ielādēts, dialoglodziņā Iestatījumi noklikšķiniet uz cilnes Zināmie failu tipi. Atcerieties, ka faila tipu pievienojām grupai Multivides video (Multivide: Video). Paplašinot šo grupu (mapi), mums vajadzētu redzēt elementu ar aprakstu, ko norādījām, veidojot XML failu: Sony cam video, XDCam-EX (.mp4).

Noklikšķiniet uz attēla, lai to palielinātu


Noklikšķiniet uz attēla, lai to palielinātu

Ja faila sintaksē ir kļūdas, jūs redzēsit atbilstošu ziņojumu:

Noklikšķiniet uz attēla, lai to palielinātu

Šādā gadījumā vēlreiz pārbaudiet, vai XML failā nav kļūdu. Atcerieties: XML sintakse ir reģistrjutīga, un katra taga beigās ir jābūt beigu tagam.

4. darbība. Faila pārbaude, kas apraksta zināmu faila tipu
Lai pārbaudītu izveidotā pielāgotā faila veida pareizību, mēģināsim atrast savus .mp4 failus noņemamajā USB zibatmiņas diskā.

1. Operētājsistēmā Windows Vista vai Windows 7 veiciet pilnu (ne ātru) diska formatēšanu vai izmantojiet diska vietas tīrīšanas utilītu (piemēram, R-Wipe & Clean), lai pilnīga noņemšana visi diskā pieejamie dati. Ļaujiet USB disks formatēts FAT32 (meklējamo failu izmērs nepārsniedz 2 GB).

2. Kopēsim to testa faili uz diska un restartējiet datoru, lai kešatmiņas saturs tiktu saglabāts diskā. Varat arī atspējot ārējais disks un pēc tam pievienojiet to vēlreiz.

3. Operētājsistēmā disks tiks definēts kā, piemēram, loģiskais disks F:\.

4. Palaidīsim R-Studio. Atlasiet mūsu disku (F:\) un noklikšķiniet uz pogas Skenēt

Noklikšķiniet uz attēla, lai to palielinātu

5. Dialoglodziņa Scan (Skenēšana) apgabalā (Failu sistēma) noklikšķiniet uz pogas Mainīt... un noņemiet atzīmi no visām izvēles rūtiņām. Tādā veidā mēs atspējosim failu sistēmu un failu meklēšanu, izmantojot nodalījuma tabulu.
Noklikšķiniet uz attēla, lai to palielinātu

6. Atzīmējiet izvēles rūtiņu Extra Search for Known File Types. Tas ļaus R-Studio skenēšanas laikā meklēt zināmos failu tipus.

7. Lai sāktu skenēšanu, noklikšķiniet uz pogas Skenēt.

8. Pagaidīsim, kamēr R-Studio skenēs disku. Cilnē Skenēšanas informācija tiks parādīta skenēšanas norise (progress).


Noklikšķiniet uz attēla, lai to palielinātu

9. Kad skenēšana ir pabeigta, atlasiet elementu Extra Found Files un veiciet dubultklikšķi uz tā.


Noklikšķiniet uz attēla, lai to palielinātu

10. Mūsu testa faili atradīsies Sony cam video, XDCam-EX mapē (vai mapē ar citu nosaukumu, kas atbilst otrajā posmā norādītajam faila tipa aprakstam).


Noklikšķiniet uz attēla, lai to palielinātu

Jūs redzat, ka failu nosaukumi, datumi un atrašanās vietas (mapes) netika atjaunoti, jo šo informāciju glabājas failu sistēmā. Tāpēc R-Studio automātiski parādīs katru failu ar jaunu nosaukumu.

Tomēr ir skaidrs, ka failu saturs nav bojāts. Lai to pārbaudītu, atveriet tos attiecīgajā programmā, piemēram, VLC multivides atskaņotājā.


Noklikšķiniet uz attēla, lai to palielinātu

Secinājums
R-Studio spēja skenēt zināmos failu tipus ļauj atgūt datus pat no diska, kura failu sistēmas ir vai nu pārrakstītas. Jūs varat diezgan efektīvi meklēt failus, izmantojot to parakstus, kas ir īpaši noderīgi, ja precīzi zināt, kāda veida faili tiek atjaunoti, kā tas ir mūsu piemērā. Iespēja izveidot pielāgotus failu tipus ļauj zināmo failu tipu sarakstam pievienot jebkuru failu, kuram ir noteikts faila paraksts.

Iespējams, daudzi ir dzirdējuši par tādiem failiem kā rarjpeg. Šis ir īpašs failu veids, kas ir jpeg attēls un rar arhīvs, kas ir cieši salīmēti kopā. Tas ir lielisks konteiners informācijas pārsūtīšanas fakta slēpšanai. Rarjpeg var izveidot, izmantojot šādas komandas:

UNIX: kaķa attēls1.jpg arhīvs.rar > attēls2.jpg
WINDOWS: kopēt /b image1.jpg+archive.rar image2.jpg

Vai arī, ja jums ir hex redaktors.

Protams, lai slēptu informācijas pārsūtīšanas faktu, varat izmantot ne tikai JPEG formātu, bet arī daudzus citus. Katram formātam ir savas īpatnības, kuru dēļ tas var būt un var nebūt piemērots konteinera lomai. Es aprakstīšu, kā var atrast ielīmētos failus populārākajos formātos vai norādīt uz līmēšanas faktu.

Apvienoto failu noteikšanas metodes var iedalīt trīs grupās:

  1. Metode apgabala pārbaudei pēc EOF marķiera. Daudziem populāriem failu formātiem ir tā sauktais faila beigu marķieris, kas ir atbildīgs par vēlamo datu parādīšanu. Piemēram, fotoattēlu skatītāji nolasa visus baitus līdz šim marķierim, bet apgabals aiz tā tiek ignorēts. Šī metode ir ideāli piemērota šādiem formātiem: JPEG, PNG, GIF, ZIP, RAR, PDF.
  2. Faila lieluma pārbaudes metode. Dažu formātu (audio un video konteineru) struktūra ļauj aprēķināt faktisko faila lielumu un salīdzināt to ar sākotnējo izmēru. Formāti: AVI, WAV, MP4, MOV.
  3. CFB failu pārbaudes metode. CFB jeb Compound File Binary Format ir Microsoft izstrādāts dokumenta formāts, kas ir konteiners ar savu failu sistēmu. Šī metode ir balstīta uz anomāliju noteikšanu failā.

Vai ir dzīve pēc faila beigām?

JPEG

Lai rastu atbildi uz šo jautājumu, ir jāiedziļinās formāta specifikācijās, kas ir sapludināto failu “sencis”, un jāsaprot tā struktūra. Jebkurš JPEG sākas ar parakstu 0xFF 0xD8.

Pēc šī paraksta ir pakalpojuma informācija, pēc izvēles attēla ikona un, visbeidzot, pats saspiestais attēls. Šajā formātā attēla beigas ir apzīmētas ar divu baitu parakstu 0xFF 0xD9.

PNG

Pirmos astoņus PNG faila baitus aizņem šāds paraksts: 0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A. Beigu paraksts, kas beidz datu straumi: 0x49, 0x45, 0x4E, 0x44, 0xAE, 0x42, 0x60, 0x82.

RAR

Kopīgs paraksts visiem rar arhīviem: 0x52 0x61 0x72 0x21 (Rar!). Pēc tam tiek parādīta informācija par arhīva versiju un citiem saistītiem datiem. Eksperimentāli tika noteikts, ka arhīvs beidzas ar parakstu 0x0A, 0x25, 0x25, 0x45, 0x4F, 0x46.

Formātu un to parakstu tabula:
Līmēšanas pārbaudes algoritms šajos formātos ir ļoti vienkāršs:

  1. Atrodiet sākotnējo parakstu;
  2. Atrodiet galīgo parakstu;
  3. Ja pēc galīgā paraksta nav datu, jūsu fails ir tīrs un nesatur pielikumus! Pretējā gadījumā pēc gala paraksta jāmeklē citi formāti.

GIF un PDF

PDF dokumentā var būt vairāk nekā viens EOF marķieris, piemēram, nepareizas dokumenta ģenerēšanas dēļ. Galīgo parakstu skaits GIF failā ir vienāds ar tajā esošo kadru skaitu. Pamatojoties uz šo formātu iezīmēm, ir iespējams uzlabot pievienoto failu klātbūtnes pārbaudes algoritmu.
  1. 1. punkts tiek atkārtots no iepriekšējā algoritma.
  2. 2. punkts tiek atkārtots no iepriekšējā algoritma.
  3. Kad atrodat galīgo parakstu, atcerieties tā atrašanās vietu un meklējiet tālāk;
  4. Ja šādā veidā sasniedzat pēdējo EOF marķieri, fails ir tīrs.
  5. Ja fails nebeidzas ar beigu parakstu, goto ir pēdējā atrastā beigu paraksta atrašanās vieta.
Liela atšķirība starp faila lielumu un pozīciju pēc pēdējā beigu paraksta norāda uz lipīga pielikuma klātbūtni. Atšķirība var būt vairāk nekā desmit baiti, lai gan var iestatīt arī citas vērtības.

ZIP

ZIP arhīvu īpatnība ir trīs dažādu parakstu klātbūtne: Arhīva struktūra ir šāda:
Vietējā faila galvene 1
Faila dati 1
Datu deskriptors 1
Vietējā faila galvene 2
Faila dati 2
2. datu deskriptors
...
Vietējā faila galvene
Failu dati n
Datu deskriptors n
Arhīva atšifrēšanas galvene
Arhivēt papildu datu ierakstu
Centrālais direktorijs
Visinteresantākais ir centrālais direktorijs, kurā ir metadati par arhīvā esošajiem failiem. Centrālais direktorijs vienmēr sākas ar parakstu 0x50 0x4b 0x01 0x02 un beidzas ar parakstu 0x50 0x4b 0x05 0x06, kam seko 18 baiti metadatu. Interesanti, ka tukšie arhīvi sastāv tikai no gala paraksta un 18 nulles baitiem. Pēc 18 baitiem parādās arhīva komentāru apgabals, kas ir ideāls konteiners faila slēpšanai.

Lai pārbaudītu ZIP arhīvu, jums jāatrod centrālā direktorija beigu paraksts, jāizlaiž 18 baiti un komentāru apgabalā jāmeklē zināmu formātu paraksti. Liels izmērs Komentārā norādīts arī uzlīmēšanas fakts.

Izmēram ir nozīme

AVI

AVI faila struktūra ir šāda: katrs fails sākas ar RIFF parakstu (0x52 0x49 0x46 0x46). 8. baitā ir AVI paraksts, kas norāda formātu (0x41 0x56 0x49 0x20). Bloks pie nobīdes 4, kas sastāv no 4 baitiem, satur datu bloka sākotnējo izmēru (baitu secība - mazais endians). Lai uzzinātu bloka numuru, kurā ir nākamais izmērs, jums jāpievieno galvenes izmērs (8 baiti) un 4-8 baitu blokā iegūtais lielums. Tas aprēķina kopējo faila lielumu. Ir pieļaujams, ka aprēķinātais izmērs var būt mazāks par faktisko faila lielumu. Kad izmērs ir aprēķināts, failā būs tikai nulle baiti (nepieciešams, lai izlīdzinātu 1 KB robežu).

Izmēra aprēķina piemērs:


WAV

Tāpat kā AVI, arī WAV fails sākas ar RIFF parakstu, taču šim failam ir paraksts no 8. baita — WAVE (0x57 0x41 0x56 0x45). Faila lielums tiek aprēķināts tāpat kā AVI. Faktiskajam izmēram pilnībā jāatbilst aprēķinātajam.

MP4

MP4 vai MPEG-4 ir multivides konteinera formāts, ko izmanto video un audio straumju glabāšanai, nodrošinot arī subtitru un attēlu glabāšanu.
Pie nobīdes 4 baiti ir paraksti: faila tips ftyp (66 74 79 70) (QuickTime Container File Type) un faila apakštips mmp4 (6D 6D 70 34). Par atzīšanu slēptos failus, mūs interesē iespēja aprēķināt faila lielumu.

Apskatīsim piemēru. Pirmā bloka izmērs ir nulles nobīdē, un tas ir 28 (00 00 00 1C, Big Endian baitu secība); tas arī norāda nobīdi, kur atrodas otrā datu bloka izmērs. Nobīdē 28 mēs atrodam nākamo bloka izmēru, kas vienāds ar 8 (00 00 00 08). Lai atrastu nākamo bloka izmēru, jāpievieno iepriekšējo atrasto bloku izmēri. Tādējādi tiek aprēķināts faila lielums:

MOV

Šis plaši izmantotais formāts ir arī MPEG-4 konteiners. MOV izmanto patentētu datu kompresijas algoritmu, tā struktūra ir līdzīga MP4 un tiek izmantota tiem pašiem mērķiem - audio un video datu, kā arī saistīto materiālu glabāšanai.
Tāpat kā MP4, jebkuram mov failam ir 4 baitu ftyp paraksts 4. nobīdē, tomēr nākamajam parakstam ir vērtība qt__ (71 74 20 20). Faila lieluma aprēķināšanas noteikums nav mainījies: sākot no faila sākuma, mēs aprēķinām nākamā bloka lielumu un to summējam.

Lai pārbaudītu, vai šajā formātu grupā nav “lipīgu” failu, tiek aprēķināts izmērs saskaņā ar iepriekš norādītajiem noteikumiem un salīdzināts ar pārbaudāmā faila lielumu. Ja pašreizējais faila izmērs ir daudz mazāks par aprēķināto, tas norāda uz līmēšanas faktu. Pārbaudot AVI failus, tiek pieņemts, ka aprēķinātais izmērs var būt mazāks par faila lielumu, jo apmales izlīdzināšanai ir pievienotas nulles. Šajā gadījumā pēc aprēķinātā faila lieluma ir jāpārbauda nulles.

Saliktā faila binārā formāta pārbaude

Šis Microsoft izstrādātais faila formāts ir pazīstams arī kā OLE (Object Linking and Embedding) vai COM (Component Object Model). DOC, XLS, PPT faili pieder pie CFB formātu grupas.

CFB fails sastāv no 512 baitu galvenes un vienāda garuma sektoriem, kas glabā datu straumes vai pakalpojumu informāciju. Katram sektoram ir savs nenegatīvs skaitlis, izņemot īpašos skaitļus: “-1” - numurē brīvo sektoru, "-2" - numurē sektoru, kas noslēdz ķēdi. Visas sektoru ķēdes ir definētas FAT tabulā.

Pieņemsim, ka uzbrucējs ir modificējis noteiktu .doc failu un tā beigās ielīmējis citu failu. Ir daži dažādos veidos atklāt to vai norādīt anomāliju dokumentā.

Neparasts faila lielums

Kā minēts iepriekš, jebkurš CFB fails sastāv no galvenes un vienāda garuma sektoriem. Lai uzzinātu sektora lielumu, jums ir jānolasa divu baitu skaitlis ar nobīdi 30 no faila sākuma un jāpalielina 2 līdz šī skaitļa pakāpēm. Šim skaitlim ir jābūt vienādam ar attiecīgi 9 (0x0009) vai 12 (0x000C), faila sektora lielums ir 512 vai 4096 baiti. Pēc sektora atrašanas jums jāpārbauda šāda vienlīdzība:

(FileSize — 512) mod SectorSize = 0

Ja šī vienlīdzība nav izpildīta, varat norādīt uz failu līmēšanas faktu. Tomēr šai metodei ir ievērojams trūkums. Ja uzbrucējs zina sektora lielumu, viņam vienkārši jāielīmē savs fails un vēl n baiti, lai ielīmēto datu lielums būtu vairākkārtējs sektora izmēram.

Nezināms sektora veids

Ja uzbrucējs zina par metodi, kā apiet iepriekšējo pārbaudi, tad šī metode var noteikt sektoru klātbūtni ar nedefinētiem veidiem.

Definēsim vienlīdzību:

FileSize = 512 + CountReal * SectorSize, kur FileSize ir faila izmērs, SectorSize ir sektora izmērs, CountReal ir sektoru skaits.

Mēs arī definējam šādus mainīgos:

  1. CountFat – FAT sektoru skaits. Atrodas 44 nobīdē no faila sākuma (4 baiti);
  2. CountMiniFAT – MiniFAT sektoru skaits. Atrodas nobīdē 64 no faila sākuma (4 baiti);
  3. CountDIFAT – DIFAT sektoru skaits. Atrodas nobīdē 72 no faila sākuma (4 baiti);
  4. CountDE – direktoriju ievades sektoru skaits. Lai atrastu šo mainīgo, jums jāatrod pirmais sektors DE, kas atrodas 48 nobīdē. Tad no FAT ir jāiegūst pilnīgs DE attēlojums un jāsaskaita DE sektoru skaits;
  5. CountStreams – sektoru skaits ar datu plūsmām;
  6. CountFree – brīvo sektoru skaits;
  7. CountClassified – sektoru skaits ar noteiktu tipu;
CountClassified = CountFAT + CountMiniFAT + CountDIFAT + CountDE + CountStreams + CountFree

Acīmredzot, ja CountClassified un CountReal ir nevienlīdzīgi, mēs varam secināt, ka faili var tikt sapludināti.

Mans priekšnieks man uzdeva diezgan interesantu uzdevumu. Īsā laikā uzrakstiet izpildāmo failu analizatoru, kas varētu atrast vīrusu korpusus, pamatojoties uz parakstiem, un noteikt izmantoto pakotāju/šifrētāju. Gatavais prototips parādījās pāris stundu laikā.

Autora vārds

Parakstu analīze

Ļaunprātīga objekta meklēšanu, izmantojot parakstus, var veikt jebkurš pretvīruss. Parasti paraksts ir formalizēts noteiktu pazīmju apraksts, pēc kura var noteikt, ka skenējamais fails ir vīruss un precīzi definēts vīruss.

Šeit ir dažādas tehnikas. Alternatīva ir izmantot parakstu, kas sastāv no N baitiem ļaunprātīga objekta. Šajā gadījumā jūs varat veikt nevis muļķīgu salīdzinājumu, bet gan salīdzināšanu, izmantojot kādu masku (piemēram, meklējot baitus EB ?? ?? CD 13). Vai arī iestatiet papildu nosacījumus, piemēram, “šādiem un tādiem baitiem jābūt programmas ieejas punktā” un tā tālāk. Ļaunprātīgas programmatūras paraksts ir īpašs jautājums.

Tādā pašā veidā ir aprakstītas dažas pazīmes, pēc kurām var noteikt, ka izpildāmais fails ir iepakots ar vienu vai otru šifrētāju vai pakotāju (piemēram, banālo ASPack). Ja rūpīgi izlasījāt mūsu žurnālu, tad noteikti esat dzirdējuši par tādu rīku kā PEiD, kas spēj identificēt visbiežāk izmantotos pakotājus, šifrētājus un kompilatorus (datubāzē ir liels parakstu skaits) uz to pārsūtītajam PE failam. . Diemžēl jaunas programmas versijas nav izlaistas ilgu laiku, un nesen oficiālajā vietnē parādījās ziņojums, ka projektam nebūs tālākas attīstības. Žēl, jo PEiD iespējas (īpaši ņemot vērā spraudņu sistēmu) man varētu ļoti noderēt. Pēc īsas analīzes kļuva skaidrs, ka tas nav risinājums. Bet pēc angļu valodas emuāru rakšanas es ātri atradu to, kas man ir piemērots. YARA projekts (code.google.com/p/yara-project).

Kas ir YARA?

Jau pašā sākumā biju pārliecināts, ka kaut kur internetā jau ir atvērta pirmkoda izstrāde, kas uzņemsies noteikt atbilstību starp noteiktu parakstu un pārbaudāmo failu. Ja es varētu atrast šādu projektu, tad to varētu viegli nolikt uz tīmekļa aplikācijas sliedēm, pievienot tur dažādus parakstus un iegūt to, ko no manis prasīja. Plāns sāka šķist vēl reālāks, kad izlasīju YARA projekta aprakstu.

Paši izstrādātāji to pozicionē kā rīku, kas palīdz ļaunprogrammatūras pētniekiem identificēt un klasificēt ļaunprātīgos paraugus. Pētnieks var izveidot aprakstus priekš dažādi veidiļaunprātīga programmatūra, izmantojot tekstu vai binārus modeļus, kas apraksta ļaunprātīgas programmatūras formalizētās īpašības. Tā tiek iegūti paraksti. Faktiski katrs apraksts sastāv no līniju kopas un dažas loģiskas izteiksmes, uz kuru pamata tiek noteikta analizatora iedarbināšanas loģika.

Ja pārbaudāmajai datnei ir izpildīti kāda no noteikumiem, to attiecīgi nosaka (piemēram, tāds un tāds tārps). Vienkāršs noteikuma piemērs, lai saprastu, par ko mēs runājam:

noteikums silent_banker: baņķieris
{
meta:
description = "Šis ir tikai piemērs"
pavediena_līmenis = 3
in_the_wild = patiess
stīgas:
$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"
nosacījums:
$a vai $b vai $c
}

Šajā noteikumā YARA sakām, ka jebkurš fails, kas satur vismaz vienu no parauga virknēm, kas aprakstītas mainīgajos $a, $b, $c, ir jāklasificē kā Silent_banker Trojas zirgs. Un tas ir ļoti vienkāršs noteikums. Patiesībā noteikumi var būt daudz sarežģītāki (par to mēs runāsim tālāk).
Pat to projektu saraksts, kas to izmanto, runā par YARA projekta autoritāti, un tas ir:

  • VirusTotal ļaunprātīgas programmatūras izlūkošanas pakalpojumi (vt-mis.com);
  • jsunpack-n (jsunpack.jeek.org);
  • Mēs skatāmies jūsu vietni (wewatchyourwebsite.com).

Viss kods ir rakstīts Python, un lietotājam tiek piedāvāts gan pats modulis izmantošanai to izstrādē, gan vienkārši izpildāms fails, lai izmantotu YARA kā atsevišķu lietojumprogrammu. Sava darba ietvaros es izvēlējos pirmo iespēju, taču vienkāršības labad šajā rakstā mēs vienkārši izmantosim analizatoru kā konsoles lietojumprogrammu.

Pēc nelielas rakšanas es ātri sapratu, kā uzrakstīt YARA noteikumus, kā arī pievienot vīrusu parakstus no bezmaksas programmatūras un iepakotājiem no PEiD. Bet mēs sāksim ar instalēšanu.

Uzstādīšana

Kā jau teicu, projekts ir rakstīts Python, tāpēc to var viegli instalēt operētājsistēmās Linux, Windows un Mac. Sākumā jūs varat vienkārši ņemt bināro. Ja mēs izsauksim lietojumprogrammu konsolē, mēs iegūsim palaišanas noteikumus.

$yara
lietojums: yara ... ... FILE | PID

Tas ir, programmas izsaukšanas formāts ir šāds: vispirms ir programmas nosaukums, tad opciju saraksts, pēc kura tiek norādīts fails ar noteikumiem, un pašās beigās - faila nosaukums. pārbaudīto (vai direktoriju, kurā ir faili), vai procesa identifikatoru. Tagad es gribētu labā veidā izskaidrot, kā tiek izstrādāti šie noteikumi, bet es nevēlos jūs uzreiz apgrūtināt ar sausu teoriju. Tāpēc mēs darīsim lietas savādāk un aizņemsimies citu cilvēku parakstus, lai YARA varētu veikt vienu no mūsu izvirzītajiem uzdevumiem - pilnvērtīgu vīrusu atklāšanu pēc parakstiem.

Savs antivīruss

Svarīgākais jautājums: kur iegūt zināmo vīrusu parakstu datu bāzi? Antivīrusu kompānijas savā starpā aktīvi dalās ar šādām datubāzēm (citi dāsnāk, citi mazāk). Ja godīgi, sākumā pat šaubījos, vai kaut kur internetā kāds atklāti publicēs tādas lietas. Bet, kā izrādījās, ir labi cilvēki. Piemērota datubāze no populārā ClamAV antivīrusa ir pieejama ikvienam (clamav.net/lang/en). Sadaļā "Jaunākā stabilā versija" varat atrast saiti uz jaunākā versija antivīrusu produkts, kā arī saites, lai lejupielādētu ClamAV vīrusu datu bāzes. Mūs galvenokārt interesēs faili main.cvd (db.local.clamav.net/main.cvd) un daily.cvd (db.local.clamav.net/daily.cvd).

Pirmajā ir galvenā parakstu datu bāze, otrajā ir vispilnīgākā datu bāze Šis brīdis bāze ar dažādiem papildinājumiem. Šim nolūkam pilnīgi pietiek ar Daily.cvd, kurā ir vairāk nekā 100 000 ļaunprātīgas programmatūras seansu. Tomēr ClamAV datu bāze nav YARA datu bāze, tāpēc mums tā ir jāpārvērš vēlamajā formātā. Bet kā? Galu galā mēs vēl neko nezinām ne par ClamAV formātu, ne par Yara formātu. Šī problēma jau tika atrisināta pirms mums, sagatavojot nelielu skriptu, kas pārvērš ClamAV vīrusu parakstu datu bāzi YARA noteikumu komplektā. Skriptu sauc clamav_to_yara.py, un to ir uzrakstījis Metjū Ričards (bit.ly/ij5HVs). Lejupielādējiet skriptu un konvertējiet datu bāzes:

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

Rezultātā clamav.yara failā saņemsim parakstu datu bāzi, kas būs uzreiz gatava lietošanai. Tagad izmēģināsim YARA un ClamAV datu bāzes kombināciju darbībā. Mapes skenēšana, izmantojot parakstu, tiek veikta ar vienu komandu:

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

Opcija -r norāda, ka skenēšana jāveic rekursīvi visās pašreizējās mapes apakšmapēs. Ja mapē /pentest/msf3/data bija vīrusu korpusi (vismaz tie, kas atrodas ClamAV datu bāzē), YARA nekavējoties par to ziņos. Principā tas ir gatavs parakstu skeneris. Ērtības labad es uzrakstīju vienkāršu skriptu, kas pārbaudīja ClamAV datu bāzes atjauninājumus, lejupielādēja jaunus parakstus un konvertēja tos YARA formātā. Bet tās jau ir detaļas. Viena uzdevuma daļa ir pabeigta, tagad varat sākt izstrādāt noteikumus pakotņu/šifrētāju identificēšanai. Bet, lai to izdarītu, man bija nedaudz jātiek galā ar viņiem.

Spēlē pēc noteikumiem

Tātad noteikums ir galvenais programmas mehānisms, kas ļauj piešķirt noteiktu failu noteiktai kategorijai. Noteikumi ir aprakstīti atsevišķā failā (vai failos), un pēc izskata tie ir ļoti līdzīgi struct() konstrukcijai no C/C++ valodas.

valda BadBoy
{
stīgas:
$a = "win.exe"
$b = "http://foo.com/badfi le1.exe"
$c = "http://bar.com/badfi le2.exe"
nosacījums:
$a un ($b vai $c)
}

Principā noteikumu rakstīšanā nav nekā sarežģīta. Šajā rakstā es pieskāros tikai galvenajiem punktiem, un sīkāku informāciju atradīsit rokasgrāmatā. Pagaidām desmit svarīgākie punkti:

1. Katra kārtula sākas ar atslēgvārdu kārtulu, kam seko kārtulas identifikators. Identifikatoriem var būt tādi paši nosaukumi kā mainīgajiem C/C++, tas ir, tie var sastāvēt no burtiem un cipariem, un pirmā rakstzīme nevar būt cipars. Maksimālais garums identifikatora nosaukums - 128 rakstzīmes.

2. Parasti noteikumi sastāv no divām sadaļām: definīcijas sadaļas (virknes) un nosacījumu sadaļas (nosacījums). Virkņu sadaļa norāda datus, uz kuru pamata nosacījumu sadaļa izlems, vai dotais fails atbilst noteiktiem nosacījumiem.

3. Katrai rindai virkņu sadaļā ir savs identifikators, kas sākas ar $ zīmi – kopumā kā mainīgā deklarācijai PHP. YARA atbalsta parastās ieliktās virknes dubultpēdiņas("") un heksadecimālās virknes, kas ietvertas lencēm(()), kā arī regulāras izteiksmes:

$my_text_string = "tekst šeit"
$my_hex_string = ( E2 34 A1 C8 23 FB )

4. Nosacījumu sadaļā ir visa noteikuma loģika. Šajā sadaļā ir jābūt Būla izteiksmei, kas nosaka, kad fails vai process atbilst kārtulai. Parasti šī sadaļa attiecas uz iepriekš deklarētām rindām. Un virknes identifikators tiek uzskatīts par Būla mainīgo, kas atgriež patieso vērtību, ja virkne tika atrasta faila vai procesa atmiņā, un false pretējā gadījumā. Iepriekš minētais noteikums nosaka, ka faili un procesi, kas satur virkni win.exe un vienu no diviem URL, ir jāklasificē kā BadBoy (pēc kārtulas nosaukuma).

5. Heksadecimālās virknes pieļauj trīs konstrukcijas, kas padara tās elastīgākas: aizstājējzīmes, lēcienus un alternatīvas. Aizvietojumi ir vietas virknē, kuras nav zināmas un kuras var aizstāt ar jebkuru vērtību. Tie ir apzīmēti ar simbolu “?”:

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

Šī pieeja ir ļoti ērta, norādot virknes, kuru garums ir zināms, bet saturs var atšķirties. Ja daļa no virknes var būt dažāda garuma, ir ērti izmantot diapazonus:

$hex_string = ( F4 23 62 B4 )

Šis ieraksts nozīmē, ka rindas vidū var būt no 4 līdz 6 dažādiem baitiem. Varat arī īstenot alternatīvu izvēli:

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

Tas nozīmē, ka trešā baita vietā var būt 62 B4 vai 56, šāds ieraksts atbilst rindām F42362B445 vai F4235645.

6. Lai pārbaudītu, vai dotā virkne atrodas noteiktā nobīdē failā vai procesa adrešu telpā, tiek izmantots operators at:

$a par 100 un $b par 200

Ja virkne var atrasties noteiktā adrešu diapazonā, tiek izmantots operators in:

$a collas (0..100) un $b collas (100..fi izmērs)

Dažreiz rodas situācijas, kad ir jānorāda, ka failā ir jābūt noteiktam skaitam no dotās kopas. Tas tiek darīts, izmantojot operatoru:

Piemēra noteikums1
{
stīgas:
$foo1 = "manekens1"
$foo2 = "manekens2"
$foo3 = "manekens3"
nosacījums:
2 no ($foo1,$foo2,$foo3)
}

Iepriekš minētais noteikums nosaka, ka failā ir jāietver jebkuras divas rindas no kopas ($foo1, $foo2, $foo3). Tā vietā, lai norādītu konkrētu rindiņu skaitu failā, varat izmantot mainīgos jebkuru (vismaz vienu rindiņu no dotās kopas) un visas (visas rindas no noteiktas kopas).

7. Pēdējā interesantā iespēja, kas jāapsver, ir viena nosacījuma piemērošana daudzām rindām. Šī funkcija ir ļoti līdzīga operatoram of, tikai jaudīgāks ir operators for..of:

virknes_kopas izteiksmei: (būla_izteiksme)

Šis ieraksts ir jālasa šādi: no virknēm, kas norādītas virknes_ kopā, vismaz izteiksmes daļām ir jāatbilst Būla_izteiksmes nosacījumam. Vai, citiem vārdiem sakot: Būla_izteiksme tiek novērtēta katrai virknei virknes_kopā, un tās izteiksmēm ir jāatgriež True. Tālāk mēs aplūkosim šo konstrukciju, izmantojot konkrētu piemēru.

PEiD izveide

Tātad, kad ar noteikumiem viss ir kļuvis vairāk vai mazāk skaidrs, mēs varam sākt savā projektā ieviest iepakotāju un šifrētāju detektoru. Sākumā kā izejmateriālu aizņēmos no tā paša PEiD pazīstamu iepakotāju parakstus. Spraudņu mapē ir fails userdb.txt, kurā ir mums nepieciešamais. Manā datubāzē bija 1850 paraksti.

Diezgan daudz, tāpēc, lai tos pilnībā importētu, iesaku uzrakstīt kaut kādu skriptu. Šīs datu bāzes formāts ir vienkāršs – tiek izmantots parastais teksta fails, kurā tiek glabāti šādi ieraksti:


paraksts = 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 = patiess

Pirmajā rindā ir norādīts iepakotāja nosaukums, kas tiks parādīts PEiD, bet mums tas būs kārtulas identifikators. Otrais ir pats paraksts. Trešais ir karodziņš ep_only, kas norāda, vai meklēt noteiktu rindu tikai ievades punkta adresē vai visā failā.

Nu, mēģināsim izveidot noteikumu, teiksim, ASPack? Kā izrādās, tajā nav nekā sarežģīta. Vispirms izveidosim failu kārtulu glabāšanai un nosauksim to, piemēram, packers.yara. Pēc tam mēs meklējam PEiD datu bāzē visus parakstus, kuru nosaukumos ir iekļauts ASPack, un pārsūtām tos uz noteikumu:

noteikums ASPack
{
stīgas:
$ = ( 60 E8 ?? ?? ?? ?? 5D 81 ED ?? ?? (43 | 44) ?? B8 ??
$ = ( 60 EB ?? 5D EB ?? FF ?? ??? ?? ?? E9 )
[.. griezt..]
$ = ( 60 E8 03 00 00 00 E9 EB 04 5D 45 55 C3 E8 01 )
nosacījums:
jebkuram no tiem: ($ieejas punktā)
}

Visiem atrastajiem ierakstiem karodziņš ep_only ir iestatīts uz patiesu, tas ir, šīm rindām jāatrodas ieejas punkta adresē. Tāpēc mēs rakstām šādu nosacījumu: “jebkuram no tiem: ($ieejas punktā)”.

Tādējādi, ja ieejas punkta adresē ir vismaz viena no norādītajām rindām, tas nozīmēs, ka fails ir iesaiņots ar ASPack. Lūdzu, ņemiet vērā arī to, ka šajā noteikumā visas rindas ir norādītas, vienkārši izmantojot $ zīmi, bez identifikatora. Tas ir iespējams, jo nosacījumu sadaļā mēs nepiekļūstam nevienam konkrētam, bet izmantojam visu komplektu.

Lai pārbaudītu iegūtās sistēmas funkcionalitāti, vienkārši palaidiet komandu konsolē:

$ yara -r packers.yara somefi le.exe

Iebarojot tur pāris aplikācijas, kas iepakotas ar ASPack, pārliecinājos, ka viss nostrādāja!

Gatavs prototips

YARA izrādījās ārkārtīgi skaidrs un caurspīdīgs rīks. Man nebija grūti uzrakstīt tam tīmekļa administratoru un iestatīt, lai tas darbotos kā tīmekļa pakalpojums. Ar nelielu radošumu analizatora sausie rezultāti jau ir iekrāsoti dažādās krāsās, norādot uz atklātās ļaunprogrammatūras bīstamības pakāpi. Neliels datu bāzes atjauninājums un daudziem šifrētājiem ir pieejams īss apraksts un dažreiz pat izpakošanas instrukcijas. Prototips ir izveidots un darbojas nevainojami, un priekšnieki sajūsmā dejo!

Funkcijas kods (FC) telegrammas galvenē identificē telegrammas veidu, piemēram, Pieprasījuma telegramma (Pieprasījums vai Sūtīt/Pieprasījums) un Apstiprinājuma vai Atbildes telegramma (Apstiprinājuma rāmis, Atbildes rāmis). Turklāt funkcijas kods satur faktisko pārraides funkciju un vadības informāciju, kas novērš ziņojumu zudumu un dublēšanos, vai stacijas tipu ar FDL statusu.

7 6 5 4 3 2 1 0 FC: funkcijas koda pieprasījums
1 Pieprasīt telegrammu
X FCV = ieslēgts maiņstrāvas bits
X href=”http://profibus.felser.ch/en/funktionscode.htm#aufruffolgebit”>FCB = mainīgs bits (no kadru skaita)
1 0 (0x0) CV = pulksteņa vērtība ()
1 cits Rezervēts
0 0 (0x0) TE = laika notikums (pulksteņa sinhronizācija)
0 3 (0x3) SDA_LOW = Sūtīt datus apstiprināts — zema prioritāte
0 4 (0x4) SDN_LOW = Sūtīt datus nav apstiprināts — zema prioritāte
0 5 (0x5) SDA_HIGH = Sūtīt datus apstiprināts — augsta prioritāte
0 6 (0x6) SDN_HIGH = Sūtīt datus nav apstiprināts
0 7 (0x7) MSRD = Sūtīt pieprasījuma datus ar multiraides atbildi
0 9 (0x9) Pieprasīt FDL statusu
0 12(0xC) SRD zems = Sūtīt un pieprasīt datus
0 13(0xD) SRD high = Sūtīt un pieprasīt datus
0 14(0xE) Pieprasīt Ident ar atbildi
0 15 (0xF) Pieprasīt LSAP statusu ar atbildi 1)
0 cits Rezervēts

1) šī vērtība standarta pēdējā versijā vairs nav definēta, bet tikai rezervēta

7 6 5 4 3 2 1 0 FC: funkcijas koda atbilde
0 Atbildes telegramma
0 Rezervēts
0 0 Vergs
0 1 Meistars nav gatavs
1 0 Meistars gatavs, bez marķiera
1 1 Meistars gatavs, žetonu gredzenā
0 (0x0) labi
1 (0x1) UE = lietotāja kļūda
2 (0x2) RR = nav resursu
3 (0x3) RS = SAP nav iespējots
8 (0x8) DL = zemi dati (parasts gadījums ar DP)
9 (0x9) NR = nav gatavi atbildes dati
10(0xA) DH = augsti dati (DP diagnoze gaida)
12(0xC) RDL = dati nav saņemti un dati zemi
13(0xD) RDH = dati nav saņemti un dati ir augsti
cits Rezervēts

Kadru skaita bits Kadru skaitīšanas bits FCB (b5) novērš ziņojuma dublēšanos no apstiprinājuma vai atbildes stacijas (atbildētāja) un izsaucēja stacijas (iniciatora) jebkādu zudumu. Šeit nav iekļauti pieprasījumi bez apstiprinājuma (SDN) un FDL statusa, identifikācijas un LSAP statusa pieprasījumi.

Drošības secībai iniciatoram ir jābūt FCB katram atbildētājam. Kad pieprasījuma telegramma (pieprasījums vai sūtīšana/pieprasījums) tiek nosūtīta atbildētājam pirmo reizi vai ja tā tiek nosūtīta atkārtoti atbildētājam, kas pašlaik ir atzīmēts kā nedarbojas, FCB ir jāiestata tā, kā norādīts atbildētājā. Ierosinātājs to sasniedz pieprasījuma telegrammā ar FCV=0 un FCB=1. Reaģētājam ir jānovērtē šāda veida telegramma kā pirmais ziņojuma cikls un jāsaglabā FCB=1 kopā ar iniciatora adresi (SA) (skatīt nākamo tabulu). Šo ziņojumu ciklu iniciators neatkārtos. Nākamajās pieprasījuma telegrammās tam pašam atbildētājam iniciatoram jāiestata FCV=1 un jāmaina FCB ar katru jaunu pieprasījuma telegrammu. Ikvienam atbildētājam, kurš saņem pieprasījuma telegrammu, kas tai adresēta ar FCV=1, ir jānovērtē FCB. Ja FCB ir mainījies, salīdzinot ar pēdējo pieprasījuma telegrammu no tā paša iniciatora (tā paša SA), tas ir derīgs apstiprinājums, ka iepriekšējais ziņojuma cikls tika pabeigts pareizi. Ja Pieprasījuma telegramma nāk no cita iniciatora (dažādas SA), FCB novērtējums vairs nav nepieciešams. Abos gadījumos atbildētājam ir jāsaglabā FCB ar avota SA, līdz tiek saņemta jauna tam adresēta telegramma. Pazaudēta vai bojāta apstiprinājuma vai atbildes telegrammas gadījumā iniciators nedrīkst mainīt FCB, atkārtojot pieprasījumu: tas norāda, ka iepriekšējais ziņojuma cikls bija kļūdains. Ja atbildētājs saņem pieprasījuma telegrammu ar FCV=1 un tādu pašu FCB kā pēdējā Pieprasījuma telegramma no tā paša iniciatora (tā paša SA), tas norāda uz pieprasījuma atkārtotu mēģinājumu. Atbildētājam, savukārt, ir atkārtoti jāpārsūta gatavībā turētā apstiprinājuma vai atbildes telegramma. Līdz iepriekš minētajam apstiprinājumam vai telegrammas saņemšanai ar citu adresi (SA vai DA), kas nav apstiprināta (Sūtīt datus bez apstiprinājuma, SDN), atbildētājam ir jāsaglabā pēdējā apstiprinājuma vai atbildes telegramma, lai varētu veikt atkārtotu pieprasījumu. . Pieprasījuma telegrammu gadījumā, kas nav apstiprinātas un ar Pieprasījuma FDL statusu, Identitāti un LSAP statusu, FCV=0 un FCB=0; atbildētāja novērtējums vairs nav nepieciešams.

b5 b4 Bitu pozīcija
FCB FCV Stāvoklis Nozīme Darbība
0 0 DA = TS/127 Pieprasījums bez apstiprinājuma
Pieprasīt FDL statusu/ Ident/LSAP statusu
Dzēst pēdējo apstiprinājumu
0/1 0/1 DA#TS Pieprasījums citam atbildētājam
1 0 DA = TS Pirmais pieprasījums FCBM:= 1
SAM:=SA
Dzēst pēdējo apstiprinājumu/atbildi
0/1 1 DA = TS
SA = SAM
FCB #FCBM
Jauns pieprasījums Dzēst pēdējo apstiprinājumu/atbildi
FCBM:=FCB
Turiet apstiprinājumu/atbildi gatavībā atkārtotam mēģinājumam
0/1 1 DA = TS
SA = SAM
FCB = FCBM
Mēģiniet vēlreiz Pieprasīt FCBM:=FCB
Atkārtojiet apstiprinājumu / atbildi un turpiniet būt gatavībā
0/1 1 DA = TS
SA#SAM
Jauns iniciators FCBM:=FCB
SAM:= SA Turiet apstiprinājumu/atbildi gatavībā atkārtotam mēģinājumam

FCBM saglabātā FCB atmiņā SAM saglabātā SA atmiņā




Tops