Skapa en anpassad känd filtyp för R-Studio. Bestämma en filtyp genom signatur Vad är en filsignatur
Konceptet " Magiskt nummer"i programmering har tre betydelser:
- Datasignatur
- Vald unika värden, som inte ska vara samma som andra värden (t.ex. UUID)
- Dålig programmeringsövning.
Datasignatur
Magiskt nummer, eller signatur, - ett heltal eller en textkonstant som används för att unikt identifiera en resurs eller data. En sådan siffra i sig har ingen betydelse och kan orsaka förvirring om den förekommer i programkoden utan lämplig kontext eller kommentar, medan ett försök att ändra det till ett annat, även ett nära i värde, kan leda till helt oförutsägbara konsekvenser. Av denna anledning kallades sådana siffror ironiskt nog magiska siffror. För närvarande är detta namn fast etablerat som en term. Till exempel börjar alla kompilerade Java-språkklasser med det hexadecimala "magiska numret" 0xCAFEBABE. Det andra allmänt kända exemplet är något körbar fil OS Microsoft Windows med tillägget .exe börjar med bytesekvensen 0x4D5A (som motsvarar ASCII-tecknen MZ - initialerna för Mark Zbikowski, en av skaparna av MS-DOS). Ett mindre känt exempel är den oinitierade pekaren i Microsoft Visual C++ (sedan 2005 års version av Microsoft Visual Studio), som har adressen 0xDEADBEEF i felsökningsläge.
I UNIX-liknande operativsystem Filtypen bestäms vanligtvis av filsignaturen, oavsett filnamnstillägget. De tillhandahåller ett standardfilverktyg för att tolka filsignaturen.
Dålig programmeringsövning
Även kallat "magiska siffror" är en dålig programmeringspraxis när ett numeriskt värde förekommer i källtexten och det inte är uppenbart vad det betyder. Till exempel skulle ett utdrag som detta, skrivet i Java, vara dåligt:
drawSprite(53, 320, 240);
final int SCREEN_WIDTH = 640 ; final int SCREEN_HEIGHT = 480 ; final int SCREEN_X_CENTER = SCREEN_WIDTH / 2 ; final int SCREEN_Y_CENTER = SCREEN_HEIGHT / 2 ; final int SPRITE_CROSSHAIR = 53 ; ... drawSprite(SPRITE_CROSSHAIR, SCREEN_X_CENTER, SCREEN_Y_CENTER);
Nu är det klart: den här linjen visar en sprite - siktets hårkors - i mitten av skärmen. I de flesta programmeringsspråk kommer alla värden som används för sådana konstanter att beräknas vid kompilering och ersättas på de platser där värdena används. Därför försämrar inte en sådan ändring i källtexten programmets prestanda.
Dessutom är magiska siffror en potentiell källa till fel i ett program:
- Om samma magiska nummer används mer än en gång i ett program (eller potentiellt skulle kunna användas), kommer en ändring av det att kräva redigeringar av varje förekomst (istället för bara en redigering av värdet på den namngivna konstanten). Om inte alla förekomster korrigeras kommer minst ett fel att uppstå.
- I åtminstone en av händelserna kan det magiska numret vara felstavat initialt, och detta är ganska svårt att upptäcka.
- Det magiska numret kan bero på en implicit parameter eller ett annat magiskt tal. Om dessa beroenden, som inte uttryckligen identifierats, inte är uppfyllda, kommer minst ett fel att inträffa.
- När du ändrar förekomster av ett magiskt nummer är det möjligt att av misstag ändra ett annat magiskt nummer som är oberoende men har samma numeriska värde.
Magiska siffror och plattformsoberoende
Ibland skadar magiska siffror plattformsoberoende kod. Faktum är att i C, på 32- och 64-bitars operativsystem, är storleken på char , short och long long-typerna garanterad, medan storleken på int , long , size_t och ptrdiff_t kan ändras (för de två första, beroende på kompilatorutvecklarnas preferenser för de två sista - beroende på målsystemets bitkapacitet). I gammal eller dåligt skriven kod kan det finnas "magiska siffror" som indikerar storleken på en typ - när man flyttar till maskiner med en annan bitkapacitet kan de leda till subtila fel.
Till exempel:
const size_t NUMBER_OF_ELEMENTS = 10 ; långa [NUMBER_OF_ELEMENTS]; memset(a, 0, 10 * 4); // incorrect - long antas vara 4 byte, magiskt antal element används memset(a, 0, NUMBER_OF_ELEMENTS * 4); // incorrect - long antas vara 4 byte memset(a, 0, NUMBER_OF_ELEMENTS * sizeof(long)); // inte helt korrekt - duplicering av typnamnet (om typen ändras måste du ändra det här också) memset (a , 0 , NUMBER_OF_ELEMENTS * storleken på (a [ 0 ])); // korrekt, optimal för dynamiska arrayer med en storlek som inte är noll memset(a, 0, storleken på(a)); // korrekt, optimal för statiska arrayer
Siffror som inte är magiska
Alla tal behöver inte omvandlas till konstanter. Till exempel koden för
Sök genom att skanna filer av kända typer (eller, som det ofta sägs, söka efter filer med signatur) är en av de mest effektiva som används i R-Studios dataåterställningsverktyg. Genom att använda en given signatur kan du återställa filer av en viss typ i de fall information om katalogstruktur och filnamn delvis eller helt saknas (skadad).
Vanligtvis används diskpartitionstabellen för att bestämma platsen för filer. Om du jämför en disk med en bok kommer partitionstabellen att likna dess innehållsförteckning. Vid skanning söker R-Studio efter kända filtyper i diskpartitionstabellen med hjälp av vissa specificerade signaturer. Detta möjliggörs av det faktum att praktiskt taget varje filtyp har en unik signatur eller datamönster. Filsignaturer finns på en specifik plats i början av filen och i många fall även i slutet av filen. Vid skanning matchar R-Studio hittade data med signaturer av kända filtyper, vilket gör att de kan identifieras och deras data återskapas.
Genom att använda teknik för att skanna kända filtyper, låter R-Studio dig återställa data från diskar som har formaterats om och vars partitionstabeller har skrivits över. Dessutom, om en diskpartition skrivs över, skadas eller raderas, så är genomsökning av kända filtyper det enda alternativet.
Men nästan allt har sina nackdelar, och de kända filtyperna som används i R-Studio är inget undantag. Så, när du skannar kända filtyper, låter R-Studio dig endast återställa ofragmenterade filer, men, som redan nämnts, är detta i de flesta fall den senaste möjliga metoden.
R-Studio innehåller redan signaturer av de vanligaste filtyperna (vy full lista filer av kända typer finns i avsnittet R-Studio onlinehjälp.)
Om det behövs kan användaren lägga till nya filtyper till R-Studio. Till exempel, om du behöver hitta filer av en unik typ, eller de som utvecklats efter det senaste releasedatumet av R-Studio, kan du lägga till dina egna signaturer till filerna av kända typer. Denna process kommer att diskuteras härnäst.
Anpassade filer av kända typer
Anpassade filsignaturer av kända filtyper lagras i XML-fil e anges i dialogrutan Inställningar. Att lägga till en signatur består av två delar:
- Fastställande av filsignaturen som finns i början av filen och, om sådan finns, i slutet av filen.
- Generera en XML-fil som innehåller en filsignatur och annan information om filtypen.
Allt detta kan göras med R-Studio. Samtidigt behöver du inte vara expert inom området att komponera (redigera) XML-dokument eller inom området hexadecimal redigering - i denna guide (artikel), som riktar sig till användaren själv nybörjarnivå, kommer alla steg i denna process att diskuteras i detalj.
Exempel: Lägga till en signatur för en MP4-fil (XDCam-EX Codec)
Låt oss titta på att lägga till en filsignatur med exemplet på en .MP4-fil skapad med Sony XDCAM-EX. Du kan använda den till exempel vid skada på SD-kortet för filer som du ännu inte har lyckats spara på din dators hårddisk.
Första steget: Fastställande av filsignatur
För att fastställa filsignaturen, överväg exempel på filer av samma format.
Låt dessa vara fyra videofiler från Sony XDCAM-EX:
ZRV-3364_01.MP4
ZRV-3365_01.MP4
ZRV-3366_01.MP4
ZRV-3367_01.MP4
För att underlätta övervägandet, låt dessa vara små filer. Större filer är svårare att se hexadecimalt.
1. Öppna filerna i R-Studio. För att göra detta, högerklicka på varje fil och välj Visa/Redigera från snabbmenyn.
2. Låt oss jämföra filerna. Vi kommer att leta efter samma mönster som finns i alla fyra filerna. Han kommer att dyka upp filsignatur. Vanligtvis hittas filsignaturer i början av filen, men ibland i slutet.
3. Definiera filsignaturen i början av filen. I vårt exempel finns den i början av filen. Observera att detta inte alltid händer - ofta finns filsignaturen i början av filen, men inte på den första raden (offset).
Av bilderna nedan framgår det att innehållet i alla fyra filer är olika, men de börjar alla med samma filsignatur. 
Klicka på bilden för att förstora den
Klicka på bilden för att förstora den
Klicka på bilden för att förstora den
Klicka på bilden för att förstora den
Det markerade området i bilderna är en filsignatur av denna typ filer. Den presenteras i både text och hexadecimalt format.
I textform ser filsignaturen ut så här:
....ftypmp42....mp42........gratis
Prickar (“.”) indikerar tecken som inte kan representeras i textform. Därför är det också nödvändigt att tillhandahålla filsignaturens hexadecimala form:
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. På samma sätt definierar vi filsignaturen, men i slutet av filen. Det kan vara en annan filsignatur, en annan längd.
Bilderna nedan markerar filsignaturen i slutet av filen: 
Klicka på bilden för att förstora den
Klicka på bilden för att förstora den
Klicka på bilden för att förstora den
Klicka på bilden för att förstora den
Observera att data före det valda området (filsignatur) är samma i alla fyra filerna. Detta är teknisk information som inte är en filsignatur, utan indikerar att alla fyra bilderna (filerna) togs med samma kamera med samma parametrar. Det är vanligtvis möjligt att skilja matchande mönster med teknisk information från en filsignatur. I vårt exempel, på sista raden före starten av filsignaturen, ser vi texten 'RecordingMode type="normal"', vilket tydligt indikerar att detta är någon slags filparameter, och inte en signatur. Var alltid särskilt uppmärksam på denna rad för att inte felaktigt inkludera teknisk information del av filsignaturen.
I vårt fall är filsignaturen följande text:
...
Låt oss påminna dig om att prickar indikerar tecken som inte kan representeras i textform.
I hexadecimal ser filsignaturen ut så här:
3N 2F 4E 6F 6E 52 65 61 6N 54 69 6A 65 4A 65 74 61 3E 0D 0A 00
Observera: signaturen kommer inte alltid att finnas i slutet av filen.
Andra steget: Skapa en XML-fil som beskriver en känd filtyp
Nu, efter att ha definierat filsignaturen, kan du skapa en XML-fil och inkludera motsvarande filtyp i R-Studio. Detta kan göras på två sätt:
2.1 Använda inbyggd grafikredigerare filsignaturer:
Välj alternativet Inställningar på menyn Verktyg, i dialogrutan Inställningar som öppnas, klicka på fliken Kända filtyper och klicka sedan på knappen Redigera användarens filtyper. 
Klicka på bilden för att förstora den
Klicka på knappen Skapa filtyp i dialogrutan Redigera användares filtyper.
Ställ in följande alternativ:
- Id - en unik digital identifierare. Detta nummer kommer att väljas slumpmässigt; Det enda är att det inte ska matcha den digitala identifieraren för någon annan filtyp.
- Gruppbeskrivning - gruppen där de hittade filerna kommer att finnas i R-Studio. Du kan ställa in antingen ny grupp, eller välj en av de som redan finns. För oss blir detta gruppen "Multimedia Video (Multimedia: Video)".
- Beskrivning - kort beskrivning filtyp. I vårt exempel kan du använda till exempel "Sony cam video, XDCam-EX".
- Extension - förlängning av filer av denna typ. I vårt fall - mp4.
Parametern Funktioner är valfri, i vårt fall behöver vi inte använda den. 
Klicka på bilden för att förstora den
Därefter måste du ange start- och slutfilsignaturen. För att göra detta, välj Börja och sedan in innehållsmeny kommandot Lägg till signatur. 
Klicka på bilden för att förstora den
Dubbelklicka sedan på fältet<пустая сигнатура> (
Klicka på bilden för att förstora den
Skapa sedan den slutliga filsignaturen. Var noga med att ange 21 i kolumnen Från. 
Klicka på bilden för att förstora den
Du har skapat din egen signatur för kända filtyper.
Nu måste du spara den. Det finns två sätt: du kan antingen spara den till standardfilen som anges på huvudfliken i dialogrutan Inställningar genom att klicka på knappen Spara. Eller klicka på knappen Spara som... och spara signaturen i någon annan fil.
2.2 Skapa manuellt en XML-fil som beskriver en känd filtyp:
För att skapa den här filen Låt oss använda XML version 1.0 och UTF-8-kodning. Misströsta inte om du inte vet vad det är - öppna bara någon textredigerare(till exempel Notepad.exe) och skriv in följande text på första raden:
Därefter kommer vi att skapa en XML-tagg som definierar filtypen (FileType). Med hänsyn till de tidigare beskrivna XML-attributen kommer taggen att se ut så här:
Låt oss sätta in det direkt efter
Därefter definierar vi filsignaturen (tagg
Om det finns måste du också definiera slutsignaturen (i slutet av filen). Detta använder samma tagg, men med ett "från"-element och ett "slut"-attribut. Det kommer att se ut så här:
Kom ihåg att den slutliga filsignaturen inte innehöll icke-texttecken, men innehöll snedstreck och triangelparenteser. För att undvika förvirring och fel i XML-syntaxen kommer vi att ersätta tecknen "/", " i signaturen<" и ">" deras hexadecimala värden.
I slutet, efter filsignaturerna, måste det finnas stängningstaggar FileType och FileTypeList:
Så hela filen ska se ut så här:
Kom ihåg: XML-syntax är skiftlägeskänslig, så rätt tagg skulle vara det
Låt oss spara filen i textformat med filtillägget .xml. Till exempel: SonyCam.xml.
Vi har framgångsrikt skapat vår egen signatur för kända filtyper. Detta exempel är helt tillräckligt för att förstå de grundläggande principerna för att skapa en anpassad filtyp. Mer erfarna användare kan använda XML version 2.0. Du kan läsa mer om detta i avsnittet R-Studio onlinehjälp.
Steg 3: Kontrollera och lägga till en fil som beskriver en känd filtyp
Nästa steg är att lägga till (ladda upp) din XML-fil till R-Studio. I det här fallet kommer det att kontrolleras automatiskt.
Låt oss ladda XML-filen som skapades i föregående steg i R-Studio. För att göra detta, välj alternativet Inställningar i menyn Verktyg. I området Användares filtyper på huvudfliken i dialogrutan Inställningar lägger du till XML-filen vi skapade (SonyCam.xml). Klicka på knappen Använd. 
Klicka på bilden för att förstora den
2. Svara Ja på begäran om att ladda ner en ny filtyp. 
Klicka på bilden för att förstora den
3. För att verifiera att filtypen har laddats, klicka på fliken Kända filtyper i dialogrutan Inställningar. Kom ihåg att vi lade till filtypen i gruppen Multimedia Video (Multimedia: Video). Efter att ha utökat denna grupp (mapp) bör vi se ett element med beskrivningen vi angav när vi skapade XML-filen: Sony cam video, XDCam-EX (.mp4). 
Klicka på bilden för att förstora den
Klicka på bilden för att förstora den
Om det finns några fel i filsyntaxen kommer du att se ett motsvarande meddelande: 
Klicka på bilden för att förstora den
I det här fallet, kontrollera din XML-fil igen för fel. Kom ihåg: XML-syntax är skiftlägeskänslig och varje tagg måste ha en avslutande tagg i slutet.
Steg 4: Testa filen som beskriver en känd filtyp
För att kontrollera riktigheten av den anpassade filtypen vi skapade, låt oss försöka hitta våra .mp4-filer på ett flyttbart USB-minne.
1. Under Windows Vista eller Windows 7, utför en fullständig (inte snabb) formatering av disken eller använd ett verktyg för rensning av diskutrymme (till exempel R-Wipe & Clean) för att fullständigt avlägsnande all data tillgänglig på disken. Låta USB-disk formaterad i FAT32 (storleken på de sökta filerna överstiger inte 2 GB).
2. Låt oss kopiera det testfiler till disk och starta om datorn så att innehållet i cacheminnet sparas på disken. Du kan också inaktivera extern enhet och anslut sedan den igen.
3. I operativsystemet kommer enheten att definieras som till exempel logisk enhet F:\.
4. Låt oss starta R-Studio. Välj vår enhet (F:\) och klicka på knappen Skanna 
Klicka på bilden för att förstora den
5. I dialogrutan Skanna, i området (Filsystem), klicka på knappen Ändra... och avmarkera alla rutorna. På så sätt kommer vi att inaktivera sökning efter filsystem och filer med hjälp av partitionstabellen. 
Klicka på bilden för att förstora den
6. Markera kryssrutan Extra sökning efter kända filtyper. Detta gör att R-Studio kan söka efter kända filtyper vid skanning.
7. För att börja skanna, klicka på knappen Skanna.
8. Låt oss vänta medan R-Studio skannar disken. Fliken Skanningsinformation visar skanningsförloppet (förloppet). 
Klicka på bilden för att förstora den
9. När skanningen är klar, välj elementet Extra Found Files och dubbelklicka på det. 
Klicka på bilden för att förstora den
10. Våra testfiler kommer att finnas i Sony cam-videon, XDCam-EX-mappen (eller i en mapp med ett annat namn som motsvarar filtypsbeskrivningen som anges i det andra steget). 
Klicka på bilden för att förstora den
Du ser att filnamn, datum och platser (mappar) inte återställdes pga denna informationen lagras i filsystemet. Därför kommer R-Studio automatiskt att visa varje fil med ett nytt namn.
Det är dock tydligt att innehållet i filerna inte är skadat. För att verifiera detta, låt oss öppna dem i lämpligt program, till exempel VLC mediaspelare. 
Klicka på bilden för att förstora den
Slutsats
R-Studios förmåga att skanna efter kända filtyper gör att du kan återställa data även från en disk vars filsystem antingen har skrivits över. Du kan söka efter filer ganska effektivt med hjälp av deras signaturer, vilket är särskilt användbart om du vet exakt vilken typ av filer som återställs, som i vårt exempel. Möjligheten att skapa anpassade filtyper låter dig lägga till vilken fil som helst som har en specifik filsignatur till listan över kända filtyper.
Många kanske har hört talas om filer som rarjpeg. Det här är en speciell typ av fil, som är en jpeg-bild och ett rar-arkiv tätt limmade. Det är en utmärkt behållare för att dölja det faktum att information överförs. Du kan skapa en rarjpeg med följande kommandon:
UNIX: cat image1.jpg archive.rar > image2.jpg
WINDOWS: kopiera /b bild1.jpg+arkiv.rar bild2.jpg
Eller om du har en hex-editor.
Naturligtvis, för att dölja faktumet att överföra information, kan du använda inte bara JPEG-formatet, utan också många andra. Varje format har sina egna egenskaper, på grund av vilka det kan eller kanske inte är lämpligt för rollen som container. Jag kommer att beskriva hur du kan hitta inklistrade filer i de mest populära formaten eller indikera limning.
Metoder för att upptäcka sammanslagna filer kan delas in i tre grupper:
- Metod för att kontrollera området efter EOF-markören. Många populära filformat har en så kallad end-of-file-markör, som ansvarar för att visa önskad data. Till exempel läser fotovisare alla byte upp till denna markör, men området efter den ignoreras. Denna metod är idealisk för följande format: JPEG, PNG, GIF, ZIP, RAR, PDF.
- Metod för att kontrollera filstorleken. Strukturen för vissa format (ljud- och videobehållare) gör att du kan beräkna den faktiska filstorleken och jämföra den med den ursprungliga storleken. Format: AVI, WAV, MP4, MOV.
- Metod för att kontrollera CFB-filer. CFB eller Compound File Binary Format är ett dokumentformat utvecklat av Microsoft, som är en behållare med ett eget filsystem. Denna metod är baserad på att upptäcka anomalier i en fil.
Finns det liv efter slutet av en fil?
JPEG
För att hitta svaret på denna fråga är det nödvändigt att fördjupa sig i specifikationerna för formatet, som är "förfadern" till sammanslagna filer och förstå dess struktur. Alla JPEG-filer börjar med signaturen 0xFF 0xD8.Efter denna signatur finns serviceinformation, eventuellt en bildikon och slutligen själva den komprimerade bilden. I detta format markeras slutet av bilden med en tvåbytesignatur 0xFF 0xD9.
PNG
De första åtta byten i PNG-filen upptas av följande signatur: 0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A. Slutsignatur som avslutar dataströmmen: 0x49, 0x45, 0x4E, 0x44, 0xAE, 0x42, 0x60, 0x82.RAR
Gemensam signatur för alla rar-arkiv: 0x52 0x61 0x72 0x21 (Rar!). Efter det kommer information om arkivversionen och annan relaterad data. Det bestämdes experimentellt att arkivet slutar med signaturen 0x0A, 0x25, 0x25, 0x45, 0x4F, 0x46.Tabell över format och deras signaturer:
Algoritmen för att kontrollera limning i dessa format är extremt enkel:
- Hitta den första signaturen;
- Hitta den slutliga signaturen;
- Om det inte finns några data efter den slutliga signaturen är din fil ren och innehåller inga bilagor! Annars är det nödvändigt att leta efter andra format efter den slutliga signaturen.
GIF och PDF
Ett PDF-dokument kan ha mer än en EOF-markör, till exempel på grund av felaktig dokumentgenerering. Antalet slutliga signaturer i en GIF-fil är lika med antalet ramar i den. Baserat på funktionerna i dessa format är det möjligt att förbättra algoritmen för att kontrollera förekomsten av bifogade filer.- Punkt 1 upprepas från föregående algoritm.
- Punkt 2 upprepas från föregående algoritm.
- När du hittar den slutliga signaturen, kom ihåg dess plats och leta vidare;
- Om du når den sista EOF-markören på detta sätt är filen ren.
- Om filen inte slutar med en slutsignatur, är goto platsen för den senast hittade slutsignaturen.
blixtlås
Det speciella med ZIP-arkiv är närvaron av tre olika signaturer: Arkivets struktur är som följer:| Lokal filhuvud 1 |
| Fildata 1 |
| Databeskrivning 1 |
| Lokal filhuvud 2 |
| Fildata 2 |
| Data Descriptor 2 |
| ... |
| Lokal filhuvud |
| Fil Data n |
| Data Descriptor n |
| Arkivdekrypteringshuvud |
| Arkivera extra datapost |
| Central katalog |
För att kontrollera ett ZIP-arkiv måste du hitta slutsignaturen för den centrala katalogen, hoppa över 18 byte och leta efter signaturer av kända format i kommentarsfältet. Stor storlek Kommentaren indikerar också faktumet att limma.
Storlek spelar roll
AVI
Strukturen för en AVI-fil är som följer: varje fil börjar med en RIFF-signatur (0x52 0x49 0x46 0x46). På byte 8 finns en AVI-signatur som anger formatet (0x41 0x56 0x49 0x20). Blocket vid offset 4, bestående av 4 byte, innehåller den initiala storleken på datablocket (byteordning - little endian). För att ta reda på blocknumret som innehåller nästa storlek, måste du lägga till rubrikstorleken (8 byte) och storleken som erhålls i 4-8 byte-blocket. Detta beräknar den totala filstorleken. Det är acceptabelt att den beräknade storleken kan vara mindre än den faktiska filstorleken. Efter den beräknade storleken kommer filen endast att innehålla noll byte (nödvändigt för att justera 1Kb-gränsen).Exempel på storleksberäkning:
WAV
Liksom AVI börjar en WAV-fil med en RIFF-signatur, men denna fil har en signatur från byte 8 - WAVE (0x57 0x41 0x56 0x45). Filstorleken beräknas på samma sätt som AVI. Den faktiska storleken måste helt matcha den beräknade.MP4
MP4 eller MPEG-4 är ett mediacontainerformat som används för att lagra video- och ljudströmmar, som även tillhandahåller lagring av undertexter och bilder.Vid offset 4 byte finns signaturer: filtyp ftyp (66 74 79 70) (QuickTime Container File Type) och filundertyp mmp4 (6D 6D 70 34). För erkännande dolda filer, vi är intresserade av möjligheten att beräkna filstorleken.
Låt oss titta på ett exempel. Storleken på det första blocket är vid förskjutning noll, och det är 28 (00 00 00 1C, Big Endian byteordning); den indikerar också förskjutningen där storleken på det andra datablocket finns. Vid offset 28 finner vi nästa blockstorlek lika med 8 (00 00 00 08). För att hitta nästa blockstorlek måste du lägga till storlekarna för de tidigare hittade blocken. Således beräknas filstorleken:
MOV
Detta mycket använda format är också en MPEG-4-behållare. MOV använder en proprietär datakomprimeringsalgoritm, har en struktur som liknar MP4 och används för samma ändamål - för lagring av ljud- och videodata, såväl som relaterat material.Liksom MP4 har alla mov-filer en 4-byte ftyp-signatur vid offset 4, men nästa signatur har värdet qt__ (71 74 20 20). Regeln för att beräkna filstorleken har inte ändrats: från början av filen beräknar vi storleken på nästa block och lägger ihop det.
Metoden för att kontrollera denna grupp av format för närvaron av "klibbiga" filer är att beräkna storleken enligt reglerna ovan och jämföra den med storleken på filen som kontrolleras. Om den aktuella filstorleken är mycket mindre än den beräknade, indikerar detta faktumet att limma. När du kontrollerar AVI-filer, accepteras det att den beräknade storleken kan vara mindre än filstorleken på grund av närvaron av tillagda nollor för att justera gränsen. I det här fallet är det nödvändigt att kontrollera om det finns nollor efter den beräknade filstorleken.
Kontrollerar sammansatt fil binärt format
Detta filformat, utvecklat av Microsoft, är också känt som OLE (Object Linking and Embedding) eller COM (Component Object Model). DOC, XLS, PPT-filer tillhör gruppen CFB-format.En CFB-fil består av en 512-byte header och lika långa sektorer som lagrar dataströmmar eller tjänstinformation. Varje sektor har sitt eget icke-negativa nummer, med undantag för specialnummer: "-1" - numrerar den fria sektorn, "-2" - numrerar sektorn som avslutar kedjan. Alla sektorkedjor definieras i FAT-tabellen.
Låt oss anta att en angripare modifierade en viss .doc-fil och klistrade in en annan fil i slutet av den. Det finns några på olika sätt upptäcka det eller indikera en anomali i dokumentet.
Onormal filstorlek
Som nämnts ovan består alla CFB-filer av en rubrik och lika långa sektorer. För att ta reda på sektorstorleken måste du läsa ett tvåbytetal vid offset 30 från början av filen och höja 2 till styrkan för detta nummer. Detta nummer måste vara lika med antingen 9 (0x0009) respektive 12 (0x000C), filsektorstorleken är 512 eller 4096 byte. Efter att ha hittat sektorn måste du kontrollera följande likhet:(Filstorlek - 512) mod SectorSize = 0
Om denna jämlikhet inte är uppfylld, kan du påpeka faktumet att limma filerna. Denna metod har emellertid en betydande nackdel. Om en angripare känner till sektorstorleken behöver han bara klistra in sin fil och ytterligare n byte så att storleken på den inklistrade informationen är en multipel av sektorstorleken.
Okänd sektortyp
Om angriparen känner till en metod för att kringgå den tidigare kontrollen, då den här metoden kan upptäcka förekomsten av sektorer med odefinierade typer.Låt oss definiera jämlikhet:
Filstorlek = 512 + CountReal * SectorSize, där FileSize är filstorleken, SectorSize är sektorstorleken, CountReal är antalet sektorer.
Vi definierar även följande variabler:
- CountFat – antal FAT-sektorer. Ligger vid offset 44 från början av filen (4 byte);
- CountMiniFAT – antal MiniFAT-sektorer. Belägen vid offset 64 från början av filen (4 byte);
- CountDIFAT – antal DIFAT-sektorer. Belägen vid offset 72 från början av filen (4 byte);
- CountDE – antal Directory Entry-sektorer. För att hitta denna variabel måste du hitta den första sektorn DE, som är vid offset 48. Sedan är det nödvändigt att få en fullständig representation av DE från FAT och räkna antalet DE-sektorer;
- CountStreams – antal sektorer med dataströmmar;
- CountFree – antal fria sektorer;
- CountClassified – antal sektorer med en viss typ;
Om CountClassified och CountReal är ojämlika kan vi naturligtvis dra slutsatsen att filer kan slås samman.
Min chef gav mig en ganska intressant uppgift. Skriv på kort tid en körbar filanalysator som skulle kunna hitta viruskroppar baserat på signaturer och bestämma vilken packare/kryptering som används. Den färdiga prototypen dök upp inom ett par timmar.
Författarens ord
Signaturanalys
Att söka efter ett skadligt objekt med hjälp av signaturer är något som alla antivirus kan göra. I allmänhet är en signatur en formaliserad beskrivning av vissa egenskaper genom vilka det kan fastställas att filen som skannas är ett virus och ett väldefinierat virus.
Det finns olika tekniker här. Ett alternativ är att använda en signatur som består av N byte av ett skadligt objekt. I det här fallet kan du inte göra en dum jämförelse, utan en jämförelse med någon mask (som att leta efter byte EB ?? ?? CD 13). Eller ställ in ytterligare villkor som "sådana och sådana bytes måste finnas vid ingångspunkten till programmet" och så vidare. Signaturen för skadlig programvara är en speciell fråga.
På samma sätt beskrivs några tecken med vilka man kan fastställa att den körbara filen är packad med en eller annan kryptor eller packare (till exempel det banala ASPacket). Om du noggrant läser vår tidning, har du definitivt hört talas om ett sådant verktyg som PEiD, som kan identifiera de vanligaste packare, kryptor och kompilatorer (databasen har ett stort antal signaturer) för PE-filen som överförs till den . Tyvärr har nya versioner av programmet inte släppts på länge, och nyligen dök ett meddelande upp på den officiella webbplatsen att projektet inte kommer att utvecklas vidare. Det är synd, eftersom funktionerna hos PEiD (särskilt med tanke på plugin-systemet) mycket väl kan vara användbara för mig. Efter en kort analys stod det klart att detta inte var ett alternativ. Men efter att ha grävt i engelskspråkiga bloggar hittade jag snabbt vad som passade mig. YARA-projekt (code.google.com/p/yara-project).
Vad är YARA?
Redan från början var jag övertygad om att det någonstans på Internet redan fanns en öppen källkodsutveckling som skulle ta på sig uppgiften att fastställa överensstämmelsen mellan en viss signatur och filen som granskas. Om jag kunde hitta ett sådant projekt så kunde det enkelt sättas på skenorna i en webbapplikation, lägga till olika signaturer där och få det som krävdes av mig. Planen började verka ännu mer realistisk när jag läste beskrivningen av YARA-projektet.
Utvecklarna själva positionerar det som ett verktyg för att hjälpa skadlig programvara att identifiera och klassificera skadliga prover. Forskaren kan skapa beskrivningar för olika typer skadlig programvara som använder text eller binära mönster som beskriver de formaliserade egenskaperna hos skadlig programvara. Så här får man signaturer. Faktum är att varje beskrivning består av en uppsättning rader och något logiskt uttryck, på grundval av vilka analysatorns utlösande logik bestäms.
Om villkoren i en av reglerna är uppfyllda för filen som granskas, bestäms den i enlighet därmed (till exempel en sådan och en mask). Ett enkelt exempel på en regel för att förstå vad vi pratar om:
regel silent_banker: bankir
{
meta:
description = "Detta är bara ett exempel"
trådnivå = 3
in_the_wild = sant
strängar:
$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"
skick:
$a eller $b eller $c
}
I denna regel säger vi till YARA att alla filer som innehåller minst en av provsträngarna som beskrivs i variablerna $a, $b, $c ska klassificeras som en silent_banker-trojan. Och detta är en mycket enkel regel. I verkligheten kan regler vara mycket mer komplexa (vi kommer att prata om detta nedan).
Till och med listan över projekt som använder den talar om YARA-projektets auktoritet, och detta är:
- VirusTotal Malware Intelligence Services (vt-mis.com);
- jsunpack-n (jsunpack.jeek.org);
- Vi bevakar din webbplats (wewatchyourwebsite.com).
All kod är skriven i Python, och användaren erbjuds både själva modulen för användning i deras utveckling, och helt enkelt en körbar fil för att använda YARA som en fristående applikation. Som en del av mitt arbete valde jag det första alternativet, men för enkelhetens skull kommer vi i den här artikeln helt enkelt att använda analysatorn som en konsolapplikation.
Efter lite grävande kom jag snabbt på hur man skriver regler för YARA, samt hur man bifogar virussignaturer från gratisprogrammet och packare från PEiD till det. Men vi börjar med installationen.
Installation
Som jag redan har sagt är projektet skrivet i Python, så det kan enkelt installeras på Linux, Windows och Mac. Till en början kan du bara ta det binära. Om vi anropar applikationen i konsolen får vi upp reglerna för lansering.
$yara
användning: yara ... ... FIL | PID
Det vill säga formatet för att anropa programmet är som följer: först är det namnet på programmet, sedan en lista med alternativ, varefter filen med reglerna anges, och i slutet - namnet på filen som är undersökt (eller katalogen som innehåller filerna), eller processidentifieraren. Nu skulle jag vilja förklara på ett bra sätt hur just dessa regler är uppbyggda, men jag vill inte omedelbart belasta dig med torr teori. Därför kommer vi att göra saker annorlunda och låna andras signaturer så att YARA kan utföra en av de uppgifter vi har satt - en fullfjädrad upptäckt av virus genom signaturer.
Ditt eget antivirus
Den viktigaste frågan: var får man tag i databasen med signaturer för kända virus? Antivirusföretag delar aktivt sådana databaser sinsemellan (vissa mer generöst, andra mindre). För att vara ärlig, tvivlade jag först till och med på att någonstans på Internet skulle någon öppet posta sådana saker. Men det visade sig att det finns bra människor. En lämplig databas från det populära antivirusprogrammet ClamAV är tillgänglig för alla (clamav.net/lang/en). I avsnittet "Senaste stabila release" kan du hitta en länk till senaste versionen antivirusprodukt, samt länkar för att ladda ner ClamAV-virusdatabaser. Vi kommer i första hand att vara intresserade av filerna main.cvd (db.local.clamav.net/main.cvd) och daily.cvd (db.local.clamav.net/daily.cvd).
Den första innehåller huvuddatabasen med signaturer, den andra innehåller den mest kompletta databasen det här ögonblicket bas med olika tillägg. Daily.cvd, som innehåller mer än 100 000 visningar av skadlig programvara, är helt tillräckligt för detta ändamål. ClamAV-databasen är dock inte en YARA-databas, så vi måste konvertera den till önskat format. Men hur? När allt kommer omkring vet vi ännu ingenting om varken ClamAV-formatet eller Yara-formatet. Detta problem har redan åtgärdats före oss genom att förbereda ett litet skript som konverterar ClamAV-virussignaturdatabasen till en uppsättning YARA-regler. Manuset heter clamav_to_yara.py och är skrivet av Matthew Richard (bit.ly/ij5HVs). Ladda ner skriptet och konvertera databaserna:
$ python clamav_to_yara.py -f daily.cvd -o clamav.yara
Som ett resultat kommer vi i filen clamav.yara att få en signaturdatabas som omedelbart är redo att användas. Låt oss nu prova kombinationen av YARA och ClamAV-databasen i aktion. Att skanna en mapp med en signatur utförs med ett enda kommando:
$ yara -r clamav.yara /pentest/msf3/data
Alternativet -r anger att skanningen ska utföras rekursivt över alla undermappar i den aktuella mappen. Om det fanns några viruskroppar i mappen /pentest/msf3/data (åtminstone de som finns i ClamAV-databasen), kommer YARA omedelbart att rapportera detta. I princip är detta en färdig signaturscanner. För större bekvämlighet skrev jag ett enkelt skript som kontrollerade ClamAV-databasuppdateringar, laddade ner nya signaturer och konverterade dem till YARA-formatet. Men det här är redan detaljer. En del av uppgiften är klar, nu kan du börja dra upp regler för identifiering av packare/kryptering. Men för att göra detta var jag tvungen att hantera dem lite.
Spela efter reglerna
Så, en regel är huvudmekanismen för ett program som låter dig tilldela en given fil till en viss kategori. Reglerna beskrivs i en separat fil (eller filer) och är till utseende mycket lika konstruktionen struct() från språket C/C++.
regel BadBoy
{
strängar:
$a = "win.exe"
$b = "http://foo.com/badfi le1.exe"
$c = "http://bar.com/badfi le2.exe"
skick:
$a och ($b eller $c)
}
I princip är det inget komplicerat i att skriva regler. I den här artikeln berörde jag bara huvudpunkterna, och du hittar detaljerna i manualen. För nu, de tio viktigaste punkterna:
1. Varje regel börjar med nyckelordsregeln, följt av regelidentifieraren. Identifierare kan ha samma namn som variabler i C/C++, det vill säga de kan bestå av bokstäver och siffror, och det första tecknet kan inte vara ett tal. Maximal längd identifieringsnamn - 128 tecken.
2. Vanligtvis består regler av två sektioner: en definitionssektion (strängar) och en villkorssektion (villkor). Strängsektionen specificerar data på grundval av vilka villkorssektionen kommer att avgöra om en given fil uppfyller vissa villkor.
3. Varje rad i strängsektionen har sin egen identifierare, som börjar med $-tecknet - i allmänhet som en variabeldeklaration i PHP. YARA stöder vanliga strängar inneslutna dubbla citattecken("") och hexadecimala strängar inneslutna i tandställning(()), såväl som reguljära uttryck:
$my_text_string = "text här"
$my_hex_string = ( E2 34 A1 C8 23 FB )
4. Villkorssektionen innehåller all logik i regeln. Det här avsnittet måste innehålla ett booleskt uttryck som avgör när en fil eller process matchar regeln. Vanligtvis hänvisar detta avsnitt till tidigare deklarerade rader. Och strängidentifieraren behandlas som en boolesk variabel som returnerar true om strängen hittades i filen eller processminnet, och annars är falskt. Ovanstående regel anger att filer och processer som innehåller strängen win.exe och en av de två webbadresserna ska kategoriseras som BadBoy (efter regelnamnet).
5. Hexadecimala strängar tillåter tre konstruktioner som gör dem mer flexibla: jokertecken, hopp och alternativ. Substitutioner är platser i en sträng som är okända och kan ersättas med vilket värde som helst. De indikeras med symbolen "?":
$hex_string = ( E2 34 ?? C8 A? FB )
Detta tillvägagångssätt är mycket praktiskt när du anger strängar vars längd är känd, men innehållet kan variera. Om en del av en sträng kan vara av olika längd är det bekvämt att använda intervall:
$hex_string = ( F4 23 62 B4 )
Denna post innebär att det i mitten av raden kan finnas från 4 till 6 olika byte. Du kan också implementera ett alternativt val:
$hex_string = ( F4 23 (62 B4 | 56) 45 )
Detta betyder att i stället för den tredje byten kan det finnas 62 B4 eller 56, en sådan post motsvarar raderna F42362B445 eller F4235645.
6. För att kontrollera att en given sträng har en specifik offset i ett fil- eller processadressutrymme, används at-operatorn:
$a vid 100 och $b vid 200
Om strängen kan vara inom ett visst adressområde används in-operatorn:
$a in (0..100) och $b in (100..fi lesize)
Ibland uppstår situationer när du behöver specificera att en fil ska innehålla ett visst nummer från en given uppsättning. Detta görs med hjälp av operatorn of:
regel av exempel1
{
strängar:
$foo1 = "dummy1"
$foo2 = "dummy2"
$foo3 = "dummy3"
skick:
2 av ($foo1,$foo2,$foo3)
}
Ovanstående regel kräver att filen innehåller två valfria rader från uppsättningen ($foo1,$foo2,$foo3). Istället för att ange ett specifikt antal rader i filen kan du använda variablerna någon (minst en rad från en given uppsättning) och alla (alla rader från en given uppsättning).
7. Tja, den sista intressanta möjligheten som måste övervägas är att tillämpa ett villkor på många rader. Den här funktionen är mycket lik operatörens, bara mer kraftfull är operatörens for..of:
för uttryck av string_set: (boolean_expression)
Denna post bör läsas så här: av strängarna som anges i string_ set, måste åtminstone uttrycksbitarna uppfylla boolean_expression-villkoret. Eller med andra ord: det booleska uttrycket utvärderas för varje sträng i stränguppsättningen, och uttrycken från dem måste returnera True. Därefter kommer vi att titta på denna konstruktion med ett specifikt exempel.
Att göra PEiD
Så när allt har blivit mer eller mindre klart med reglerna kan vi börja implementera en detektor av packare och kryptor i vårt projekt. Först, som källmaterial, lånade jag namnteckningar från välkända packare från samma PEiD. I plugins-mappen finns en fil userdb.txt, som innehåller det vi behöver. Det fanns 1850 signaturer i min databas.
Ganska mycket, så för att kunna importera dem till fullo, råder jag dig att skriva något slags manus. Formatet för denna databas är enkelt - det vanliga används textfil, som lagrar poster som:
signatur = 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 = sant
Den första raden anger namnet på packaren, som kommer att visas i PEiD, men för oss kommer det att vara regelidentifieraren. Den andra är signaturen i sig. Den tredje är flaggan ep_only, som indikerar om man ska söka efter en given rad endast vid ingångspunktsadressen eller genom hela filen.
Tja, låt oss försöka skapa en regel, säg, för ASPack? Som det visar sig är det inget komplicerat med detta. Låt oss först skapa en fil för att lagra reglerna och kalla den till exempel packers.yara. Sedan söker vi i PEiD-databasen efter alla signaturer som innehåller ASPack i deras namn och överför dem till regeln:
regel ASPack
{
strängar:
$ = ( 60 E8 ?? ?? ?? ?? 5D 81 ED ?? ?? (43 | 44) ?? B8 ?? ?? (43 | 44) ?? 03 C5 )
$ = ( 60 EB ?? 5D EB ?? FF ?? ?? ?? ?? ?? E9 )
[.. klippa..]
$ = ( 60 E8 03 00 00 00 E9 EB 04 5D 45 55 C3 E8 01 )
skick:
för någon av dem: ($vid entrypoint)
}
Alla hittade poster har ep_only-flaggan satt till true, det vill säga dessa rader måste finnas vid ingångspunktsadressen. Därför skriver vi följande villkor: "för någon av dem: ($vid entrypoint)".
Således kommer närvaron av åtminstone en av de givna raderna vid ingångspunktsadressen att innebära att filen är packad med ASPack. Observera också att i denna regel anges alla rader helt enkelt med $-tecknet, utan en identifierare. Detta är möjligt eftersom vi i villkorssektionen inte kommer åt några specifika, utan använder hela uppsättningen.
För att kontrollera funktionen hos det resulterande systemet, kör bara kommandot i konsolen:
$ yara -r packers.yara somefi le.exe
Efter att ha matat ett par applikationer paketerade med ASPack där, var jag övertygad om att allt fungerade!
Färdig prototyp
YARA visade sig vara ett extremt tydligt och transparent verktyg. Det var inte svårt för mig att skriva en webbadmin för den och ställa in den för att fungera som en webbtjänst. Med lite kreativitet är analysatorns torra resultat redan färgade i olika färger, vilket indikerar graden av fara för den upptäckta skadliga programvaran. En liten uppdatering av databasen, och för många av kryptorna finns en kort beskrivning tillgänglig, och ibland även uppackningsinstruktioner. Prototypen har skapats och fungerar perfekt, och cheferna dansar av förtjusning!
Funktionskoden (FC) i telegramhuvudet identifierar telegramtypen, t.ex. Request-telegram (Request eller Send/Request) och Acknowledgement or Response-telegram (Acknowledgement-ram, Response-ram). Dessutom innehåller funktionskoden den faktiska överföringsfunktionen och styrinformation som förhindrar förlust och duplicering av meddelanden, eller stationstypen med FDL-status.
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | FC: Begäran om funktionskod |
| 1 | Begär telegram | |||||||
| X | FCV = Alternerande bit påslagen | |||||||
| X | href=”http://profibus.felser.ch/en/funktionscode.htm#aufruffolgebit”>FCB = Alternerande bit (från bildräkning) | |||||||
| 1 | 0 (0x0) | CV = Klockvärde() | ||||||
| 1 | Övrig | Reserverad | ||||||
| 0 | 0 (0x0) | TE = Tidshändelse (klocksynkronisering) | ||||||
| 0 | 3 (0x3) | SDA_LOW = Skicka data bekräftad - låg prioritet | ||||||
| 0 | 4 (0x4) | SDN_LOW = Skicka data ej bekräftad - låg prioritet | ||||||
| 0 | 5 (0x5) | SDA_HIGH = Skicka data bekräftad - hög prioritet | ||||||
| 0 | 6 (0x6) | SDN_HIGH = Skicka data ej bekräftad | ||||||
| 0 | 7 (0x7) | MSRD = Skicka förfrågningsdata med Multicast-svar | ||||||
| 0 | 9 (0x9) | Begär FDL-status | ||||||
| 0 | 12(0xC) | SRD låg = Skicka och begära data | ||||||
| 0 | 13(0xD) | SRD hög = Skicka och begära data | ||||||
| 0 | 14(0xE) | Begär ID med svar | ||||||
| 0 | 15 (0xF) | Begär LSAP Status med svar 1) | ||||||
| 0 | Övrig | Reserverad | ||||||
1) detta värde finns i den senaste versionen av standarden inte längre definierat utan endast reserverat
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | FC: Funktionskodssvar |
| 0 | Svarstelegram | |||||||
| 0 | Reserverad | |||||||
| 0 | 0 | Slav | ||||||
| 0 | 1 | Mästaren är inte redo | ||||||
| 1 | 0 | Mästare redo, utan token | ||||||
| 1 | 1 | Master redo, i token ring | ||||||
| 0 (0x0) | OK | |||||||
| 1 (0x1) | UE = Användarfel | |||||||
| 2 (0x2) | RR = Inga resurser | |||||||
| 3 (0x3) | RS = SAP inte aktiverat | |||||||
| 8 (0x8) | DL = Data låg (normalt fall med DP) | |||||||
| 9 (0x9) | NR = Inga svarsdata redo | |||||||
| 10(0xA) | DH = Data hög (DP-diagnos väntar) | |||||||
| 12(0xC) | RDL = Data ej mottagen och Data låg | |||||||
| 13(0xD) | RDH = Data ej mottagen och Data hög | |||||||
| Övrig | Reserverad | |||||||
Ramräkningsbit Ramräknebiten FCB (b5) förhindrar meddelandeduplicering av den bekräftande eller svarande stationen (svararen) och varje förlust av den anropande stationen (initiatorn). Undantagna från detta är förfrågningar utan bekräftelse (SDN) och förfrågningar om FDL Status, Ident och LSAP Status.
För säkerhetssekvensen måste initiatorn bära en FCB för varje responder. När ett förfrågningstelegram (förfrågan eller sänd/förfrågan) skickas till en svarsperson för första gången, eller om det återsänds till en svarsperson som för närvarande är markerad som icke-operativ, måste FCB ställas in enligt definitionen i svarspersonen. Initiativtagaren uppnår detta i ett Request-telegram med FCV=0 och FCB=1. Svararen måste bedöma ett telegram av detta slag som den första meddelandecykeln och lagra FCB=1 tillsammans med initiatorns adress (SA) (se följande tabell). Denna meddelandecykel kommer inte att upprepas av initiatorn. I efterföljande begärantelegram till samma svarsmottagare måste initiatorn ställa in FCV=1 och ändra FCB med varje nytt begärantelegram. Varje svarare som tar emot ett begäranstelegram adresserat till den med FCV=1 måste utvärdera FCB. Om FCB har ändrats jämfört med det senaste begärantelegrammet från samma initiator (samma SA), är detta en giltig bekräftelse på att föregående meddelandecykel avslutades korrekt. Om Request-telegrammet kommer från en annan initiator (annan SA), är utvärdering av FCB inte längre nödvändig. I båda fallen måste svarsmottagaren spara FCB med källan SA tills mottagandet av ett nytt telegram adresserat till den. I fallet med ett förlorat eller försämrat bekräftelse- eller svarstelegram, får FCB inte ändras av initiatorn i begäran om nytt försök: detta kommer att indikera att föregående meddelandecykel var felaktig. Om svaranden tar emot ett begäranstelegram med FCV=1 och samma FCB som det senaste begäranstelegrammet från samma initiator (samma SA), kommer detta att indikera ett nytt försök. Den som svarar måste i sin tur återsända bekräftelsen eller svarstelegrammet som hålls i beredskap. Fram till den ovan nämnda bekräftelsen eller mottagandet av ett telegram med en annan adress (SA eller DA) som inte bekräftas (Send Data with No Acknowledge, SDN) måste svaranden hålla den senaste bekräftelsen eller svarstelegrammet i beredskap för varje eventuellt återförsök med begäran . I fallet med Request-telegram som inte är kvitterade och med Request FDL Status, Ident och LSAP Status, FCV=0 och FCB=0; utvärdering av svaranden är inte längre nödvändig.
| b5 | b4 | Bitposition | ||
| FCB | FCV | Skick | Menande | Handling |
| 0 | 0 | DA = TS/127 | Begäran utan bekräftelse Begär FDL Status/ Ident/ LSAP Status |
Radera senaste bekräftelsen |
| 0/1 | 0/1 | DA#TS | Begäran till en annan svarare | |
| 1 | 0 | DA = TS | Första begäran | FCBM:= 1 SAM:=SA Ta bort senaste bekräftelse/svar |
| 0/1 | 1 | DA = TS SA = SAM FCB#FCBM |
Ny förfrågan | Ta bort senaste bekräftelse/svar FCBM:=FCB Håll bekräftelsen/svaret redo för ett nytt försök |
| 0/1 | 1 | DA = TS SA = SAM FCB = FCBM |
Försök igen Begäran | FCBM:=FCB Upprepa bekräftelse/svar och fortsätt att hålla i beredskap |
| 0/1 | 1 | DA = TS SA#SAM |
Ny initiativtagare | FCBM:=FCB SAM:= SA Håll bekräftelse/svar i beredskap för ett nytt försök |
FCBM lagrade FCB i minnet SAM lagrade SA i minnet
