Сокрытие информации и бинарные форматы файлов

Не так у меня была заметка про то как извлекать скрытые метаданные, но, для объективности, можно сказать что это только одна сторона медали.

Далее будут рассуждения и не более.

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

Правильные ответ — любые, какие только могут вздуматься производителю ПО, до которых это ПО может добраться и объём которых укладывается в полезную ёмкость контейнера для рассматриваемого формата.

Термин полезная ёмкость контейнера взят из стеганографии и он определяет то какой объём информации мы можем поместить в файл при этом сохранив остальное его содержимое неизменным для программ и людей которые с ним будут работать.

Фокус в том что стеганографические способы сокрытия метаданных обычно применяют в мультимедиа файлах — видео, изображениях и музыкальных файлах, например, через Least Significant Bit и ещё ряд методов. Когда нужно скрыть сравнительно большие объёмы данных или же возникает потребность в «скрытом канале информации», то по другому и не получится.

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

И всё упирается в три простых понятия характеризующих любого разработчика ПО как компании работающего с такими форматами:

1. Мотивация — есть ли у разработчика ПО потребность в получении скрытой информации о пользователе?
2. Репутация — превышает ли потенциальная выгода от получения риск обнаружения?
3. Квалификация — обладает ли компания квалифицированными кадрами чтобы обеспечить сокрытие информации?

Всё начинается с понятия мотивация и я приведу несколько потенциальных причин для её появления на неё влияющих:

1. Желание отслеживать «лицензионную чистоту» ПО по серийным номерам продуктов.

2. Желание отслеживать наличие/отсутствие ПО конкурентов.

3. Необходимость сотрудничества со спецслужбами, выполняя их требования по идентификации персоны по каким-либо оставленным файлам.

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

Главный риск любого тайного отслеживания пользователя в том что если это вскроется и получит огласку, то потом будет очень сложно доказать что всё это делалось для блага, а не с корыстными целями. Риски получения судебных исков будут более чем реальны и вопрос в том что же перевесит мотивация или репутация? Да, конечно, можно частично минизировать их, например, распространяя действие коммерческой тайны на форматы файла и запрещая дизассемблирование ПО. В этом случае репутационные риски могут возникнуть только в случае нарушения закона со стороны обнаруживших сокрытие данных. Как резюме — можно предположить ситуации когда производитель ПО может рисковать и использовать сокрытие информации несмотря на риски.

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

При этом файл как контейнер для хранения этой скрытой информации будет обладать как очевидными так и неочевидными носителями информациями — участками и способами кодирования в которых скрытые данные могут передаваться.

Наиболее очевидными носителями информации будут:

• Проприетарные участки файла для закрытых форматов
• Резервные поля и блоки файла если формат является условно-открытым и часть описания присутствует, а часть нет.

Всё это довольно просто — если формат файла неизвестен никому или же в нём есть закрытые куски, то можно сохранять в нём куски из блока скрываемой информации подвергшиеся предварительному преобразованию — сжатию, кодированию, сглаживанию и так далее.

Но, кроме очевидных способов сокрытия данных найдутся и весьма неочевидные:

• GUID’ы и UUID’ы — за счёт эмуляции псевдослучайных чисел присутствует по 16 байт на каждый уникальный идентификатор
• уникальные идентификаторы объектов отличные от UUID, например, если формат файла XML подобен и внутри у записей есть уникальные идентификаторы используемые только внутри контейнера и не несущие смысловой нагрузки при интерпретации программами потребителями, то идентификаторы записей могут использоваться как носители скрытой информации.
• использование особенностей чередования объектов/символов или стеганография пробелами для текстовых файлов.
• сокрытие информации внутри бинарных объектов в файле контейнере, например, в мультимедиа файлах.

Иначе говоря, при необходимости можно скрывать информации даже в открытых форматах.

Собственно, а как это можно отследить и выявить?

1. Отслеживать обращения ПО к информации уникально идентифицирующей компьютер/персону. Например, выявлять попытки чтения адреса Ethernet или Wifi/Wimax адаптера, чтения CPUID, попытки доступа к хранилищам сертификатов, номерам лицензий ОС и других программных пакетов и так далее.

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

2. Очисткой файлов от «бинарных блоков», например, перекодированием изображений и перегенерация кодов GUID/UUID.

3. Анализ аномалий в потенциальных носителях информации, но это уже совсем другая история.

Пока же могу сказать точно что у производителей софта гораздо больше возможностей отслеживать пользователей, чем у пользователей возможностей это предотвратить.

Такие дела.