Стеганография в BMP

Выкладываю программу, которая записывает текстовое сообщение внутрь BMP или PNG
Для картинки 100*100 максимальная количество символов чуть меньше 3750.
Для человеческого глаза изменения не видны.

Позже сделаю шифрование зависимым от какого-нибудь ключа.

C#.NET Framework 2.0

Вложения

SteganographyInBmp.rar (7.7 Кб, 1259 просмотров)

1

> Оригинальную мы теряем, но на глаз полученная не отличается от оригинала

То, что картинка меняется - это понятно. Мне почему-то сначала казалось что для восстановления нужен оригинал. Думал, что мы вносим возмущение, а потом через оригинал это самое возмущение считаем. Только когда я отправил пост, до меня дошло, что мы просто затираем часть информации, а потому оригинал неважен

Но потом меня посетили сомнения по поводу jpeg'а, ибо я видел, что программа умеет работать с ним. Но на работе не было возможности проверить. Теперь допёрло, что jpeg только читается, но не пишется.

> Возможно, я не очень точно описал алгоритм. Если интересует - его описание есть в интернете

Я знаю, как устроен jpeg на алгоритмическом уровне. Потому и спросил про него. Но мне кажется, что левый верхний бит не может сохраняться из-за того, что используется дискретное косинусное преобразование. С математикой у меня туго, но при этом теоретически весь квадрат может испортиться. А вот после преобразования, возможно, левый верхний пиксель и сохраняется, поскольку теперь он соотвествует самой низкой частоте. Т.е. вопрос с jpeg'ом, судя по всему, остаётся открытым.

А какова область практического применения такого кодирования? Если нужно от кого-то втихаря что-то передавать, но при этом всё должно оставаться на виду, то постоянные пересылки в форматах bmp и ico в теории должны навести на подозрение

0

Сообщение от Evg ... Но мне кажется, что левый верхний бит не может сохраняться из-за того, что используется дискретное косинусное преобразование. С математикой у меня туго, но при этом теоретически весь квадрат может испортиться.

С математикой у меня тоже не очень. Но весь квадрат и не нужен. Используем только верхний левый пиксель. Ведь при чтении картинки на его основе восстанавливается всё изображение.

Сообщение от Evg А вот после преобразования, возможно, левый верхний пиксель и сохраняется,

Вот именно потому я и работал с файлом картинки-носителя напрямую. Без использования классов обработки изображения.
Собственно, первая моя программа такого типа писалась на паскале под консоль. И там вообще никаких классов не было. BlockRead/BlockWrite. Программа была призвана сохранять мелкие файлы в фотках.

Сообщение от Evg ... Т.е. вопрос с jpeg'ом, судя по всему, остаётся открытым.

Сейчас, когда 1,5МБ джипегом никого не удивишь - уже можно рассматривать вопрос о поддержке этого формата. Когда я создавал свою прогу - джипег в 200кБ считался огромным, а диал-ап на скорости 5-6кБ/сек считался пределом достижимого.

Сообщение от Evg А какова область практического применения такого кодирования?

Передача или хранение информации когда нужно скрыть факт сокрытия информации.
Пароли, например, так можно хранить.

Сообщение от Evg Если нужно от кого-то втихаря что-то передавать, но при этом всё должно оставаться на виду, то постоянные пересылки в форматах bmp и ico в теории должны навести на подозрение

Можно включить поддержку несжатого TIFF. По сути - тот же ВМР, только заголовок чуть другой.
А многие фотоаппараты в таком формате фотки делают (например мой Olympus C770UZ).
Если же поддерживать TIFF со сжатием без потери данных - то придётся писать алгоритм его распаковки в оперативку и упаковки обратно.
Так же перспективен формат RAW - побитовая копия матрицы фотоаппарата (вообще без каких либо заголовков, для корректного просмотра таких файлов нужно знать в каком разрешении снимок делался, но для шифрования это некритично)

1

Сообщение от Delphin_KKC С математикой у меня тоже не очень. Но весь квадрат и не нужен. Используем только верхний левый пиксель. Ведь при чтении картинки на его основе восстанавливается всё изображение.

Клясться и бодиться не буду, ибо на практике никогда не работал. Но насколько я знаю, квадрат 8 на 8 переводится из цветового режима в частотный (делается ДКП). Формулу преобразования я опять-таки навскидку не знаю, но преобразования такогорода, как мне кажется, не могут сохранять какой-то конкретный пиксель. К тому же перед этим делается преобразование 4:4:4 -> 4:1:1, которое усредняет группы из четырёх точек в красном и синем каналах. Т.е. уже на одном только этом первоначальноый цвет точки потенциально теряется

Сообщение от Delphin_KKC Сейчас, когда 1,5МБ джипегом никого не удивишь - уже можно рассматривать вопрос о поддержке этого формата. Когда я создавал свою прогу - джипег в 200кБ считался огромным, а диал-ап на скорости 5-6кБ/сек считался пределом достижимого.

Вопрос с jpeg'ом для меня открыт не потому, что нужен большой файл, а потому, что я пока "не верю" (c) в то, что хоть какой-то пиксель там остаётся без изменений

