Креирање на прилагоден познат тип на датотека за R-Studio. Одредување тип на датотека по потпис Што е потпис на датотека
Концепт " Магичен број„во програмирањето има три значења:
- Потпис на податоци
- Избрани единствени вредности, што не треба да биде исто како и другите вредности (на пр. UUID)
- Лоша практика на програмирање.
Потпис на податоци
Магичен број, или потпис, - цел број или текстуална константа што се користи за уникатно идентификување на ресурс или податоци. Таков број сам по себе нема никакво значење и може да предизвика забуна доколку се појави во програмскиот код без соодветен контекст или коментар, додека обидот да се смени во друг, дури и со блиска вредност, може да доведе до целосно непредвидливи последици. Поради оваа причина, таквите броеви иронично беа наречени магични броеви. Во моментов, ова име е цврсто воспоставено како термин. На пример, секоја компајлирана класа на Јава јазик започнува со хексадецималниот „магичен број“ 0xCAFEBABE. Вториот нашироко познат пример е кој било извршна датотекаОС Microsoft Windowsсо наставката .exe започнува со бајтната секвенца 0x4D5A (што одговара на ASCII знаците MZ - иницијалите на Марк Збиковски, еден од креаторите на MS-DOS). Помалку познат пример е неиницијализираниот покажувач во Microsoft Visual C++ (од верзијата на Microsoft Visual Studio од 2005 година), кој ја има адресата 0xDEADBEEF во режим за отстранување грешки.
Во UNIX-како оперативни системиТипот на датотеката обично се одредува со потписот на датотеката, без оглед на проширувањето на неговото име. Тие обезбедуваат стандардна алатка за датотеки за толкување на потписот на датотеката.
Лоша практика на програмирање
Исто така наречено „магични броеви“ е лоша програмска практика кога се појавува нумеричка вредност во изворниот текст и не е очигледно што значи тоа. На пример, фрагмент како овој, напишан на Java, би бил лош:
drawSprite(53, 320, 240);
конечна int SCREEN_WIDTH = 640 ; конечна интенција SCREEN_HEIGHT = 480 ; конечна интенција SCREEN_X_CENTER = SCREEN_WIDTH / 2; конечна интенција SCREEN_Y_CENTER = SCREEN_HEIGHT / 2 ; конечна инт SPRITE_CROSSHAIR = 53 ; ... drawSprite(SPRITE_CROSSHAIR, SCREEN_X_CENTER, SCREEN_Y_CENTER);
Сега е јасно: оваа линија прикажува спрајт - нишан на глетката - во центарот на екранот. Во повеќето програмски јазици, сите вредности што се користат за таквите константи ќе се пресметуваат во времето на компајлирање и ќе се заменат во местата каде што се користат вредностите. Затоа, таквата промена на изворниот текст не ја деградира работата на програмата.
Покрај тоа, магичните броеви се потенцијален извор на грешки во програмата:
- Ако истиот магичен број се користи повеќе од еднаш во програмата (или може потенцијално да се користи), тогаш неговото менување ќе бара измени на секоја појава (наместо само едно уредување на вредноста на именуваната константа). Ако не се поправат сите појави, ќе се појави барем една грешка.
- Во барем една од појавите, магичниот број првично може да биде погрешно напишан, а тоа е доста тешко да се открие.
- Магичниот број може да зависи од имплицитен параметар или друг магичен број. Ако овие зависности, кои не се експлицитно идентификувани, не се задоволени, ќе се појави барем една грешка.
- Кога се менуваат појавите на еден магичен број, можно е погрешно да се смени друг магичен број кој е независен, но има иста нумеричка вредност.
Магични броеви и крос-платформа
Понекогаш волшебните броеви му наштетуваат на кодот на повеќе платформи. Факт е дека во C, на 32- и 64-битни оперативни системи, големината на типовите char , кратки и долги долги е загарантирана, додека големината на int , long , size_t и ptrdiff_t може да се менува (за првите два, во зависност од преференциите на развивачите на компајлерот, за последните две - во зависност од битниот капацитет на целниот систем). Во стариот или лошо напишан код, може да има „магични броеви“ кои ја означуваат големината на типот - кога се префрлате на машини со различен бит капацитет, тие може да доведат до суптилни грешки.
На пример:
const size_t NUMBER_OF_ELEMENTS = 10 ; долга [NUMBER_OF_ELEMENTS]; мемсет (a, 0, 10 * 4); // неточно - долго се претпоставува дека е 4 бајти, се користи магичен број на елементи memset(a, 0, NUMBER_OF_ELEMENTS * 4); // неточно - долго се претпоставува дека е 4 бајтимемсет(а, 0, NUMBER_OF_ELEMENTS * големина (долго)); // не е сосема точно - дуплирање на името на типот (ако се промени типот, ќе мора да го промените и овде)мемсет (a , 0 , NUMBER_OF_ELEMENTS * големина (a [ 0 ])); // точен, оптимален за динамички низи со ненулта големина memset(a, 0, sizeof(a)); // точно, оптимално за статични низи
Броеви кои не се магични
Не треба сите броеви да се претвораат во константи. На пример, кодот за
Пребарувањето со скенирање датотеки од познати типови (или, како што често се вели, пребарување датотеки со потпис) е едно од најефикасните што се користат во алатката за обновување податоци R-Studio. Користењето на даден потпис ви овозможува да ги вратите датотеките од одреден тип во случаи кога информациите за структурата на директориумот и имињата на датотеките делумно или целосно недостасуваат (оштетени).
Вообичаено, табелата за партиции на дискот се користи за одредување на локацијата на датотеките. Ако споредите диск со книга, табелата со партиции ќе биде слична на нејзината содржина. При скенирање, R-Studio бара познати типови датотеки во табелата со партиции на дискот користејќи одредени наведени потписи. Ова е овозможено со фактот што практично секој тип на датотека има уникатен потпис или шема на податоци. Потписите на датотеката се наоѓаат на одредена локација на почетокот на датотеката и во многу случаи и на крајот од датотеката. При скенирање, R-Studio ги совпаѓа пронајдените податоци со потписи на познати типови на датотеки, што овозможува нивно идентификување и враќање на нивните податоци.
Користејќи ја технологијата за скенирање познати типови датотеки, R-Studio ви овозможува да ги вратите податоците од дисковите што се преформатирани и чии табели со партиции се препишани. Освен тоа, ако партицијата на дискот е препишана, оштетена или избришана, тогаш скенирањето познати типови на датотеки е единствената опција.
Но, речиси сè има свои недостатоци, а познатите типови датотеки што се користат во R-Studio не се исклучок. Значи, кога скенирате познати типови датотеки, R-Studio ви овозможува да ги вратите само нефрагментираните датотеки, но, како што веќе споменавме, во повеќето случаи ова е најновиот можен метод.
R-Studio веќе вклучува потписи на најчестите типови на датотеки (поглед целосна листадатотеките од познати типови може да се најдат во делот R-Studio Online Help.)
Доколку е потребно, корисникот може да додаде нови типови на датотеки во R-Studio. На пример, ако треба да најдете датотеки од уникатен тип, или оние развиени по последниот датум на издавање на R-Studio, можете да додадете свои потписи во датотеките од познати типови. Овој процес ќе се дискутира понатаму.
Прилагодени датотеки од познати типови
Во XML датотека e наведено во полето за дијалог Settings. Додавањето потпис се состои од два дела:
- Одредување на потписот на датотеката лоциран на почетокот на датотеката и, доколку е присутен, на крајот од датотеката.
- Генерирајте XML-датотека која содржи потпис на датотека и други информации за типот на датотеката.
Сето ова може да се направи со помош на R-Studio. Во исто време, не треба да бидете експерт во областа на составување (уредување) XML документи или во областа на хексадецимално уредување - во овој водич (напис), кој е наменет за самиот корисник влезно ниво, сите фази од овој процес ќе бидат детално разгледани.
Пример: Додавање потпис за датотека MP4 (кодек XDCam-EX)
Ајде да погледнеме како додаваме потпис на датотека користејќи го примерот на датотека .MP4 создадена со помош на Sony XDCAM-EX. Можете да го користите, на пример, во случај на оштетување на SD-картичката за датотеки што сè уште не сте успеале да ги зачувате на тврдиот диск на вашиот компјутер.
Прва фаза: Одредување на потпис на датотека
За да го одредите потписот на датотеката, разгледајте примери на датотеки со ист формат.
Нека се ова четири видео датотеки од Sony XDCAM-EX:
ZRV-3364_01.MP4
ZRV-3365_01.MP4
ZRV-3366_01.MP4
ZRV-3367_01.MP4
За полесно разгледување, нека бидат мали датотеки. Поголемите датотеки потешко се гледаат во хексадецимално.
1. Отворете ги датотеките во R-Studio. За да го направите ова, кликнете со десното копче на секоја датотека и изберете View/Edit од контекстното мени.
2. Да ги споредиме датотеките. Ќе ја бараме истата шема пронајдена во сите четири датотеки. Тој ќе се појави потпис на датотека. Вообичаено, потписите на датотеката се наоѓаат на почетокот на датотеката, но понекогаш и на крајот.
3. Дефинирајте го потписот на датотеката на почетокот на датотеката. Во нашиот пример, таа се наоѓа на самиот почеток на датотеката. Забележете дека тоа не се случува секогаш - честопати потписот на датотеката е на почетокот на датотеката, но не и на првата линија (офсет).
Од сликите подолу, се чини дека содржината на сите четири датотеки е различна, но сите тие започнуваат со ист потпис на датотеката. 
Кликнете на сликата за да ја зголемите
Кликнете на сликата за да ја зголемите
Кликнете на сликата за да ја зголемите
Кликнете на сликата за да ја зголемите
Означената област на сликите е потпис на датотека од овој типдатотеки. Тој е претставен и во текст и во хексадецимален формат.
Во текстуална форма, потписот на датотеката изгледа вака:
....ftypmp42....mp42.........бесплатно
Точките („“) означуваат знаци што не можат да се претстават во текстуална форма. Затоа, исто така е неопходно да се обезбеди хексадецимална форма на потписот на датотеката:
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. На ист начин, го дефинираме потписот на датотеката, но на самиот крај на датотеката. Може да биде различен потпис на датотека, различна должина.
Сликите подолу го истакнуваат потписот на датотеката на крајот од датотеката: 
Кликнете на сликата за да ја зголемите
Кликнете на сликата за да ја зголемите
Кликнете на сликата за да ја зголемите
Кликнете на сликата за да ја зголемите
Имајте предвид дека податоците пред избраната област (потпис на датотека) се исти во сите четири датотеки. Ова е техничка информација што не е потпис на датотека, но укажува дека сите четири слики (датотеки) се направени со користење на иста камера со исти параметри. Вообичаено е можно да се разликуваат моделите што се совпаѓаат со техничките информации од потписот на датотеката. Во нашиот пример, во последната линија пред почетокот на потписот на датотеката, го гледаме текстот „RecordingMode type=“normal““, што јасно покажува дека ова е некој вид параметар на датотека, а не потпис. Секогаш посветувајте посебно внимание на оваа линија за да не ја вклучите погрешно техничка информацијадел од потписот на датотеката.
Во нашиот случај, потписот на датотеката е следниов текст:
...
Да ве потсетиме дека точките означуваат знаци кои не можат да се претстават во текстуална форма.
Во хексадецимален, потписот на датотеката изгледа вака:
3N 2F 4E 6F 6E 52 65 61 6N 54 69 6A 65 4A 65 74 61 3E 0D 0A 00
Ве молиме имајте предвид: потписот нема секогаш да биде на крајот од датотеката.
Втора фаза: Креирање XML-датотека која опишува познат тип на датотека
Сега, откако го дефиниравте потписот на датотеката, можете да креирате XML-датотека и да го вклучите соодветниот тип на датотека во R-Studio. Ова може да се направи на два начина:
2.1 Користење на вградено графички уредникпотписи на датотеки:
Изберете ја ставката Поставки од менито Алатки, во полето за дијалог Поставки што се отвора, кликнете на јазичето Познати типови датотеки и потоа кликнете на копчето Уреди типови датотеки на корисникот. 
Кликнете на сликата за да ја зголемите
Кликнете на копчето Креирај тип на датотека во полето за дијалог Уреди типови датотеки на корисникот.
Поставете ги следните опции:
- ИД - единствен дигитален идентификатор. Овој бројќе бидат избрани по случаен избор; Единственото нешто е што не треба да одговара на дигиталниот идентификатор на кој било друг тип на датотека.
- Опис на групата - групата во која ќе се наоѓаат пронајдените датотеки во R-Studio. Можете да поставите или нова група, или изберете една од оние што веќе постојат. За нас ова ќе биде групата „Мултимедијално видео (Мултимедија: Видео)“.
- Опис - Краток опистип на датотека. Во нашиот пример, можете да го користите, на пример, "Sony cam video, XDCam-EX".
- Екстензија - продолжување на датотеки од овој тип. Во нашиот случај - mp4.
Параметарот Features е опционален, во нашиот случај не треба да го користиме. 
Кликнете на сликата за да ја зголемите
Следно, треба да го внесете потписот на почетната и завршната датотека. За да го направите ова, изберете Почеток и потоа внатре контекстното меникомандата Додај потпис. 
Кликнете на сликата за да ја зголемите
Потоа кликнете двапати на полето<пустая сигнатура> (
Кликнете на сликата за да ја зголемите
Потоа креирајте го конечниот потпис на датотеката. Не заборавајте да внесете 21 во колоната Од. 
Кликнете на сликата за да ја зголемите
Успешно креиравте сопствен потпис за познати типови датотеки.
Сега треба да го зачувате. Постојат два начина: можете или да ја зачувате во стандардната датотека наведена во Главна картичка во полето за дијалог Поставки со кликнување на копчето Зачувај. Или кликнете на копчето Зачувај како... и зачувајте го потписот во некоја друга датотека.
2.2 Рачно креирање на XML-датотека која опишува познат тип на датотека:
За создавање оваа датотекаАјде да користиме XML верзија 1.0 и UTF-8 кодирање. Не очајувајте ако не знаете што е тоа - само отворете кој било уредувач на текст(на пример, Notepad.exe) и внесете го следниов текст во првата линија:
Следно ќе создадеме ознака XML што го дефинира типот на датотеката (FileType). Земајќи ги предвид претходно опишаните XML атрибути, ознаката ќе изгледа вака:
Ајде да го вметнеме веднаш потоа
Следно, го дефинираме потписот на датотеката (ознака
Доколку е присутен, мора да го дефинирате и завршниот потпис (на крајот од датотеката). Ова ја користи истата ознака, но со елемент „од“ и атрибут „крај“. Ќе изгледа вака:
Запомнете дека конечниот потпис на датотеката не содржеше нетекстуални знаци, но содржи коси црти и триаголни загради. За да избегнеме забуна и грешки во синтаксата на XML, ќе ги замениме знаците "/", " во потписот<" и ">„нивните хексадецимални вредности.
На крајот, по потписите на датотеките, мора да има ознаки за затворање FileType и FileTypeList:
Значи, целата датотека треба да изгледа вака:
Запомнете: XML синтаксата е чувствителна на букви, па затоа би била точната ознака
Да ја зачуваме датотеката во текстуален формат со наставката .xml. На пример: SonyCam.xml.
Успешно создадовме сопствен потпис за познати типови датотеки. Овој пример е сосема доволен за да се разберат основните принципи за креирање прилагоден тип на датотека. Поискусните корисници можат да користат XML верзија 2.0. Можете да прочитате повеќе за ова во делот за онлајн помош на R-Studio.
Чекор 3: Проверка и додавање датотека што опишува познат тип на датотека
Следниот чекор е да ја додадете (подигнете) вашата XML-датотека во R-Studio. Во овој случај, автоматски ќе се провери.
Ајде да ја вчитаме датотеката XML создадена во претходната фаза во R-Studio. За да го направите ова, изберете ја ставката Поставки во менито Алатки. Во полето за типови датотеки на корисникот на Главното јазиче во полето за дијалог Поставки, додадете ја XML-датотеката што ја создадовме (SonyCam.xml). Кликнете на копчето Примени. 
Кликнете на сликата за да ја зголемите
2. Одговорете со Да на барањето за преземање нов тип на датотека. 
Кликнете на сликата за да ја зголемите
3. За да потврдите дека типот на датотека е успешно вчитан, кликнете на картичката Познати типови датотеки во полето за дијалог Поставки. Запомнете дека го додадовме типот на датотека во групата Мултимедија видео (Мултимедија: Видео). Откако ја проширивме оваа група (папка), треба да видиме елемент со описот што го наведовме при креирањето на XML-датотеката: Sony cam видео, XDCam-EX (.mp4). 
Кликнете на сликата за да ја зголемите
Кликнете на сликата за да ја зголемите
Ако има какви било грешки во синтаксата на датотеката, ќе видите соодветна порака: 
Кликнете на сликата за да ја зголемите
Во овој случај, повторно проверете ја вашата XML датотека за грешки. Запомнете: XML синтаксата е осетлива на букви и секоја ознака мора да има ознака за затворање на крајот.
Чекор 4: Тестирање на датотеката што опишува познат тип на датотека
За да ја провериме исправноста на приспособениот тип на датотека што го создадовме, ајде да се обидеме да ги најдеме нашите .mp4-датотеки на отстранлив USB флеш-уред.
1. Под Windows Vista или Windows 7, извршете целосно (не брзо) форматирање на дискот или користете алатка за чистење простор на дискот (на пример, R-Wipe & Clean) за да целосно отстранувањесите податоци достапни на дискот. Нека USB-дискформатирано во FAT32 (големината на пребаруваните датотеки не надминува 2 GB).
2. Ајде да го копираме тест датотекина дискот и рестартирање на компјутерот така што содржината на кеш меморијата се зачувува на дискот. Можете исто така да оневозможите надворешен погони потоа поврзете го повторно.
3. Во ОС, погонот ќе биде дефиниран како, на пример, логички погон F:\.
4. Да го лансираме R-Studio. Изберете го нашиот диск (F:\) и кликнете на копчето Скенирај 
Кликнете на сликата за да ја зголемите
5. Во полето за дијалог Скенирај, во областа (Систем на датотеки), кликнете на копчето Промени... и отштиклирајте ги сите полиња. На овој начин ќе го оневозможиме пребарувањето за датотечни системи и датотеки користејќи ја табелата со партиции. 
Кликнете на сликата за да ја зголемите
6. Проверете го полето за избор Дополнително пребарување за познати типови датотеки. Ова ќе му овозможи на R-Studio да бара познати типови датотеки при скенирање.
7. За да започнете со скенирање, кликнете на копчето Скенирај.
8. Да почекаме додека R-Studio го скенира дискот. Јазичето за информации за скенирање ќе го прикаже напредокот (напредок) на скенирањето. 
Кликнете на сликата за да ја зголемите
9. Откако ќе заврши скенирањето, изберете го елементот Extra Found Files и кликнете двапати на него. 
Кликнете на сликата за да ја зголемите
10. Нашите тест-датотеки ќе се наоѓаат во видеото на Sony cam, папката XDCam-EX (или во папка со друго име што одговара на описот на типот на датотеката наведен во Втората фаза). 
Кликнете на сликата за да ја зголемите
Гледате дека имињата на датотеките, датумите и локациите (папките) не се обновени затоа што оваа информацијазачувани во датотечниот систем. Затоа, R-Studio автоматски ќе ја прикаже секоја датотека со ново име.
Сепак, јасно е дека содржината на датотеките не е оштетена. За да го потврдиме ова, ајде да ги отвориме во соодветната програма, на пример VLC медиа плеер. 
Кликнете на сликата за да ја зголемите
Заклучок
Способноста на R-Studio да скенира познати типови датотеки ви овозможува да ги вратите податоците дури и од диск чии датотечни системи се или препишани. Можете да пребарувате датотеки доста ефикасно користејќи ги нивните потписи, што е особено корисно ако точно го знаете типот на датотеки што се обновуваат, како во нашиот пример. Способноста да креирате сопствени типови датотеки ви овозможува да додадете која било датотека што има специфичен потпис на датотека на списокот со познати типови датотеки.
Можеби многумина слушнале за датотеки како што е rarjpeg. Ова е посебен тип на датотека, која е слика jpeg и архива rar блиску залепени заедно. Тоа е одличен контејнер за криење на фактот за пренос на информации. Можете да креирате rarjpeg користејќи следните команди:
UNIX: мачка image1.jpg архива.rar > image2.jpg
WINDOWS: копирајте /b image1.jpg+архива.rar image2.jpg
Или ако имате хексадецимален уредник.
Се разбира, за да го скриете фактот за пренос на информации, можете да го користите не само форматот JPEG, туку и многу други. Секој формат има свои карактеристики, поради што може или не може да биде соодветен за улогата на контејнер. Ќе опишам како можете да најдете залепени датотеки во најпопуларните формати или да го означите фактот на лепење.
Методите за откривање на споени датотеки може да се поделат во три групи:
- Метод за проверка на површината по маркерот EOF. Многу популарни формати на датотеки имаат таканаречен маркер за крај на датотеката, кој е одговорен за прикажување на саканите податоци. На пример, гледачите на фотографии ги читаат сите бајти до овој маркер, но областа по него е игнорирана. Овој метод е идеален за следните формати: JPEG, PNG, GIF, ZIP, RAR, PDF.
- Метод за проверка на големината на датотеката. Структурата на некои формати (аудио и видео контејнери) ви овозможува да ја пресметате вистинската големина на датотеката и да ја споредите со оригиналната големина. Формати: AVI, WAV, MP4, MOV.
- Метод за проверка на CFB-датотеките. CFB или бинарен формат на сложена датотека е формат на документ развиен од Microsoft, кој е контејнер со сопствен датотечен систем. Овој метод се заснова на откривање аномалии во датотека.
Дали има живот по завршувањето на датотеката?
JPEG
За да го најдете одговорот на ова прашање, неопходно е да се навлезе во спецификациите на форматот, кој е „предок“ на споените датотеки и да се разбере неговата структура. Секој JPEG започнува со потписот 0xFF 0xD8.По овој потпис има информации за услугата, опционално икона за слика и, конечно, самата компресирана слика. Во овој формат, крајот на сликата е означен со потпис од два бајти 0xFF 0xD9.
PNG
Првите осум бајти од датотеката PNG се окупирани со следниов потпис: 0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A. Заврши потпис што го завршува протокот на податоци: 0x49, 0x45, 0x4E, 0x44, 0xAE, 0x42, 0x60, 0x82.РАР
Заеднички потпис за сите rar архиви: 0x52 0x61 0x72 0x21 (Rar!). После тоа доаѓаат информации за верзијата на архивата и други поврзани податоци. Експериментално беше утврдено дека архивата завршува со потписот 0x0A, 0x25, 0x25, 0x45, 0x4F, 0x46.Табела на формати и нивните потписи:
Алгоритмот за проверка на лепење во овие формати е исклучително едноставен:
- Најдете го почетниот потпис;
- Најдете го конечниот потпис;
- Ако нема податоци по конечниот потпис, вашата датотека е чиста и не содржи прилози! Во спротивно, потребно е да се бараат други формати по финалниот потпис.
GIF и PDF
Документот PDF може да има повеќе од еден EOF маркер, на пример поради неправилно генерирање документи. Бројот на конечни потписи во GIF-датотеката е еднаков на бројот на рамки во неа. Врз основа на карактеристиките на овие формати, можно е да се подобри алгоритмот за проверка на присуството на прикачени датотеки.- Точката 1 се повторува од претходниот алгоритам.
- Точката 2 се повторува од претходниот алгоритам.
- Кога ќе го најдете конечниот потпис, запомнете ја неговата локација и погледнете понатаму;
- Ако на овој начин го достигнете последниот маркер EOF, датотеката е чиста.
- Ако датотеката не завршува со краен потпис, goto е локацијата на последниот пронајден потпис.
ZIP
Особеноста на архивите ZIP е присуството на три различни потписи: Структурата на архивата е како што следува:| Заглавие на локална датотека 1 |
| Податоци за датотека 1 |
| Опис на податоци 1 |
| Заглавие на локална датотека 2 |
| Податоци за датотека 2 |
| Опис на податоци 2 |
| ... |
| Заглавие на локална датотека |
| Податоци за датотека n |
| Опис на податоци n |
| Заглавие за дешифрирање на архива |
| Архивирајте запис за дополнителни податоци |
| Централен директориум |
За да ја проверите архивата ZIP, треба да го пронајдете крајниот потпис на централниот директориум, да прескокнете 18 бајти и да барате потписи на познати формати во областа за коментари. Голема величинаКоментарот укажува и на фактот на лепење.
Големината значи
AVI
Структурата на датотеката AVI е како што следува: секоја датотека започнува со потпис RIFF (0x52 0x49 0x46 0x46). На бајтот 8 има потпис AVI кој го одредува форматот (0x41 0x56 0x49 0x20). Блокот на поместување 4, кој се состои од 4 бајти, ја содржи почетната големина на податочниот блок (редослед на бајти - мал ендиан). За да го дознаете бројот на блокот што ја содржи следната големина, треба да ја додадете големината на заглавјето (8 бајти) и големината добиена во блокот од 4-8 бајти. Ова ја пресметува вкупната големина на датотеката. Прифатливо е пресметаната големина да биде помала од вистинската големина на датотеката. Откако ќе се пресмета големината, датотеката ќе содржи само нула бајти (неопходни за усогласување на границата од 1 Kb).Пример за пресметка на големината:
WAV
Како AVI, WAV-датотеката започнува со потпис RIFF, меѓутоа, оваа датотека има потпис од бајтот 8 - WAVE (0x57 0x41 0x56 0x45). Големината на датотеката се пресметува на ист начин како и AVI. Вистинската големина мора целосно да одговара на пресметаната.MP4
MP4 или MPEG-4 е формат на контејнер за медиуми што се користи за складирање на видео и аудио преноси, исто така обезбедува складирање на преводи и слики.При поместување од 4 бајти има потписи: тип на датотека ftyp (66 74 79 70) (Тип на датотека со контејнер QuickTime) и подтип на датотека mmp4 (6D 6D 70 34). За признавање скриени датотеки, ние сме заинтересирани за можноста да ја пресметаме големината на датотеката.
Ајде да погледнеме на пример. Големината на првиот блок е на поместување нула и е 28 (00 00 00 1C, редослед на големиот Ендиски бајти); го означува и поместувањето каде се наоѓа големината на вториот блок на податоци. При поместување 28 ја наоѓаме следната големина на блок еднаква на 8 (00 00 00 08). За да ја пронајдете следната големина на блок, треба да ги додадете големините на претходните пронајдени блокови. Така, големината на датотеката се пресметува:
MOV
Овој широко користен формат е и контејнер MPEG-4. MOV користи комерцијален алгоритам за компресија на податоци, има структура слична на MP4 и се користи за истите цели - за складирање аудио и видео податоци, како и сродни материјали.Како и MP4, секоја mov-датотека има 4-бајти ftyp потпис при поместување 4, сепак, следниот потпис има вредност qt__ (71 74 20 20). Правилото за пресметување на големината на датотеката не е променето: почнувајќи од почетокот на датотеката, ја пресметуваме големината на следниот блок и го собираме.
Начинот на проверка на оваа група формати за присуство на „лепливи“ датотеки е да се пресмета големината според правилата наведени погоре и да се спореди со големината на датотеката што се проверува. Ако тековната големина на датотеката е многу помала од пресметаната, тогаш ова укажува на фактот на лепење. При проверка на AVI-датотеките, се прифаќа дека пресметаната големина може да биде помала од големината на датотеката поради присуството на додадени нули за усогласување на границата. Во овој случај, неопходно е да се проверат нули по пресметаната големина на датотеката.
Проверка на бинарен формат на сложената датотека
Овој формат на датотека, развиен од Microsoft, е познат и како OLE (Поврзување и вградување на објекти) или COM (Модел на компонентен објект). Датотеките DOC, XLS, PPT припаѓаат на групата CFB формати.Датотеката CFB се состои од заглавие од 512 бајти и сектори со еднаква должина што складираат текови на податоци или информации за услугите. Секој сектор има свој ненегативен број, со исклучок на специјалните броеви: „-1“ - го нумери слободниот сектор, „-2“ - го нумерира секторот што го затвора ланецот. Сите секторски синџири се дефинирани во табелата FAT.
Да претпоставиме дека напаѓачот изменил одредена датотека .doc и залепи друга датотека на крајот од неа. Има неколку на различни начинидетектирајте го или посочете аномалија во документот.
Ненормална големина на датотека
Како што споменавме погоре, секоја CFB-датотека се состои од заглавие и сектори со еднаква должина. За да ја дознаете големината на секторот, треба да прочитате број од два бајти со поместување 30 од почетокот на датотеката и да подигнете 2 на моќноста на овој број. Овој број мора да биде еднаков на 9 (0x0009) или 12 (0x000C), соодветно, големината на секторот на датотеки е 512 или 4096 бајти. Откако ќе го пронајдете секторот, треба да ја проверите следната еднаквост:(Големина на датотека - 512) мод SectorSize = 0
Ако оваа еднаквост не е задоволена, тогаш можете да го истакнете фактот на лепење на датотеките. Сепак, овој метод има значителен недостаток. Ако напаѓачот ја знае големината на секторот, тогаш треба само да ја залепи својата датотека и уште n бајти, така што големината на залепените податоци е повеќекратна од големината на секторот.
Непознат тип на сектор
Ако напаѓачот знае за метод за заобиколување на претходната проверка, тогаш овој методможе да открие присуство на сектори со недефинирани типови.Ајде да ја дефинираме еднаквоста:
FileSize = 512 + CountReal * SectorSize, каде што FileSize е големината на датотеката, SectorSize е големината на секторот, CountReal е бројот на сектори.
Ги дефинираме и следните променливи:
- CountFat – број на FAT сектори. Се наоѓа на поместување 44 од почетокот на датотеката (4 бајти);
- CountMiniFAT – број на сектори MiniFAT. Се наоѓа на офсет 64 од почетокот на датотеката (4 бајти);
- CountDIFAT – број на сектори DIFAT. Се наоѓа на поместување 72 од почетокот на датотеката (4 бајти);
- CountDE – број на сектори за внесување директориум. За да ја пронајдете оваа променлива, треба да го пронајдете првиот сектор DE, кој е на поместување 48. Потоа потребно е да се добие целосна претстава за DE од FAT и да се брои бројот на сектори DE;
- CountStreams – број на сектори со текови на податоци;
- CountFree – број на слободни сектори;
- CountClassified – број на сектори со одреден тип;
Очигледно, ако CountClassified и CountReal се нееднакви, можеме да заклучиме дека датотеките може да се спојат.
Мојот шеф ми даде прилично интересна задача. За кратко време, напишете извршна анализатор на датотеки што ќе може да пронајде вирусни тела врз основа на потписи и да го одреди употребениот пакувач/криптор. Готовиот прототип се појави за неколку часа.
Збор на авторот
Анализа на потпис
Пребарувањето на злонамерен објект со помош на потписи е нешто што секој антивирус може да го направи. Општо земено, потписот е формализиран опис на одредени карактеристики со кои може да се утврди дека датотеката што се скенира е вирус и добро дефиниран вирус.
Тука има различни техники. Алтернатива е да се користи потпис составен од N бајти на малициозен објект. Во овој случај, не можете да направите глупава споредба, туку споредба користејќи некоја маска (како да барате бајти EB ?? ?? CD 13). Или поставете дополнителни услови како „такви и такви бајти мора да бидат на влезната точка во програмата“ и така натаму. Потписот на малициозниот софтвер е посебна работа.
На ист начин, се опишани некои знаци со кои може да се утврди дека извршната датотека е спакувана со еден или друг криптор или пакувач (на пример, баналниот ASPack). Ако внимателно го прочитавте нашето списание, тогаш дефинитивно сте слушнале за таква алатка како PEiD, која е способна да ги идентификува најчесто користените пакувачи, криптори и компајлери (базата на податоци има голем број потписи) за датотеката PE пренесена во неа . За жал, новите верзии на програмата не се објавени долго време, а неодамна на официјалната веб-страница се појави порака дека проектот нема да има понатамошен развој. Штета, бидејќи можностите на PEiD (особено со оглед на системот за приклучоци) може многу добро да ми бидат корисни. По кратка анализа, стана јасно дека тоа не е опција. Но, откако копав низ блоговите на англиски јазик, брзо го најдов она што ми одговараше. YARA проект (code.google.com/p/yara-project).
Што е YARA?
Од самиот почеток бев убеден дека некаде на Интернет веќе постои развој на отворен код кој ќе преземе задача да ја утврди кореспонденцијата помеѓу одреден потпис и датотеката што се испитува. Кога би можел да најдам таков проект, тогаш лесно би можел да се стави на шините на веб-апликацијата, да додадам различни потписи таму и да го добијам она што се бара од мене. Планот почна да изгледа уште пореален кога го прочитав описот на проектот YARA.
Самите програмери го позиционираат како алатка која им помага на истражувачите на малициозен софтвер да ги идентификуваат и класифицираат малициозните примероци. Истражувачот може да креира описи за различни типовималициозен софтвер кој користи текст или бинарни обрасци кои ги опишуваат формализираните карактеристики на малициозен софтвер. Така се добиваат потписи. Всушност, секој опис се состои од збир на линии и некои логички изрази, врз основа на кои се одредува логиката на активирање на анализаторот.
Ако се исполнети условите на едно од правилата за датотеката што се испитува, тоа се одредува соодветно (на пример, таков и таков црв). Едноставен пример на правило за да разбереме за што зборуваме:
правило silent_banker: банкар
{
мета:
опис = "Ова е само пример"
Ниво_ниво = 3
во_дивината = точно
жици:
$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"
состојба:
$a или $b или $c
}
Во ова правило му кажуваме на YARA дека секоја датотека што содржи барем една од стринговите на примероци опишани во променливите $a, $b, $c треба да се класифицира како тројанец silent_banker. И ова е многу едноставно правило. Во реалноста, правилата може да бидат многу посложени (за ова ќе зборуваме подолу).
Дури и списокот на проекти што го користат зборува за авторитетот на проектот YARA, а ова е:
- Разузнавачки услуги за малициозен софтвер VirusTotal (vt-mis.com);
- jsunpack-n (jsunpack.jeek.org);
- Ние ја гледаме вашата веб-страница (wewatchyourwebsite.com).
Целиот код е напишан во Python, а на корисникот му се нуди и самиот модул за употреба во нивниот развој, и едноставно извршна датотека за користење на YARA како самостојна апликација. Како дел од мојата работа, ја избрав првата опција, но за едноставност во оваа статија едноставно ќе го користиме анализаторот како апликација за конзола.
По некое копање, брзо сфатив како да напишам правила за YARA, како и како да прикачам потписи за вируси од бесплатниот софтвер и пакувачите од PEiD на него. Но, ќе започнеме со инсталацијата.
Инсталација
Како што веќе реков, проектот е напишан во Python, така што лесно може да се инсталира на Linux, Windows и Mac. Отпрвин, можете само да го земете бинарното. Ако ја повикаме апликацијата во конзолата, ќе ги добиеме правилата за стартување.
$јара
употреба: yara ... ... ДАТОТЕКА | PID
Односно, форматот за повикување на програмата е како што следува: прво е името на програмата, потоа список на опции, по што е наведена датотеката со правилата, а на самиот крај - името на датотеката што е испитани (или директориумот што ги содржи датотеките), или идентификаторот на процесот. Сега би сакал на добар начин да објаснам како се составени токму овие правила, но не сакам веднаш да ве оптоварувам со сува теорија. Затоа, ќе ги правиме работите поинаку и ќе позајмуваме туѓи потписи за YARA да може да изврши една од задачите што ги поставивме - целосно откривање на вируси со потписи.
Сопствен антивирус
Најважното прашање: каде да се добие базата на податоци за потписи на познати вируси? Антивирусни компании активно споделуваат такви бази на податоци меѓу себе (некои повеликодушно, други помалку). Да бидам искрен, на почетокот дури и се сомневав дека некаде на интернет некој отворено ќе објави такви работи. Но, како што се испостави, има добри луѓе. Соодветна база на податоци од популарниот антивирус ClamAV е достапна за секого (clamav.net/lang/en). Во делот „Најнов стабилно издание“ можете да најдете врска до Најновата верзијаантивирусен производ, како и линкови за преземање бази на податоци за вируси ClamAV. Ќе нè интересираат првенствено датотеките main.cvd (db.local.clamav.net/main.cvd) и daily.cvd (db.local.clamav.net/daily.cvd).
Првата ја содржи главната база на податоци за потписи, втората ја содржи најкомплетната база на податоци овој моментоснова со разни додатоци. Daily.cvd, кој содржи повеќе од 100.000 импресии од малициозен софтвер, е сосема доволен за оваа намена. Сепак, базата на податоци ClamAV не е база на податоци YARA, па затоа треба да ја конвертираме во саканиот формат. Но како? На крајот на краиштата, сè уште не знаеме ништо за форматот ClamAV или форматот Yara. За овој проблем веќе е решено пред нас со подготовка на мала скрипта што ја конвертира базата на податоци за потписи на вирусот ClamAV во збир на правила YARA. Сценариото се вика clamav_to_yara.py и напишано од Метју Ричард (bit.ly/ij5HVs). Преземете ја скриптата и конвертирате ги базите на податоци:
$ python clamav_to_yara.py -f daily.cvd -o clamav.yara
Како резултат на тоа, во датотеката clamav.yara ќе добиеме база на податоци за потписи која веднаш ќе биде подготвена за употреба. Ајде сега да ја пробаме комбинацијата на YARA и базата на податоци ClamAV во акција. Скенирањето папка со помош на потпис се врши со една единствена команда:
$ yara -r clamav.yara /pentest/msf3/data
Опцијата -r одредува дека скенирањето треба да се врши рекурзивно низ сите потпапки од тековната папка. Ако имало какви било тела на вируси во папката /pentest/msf3/data (барем оние што се во базата на податоци ClamAV), тогаш YARA веднаш ќе го пријави ова. Во принцип, ова е готов скенер за потписи. За поголема погодност, напишав едноставна скрипта која ги проверуваше ажурирањата на базата на податоци на ClamAV, преземаше нови потписи и ги конвертира во формат YARA. Но, ова се веќе детали. Еден дел од задачата е завршен, сега можете да започнете со изготвување правила за идентификација на пакувачи/криптори. Но, за да го направам ова, морав малку да се справам со нив.
Играјте според правилата
Значи, правилото е главниот механизам на програмата што ви овозможува да доделите дадена датотека на одредена категорија. Правилата се опишани во посебна датотека (или датотеки) и по изглед се многу слични на конструкцијата struct() од јазикот C/C++.
владее со BadBoy
{
жици:
$a = "win.exe"
$b = "http://foo.com/badfi le1.exe"
$c = "http://bar.com/badfi le2.exe"
состојба:
$a и ($b или $c)
}
Во принцип, нема ништо комплицирано во пишувањето правила. Во оваа статија ги допрев само главните точки, а деталите ќе ги најдете во прирачникот. Засега, десетте најважни точки:
1. Секое правило започнува со правилото за клучни зборови, проследено со идентификаторот на правилото. Идентификаторите можат да ги имаат истите имиња како променливите во C/C++, односно да се состојат од букви и бројки, а првиот знак не може да биде број. Максимална должинаиме на идентификатор - 128 знаци.
2. Вообичаено, правилата се состојат од два дела: дел за дефиниција (жици) и дел за услови (состојба). Секцијата стринг одредува податоци врз основа на кои делот за услови ќе одлучи дали дадената датотека задоволува одредени услови.
3. Секоја линија во делот жици има свој идентификатор, кој започнува со знакот $ - генерално, како декларација на променлива во PHP. YARA поддржува редовни жици затворени во двојни наводници("") и хексадецимални жици затворени во загради(()), како и регуларни изрази:
$my_text_string = "текст тука"
$my_hex_string = ( E2 34 A1 C8 23 FB )
4. Делот услов ја содржи целата логика на правилото. Овој дел мора да содржи Булова израз кој одредува кога датотека или процес се совпаѓа со правилото. Вообичаено, овој дел се однесува на претходно декларирани линии. И идентификаторот на стрингот се третира како булова променлива која враќа true ако низата е пронајдена во датотеката или процесната меморија, а во спротивно неточно. Горенаведеното правило одредува дека датотеките и процесите што ја содржат низата win.exe и една од двете URL-адреса треба да се категоризираат како BadBoy (според името на правилото).
5. Хексадецималните жици дозволуваат три конструкции кои ги прават пофлексибилни: знаци, скокови и алтернативи. Замените се места во низата кои се непознати и може да се заменат со која било вредност. Тие се означени со симболот „?“:
$hex_string = ( E2 34 ?? C8 A? FB )
Овој пристап е многу удобен кога се одредуваат низи чија должина е позната, но содржината може да варира. Ако дел од низата може да биде со различна должина, погодно е да се користат опсези:
$hex_string = ( F4 23 62 B4 )
Овој запис значи дека во средината на линијата може да има од 4 до 6 различни бајти. Можете исто така да спроведете алтернативен избор:
$hex_string = ( F4 23 (62 B4 | 56) 45 )
Ова значи дека на местото на третиот бајт може да има 62 B4 или 56, таков запис одговара на линиите F42362B445 или F4235645.
6. За да се провери дали дадената низа е на одредено поместување во просторот за адреса на датотека или процес, се користи операторот at:
$a на 100 и $b на 200
Ако низата може да биде во одреден опсег на адреси, се користи операторот in:
$a во (0..100) и $b во (100..fi lesize)
Понекогаш се појавуваат ситуации кога треба да наведете дека датотеката треба да содржи одреден број од дадено множество. Ова е направено со користење на операторот:
правило На пример 1
{
жици:
$foo1 = „кукла1“
$foo2 = „кукла2“
$foo3 = "кукла3"
состојба:
2 од ($foo1,$foo2,$foo3)
}
Горенаведеното правило бара датотеката да содржи кои било две линии од множеството ($foo1,$foo2,$foo3). Наместо да наведете одреден број линии во датотеката, можете да ги користите променливите било (барем една линија од дадено множество) и сите (сите линии од дадено множество).
7. Па, последната интересна можност што треба да се разгледа е да се примени еден услов на многу редови. Оваа карактеристика е многу слична на операторот на, само помоќен е операторот for..of:
за изразување на стринг_сет: (буловен_израз)
Овој запис треба да се чита вака: од низите наведени во множеството string_, барем парчињата на изразот мора да го задоволуваат условот boolean_expression. Или, со други зборови: boolean_expression се оценува за секоја низа во string_set, а изразите од нив мора да се вратат True. Следно, ќе ја разгледаме оваа конструкција користејќи конкретен пример.
Изработка на PEiD
Значи, кога сè ќе стане повеќе или помалку јасно со правилата, можеме да започнеме да имплементираме детектор на пакувачи и криптори во нашиот проект. Отпрвин, како изворен материјал, ги позајмив потписите на познати пакувачи од истиот PEiD. Во папката со приклучоци има датотека userdb.txt, која го содржи она што ни треба. Имаше 1850 потписи во мојата база на податоци.
Доста многу, па за да ги увезете целосно, ве советувам да напишете некаква скрипта. Форматот на оваа база на податоци е едноставен - се користи вообичаениот текстуална датотека, кој складира записи како:
потпис = 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 = точно
Првата линија го одредува името на пакувачот, кој ќе биде прикажан во PEiD, но за нас тоа ќе биде идентификатор на правило. Вториот е самиот потпис. Третото е знамето ep_only, кое покажува дали да се бара дадена линија само на адресата на влезната точка или низ целата датотека.
Па, ајде да се обидеме да создадеме правило, да речеме, за ASPack? Како што се испоставува, нема ништо комплицирано за ова. Прво, ајде да создадеме датотека за складирање на правилата и да ја наречеме, на пример, packers.yara. Потоа ја пребаруваме базата на податоци на PEiD за сите потписи кои вклучуваат ASPack во нивните имиња и ги пренесуваме на правилото:
правило ASPack
{
жици:
$ = ( 60 E8 ?? ?? ?? ?? 5D 81 ED ?? ?? (43 | 44) ?? B8 ?? ?? (43 | 44) ?? 03 C5 )
$ = ( 60 EB ?? 5D EB ?? FF ?? ?? ?? ?? ?? E9 )
[.. исечете..]
$ = ( 60 E8 03 00 00 00 E9 EB 04 5D 45 55 C3 E8 01 )
состојба:
за било кој од нив: ($ на влезната точка)
}
Сите пронајдени записи имаат знаменце ep_only поставено на true, односно овие линии мора да се наоѓаат на адресата на влезната точка. Затоа, го пишуваме следниов услов: „за кој било од нив: ($at entrypoint)“.
Така, присуството на барем една од дадените линии на адресата на влезната точка ќе значи дека датотеката е спакувана со ASPack. Ве молиме имајте предвид дека во ова правило сите линии се наведени едноставно со користење на знакот $, без идентификатор. Ова е можно затоа што во делот за услови не пристапуваме до некои конкретни, туку го користиме целиот сет.
За да ја проверите функционалноста на добиениот систем, само извршете ја командата во конзолата:
$ yara -r packers.yara somefi le.exe
Откако нахранив неколку апликации спакувани со ASPack таму, бев убеден дека сè функционира!
Подготвен прототип
YARA се покажа како исклучително јасна и транспарентна алатка. Не ми беше тешко да напишам вебадмин за него и да го поставам да работи како веб-услуга. Со малку креативност, сувите резултати на анализаторот веќе се обоени во различни бои, што укажува на степенот на опасност од откриениот малициозен софтвер. Мало ажурирање на базата на податоци и за многу од крипторите е достапен краток опис, а понекогаш дури и инструкции за отпакување. Прототипот е создаден и функционира совршено, а газдите танцуваат од воодушевување!
Кодот на функцијата (FC) во заглавието на телеграмата го идентификува типот на телеграмата, како што се Барање телеграма (Барање или Испрати/Барање) и Телеграма за потврда или одговор (Рамка за потврда, рамка за одговор). Дополнително, функцискиот код ја содржи вистинската функција за пренос и информации за контрола кои спречуваат губење и дуплирање на пораките или типот на станицата со статус FDL.
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ФК: Барање за код за функција |
| 1 | Побарајте Телеграма | |||||||
| X | FCV = Вклучен е алтернативен бит | |||||||
| X | href=”http://profibus.felser.ch/en/funktionscode.htm#aufruffolgebit”>FCB = Алтернативен бит (од број на рамки) | |||||||
| 1 | 0 (0x0) | CV = Вредност на часовникот() | ||||||
| 1 | други | Резервирано | ||||||
| 0 | 0 (0x0) | TE = Временски настан (синхронизација на часовникот) | ||||||
| 0 | 3 (0x3) | SDA_LOW = Испрати податоци потврдено - низок приоритет | ||||||
| 0 | 4 (0x4) | SDN_LOW = Испрати податоци не е потврдено - низок приоритет | ||||||
| 0 | 5 (0x5) | SDA_HIGH = Испрати податоци потврдено - висок приоритет | ||||||
| 0 | 6 (0x6) | SDN_HIGH = Испрати податоци Не е потврдено | ||||||
| 0 | 7 (0x7) | MSRD = Испрати податоци за барање со повеќекратен одговор | ||||||
| 0 | 9 (0x9) | Побарајте статус на FDL | ||||||
| 0 | 12 (0xC) | SRD low = Испрати и побарај податоци | ||||||
| 0 | 13 (0xD) | SRD high = Испрати и побарај податоци | ||||||
| 0 | 14 (0xE) | Побарајте идентификација со одговор | ||||||
| 0 | 15 (0xF) | Побарајте статус на LSAP со одговор 1) | ||||||
| 0 | други | Резервирано | ||||||
1) оваа вредност е во последната верзија на стандардот не е веќе дефинирана, туку само резервирана
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ФК: Одговор на кодот на функцијата |
| 0 | Телеграма за одговор | |||||||
| 0 | Резервирано | |||||||
| 0 | 0 | Роб | ||||||
| 0 | 1 | Мајсторот не е подготвен | ||||||
| 1 | 0 | Господар подготвен, без токен | ||||||
| 1 | 1 | Господар подготвени, во знак прстен | ||||||
| 0 (0x0) | добро | |||||||
| 1 (0x1) | UE = Корисничка грешка | |||||||
| 2 (0x2) | RR = Нема ресурси | |||||||
| 3 (0x3) | RS = SAP не е овозможен | |||||||
| 8 (0x8) | DL = Ниски податоци (нормален случај со DP) | |||||||
| 9 (0x9) | NR = Нема подготвени податоци за одговор | |||||||
| 10 (0xA) | DH = Високи податоци (ДП дијагнозата се чека) | |||||||
| 12 (0xC) | RDL = Податоци не се примени и податоци ниски | |||||||
| 13 (0xD) | RDH = Податоци не се примени и податоци Високи | |||||||
| други | Резервирано | |||||||
Бит за броење кадри Битот за броење рамки FCB (b5) спречува дуплирање на пораките од страна на станицата (одговорувач) што потврдува или одговара и каква било загуба од станицата која повикува (иницијатор). Од ова се исклучени барањата без потврда (SDN) и барањата за статус на FDL, Ident и LSAP статус.
За безбедносната секвенца, иницијаторот мора да носи FCB за секој одговор. Кога телеграма за барање (Барање или Испрати/Барање) е испратена до одговорувач за прв пат, или ако е повторно испратена до одговорувач кој моментално е означен како неоперативен, FCB мора да се постави како што е дефинирано во одговорувачот. Иницијаторот го постигнува ова во телеграма за барање со FCV=0 и FCB=1. Одговарачот мора да оцени телеграма од овој вид како прв циклус на пораки и да ја складира FCB=1 заедно со адресата на иницијаторот (SA) (видете ја следната табела). Овој циклус на пораки нема да се повтори од иницијаторот. Во следните телеграми за барање до истиот одговор, иницијаторот мора да постави FCV=1 и да го менува FCB со секоја нова телеграма за барање. Секој одговорен што ќе добие телеграма за барање упатена до него со FCV=1 мора да го оцени FCB. Ако FCB се промени во споредба со последната телеграма за барање од истиот иницијатор (ист SA), ова е валидна потврда дека претходниот циклус на пораки бил правилно завршен. Ако телеграмата за барање потекнува од различен иницијатор (различен SA), евалуацијата на FCB повеќе не е потребна. Во двата случаи, одговорот мора да го зачува FCB со изворот SA додека не добие нова телеграма упатена до него. Во случај на изгубена или оштетена телеграма за потврда или одговор, FCB не смее да се менува од иницијаторот при повторното обидување на барањето: тоа ќе покаже дека претходниот циклус на пораки бил погрешен. Ако одговорачот добие телеграма за барање со FCV=1 и истата FCB како и последната телеграма за барање од истиот иницијатор (ист SA), тоа ќе укаже на барање повторно да се обиде. Одговорувачот за возврат мора повторно да ја пренесе телеграмата за потврда или одговор што се чува во подготвеност. До гореспоменатата потврда или прием на телеграма со различна адреса (SA или DA) што не е потврдена (Испрати податоци без потврда, SDN) одговорниот мора да ја држи последната телеграма за потврда или одговор во подготвеност за секое можно барање повторен обид . Во случај на Барање телеграми кои не се потврдени и со Барање FDL статус, Идент и LSAP статус, FCV=0 и FCB=0; евалуацијата од страна на одговорниот повеќе не е потребна.
| b5 | б4 | Положба на бит | ||
| FCB | FCV | Состојба | Значење | Акција |
| 0 | 0 | ДА = ТС/127 | Барање без потврда Побарајте статус на FDL/ Ident/ LSAP статус |
Избришете ја последната потврда |
| 0/1 | 0/1 | DA#TS | Барање до друг одговор | |
| 1 | 0 | ДА = ТС | Прво барање | FCBM: = 1 САМ:=СА Избришете ја последната потврда / одговор |
| 0/1 | 1 | ДА = ТС СА = САМ FCB#FCBM |
Ново барање | Избришете ја последната потврда / одговор FCBM:=FCB Задржете го признанието / одговорот во подготвеност за повторно обид |
| 0/1 | 1 | ДА = ТС СА = САМ FCB = FCBM |
Обидете се повторно со барање | FCBM:=FCB Повторете го признавањето / одговорот и продолжете да останете на подготвеност |
| 0/1 | 1 | ДА = ТС SA#SAM |
Нов иницијатор | FCBM:=FCB SAM:= SA Задржете потврда / одговор во подготвеност за повторно обид |
FCBM го складираше FCB во меморијата SAM го складираше SA во меморијата
