Багато хто міг чути про такі файлах, як rarjpeg "і. Це особливий вид файлів, що представляє собою склеєну впритул jpeg-картинку і rar-архів. Він є прекрасним контейнером для приховування факту передачі інформації. Створити rarjpeg можна за допомогою наступних команд:
UNIX: cat image1.jpg archive.rar\u003e image2.jpg
WINDOWS: copy / b image1.jpg + archive.rar image2.jpg
Або ж при наявності hex-редактора.
Зрозуміло, для приховування факту передачі інформації можна використовувати не тільки формат JPEG, але і багато інших. Кожен формат має свої особливості, завдяки яким він може підходити чи ні для ролі контейнера. Я опишу, як можна знайти приклеєні файли в найбільш популярних форматах або ж вказати на факт склейки.
Методи детектування склеєних файлів можна розділити на три групи:
- Метод перевірки області після EOF-маркера. Безліч популярних форматів файлів мають так званий маркер кінця файлу, який відповідає за відображення потрібних даних. Наприклад, програми для перегляду фотографій зчитують все байти аж до цього маркера, проте, область після нього залишається ігнорованої. Цей метод ідеально підходить для форматів: JPEG, PNG, GIF, ZIP, RAR, PDF.
- Метод перевірки розміру файлу. Структура деяких форматів (аудіо- і Відеоконтейнер) дозволяє обчислити реальний розмір файлу і порівняти його з початковим розміром. Формати: AVI, WAV, MP4, MOV.
- Метод перевірки CFB-файлів. CFB або Compound File Binary Format - формат документів, розроблений в 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
Загальна сигнатура для всіх rar-архівів: 0x52 0x61 0x72 0x21 (Rar!). Після неї йде інформація про версії архіву та інші супутні дані. Досвідченим шляхом було встановлено, що архів закінчується сигнатурою 0x0A, 0x25, 0x25, 0x45, 0x4F, 0x46.Таблиця форматів і їх сигнатур:
Алгоритм перевірки на склейку в даних форматах гранично простий:
- Знайти початкову сигнатуру;
- Знайти кінцеву сигнатуру;
- Якщо після кінцевої сигнатури немає даних - ваш файл чистий і не містить вкладень! В іншому випадку необхідно шукати після кінцевої сигнатури інші формати.
GIF і PDF
PDF документ може мати більше одного EOF-маркера, наприклад, через неправильну генерації документа. Кількість кінцевих сигнатур в GIF-файлі дорівнює кількості кадрів в ньому. Виходячи з особливостей цих форматів, можна поліпшити алгоритм перевірки наявності приклеєних файлів.- Пункт 1 повторюється з попереднього алгоритму.
- Пункт 2 повторюється з попереднього алгоритму.
- При знаходженні кінцевої сигнатури запам'ятати її розташування і шукати далі;
- Якщо таким чином дійшли до останнього EOF-маркера - файл чистий.
- Якщо файл не закінчується кінцевою сигнатурою - goto місце останньої знайденої кінцевої сигнатури.
ZIP
Особливість ZIP-архівів полягає в наявність трьох різних сигнатур: Структура архіву така:| Local File Header 1 |
| File Data 1 |
| Data Descriptor 1 |
| Local File Header 2 |
| File Data 2 |
| Data Descriptor 2 |
| ... |
| Local File Header n |
| File Data n |
| Data Descriptor n |
| Archive decryption header |
| Archive extra data record |
| Central directory |
Для перевірки ZIP-архіву необхідно знайти кінцеву сигнатуру центральної директорії, пропустити 18 байт і шукати сигнатури відомих форматів в області коментаря. Великий розмір коментаря також свідчить про факт склейки.
Розмір має значення
AVI
Структура AVI-файлу наступна: кожен файл починається з сигнатури RIFF (0x52 0x49 0x46 0x46). На 8 байте йде уточнююча формат сигнатура AVI (0x41 0x56 0x49 0x20). Блок на зміщенні 4, що складається з 4 байт, містить початковий розмір блоку даних (порядок байт - little endian). Щоб дізнатися номер блоку, що містить наступний розмір, необхідно скласти розмір заголовка (8 байт) і розмір, отриманий в блоці 4-8 байт. Таким чином обчислюється повний розмір файлу. Допускається, що обчислений розмір може бути менше, ніж реальний розмір файлу. Після обчисленого розміру файл буде містити тільки нульові байти (необхідно для вирівнювання кордону в 1 Кб).Приклад обчислення розміру:
WAV
Як і AVI, WAV-файл починається з сигнатури RIFF, однак, у цього файлу сигнатура з 8 байта - WAVE (0x57 0x41 0x56 0x45). Розмір файлу обчислюється таким же чином, як і AVI. Реальний розмір повинен повністю збігатися з обчисленим.MP4
MP4 або MPEG-4 - формат медіаконтейнера, який використовується для зберігання відео та звук, також передбачає зберігання субтитрів і зображень.На зміщенні 4 байта розташовані сигнатури: тип файлу ftyp (66 74 79 70) (QuickTime Container File Type) і підтип файла mmp4 (6D 6D 70 34). Для розпізнання прихованих файлів, нас цікавить можливість обчислення розміру файлу.
Розглянемо приклад. Розмір першого блоку знаходиться на нульовому зміщенні, і він дорівнює 28 (00 00 00 1С, порядок байт Big Endian); він же вказує на зсув, де знаходиться розмір другого блоку даних. На 28 зміщенні знаходимо наступний розмір блоку дорівнює 8 (00 00 00 08). Щоб знайти наступний розмір блоку, необхідно складати розміри знайдених попередніх блоків. Таким чином, обчислюється розмір файлу:
MOV
Цей широко використовуваний формат є також контейнером MPEG-4. MOV використовує пропріетарний алгоритм стиснення даних, має схожу на MP4 структуру і використовується в тих же цілях - для зберігання аудіо і відео даних, а також супутніх матеріалів.Як і MP4, будь mov-файл має на 4 зміщенні 4-х байтную сигнатуру ftyp, однак, наступна сигнатура має значення qt__ (71 74 20 20). Правило обчислення розміру файлу не змінилося: починаючи з початку файлу обчислюємо розмір наступного блоку і складаємо.
Метод перевірки цієї групи форматів на наявність «приклеєних» файлів полягає в обчисленні розміру по заданих вище правилам і порівнянні його з розміром перевіряється файлу. Якщо поточний розмір файлу багато менше обчисленого, то це вказує на факт склейки. При перевірці AVI-файлів допускається, що обчислений розмір може бути меншою за розмір файлу через наявність доданих нулів для вирівнювання кордону. В такому випадку, необхідно перевіряти нулі після обчисленого розміру файлу.
Перевіряємо Compound File Binary Format
Цей формат файлу, розроблений в Microsoft, також відомий під назвою OLE (Object Linking and Embedding) або COM (Component Object Model). Файли DOC, XLS, PPT належать до групи CFB-форматів.CFB-файл складається з 512-байтного заголовка і секторів однакової довжини, що зберігають потоки даних або службову інформацію. Кожен сектор має свій власний ненегативний номер, виняток становлять спеціальні номери: «-1» - нумерує вільний сектор, «-2» - нумерує сектор, який замикає ланцюжок. Усі бесіди секторів визначені в FAT-таблиці.
Припустимо, що зловмисник модифікував якийсь doc-файл і вклеїв в його кінець інший файл. Є кілька різних способів його виявити або вказати на аномалію в документі.
Аномальний розмір файлу
Як було сказано вище, будь-який CFB-файл складається з заголовка і секторів рівної довжини. Щоб дізнатися розмір сектора, необхідно вважати двухбайтное число на 30 зміщенні від початку файлу і звести 2 в ступінь цього числа. Дане число має дорівнювати або 9 (0x0009), або 12 (0x000C), відповідно, розмір сектора файлу дорівнює 512 або 4096 байт. Після знаходження сектора необхідно перевірити наступне рівність:(FileSize - 512) mod SectorSize \u003d 0
Якщо це рівність не виконується, то можна вказати на факт склейки файлів. Однак цей метод має істотний недолік. Якщо зловмисник знає розмір сектора, то йому достатньо приклеїти свій файл і ще n байт, щоб величина приклеєних даних була кратна розміру сектора.
Невідомий тип сектора
Якщо зловмисник знає про метод обходу попередньої перевірки, то даний метод може детектувати наявність секторів з невизначеними типами.Визначимо рівність:
FileSize \u003d 512 + CountReal * SectorSize, де FileSize - розмір файлу, SectorSize - розмір сектора, CountReal - кількість секторів.
Визначимо також наступні змінні:
- CountFat - кількість секторів FAT. Знаходиться на 44 зміщенні від початку файлу (4 байта);
- CountMiniFAT - кількість секторів MiniFAT. Знаходиться на 64 зміщенні від початку файлу (4 байта);
- CountDIFAT - кількість секторів DIFAT. Знаходиться на 72 зміщенні від початку файлу (4 байта);
- CountDE - кількість секторів Directory Entry. Для знаходження цієї змінної необхідно знайти перший сектор DE, який знаходиться на 48 зсуві. Потім необхідно отримати повне уявлення DE з FAT і порахувати число DE-секторів;
- CountStreams - кількість секторів з датастрімамі;
- CountFree - кількість вільних секторів;
- CountClassified - кількість секторів з певним типом;
Очевидно, що при нерівності CountClassified і CountReal можна зробити висновок про можливу склеюванні файлів.
The function code (FC) in the telegram header identifies the telegram type, such as Request telegram (Request or Send / Request) and Acknowledgement or Response telegram (Acknowledgement frame, Response frame). In addition the function code contains the actual transmission function and control information that prevent loss and duplication of messages, or the station type with FDL status.
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | FC: Function Code Request |
| 1 | Request Telegramm | |||||||
| X | FCV \u003d Alternating bit switched on | |||||||
| X | href \u003d "http://profibus.felser.ch/en/funktionscode.htm#aufruffolgebit»\u003e FCB \u003d Alternating bit (from frame count) | |||||||
| 1 | 0 (0x0) | CV \u003d Clock Value () | ||||||
| 1 | other | Reserved | ||||||
| 0 | 0 (0x0) | TE \u003d Time Event (Clock synchronization) | ||||||
| 0 | 3 (0x3) | SDA_LOW \u003d Send Data Acknowledged - low priority | ||||||
| 0 | 4 (0x4) | SDN_LOW \u003d Send Data Not acknowledged - low priority | ||||||
| 0 | 5 (0x5) | SDA_HIGH \u003d Send Data Acknowledged - high priority | ||||||
| 0 | 6 (0x6) | SDN_HIGH \u003d Send Data Not acknowledged | ||||||
| 0 | 7 (0x7) | MSRD \u003d Send Request Data with Multicast Reply | ||||||
| 0 | 9 (0x9) | Request FDL Status | ||||||
| 0 | 12 (0xC) | SRD low \u003d Send and Request Data | ||||||
| 0 | 13 (0xD) | SRD high \u003d Send and Request Data | ||||||
| 0 | 14 (0xE) | Request Ident with reply | ||||||
| 0 | 15 (0xF) | Request LSAP Status with reply 1) | ||||||
| 0 | other | Reserved | ||||||
1) this value is in the last version of the standard not defined anymore but only reserved
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | FC: Function Code Response |
| 0 | Response telegram | |||||||
| 0 | Reserved | |||||||
| 0 | 0 | Slave | ||||||
| 0 | 1 | Master not ready | ||||||
| 1 | 0 | Master ready, without token | ||||||
| 1 | 1 | Master ready, in token ring | ||||||
| 0 (0x0) | OK | |||||||
| 1 (0x1) | UE \u003d User Error | |||||||
| 2 (0x2) | RR \u003d No resources | |||||||
| 3 (0x3) | RS \u003d SAP not enabled | |||||||
| 8 (0x8) | DL \u003d Data Low (normal case with DP) | |||||||
| 9 (0x9) | NR \u003d No response data ready | |||||||
| 10 (0xA) | DH \u003d Data High (DP diagnosis pending) | |||||||
| 12 (0xC) | RDL \u003d Data not received and Data Low | |||||||
| 13 (0xD) | RDH \u003d Data not received and Data High | |||||||
| other | Reserved | |||||||
Frame Count Bit The frame count bit FCB (b5) prevents message duplication by the acknowledging or responding station (responder) and any loss by the calling station (initiator). Excluded from this are requests without acknowledgement (SDN) and FDL Status, Ident and LSAP Status requests.
For the security sequence, the initiator must carry an FCB for each responder. When a Request telegram (Request or Send / Request) is sent to a responder for the first time, or if it is re-sent to a responder currently marked as non-operational, the FCB must be set as defined in the responder. The initiator achieves this in a Request telegram with FCV \u003d 0 and FCB \u003d 1. The responder must assess a telegram of this kind as the first message cycle and store the FCB \u003d 1 together with the initiator's address (SA) (see following table). This message cycle will not be repeated by the initiator. In subsequent Request telegrams to the same responder, the initiator must set FCV \u003d 1 and change the FCB with each new Request telegram. Any responder that receives a Request telegram addressed to it with FCV \u003d 1 must evaluate the FCB. If the FCB has changed when compared with the last Request telegram from the same initiator (same SA), this is valid confirmation that the preceding message cycle was concluded properly. If the Request telegram originates from a different initiator (different SA), evaluation of the FCB is no longer necessary. In both cases, the responder must save the FCB with the source SA until receipt of a new telegram addressed to it. In the case of a lost or impaired acknowledgement or response telegram, the FCB must not be changed by the initiator in the request retry: this will indicate that the previous message cycle was faulty. If the responder receives a Request telegram with FCV \u003d 1 and the same FCB as the last Request telegram from the same initiator (same SA), this will indicate a request retry. The responder must in turn retransmit the acknowledgement or response telegram held in readiness. Until the above-mentioned confirmation or receipt of a telegram with a different address (SA or DA) that is not acknowledged (Send Data with No Acknowledge, SDN) the responder must hold the last acknowledgement or response telegram in readiness for any possible request retry . In the case of Request telegrams that are not acknowledged and with Request FDL Status, Ident, and LSAP Status, FCV \u003d 0 and FCB \u003d 0; evaluation by the responder is no longer necessary.
| b5 | b4 | Bit position | ||
| FCB | FCV | Condition | Meaning | Action |
| 0 | 0 | DA \u003d TS / 127 | Request without acknowledgement Request FDL Status / Ident / LSAP Status |
Delete last acknowledgement |
| 0/1 | 0/1 | DA # TS | Request to another responder | |
| 1 | 0 | DA \u003d TS | First request | FCBM: \u003d 1 SAM: \u003d SA Delete last acknowledgement / response |
| 0/1 | 1 | DA \u003d TS SA \u003d SAM FCB # FCBM |
New Request | Delete last acknowledgement / response FCBM: \u003d FCB Hold acknowledgement / response in readiness for retry |
| 0/1 | 1 | DA \u003d TS SA \u003d SAM FCB \u003d FCBM |
Retry Request | FCBM: \u003d FCB Repeat acknowledgement / response and continue to hold in readiness |
| 0/1 | 1 | DA \u003d TS SA # SAM |
New initiator | FCBM: \u003d FCB SAM: \u003d SA Hold acknowledgement / response in readiness for retry |
FCBM stored FCB in memory SAM stored SA in memory
поняття « магічне число»В програмуванні має три значення:
- сигнатура даних
- Виділені унікальні значення, які не повинні збігатися з іншими значеннями (наприклад, UUID)
- Погана практика програмування.
сигнатура даних
магічне число, або сигнатура, - целочисленная або текстова константа, яка використовується для однозначної ідентифікації ресурсу або даних. Таке число саме по собі не несе ніякого сенсу і може викликати подив, зустрівшись в коді програми без відповідного контексту або коментаря, при цьому спроба змінити його на інше, навіть близьке за значенням, може привести до абсолютно непередбачуваних наслідків. З цієї причини подібні числа були іронічно названі магічними. В даний час ця назва міцно закріпилася як термін. Наприклад, будь-який відкомпільований клас мови Java починається з шістнадцятирічного «магічного числа» 0xCAFEBABE. Другий широко відомий приклад - будь-який виконуваний файл ОС Microsoft Windows з расшіреніем.exe починається з послідовності байт 0x4D5A (що відповідає ASCII-символ MZ - ініціали Марка Збіковскі, одного з творців MS-DOS). Менш відомим прикладом є неініціалізованих покажчик в Microsoft Visual С ++ (починаючи з 2005 версії Microsoft Visual Studio), який в режимі налагодження має адресу 0xDEADBEEF.
В UNIX-подібних операційних системах тип файлу зазвичай визначається по сигнатурі файлу, незалежно від розширення його назви. Для інтерпретації сигнатури файлу в них передбачається стандартна утиліта file.
Погана практика програмування
Також «магічними числами» називають погану практику програмування, коли в початковому тексті зустрічається числове значення і неочевидно, що воно означає. Наприклад, такий фрагмент, написаний на Java, буде поганим:
drawSprite (53, 320, 240);
final int SCREEN_WIDTH \u003d 640; final int SCREEN_HEIGHT \u003d 480; final int SCREEN_X_CENTER \u003d SCREEN_WIDTH / 2; final int SCREEN_Y_CENTER \u003d SCREEN_HEIGHT / 2; final int SPRITE_CROSSHAIR \u003d 53; ... drawSprite (SPRITE_CROSSHAIR, SCREEN_X_CENTER, SCREEN_Y_CENTER);
Тепер зрозуміло: цей рядок виводить в центр екрана спрайт - перехрестя прицілу. У більшості мов програмування все значення, які використовуються для таких констант, будуть обчислені ще на етапі компіляції і підставлені в місця використання значень. Тому така зміна вихідного тексту не погіршує швидкодію програми.
Крім того, магічні числа - потенційне джерело помилок в програмі:
- Якщо один і той же магічне число використовується в програмі більше одного разу (або потенційно може використовуватися), то його зміна зажадає правок кожного входження (замість однієї правки значення іменованої константи). Якщо будуть виправлені не всі випадки, виникне як мінімум одна помилка.
- Як мінімум в одному з входжень магічне число може бути написано з помилкою спочатку, і це досить складно виявити.
- Магічне число може залежати від неявного параметра або іншого магічного числа. Якщо ці залежності, не виділені явно, не будуть задоволені, виникне як мінімум одна помилка.
- При модифікації входжень одного магічного числа можна помилково змінити інше магічне число, незалежне, але має той же числове значення.
Магічні числа та кроссплатформенность
Іноді магічні числа шкодять платформ коду. Справа в тому, що в Сі в 32- і 64-бітних ОС гарантується розмір типів char, short і long long, в той час як розмір int, long, size_t і ptrdiff_t може змінюватися (у перших двох - в залежності від уподобань розробників компілятора , у останніх двох - у залежності від розрядності цільової системи). У старому або некваліфіковано написаному коді можуть зустрічатися «магічні числа», що означають розмір будь-якого типу - при переході на машини з іншого розрядністю вони можуть привести до важковловимий помилок.
наприклад:
const size_t NUMBER_OF_ELEMENTS \u003d 10; long a [NUMBER_OF_ELEMENTS]; memset (a, 0, 10 * 4); // неправильно - мається на увазі, що long дорівнює 4 байтам, використовується магічне число елементів memset (a, 0, NUMBER_OF_ELEMENTS * 4); // неправильно - мається на увазі, що long дорівнює 4 байтам memset (a, 0, NUMBER_OF_ELEMENTS * sizeof (long)); // не зовсім правильно - дублювання імені типу (якщо зміниться тип, то доведеться міняти і тут) memset (a, 0, NUMBER_OF_ELEMENTS * sizeof (a [0])); // правильно, оптимально для динамічних масивів ненульового розміру memset (a, 0, sizeof (a)); // правильно, оптимально для статичних масивів
Числа, які не є магічними
Не всі числа потрібно переносити в константи. Наприклад, код на
Пошук при скануванні файлів відомих типів (або, як часто говорять, пошук файлів по сигнатурам) є однією з найбільш ефективних, використовуваних в утиліті відновлення даних R-Studio. Використання заданої сигнатури дозволяє відновлювати файли певного типу в тому випадку, коли частково або повністю відсутня (пошкоджена) інформація по структурі каталогів і імен файлів.
Зазвичай для визначення місця розташування файлів використовується таблиця розділів диска. Якщо порівняти диск з книгою, то таблиця розділів буде аналогічна її змісту. При скануванні R-Studio шукає файли відомих типів в таблиці розділів диска за певними заданими сигнатурам. Це стає можливим завдяки тому, що практично кожен тип файлу має унікальну сигнатуру або шаблон даних. Файлові сигнатури знаходяться в певному місці на початку файлу і в багатьох випадках також і в кінці файлу. При скануванні R-Studio зіставляє знайдені дані з сигнатурами файлів відомих типів, що дозволяє їх ідентифікувати і відновити їх дані.
За допомогою технології сканування файлів відомих типів R-Studio дозволяє відновити дані з дисків, які були переформатовані, а також таблиці розділів яких були перезаписані. Більш того, якщо розділ диска перезаписан, пошкоджений або знищений, то сканування файлів відомих типів є єдино можливим.
Але практично завжди і у всьому є свої недоліки, і файли відомих типів, які використовуються в R-Studio, не є винятком. Так, при скануванні файлів відомих типів R-Studio відновлює лише те нефрагментовані файли, але, як уже говорилося, в більшості це самий останній з можливих методів.
До складу R-Studio вже включені сигнатури найбільш распростанение типів файлів (переглянути повний список файлів відомих типів можна в розділі R-Studio Online Довідки.)
У разі необхідності користувач може додати нові типи файлів до складу R-Studio. Наприклад, якщо необхідно знайти файли будь-якого унікального типу, або ж розробленого після дати останнього випуску R-Studio, то можна додати до складу файлів відомих типів власні сигнатури. Далі буде розглянуто даний процес.
Призначені для користувача файли Відомих Типів
Призначені для користувача сигнатури файлів відомих типів зберігаються в XML файлі, заданого в діалоговому вікні Налаштування. Додавання сигнатури складається з двох частин:
- Визначення файлової сигнатури знаходиться на початку файлу і при наявності в кінці файлу.
- Створення XML файлу, що містить файлову сигнатуру і іншу інформацію про тип файлів.
Все це можна виконати за допомогою R-Studio. При цьому вам не потрібно бути фахівцем в області складання (редагування) XML документів або в області шестнадцатиричного редагування - в цьому посібнику (статті), орієнтованому на користувача самого початкового рівня, будуть детально розглянуті всі етапи цього процесу.
Приклад: Додавання сигнатури для файлу формату MP4 (XDCam-EX Codec)
Розглянемо додавання файлової сигнатури на прикладі файла.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. Визначимо файлову сигнатуру на початку файлу. У нашому прикладі вона знаходиться на самому початку файлу. Зверніть увагу, що так відбувається не завжди - часто файлова сигнатура знаходиться на початку файлу, але не в першому рядку (зміщення).
З наведених нижче зображень слід, що вміст всіх чотирьох файлів по-різному, але всі вони починаються з однієї і тієї ж файлової сигнатури. 
Клацніть по зображенню для його збільшення
Клацніть по зображенню для його збільшення
Клацніть по зображенню для його збільшення
Клацніть по зображенню для його збільшення
Виділена область на зображеннях є файлової сигнатурою даного типу файлів. Вона представлена \u200b\u200bяк в текстовому, так і в шестнадцатиричном вигляді.
InВ текстовому вигляді файлова сигнатура має наступний вигляд:
.... ftypmp42 .... mp42 ........ free
Точками ( ".") Позначені символи, які не можуть бути представлені в текстовому вигляді. Тому необхідно також привести і шістнадцятковий вид файлової сигнатури:
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 \u003d "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 Використовуючи вбудований графічний редактор файлових сигнатур:
Виберіть пункт Налаштування (Settings) меню Інструменти (Tools), в діалоговому вікні Налаштування (Settings) клацніть по вкладці Відомі типи файлів (Known Files Types) і далі натисніть кнопку Редагувати ... (Edit User's File Types). 
Клацніть по зображенню для його збільшення
Натисніть кнопку Створити тип файлу (Create File Type) в діалоговому вікні Редагування власних типів (Edit User "s File Types).
Задайте наступні параметри:
- Id - унікальний цифровий ідентифікатор. Дане число буде вибрано довільно; єдине, воно не повинно збігатися з цифровим кодом будь-якого іншого типу файлів.
- Group Description - група, в якій будуть знаходиться знайдені файли в R-Studio. Можна задати або нову групу, або вибрати одну з тих які вже є. У нас це буде група "Multimedia Video (Мультимедіа: Відео)".
- Description - короткий опис типу файлів. У нашому прикладі можна використовувати, наприклад, "Sony cam video, XDCam-EX".
- Extension - розширення файлів даного типу. У нашому випадку - mp4.
Параметр Властивості (Features) необов'язковий, в нашому випадку нам не потрібно його використовувати. 
Клацніть по зображенню для його збільшення
Далі необхідно ввести початкову і кінцеву файлову сигнатуру. Для цього виберіть Початок (Begin) і далі в контекстному меню команду Додати сигнатуру (Add Signature). 
Клацніть по зображенню для його збільшення
Потім двічі клацніть по полю<пустая сигнатура> (
Клацніть по зображенню для його збільшення
Потім створіть кінцеву файлову сигнатуру. Не забудьте ввести 21 в поле стовпця Від (From). 
Клацніть по зображенню для його збільшення
Ви успішно створили власну сигнатуру файлів відомого типу.
Тепер необхідно її зберегти. Є два способи: ви можете або зберегти її в файл за умовчанням заданий на вкладці Основне (Main) діалогового вікна Налаштування (Settings) натиснувши на кнопку Зберегти (Save). Або натиснути на кнопку Зберегти як ... (Save As ...) і зберегти сигнатуру в будь-якій іншій файл.
2.2 Створення XML файлу, що описує Відомий Тип фото, вручну:
Для створення даного файлу скористаємося XML версією 1.0 і кодуванням UTF-8. Не впадайте у відчай, якщо ви не знаєте, що це таке, - просто відкрийте будь-який текстовий редактор (наприклад, Notepad.exe) і в першому рядку ввести наступний текст:
Далі ми створимо XML тег, що визначає тип файлу (FileType). З урахуванням описаних раніше атрибутів XML тег буде виглядати наступним чином:
Вставимо його відразу після
Далі визначимо файлову сигнатуру (тег
У разі наявності необхідно також визначити кінцеву сигнатуру (в кінці файлу). Для цього використовується той же тег, але з елементом "from" і атрибутом "end". Це буде виглядати наступним чином:
Згадайте, що в кінцевій файлової сигнатуре не було нетекстових символів, проте був слеші і трикутні дужки. Щоб уникнути плутанини і помилок в синтаксисі XML ми замінимо в сигнатурі символи "/", "<" и ">"Їх Шістнадцяткова значеннями.
В кінці після файлових сигнатур обов'язково повинні знаходитися закривають теги FileType і FileTypeList:
Таким чином, весь файл повинен виглядати наступним чином:
Пам'ятайте: синтаксис XML чутливий до регістру, отже, правильним буде тег
Збережемо файл в текстовому форматі з расшіреніем.xml. Наприклад: SonyCam.xml.
Ми успішно створили власну сигнатуру файлів відомого типу. Даний приклад цілком достатній для розуміння основних принципів створення призначеного для користувача типу файлів. Більш досвідчені користувачі можуть використовувати XML версії 2.0. Детальніше про це можна прочитати в розділі R-Studio online Довідки.
Етап 3: Перевірка і Додавання файлу, що описує Відомий Тип фото
На наступному етапі необхідно додати (завантажити) ваш XML файл в R-Studio. При цьому він буде автоматично перевірено.
Завантажимо в R-Studio створений на попередньому етапі XML файл. Для цього виберемо пункт Налаштування (Settings) меню Інструменти (Tools). В області для користувача типи файлів (User's file types) вкладки Головна (Main) діалогового вікна Налаштування (Settings) додамо створений нами XML файл (SonyCam.xml). Натиснемо кнопку Застосувати (Apply). 
Клацніть по зображенню для його збільшення
2. Відповімо Так (Yes) на запит про завантаження нового типу файлів. 
Клацніть по зображенню для його збільшення
3. Для перевірки того, що тип файлів був успішно завантажений, клацнемо на вкладку Відомі Типи фото (Known File Types) діалогового вікна Налаштування (Settings). Згадайте, що ми додавали тип файлів в групу Multimedia Video (Мультимедіа: Відео). Розкривши цю групу (папку), ми повинні побачити елемент з описом, заданим нами при створенні XML файлу: Sony cam video, XDCam-EX (.mp4). 
Клацніть по зображенню для його збільшення
Клацніть по зображенню для його збільшення
Якщо в синтаксисі файлу є які-небудь помилки, то ви побачите відповідне повідомлення: 
Клацніть по зображенню для його збільшення
В цьому випадку перевірте ще раз ваш XML файл на наявність помилок. Пам'ятайте: синтаксис XML чутливий до регістру і для кожного тега в кінці обов'язково повинен знаходитися закриває тег.
Етап 4: Тестування файлу, що описує Відомий Тип фото
ля перевірки коректності створеного нами призначеного для користувача типу файлів спробуємо знайти наші.mp4 файли на знімному USB флеш-диску.
1. Під ОС Windows Vista або Windows 7 виконаємо повне (не швидка) форматування диска або скористаємося утилітою очищення дискового простору (наприклад, R-Wipe & Clean) для повного видалення всіх наявних на диску даних. Нехай USB диск отформітрован в FAT32 (розмір шуканих файлів не перевищує 2 Гб).
2. Перекопіруем тестові файли на диск і перезавантажити комп'ютер, щоб на диску було збережено вміст кеш-пам'яті. Також можна відключити зовнішній диск і потім підключити його знову.
3. В ОС диск буде визначено як, наприклад, логічний диск F: \\.
4. Запустимо R-Studio. Виберемо наш диск (F: \\) і натиснемо кнопку Сканувати (Scan) 
Клацніть по зображенню для його збільшення
5. У діалоговому вікні Сканувати (Scan) в області (File System) клацнемо на кнопку Змінити ... (Change ...) і знімемо всі прапорці. Таким чином ми відключимо пошук файлових систем і файлів, використовуючи таблицю розділів. 
Клацніть по зображенню для його збільшення
6. Встановимо прапорець Додатково Шукати Відомі Типи фото (Extra Search for Known File Types). Це дозволить R-Studio шукати при скануванні файли відомих типів.
7. Щоб почати сканування натиснемо кнопку Сканувати (Scan).
8. Почекаємо, поки R-Studio сканує диск. На вкладці Інформація про сканування (Scan Information) буде відображатися хід сканування (прогрес). 
Клацніть по зображенню для його збільшення
9. Після закінчення сканування виберемо елемент Додатково Знайдені Файли (Extra Found Files) і двічі клацнемо по ньому мишею. 
Клацніть по зображенню для його збільшення
10. Наші тестові файли будуть знаходитися в папці Sony cam video, XDCam-EX folder (або в папці під іншою назвою, відповідним опису типу файлів, заданому на Другому Етапі). 
Клацніть по зображенню для його збільшення
Ви бачите, що імена файлів, дати і місце розташування (папки) не були поновлені, так як дана інформація зберігається в файлової системі. Тому в R-Studio автоматично кожен файл буде відображено з новим ім'ям.
Однак видно, що вміст файлів не пошкоджено. Щоб в цьому переконатися, відкриємо їх у відповідній програмі, наприклад VLC media player. 
Клацніть по зображенню для його збільшення
висновок
Можливість R-Studio при скануванні шукати файли відомих типів дозволяє відновлювати дані навіть з диска, чиї файлововие системи або або перезаписані. Ви можете досить ефективно шукати файли використовуючи їх сигнатури, що особливо корисно в тому випадку, якщо вам точно відомий тип відновлюваних файлів, як, наприклад, в нашому прикладі. Можливість створювати власні типи файлів дозволяє додати в список файлів відомих типів будь-який файл, який має певну файлову сигнатуру.
Начальство поставило мені досить цікаве завдання. У стислі терміни написати аналізатор виконуваних файлів, який по сигнатурам вмів би знаходити тіла вірусів і визначати використовуваний пакувальник / криптор. Готовий прототип з'явився вже через пару годин.
слово автора
сигнатурний аналіз
Пошук шкідливого об'єкта по сигнатурам - це те, що вміє будь-антивірус. У загальному випадку сигнатура - це формалізований опис деяких ознак, за якими можна визначити, що сканований файл - це вірус і вірус цілком певний.
Тут є різні методики. Як варіант - використовувати сигнатуру, складену з N байт шкідливого об'єкта. При цьому можна зробити не тупе порівняння, а порівняння з деякою масці (типу шукати байти EB ?? ?? CD 13). Або ставити додаткові умови на кшталт «такі-то байти повинні перебувати у точки входу в програму» і так далі. Сигнатура саме малварі - це випадковість.
Точно так же описуються деякі ознаки, за якими можна визначити, що виконуваний файл упакований тим чи іншим криптор або пакувальником (наприклад, банальним ASPack). Якщо ти уважно читаєш наш журнал, то точно чув про таку ТУЛЗ як PEiD, здатної визначати найбільш часто використовувані пакувальники, криптор і компілятори (в базі є велика кількість сигнатур) для переданого їй PE-файла. На жаль, нові версії програми давно не виходять, а недавно на офіційному сайті і зовсім з'явилося повідомлення, що подальшого розвитку проекту не буде. Шкода, тому що можливості PEiD (особливо з огляду на систему плагінів) цілком могли виявитися мені корисними. Після недовгого аналізу все-таки стало ясно, що це не варіант. Але покопавшись в англомовних блогах, я швидко знайшов те, що мені підійшло. Проект YARA (code.google.com/p/yara-project).
Що таке YARA?
Я був з самого початку переконаний, що десь в Мережі вже є відкриті розробки, яка б взяли на себе завдання визначення відповідності між деякої сигнатурою і досліджуваним файлом. Якби я зміг знайти такий проект, то його легко можна було б поставити на рейки веб-додатки, додати туди різних сигнатур і отримати те, що від мене вимагалося. План став здаватися ще більш реальним, коли я прочитав опис проекту YARA.
Самі розробники позиціонують його як інструмент для допомоги дослідникам малварі в ідентифікації та класифікації шкідливих семплів. Дослідник може створити опису для різного типу зловредів, використовуючи текстові або бінарні патерни, в яких описуються формалізовані ознаки малварі. Таким чином виходять сигнатури. По суті, кожне опис складається з набору рядків і деякого логічного виразу, на основі якого визначається логіка спрацьовування аналізатора.
Якщо для досліджуваного файлу виконуються умови одного з правил, він визначається відповідним чином (наприклад, черв'як такий-то). Простий приклад правила, щоб розуміти, про що йде мова:
rule silent_banker: banker
{
meta:
description \u003d "This is just an example"
thread_level \u003d 3
in_the_wild \u003d true
strings:
$ A \u003d (6A 40 68 00 30 00 00 6A 14 8D 91)
$ B \u003d (8D 4D B0 2B C1 83 C0 27 99 6A 4E 59 F7 F9)
$ C \u003d "UVODFRYSIHLNWPEJXQZAKCBGMT"
condition:
$ A or $ b or $ c
}
У цьому правилі ми говоримо YARA, що будь-який файл, який містить хоча б одну з рядків-семплів, описаних в змінних $ a, $ b, $ c, повинен класифікуватися як троян silent_banker. І це дуже просте правило. На ділі рулеси можуть бути набагато складніше (ми про це поговоримо нижче).
Про авторитет проекту YARA говорить вже навіть список проектів, які його використовують, а це:
- VirusTotal Malware Intelligence Services (vt-mis.com);
- jsunpack-n (jsunpack.jeek.org);
- We Watch Your Website (wewatchyourwebsite.com).
Весь код написаний на Python, причому користувачеві пропонується як сам модуль для використання в своїх розробках, так і просто виконуваний файл, щоб юзати YARA як самостійний додаток. В рамках своєї роботи я вибрав перший варіант, але для простоти в статті ми будемо використовувати аналізатор просто як консольний додаток.
Трохи покопавшись, я досить швидко розібрався, як писати для YARA правила, а також як прикрутити до нього сигнатури вірусів від безкоштовного Авер і пакувальників від PEiD. Але почнемо ми з установки.
установка
Як я вже сказав, проект написаний на Python'е, тому легко може бути встановлений і на Linux, і на Windows, і на Mac. На перших порах можна просто взяти бінарник. Якщо викликати додаток в консолі, то отримаємо правила для запуску.
$ yara
usage: yara ... ... FILE | PID
Тобто формат виклику програми наступний: спочатку йде ім'я програми, потім список опцій, після чого вказується файл з правилами, а в самому кінці - ім'я досліджуваного файлу (або каталогу, що містить файли), або ідентифікатор процесу. Зараз би по-хорошому пояснити, як ці самі правила складаються, але не хочу відразу вантажити тебе сухою теорією. Тому ми зробимо по-іншому і запозичимо чужі сигнатури, щоб YARA міг виконувати одну з поставлених нами завдань - повноцінне визначення вірусів по сигнатурам.
свій антивірус
Найголовніше питання: де взяти базу сигнатур відомих вірусів? Антивірусні компанії активно діляться такими базами між собою (хтось більш щедро, хтось - менше). Якщо чесно, я спочатку навіть сумнівався, що десь в Мережі хтось відкрито викладає подібні речі. Але, як виявилося, є добрі люди. Відповідна база з популярного антивіруса ClamAV доступна всім бажаючим (clamav.net/lang/en). У розділі «Latest Stable Release» можна знайти посилання на останню версію антивірусного продукту, а також посилання для скачування вірусних баз 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 () з мови С / С ++.
rule BadBoy
{
strings:
$ A \u003d "win.exe"
$ B \u003d "http://foo.com/badfi le1.exe"
$ C \u003d "http://bar.com/badfi le2.exe"
condition:
$ A and ($ b or $ c)
}
В принципі, нічого складного в написанні правил немає. В рамках цієї статті я торкнувся лише основних моментів, а деталі ти знайдеш в манула. Поки ж десять найважливіших пунктів:
1. Кожне правило починається з ключового слова rule, після якого йде ідентифікатор правила. Ідентифікатори можуть мати такі ж імена, як і змінні в C / С ++, тобто складатися з букв і цифр, причому перший символ не може бути цифрою. Максимальна довжина імені ідентифікатора - 128 символів.
2. Зазвичай правила складаються з двох секцій: секція визначень (strings) і секція умови (condition). У секції strings задаються дані, на основі яких в секції condition буде прийматися рішення, чи задовольняє заданий файл певним умовам.
3. Кожен рядок в розділі strings має свій ідентифікатор, який починається зі знака $ - в загальному, як оголошення змінної в php. YARA підтримує звичайні рядки, укладені в подвійні лапки ( "") і шістнадцяткові рядки, укладені у фігурні дужки (()), а також регулярні вирази:
$ My_text_string \u003d "text here"
$ My_hex_string \u003d (E2 34 A1 C8 23 FB)
4. У секції condition міститься вся логіка правила. Ця секція повинна містити логічне вираз, що визначає, в якому випадку файл або процес задовольняє правилу. Зазвичай в цій секції йде звернення до раніше оголошених рядках. А ідентифікатор рядка розглядається в якості логічної змінної, яка повертає true, якщо рядок була знайдена в файлі або пам'яті процесу, і false у противному випадку. Вищевказане правило визначає, що файли і процеси, що містять рядок win.exe і один з двох URL, повинні бути віднесені до категорії BadBoy (по імені правила).
5. Шістнадцятиричні рядки дозволяють використовувати три конструкції, які роблять їх більш гнучкими: підстановки (wildcards), діапазони (jumps) і альтернативний вибір (alternatives). Підстановки - це місця в рядку, які невідомі, і на їх місці може бути будь-яке значення. Позначаються вони символом «?»:
$ Hex_string \u003d (E2 34 ?? C8 A? FB)
Такий підхід дуже зручний при завданні рядків, довжина яких відома, а вміст може змінюватися. Якщо ж частина рядка може бути різної довжини, зручно використовувати діапазони:
$ Hex_string \u003d (F4 23 62 B4)
Даний запис означає, що в середині рядка може бути від 4 до 6 різних байт. Можна реалізувати також і альтернативний вибір:
$ Hex_string \u003d (F4 23 (62 B4 | 56) 45)
Це означає, що на місці третього байта може бути 62 В4 або 56, такого запису відповідають рядки F42362B445 або F4235645.
6. Щоб перевірити, що заданий рядок знаходиться за певною зміщення в файлі або адресному просторі процесу, використовується оператор at:
$ A at 100 and $ b at 200
Якщо рядок може знаходитися всередині певного діапазону адрес, використовується оператор in:
$ A in (0..100) and $ b in (100..fi lesize)
Іноді виникають ситуації, коли необхідно вказати, що файл повинен містити певну кількість із заданого набору. Робиться це за допомогою оператора of:
rule OfExample1
{
strings:
$ Foo1 \u003d "dummy1"
$ Foo2 \u003d "dummy2"
$ Foo3 \u003d "dummy3"
condition:
2 of ($ foo1, $ foo2, $ foo3)
}
Наведене правило вимагає, щоб файл містив будь-які два рядки з безлічі ($ foo1, $ foo2, $ foo3). Замість вказівки конкретного числа рядків у файлі можна використовувати змінні any (хоча б один рядок із заданої множини) і all (всі рядки із заданої множини).
7. Ну і остання цікава можливість, яку треба розглянути - застосування однієї умови до багатьох рядках. Ця можливість дуже схожа на оператор of, тільки більш потужна - це оператор for..of:
for expression of string_set: (boolean_expression)
Цей запис треба читати так: з рядків, заданих в string_ set, принаймні expression штук повинно задовольняти умові boolean_expression. Або, іншими словами: вираз boolean_expression обчислюється для кожного рядка з string_set, і expression з них повинні повернути значення True. Далі ми розглянемо цю конструкцію на конкретному прикладі.
робимо PEiD
Отже, коли з правилами все стало більш-менш зрозуміло, можна приступати до реалізації в нашому проекті детектора пакувальників та криптор. В якості вихідного матеріалу на перших порах я запозичив сигнатури відомих пакувальників у все того ж PEiD. В папці plugins знаходиться файл userdb.txt, який і містить те, що нам потрібно. У моїй базі виявилося 1850 сигнатур.
Чимало, так що для того, щоб повністю імпортувати їх, раджу написати якийсь скриптик. Формат цієї бази простий - використовується звичайний текстовий файл, в якому зберігаються записи виду:
signature \u003d 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 \u003d true
Перший рядок задає ім'я пакувальника, яке буде відображатися в PEiD, для нас же це буде ідентифікатор правила. Друга - безпосередньо сама сигнатура. Третя - прапор ep_only, який вказує, чи шукати цього рядка тільки за адресою точки входу, або ж по всьому файлу.
Ну що, спробуємо створити правило, скажімо, для ASPack? Як виявилося, в цьому немає нічого складного. Спочатку створимо файл для зберігання правил і назвемо його, наприклад, packers.yara. Потім шукаємо в базі PEiD все сигнатури, в назві яких фігурує ASPack, і переносимо їх в правило:
rule ASPack
{
strings:
$ \u003d (60 E8 ?? ?? ?? ?? 5D 81 ED ?? ?? (43 | 44) ?? B8 ?? ?? (43 | 44) ?? 03 C5)
$ \u003d (60 EB ?? 5D EB ?? FF ?? ?? ?? ?? ?? E9)
[.. вирізане ..]
$ \u003d (60 E8 03 00 00 00 E9 EB 04 5D 45 55 C3 E8 01)
condition:
for any of them: ($ at entrypoint)
}
У всіх знайдених записів прапор ep_only встановлений в true, тобто ці рядки повинні розташовуватися за адресою точки входу. Тому ми пишемо наступне умова: «for any of them: ($ at entrypoint)».
Таким чином, наявність хоч однієї із заданих рядків за адресою точки входу означатиме, що файл упакований ASPack'ом. Зверни також увагу, що в даному правилі всі рядки задані просто за допомогою знака $, без ідентифікатора. Це можливо, тому що в condition-секції ми не звертаємося до якихось конкретних з них, а використовуємо весь набір.
Щоб перевірити працездатність отриманої системи, досить виконати в консолі команду:
$ Yara -r packers.yara somefi le.exe
Згодувавши туди пару додатків, упакованих ASPack'ом, я переконався, що все працює!
готовий прототип
YARA виявився на рідкість зрозумілим і прозорим інструментом. Мені не склало великих труднощів написати для нього вебадмінку і налагодити роботу в якості веб-сервісу. Трохи креативу, і сухі результати аналізатора вже розфарбовуються різними кольорами, позначаючи ступінь небезпеки знайденого зловреда. Невелике оновлення бази, і для багатьох з криптор є короткий опис, а іноді навіть і інструкція з розпакування. Прототип створений і працює відмінно, а начальство танцює від захвату!
