Pull to refresh

Comments 40

И не используйте картинку, которая уже есть в интернете… Чтобы не было двух почти одинаковых картинок, различающихся байтами.

Я как то пытался найти идентичные картинки на разных сайтах которые бы не различались байтами при помощи поиска по картинке. Скачал много визуальных копий одной и той же картинки. Они различались либо размерами изображения, либо размером файла. Хеши разные. Вот только про VCDIFF я тогда ещё не знал и им не сравнивал. Нашёл ли я идентичные копии в итоге не помню.


Так что найти того самого котика может оказаться не простым делом.

Если в теории есть возможность, то лучше не рисковать. Хотя прятать критически данные LSB-стеганографией само по себе рискованно…

в случае с JPEG скорей всего будет производиться пережатие в момент размещения на сайте. А вот те же PNG не считая метаинформации могут оказаться пиксель-в-пиксель

Извиняюсь, если вопрос не совсем по теме. Существуют ли методы стеганографии, устойчивые к преобразованию изображения? Я имею в виду resize, изменение яркости/контрастности/насыщенности/тона, минимальная корректировка геометрии и т.п. В том числе, существует ли метод, который «выдержит», скажем, печать изображения + последующее сканирование. Понятно, что при таких требованиях много информации не спрячешь, но много и не надо, достаточно нескольких байт. Интересует как теория, так и конкретные реализации.
Я думаю если использовать LSB не пикселей, а «частот» которые используются в JPEG и иже с ними, то ко многим из искажений будет устойчивость. Насчет печати/сканирования трудно так сразу сказать, но если есть возможность откалибровать весь процесс, то скорее тоже возможно, чем нет.
Скорее всего, это очередной велосипед, причем нерабочий, но за 30 секунд придумался примерно такой метод:

1. Режем картинку на квадраты где-нибудь так 10x10 пикселей и выше.
2. изменение яркости центра квадрата — наши биты
3. чтобы изменение яркости на границах соседних квадратов было не особо заметно — яркость растет/падает плавно к центру квадрата. Яркость границы между квадратами остается оригинальной (можно использовать в качестве «опорного» сигнала).

Далее традиционно — полезную нагрузку зашифровать, поверх помехоустойчивое кодирование и результат использовать в качестве «модулятора яркости» квадратов.

Можно сбоку на изоленту даже троичное кодирование прикрутить — яркость+, яркость -, яркость не изменилась, тогда возможный размер полезной нагрузки при прочих равных немного увеличится (а устойчивость кодирования к внешним помехам, соответственно, упадет).

P.S. Сильно подозреваю, что кто-то где-то нечто подобное уже воплотил (или доказал, что сие работать не будет).

Этот метод подразумевает, что есть эталонная картинка, и декодер сравнивает картинку с изменёнными яркостями квадратов с эталоном?
С эталонной картинкой такое просчитать вообще без проблем, но как-то неспортивно :)

Сдается мне, что здесь и без эталонной картинки обойтись можно, опираясь на среднюю яркость границы конкретного квадрата и его содержимого.
По идее, на реальных изображениях внутри такого «макропикселя» яркость сильно гулять не должна. А если сильно гуляет и алгоритм декодирования ошибся, то, быть может, помехоустойчивое кодирование выручит. Я бы, пожалуй, после кодирования тут же пробное декодирование делал: раскодировалось — хорошо, нет — пробуем немного поиграться с начальными условиями (нарезать на бОльшие квадраты, e.t.c.)

Строгого математического алгоритма предоставить не могу, повторюсь, идея возникла секунд за 30, после чего была озвучена. Так что, очень даже может быть, что декодировать сие без оригинальной картинки нереально или крайне сложно — тогда идею только в мусор.
Я вот представил себе абсолютно произвольную картинку — пусть это будут рандомные данные с неизвестным распределением, попробовал к ней применить ваш концепт, и не получилось.
Очень даже может быть, что моя идея — пустышка. Не готов сейчас отстаивать ее жизнеспособность.
Нуу, самая устойчивая реализация это «если всё будет хорошо — пришлю картинку с котиком».
Благодарю за уточнение. Причем, в моем случае, они должны быть еще и невидимые (малозаметные) для человеческого глаза.

Есть, и активно применяется в кинематографе для ловли пиратов. В каждый кинотеатр отправляется фильм с разным скрытым сообщением, и если в каком-то кинотеатре снимут экранку и выложат в интернет, то сразу ясно в каком кинотеатре она была снята, и кинотеатру выписывается штраф.

Сейчас не скажу, но раньше в Photoshop был встроенный плагин записи копирайта в изображение, причем довольно устойчивый к изменениям.
Для печати документов есть «желтые точки», но их научились обходить — xakep.ru/2018/06/27/deda-vs-yellow-dots
Один заказчик на Upwork обратился к мне с подобным предложением. Он хотел зашифровать сообщение в картинке, чтобы ее можно было распечатать и повесить где-нибудь, а другой юзер мог бы с помощью приложения сфоткать картинку и считать оттуда секретное сообщение.

Я подумал и пришел к выводу что нельзя это сделать незаметно. Есть такое понятие «динамический диапазон», у человеческого глаза он очень большой, а у камеры низкий. Если сделать в изображении водяные знаки, которые бы читались и различались камерой, то человеческий глаз их тоже заметит, и обратит внимание что с картинкой что-то не так.

Я предложил заказчику другой выход — использовать машинное зрение и распознавание объектов. Например, можно разместить на картинке человеческое лицо, повернутое определенным образом, и зашифровать сообщение в параметрах этого лица — угол поворота, положение ключевых точек относительно друг друга. Эти параметры более-менее устойчивы при разном качестве изображения и не привлекают внимания. Но в таком случае нельзя зашифровать сообщение в произвольной картинке, скорее нужно наоборот, подбирать картинку, которая соответствует сообщению.
В случае произвольной картинки, видимо, так и есть. Как вырожденный вариант — полностью белый лист. Вряд ли на нем можно спрятать так, чтобы глаз не заметил, а камера увидела.
Но вот в случае «нормальных» изображений можно, наверное, найти участок с высокой энтропией и добавить туда что-то малозаметное для глаза. Ну, например, кто заметит лишний листик на фотографии кроны дерева? А при этом камерой распознается легко, да и устойчивость к обработке картинки будет высокой.
Хмм… а соотношение сторон? Пример — 19:11 — дата восстания против скайнета.

Если картинка может быть любая, то работаем с зональными уровнями яркости, это не вызовет подозрений и переживет ресайз/пережатие и печать в газете.

Сообщение можно адресовать группе людей, скажем у модели в руке тетрис, а в нем закодировано морзянкой сообщение. Или постер к матрице, в вертикальных зеленых буковках ASCII код, прочтут только программисты. Креативно составленный ребус может быть хорошим промокодом.
хеш-стеганография методом Machine Learning ;)

Пост на хабре будет?
UFO just landed and posted this here

Проще в местную газету "Из рук в руки" писать объявление про пропажу котика таких-то параметров, а параметры указывают на третьи строки в Большой Советской Энциклопедии, как в старые добрые времена :)

В процессе печати изображения используется цветовая схема CMYK с градацией цвета от 0 до 100 в классическом варианте. Если смотреть на нее долго и очень пристально, то можно увидеть небольшую разницу между соседними цветами. Так что я думаю, ответ на ваш вопрос скорее нет, чем да.



Хотя неплохо было бы проверить это экспериментально. Скорее всего нужно рассматривать более подробно процесс растрирования изображения перед печатью.

Вы пишете:


Возьмем меньший по модулю корень, то есть х_2.

И тут же проводите вычисления с корнем х_1 = 1.7951, который больше по модулю. Это, наверное, ошибка, тем более, что результат получился не 0.3256, как вы пишете ниже, а 0.4567.

Вы правы, в конечной формуле должно использоваться значение x_2.

Но спешу заметить, что значение 0.3256 мы получаем для рандомного котика, а не для котика с последовательным встраиванием, как в примере.
Незаполненный контейнер и контейнер, заполненный на 95% визуально отличаются. На заполненном много шумов в местах, которые не свойственны JPEG. Я бы заподозрил неладное.
Найти шумы, не свойственные JPEG, в PNG это, конечно, мощно.
И если ты долго смотришь в бездну, то бездна тоже смотрит в тебя.
Почему в оригинальном PNG на котике больше шума, чем на фоне?
Если это настоящая фотография, то матрице вообще без разницы, где генерировать тепловой шум.

Возможно, это фото было когда-то JPEG-ом, который удалил шум на низкочастотных участках, либо является монтажом, когда кот с одним шумом вклеен в фон с другим шумом. Обычно фотокамеры снимают в JPEG, мало кто заморачивается с RAW. Скорее всего, png — конверсия

А какое у вас объяснение?
Я вынуждена вам признаться… Этот котик был когда-то JPEGом. Ну он был слишком милым, и я не смогла справится с соблазном использовать его в статье. Прошу простить.

Суть в том, что неподготовленный глаз все равно не будет видеть шум, даже если он там есть (а он там есть по определению).
Для меня различие заметно невооруженным глазом, будто на второй картинке кто-то неумело попытался убрать бандинг/блочность.
Еще аргумент к тому, чтобы не заполнять контейнер под завязку :)
Использование PNG для фото явно с камеры само по себе подозрительно! :) Опять же, какие массовые сервисы или соцсети позволяют публиковать PNG для открытого доступа.
Замечание по поводу LSB из представления RGB. Верно ли, что значения 0 и 1 визуально отличаются друг от друга больше, чем 254 и 255? Более общо: вот эта шкала значений от 0 до 255 насколько сильно отличается от равномерной по восприятию? Мне кажется, что надежнее использовать LSB других величин, например, спектральных коэффициентов, которые используются во многих графических форматах, в том числе JPEG, а также в аудиоформатах. Смысл в том, что для этих lossy форматов уже была проведена работа по изучению того, какую информацию и в каких количествах можно отбрасывать так, чтобы результат не сильно испортился с точки зрения восприятия человеком. Грубо говоря, можно сжать один и тот же файл с разной степенью сжатия и посмотреть на разницу того, что выброшено при более агрессивном сжатии и менее. Таким образом можно найти те биты в менее сжатом представлении, которые можно портить стеганографией. (Разумеется, здесь нужно знать потроха формата.)

Теперь насчет статистического стеганоанализа. Верно ли, что вопрос о существовании надежного стеганографического контейнера всё еще открыт? Навскидку кажется, что таковой можно построить, если известно распределение LSB в «обычных» картинках. (Хм, не совсем так, а чуть сложнее: условное распределение LSB в зависимости от всего контекста.) Тогда достаточно построить функциональное отображение из равномерного распределения (к которому обычно принадлежит зашифрованное сообщение) в это «природное» распределение. И потом применить его к сообщению и результат засунуть в LSB.
Вопрос о равномерности RGB по восприятию довольно сложен лично для меня. Советую почитать про CIE 1931.
Можно провести такой эксперимент на коленке:
сможете ли вы различить, где здесь настоящий белый, почти белый (разница с настоящим белым равна 1) и уже не белый (разница с настоящим белым равна 5)?


Честно признаться, я смогла бы. Но не играют ли тут внешние факторы? Например, вы точно знаете, что это три различных цвета, вы видите большой участок покрытый этим цветом, а не мааааленький пиксель, вокруг много чисто белого, который создает контраст. Цветовосприятие крайне субъективная штука.
А здесь различаете настоящий черный, почти черный и уже не черный? Пусть вопрос останется отрытым. :)



Насчет JPEG тоже есть много нюансов. Я думаю, вам будет интересно это видео.

Словами «надежный» и «безопасный» надо играться очень осторожно. Будет обидно, если надежный стегоконтейнер придумали и успешно им пользуются, а мы об этом конечно же не знаем :) Нужно определять меру надежности в каждом отдельном случае, потому что то, что надежно сегодня, не будет надежно завтра. Распределение LSB может быть абсолютно любым с моей точки зрения. Изображение может быть псевдослучайным или однотонным.

Ну, на мой глаз третья картинка от первой заметно отличается, а вот черные все кажутся одинаковыми. Это всего лишь свидетельство против моего предположения сравнении 0, 1 и 254, 255. Но мой основной тезис был в том, что психометрические модели уже кем-то были разработаны и используются в популярных форматах со сжатием, так что в стеганографической задаче выбора наименее значимых кусочков информации нужно «всего лишь» воспользоваться готовым результатом.

Словами «надежный» и «безопасный» надо играться очень осторожно.

Это, конечно, верно. Однако мне бы хотелось получить примерно ту же степень строгости оценки качества стеганографии, что мы имеем сейчас в криптографии. Там существуют оценки стойкости шифров, опирающиеся на математические факты и математические же гипотезы. Ну и на другие практические вещи вроде качества ГСЧ, которые более-менее понятны.
Замечание по поводу LSB из представления RGB. Верно ли, что значения 0 и 1 визуально отличаются друг от друга больше, чем 254 и 255?
Не отличаются физически. В большинстве мониторов 6-битные ЦАП на матрицах, т.е. на 1 не приводит к изменению картинки. Нужно менять значение на 4.

А вот в HDR-мониторах, которых на вход получают 10 бит на канал, стоят обычно 8-битные матрицы.
Сотня килобайт — для нынешнего века маловато. Поэтому есть идеи по расширению масштаба. Например использовать НЗБ в звуковом файле, сохраненном во FLAC. Или можно вообще увеличить емкость секретного контейнера в 9 раз, если использовать 48-битный PNG или 24-битный звук. Т.е добавить ещё 8 бит разрядности на каждый канал и записывать в 9 наименее значащих битов ))) Но это будет конечно наглёж, который при битовом анализе покажет кучу шума там где его не должно быть.
Однако многим зловредам это хватает. Взять хотя бы ZeusVM, Triton, Zero.T. Все они использовали стеганографию.
Sign up to leave a comment.

Articles