Code @ C++
Не только на C++. Новые технологии, процессы и Agile.
- Все подряд
- Разработка под Android
- Работа и сотрудники
- Поиск сотрудников
вторник, 17 мая 2016 г.
hex dump
Постоянные пользователи Vim наверняка слышали об утилите xxd. Она позволяет вывести дамп указанного файла. Выглядит это следующим образом:
$ xxd -l 64 db.sqlite3 0000000: 5351 4c69 7465 2066 6f72 6d61 7420 3300 SQLite format 3. 0000010: 0400 0101 0040 2020 0000 0013 0000 0024 . @ . $ 0000020: 0000 0000 0000 0000 0000 0017 0000 0004 . 0000030: 0000 0000 0000 0000 0000 0001 0000 0000 .
Параметр -l 64 указывает, что нужно вывести только первые 64 байта. Есть еще один любопытный параметр (-i), который позволяет сгенерировать код, и его можно сразу вставлять в C или C++ файл:
$ xxd -i -l 64 db.sqlite3 unsigned char db_sqlite3[] = < 0x53, 0x51, 0x4c, 0x69, 0x74, 0x65, 0x20, 0x66, 0x6f, 0x72, 0x6d, 0x61, 0x74, 0x20, 0x33, 0x00, 0x04, 0x00, 0x01, 0x01, 0x00, 0x40, 0x20, 0x20, 0x00, 0x00, 0x00, 0x13, 0x00, 0x00, 0x00, 0x24, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x17, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00 >; unsigned int db_sqlite3_len = 64;
Параметров для генерации кода для других языков не предусмотрено. Но это поправимо. Например, мне понадобилось вставить код в модульные тесты на Python 3. Помог в этом потоковый редактор sed:
$ xxd -l 64 -g 1 -u db.sqlite3 | sed -e 's/.\+: /b"\\x/g' -e 's/ .*/"/g' -e 's/ /\\x/g' b"\x53\x51\x4C\x69\x74\x65\x20\x66\x6F\x72\x6D\x61\x74\x20\x33\x00" b"\x04\x00\x01\x01\x00\x40\x20\x20\x00\x00\x00\x13\x00\x00\x00\x24" b"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x17\x00\x00\x00\x04" b"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00"
И кстати, вскоре я поделюсь опытом как быстро начать писать программы на Python.
- Дню Нейл. Практическое использование Vim
- Марк Лутц. Программирование на Python. Том 1
Как создать Hexdump файла или строки текста
Шестнадцатеричный дамп представляет собой вид шестнадцатеричные данных. Используйте шестнадцатеричный код при отладке программы или для обратного проектирования программы.
Например, во многих форматах файлов используются специальные шестнадцатеричные символы для обозначения их типа. Когда вы пытаетесь прочитать файл, но он загружается неправильно, возможно, файл не в том формате, который вы ожидаете. Шестнадцатеричный дамп помогает устранить неисправности. Аналогично, чтобы разобраться, как программа работает без исходного кода, посмотрите на шестнадцатеричный дамп, чтобы оценить ее производительность.
Что такое шестнадцатеричное?
Компьютеры думают в двоичном формате . На каждый символ, число и символ ссылаются двоичные значения — то, что называется арифметикой с основанием 2 , с использованием нулей и единиц. Люди думают в десятичной или десятичной арифметике, которая опирается на цифры от нуля до девяти. В шестнадцатеричном или базовом 16 арифметическом вычислении используются 16 единиц, представленных цифрами от нуля до девяти плюс буквы от A до F.
Как создать шестнадцатеричный дамп с помощью Linux
Чтобы создать шестнадцатеричный дамп с помощью Linux, используйте команду hexdump .
Средства просмотра файлов и редакторы общего назначения
Выбор подходящих редакторов и средств просмотра файлов является фундаментом успешного судебного анализа. Без средств, позволяющих должным образом рассматривать подозрительные файлы, следователь может прийти к неправильному заключению. Например, представьте себе аналитика, который полагается на средство просмотра изображений, обеспечивая надлежащие результаты для файла с именем image. tiff . Если файл image. tiff в действительности является музыкальным файлом MP3 , он не будет правильно отображен в средстве просмотра, предназначенном для рисунков. Следовательно, нужно использовать общие средства просмотра файлов. К счастью для аналитика, такие средства просмотра общего назначения существуют.
Эта лекция посвящена редакторам и средствам просмотра, используемым во время типичного судебного анализа. Эти средства определены, как общие ( generic ) в том смысле, что они поддерживают много различных типов файлов. Некоторые из представленных средств просмотра поддерживают даже неограниченное количество файловых форматов. Более того, хотя «редактирование» обычно не выполняется во время расследования. В этой лекции проиллюстрировано, что редакторы, могут также добавлять мощные свойства к комплекту инструментов аналитика.
Команда file
Хотя команда file , которая поставляется с большинством инсталляций Unix, не активизирует средство просмотра, она упомянута здесь, потому что ее фундаментальное использование дополнит средства просмотра, обсуждаемые в следующих разделах. Поскольку эта команда присутствует в операционных системах Unix с открытым кодом (FreeBSD, Linux и так далее), ее исходный код легко доступен.
Реализация
Команда file принимает в качестве аргумента имя файла. Она выполняется следующим способом:
forensic# file
Команда file смотрит на заголовки и другие свойства указанного файла в файле «magic». Файл «magic» в большинстве операционных систем Unix, расположен в каталоге /usr/share/magic. Файл «magic» содержит сигнатуры многих известных файлов, таких как текстовые файлы, исполняемые, сжатые и другие.
Вы можете указать другой файл «magic» вместо файла, заданного по умолчанию, используя ключ -m .
forensic# file -m mymagicfile.txt
Эта команда будет использовать файл mymagicfile.txt, расположенный в текущем каталоге, в качестве таблицы для поиска сигнатур файлов.
Ниже приводится пример типов вывода, которые дает команда file .
forensic# file netcat.c netcat.c: ASCII C program text, with CRLF line terminators forensic# file nc.exe nc.exe: MS Windows PE 32-bit Intel 80386 console executable not relocatable forensic# file nc11nt.zip nc11nt.zip: Zip archive data, at least v2.0 to extract forensic# cd suspiciousfiles forensic# file * Finding Me.mp3: mp3 file with ID3 2.0 tag Finding Me.wma: Microsoft ASF Somebrowserimagefile.tif: mp3 file with ID3 2.0 tag
Как видите, команда file просто отображает имена файлов с сигнатурами, найденными в файле magic. Поскольку файл magic доведен до совершенства, вы можете видеть, что команда file довольно точна в определении сигнатур многих типов файла, даже если они не родные для системы Unix.
Как показано ниже, команда file может распознавать даже устройства Unix.
#file -s /dev/sda /dev/sda1: Linux/i386 ext2 filesystem /dev/sda2: x86 boot sector, extended partition table /dev/sda3: can"t read "/dev/sda3" (Device not configured). /dev/sda4: can"t read "/dev/sda4" (Device not configured). /dev/sda5: Linux/i386 ext2 filesystem
Повсюду в этой лекции, просматривая файлы с другими средствами просмотра, мы будет пользоваться командой file .
Hexdump
Hexdump — это инструмент просмотра файлов, работающий в таком режиме, который выполняет меньше всего интерпретации при представлении содержимого входного файла. В связи с такими функциональными возможностями, Hexdump является естественным и эффективным инструментом, который используется для определения типа файла и цели, для которой предназначено его содержимое. Кроме того, Hexdump поставляется вместе с популярными марками некоммерческих операционных систем Unix типа Linux и FreeBSD. А это значит, что Hexdump легко доступен, потому что исходный код этих операционных систем открыт.
Реализация
В своей самой простой форме, Hexdump используется следователем для того, чтобы читать содержимое файла и отображать его с «сырым» форматированием. При выполнении Hexdump в этом режиме указывается единственный параметр — имя входного файла. Например, набрав команду, показанную ниже, вы получите вывод файла с именем 1.tiff , продемонстрированный на следующей иллюстрации.
forensic# hexdump 1.tiff
Поскольку хорошо известно, что файл в формате TIFF (Tag Image File Format ) начинается с байтов 49 49 00 2A в шестнадцатеричной системе, то тип файла легко увидеть в этом выводе после небольшого визуального анализа. Если этот заголовок вам не известен, не волнуйтесь: большинство систем Unix включает файл, который содержит сигнатуры файлов, в каталоге /usr/share/magic. Выборка из файла magic показывает заголовок формата TIFF.
# Tag Image File Format, from Daniel Quinlan (quinlan@yggdrasil.com) # The second word of TIFF files is the TIFF version number, 42, which has # never changed. The TIFF specification recommends testing for it. 0 string MM\x00\x2a TIFF image data, big-endian 0 string II\x2a\x00 TIFF image data, little-endian
Команда file системы Unix использует эту информацию, чтобы определить неизвестный тип файла.
Вывод Hexdump , как показано на предыдущей иллюстрации, отформатирован так, что крайний левый столбец содержит смещение байта в пределах файла 1.tiff, в шестнадцатеричном коде. Байты входного файла отображены в строке после смещения. В этом примере, вы можете видеть, что третья строка содержит звездочку (*), что означает, что все строки, расположенные после последней отображенной, являются дубликатами.
В некоторых случаях, может быть удобным рассматривать вывод инструмента Hexdump в шестнадцатеричном формате и в формате ASCII одновременно. Программа Hexdump , поставляемая с FreeBSD, выполнит преобразование автоматически, если использовать ключ -C . Давайте посмотрим другой тип файла, используя этот ключ.
forensic# hexdump-C suspiciousfile.bin
Ниже показан соответствующий вывод.
Вы можете легко распознать, что этот файл содержит заголовок формата GIF, версии 89a, графический файл (и если вы не знали этого, то могли бы посмотреть файл magic). Однако если системы FreeBSD под рукой нет, чтобы можно было выполнить преобразование выходного формата, используя один ключ командной строки, напишите маленький файл форматирования, чтобы выполнить подобное преобразование. Это случается, когда в расследовании используется инструмент Hexdump системы Linux. Чтобы решить эту проблему, создайте следующий файл и назовите его hexdump. fmt .
"%12.12_ad" 16/1 "%02X" "\t" 16/1 "%_p" "\n"
Создав файл, вы можете использовать его вместе с Hexdump следующим образом.
forensic# hexdump-f hexdump.fmt suspiciousfile.bin
Распаковка нестандартно упакованных файлов
Безусловно, термин нестандарно упакованные файлы не удачен, но другого лучшего выражения не придумал, да и в общем то это не суть так важно. А суть в следующем — встречаются файлы, про которые точно знаешь, что они упакованы определенным архиватором, а распаковать их стандартным способом не можешь, или, например, распаковал, а в распакованном файле обнаруживаешь другие упакованные файлы, распаковать которые тоже обычным способом не получается.
Вот о распаковке таких файлов и хочу поделиться опытом с пользователями, которые с этим не знакомы. А чтобы бы понять саму идею распаковки таких файлов, сначала немного поэкспериментируем, а для проведения экспериментов упакуем/заархивируем произвольный простой файл, но сначала создадим его
$ echo ‘Т Е С Т’ > ~/test
Убедимся, что файл создан
$ cat ~/test
Т Е С Т
упакуем этот файл, например, архиватором gzip
$ gzip ~/test
и посмотрим на упакованный файл утилитой hexdump, точнее посмотрим 1-ые 16 байт
$ hexdump -C -n 16 ~/test.gz
00000000 1f 8b 08 08 9e 52 18 59 00 03 74 65 73 74 00 bb |. R.Y..test..|
Первые 3 байта — это так называемая сигнатура (HEX код) архиватора gzip — 1F 8B 08, которая является составной частью упакованного файла (его началом) и присуща только архиватору gzip, что позволяет отличить этот файл от других и, главное, видно, что архиватор, точнее сигнатура начинается с самого начала (с нулевого байта, смещение равно 0).
UPD — если быть точным, то сама сигнатура два байта (0x1f, 0x8b), а 3-ий байт определяет compression method (08 — deflate)
При распаковке этого файла, утилита gzip сначала проверит наличие сигнатуры, присущей gzip, и только после этого примет решение о распаковке.
Проверим это, а для чего изменим сигнатуру файла, точнее, изменим 1-ый байт — вместо 1F запишем 1E (я проделал это в hex редакторе)
$ hexdump -C -n 16 ~/test.gz
00000000 1e 8b 08 08 9e 52 18 59 00 03 74 65 73 74 00 bb |. R.Y..test..|
Ну и попытаемся рапаковать
$ gzip -d ~/test.gz
gzip: ~/test.gz: not in gzip format
И то же самое будет, если сигнатура будет правильная, но начинаться будет не с начала файла (смещение не равно 0) — вернем все на место, но перед сигнатурой запишем 1 байт — 00 (я сохранил этот файл, как test1.gz).
$ hexdump -C -n 16 ~/test1.gz
00000000 00 1f 8b 08 08 9e 52 18 59 00 03 74 65 73 74 00 |. R.Y..test.|
$ gzip -d ~/test1.gz
gzip: ~/test1.gz: not in gzip format
И значит распаковывать такие файлы нужно по-другому, а именно, нужно указать при распаковке смещение, откуда начинать, т.е. где начинается сигнатура.
Самый простой вариант — удалить байты до сигнатуры, но это не этично, да и иногда это выливается в мегабайты и десятки мегабайт.
Лучше поступить грамотно — указать утилите смещение, с которго начинать распаковку (делаем пропуск с помощью dd в 1 байт прежде чем начать распаковку)
$ dd if=~/test1.gz skip=1 bs=1 | gzip -d > test1
Проверим, что мы получили
$ cat ~/test1
Т Е С Т
То есть распаковали успешно и получили исходный файл.
И так на простом файле показал суть и сам принцип распаковки таких нестандартно упакованных файлов.
Но в жизни все сложнее, но когда понимаешь суть, то можно распаковать и более сложные файлы.
Попробуем сейчас опробовать наши знания на ядре Archlinux — пример неудачный, но полезный для обучения.
Справка — ядро, как правило, находится в сжатом виде, но, главное, сжатое ядро представляет собой загрузчик и распаковщик, за которым следует собственно сжатый алгоритмом zlib vmlinux, а потому сначала необходимо отделить сжатое ядро от загрузчика.
Сначала используя утилиты hexdump и file попробуем выяснить, что же это такое, наше ядро
# hexdump -C -n 16 /boot/vmlinuz-linux
00000000 4d 5a ea 07 00 c0 07 8c c8 8e d8 8e c0 8e d0 31 |MZ. 1|
Судя по сигнатуре 4d 5a (MZ) перед нами стандартный исполняемый формат (исполняемый DOS файл), сигнатура которого 4D 5A (MZ) составлена из инициалов одного из создателей MS-DOS Марка Збиковски.
$ file /boot/vmlinuz-linux
/boot/vmlinuz-linux: Linux kernel x86 boot executable bzImage, version 4.7.6-1-ARCH (builduser@tobias) #1 SMP PREEMPT Fri Sep 30 19:46, RO-rootFS, swap_dev 0x4, Normal VGA
И в итоге подтверждается сказанное выше, что сжатое ядро представляет собой загрузчик + распаковщик + само ядро сжатое алгоритмом zlib архиватора gzip с распаковкой в процессе загрузки.
Но нам, главное, понятно (по 1-ой части), чтобы распаковать ядро, нам нужно отделить сжатое ядро от загрузчика.
Как нам уже известно, gzip имеет сигнатуру 1f 8b 08 — вот и найдем его начало.
Перечислю способы, которыми можно это сделать.
1. Используя hex-редактор, например, bless — определяем, что 1f 8b 08 начинается с адреса 0х4501 или в 10 системе — 17665
UPD — делал и писал давно (обучал молодежь), так что число 17665 уже будет другое.
2. Используя утилиту od
od -A d -t x1 vmlinuz-linux | grep «1f 8b 08»
0017664 e0 1f 8b 08 00 00 00 00 00 02 03 ec 5a 7b 74 53
и получаем опять 17665
3. Очень хорошую утилиту binwalk
binwalk vmlinuz-linux
DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 Microsoft executable, portable (PE) 17665 0x4501 gzip compressed data, maximum compression, from Unix, NULL date (1970-01-01 00:00:00) . Как видим совпадает во всех случаях — 17665
Остается только извлечь из vmlinuz сжатое ядро и распаковать его:
dd if=vmlinuz-linux skip=17665 bs=1 | gzip -d > vmlinux
gzip: stdin: decompression OK, trailing garbage ignored
Желающие могут снова применить binwalk — binwalk vmlinux
и увидят уже названия файлов, правда вытащить их просто так уже не получится.
Вот и все.
binwalk также удобно использовать для определения архиватора, в случае если есть сомнения. Утилита включает большую базу сигнатур известных архиваторов. Но, разумеется, база базой, но лучше всегда перепроверить ручками, использую hex-редактор.
Ну и бонус на посошок любителям паролей — можно не вешать никакие пароли на сжимаемый файл, а просто ручками добавить в начало несколько байтов, но ЛУЧШЕ изменить сигнатуру и никто этот файл не распакует.
Конечно, эти изменения должны быть постоянны и легко запоминаемы.
Ошибки не исчезают с опытом — они просто умнеют