Сигнатури форматів файлів. Сигнатурні відносини: Аналізатор файлів та антивірус - своїми руками. Невідомий тип сектору

Поняття « Магічна кількість» у програмуванні має три значення:

• Сигнатура даних
• Виділені унікальні значення, які не повинні співпадати з іншими значеннями (наприклад, UUID)
• Погана практика програмування.

Сигнатура даних

Магічна кількість, або сигнатура, -- цілісна чи текстова константа , використовувана для однозначної ідентифікації ресурсу чи даних . Така кількість сама по собі не несе жодного сенсу і може викликати здивування, зустрівшись у коді програми без відповідного контексту або коментаря, при цьому спроба змінити його на інше, навіть близьке за значенням, може призвести до абсолютно непередбачуваних наслідків. Тому подібні числа були іронічно названі магічними. В даний час ця назва міцно закріпилася як термін. Наприклад, будь-який відкомпільований клас мови Java починається з шістнадцяткового «магічного числа» 0xCAFEBABE . Другий широко відомий приклад - будь-який виконуваний файл ОС Microsoft Windows з розширенням. Менш відомим прикладом є неініціалізований покажчик Microsoft Visual C++ (починаючи з 2005 версії Microsoft Visual Studio), який в режимі налагодження має адресу 0xDEADBEEF .

У UNIX-подібних операційних системах тип файлу зазвичай визначається за сигнатурою файлу незалежно від розширення його назви. Для інтерпретації сигнатури файлу у них передбачається стандартна утиліта file.

Погана практика програмування

Також «магічними числами» називають погану практику програмування, як у вихідному тексті зустрічається числове значення й неочевидно, що означає. Наприклад, такий фрагмент, написаний на Java, буде поганим:

drawSprite (53, 320, 240);

final int SCREEN_WIDTH = 640; final int SCREEN_HEIGHT = 480; final int SCREEN_X_CENTER = SCREEN_WIDTH/2; final int SCREEN_Y_CENTER = SCREEN_HEIGHT/2; final int SPRITE_CROSSHAIR = 53; ... drawSprite (SPRITE_CROSSHAIR , SCREEN_X_CENTER , SCREEN_Y_CENTER );

Тепер зрозуміло: цей рядок виводить у центр екрану спрайт – перехрестя прицілу. У більшості мов програмування всі значення, що використовуються для таких констант, будуть обчислені ще на етапі компіляції та підставлені до місць використання значень. Тому така зміна вихідного тексту не погіршує швидкодію програми.

Крім того, магічні числа - потенційне джерело помилок у програмі:

• Якщо одне й те магічне число використовується в програмі більше одного разу (або потенційно може використовуватися), то його зміна вимагатиме правок кожного входження (замість однієї правки значення іменованої константи). Якщо виправлять не всі входження, виникне щонайменше одна помилка.
• Як мінімум в одному з входжень магічна кількість може бути написано з помилкою спочатку, і це досить складно виявити.
• Магічне число може залежати від неявного параметра чи іншого магічного числа. Якщо ці залежності, не виділені явно, не будуть задоволені, виникне щонайменше одна помилка.
• При модифікації входжень одного магічного числа можна помилково змінити інше магічне число, незалежне, але таке ж числове значення.

Магічні числа та кросплатформність

Іноді магічні числа шкодять кроссплатформенності коду. Справа в тому, що в Сі в 32- і 64-бітних ОС гарантується розмір типів char, short і long long, у той час як розмір int, long, size_t і ptrdiff_t може змінюватися (у перших двох - залежно від переваг розробників компілятора , В останніх двох - в залежності від розрядності цільової системи). У старому або некваліфіковано написаному коді можуть зустрічатися "магічні числа", що означають розмір якого-небудь типу - при переході на машини з іншою розрядністю вони можуть призвести до помилок, що важко вловити.

Наприклад:

const size_t NUMBER_OF_ELEMENTS = 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)); // Правильно, оптимально для статичних масивів

Числа, які не є магічними

Не всі числа потрібно переносити до константів. Наприклад, код на

