Комментарии 38
Эх чуть бы пораньше. Буквально пару дней назад искал такую информацию, чтобы объяснить подобное на пальцах.
Но все равно спасибо!
Но все равно спасибо!
В jpeg далеко не всегда файл заканчивается 0xFF 0xD9. Можете снести их и файл откроется в большинстве смотрелок. Этим грешат некоторые мобилки.
Ценное замечание. Однако сделан расчет на то, что злоумышленник не будет каким-либо образом модифицировать файл исходного формата, кроме как приклеивать вложение. Если же конечная сигнатура была удалена, то можно попробовать найти вложение простым сигнатурным поиском по файлу.
А не будет ли наоборот, ложных срабатываний, потому что маркер FF D9 просто статистически встретится внутри huffman-потока? Я взял несколько больших jpeg и пару раз нашёл FF D9 в середине файла
Если FF D9 встречается несколько раз, то можно проверять jpeg по принципу pdf и gif, где их "конечные" сигнатуры могут повторяться. Даже если будет не последний FF D9 будет найден, то после него область файла будет проверяться поиском сигнатур, длина которых от 4 байт и выше. Вероятность ЛПС в таком случае крайне невысокая.
Что делать если «злоумышленник» приклеит «нагрузку» к обычному файлу TXT, который по определению не имеет заранее заданного формата?
Просматривать всё содержимое таких файлов, независимо от размера, на предмет поиска известных сигнатур и пытаться выделить файлы по сигнатурам для подтверждения гипотезы?
Просматривать всё содержимое таких файлов, независимо от размера, на предмет поиска известных сигнатур и пытаться выделить файлы по сигнатурам для подтверждения гипотезы?
В кодировку чего?
txt может быть и в UTF и в ANSI и в др.кодировке кодировке.
txt может быть и в UTF и в ANSI и в др.кодировке кодировке.
Ок. В случае, если Вы знаете или можете определить в какой кодировке у Вас файл. Более того, в качестве гипотезы, вполне вероятно, что существует сочетания, которых нет ни в одной распространенной кодировке.
Если при парсинге в мультибитовую кодировку в массиве символов оказываются 0х00-0x1F, исключая 0x0D и 0x0A, это скорее всего бинарник. При этом проверять имеет смысл всего три — UTF8LE, UTF8BE, UTF16 (она ЕМНИП только LE).
А если это win1251 или koi8-r окажется?
А разве в них как в массиве байт в нормальном виде есть 0х00-0x1F, исключая 0x0D и 0x0A? Другое дело, если этот текстовик будет на каком-нибудь 05AB1E, где уже вполне могут попадаться символы из этого диапазона. Однако процент текстовых файлов на всяких экзотических ЯП вроде этого позволяет им пренебречь при анализе потенциально склеенных файлов.
С точки зрения борьбы с zip-бомбой такие проверки подойдут, но есть более изящные средства. С точки зрения поиска стеганографических весселов, существует много способов сокрытия, и создать графический файл содержащий в себе, скажем, архив и проходящей проверки на структуру вполне возможно.
Однако, для хранения, изображения и видео всё равно надо перекодировать, при определённых настройках, любая сокрытая информация будет потеряна.
Предположим, что злоумышленник модифицировал некий doc-файл и вклеил в его конец другой файлРазумнее класть новый файл сразу в файловую систему Compound. Или даже не в новый файл, а по принципу rarjpeg в один из объектов контейнера.
Это интересно, но мой стеганограф написанный еще в лохматом году на бейсике не возьмет.
Не кидайте кирпичи, я не критикую статью, сам такие методы поиска не знал, просто дополняю что есть способы спрятать и по лучше.
На мой взгляд такой вид сокрытия даты слишком наивен.
Я складывал в младшие значащие биты png (визуально незаметно, к тому же если это фото там есть естественный шум матрицы) к слову сказать спрятать дату можно абсолютно в любой медийный формат допускающий субъективно незаметные огрехи.
Для jpeg'а только пришлось бы внедриться в формат кодирования. Найти в нем парные взаимоисключающие условия и на стадии кодирования подменять их в обход правильного кодирования (только в местах мало влияющих на визуальный результат) своим выбором
И в jpeg конечно можно внедрить значительно меньше даты без видимых артефактов
Я видал стеганографф даже для mp3
В простейшем случае для mp3 берется малораспространенный ABR (Avarage Bit Rate) — его суть в том, что он берет для фрейма строго заданный размер. (И чем же это отличается от CBR спросите вы) Дело в том, что он продолжает пытаться сжать сильнее (например тишину), и оставшееся место накапливает, для расширения следующих фреймов. (Само собой это означало бы невозможность реалтаймового кодирования с трансляцией, ведь данные для будущих фреймов должны были бы содержаться в уже переданных) Но еще он ограничивает возможность подключать оставшееся место дальше чем условно на время t. Таким образом он все таки может передаваться почти реалтаймово, с «пингом» воспроизведения в несколько секунд. (Естественно это юзалось в основном при потоковом прослушивании напрмер радиостанций, но не колл-войса)
Так вот, в связи с тем, что периодически этот формат теряет «запасы» слишком далеких полупустых фреймов, туда можно свободно записать что угодно.
Хотя даже этот метод с mp3 ближе к вашему описанию, и послабее защищен чем кодирование «со специальными ошибками» (естественно и для классического cbr/vbr можно реализовать мудреный алг «ошибочного кодирования», но это потребует разбираться в формате досконально)
Не кидайте кирпичи, я не критикую статью, сам такие методы поиска не знал, просто дополняю что есть способы спрятать и по лучше.
На мой взгляд такой вид сокрытия даты слишком наивен.
Я складывал в младшие значащие биты png (визуально незаметно, к тому же если это фото там есть естественный шум матрицы) к слову сказать спрятать дату можно абсолютно в любой медийный формат допускающий субъективно незаметные огрехи.
Для jpeg'а только пришлось бы внедриться в формат кодирования. Найти в нем парные взаимоисключающие условия и на стадии кодирования подменять их в обход правильного кодирования (только в местах мало влияющих на визуальный результат) своим выбором
И в jpeg конечно можно внедрить значительно меньше даты без видимых артефактов
Я видал стеганографф даже для mp3
В простейшем случае для mp3 берется малораспространенный ABR (Avarage Bit Rate) — его суть в том, что он берет для фрейма строго заданный размер. (И чем же это отличается от CBR спросите вы) Дело в том, что он продолжает пытаться сжать сильнее (например тишину), и оставшееся место накапливает, для расширения следующих фреймов. (Само собой это означало бы невозможность реалтаймового кодирования с трансляцией, ведь данные для будущих фреймов должны были бы содержаться в уже переданных) Но еще он ограничивает возможность подключать оставшееся место дальше чем условно на время t. Таким образом он все таки может передаваться почти реалтаймово, с «пингом» воспроизведения в несколько секунд. (Естественно это юзалось в основном при потоковом прослушивании напрмер радиостанций, но не колл-войса)
Так вот, в связи с тем, что периодически этот формат теряет «запасы» слишком далеких полупустых фреймов, туда можно свободно записать что угодно.
Хотя даже этот метод с mp3 ближе к вашему описанию, и послабее защищен чем кодирование «со специальными ошибками» (естественно и для классического cbr/vbr можно реализовать мудреный алг «ошибочного кодирования», но это потребует разбираться в формате досконально)
Речь идёт не о полноценной стеганографии, а исключительно о составных файлах.
Благодарю за дополнение, однако, те методы, что вы описали, не совсем подходят под тематику статьи, поскольку в них происходит внедрение в структуру файла, а не склейка, как я уже писал выше. Также, как я понял, это методы скрытия информации, а не обнаружения.
Приложу ссылочку на ещё одну интересную методику сокрытия информации:
http://old.computerra.ru/gid/rtfm/office/327832/
Было бы очень интересно услышать комментарии авторов на эту тему.
http://old.computerra.ru/gid/rtfm/office/327832/
Было бы очень интересно услышать комментарии авторов на эту тему.
Склеивание файлов
Возможно ссылка не совсем точная. Но суть в том, что используя особенности контейнера можно сделать файл, котрый будет _одновременно_ и word и excel и при открытии соответствующей программой будет работать и так и так. Но по расширению то это один файл! и сложно догадаться проверить например word на предмет возможности открытия его как excel.
Было бы очень интересно услышать комментарии авторов на эту тему.
Возможно ссылка не совсем точная. Но суть в том, что используя особенности контейнера можно сделать файл, котрый будет _одновременно_ и word и excel и при открытии соответствующей программой будет работать и так и так. Но по расширению то это один файл! и сложно догадаться проверить например word на предмет возможности открытия его как excel.
Было бы очень интересно услышать комментарии авторов на эту тему.
В материале по данной ссылке не описана подробная методика сокрытия doc файла в xls, а скорее гайд, как пользоваться готовой программой, принцип работы которой не раскрывается.
Формат CFB позволяет внедрить в его внутреннюю файловую систему «нагрузку». Лет 6 назад проверял, запихифая из плагина для фар в doc файл и .zip и .exe. Word при открытии «нагруженных» документов молчал, никак не замечая нагрузку.
Многие комментаторы выше не до конца понимают в чём же ценность jpegrar. Если его открыть в графической приблуде, то видно JPEG, а если в архиваторе — то он распаковывается как RAR-архив. Причём безо всяких манипуляций.
Поддерживаю, и из описанного в статье получилось бы хорошее расширение для файлового менеджера. Я часто делаю, например, PNG{SVG}, но не всегда хочется добавлять на изображение метку ![un[7z]me](https://habrastorage.org/webt/jb/dr/dp/jbdrdpf0zozugszofy1owgrpweu.png#un7zipMe.png "Попробуй распаковать меня ;-)")
, которую к тому же не видно на маленьком эскизе в менеджере файлов. А так метку мог бы ставить сам менеджер.
Tsyganov_M: И почему "злоумышленник":
А для ".doc" можно сохранить исходный «TeX».
, которую к тому же не видно на маленьком эскизе в менеджере файлов. А так метку мог бы ставить сам менеджер.Tsyganov_M: И почему "злоумышленник":
Предположим, что злоумышленник модифицировал, я например, использую для сохранения исходных данных для картинки: исходные данные диаграммы, векторное изображение,…
А для ".doc" можно сохранить исходный «TeX».
Предположим некто Джим в какой-то социалке разместил фото красивейшего заката на каких-нибудь островах в океане. Также представим, что некоему Джону это фото ну очень понравилась и он репостнул его у себя в ленте.
Вдруг выясняется, что внутри этого фото с помощью стеганографии скрыто еще одно, например с детским порно.
Вопрос:
Можно ли в этом случае предъявить Джиму и Джону обвинения в распространении детского порно, при условии, что они оба настаивают на том, что не знали о том, что внутри фото с закатом было еще что-то?
Вдруг выясняется, что внутри этого фото с помощью стеганографии скрыто еще одно, например с детским порно.
Вопрос:
Можно ли в этом случае предъявить Джиму и Джону обвинения в распространении детского порно, при условии, что они оба настаивают на том, что не знали о том, что внутри фото с закатом было еще что-то?
Тут вопрос, кто предоставляет ключи дешифровки.
С помощью алгоритма «одноразовый блокнот» можно любой заказ расшифровать с любое порно, всё зависит от ключей.
С помощью алгоритма «одноразовый блокнот» можно любой заказ расшифровать с любое порно, всё зависит от ключей.
Предположим, что ключи и алгоритмы декодирования были обнаружены при обыске у некоего Джека на древней, но рабочей флешке. По его показаниям — он случайно нашел ее более трех лет назад в очень людном месте. А эту и возможно другие скрытые фото обнаружил, когда в свободное время развлекался тем, что проверял все доступные ему изображения с помощью найденного софта.
Ключевой момент «Вдруг выясняется».
Кто эту информацию опубликовал, тот и виноват.
Лежала эта фотография заката в соцсети, никому не мешала. А если некий Боб написал под ней, что с ключом xxxyyyyzzz это расшифровывается в порно, то его коммент — преступление.
Кто эту информацию опубликовал, тот и виноват.
Лежала эта фотография заката в соцсети, никому не мешала. А если некий Боб написал под ней, что с ключом xxxyyyyzzz это расшифровывается в порно, то его коммент — преступление.
Никто под фото ничего не писал и в другом месте не публиковал — т.к. в этом случае вина разместившего эту инфу будет очевидна и вы это верно описали выше.
Правоохранителям случайно во время «общения» с Джеком стало известно, что у некоторых фото в сети есть, скажем так, нелегальные вложения.
Вопросы остаются:
1. Вправе ли они обвинять в чем-то Джима и Джона?
2. Вправе ли они требовать удаления этих фото у Джима и Джона?
это вопросы не к вам конкретно — просто интересно ваше мнение и других людей.
Правоохранителям случайно во время «общения» с Джеком стало известно, что у некоторых фото в сети есть, скажем так, нелегальные вложения.
Вопросы остаются:
1. Вправе ли они обвинять в чем-то Джима и Джона?
2. Вправе ли они требовать удаления этих фото у Джима и Джона?
это вопросы не к вам конкретно — просто интересно ваше мнение и других людей.
Непонятно, по какому поводу правоохранители «решили пообщаться». Давайте без намёков, разгадывать ребусы неохота.
Какие ребусы? Разве так важны детали того, как инфа о вложении в фото попала к правоохранителям? Я предложил всего лишь один вариант из многих. Вам не нравится история с Джеком. Ну ок — пусть это будет анонимный донос, или сами придумайте вариант. Остановимся на том, что они это знают и кроме этого знания у них на Джима и Джона ничего нет. По прежнему интересует ответ на вопросы из пред. поста.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Методы обнаружения «склеенных» файлов