Склейка вируса с doc
Открываем Microsoft Office Word 2007, копируем подготовленную ранее склейку и вставляем в документ (можно просто перетащить файл мышкой в нужное место документа)
У нас появилось изображение с иконкой от SFX склейки и подписью о названии файла троян.exe
Название конечно можно было заранее переименовать в любое, но вот избавиться от разоблачения расширения "exe" это не помогло бы.Но мы это легко можем обойти
Сохраняем полученный документ, проследив чтобы он сохранился с расширением docx.
Теперь сохранённый документ открываем в винраре (программой WinRAR).Нам откроется следующее:
.
Далее заходим в папку word:
Затем заходим в папку media:
В папке media мы видим файл image1.wmf - это изображение.
Достаём этот файл и смотрим его размеры - в нашем случае размеры 175 X 50 пикселей.
Теперь ищем подходящую картинку соответствующего размера для замены, или рисуем сами.
Сохраняем эту картинку под названием image1, если не можете сохранить с расширением wmf, можете сохранить с расширением jpg
Если вам удалось сохранить изображение в формате wmf, то можете сразу заменить им стандартное, просто перетащив его мышкой в открытое окно винрара. Если вы сохранили изображение в формате jpg, то вам необходимо сменить расширение изображения на wmf
Изменить расширение можно при помощи Total Commander, или WinRAR.
В итоге у нас получилось следующее:
При клике по изображению запустится наша склейка и установится троян.
Изначально для внедрения в документ, склейку трояна в данном варианте, делать желательно с картинкой, чтобы на самом деле открылось аналогичное изображение, только большего размера. Вместо надписи "Теперь при клике по изображению снизу, запустится наш троян" естественно нужно написать что то другое. К примеру вы можете создать нечто вроде каталога товаров, с маленькими изображениями товаров, при клике на которые открывается более крупное изображение.
Из недостатков описанного метода склейки трояна с документом, следует отметить:
- Необходимо кликнуть в документе по изображению/ссылке для запуска трояна.
- Возможно при клике по изображению выскочит окно безопасности с вопросом "Запускать или не запускать файл".
В комментарии ниже к этой статье была информация о том,как избавится от окошка с предупреждением системы безопасности.
Часто при попытке запустить файлы, скачанные из интернета, появляется примерно такое окно:
Как Windows определяет, что файл был загружен из Интернета
Зато альтернативные потоки NTFS можно легко посмотреть в консоли обычной командой DIR с ключом /R
Просмотр альтернативных потоков NTFS при помощи команды DIR
Можно воспользоваться консольной утилитой Streams от Mark Russinovich.
Просмотр альтернативных потоков NTFS при помощи программы Streams
Для любителей оконных интерфейсов есть замечательная программа NTFS Stream Explorer, которая тоже позволяет обнаружить и посмотреть альтернативные потоки NTFS.
Просмотр альтернативных потоков NTFS при помощи NTFS Stream Explorer
Или бесплатная утилита AlternateStreamView от NirSoft.
Просмотр альтернативных потоков NTFS при помощи программы AlternateStreamView
Что же интересного записано в этом файле, а главное, как его открыть? Проще всего это делается при помощи обычного Блокнота, который входит в состав каждой Windows. Набираем в командной строке следующее:
notepad C:\setup.exe:Zone.Identifier
В Блокноте открывается содержимое альтернативного потока Zone.Identifier. Да, это самый обычный текстовый (а точнее ini) файл:
Содержимое альтернативного потока NTFS
Параметр ZoneId=3 отвечает именно за то, чтобы файл считался небезопасным, и на основании именно этого значения система принимает решение о показе предупреждения.
Хорошо, наличие спрятанного альтернативного потока мы определили, его содержимое посмотрели. А дальше-то что? А дальше можно разблокировать основной файл путем удаления альтернативного потока.
Удаление альтернативного потока через программу Streams
Удаление альтернативного потока программой NTFS Stream Explorer
Удаление альтернативного потока программой AlternateStreamView
Альтернативный поток NTFS также удаляется при разблокировке файла через меню Проводника Windows. После удаления потока файл запускается без каких-либо предупреждений.
Можно ли заблокировать файл обратно? Да, можно. Для этого, как несложно догадаться, надо создать альтернативный поток Zone.Identifier с нужным содержимым. Делается это при помощи все того же Блокнота уже знакомой нам командой:
notepad C:\setup.exe:Zone.Identifier
На запрос о создании нового файла надо ответить подтверждением.
Создание альтернативного потока NTFS вручную
Осталось записать в созданный файл потока строчки, отвечающие за блокировку основного файла, и сохранить изменения.
[ZoneTransfer]
ZoneId=3
После этого файл снова становится небезопасным со всеми вытекающими последствиями. Путем несложных экспериментов я также выяснил, что значение ZoneId=4 при попытке запустить файл приводит вот к такому интересному эффекту:
Файл полностью заблокирован
То есть файл становится полностью блокированным для запуска. Пусть ваша фантазия подскажет вам, где это можно использовать.
Напоследок хочу предупредить вас, что неразумное создание или удаление альтернативных потоков может привести к непредсказуемым последствиям, вплоть до сбоев в работе системы. Как и при работе с любыми другими внутренностями Windows, надо быть очень осторожным
Небольшой гиф-обзор инструкции (от меня)
В хакерской практике достаточно часто возникает потребность
внедрить в готовый exe-файл свой код (необязательно вредоносный) так, чтобы он получал управление первым, не вызывал ругательств со стороны антивирусов и вообще по возможности вел себя максимально скрытно, не бросаясь в глаза. Как это сделать? Мы знаем, как, и сейчас обстоятельно тебе это объясним.
Правильные хакеры так себя не ведут и склеивают программы самостоятельно. И это совсем нетрудно! Нужны лишь верный друг hiew и минимальные навыки программирования на Си. Но прежде чем брать быка за рога, сделаем одно важное уточнение. Внедряемый код не обязательно должен быть вирусом, червем, руткитом или любой другой вредоносной заразой, поэтому, во избежание недоразумений, условимся называть его X-кодом.
Как мы будем действовать
Всякий exe-файл импортирует одну или несколько динамических библиотек (Dynamic Link Library, или сокращенно DLL), прописанных в таблице импорта. При запуске exe-файла системный загрузчик анализирует таблицу импорта, загружает все перечисленные в ней динамические библиотеки, вызывая функцию DllMain для инициализации каждой DLL, и только после этого передает управление на оригинальную точку входа (Original Entry Point, или сокращенно OEP) запускаемого exe-файла.
Подготовка к экспериментам
$inject.exe
I'm nezumi
Берем в свои загребущие лапы hiew, открываем файл inject.exe, переходим в hex-режим по , давим для отображения PE-заголовка, нажимаем (Dir) и среди прочих элементов IMAGE_DATA_DIRECTORY выбираем секцию импорта (Import), расположенную в нашем случае по RVA-адресу, равному 5484h и раскинувшуюся в ширину на целых 28h байт (смотри рисунок 1).
Клавиша переносит нас к структуре Import Directory Table, о которой мы поговорим чуть позже. А пока обсудим, как найти указатель на Import Directory Table при отсутствии hiew'а.
Двойное слово, лежащее по смещению 80h от начала PE-заголовка (легко опознаваемого визуально по сигнатуре PE), и есть RVA-адрес, указывающий на Import Directory Table, а следующее двойное слово хранит ее размер. Так что для поиска таблицы
импорта hiew совсем необязателен.
Таблица импорта представляет собой достаточно сложное сооружение иерархического типа. Вершину иерархии занимает структура Import Directory Table, фактически являющаяся массивом подчиненных структур типа IMAGE_IMPORT_DESCRIPTOR, каждая из которых содержит RVA-указатель на имя загружаемой динамической библиотеки, ссылки на OriginalFirstThunk и FirstThunk с именами/ординалами импортируемых функций (причем поле OriginalFirstThunk не является обязательным и может быть равно нулю). Два других поля — TimeDateStamp (временная отметка) и ForwarderChain (форвардинг) - также необязательны, и потому для подключения своей собственной DLL нам необходимо заполнить всего лишь два поля структуры IMAGE_IMPORT_DESCRIPTOR: Name и FirstThunk, а также создать таблицу Import Address Table (сокращено IAT), импортирующую по меньшей мере одно имя (в данном случае
dummy).
Если вместо стройной иерархии структур в нашей голове образовалась каша, не стоит волноваться — это нормально! Постепенно она утрясется и все структуры встанут на свои места, так что оставим их дозревать, а сами сосредоточимся на текущих проблемах. Чтобы внедрить X-DLL в Import Directory Table, необходимо добавить еще один экземпляр структуры IMAGE_IMPORT_DESCRIPTOR. Но просто так сделать это не получится, поскольку сразу же за концом Import Directory Table начинается IAT первой динамической библиотеки, и нам просто некуда втиснуться, если, конечно, не перенести Import Directory Table в какое-нибудь другое место! А что?! И перенесем!
Теперь, прокручивая файл, клацаем
до тех пор, пока не выйдем на оперативный простор свободного места, оккупированного длинной вереницей нулей. В нашем случае это место располагается по адресу 405810h, непосредственно за концом таблицы импорта.
Далее нам необходимо скопировать оригинальную Import Directory Table на новое место, не забыв при этом зарезервировать место для одного элемента структуры типа IMAGE_IMPORT_DESCRIPTOR, в который мы чуть позже поместим нашу динамическую библиотеку. Она будет проинициализирована самой первой, что очень полезно для борьбы с антивирусами, иммунизирующими exe-файлы путем прививки им специальной dll-вакцины, выполняющей проверку целостности содержимого образа исполняемого файла.
Поскольку, как нетрудно подсчитать, размер структуры IMAGE_IMPORT_DESCRIPTOR составляет 14h байт, а незанятая область начинается с адреса 405810h, мы должны передвинуть курсор по адресу 405824h, нажать , выделить 28h байт (размер оригинальной Import Directory Table) и нажать еще раз, а потом обязательно переместить курсор в начало выделенного блока. Далее жмем (Get Block), вводим имя файла, в который мы только что сохранили блок, - idt-org и считываем его с диска.
Теперь возвращаемся в начало файла и корректируем RVA-адрес таблицы импорта, который в данном случае составит 5824h. У тебя может возникнуть вопрос: почему 5824h, а не 405824h?! Да потому что RVA-адреса получаются путем вычитания базового адреса (прописанного в заголовке PE-файла и в нашем случае равного 400000h) из виртуального адреса (равного 405824h). Причем, с учетом порядка старшинства байт, принятого на процессорах x86 (младшие биты располагаются по меньшим адресам), мы должны записать 24 58, а не 58 24, как делают многие начинающие хакеры, удивляясь потом, почему оно не работает.
Значит, открываем файл inject.exe в hiew'e, находим PE-сигнатуру, опускаем курсор вниз на 80h байт, видим там 84 54 (смотри рисунок 1), нажимаем для разрешения редактирования, меняем адрес на 24 58, сохраняем изменения по и выходим… за пивом. Пиво для хакеров — это святое!
Проверяем работоспособность файла — а вдруг она пострадала?! Запускаем inject.exe и (если все операции были проделаны правильно) на экране появится триумфальное приветствие. В противном же случае система откажется загружать файл или выбросит исключение.
Смочив пересохшее горло, приступаем к самой сложной и самой ответственной части — заполнению структуры IMAGE_IMPORT_DESCRIPTOR. Начнем с того, что переместим курсор в конец Import Directory Table, подогнав его к адресу 405850h, и запишем имя функции-пустышки (dummy), оканчивающееся нулем и предваренное двумя нулями, а следом за ним – имя внедряемой динамической библиотеки injected_dll.dll. Впрочем, порядок их расположения может быть и другим, системному загрузчику на такие мелочи уже давно положить.
Сделав это, перемещаемся на первый байт, ранее зарезервированный нами для структуры IMAGE_IMPORT_DESCRIPTOR, и начинаем колдовать. Первое двойное слово оставляем равным нулю. За ним идут 4 байта, отведенные для TimeDataStamp, и мы, желая слегка поизвращаться, занесем сюда IAT, то есть двойное слово, содержащее RVA-адрес импортируемой функции. В нашем случае эта функция зовется dummy, а ее имя (предваренное двумя нулями!) начинается с RVA-адреса 5850h. Учитывая обратный порядок байт на x86, пишем: 50 58. Пропустив следующее двойное слово (Forwarder Chain), в поле Name записываем RVA-адрес имени внедряемой динамической библиотеки injected_dll.dll, в нашем случае равный 5858h. Остается заполнить последнее поле — Import Address Table, содержащее RVA-адрес таблицы IAT, размещенной нами поверх поля TimeDateStamp с RVA-адресом, равным 5814h.
Вот, собственно говоря, и все… После добавления новой структуры IMAGE_IMPORT_DESCRIPTOR в массив Import Directory Table, последний будет выглядеть так:
Остается сущая мелочь. Надо вернуться в начало файла, отсчитать от PE-заголовка 80h байт, исправив указатель на таблицу импорта с 5824h на 5810h и увеличив ее размер до 3Сh. Сохраняем проделанные изменения и, набрав побольше воздуха в грудь, запускаем файл
inject.exe:
$inject.exe
hello,world!
I'm nezumi
good-bye,world!
Копирование X-DLL в NTFS-stream
Теперь запускаем файл inject.exe и убеждаемся, что его работоспособность в результате последних манипуляций ничуть не пострадала.
Переход от теории к практике
Внедрение своей собственной динамической библиотеки - это, конечно, очень хорошо, но на практике гораздо чаще приходится сталкиваться с тем, что требуется
внедрить чужой исполняемый файл. Что делать?! Преобразовывать его в DLL?! Конечно же нет! Достаточно просто слегка доработать нашу X-DLL, научив ее запускать exe-файлы посредством API-функции CreateFile, при этом сами исполняемые файлы можно (и нужно) поместить в именованные NTFS-потоки, число которых фактически неограниченно. Причем, если внедряемый exe тащит за собой динамические библиотеки или другие компоненты, они также могут быть внедрены в NTFS-потоки (естественно, в текущем каталоге их уже не окажется, и потому исполняемый файл придется подвергнуть правке на предмет изменения всех путей). Если же этот файл упакован (а большинство боевых утилит типа систем удаленного администрирования редко поставляются в открытом виде), наша X-DLL может перехватить API-функции CreateFile/LoadLibrary, автоматически отслеживая обращения к отсутствующим файлам и подсовывая вместо них соответствующие им именованные NTFS-потоки.
Другой немаловажный момент. Отправляя exe-файл с внедренной в него X-DLL по почте, записывая его на лазерный диск или любой другой не-NTFS-носитель, мы теряем все именованные потоки, и программа тут же отказывает в работе, ругаясь на то, что не может найти dll.
Повторяем процедуру пересылки файла по электронной почте еще раз, распаковываем полученный архив, запускаем inject.exe, и… о чудо! Он работает!
Заметай за собой следы (для грамотных парней)
Некоторые файлы (особенно упакованные протекторами) скрупулезно следят за своей целостностью и на попытку внедрения реагируют, прямо скажем, не совсем адекватно. Однако поскольку X-DLL получает управление вперед остальных, она может восстановить таблицу импорта в памяти, как будто все так и было, словно к ней никто и не прикасался. Для этого достаточно вызывать API-функцию
VirtualProtect, присвоив соответствующим регионами памяти атрибут
PAGE_READWRITE, восстановить таблицу импорта (оригинал которой легко сохранить в
X-DLL), а затем заново установить атрибут PAGE_READONLY с помощью все той же
VirtualProtect. Более того, X-DLL может выделить блок памяти из кучи с помощью API-функции VirtualAlloc и скопировать туда свое тело, которое, естественно, должно быть полностью перемещаемо, то есть сохранять работоспособность независимо от базового адреса загрузки. Далее остается только выгрузить ставшую ненужной X-DLL вызовом FreeLibrary (на тот случай, если какой-то хитрый механизм проверки целостности решит перечислить список загруженных модулей).
Маленький технический нюанс: на процессорах с поддержкой битов
NX/XD, запрещающий исполнение кода в страницах памяти, не имеющих соответствующих атрибутов, выделяемому блоку памяти следует присвоить атрибут
PAGE_EXECUTE_READWRITE. В противном случае, если у пользователя задействован аппаратный DEP для всех приложений (а не только для системных компонентов, как это происходит по умолчанию), вместо выполнения машинного кода система выбросит исключение, и выполнение троянизированной программы завершится в аварийном режиме.
В заголовке PE-файла имеется специальное поле, содержащее контрольную сумму. В подавляющем большинстве случаев оно равно нулю, но если это не так, то после вмешательства в таблицу импорта контрольную сумму необходимо пересчитать. Этим занимается утилита
EDITBIT.EXE, запущенная с ключом ‘/RELEASE’. Она входит как в штатную поставку компилятора Microsoft Visual
Studio, так и в Platform SDK, так что проблем с ее поиском возникнуть не должно.
Заключение
Технологии внедрения в исполняемые файлы не стоят на месте и развиваются вместе с защитными механизмами и операционными системами. Извечная проблема меча и щита — кто усовершенствуется первым. Использование готовых утилит, работающих в полностью автоматическом режиме, во-первых, непрестижно, а во-вторых, слишком ненадежно. Разработчики антивирусов даром свой хлеб не едят! Чтобы не погореть на мелочах, весь X-код следует писать самостоятельно. До тех пор пока он существует в единственном экземпляре, у защитных систем не остается никакого шанса предотвратить атаку!
Полную версию статьи
читай в майском номере
Хакера! Кроме того, в видеоинструкции на диске мы наглядно показываем, как
надо склеивать файлы. Рекомендую посмотреть видео сразу после прочтения статьи, чтобы разрешить все возникшие вопросы.
И конечно: на диске тебя ждут все упомянутые инструменты, примеры, компилятор Си для сборки приведенного кода, а также подборка
готовых джойнеров.
Многие могли слышать о таких файлах, как rarjpeg'и. Это особый вид файлов, представляющий собой склеенную вплотную jpeg-картинку и rar-архив. Он является прекрасным контейнером для скрытия факта передачи информации. Создать rarjpeg можно с помощью следующих команд:
UNIX: cat image1.jpg archive.rar > 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, представляющий собой контейнер с собственной файловой системой. Этот метод основан на обнаружении аномалий в файле.
Есть ли жизнь после конца файла?
После этой сигнатуры находится служебная информация, опционально иконка изображения и, наконец, само сжатое изображение. В этом формате конец изображения отмечается двухбайтной сигнатурой 0xFF 0xD9.
Первые восемь байт PNG-файла занимает следующая сигнатура: 0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A. Сигнатура конца, которая заканчивает поток данных: 0x49, 0x45, 0x4E, 0x44, 0xAE, 0x42, 0x60, 0x82.
Общая сигнатура для всех rar-архивов: 0x52 0x61 0x72 0x21 (Rar!). После неё идет информация о версии архива и прочие сопутствующие данные. Опытным путем было установлено, что архив заканчивается сигнатурой 0x0A, 0x25, 0x25, 0x45, 0x4F, 0x46.
Таблица форматов и их сигнатур:
| Формат | Начальная сигнатура | Конечная сигнатура |
|---|---|---|
| JPEG | 0xFF 0xD8 | 0xFF 0xD9 |
| PNG | 0x89 0x50 0x4E 0x47 0x0D 0x0A 0x1A 0x0A | 0x49 0x45 0x4E 0x44 0xAE 0x42 0x60 0x82 |
| RAR | 0x52 0x61 0x72 0x21 | 0x0A 0x25 0x25 0x45 0x4F 0x46 |
- Найти начальную сигнатуру;
- Найти конечную сигнатуру;
- Если после конечной сигнатуры нет данных — ваш файл чист и не содержит вложений! В ином случае необходимо искать после конечной сигнатуры другие форматы.
| Формат | Начальная сигнатура | Конечная сигнатура |
|---|---|---|
| GIF | 0x47 0x49 0x46 0x38 | 0x00 0x3B |
| 0x25 0x50 0x44 0x46 | 0x0A 0x25 0x25 0x45 0x4F 0x46 |
- Пункт 1 повторяется из предыдущего алгоритма.
- Пункт 2 повторяется из предыдущего алгоритма.
- При нахождении конечной сигнатуры запомнить её расположение и искать дальше;
- Если таким образом дошли до последнего EOF-маркера — файл чист.
- Если файл не заканчивается конечной сигнатурой — goto место последней найденной конечной сигнатуры.
Большая разница между размером файла и позицией после последней конечной сигнатуры указывает на наличие приклеенного вложения. Разница может составлять больше десяти байт, хотя возможна установка иных значений.
Особенность ZIP-архивов заключается в наличие трех различных сигнатур:
| Сигнатуры | Описание |
|---|---|
| 0x50 0x4B 0x03 0x04 | Сигнатура обычного архива |
| 0x50 0x4B 0x05 0x06 | Сигнатура пустого архива |
| 0x50 0x4B 0x07 0x08 | Сигнатура архива, разделенного на части |
| 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-файла следующая: каждый файл начинается с сигнатуры RIFF (0x52 0x49 0x46 0x46). На 8 байте идет уточняющая формат сигнатура AVI (0x41 0x56 0x49 0x20). Блок на смещении 4, состоящий из 4 байт, содержит начальный размер блока данных (порядок байт — little endian). Чтобы узнать номер блока, содержащего следующий размер, необходимо сложить размер заголовка (8 байт) и размер, полученный в блоке 4-8 байт. Таким образом вычисляется полный размер файла. Допускается, что вычисленный размер может быть меньше, чем реальный размер файла. После вычисленного размера файл будет содержать только нулевые байты (необходимо для выравнивания границы в 1 Кб).
Пример вычисления размера:
| Смещение | Размер | Следующее смещение |
|---|---|---|
| 4 | 31442 | 8+31442=31450 |
Как и AVI, WAV-файл начинается с сигнатуры RIFF, однако, у этого файла сигнатура с 8 байта — WAVE (0x57 0x41 0x56 0x45). Размер файла вычисляется таким же образом, как и AVI. Реальный размер должен полностью совпадать с вычисленным.
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). Чтобы найти следующий размер блока, необходимо складывать размеры найденных предыдущих блоков. Таким образом, вычисляется размер файла:
| Смещение | Значение | Следующее смещение |
|---|---|---|
| 0 | 28 | 28+0=28 |
| 28 | 8 | 28+8=36 |
| 36 | 303739 | 36+303739=303775 |
| 303775 | 6202 | 303775+6202=309977 |
Этот широко используемый формат является также контейнером MPEG-4. MOV использует проприетарный алгоритм сжатия данных, имеет похожую на MP4 структуру и используется в тех же целях — для хранения аудио и видеоданных, а также сопутствующих материалов.
Как и MP4, любой mov-файл имеет на 4 смещении 4-х байтную сигнатуру ftyp, однако, следующая сигнатура имеет значение qt__ (71 74 20 20). Правило вычисления размера файла не изменилось: начиная с начала файла вычисляем размер следующего блока и складываем.
Проверяем Compound File Binary Format
Этот формат файла, разработанный в Microsoft, также известен под названием OLE (Object Linking and Embedding) или COM (Component Object Model). Файлы DOC, XLS, PPT принадлежат к группе CFB-форматов.
Предположим, что злоумышленник модифицировал некий doc-файл и вклеил в его конец другой файл. Есть несколько различных способов его обнаружить или указать на аномалию в документе.
Как было сказано выше, любой CFB-файл состоит из заголовка и секторов равной длины. Чтобы узнать размер сектора, необходимо считать двухбайтное число на 30 смещении от начала файла и возвести 2 в степень этого числа. Данное число должно быть равно или 9 (0x0009), или 12 (0x000C), соответственно, размер сектора файла равен 512 или 4096 байт. После нахождения сектора необходимо проверить следующее равенство:
(FileSize — 512) mod SectorSize = 0
Если это равенство не выполняется, то можно указать на факт склейки файлов. Однако этот метод имеет существенный недостаток. Если злоумышленник знает размер сектора, то ему достаточно приклеить свой файл и ещё n байт, чтобы величина приклеенных данных была кратна размеру сектора.
Если злоумышленник знает о методе обхода предыдущей проверки, то данный метод может детектировать наличие секторов с неопределенными типами.
FileSize = 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 = CountFAT + CountMiniFAT + CountDIFAT + CountDE + CountStreams + CountFree
Очевидно, что при неравенстве CountClassified и CountReal можно сделать вывод о возможной склейке файлов.
Читайте также: