Материал просмотрен 102 раз(а)

Привет! Пришла пора вспомнить такой “бородатый” способ сокрытия информации, как объединение в единый файл картинки и архива. Способу уже не один десяток лет, сейчас он довольно таки позабыт многими, я к примеру, узнал о нём совсем недавно.

Суть метода заключается в том, что создаётся файл из двух форматов, сигнатуры которых особо не конфликтуют друг с другом. Наиболее простой – симбиоз архива RAR и изображения JPEG. В формате JPEG жестко задается размер картинки, выходя за пределы которого файл просто не обрабатывается как графическое изображение. Формату RAR же плевать, где находится его сигнатура. Если где-то в толще файла встречается RAR, то архиватор открывает файл начиная с этого места как архив, и не читает то, что шло до сигнатуры “Rar!”.

Как выглядит RARJPEG

Приведу пример:

Вот та самая картинка

Вот та самая картинка

Сохраните полную версию картинки себе и поменяйте расширение с jpg на rar и откройте при помощи архиватора. Я оставил там документик.

Как сделать RARJPEG

Сделать его очень просто. Для Windows можно воспользоваться командой:

copy /b jpegfile+rarfile rarjpegfile

То есть мы просто копируем оба файла в бинарном виде в один, выходной, причём важен порядок файлов. Сперва идёт картинка, затем архив.

Создаём RARJPEG

Создаём RARJPEG

Для Linux соответственно команда

$ cat jpegfile rarfile > rarjpeg

Строение RARJPEG файла

Ну и давайте поглядим, как структурно выглядит RARJPEG. Для этого откроем файл HEX-редактором. Сперва картинку:

Видим размер картинки 0x15643 байт (в десятичном виде – 87619 байт). А теперь откроем это же смещение в RARJPEG:

Видите, непосредственно со следующих байт пошла сигнатура “Rar!” – я выделил в правой части, то есть непосредственно пошло тело архива. Суммарный файл, разумеется, будет равен по объему сумме двух исходных. А прикрепив куда-нибудь RARJPEG мы можем передать небольшого объёма архив практически незаметно для других.

Почему этот метод сложно распознать?

Дело в том, что многие алгоритмы ищут сигнатуры именно в начале файла. Потому как в нормальных условиях сигнатура там и должна оказаться. Если поиск идёт на диске, то сигнатура должна прийтись как раз на границу кластеров (windows) или блоков (linux), что будет кратным смещению 512 байт в общем случае. Для ускорения процесса многие алгоритмы даже не станут искать в других местах, справедливо пологая, что сигнатура в произвольной толще файла является аномалией, мусором, данными, но уж точно не началом какого-либо файла.

Обнаружить такой способ передачи сообщения можно именно намеренным поиском всей структуры файла на предмет искомой сигнатуры (что-то типа grep), что весьма ресурсоёмко. Такие вот дела! Возьмите на вооружение данный способ, может пригодиться. Кстати, это не единственная связка форматов, который нормально дружат вместе!

Друзья! Вступайте в нашу группу Вконтакте, чтобы не пропустить новые статьи! Также, подписывайтесь на наш канал в YouTube