###
  • Програми
  • Безпека
  • Новини
  • Цікаве
  • Поради
  • Новини
  • Огляди

    • Яку сигнатуру має файл txt. Методи виявлення «склеєних» файлів. Невідомий тип сектору

    07.01.2021 Новини

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

    • Сигнатура даних
    • Виділені унікальні значення, які не повинні збігатися з іншими значеннями (наприклад, 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)); // Правильно, оптимально для статичних масивів

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

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

    Пошук при скануванні файлів відомих типів (або, як часто кажуть, пошук файлів по сигнатурах) є однією з найбільш ефективних , що використовуються в утиліті відновлення даних 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\x18ftypmp42x00x00x00x00mp42x00x00x00x00x00x00x00x08free
    \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 при скануванні шукати файли відомих типів дозволяє відновлювати дані навіть з диска, чиї файлові системи або перезаписані. Ви можете досить ефективно шукати файли, використовуючи їх сигнатури, що особливо корисно в тому випадку, якщо вам точно відомий тип файлів, що відновлюються, як, наприклад, у нашому прикладі. Можливість створити типи файлів користувача дозволяє додати до списку файлів відомих типів будь-який файл, що має певну файлову сигнатуру.

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

    7 6 5 4 3 2 1 0 FC: Function Code Request
    1 Request Telegramm
    X FCV = Alternating bit switched on
    X href="http://profibus.felser.ch/en/funktionscode.htm#aufruffolgebit">FCB = Alternating bit (від frame count)
    1 0 (0x0) CV = Clock Value ()
    1 other Reserved
    0 0 (0x0) TE = Time Event (Clock synchronization)
    0 3 (0x3) SDA_LOW = Send Data Acknowledged - low priority
    0 4 (0x4) SDN_LOW = Send Data Not acknowledged - low priority
    0 5 (0x5) SDA_HIGH = Send Data Acknowledged - high priority
    0 6 (0x6) SDN_HIGH = Send Data Not acknowledged
    0 7 (0x7) MSRD = Send Request Data with Multicast Reply
    0 9 (0x9) Request FDL Status
    0 12(0xC) SRD low = Send and Request Data
    0 13(0xD) SRD High = Send and Request Data
    0 14(0xE) Request Ident with reply
    0 15 (0xF) Request LSAP Status with reply 1)
    0 other Reserved

    1) ця величина є в останній версії стандарту, не визначена аніморе, але лише затверджена

    7 6 5 4 3 2 1 0 FC: Function Code Response
    0 Response telegram
    0 Reserved
    0 0 Slave
    0 1 Master no ready
    1 0 Master ready, без token
    1 1 Master ready, in token ring
    0 (0x0) OK
    1 (0x1) UE = User Error
    2 (0x2) RR = No resources
    3 (0x3) RS = SAP not enabled
    8 (0x8) DL = Data Low (normal case with DP)
    9 (0x9) NR = No response data ready
    10(0xA) DH = Data High (DP diagnosis pending)
    12(0xC) RDL = Data not received and Data Low
    13(0xD) RDH = Data not received and Data High
    other Reserved

    Frame Count Bit Frame count bit FCB (b5) повідомляє про поновлення повідомлень або повідомлень або відповідальних станцій (відповідь) і any loss by calling station (initiator). Виключені з цих функцій без викладання (SDN) і FDL Status, ID і LSAP Status Requests.

    Для захисту sequence, ініціатор повинен працювати на FCB для кожного 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 Request telegram with FCV=0 and FCB=1. Залишити велику оцінку на телеграмі цього малюка, як перший повідомлень акцій і магазин FCB=1 разом з ініціативною адресою (SA) (see following table). Цей message cycle не буде repeated by the initiator. У додаткових Request telegrams до того ж самого відповідача, втікача повинен встановити FCV=1 і змінювати FCB з кожним новим Request telegram. Any responder що receives a Request telegram addressed to it with FCV=1 must evaluate the FCB. Якщо FCB був змінений, коли він пов'язаний з останнім Request telegram від самої ініціативи (Same SA), це є правильним затвердженням, що перехідний ланцюжок cycle був затверджений properly. Якщо Request telegram originates from different initiator (different SA), оцінка FCB не є тривалим. У деяких випадках, responder повинен зберігати FCB з джерелом SA until receipt of new telegram addressed to it. У випадку останнього або невтішного з'ясування або реагування на телеграму, FCB не може бути змінений у бісером в ході запиту: це буде визначено, що напередодні message cycle був faulty. Якщо у відповідь отримувати Request telegram with FCV=1 і сам FCB як останній Request telegram від того самого ініціатора (same SA), це буде повідомити про request retry. Відпочинок повинен у turn retransmit the acknowledgement or response telegram held in readiness. Неможливо описати-конфігурацію або отримання телеграми з різними адресами (SA або DA), що не підтримується (Send Data with No Acknowledge, SDN), щоб відповісти, необхідний останній анонсування або відповідь телеграми в readiness для будь-якого можливого запиту . У випадку, коли Ви використовуєте телеграми, ви не знайдете і з Request FDL Status, ID, LSAP Status, FCV=0 and FCB=0; evaluation by the responder is no longer необхідно.

    b5 b4 Bit position
    FCB FCV Condition Meaning Action
    0 0 DA = 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 = TS First request FCBM:= 1
    SAM:= SA
    Delete last acknowledgement / response
    0/1 1 DA = TS
    SA = SAM
    FCB # FCBM    		 New Request Delete last acknowledgement / response
    FCBM:= FCB
    Hold acknowledgement / response в readiness retry
    0/1 1 DA = TS
    SA = SAM
    FCB = FCBM    		 Retry Request FCBM:= FCB
    Repeat acknowledgement / response and continue to hold in readiness
    0/1 1 DA = TS
    SA # SAM    		 New initiator FCBM:= FCB
    SAM:= SA Hold acknowledgement / response in readiness for retry

    FCBM stored FCB in memory SAM stored SA in memory

    Багато хто міг чути про такі файли, як 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

    Для знаходження відповіді на це питання необхідно заглибитися в специфікації формату, який є «родоначальником» склеєних файлів і зрозуміти його структуру. Будь-який 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.

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

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

    GIF та PDF

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

    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
    Найбільш цікава центральна директорія, яка містить метадані про файли в архіві. Центральна директорія завжди починається з сигнатури 0x50 0x4b 0x01 0x02 і закінчується сигнатурою 0x50 0x4b 0x05 0x06, після яких слідує 18 байт метаданих. Що цікаво, порожні архіви складаються лише з кінцевої сигнатури та 18 нульових байт. Після 18 байт слідує область коментаря до архіву, яка є ідеальним контейнером для приховання файлу.

    Для перевірки 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 (0000001С, порядок байт 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 = 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 = CountFAT + CountMiniFAT + CountDIFAT + CountDE + CountStreams + CountFree

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

    Начальство поставило мені досить цікаве завдання. У стислі терміни написати аналізатор виконуваних файлів, який за сигнатурами умів би знаходити тіла вірусів і визначати використовується пакувальник/криптор. Готовий прототип з'явився вже за кілька годин.

    Слово автора

    Сигнатурний аналіз

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

    Тут є різні методики. Як варіант – використовувати сигнатуру, складену з 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 тисяч зліпків малварі. Однак база 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 і $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 виявився надзвичайно зрозумілим і прозорим інструментом. Мені не важко було написати для нього вебадмінку і налагодити роботу як веб-сервіс. Трохи креативу і сухі результати аналізатора вже розфарбовуються різними кольорами, позначаючи ступінь небезпеки знайденого зловреда. Невелике оновленнябази, і для багатьох крипторів є короткий опис, а іноді навіть інструкція з розпакування. Прототип створений і працює чудово, а начальство танцює від захоплення!