Итак, дошли руки написать полноценный ответ.
Чтож, как искать — уже сложилась традиция и инструменты. Если рассматривать простые CTF, они так или иначе уповают на стандартные инструменты. Средние — это комбинация с хитростями, сложные — это что-то, что вы не найдёте в интернете, или искать будет очень сложно.
Остановимся на простых-средних. Они, опять же, очень доступным языком описаны даже на пикабу.
Желательно иметь под рукой linux или WSL.
Пробуем команду file
, она покажет что из себя представляет изображение. Файл может именоваться jpeg, а по сути быть PNG. Если разрешение не совпадает, то это уже подозрительно, надо копать! К слову, в Forensic практике, откуда у меня большая часть опыта, файлы проверяют на сигнатуры (signatures), т.е. начало файла. Если оно не совпадает с разрешением, это дико подозрительно. Windows отобразит PNG как PNG, даже если его назвать ***.jpg, так устроена система, но важно знать с каким файлом имеем дело. Для linux и вовсе разрешения не важны, это скорее удобство, гораздо важнее разрешения на файл, и, в частности, исполняемый он или нет.
Проверили файл, отлично, убедились, что это PNG.
Что дальше? Метаданные. Их обязательно стоит проверить. Там могут быть лёгкие флаги. Для этого используем:
Оба хороши. Первый выдаст:
Warning : [minor] Text/EXIF chunk(s) found after PNG IDAT (may be ignored by some readers)
Наверное, единственное к чему стоит придраться. Но, если поискать по этой ошибке, создатели говорят, что стоит использовать другие инструменты, а другие (exiv2) не выдают ничего более интересного, и если в ручную хексом посмотреть, там нет ничего интересного, поехали далее.
Далее я использовал xxd
, по нему ничего интересного, останавливаться не буду.
strings
— очень классная команда, позволяет найти завуалированные сообщения. Для неё необходимо поставить: apt-get install binutils
. В нашем случае видим чанки и ничего интересного.
binwalk
— мощнейший инструмент для CTF. Не важно, склеили ли вы файл банальной командой, которая склеивает jpg и rar (любой другой архив), или как-то хитрее, в большинстве случаев данная команда покажет склейку. Всё зависит от хтрости, верить ей полноценно не стоит, может и не показать. А может показать false positive:
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 PNG image, 1015 x 393, 8-bit/color RGBA, non-interlaced
17481 0x4449 TIFF image data, big-endian, offset of first image directory: 8
Видим TIFF, но по размеру понятно, что там ничего нет. Можно сделать экстракцию через binwalk --dd='.*' 3.png
, но интересного там ничего нет. Также команда поддерживает deflate и прочее сжатие, но, опять же, мимо. Может быть не мимо для других CTF.
foremost
тоже дико крутая штука, как binwalk, но мимо.
pngcheck
— раз уж мы имеем дело с PNG, абсолютно нужная штука. Что выдаст pngcheck -c -v -t 3.png
:
File: 3.png (17511 bytes)
chunk IHDR at offset 0x0000c, length 13
1015 x 393 image, 32-bit RGB+alpha, non-interlaced
chunk sRGB at offset 0x00025, length 1
rendering intent = perceptual
chunk IDAT at offset 0x00032, length 8192
zlib: deflated, 32K window, fast compression
chunk IDAT at offset 0x0203e, length 8192
chunk IDAT at offset 0x0404a, length 1007
chunk eXIf at offset 0x04445, length 14: EXIF metadata, big-endian (MM) format
chunk IEND at offset 0x0445f, length 0
No errors detected in 3.png (7 chunks, 98.9% compression).
Опять же, мало чего полезного.
Имеем стандартный PNG, чанки по 8192, что является лимитом для PNG и вполне логично. Если бы чанки были меньше — вот это было бы подозрительно. Но тут всё 👌. Смущает только то, что если в Photoshop сохранить файл, то изображение помещается в один чанк, без потери в качестве и изначальном сообщении, значит что-то там спрятано!
Иструментов далее куча! Это и stegseek
, steghide
, stegsolve
и много-много других.
Остановимся на zsteg
.
И тут всё интересно. Библиотека на ruby смотрит MSB и LSB, гуглите :)
Если вкратце, LSB — least significant bit, в отличие от MSB слабо меняет изображение и идеально подходит для стеганографии. Что это значит? Это значит, что информация помещается попиксельно с минимальными изменениями, где зелёный продолжает быть зелёным, для глазу непринциписально, смотри комментарий @avp. Тут можно много навыдумывать, но есть и инструменты, такие как zsteg
. Помимо него полезно попробовать Stegsolve.jar
, но тут всё идёт автоматически. И, вот проблема, библиотека выдала многострочную string, но в ней не было искомой информации. Она нашлась по тем же алгоритмам в онлайн инструментах: [ 1 | 2 ]. Почему? Будем разбираться в issue на GH.
Тут ответ:
there is no quest with a portal it's just an excuse
Если ничего не нашлось (а уже нашлось), стоит смотреть в более экзотические методы, например, как по ссылке, скрытие информации в области, которая не будет рендериться при открытии. Инструменты ничего не покажут, глаз увидит, если знать. Всё что нужно — расширить область рендеринга в IHDR
, при этом соблюсти CRC. Как написано в статье, если не получается посчитать его, берите другой файл с схожим разрешением. На самом деле можно поменять размерность и получить искомый CRC через pngcheck
, это довольно просто.
Но, здесь ничего не скрыто.
Если рассматривать продвинутый уровень CTF, там может быть что угодно! Всё выше описанное, возможно надо будет отредактировать файл и переместить квадраты, возможно собрать сообщение из нескольких LSB, возможно смотреть на размер чанков, или убирать их, чтобы увидеть сообщение, тут раздолье для шифропанков. Оставим сложные задачи для соревновательного формата и не будем раскрывать все секреты :)