Багато хто міг чути про такі файли, як rarjpeg"і. Це особливий вид файлів, що являє собою склеєну впритул jpeg-картинку і rar-архів. Він є чудовим контейнером для приховування факту передачі інформації. Створити rarjpeg можна за допомогою наступних команд:

UNIX: cat image1.jpg archive.rar > image2.jpg
WINDOWS: copy /b image1.jpg+archive.rar image2.jpg

Або ж за наявності hex-редактора.

Зрозуміло, для приховування факту передачі можна використовувати не тільки формат JPEG, але і багато інших. Кожен формат має свої особливості, завдяки яким може підходити чи ні для ролі контейнера. Я опишу, як можна знайти приклеєні файли в найбільш популярних форматах або вказати на факт склеювання.

Методи детектування склеєних файлів можна розділити на три групи:

1. Метод перевірки області після EOF-маркера. Багато популярних форматів файлів мають так званий маркер кінця файлу, який відповідає за відображення потрібних даних. Наприклад, програми для перегляду фотографій зчитують усі байти аж до цього маркера, однак область після нього залишається ігнорованою. Цей метод ідеально підходить для форматів: JPEG, PNG, GIF, ZIP, RAR, PDF.
2. Спосіб перевірки розміру файла. Структура деяких форматів (аудіо та відеоконтейнери) дозволяє обчислити реальний розмір файлу і порівняти його з вихідним розміром. Формати: AVI, WAV, MP4, MOV.
3. Спосіб перевірки CFB-файлів. CFB або Compound File Binary Format - формат документів, розроблений у Microsoft, що є контейнером з власною файловою системою. Цей метод ґрунтується на виявленні аномалій у файлі.

Чи є життя після завершення файлу?

JPEG

Після цієї сигнатури знаходиться службова інформація, опціонально іконка зображення та, нарешті, саме стисло зображення. У цьому форматі кінець зображення відзначається двобайтною сигнатурою 0xFF 0xD9.

PNG

RAR

Таблиця форматів та їх сигнатур:
Алгоритм перевірки на склеювання в даних форматах гранично простий:

1. Знайти початкову сигнатуру;
2. Знайти кінцеву сигнатуру;
3. Якщо після кінцевої сигнатури немає даних – ваш файл чистий і не містить вкладень! Інакше потрібно шукати після кінцевої сигнатури інші формати.

GIF та PDF

1. Пункт 1 повторюється із попереднього алгоритму.
2. Пункт 2 повторюється із попереднього алгоритму.
3. При знаходженні кінцевої сигнатури запам'ятати її розташування та шукати далі;
4. Якщо так дійшли до останнього EOF-маркера - файл чистий.
5. Якщо файл не закінчується кінцевою сигнатурою - це місце останньої знайденої кінцевої сигнатури.

ZIP

Для перевірки ZIP-архіву необхідно знайти кінцеву сигнатуру центральної директорії, пропустити 18 байт та шукати сигнатури відомих форматів у області коментаря. Великий розмір коментаря також свідчить про факт склеювання.

Розмір має значення

AVI

Приклад обчислення розміру:

WAV

MP4

Розглянемо приклад. Розмір першого блоку знаходиться на нульовому зміщенні, і він дорівнює 28 (0000001С, порядок байт Big Endian); він вказує на зсув, де знаходиться розмір другого блоку даних. На 28 зсуві знаходимо наступний розмір блоку рівний 8 (0000088). Щоб знайти наступний розмір блоку, потрібно складати розміри знайдених попередніх блоків. Таким чином, обчислюється розмір файлу:

MOV

Метод перевірки цієї групи форматів на наявність «приклеєних» файлів полягає у обчисленні розміру за заданими вище правилами та порівнянні його з розміром файлу, що перевіряється. Якщо поточний розмір файлу набагато менше обчисленого, це вказує на факт склейки. При перевірці AVI-файлів допускається, що обчислений розмір може бути меншим за розмір файлу через наявність доданих нулів для вирівнювання кордону. У такому випадку необхідно перевіряти нулі після обчисленого розміру файлу.

Перевіряємо Compound File Binary Format

