Total Commander

Мощный плагин для стеганографического скрытия в JPEG изображении произвольных данных с использованием авторского метода. Потоковое шифрование, маскирование с использованием ГПСЧ, LZMA компрессия, возможность скрытия группы файлов (режим tar.jpeg)

скачать

30.11.2011: Плагин обновлен.

1.Добавлена опция смены идентификатора контейнера. Т.о., даже зная верный пароль маскировки, контейнер распознается только при совпадении идентификатора.

2. Добавлены опции параметров LZMA компрессии

06.02.2013: Плагин обновлен.

1.Добавлен алгоритм случайного секретного распределения. Таким образом, без знания ключа ССР (RSD) невозможно провести атаку на стегоконтейнер - извлечь вложение в исходном порядке байт будет просто не реально.

2. Переход на новое ядро LZMA актуальной версии

3. Расширен перечень параметров компрессора.

4. Обновлены как x86, так и x86-64 редакции.

1. При извлечении файлов из контейнера имена файлов сократились до восьмизначного формата. Как сделать, чтобы имена файлов не менялись?

2. После успешного извлечения фалов из контейнера повторно нажимаю на распаковку файлов и второй раз пароли уже не запрашиваются. Хм.. почему? Получается, что файлы извлёк, затем удалил, но их можно затем снова извлечь без пароля.

Rusl8, по второму вопросу. Если перезапустить TC, то пароль запросится вновь.
alexanderwdark, JPG в который пакуем файл, должен быть больше самого этого фала, а на сколько? Просто хотел запаковать архив 2.5 Мб в JPG 3.5 Мб, выдало о нехватке памяти.

Rusl8
1. Это особенности заголовка. Поскольку реальная стеганография в JPEG раньше вообще считалась невозможной, а теперь - великая редкость, и возможный размер стеговложения не так уж велик, то тут каждый байт на счету. Такое ограничение существует еще и для совместимости с программой RedJPEG XT. Если будет много запросов от пользователей, заголовок можно будет и доработать.

2. Пароли просто кешируются. Историю открытия архива хранит и сам TC (список файлов в архиве, что выдает ReadHeader)

Добавлено спустя 6 минут:

jentoso писал(а):alexanderwdark, JPG в который пакуем файл, должен быть больше самого этого фала, а на сколько? Просто хотел запаковать архив 2.5 Мб в JPG 3.5 Мб, выдало о нехватке памяти.

Имеете в виду нехватку доступной памяти (емкости) контейнера? Используется метод модификации таблиц кодировщика, причем с ограничениями по их начальному содержимому (иначе модификация будет визуально различима). Поэтому зависит не только от размерности изображения, но и от его цвето-насыщенных показателей, от самой "картинки". Доступный размер значительно меньще, чем в обычном битмапе (или в изображении без потери качества), как-то в StegoTC G2. Сами понимаете, LSB метод для JPEG не подойдет. Данный метод подразумевает реальную стеганографию, а не модификация тегов, или дописывание, поэтому ограничений много и они индивидуальны.

Добавлено спустя 19 минут:

jentoso писал(а):Просто хотел запаковать архив 2.5 Мб в JPG 3.5 Мб

Такие объемы вложения в JPEG просто недостижимы. Если появиться когда-нибудь решение, позволяющее скрыть что-либо в изображении с алгоритмом JPEG, значит стеганографией там и не пахнет. Это скорее всего что-нибудь из оперы с дописыванием файла к файлу или с использование блока JIFF, предназначенного для тегов, комментариев. Да и говорить о соотношении размер контейнера = размер доступного вложения нельзя (как я уже разъяснил). Если можно как-то связать, то лишь косвенно с размером в пикселях (не явно, как в StegoTC G2/LSB). Скажем, у меня изображение 1890Х2835 позволяет вместить около 400 Кб. Если скрывать сжимаемые данные и покрутить опциями LZMA компрессора, выйдет гораздо больше. Узнать, сколько позволяет скрыть той или иной контейнеро можно. Для этого поставьте галку под опцией "Calculate capacity..". Число покажет саму емкость указанного JIFF после анализа таблиц кодировщика. Если вложение поддается компрессии, влезет гораздо больше. Суть данной стеганографии - не в доступной емкости, а в практическом отсутствии возможных атак на защищаемые данные. Используя RSD (выключен по-умолчанию) восстановить стеговложение без знания ключа вероятностей нет.

[mod="Avada"]Не надо полностью цитировать предыдущие собщения, на которые даётся ответ. И уж тем более — дублировать цитаты в одном и том же ответе. Лишнее удалено.[/mod]

alexanderwdark, в окне упаковки файлов, подставляется не имя исходного файла, а имя папки в которой он находится. Это касается именно архивов.

Еще одна странная особенность работы плагина. Упаковываем файл, он поялвется в противоположной панели. Запускаем повторную упаковку, и вместо того чтобы предложить выбор действий (переименовать и т.д.), как это делают другие плагины, выводится ошибка "Функция не поддерживается.

Имеются архивы в изображениях JPG без паролей, после установки плагина, открыть их уже не получается по Ctrl+PgDn. Как можно обойтись в этом случае?

jentoso писал(а):в окне упаковки файлов, подставляется не имя исходного файла, а имя папки в которой он находится.

Т.е. конечным именем jpg - контейнера становится имя папки, в котором лежал скрываемый файл? Надо посмотреть.

пускаем повторную упаковку,..., выводится ошибка "Функция не поддерживается.

Правильно, изменение стегоархивов не поддерживается. Поэтому, если конечный файл с таким именем существует, плагин выдает TC такой код в ответ на список возможностей. Это ведь не архивы на самом деле.

Имеются архивы в изображениях JPG без паролей, после установки плагина, открыть их уже не получается по Ctrl+PgDn. Как можно обойтись в этом случае?

А чем вы создавали архивы? Плагин совместим со своей прошлой версией при условии идентичности настроек (RSD выкл., одинаковый заголовок, идентичные строковые пароли)

А зачем данный плагин? Ведь есть StegoTC G2, который тоже работает с JPEG? Или у них разные возможности в этом плане?

Афи писал(а):А зачем данный плагин?

Меня больше интересует, зачем нужен данный плагин вообще? Пока вижу только одно применение - замаскировать запароленную зашифрованную базу данных менеджера паролей в *.JPG под паролем с заливкой на ту же почту, куда вход также не без пароля = реальная защита.

alexanderwdark писал(а):конечным именем jpg - контейнера становится имя папки

Так и есть. Только это почему происходит, если файлом является архив (rar, zip, 7z)

alexanderwdark писал(а):если конечный файл с таким именем существует, плагин выдает TC такой код

Я хочу зашифровать файл A в изображение B, проделываю это. Потом мне надо этот же файл A, зашифровать в изображение С. Здесь я сталкиваюсь с тем, что плагин сразу мне выдают ошибку, не предоставляя возможности, выбрать исходный файл изображение и переименовать конечный зашифрованный файл. Приходится в противоположной панели, переименовать предыдущий файл B, и только потом создавать файл C.

alexanderwdark писал(а):А чем вы создавали архивы?

Командой copy /b файл.jpg+архив.rar файлархив.jpg

Афи писал(а):А зачем данный плагин? Ведь есть StegoTC G2, который тоже работает с JPEG? Или у них разные возможности в этом плане?

StegoTC G2 - это расширенная LSB стеганография + RSD алгоритм в изображениях со сжатием без потери качества. В JPEG он ничего скрывать как теоритически, так и практически не может. Для этого алгоритма не применима классическая стеганография.

RedJPEG - Авторский метод JPEG стеганографии + RSD (алгоритм ССР)

jentoso писал(а): конечным именем jpg - контейнера становится имя папки если файлом является архив

Проверил. И правда. Видимо это поведение TC - никакой специальной обработки для архивных файлов не производится.

jentoso писал(а): Я хочу зашифровать файл A в изображение B, проделываю это. Потом мне надо этот же файл A, зашифровать в изображение С. .

На какой версии TC вы проделываете операцию? У меня происходит другое - просто заменяется конечный архивный файл, если имя сохранить прежнее. При этом TC предварительно вызывает чтение содержимого конечного архива. Хотя плагин и выдает флаг отсутствия поддержки модификации архива.

jentoso писал(а): Командой copy /b файл.jpg+архив.rar файлархив.jpg

Тогда врядли плагин позволит зайти в такой архив. Просто он для всех файлов выдает код возврата возможности оперирования с JIFF контейнером в текущей сборке. Почему так? Все просто, ведь никаких специальных маркеров в файле нет и быть не может. Сам файт наличия стеговложения можно определить только после целого ряда преобразований самого изображения. Уже после чего инициализируется поточный шифр и происходит анализ. Причем для инициализации шифров следует запростить у пользователя ключ на контейнер, а возможно и индивидуальные настройки стегоалгоритма. Если добавлять проверку на каждый вызов свой-чужой от TC то это дико замедлит работу и будет раздражать пользователя. Чтобы зайти в любой нестеганографический файл, как в архив просто переименуйте его в .JPEG и оперируйте без ядра RedJPEG - это расширение специально игнорируется.

alexanderwdark писал(а):На какой версии TC вы проделываете операцию?

TC 8.01 x32 (x64), Windows 8 x64

jentoso писал(а):TC 8.01 x32 (x64), Windows 8 x64

Странно, но у меня на такой же конфигурации плагин позволяет в стандартном диалоге задать другое имя стегоархива, даже если архив с именем, которое предлагает TC существует. Скажем, если паковать архив rar из папки загрузок, то TC предлагает имя downloads.jpg (вместо исходного), но в диалоге упаковки можно в обычном режиме задать имя, скажем, downloads1.jpg

Никак не могу повторить описанную вами ситуацию.