Не так у меня была заметка про то как извлекать скрытые метаданные, но, для объективности, можно сказать что это только одна сторона медали.
Далее будут рассуждения и не более.
Есть и другая и она заключается в том, какие же скрытые данные в принципе могут присутствовать в различного рода файлах.
Правильные ответ – любые, какие только могут вздуматься производителю ПО, до которых это ПО может добраться и объём которых укладывается в полезную ёмкость контейнера для рассматриваемого формата.
Термин полезная ёмкость контейнера взят из стеганографии и он определяет то какой объём информации мы можем поместить в файл при этом сохранив остальное его содержимое неизменным для программ и людей которые с ним будут работать.
Фокус в том что стеганографические способы сокрытия метаданных обычно применяют в мультимедиа файлах – видео, изображениях и музыкальных файлах, например, через Least Significant Bit и ещё ряд методов. Когда нужно скрыть сравнительно большие объёмы данных или же возникает потребность в «скрытом канале информации», то по другому и не получится.
Но, вот в том то и хитрость что скрывать большие объёмы данных может потребоваться не всегда, а вот контроль и мониторинг действий пользователей можно обеспечить и малым объёмом наиболее важной информации.
И всё упирается в три простых понятия характеризующих любого разработчика ПО как компании работающего с такими форматами:
- Мотивация – есть ли у разработчика ПО потребность в получении скрытой информации о пользователе?
- Репутация – превышает ли потенциальная выгода от получения риск обнаружения?
- Квалификация – обладает ли компания квалифицированными кадрами чтобы обеспечить сокрытие информации?
Всё начинается с понятия мотивация и я приведу несколько потенциальных причин для её появления на неё влияющих:
1. Желание отслеживать «лицензионную чистоту» ПО по серийным номерам продуктов.
2. Желание отслеживать наличие/отсутствие ПО конкурентов.
3. Необходимость сотрудничества со спецслужбами, выполняя их требования по идентификации персоны по каким-либо оставленным файлам.
Иначе говоря, найти мотивацию возможно, и потенциальная выгода, в зависимости от ситуации, может быть довольно привлекательно, исходя из этого перейдём к другому понятию – репутация.
Главный риск любого тайного отслеживания пользователя в том что если это вскроется и получит огласку, то потом будет очень сложно доказать что всё это делалось для блага, а не с корыстными целями. Риски получения судебных исков будут более чем реальны и вопрос в том что же перевесит мотивация или репутация? Да, конечно, можно частично минизировать их, например, распространяя действие коммерческой тайны на форматы файла и запрещая дизассемблирование ПО. В этом случае репутационные риски могут возникнуть только в случае нарушения закона со стороны обнаруживших сокрытие данных. Как резюме – можно предположить ситуации когда производитель ПО может рисковать и использовать сокрытие информации несмотря на риски.
И, фактор третий, квалификация. Это ничто иное как способность программистов скрыть сам факт сбора информации и сохранение в файл. В квалификацию также можно включить наличие понимания того как определить полезную ёмкость информации для форматов файлов и использовать её.
При этом файл как контейнер для хранения этой скрытой информации будет обладать как очевидными так и неочевидными носителями информациями – участками и способами кодирования в которых скрытые данные могут передаваться.
Наиболее очевидными носителями информации будут:
- Проприетарные участки файла для закрытых форматов
- Резервные поля и блоки файла если формат является условно-открытым и часть описания присутствует, а часть нет.
Всё это довольно просто – если формат файла неизвестен никому или же в нём есть закрытые куски, то можно сохранять в нём куски из блока скрываемой информации подвергшиеся предварительному преобразованию – сжатию, кодированию, сглаживанию и так далее.
Но, кроме очевидных способов сокрытия данных найдутся и весьма неочевидные:
- GUID’ы и UUID’ы – за счёт эмуляции псевдослучайных чисел присутствует по 16 байт на каждый уникальный идентификатор
- уникальные идентификаторы объектов отличные от UUID, например, если формат файла XML подобен и внутри у записей есть уникальные идентификаторы используемые только внутри контейнера и не несущие смысловой нагрузки при интерпретации программами потребителями, то идентификаторы записей могут использоваться как носители скрытой информации.
- использование особенностей чередования объектов/символов или стеганография пробелами для текстовых файлов.
- сокрытие информации внутри бинарных объектов в файле контейнере, например, в мультимедиа файлах.
Иначе говоря, при необходимости можно скрывать информации даже в открытых форматах.
Собственно, а как это можно отследить и выявить?
1. Отслеживать обращения ПО к информации уникально идентифицирующей компьютер/персону. Например, выявлять попытки чтения адреса Ethernet или Wifi/Wimax адаптера, чтения CPUID, попытки доступа к хранилищам сертификатов, номерам лицензий ОС и других программных пакетов и так далее.
Но, во первых чтобы отследить все обращения нужен специальный софт который бы это мониторил, а во вторых, программы могут обращаться к такой информации не постоянно, а лишь единожды при запуске и далее сохранять её в памяти в неоднократно, но обратимо преобразованном виде.
2. Очисткой файлов от «бинарных блоков», например, перекодированием изображений и перегенерация кодов GUID/UUID.
3. Анализ аномалий в потенциальных носителях информации, но это уже совсем другая история.
Пока же могу сказать точно что у производителей софта гораздо больше возможностей отслеживать пользователей, чем у пользователей возможностей это предотвратить.
Такие дела.