CFB-файл складається з 512-байтного заголовка та секторів однакової довжини, що зберігають потоки даних або службову інформацію. Кожен сектор має власний неотрицательный номер, виняток становлять спеціальні номери: «-1» - нумерує вільний сектор, «-2» - нумерує сектор, що замикає ланцюжок. Усі ланцюжки секторів визначені у FAT-таблиці.

Припустимо, що зловмисник модифікував якийсь doc-файл і вклеїв у його кінець інший файл. Є кілька різних способів виявити або вказати на аномалію в документі.

Аномальний розмір файлу

(FileSize - 512) mod SectorSize = 0

Якщо ця рівність не виконується, можна вказати на факт склеювання файлів. Однак цей метод має значний недолік. Якщо зловмисник знає розмір сектора, йому досить приклеїти свій файл і ще n байт, щоб величина приклеєних даних була кратна розміру сектора.

Невідомий тип сектору

Визначимо рівність:

FileSize = 512 + CountReal * SectorSize, де FileSize – розмір файлу, SectorSize – розмір сектора, CountReal – кількість секторів.

Визначимо також такі змінні:

1. CountFat – кількість секторів FAT. Знаходиться на 44 зміщенні від початку файлу (4 байти);
2. CountMiniFAT – кількість секторів MiniFAT. Знаходиться на 64 зсуві від початку файлу (4 байти);
3. CountDIFAT – кількість секторів DIFAT. Знаходиться на 72 зміщенні від початку файлу (4 байти);
4. CountDE – кількість секторів Directory Entry. Для знаходження цієї змінної необхідно знайти перший сектор DE, що знаходиться на 48 зміщенні. Потім необхідно отримати повне уявлення DE з FAT та порахувати число DE-секторів;
5. CountStreams – кількість секторів із датастримами;
6. CountFree – кількість вільних секторів;
7. CountClassified – кількість секторів із певним типом;

Очевидно, що при нерівності CountClassified та CountReal можна зробити висновок про можливе склеювання файлів.

Функція коду (FC) в телеграмі повідомлень використовується для телеграм типу, так як Request telegram (Request or Send/Request) and Acknowledgement or Response telegram (Acknowledgement frame, Response frame). У порівнянні з функцією code contains the actual transmission функція і управління інформацією, що попередньої втрати і duplication of messages, або станції типу з FDL status .

1) this value is in last version of the standard not defined anymore but only reserved

Frame Count Bit Frame Count bit FCB (b5) повідомляє про придбання повідомлень або повідомлень або відповідних станцій (відповідь) і будь-якого байдужого за промовчанням (ініціатор). Excluded from this are requests with acknowledgement (SDN) and FDL Status, Ident and LSAP Status requests.

Для захисту sequence, the initiator повинен кар'єри FCB for each responder. Коли Request telegram (Request or Send/Request) is sent to a respond for the first time, or if it is re-sent to a respond The initiator achieves this in a Request telegram with FCV=0 and FCB=1. Залишається велику оцінку на телеграмі цього малюка як перша категорія повідомлень і збереження FCB=1 разом з ініціатором адреси (SA) (see following table). Цей message cycle не буде repeated by the initiator. У subsequent Request telegrams to the same respond, the initiator must set FCV=1 and change the FCB with each new Request telegram. Any responder що receives a Request telegram addressed to it with FCV=1 must evaluate the FCB. Якщо FCB був змінений, коли він пов'язаний з останнім Request telegram від самої ініціативи (same SA), це є valid confirmation, що повторюваний cyclic message був затверджений properly. Якщо Request telegram originates from different initiator (different SA), оцінка FCB is no longer necessary. У разі випадків, учасник повинен забезпечувати FCB з джерелом SA until receipt of new telegram addressed to it. У разі втрати або невтішного розпізнавання або реагування на телеграм, FCB не може бути зміненим у відповідності з цією вимогою: це буде оцінка того, що попереднє повідомлення cycle було faulty. Якщо у вас є відповідь на Request telegram with FCV=1 and the same FCB as the last Request telegram from the same initiator (same SA), це буде зазначено в request retry. Відповідь повинен у turn retransmit the acknowledgement or response telegram held in readiness. Попередньо зазначено затвердження або отримання телеграми з різними адресами (SA або DA), що не з'явиться (Send Data with No Acknowledge, SDN), щоб повідомити про помилку, щоб отримати останній знімок або відповідь телеграми в readiness для будь-якої відповідної реакції . У випадку з Request telegrams, які не знаються і з Request FDL Status, Ident, and LSAP Status, FCV=0 and FCB=0; evaluation by the responder is не longer necessary.

FCBM stored FCB in memory SAM stored SA in memory

Пошук при скануванні файлів відомих типів (або, як часто кажуть, пошук файлів по сигнатурах) є однією з найефективніших, що використовуються в утиліті відновлення даних R-Studio. Використання заданої сигнатури дозволяє відновлювати файли певного типу в тому випадку, коли частково або повністю відсутня (пошкоджена) інформація щодо структури каталогів та імен файлів.

Зазвичай для визначення розташування файлів використовується таблиця розділів диска. Якщо порівняти диск із книгою, то таблиця розділів буде аналогічна до її змісту. При скануванні R-Studio шукає файли відомих типів у таблиці розділів диска за певними заданими сигнатурами. Це стає можливим завдяки тому, що кожен тип файлу має унікальну сигнатуру або шаблон даних. Файлові сигнатури знаходяться в певному місці на початку файлу і в багатьох випадках також і наприкінці файлу. При скануванні R-Studio зіставляє знайдені дані із сигнатурами файлів відомих типів, що дозволяє їх ідентифікувати та відновити дані .

За допомогою технології сканування файлів відомих типів R-Studio дозволяє відновити дані з дисків, які були переформатовані та таблиці розділів яких були перезаписані. Більше того, якщо розділ диска перезаписаний, пошкоджений або видалений, сканування файлів відомих типів є єдиним можливим.

Але практично завжди і в усьому є свої недоліки, і файли відомих типів, що використовуються в R-Studio, є винятком. Так, при скануванні файлів відомих типів R-Studio дозволяє відновити тільки нефрагментовані файли, але, як говорилося, в більшості це останній з можливих методів.

До складу R-Studio вже включені сигнатури найбільш поширених типів файлів (переглянути повний список файлів відомих типів можна в розділі R-Studio Online Довідки.)

У разі потреби користувач може додати нові типи файлів до складу R-Studio. Наприклад, якщо потрібно знайти файли будь-якого унікального типу, або ж розробленого після дати останнього випуску R-Studio, можна додати до складу файлів відомих типів власні сигнатури. Далі буде розглянуто цей процес.

Користувальницькі Файли Відомих Типів
Користувацькі сигнатури файлів відомих типів зберігаються у файлі XML, заданому в діалоговому вікні Налаштування. Додавання сигнатури складається із двох частин:

1. Визначення файлової сигнатури, що знаходиться на початку файлу і за наявності в кінці файлу.
2. Створення файлу 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. Визначимо файлову сигнатуру на початку файла. У нашому прикладі вона знаходиться на самому початку файлу. Зверніть увагу, що так відбувається не завжди - часто файлова сигнатура знаходиться на початку файлу, але не в першому рядку (зміщення).

З наведених нижче зображень випливає, що вміст всіх чотирьох файлів по-різному, але всі вони починаються з однієї і тієї ж файлової сигнатури.


Натисніть на зображення для його збільшення

Натисніть на зображення для його збільшення

Натисніть на зображення для його збільшення

Натисніть на зображення для його збільшення

Виділена область на зображеннях є файловою сигнатурою типу файлів. Вона представлена ​​як у текстовому, так і у шістнадцятковому вигляді.

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=”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 тег буде виглядати так:

Вставимо його відразу після

Далі визначимо файлову сигнатуру (тег ). Початкова сигнатура (на початку файлу), буде перебувати всередині тега без будь-яких атрибутів. Використовуємо текстовий вид сигнатури, але при цьому замінивши шістнадцятковими символами, які не можуть бути представлені в текстовому вигляді. Перед кожним символом шістнадцяти вставимо "\x" Таким чином тег з файловою сигнатурою буде виглядати так:

У разі наявності необхідно також визначити кінцеву сигнатуру (наприкінці файлу). Для цього використовується той самий тег, але з елементом "from" та атрибутом "end". Це буде виглядати так:

Згадайте, що в кінцевій файловій сигнатурі не було нетекстових символів, однак були сліші та трикутні дужки. Щоб уникнути плутанини та помилок у синтаксисі XML, ми замінимо в сигнатурі символи "/", "<" и ">їх шістнадцятковими значеннями.

В кінці після файлових сигнатур обов'язково повинні знаходитися теги FileType і FileTypeList:

Таким чином, весь файл повинен виглядати так:


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

Пам'ятайте: синтаксис 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 = "Тим є just an example"
thread_level = 3
in_the_wild = true
strings:
$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"
condition:
$a або $b або $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 = "win.exe"
$b = "http://foo.com/badfi le1.exe"
$c = "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 = "text here"
$ my_hex_string = ( E2 34 A1 C8 23 FB )

4. У секції condition міститься вся логіка правила. Ця секція повинна містити логічний вираз, який визначає, у якому випадку файл чи процес задовольняє правилу. Зазвичай у цій секції йде звернення до раніше оголошених рядків. А ідентифікатор рядка розглядається як логічна змінна, яка повертає true, якщо рядок був знайдений у файлі або пам'яті процесу, і false в іншому випадку. Вищезазначене правило визначає, що файли та процеси, що містять рядок win.exe та одну з двох URL, мають бути віднесені до категорії BadBoy (на ім'я правила).

5. Шістнадцяткові рядки дозволяють використовувати три конструкції, які роблять їх більш гнучкими: підстановки (wildcards), діапазони (jumps) та альтернативний вибір (alternatives). Підстановки - це місця у рядку, які невідомі, і на їхньому місці може бути будь-яке значення. Позначаються вони символом "?":

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

Такий підхід дуже зручний при заданні рядків, довжина яких відома, а вміст може змінюватися. Якщо частина рядка може бути різної довжини, зручно використовувати діапазони:

$hex_string = ( F4 23 62 B4 )

Цей запис означає, що в середині рядка може бути від 4 до 6 різних байт. Можна реалізувати також альтернативний вибір:

$hex_string = ( 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 = "dummy1"
$foo2 = "dummy2"
$foo3 = "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 = 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 = true

Перший рядок задає ім'я пакувальника, яке відображатиметься в PEiD, а для нас це буде ідентифікатор правила. Друга – безпосередньо сама сигнатура. Третя - прапор ep_only, що вказує, чи шукати цей рядок тільки за адресою точки входу, або ж по всьому файлу.

Ну що спробуємо створити правило, скажімо, для ASPack? Як виявилось, у цьому немає нічого складного. Спочатку створимо файл для зберігання правил та назвемо його, наприклад, packers.yara. Потім шукаємо в базі PEiD усі сигнатури, в назві яких фігурує ASPack, та переносимо їх у правило:

rule ASPack
{
strings:
$ = ( 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 )
condition:
для будь-якого з них: ($ at entrypoint)
}

У всіх знайдених записів прапор ep_only встановлений у true, тобто ці рядки мають розташовуватися на адресу точки входу. Тому ми пишемо таку умову: "for any of them: ($ at entrypoint)".

Таким чином, наявність хоч одного із заданих рядків за адресою точки входу означатиме, що файл упакований ASPack'ом. Зверніть увагу, що в даному правилі всі рядки задані просто за допомогою знака $, без ідентифікатора. Це можливо, тому що в condition-секції ми не звертаємось до якихось конкретних із них, а використовуємо весь набір.

Щоб перевірити працездатність отриманої системи, достатньо виконати у консолі команду:

$ yara -r packers.yara somefi le.exe

Згодувавши туди пару додатків, запакованих ASPack'ом, я переконався, що все працює!

Готовий прототип

YARA виявився надзвичайно зрозумілим і прозорим інструментом. Мені не важко було написати для нього вебадмінку і налагодити роботу як веб-сервіс. Трохи креативу і сухі результати аналізатора вже розфарбовуються різними кольорами, позначаючи ступінь небезпеки знайденого зловреда. Невелике оновлення бази, і для багатьох крипторів доступний короткий опис, а іноді навіть інструкція з розпакування. Прототип створено і працює чудово, а начальство танцює від захоплення!