Opprette en tilpasset kjent filtype for R-Studio. Bestemme en filtype etter signatur Hva er en filsignatur
Konseptet " Magisk tall"i programmering har tre betydninger:
- Datasignatur
- Valgt unike verdier, som ikke skal være det samme som andre verdier (f.eks. UUID)
- Dårlig programmeringspraksis.
Datasignatur
Magisk tall, eller signatur, - et heltall eller en tekstkonstant som brukes til å identifisere en ressurs eller data unikt. Et slikt tall i seg selv har ingen betydning og kan skape forvirring hvis det dukker opp i programkoden uten den rette konteksten eller kommentaren, mens et forsøk på å endre det til et annet, selv en i nærheten av verdi, kan føre til helt uforutsigbare konsekvenser. Av denne grunn ble slike tall ironisk nok kalt magiske tall. Foreløpig er dette navnet godt etablert som et begrep. For eksempel starter enhver kompilert Java-språkklasse med det heksadesimale "magiske tallet" 0xCAFEBABE. Det andre kjente eksemplet er et hvilket som helst kjørbar fil OS Microsoft Windows med utvidelsen .exe begynner med bytesekvensen 0x4D5A (som tilsvarer ASCII-tegnene MZ - initialene til Mark Zbikowski, en av skaperne av MS-DOS). Et mindre kjent eksempel er den uinitialiserte pekeren i Microsoft Visual C++ (siden 2005-versjonen av Microsoft Visual Studio), som har adressen 0xDEADBEEF i feilsøkingsmodus.
I UNIX-lignende operativsystemer Filtypen bestemmes vanligvis av filsignaturen, uavhengig av filtypen til navnet. De tilbyr et standard filverktøy for å tolke filsignaturen.
Dårlig programmeringspraksis
Også kalt "magiske tall" er en dårlig programmeringspraksis når en numerisk verdi forekommer i kildeteksten og det ikke er åpenbart hva det betyr. For eksempel, en tekstbit som dette, skrevet i Java, ville være dårlig:
drawSprite(53, 320, 240);
final int SCREEN_WIDTH = 640 ; endelig 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);
Nå er det klart: denne linjen viser en sprite - siktets trådkors - i midten av skjermen. I de fleste programmeringsspråk vil alle verdier som brukes for slike konstanter, bli beregnet på kompileringstidspunktet og erstattet på stedene der verdiene brukes. Derfor forringer ikke en slik endring i kildeteksten ytelsen til programmet.
I tillegg er magiske tall en potensiell kilde til feil i et program:
- Hvis det samme magiske tallet brukes mer enn én gang i et program (eller potensielt kan brukes), vil endring av det kreve endringer av hver forekomst (i stedet for bare én redigering av verdien til den navngitte konstanten). Hvis ikke alle forekomster er korrigert, vil minst én feil oppstå.
- I minst én av hendelsene kan det magiske tallet være feilstavet innledningsvis, og dette er ganske vanskelig å oppdage.
- Det magiske tallet kan avhenge av en implisitt parameter eller et annet magisk tall. Hvis disse avhengighetene, som ikke er eksplisitt identifisert, ikke tilfredsstilles, vil minst én feil oppstå.
- Når du endrer forekomster av ett magisk tall, er det mulig å feilaktig endre et annet magisk tall som er uavhengig, men som har samme tallverdi.
Magiske tall og tverrplattformer
Noen ganger skader magiske tall kode på tvers av plattformer. Faktum er at i C, på 32- og 64-bits operativsystemer, er størrelsen på char , short og long long typen garantert, mens størrelsen på int , long , size_t og ptrdiff_t kan endres (for de to første, avhengig av preferansene til kompilatorutviklerne , for de to siste - avhengig av bitkapasiteten til målsystemet). I gammel eller dårlig skrevet kode kan det være "magiske tall" som indikerer størrelsen på en type - når du flytter til maskiner med en annen bitkapasitet, kan de føre til subtile feil.
For eksempel:
const size_t NUMBER_OF_ELEMENTS = 10 ; lang [NUMBER_OF_ELEMENTS]; memset(a, 0, 10 * 4); // feil - lang antas å være 4 byte, magisk antall elementer brukes memset(a, 0, NUMBER_OF_ELEMENTS * 4); // feil - lang antas å være 4 byte memset(a, 0, NUMBER_OF_ELEMENTS * størrelsen på (lang)); // ikke helt korrekt - duplisering av typenavnet (hvis typen endres, må du endre det her også) memset (a , 0 , NUMBER_OF_ELEMENTS * størrelsen på (a [ 0 ])); // korrekt, optimalt for dynamiske arrays med en størrelse som ikke er null memset(a, 0, størrelsen på(a)); // korrekt, optimal for statiske arrays
Tall som ikke er magiske
Ikke alle tall trenger å konverteres til konstanter. For eksempel koden for
Søk ved å skanne filer av kjente typer (eller, som det ofte sies, søke etter filer med signatur) er en av de mest effektive som brukes i R-Studios datagjenopprettingsverktøy. Ved å bruke en gitt signatur kan du gjenopprette filer av en bestemt type i tilfeller der informasjon om katalogstruktur og filnavn mangler helt eller delvis (skadet).
Vanligvis brukes diskpartisjonstabellen til å bestemme plasseringen av filene. Hvis du sammenligner en disk med en bok, vil partisjonstabellen være lik innholdsfortegnelsen. Ved skanning søker R-Studio etter kjente filtyper i diskpartisjonstabellen ved å bruke visse spesifiserte signaturer. Dette er muliggjort av det faktum at praktisk talt hver filtype har en unik signatur eller datamønster. Filsignaturer finnes på et bestemt sted i begynnelsen av filen og i mange tilfeller også på slutten av filen. Ved skanning matcher R-Studio de funnet dataene med signaturer av kjente filtyper, noe som gjør at de kan identifiseres og dataene gjenopprettes.
Ved å bruke teknologi for å skanne kjente filtyper, lar R-Studio deg gjenopprette data fra disker som har blitt omformatert og hvis partisjonstabeller er overskrevet. Dessuten, hvis en diskpartisjon blir overskrevet, skadet eller slettet, er skanning av kjente filtyper det eneste alternativet.
Men nesten alt har sine ulemper, og de kjente filtypene som brukes i R-Studio er intet unntak. Så når du skanner kjente filtyper, lar R-Studio deg bare gjenopprette ufragmenterte filer, men som allerede nevnt, i de fleste tilfeller er dette den siste mulige metoden.
R-Studio inkluderer allerede signaturer av de vanligste filtypene (vis full liste filer av kjente typer kan bli funnet i R-Studio Online Help-seksjon.)
Om nødvendig kan brukeren legge til nye filtyper i R-Studio. Hvis du for eksempel trenger å finne filer av en unik type, eller de som er utviklet etter siste utgivelsesdato for R-Studio, kan du legge til dine egne signaturer til filene av kjente typer. Denne prosessen vil bli diskutert neste gang.
Egendefinerte filer av kjente typer
Egendefinerte filsignaturer av kjente filtyper lagres i XML-fil e spesifisert i dialogboksen Innstillinger. Å legge til en signatur består av to deler:
- Bestemmelse av filsignaturen plassert i begynnelsen av filen og, hvis den finnes, på slutten av filen.
- Generer en XML-fil som inneholder en filsignatur og annen informasjon om filtypen.
Alt dette kan gjøres ved hjelp av R-Studio. Samtidig trenger du ikke å være ekspert på å komponere (redigere) XML-dokumenter eller på området heksadesimal redigering - i denne veiledningen (artikkelen), som er rettet mot brukeren selv inngangsnivå, vil alle stadier av denne prosessen bli diskutert i detalj.
Eksempel: Legge til en signatur for en MP4-fil (XDCam-EX Codec)
La oss se på å legge til en filsignatur ved å bruke eksemplet på en .MP4-fil opprettet med Sony XDCAM-EX. Du kan bruke den for eksempel i tilfelle skade på SD-kortet for filer du ennå ikke har klart å lagre på datamaskinens harddisk.
Første trinn: Bestemme filsignatur
For å bestemme filsignaturen, vurder eksempler på filer med samme format.
La disse være fire videofiler fra Sony XDCAM-EX:
ZRV-3364_01.MP4
ZRV-3365_01.MP4
ZRV-3366_01.MP4
ZRV-3367_01.MP4
For enkelhets skyld, la disse være små filer. Større filer er vanskeligere å se i heksadesimal.
1. Åpne filene i R-Studio. For å gjøre dette, høyreklikk på hver fil og velg Vis/Rediger fra hurtigmenyen.
2. La oss sammenligne filene. Vi vil se etter det samme mønsteret som finnes i alle fire filene. Han vil dukke opp fil signatur. Vanligvis finnes filsignaturer i begynnelsen av filen, men noen ganger på slutten.
3. Definer filsignaturen i begynnelsen av filen. I vårt eksempel er den plassert helt i begynnelsen av filen. Merk at dette ikke alltid skjer - ofte er filsignaturen i begynnelsen av filen, men ikke på den første linjen (offset).
Fra bildene nedenfor ser det ut til at innholdet i alle fire filene er forskjellig, men de starter alle med samme filsignatur. 
Klikk på bildet for å forstørre det
Klikk på bildet for å forstørre det
Klikk på bildet for å forstørre det
Klikk på bildet for å forstørre det
Det uthevede området i bildene er en filsignatur av denne typen filer. Den presenteres i både tekst og heksadesimalt format.
I tekstform ser filsignaturen slik ut:
....ftypmp42....mp42........gratis
Prikker (“.”) indikerer tegn som ikke kan representeres i tekstform. Derfor er det også nødvendig å oppgi den heksadesimale formen til filsignaturen:
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å samme måte definerer vi filsignaturen, men helt på slutten av filen. Det kan være en annen filsignatur, en annen lengde.
Bildene nedenfor fremhever filsignaturen på slutten av filen: 
Klikk på bildet for å forstørre det
Klikk på bildet for å forstørre det
Klikk på bildet for å forstørre det
Klikk på bildet for å forstørre det
Vær oppmerksom på at dataene før det valgte området (filsignatur) er de samme i alle fire filene. Dette er teknisk informasjon som ikke er en filsignatur, men indikerer at alle fire bildene (filene) ble tatt med samme kamera med samme parametere. Det er vanligvis mulig å skille samsvarende mønstre med teknisk informasjon fra en filsignatur. I vårt eksempel, på den siste linjen før starten av filsignaturen, ser vi teksten 'RecordingMode type="normal"', som tydelig indikerer at dette er en slags filparameter, og ikke en signatur. Vær alltid spesielt oppmerksom på denne linjen for ikke å feilaktig inkludere teknisk informasjon del av filsignaturen.
I vårt tilfelle er filsignaturen følgende tekst:
...
La oss minne deg på at prikker indikerer tegn som ikke kan representeres i tekstform.
I heksadesimal ser filsignaturen slik ut:
3N 2F 4E 6F 6E 52 65 61 6N 54 69 6A 65 4A 65 74 61 3E 0D 0A 00
Vær oppmerksom på: signaturen vil ikke alltid være på slutten av filen.
Andre trinn: Opprette en XML-fil som beskriver en kjent filtype
Nå, etter å ha definert filsignaturen, kan du opprette en XML-fil og inkludere den tilsvarende filtypen i R-Studio. Dette kan gjøres på to måter:
2.1 Bruke innebygd grafikk editor fil signaturer:
Velg Innstillinger-elementet fra Verktøy-menyen, i dialogboksen Innstillinger som åpnes, klikk på fanen Kjente filtyper og klikk deretter på Rediger brukers filtyper-knappen. 
Klikk på bildet for å forstørre det
Klikk på knappen Opprett filtype i dialogboksen Rediger brukerens filtyper.
Still inn følgende alternativer:
- ID - en unik digital identifikator. Dette nummeret vil bli valgt tilfeldig; Det eneste er at det ikke skal samsvare med den digitale identifikatoren til noen annen filtype.
- Gruppebeskrivelse - gruppen der filene som ble funnet vil være plassert i R-Studio. Du kan stille inn enten ny gruppe, eller velg en av de som allerede finnes. For oss vil dette være gruppen "Multimedia Video (Multimedia: Video)".
- Beskrivelse - Kort beskrivelse filtype. I vårt eksempel kan du bruke for eksempel "Sony cam video, XDCam-EX".
- Utvidelse - utvidelse av filer av denne typen. I vårt tilfelle - mp4.
Funksjoner-parameteren er valgfri, i vårt tilfelle trenger vi ikke bruke den. 
Klikk på bildet for å forstørre det
Deretter må du skrive inn start- og sluttfilsignaturen. For å gjøre dette, velg Start og deretter kontekstmenyen kommandoen Legg til signatur. 
Klikk på bildet for å forstørre det
Dobbeltklikk deretter på feltet<пустая сигнатура> (
Klikk på bildet for å forstørre det
Lag deretter den endelige filsignaturen. Sørg for å skrive inn 21 i Fra-kolonnen. 
Klikk på bildet for å forstørre det
Du har opprettet din egen signatur for kjente filtyper.
Nå må du lagre den. Det er to måter: du kan enten lagre den til standardfilen som er angitt i hovedfanen i dialogboksen Innstillinger ved å klikke på Lagre-knappen. Eller klikk på Lagre som...-knappen og lagre signaturen til en annen fil.
2.2 Lage en XML-fil som beskriver en kjent filtype manuelt:
For å skape denne filen La oss bruke XML versjon 1.0 og UTF-8-koding. Fortvil ikke hvis du ikke vet hva det er - bare åpne noen tekstredigerer(for eksempel Notepad.exe) og skriv inn følgende tekst på den første linjen:
Deretter vil vi lage en XML-tag som definerer filtypen (FileType). Med de tidligere beskrevne XML-attributtene i betraktning, vil taggen se slik ut:
La oss sette den inn rett etter
Deretter definerer vi filsignaturen (tag
Hvis tilstede, må du også definere sluttsignaturen (på slutten av filen). Denne bruker den samme taggen, men med et "from"-element og et "end"-attributt. Det vil se slik ut:
Husk at den endelige filsignaturen ikke inneholdt ikke-teksttegn, men inneholdt skråstreker og trekantparenteser. For å unngå forvirring og feil i XML-syntaks, vil vi erstatte tegnene "/", " i signaturen<" и ">" deres heksadesimale verdier.
På slutten, etter filsignaturene, må det være avsluttende tagger FileType og FileTypeList:
Så hele filen skal se slik ut:
Husk: XML-syntaks skiller mellom store og små bokstaver, så den riktige taggen vil være
La oss lagre filen i tekstformat med filtypen .xml. For eksempel: SonyCam.xml.
Vi har opprettet vår egen signatur for kjente filtyper. Dette eksemplet er ganske tilstrekkelig til å forstå de grunnleggende prinsippene for å lage en tilpasset filtype. Mer erfarne brukere kan bruke XML versjon 2.0. Du kan lese mer om dette i R-Studios netthjelpseksjon.
Trinn 3: Kontrollere og legge til en fil som beskriver en kjent filtype
Det neste trinnet er å legge til (laste opp) XML-filen din til R-Studio. I dette tilfellet vil det bli sjekket automatisk.
La oss laste inn XML-filen som ble opprettet på forrige trinn i R-Studio. For å gjøre dette, velg Innstillinger-elementet i Verktøy-menyen. I området for brukerens filtyper i hovedfanen i dialogboksen Innstillinger legger du til XML-filen vi opprettet (SonyCam.xml). Klikk på Bruk-knappen. 
Klikk på bildet for å forstørre det
2. Svar Ja på forespørselen om å laste ned en ny filtype. 
Klikk på bildet for å forstørre det
3. For å bekrefte at filtypen ble lastet, klikk på fanen Kjente filtyper i dialogboksen Innstillinger. Husk at vi la til filtypen i Multimedia Video-gruppen (Multimedia: Video). Etter å ha utvidet denne gruppen (mappen), bør vi se et element med beskrivelsen vi spesifiserte da vi opprettet XML-filen: Sony cam video, XDCam-EX (.mp4). 
Klikk på bildet for å forstørre det
Klikk på bildet for å forstørre det
Hvis det er noen feil i filsyntaksen, vil du se en tilsvarende melding: 
Klikk på bildet for å forstørre det
I dette tilfellet må du sjekke XML-filen på nytt for feil. Husk: XML-syntaks skiller mellom store og små bokstaver, og hver tag må ha en avsluttende kode på slutten.
Trinn 4: Teste filen som beskriver en kjent filtype
For å sjekke riktigheten til den tilpassede filtypen vi opprettet, la oss prøve å finne .mp4-filene våre på en flyttbar USB-flash-stasjon.
1. Under Windows Vista eller Windows 7, utfør en full (ikke rask) formatering av disken eller bruk et verktøy for å rydde diskplass (for eksempel R-Wipe & Clean) for å fullstendig fjerning alle data tilgjengelig på disken. La USB-disk formatert i FAT32 (størrelsen på de søkte filene overstiger ikke 2 GB).
2. La oss kopiere det testfiler til disk og start datamaskinen på nytt slik at innholdet i cache-minnet lagres på disken. Du kan også deaktivere ekstern stasjon og koble den deretter til igjen.
3. I OS vil stasjonen være definert som for eksempel logisk stasjon F:\.
4. La oss starte R-Studio. Velg vår stasjon (F:\) og klikk på Skann-knappen 
Klikk på bildet for å forstørre det
5. I dialogboksen Skann, i området (Filsystem), klikk på Endre...-knappen og fjern merket for alle boksene. På denne måten vil vi deaktivere søk etter filsystemer og filer ved hjelp av partisjonstabellen. 
Klikk på bildet for å forstørre det
6. Merk av for Ekstra søk etter kjente filtyper. Dette vil tillate R-Studio å søke etter kjente filtyper under skanning.
7. For å starte skanningen, klikk på Skann-knappen.
8. La oss vente mens R-Studio skanner disken. Kategorien Skanneinformasjon vil vise skannefremdriften (fremdrift). 
Klikk på bildet for å forstørre det
9. Etter at skanningen er fullført, velg elementet Extra Found Files og dobbeltklikk på det. 
Klikk på bildet for å forstørre det
10. Testfilene våre vil bli plassert i Sony cam-videoen, XDCam-EX-mappen (eller i en mappe med et annet navn som tilsvarer filtypebeskrivelsen spesifisert i andre trinn). 
Klikk på bildet for å forstørre det
Du ser at filnavn, datoer og plasseringer (mapper) ikke ble gjenopprettet pga denne informasjonen lagret i filsystemet. Derfor vil R-Studio automatisk vise hver fil med et nytt navn.
Det er imidlertid klart at innholdet i filene ikke er skadet. For å bekrefte dette, la oss åpne dem i det aktuelle programmet, for eksempel VLC media player. 
Klikk på bildet for å forstørre det
Konklusjon
R-Studios evne til å skanne etter kjente filtyper lar deg gjenopprette data selv fra en disk hvis filsystemer enten er overskrevet. Du kan søke etter filer ganske effektivt ved å bruke deres signaturer, noe som er spesielt nyttig hvis du vet nøyaktig hvilken type filer som gjenopprettes, som i vårt eksempel. Muligheten til å lage egendefinerte filtyper lar deg legge til en hvilken som helst fil som har en bestemt filsignatur til listen over kjente filtyper.
Mange har kanskje hørt om filer som rarjpeg. Dette er en spesiell type fil, som er et jpeg-bilde og et rar-arkiv som er limt tett sammen. Det er en utmerket beholder for å skjule det faktum å overføre informasjon. Du kan lage en rarjpeg ved å bruke følgende kommandoer:
UNIX: cat image1.jpg archive.rar > image2.jpg
WINDOWS: kopier /b bilde1.jpg+arkiv.rar bilde2.jpg
Eller hvis du har en hex-editor.
Selvfølgelig, for å skjule det faktum å overføre informasjon, kan du bruke ikke bare JPEG-formatet, men også mange andre. Hvert format har sine egne egenskaper, på grunn av hvilke det kan eller kanskje ikke er egnet for rollen som container. Jeg vil beskrive hvordan du kan finne limte filer i de mest populære formatene eller indikere liming.
Metoder for å oppdage sammenslåtte filer kan deles inn i tre grupper:
- Metode for kontroll av området etter EOF-markøren. Mange populære filformater har en såkalt end-of-file-markør, som er ansvarlig for å vise ønsket data. For eksempel leser bildevisere alle byte opp til denne markøren, men området etter den ignoreres. Denne metoden er ideell for følgende formater: JPEG, PNG, GIF, ZIP, RAR, PDF.
- Metode for å sjekke filstørrelse. Strukturen til noen formater (lyd- og videobeholdere) lar deg beregne den faktiske filstørrelsen og sammenligne den med den opprinnelige størrelsen. Formater: AVI, WAV, MP4, MOV.
- Metode for å sjekke CFB-filer. CFB eller Compound File Binary Format er et dokumentformat utviklet av Microsoft, som er en beholder med eget filsystem. Denne metoden er basert på å oppdage uregelmessigheter i en fil.
Er det liv etter slutten av en fil?
JPEG
For å finne svaret på dette spørsmålet, er det nødvendig å fordype seg i spesifikasjonene til formatet, som er "forfedre" til sammenslåtte filer og forstå strukturen. Enhver JPEG starter med signaturen 0xFF 0xD8.Etter denne signaturen er det serviceinformasjon, eventuelt et bildeikon og til slutt selve det komprimerte bildet. I dette formatet er slutten av bildet merket med en to-byte signatur 0xFF 0xD9.
PNG
De første åtte bytene av PNG-filen er okkupert av følgende signatur: 0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A. Sluttsignatur som avslutter datastrømmen: 0x49, 0x45, 0x4E, 0x44, 0xAE, 0x42, 0x60, 0x82.RAR
Felles signatur for alle rar-arkiver: 0x52 0x61 0x72 0x21 (Rar!). Etter det kommer informasjon om arkivversjonen og andre relaterte data. Det ble eksperimentelt bestemt at arkivet slutter med signaturen 0x0A, 0x25, 0x25, 0x45, 0x4F, 0x46.Tabell over formater og deres signaturer:
Algoritmen for å sjekke for liming i disse formatene er ekstremt enkel:
- Finn den første signaturen;
- Finn den endelige signaturen;
- Hvis det ikke er data etter den endelige signaturen, er filen din ren og inneholder ikke vedlegg! Ellers er det nødvendig å se etter andre formater etter den endelige signaturen.
GIF og PDF
Et PDF-dokument kan ha mer enn én EOF-markør, for eksempel på grunn av feil dokumentgenerering. Antall endelige signaturer i en GIF-fil er lik antall rammer i den. Basert på funksjonene til disse formatene, er det mulig å forbedre algoritmen for å sjekke tilstedeværelsen av vedlagte filer.- Punkt 1 gjentas fra forrige algoritme.
- Punkt 2 gjentas fra forrige algoritme.
- Når du finner den endelige signaturen, husk plasseringen og se videre;
- Hvis du når den siste EOF-markøren på denne måten, er filen ren.
- Hvis filen ikke ender med en sluttsignatur, er goto stedet for den siste sluttsignaturen som ble funnet.
glidelås
Det særegne ved ZIP-arkiver er tilstedeværelsen av tre forskjellige signaturer: Strukturen til arkivet er som følger:| Lokal filoverskrift 1 |
| Fildata 1 |
| Databeskrivelse 1 |
| Lokal filoverskrift 2 |
| Fildata 2 |
| Databeskrivelse 2 |
| ... |
| Lokal filoverskrift |
| Fildata n |
| Databeskrivelse n |
| Overskrift for arkivdekryptering |
| Arkiver ekstra datapost |
| Sentral katalog |
For å sjekke et ZIP-arkiv, må du finne sluttsignaturen til den sentrale katalogen, hoppe over 18 byte og se etter signaturer av kjente formater i kommentarfeltet. Stor størrelse Kommentaren indikerer også liming.
Størrelse er viktig
AVI
Strukturen til en AVI-fil er som følger: hver fil begynner med en RIFF-signatur (0x52 0x49 0x46 0x46). På byte 8 er det en AVI-signatur som spesifiserer formatet (0x41 0x56 0x49 0x20). Blokken ved offset 4, bestående av 4 byte, inneholder den opprinnelige størrelsen på datablokken (byte-rekkefølge - little endian). For å finne ut blokknummeret som inneholder neste størrelse, må du legge til overskriftsstørrelsen (8 byte) og størrelsen oppnådd i blokken på 4-8 byte. Dette beregner den totale filstørrelsen. Det er akseptabelt at den beregnede størrelsen kan være mindre enn den faktiske filstørrelsen. Når størrelsen er beregnet, vil filen bare inneholde null byte (nødvendig for å justere 1Kb-grensen).Eksempel på størrelsesberegning:
WAV
Som AVI begynner en WAV-fil med en RIFF-signatur, men denne filen har en signatur fra byte 8 - WAVE (0x57 0x41 0x56 0x45). Filstørrelsen beregnes på samme måte som AVI. Den faktiske størrelsen må samsvare fullstendig med den beregnede.MP4
MP4 eller MPEG-4 er et mediebeholderformat som brukes til å lagre video- og lydstrømmer, og sørger også for lagring av undertekster og bilder.Ved offset 4 byte er det signaturer: filtype ftyp (66 74 79 70) (QuickTime Container File Type) og filundertype mmp4 (6D 6D 70 34). For anerkjennelse skjulte filer, vi er interessert i muligheten til å beregne filstørrelsen.
La oss se på et eksempel. Størrelsen på den første blokken er i offset null, og den er 28 (00 00 00 1C, Big Endian byte-rekkefølge); den indikerer også forskyvningen der størrelsen på den andre datablokken er plassert. Ved offset 28 finner vi neste blokkstørrelse lik 8 (00 00 00 08). For å finne neste blokkstørrelse, må du legge til størrelsene til de forrige blokkene som ble funnet. Dermed beregnes filstørrelsen:
MOV
Dette mye brukte formatet er også en MPEG-4-beholder. MOV bruker en proprietær datakomprimeringsalgoritme, har en struktur som ligner MP4 og brukes til samme formål - for lagring av lyd- og videodata, samt relatert materiale.Som MP4 har enhver mov-fil en 4-byte ftyp-signatur ved offset 4, men den neste signaturen har verdien qt__ (71 74 20 20). Regelen for beregning av filstørrelsen har ikke endret seg: fra begynnelsen av filen beregner vi størrelsen på neste blokk og legger den sammen.
Metoden for å sjekke denne gruppen av formater for tilstedeværelsen av "klebrige" filer er å beregne størrelsen i henhold til reglene gitt ovenfor og sammenligne den med størrelsen på filen som kontrolleres. Hvis den nåværende filstørrelsen er mye mindre enn den beregnede, indikerer dette at det er liming. Når du sjekker AVI-filer, aksepteres det at den beregnede størrelsen kan være mindre enn filstørrelsen på grunn av tilstedeværelsen av lagt til nuller for å justere grensen. I dette tilfellet er det nødvendig å se etter nuller etter den beregnede filstørrelsen.
Sjekker sammensatt fil binært format
Dette filformatet, utviklet av Microsoft, er også kjent som OLE (Object Linking and Embedding) eller COM (Component Object Model). DOC, XLS, PPT-filer tilhører gruppen av CFB-formater.En CFB-fil består av en 512-byte overskrift og sektorer av lik lengde som lagrer datastrømmer eller tjenesteinformasjon. Hver sektor har sitt eget ikke-negative nummer, med unntak av spesielle tall: "-1" - nummererer den frie sektoren, "-2" - nummererer sektoren som lukker kjeden. Alle sektorkjeder er definert i FAT-tabellen.
La oss anta at en angriper modifiserte en bestemt .doc-fil og limte inn en annen fil på slutten av den. Det er noen få på ulike måter oppdage det eller indikere en anomali i dokumentet.
Unormal filstørrelse
Som nevnt ovenfor, består enhver CFB-fil av en overskrift og sektorer av samme lengde. For å finne ut sektorstørrelsen, må du lese et to-byte tall ved offset 30 fra begynnelsen av filen og heve 2 til potensen av dette tallet. Dette tallet må være lik henholdsvis 9 (0x0009) eller 12 (0x000C), filsektorstørrelsen er 512 eller 4096 byte. Etter å ha funnet sektoren, må du sjekke følgende likhet:(Filstørrelse - 512) mod SectorSize = 0
Hvis denne likheten ikke er oppfylt, kan du påpeke faktumet med å lime filene. Imidlertid har denne metoden en betydelig ulempe. Hvis en angriper kjenner til sektorstørrelsen, trenger han bare å lime inn filen sin og ytterligere n byte slik at størrelsen på de limte dataene er et multiplum av sektorstørrelsen.
Ukjent sektortype
Hvis angriperen vet om en metode for å omgå den forrige kontrollen, da denne metoden kan oppdage tilstedeværelsen av sektorer med udefinerte typer.La oss definere likhet:
FileSize = 512 + CountReal * SectorSize, der FileSize er filstørrelsen, SectorSize er sektorstørrelsen, CountReal er antall sektorer.
Vi definerer også følgende variabler:
- CountFat – antall FAT-sektorer. Plassert ved offset 44 fra begynnelsen av filen (4 byte);
- CountMiniFAT – antall MiniFAT-sektorer. Plassert ved offset 64 fra begynnelsen av filen (4 byte);
- CountDIFAT – antall DIFAT-sektorer. Plassert ved offset 72 fra begynnelsen av filen (4 byte);
- CountDE – antall Directory Entry-sektorer. For å finne denne variabelen må du finne den første sektoren DE, som er på offset 48. Da er det nødvendig å få en fullstendig representasjon av DE fra FAT og telle antall DE-sektorer;
- CountStreams – antall sektorer med datastrømmer;
- CountFree – antall frie sektorer;
- CountClassified – antall sektorer med en bestemt type;
Selvfølgelig, hvis CountClassified og CountReal er ulik, kan vi konkludere med at filer kan slås sammen.
Sjefen min ga meg en ganske interessant oppgave. På kort tid kan du skrive en kjørbar filanalysator som vil kunne finne viruskropper basert på signaturer og bestemme pakkeren/kryptoren som brukes. Den ferdige prototypen dukket opp i løpet av et par timer.
Forfatterens ord
Signaturanalyse
Å søke etter et ondsinnet objekt ved hjelp av signaturer er noe ethvert antivirus kan gjøre. Generelt er en signatur en formalisert beskrivelse av visse egenskaper som gjør det mulig å fastslå at filen som skannes er et virus og et veldefinert virus.
Det er ulike teknikker her. Et alternativ er å bruke en signatur som består av N byte av et skadelig objekt. I dette tilfellet kan du ikke gjøre en dum sammenligning, men en sammenligning med en eller annen maske (som å lete etter byte EB ?? ?? CD 13). Eller angi tilleggsbetingelser som "slike og slike bytes må være ved inngangspunktet til programmet" og så videre. Signaturen til skadevaren er en spesiell sak.
På samme måte beskrives noen tegn som man kan fastslå at den kjørbare filen er pakket med en eller annen kryptor eller pakker (for eksempel den banale ASPack). Hvis du leser magasinet vårt nøye, har du definitivt hørt om et slikt verktøy som PEiD, som er i stand til å identifisere de mest brukte pakkere, kryptor og kompilatorer (databasen har et stort antall signaturer) for PE-filen som er overført til den . Akk, nye versjoner av programmet har ikke blitt utgitt på lenge, og nylig dukket det opp en melding på den offisielle nettsiden om at prosjektet ikke vil ha videre utvikling. Det er synd, fordi egenskapene til PEiD (spesielt med tanke på plugin-systemet) kan være nyttige for meg. Etter en kort analyse ble det klart at dette ikke var et alternativ. Men etter å ha gravd i engelskspråklige blogger fant jeg raskt hva som passet meg. YARA-prosjekt (code.google.com/p/yara-project).
Hva er YARA?
Helt fra begynnelsen var jeg overbevist om at det et sted på Internett allerede fantes en åpen kildekode-utvikling som ville ta på seg oppgaven med å bestemme samsvaret mellom en bestemt signatur og filen som undersøkes. Hvis jeg kunne finne et slikt prosjekt, så kunne det lett settes på skinnene i en webapplikasjon, legge til forskjellige signaturer der og få det som kreves av meg. Planen begynte å virke enda mer realistisk da jeg leste beskrivelsen av YARA-prosjektet.
Utviklerne selv posisjonerer det som et verktøy for å hjelpe skadevareforskere med å identifisere og klassifisere ondsinnede prøver. Forskeren kan lage beskrivelser for forskjellige typer skadelig programvare som bruker tekst eller binære mønstre som beskriver de formaliserte egenskapene til skadelig programvare. Slik oppnås signaturer. Faktisk består hver beskrivelse av et sett med linjer og noen logiske uttrykk, på grunnlag av hvilke analysatorens utløsende logikk bestemmes.
Hvis betingelsene i en av reglene er oppfylt for filen som undersøkes, bestemmes den deretter (for eksempel en slik og en orm). Et enkelt eksempel på en regel for å forstå hva vi snakker om:
regel silent_banker: banker
{
meta:
description = "Dette er bare et eksempel"
trådnivå = 3
in_the_wild = sant
strenger:
$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"
betingelse:
$a eller $b eller $c
}
I denne regelen forteller vi YARA at enhver fil som inneholder minst én av prøvestrengene beskrevet i variablene $a, $b, $c skal klassifiseres som en silent_banker-trojaner. Og dette er en veldig enkel regel. I virkeligheten kan regler være mye mer komplekse (vi snakker om dette nedenfor).
Til og med listen over prosjekter som bruker den snakker om autoriteten til YARA-prosjektet, og dette er:
- VirusTotal Malware Intelligence Services (vt-mis.com);
- jsunpack-n (jsunpack.jeek.org);
- Vi ser på nettstedet ditt (wewatchyourwebsite.com).
All kode er skrevet i Python, og brukeren tilbys både selve modulen for bruk i deres utvikling, og rett og slett en kjørbar fil for å bruke YARA som en frittstående applikasjon. Som en del av arbeidet mitt valgte jeg det første alternativet, men for enkelhets skyld vil vi i denne artikkelen ganske enkelt bruke analysatoren som en konsollapplikasjon.
Etter litt graving fant jeg raskt ut hvordan jeg skulle skrive regler for YARA, samt hvordan jeg fester virussignaturer fra freeware og pakkere fra PEiD til den. Men vi starter med installasjonen.
Installasjon
Som jeg allerede har sagt, er prosjektet skrevet i Python, så det kan enkelt installeres på Linux, Windows og Mac. Først kan du bare ta den binære. Hvis vi kaller opp applikasjonen i konsollen, får vi reglene for lansering.
$yara
bruk: yara ... ... FIL | PID
Det vil si at formatet for å ringe programmet er som følger: først er det navnet på programmet, deretter en liste over alternativer, hvoretter filen med reglene er angitt, og helt til slutt - navnet på filen som undersøkt (eller katalogen som inneholder filene), eller prosessidentifikatoren. Nå vil jeg gjerne forklare på en god måte hvordan disse reglene er utarbeidet, men jeg vil ikke umiddelbart belaste deg med tørr teori. Derfor vil vi gjøre ting annerledes og låne andres signaturer slik at YARA kan utføre en av oppgavene vi har satt - en fullverdig påvisning av virus ved hjelp av signaturer.
Ditt eget antivirus
Det viktigste spørsmålet: hvor får man tak i databasen med signaturer til kjente virus? Antivirusselskaper deler aktivt slike databaser seg imellom (noen mer sjenerøst, andre mindre). For å være ærlig tvilte jeg til og med på at noen på Internett et sted på Internett åpenlyst ville legge ut slike ting. Men, som det viste seg, er det flinke folk. En passende database fra det populære antivirusprogrammet ClamAV er tilgjengelig for alle (clamav.net/lang/en). I delen "Siste stabile utgivelser" kan du finne en lenke til siste versjon antivirusprodukt, samt lenker for å laste ned ClamAV-virusdatabaser. Vi vil først og fremst være interessert i filene main.cvd (db.local.clamav.net/main.cvd) og daily.cvd (db.local.clamav.net/daily.cvd).
Den første inneholder hoveddatabasen med signaturer, den andre inneholder den mest komplette databasen dette øyeblikket base med ulike tillegg. Daily.cvd, som inneholder mer enn 100 000 malware-visninger, er ganske tilstrekkelig for dette formålet. ClamAV-databasen er imidlertid ikke en YARA-database, så vi må konvertere den til ønsket format. Men hvordan? Tross alt vet vi ennå ikke noe om hverken ClamAV-formatet eller Yara-formatet. Dette problemet har allerede blitt tatt hånd om før oss ved å utarbeide et lite skript som konverterer ClamAV-virussignaturdatabasen til et sett med YARA-regler. Manuset heter clamav_to_yara.py og er skrevet av Matthew Richard (bit.ly/ij5HVs). Last ned skriptet og konverter databasene:
$ python clamav_to_yara.py -f daily.cvd -o clamav.yara
Som et resultat vil vi i clamav.yara-filen motta en signaturdatabase som umiddelbart er klar til bruk. La oss nå prøve kombinasjonen av YARA og ClamAV-databasen i aksjon. Skanning av en mappe ved hjelp av en signatur utføres med én enkelt kommando:
$ yara -r clamav.yara /pentest/msf3/data
Alternativet -r spesifiserer at skanningen skal utføres rekursivt på tvers av alle undermapper i gjeldende mappe. Hvis det var noen viruslegemer i /pentest/msf3/data-mappen (minst de som er i ClamAV-databasen), vil YARA umiddelbart rapportere dette. I prinsippet er dette en ferdiglaget signaturskanner. For større bekvemmelighet skrev jeg et enkelt skript som sjekket ClamAV-databaseoppdateringer, lastet ned nye signaturer og konverterte dem til YARA-formatet. Men dette er allerede detaljer. En del av oppgaven er fullført, nå kan du begynne å utarbeide regler for identifisering av pakkere/kryptorer. Men for å gjøre dette måtte jeg forholde meg litt til dem.
Spill etter reglene
Så en regel er hovedmekanismen til et program som lar deg tilordne en gitt fil til en bestemt kategori. Reglene er beskrevet i en egen fil (eller filer) og ligner i utseende veldig på struct()-konstruksjonen fra C/C++-språket.
regel BadBoy
{
strenger:
$a = "win.exe"
$b = "http://foo.com/badfi le1.exe"
$c = "http://bar.com/badfi le2.exe"
betingelse:
$a og ($b eller $c)
}
I prinsippet er det ikke noe komplisert i å skrive regler. I denne artikkelen berørte jeg bare hovedpunktene, og du finner detaljene i håndboken. Foreløpig de ti viktigste punktene:
1. Hver regel begynner med nøkkelordregelen, etterfulgt av regelidentifikatoren. Identifikatorer kan ha samme navn som variabler i C/C++, det vil si at de kan bestå av bokstaver og tall, og det første tegnet kan ikke være et tall. Maksimal lengde identifikatornavn - 128 tegn.
2. Vanligvis består regler av to seksjoner: en definisjonsdel (strenger) og en betingelsesdel (betingelse). Stringsdelen spesifiserer data på grunnlag av hvilke betingelsesdelen vil avgjøre om en gitt fil tilfredsstiller visse betingelser.
3. Hver linje i strengdelen har sin egen identifikator, som begynner med $-tegnet - generelt som en variabeldeklarasjon i PHP. YARA støtter vanlige strenger innesluttet doble anførselstegn("") og heksadesimale strenger omsluttet av tannregulering(()), samt regulære uttrykk:
$my_text_string = "tekst her"
$my_hex_string = ( E2 34 A1 C8 23 FB )
4. Betingelsesdelen inneholder all logikken til regelen. Denne delen må inneholde et boolsk uttrykk som bestemmer når en fil eller prosess samsvarer med regelen. Vanligvis refererer denne delen til tidligere deklarerte linjer. Og strengidentifikatoren behandles som en boolsk variabel som returnerer sann hvis strengen ble funnet i filen eller prosessminnet, og ellers usann. Regelen ovenfor spesifiserer at filer og prosesser som inneholder strengen win.exe og en av de to URL-ene skal kategoriseres som BadBoy (etter regelnavnet).
5. Heksadesimale strenger tillater tre konstruksjoner som gjør dem mer fleksible: jokertegn, hopp og alternativer. Substitusjoner er steder i en streng som er ukjente og kan erstattes av en hvilken som helst verdi. De er indikert med symbolet "?":
$hex_string = ( E2 34 ?? C8 A? FB )
Denne tilnærmingen er veldig praktisk når du spesifiserer strenger hvis lengde er kjent, men innholdet kan variere. Hvis en del av en streng kan ha forskjellig lengde, er det praktisk å bruke områder:
$hex_string = ( F4 23 62 B4 )
Denne oppføringen betyr at det i midten av linjen kan være fra 4 til 6 forskjellige byte. Du kan også implementere et alternativt valg:
$hex_string = ( F4 23 (62 B4 | 56) 45 )
Dette betyr at i stedet for den tredje byten kan det være 62 B4 eller 56, en slik oppføring tilsvarer linjene F42362B445 eller F4235645.
6. For å kontrollere at en gitt streng har en spesifikk forskyvning i et fil- eller prosessadresserom, brukes at-operatøren:
$a ved 100 og $b ved 200
Hvis strengen kan være innenfor et bestemt adresseområde, brukes in-operatoren:
$a in (0..100) og $b in (100..fi lesize)
Noen ganger oppstår det situasjoner når du må spesifisere at en fil skal inneholde et visst antall fra et gitt sett. Dette gjøres ved å bruke operatøren av:
regel av eksempel1
{
strenger:
$foo1 = "dummy1"
$foo2 = "dummy2"
$foo3 = "dummy3"
betingelse:
2 av ($foo1,$foo2,$foo3)
}
Regelen ovenfor krever at filen inneholder to linjer fra settet ($foo1,$foo2,$foo3). I stedet for å spesifisere et spesifikt antall linjer i filen, kan du bruke variablene any (minst én linje fra et gitt sett) og alle (alle linjer fra et gitt sett).
7. Vel, den siste interessante muligheten som må vurderes er å bruke én betingelse på mange rader. Denne funksjonen er veldig lik operatøren, bare kraftigere er operatørens for..:
for uttrykk for strengsett: (boolsk uttrykk)
Denne oppføringen bør leses slik: av strengene som er spesifisert i string_-settet, må minst uttrykksstykkene tilfredsstille boolean_expression-betingelsen. Eller med andre ord: det boolske uttrykket evalueres for hver streng i strengsettet, og uttrykkene fra dem må returnere True. Deretter skal vi se på denne konstruksjonen ved å bruke et spesifikt eksempel.
Lage PEiD
Så når alt har blitt mer eller mindre klart med reglene, kan vi begynne å implementere en detektor av pakkere og kryptor i prosjektet vårt. Først, som kildemateriale, lånte jeg signaturene til kjente pakkere fra samme PEiD. I plugins-mappen er det en fil userdb.txt, som inneholder det vi trenger. Det var 1850 signaturer i databasen min.
Ganske mye, så for å kunne importere dem fullt ut, anbefaler jeg deg å skrive et slags manus. Formatet til denne databasen er enkelt - den vanlige brukes tekstfil, som lagrer 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ørste linjen spesifiserer navnet på pakkeren, som vil vises i PEiD, men for oss vil det være regelidentifikatoren. Den andre er selve signaturen. Det tredje er ep_only-flagget, som indikerer om det skal søkes etter en gitt linje kun ved inngangspunktadressen, eller gjennom hele filen.
Vel, la oss prøve å lage en regel, for eksempel, for ASPack? Som det viser seg, er det ikke noe komplisert med dette. La oss først lage en fil for å lagre reglene og kalle den for eksempel packers.yara. Deretter søker vi i PEiD-databasen etter alle signaturer som inkluderer ASPack i navnene og overfører dem til regelen:
regel ASPack
{
strenger:
$ = ( 60 E8 ?? ?? ?? ?? 5D 81 ED ?? ?? (43 | 44) ?? B8 ?? ?? (43 | 44) ?? 03 C5 )
$ = ( 60 EB ?? 5D EB ?? FF ?? ?? ?? ?? ?? E9 )
[.. kutte opp..]
$ = ( 60 E8 03 00 00 00 E9 EB 04 5D 45 55 C3 E8 01 )
betingelse:
for noen av dem: ($ved inngangspunkt)
}
Alle funnet poster har ep_only-flagget satt til true, det vil si at disse linjene må være plassert på inngangspunktadressen. Derfor skriver vi følgende betingelse: "for noen av dem: ($ved inngangspunkt)".
Dermed vil tilstedeværelsen av minst én av de gitte linjene ved inngangspunktadressen bety at filen er pakket med ASPack. Vær også oppmerksom på at i denne regelen er alle linjer spesifisert ved å bruke $-tegnet, uten en identifikator. Dette er mulig fordi vi i tilstandsdelen ikke får tilgang til noen spesifikke, men bruker hele settet.
For å sjekke funksjonaliteten til det resulterende systemet, kjør bare kommandoen i konsollen:
$ yara -r packers.yara somefi le.exe
Etter å ha matet et par applikasjoner pakket med ASPack der, var jeg overbevist om at alt fungerte!
Klar prototype
YARA viste seg å være et ekstremt klart og gjennomsiktig verktøy. Det var ikke vanskelig for meg å skrive en webadmin for den og sette den opp til å fungere som en nettjeneste. Med litt kreativitet er de tørre resultatene til analysatoren allerede farget i forskjellige farger, noe som indikerer graden av fare for den oppdagede skadevare. En liten oppdatering av databasen, og for mange av kryptografene er en kort beskrivelse tilgjengelig, og noen ganger til og med utpakkingsinstruksjoner. Prototypen er laget og fungerer perfekt, og sjefene danser av glede!
Funksjonskoden (FC) i telegramoverskriften identifiserer telegramtypen, for eksempel Request-telegram (Request or Send/Request) og Acknowledgement or Response-telegram (Acknowledgement Frame, Response Frame). I tillegg inneholder funksjonskoden selve overføringsfunksjonen og kontrollinformasjon som forhindrer tap og duplisering av meldinger, eller stasjonstypen med FDL-status.
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | FC: Funksjonskodeforespørsel |
| 1 | Be om telegram | |||||||
| X | FCV = Alternerende bit slått på | |||||||
| X | href=”http://profibus.felser.ch/en/funktionscode.htm#aufruffolgebit”>FCB = Alternerende bit (fra antall bilder) | |||||||
| 1 | 0 (0x0) | CV = Klokkeverdi() | ||||||
| 1 | annen | Forbeholdt | ||||||
| 0 | 0 (0x0) | TE = Time Event (klokkesynkronisering) | ||||||
| 0 | 3 (0x3) | SDA_LOW = Send data bekreftet - lav prioritet | ||||||
| 0 | 4 (0x4) | SDN_LOW = Send data ikke bekreftet - lav prioritet | ||||||
| 0 | 5 (0x5) | SDA_HIGH = Send data bekreftet - høy prioritet | ||||||
| 0 | 6 (0x6) | SDN_HIGH = Send data ikke bekreftet | ||||||
| 0 | 7 (0x7) | MSRD = Send forespørselsdata med Multicast-svar | ||||||
| 0 | 9 (0x9) | Be om FDL-status | ||||||
| 0 | 12(0xC) | SRD lav = Send og be om data | ||||||
| 0 | 13(0xD) | SRD høy = Send og be om data | ||||||
| 0 | 14(0xE) | Be om ID med svar | ||||||
| 0 | 15 (0xF) | Be om LSAP Status med svar 1) | ||||||
| 0 | annen | Forbeholdt | ||||||
1) denne verdien er i den siste versjonen av standarden ikke lenger definert, men kun reservert
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | FC: Funksjonskoderespons |
| 0 | Svartelegram | |||||||
| 0 | Forbeholdt | |||||||
| 0 | 0 | Slave | ||||||
| 0 | 1 | Mester ikke klar | ||||||
| 1 | 0 | Mester klar, uten token | ||||||
| 1 | 1 | Master klar, i token ring | ||||||
| 0 (0x0) | OK | |||||||
| 1 (0x1) | UE = Brukerfeil | |||||||
| 2 (0x2) | RR = Ingen ressurser | |||||||
| 3 (0x3) | RS = SAP ikke aktivert | |||||||
| 8 (0x8) | DL = Data Low (normalt tilfelle med DP) | |||||||
| 9 (0x9) | NR = Ingen responsdata klar | |||||||
| 10(0xA) | DH = Data høy (DP-diagnose venter) | |||||||
| 12(0xC) | RDL = Data ikke mottatt og Data lav | |||||||
| 13(0xD) | RDH = Data ikke mottatt og Data høy | |||||||
| annen | Forbeholdt | |||||||
Frame Count Bit Frame Count Bit FCB (b5) forhindrer meldingsduplisering av den bekreftende eller svare stasjon (responder) og ethvert tap av den anropende stasjon (initiator). Unntatt fra dette er forespørsler uten bekreftelse (SDN) og forespørsler om FDL Status, Ident og LSAP Status.
For sikkerhetssekvensen må initiativtakeren ha en FCB for hver responder. Når et forespørselstelegram (Request eller Send/Request) sendes til en responder for første gang, eller hvis det sendes på nytt til en responder som for øyeblikket er merket som ikke-operativ, må FCB settes som definert i responderen. Initiativtakeren oppnår dette i et Request-telegram med FCV=0 og FCB=1. Reageren må vurdere et telegram av denne typen som den første meldingssyklusen og lagre FCB=1 sammen med initiatorens adresse (SA) (se følgende tabell). Denne meldingssyklusen vil ikke bli gjentatt av initiativtakeren. I påfølgende forespørselstelegrammer til samme responder må initiativtakeren sette FCV=1 og endre FCB med hvert nytt forespørselstelegram. Enhver responder som mottar et forespørselstelegram adressert til den med FCV=1 må evaluere FCB. Hvis FCB har endret seg sammenlignet med siste forespørselstelegram fra samme initiator (samme SA), er dette en gyldig bekreftelse på at den foregående meldingssyklusen ble avsluttet på riktig måte. Hvis Request-telegrammet kommer fra en annen initiativtaker (annen SA), er evaluering av FCB ikke lenger nødvendig. I begge tilfeller må responderen lagre FCB med kilden SA inntil mottak av et nytt telegram adressert til den. I tilfelle av et tapt eller svekket bekreftelses- eller svartelegram, må ikke FCB endres av initiativtakeren i forespørselen på nytt: dette vil indikere at forrige meldingssyklus var feil. Hvis responderen mottar et forespørselstelegram med FCV=1 og samme FCB som det siste forespørselstelegrammet fra samme initiativtaker (samme SA), vil dette indikere et nytt forsøk. Respondenten må i sin tur videresende bekreftelses- eller svartelegrammet som holdes i beredskap. Inntil ovennevnte bekreftelse eller mottak av et telegram med en annen adresse (SA eller DA) som ikke er bekreftet (Send Data with No Acknowledge, SDN) må svarpersonen holde den siste bekreftelsen eller svartelegrammet klar for enhver mulig forespørsel på nytt . I tilfelle av forespørselstelegrammer som ikke er bekreftet og med forespørsel FDL-status, ID og LSAP-status, FCV=0 og FCB=0; evaluering av responderen er ikke lenger nødvendig.
| b5 | b4 | Bitposisjon | ||
| FCB | FCV | Betingelse | Betydning | Handling |
| 0 | 0 | DA = TS/127 | Forespørsel uten bekreftelse Be om FDL Status/ Ident/ LSAP Status |
Slett siste bekreftelse |
| 0/1 | 0/1 | DA#TS | Forespørsel til en annen responder | |
| 1 | 0 | DA = TS | Første forespørsel | FCBM:= 1 SAM:=SA Slett siste bekreftelse/svar |
| 0/1 | 1 | DA = TS SA = SAM FCB#FCBM |
Ny forespørsel | Slett siste bekreftelse/svar FCBM:=FCB Hold bekreftelse/svar klar for nytt forsøk |
| 0/1 | 1 | DA = TS SA = SAM FCB = FCBM |
Prøv forespørsel på nytt | FCBM:=FCB Gjenta bekreftelse/svar og fortsett å holde beredskapen |
| 0/1 | 1 | DA = TS SA#SAM |
Ny initiativtaker | FCBM:=FCB SAM:= SA Hold bekreftelse/svar klar for nytt forsøk |
FCBM lagret FCB i minnet SAM lagret SA i minnet