Сообщение от Delphin_KKC Можно включить поддержку несжатого TIFF. По сути - тот же ВМР, только заголовок чуть другой. А многие фотоаппараты в таком формате фотки делают (например мой Olympus C770UZ). Если же поддерживать TIFF со сжатием без потери данных - то придётся писать алгоритм его распаковки в оперативку и упаковки обратно. Так же перспективен формат RAW - побитовая копия матрицы фотоаппарата (вообще без каких либо заголовков, для корректного просмотра таких файлов нужно знать в каком разрешении снимок делался, но для шифрования это некритично)

Я не совсем правильно написал. Вопрос о практической применимости в первую очередь касался именно данной программы, поскольку она работает только с "неинтересными" форматами bmp и ico. Вариант для хранения паролей - возможно, но намного надёжнее пароль написать на бумажке и спрятать её в ящике стола. Сама идея кодирования информации через модификацию картинки, несомненно, очень интересная

0

ну так можно просто файлик на файлообменник выложить или свою новую фотку вконтакте добавить! а там пароль.

эх, если будет совсем не лень, попробую завтра дешифратор написать идея в том, что если сделать ДПФ на фотке, то появятся всплески в области высоких частот (ну, потому что картинка содержит в основном крупные элементы, соответствующие нихким частотам, а измененные биты добавляют ВЧ шум. не знаю, что получится, но заготовки для ДПФ у меня есть уже...

0

> ДПФ

Во! Правильно наверно не косинусное, а фурье

Тут же фигня не столько в том, чтобы зашифровать, сколько в том, что надо ещё обратно расшифровать

0

По идее в JPEG можно найти байты, изменение младшего бита которых не вызывает заметных изменений цвета. И эти байты использовать для хранения скрытой информации. Если после сохранения в файле информации его не редактировать - то хоть косинусное преобразование, хоть Фурье - без разницы.

0

Ты уверен, что можно найти? Вот у меня такой уверенности нет

Добавлено через 4 минуты
jpeg - это алгоритм с компрессией данных. А любая компрессия подразумевает отсуствие избыточных данных. Т.е. каждый бит является важным и изменение одного бита в бинарном предсталвнии (т.е. напрямую в файл без разжимания изображения) приведёт к тому, что картинка попросту не будет читаться

0

Сообщение от Evg Ты уверен, что можно найти? Вот у меня такой уверенности нет

А у меня есть.
Вот ссылка на страницу с описанием одной бесплатной программки времён Win95 (на ХР работает. проверял), которая скрывает файлы в картинках JPG: http://inoe.name/38476-steganografija.html

0

Насколько я понимаю, там только экзешник (а работы у меня с ifolder'а так и не скачалось). А хотелось бы услышать словесное описание того, что там делается (а точнее, как делается)

0

Да, там экзешник. Но раз есть такая программа - значит в JPG возможно сохранять инфу, а значит есть и алгоритм нахождения этих самых "не очень важных" байт.
Честно говоря, мне самому интересен алгоритм её работы. А именно - алгоритм нахождения в jpeg-файле байтов, которые относительно безболезненно можно менять.

0

А не могут ли в jpeg'е быть какие-то "пустые" биты, остающиеся по принципу выравнивания (т.е. в какойто момент битовую последовательность надо выравнивать на границу байта)?

0

Возможно. Но как тогда определить этот момент выравнивания?
В справке той программы написано: "файл может скрыть приблизительно 10 % своего собственного размера" (правда, там на английском, я перевёл).
Точный максимальный размер скрываемого файла программа вычисляет индивидуально для каждого файла.
Так что вполне возможно что информация скрывается в "хвостах". Однако, если это так - скрытую информацию легко обнаружить. (хвосты ведь обычно содержат нули. Врядли джипег заполняет их мусором)

0

Тут я уже ничего сказать не могу, ибо никакого понятия не имею о том, как устроен jpeg на уровне формата. Но я видел "битые" картинки, где косяки возникают в виде квадратов, а не в виде всей перекошенной картинки. Поэтому предполагаю, что в бинарном виде информация записывается не сплошным потоком, а разбивается на квадраты (из соображений помехоустойчивости). В этом случае имели бы место дырки от 1 до 7 бит на границе квадратов. Тогда по конкретной картинке всегда можно узнать, где эти дырки находятся и закодированная информация точно так же раскодируется. Но это только предположение.

0

Однако, если бы дело было в дырках - то ведь может существовать изображение, которое будет иметь либо критично малое количество дырок (меньше 5% объёма файла) либо вообще их не будет иметь (крайний случай).
Слова "приблизительно 10 %" я склонен понимать как "от 5 до 15 %".
Скорее всего дело либо вообще не в дырках, либо не только в дырках

0

В общем, надо разбираться с форматом jpeg'а, чтобы понять

0

сделал в проге Алгоритм?

0

Мммм... насчет JPEG подумаю . . . Возможно реализую в своей программе.

0

JPEG искажает пиксели

0

JPEG искажает пиксели

Вы правы, но это при конвертировании в JPEG...

0

jpeg - алгоритм сжатия с потерями. Поэтому те же принципы, что и в bmp тут не канают. Ибо нет никакой гарантии, что после распаковки изображения тот или иной пиксель распакуется ровном в том же виде, в каком и был запакован. Правда высказывались мнения, что левый верхний угол каждого квадрата распаковывается без потерь, но если использовать только это, то количество возможной информации для кодирования будет совсем небольшим

0