Я пытаюсь создать редактор заголовков в формате ELF. При разработке я заметил, что в бинарных группах по два байта всегда инвертированы.
Вот, например, шестнадцатеричный дамп (для справки я назову его шестнадцатеричным дампом).
[email protected]:~/Documents/ElfEditor$ hexdump Test | head 0000000 457f 464c 0102 0001 0000 0000 0000 0000 0000010 0003 003e 0001 0000 07a0 0000 0000 0000 0000020 0040 0000 0000 0000 2758 0000 0000 0000 0000030 0000 0000 0040 0038 0009 0040 0022 0021 0000040 0006 0000 0004 0000 0040 0000 0000 0000 0000050 0040 0000 0000 0000 0040 0000 0000 0000 0000060 01f8 0000 0000 0000 01f8 0000 0000 0000 0000070 0008 0000 0000 0000 0003 0000 0004 0000 0000080 0238 0000 0000 0000 0238 0000 0000 0000 0000090 0238 0000 0000 0000 001c 0000 0000 0000
Например, в первых 4 байтах я ожидал 7f45 4c46, а не 457f 464c.
Когда я запускаю шестнадцатеричный дамп с аргументом -C, я получаю дамп так, как я ожидал. (Я назову этот hexdump как hexdump2 для справки).
00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF…………| 00000010 03 00 3e 00 01 00 00 00 a0 07 00 00 00 00 00 00 |..>………….| 00000020 40 00 00 00 00 00 00 00 58 27 00 00 00 00 00 00 |@…….X’……| 00000030 00 00 00 00 40 00 38 00 09 00 40 00 22 00 21 00 |[email protected]@.».!.| 00000040 06 00 00 00 04 00 00 00 40 00 00 00 00 00 00 00 |[email protected]| 00000050 40 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 |@[email protected]| 00000060 f8 01 00 00 00 00 00 00 f8 01 00 00 00 00 00 00 |…………….| 00000070 08 00 00 00 00 00 00 00 03 00 00 00 04 00 00 00 |…………….| 00000080 38 02 00 00 00 00 00 00 38 02 00 00 00 00 00 00 |8…….8…….| 00000090 38 02 00 00 00 00 00 00 1c 00 00 00 00 00 00 00 |8……………|
Бинарный файл сохраняется как hexdump1, что затрудняет его чтение в C.
Еще немного дополнительной информации. Это не проблема с порядком байтов, потому что связанные данные, например целые числа, верны в формате с прямым порядком байтов в hexdump2 и неверны в hexdump1. Например, в байте смещения 0x14 начинается 32-битное Int (значение 1), в hexdump2 он правильно представлен байтами 01 00 00 00, а в hexdump1 он неверен (байты 00 01 00 00).
Итак, мои сомнения:
- Это нормально?
- Почему так происходит?
- Так происходит во всех дистрибутивах и архитектурах Linux?
- Могу ли я просто инвертировать байты во всем файле (включая остальную часть двоичного файла)?
- Есть ли простой или правильный способ исправить порядок байтов?
Я хотел бы сделать мою программу гибкой для работы в любом дистрибутиве или архитектуре Linux. Спасибо за помощь заранее.
Аппаратное обеспечение с прямым порядком байтов? Endianness См. Исполняемый и связываемый форматы — person Henry schedule 02.07.2020
Оба шестнадцатеричных дампа верны, потому что 7F 45 действительно является представлением 457F с прямым порядком байтов. Просто в первом дампе данные отображаются как 16-битные значения, тогда как во втором дампе данные отображаются побайтно. — person Henry schedule 02.07.2020
Спасибо за ответы. Когда я читаю двоичный файл на C, я тоже получаю байты, как и в hexdump1. Он тоже читает 16-битные куски (почему 16 бит, а не другое значение)? Первые 16 байтов в файле должны быть массивом беззнаковых символов. Разве массив char не должен оставаться в порядке независимо от порядка байтов? — person Henry schedule 02.07.2020
Источник: