Из слайдов, которые вы связали, похоже, что буквально воспринимают байты исполняемого файла как данные изображения в градациях серого , один байт на пиксель, с черным = 0.
Для файлов меньшего размера они используют более узкую ширину (например, 32 пикселя в ширину) или большую ширину для больших файлов, поэтому вы всегда получаете высокое изображение.
Это тривиально,например, с PGM-двоичным (P5) форматом изображения , который имеет очень короткий и простой текстовый заголовок, а затем двоичные данные.В заголовке также должна быть указана высота, поэтому вы должны рассчитать ее по выбранной ширине и размеру файла.
Например, этот быстрый взлом сценария оболочки:
#!/bin/bash
# args: filename [width]
# writes to stdout, redirect to a file
fn=$1
width=${2:-32} # default width=32 if there's no 2nd arg
size=$(stat -c %s "$fn")
echo -e "P5\n$width $((size/width))\n255" # header
cat "$fn"
это вывод на 15kB a.out, сделанный gcc, это то, что я могу просматривать (и увеличивать) с помощью любого средства просмотра изображений, которое понимает изображения PNG.Например, qiv, geeqie, gwenview.
P5 (grayscale, binary version)
32 449 (width height)
255 (max grayscale value)
^?ELF^B^A^A...
Например, ./stick-in-pgm.sh a.out 64 > a.out.64.pgm правильно использует width = 64 и вычисляет высоту = 224 из размера файла.
Очевидно, большинство PGM-читая программы не заботятся, если точный размер файла равен полному числу строк, но они жалуются, что файл "заканчивается рано", если высота слишком велика.(Так что вы не можете просто echo 32 10000.) Деление размера на ширину дает высоту, которая заставляет их не жаловаться;Мне не нужно было использовать dd, чтобы заполнить вывод полным числом 32-байтовых блоков строк.