Я вижу буквы на странице, буква а, это может быть много разных слов, буква после нее — н. Это может быть и, ответ, любое количество слов, так что я продолжаю.
Так работал x86 и другой машинный код той эпохи, в частности, наборы инструкций, из которых он был непосредственно получен.
Во-первых, и это самое главное, если вы просто возьмете все байты программы и прыгнете в середину, это не будет иметь никакого смысла, очень легко встать не с той ноги. " что это такое? Процессор запускается и продолжает работу на основе правил набора инструкций, процессор довольно глуп, он следует правилам, определенным или, по крайней мере, задокументированным в руководствах по процессору. Пока программист и инструменты создали правильно построенную программу, она не потеряется, если это произойдет, это вина программиста/инструментов, а не процессора. Процессор начнет декодировать байт кода операции как байт кода операции. Этот байт может быть целой инструкцией или просто частью, зависящей от конкретного байта. Если дробь, то первый байт плюс следующий за ним байт могут определять всю инструкцию или быть дробью.
CISC, в частности, сами коды операций и частично следующие байты могут содержать или не содержать биты, которые означают что-то важное. В RISC, таких как mips, arm или другие, 0000 в конкретном Please означает регистр 0, 0001 означает регистр 1 и так далее. Но в некоторых, если не во многих инструкциях CISC, нет ничего, что отличало бы регистр x от регистра y, регистр a от регистра b. Весь код операции нужно было просмотреть в таблице, чтобы понять, что он означает.
x86 - это набор инструкций переменной длины, некоторые инструкции состоят из одного байта, без других операндов, другим требуется больше байтов, чем, возможно, сразу после этого. Хотите переместить непосредственное значение 0x12345678 в регистр EAX, не глядя ни на какую документацию, в которой говорится, что это либо 5-, либо 6-байтовая инструкция, либо код операции, который говорит, что загружать немедленно в ax, либо байт, который говорит, что загружать немедленно, и другой байт, который говорит это топор, то четыре байта непосредственного.
mov eax,0x12345678
mov ebx,0x12345678
mov ecx,0x12345678
mov edx,0x12345678
Disassembly of section .text:
00000000 <.text>:
0: b8 78 56 34 12 mov eax,0x12345678
5: bb 78 56 34 12 mov ebx,0x12345678
a: b9 78 56 34 12 mov ecx,0x12345678
f: ba 78 56 34 12 mov edx,0x12345678
получается 5 байт. Хотя возможно, что биты этих байтов могут быть декодированы непосредственно в один из четырех регистров, это маловероятно, поскольку эти наборы инструкций были разработаны иначе.
Возможно, вы слишком усложняете это, и, к сожалению, Intel и другие документы по x86 не так хороши, как у некоторых других поставщиков. Но на самом деле это просто блок-схема, довольно легко декодируемая, первый байт сообщает вам, ищете ли вы другой байт или нет по его определению, следующий байт указывает, нужно ли вам искать дальше и так далее. Вы не декодируете x86, как вы декодируете mips или arm или другие, которые разработаны по-другому. Все они имеют декодирование, в котором говорится: посмотрите на эти биты и определите инструкцию или определите, нужно ли мне больше битов, но x86 делает это одним способом, mips — другим, arm — другим. У каждого есть свои плюсы и минусы.
CISC, как и x86, хотя и является скорее блок-схемой, первый байт говорит вам перейти на страницу X, на которой либо есть полный ответ, либо он говорит, что нужно получить следующий байт, и на его основе перейти на страницу Y в приложении X.
В некоторых домах есть один жилец, адрес/местоположение приводит вас к одному человеку. У некоторых их несколько, и как только вы доберетесь до дома по адресу, вам понадобится дополнительная информация, чтобы определить, какой человек или домашнее животное вас интересует. Первая часть информации, почтовый адрес, соответствует стандарту, но информация для изоляции человека/животного в этом доме соответствует стандарту для этого дома. Первый байт инструкции — это код операции. Но на основе кода операции, если есть дополнительные байты, то эти байты зависят от кода операции, как мы видели выше. b8 78 56 34 12 для 0xB8 второй байт является частью непосредственного значения. Есть много, вы можете посмотреть, где второй байт является дальнейшей расшифровкой инструкции.
mov eax,eax
mov eax,ebx
mov eax,ecx
mov eax,edx
0: 89 c0 mov eax,eax
2: 89 d8 mov eax,ebx
4: 89 c8 mov eax,ecx
6: 89 d0 mov eax,edx
для кода операции 0x89 второй байт в этих случаях не является данными, но определяет инструкцию.
Это правда, что декодирование второго байта не является уникальным только для этого кода операции, многие инструкции будут использовать одно и то же декодирование этих битов, например, для определения ah, al, ax, eax, bh, bl, bx... и т. д. И это задокументировано в документации Intel, а также в бесчисленном количестве других книг и веб-сайтов.
Настоящей документацией является исходный код самого чипа, так как мы редко имеем к нему доступ, мы получаем документацию, которая обычно пишется не автором логики, а потом может быть отшлифована техническим писателем, на каждом шаге может быть какая-то информация. быть потеряны или оставлены в замешательстве. Некоторые поставщики лучше других, некоторые версии их документации лучше других.
x86 — это в значительной степени последний набор инструкций, который вы хотите изучить, наличие одного не является уважительной причиной, для каждого x86, который у вас есть, внутри этой коробки есть много процессоров, отличных от x86, плюс на каждый x86, который у вас есть, у вас есть довольно много , десятки устройств, отличных от x86. И если целью является образование и обучение, вы все равно хотите начать с симулятора, который значительно повысит ваши шансы на успех, а аварии не так болезненны. Для начала есть гораздо лучшие наборы инструкций, такие как msp430 и pdp11, что явно повлияло на него. рука, большой палец, позже углубившись в мипс и его нюансы, то из 8 бит я бы не начал с х86 я бы пошел с чем-то еще 6502 или другими. Тогда, может быть, если любопытно, 8088/8086 с использованием эмулятора и старых документов в Интернете на обратном пути, то, наконец, x86, как в 80386, 80486 и x86-64. Погружение в x86-64 сначала должно быть связано с болью, действительно для людей, злоупотребляющих собой. Если вы все еще чувствуете, что вам нужно это сделать, менее болезненный путь этого болезненного пути - начать с 8088/8086, используя старые руководства и dosbox или bochs или ряд других эмуляторов. Как только вы получите основу, то, что они добавили на шаге к 32-битной, а затем 64-битной версии, может иметь больше смысла, и вас не должно смущать огромное количество защиты, добавляемой с течением времени, вы можете начать с чистого листа.
Дизассемблирование наборов инструкций переменной длины — это огромная проблема, которую нужно решить, и никто не решил ее, потому что они не могут полностью. Невозможно. Раньше я изучал все новые наборы инструкций, начиная с дизассемблера. В эти дни я, вероятно, вместо этого сделал бы симулятор. Единственный способ иметь хотя бы половину шанса на успех — начать с действующей точки входа. И декодировать в порядке выполнения, а не линейно через бинарник. Это только раскроет часть кода. Остальное, если оно есть, основано на данных, и вы можете попытаться подражать, но это тоже не будет идеальным. Во-первых, данные во время дизассемблирования могут измениться во время выполнения. Вы даже можете эмулировать программу и запускать ее в течение нескольких дней/недель, чтобы обнаружить различные значения данных в разных местах, на которые смотрит конкретная инструкция, и все еще не знать всех возможностей. Так что некоторые дизассемблеры просто ошибаются, но показывают это вам так, как будто это правильно, а другие правильно, просто говорят, что я не знаю, что это такое...
сегодня подавляющее большинство двоичных файлов скомпилировано, поэтому пути данных в основном в порядке и полны. Но возьми немного ромов со времен стендап-видеоигр, например, астероиды. вы увидите что-то похожее на этот псевдокод:
a = 0
if(a == 0) goto somewhere
b = 7
мы можем легко увидеть, что условный переход на самом деле является безусловным, дизассемблирование нам нужно было бы рассматривать инструкцию после условного перехода как возможный путь выполнения. Но то, что вы обнаружите в этом роме, это то, что следующая инструкция является фактическими данными, а не инструкцией. 1 представляет байт кода операции 2 и 3 представляют дополнительные байты для этой инструкции, больше псевдокода
1 a = 0;
2
1 if(a == 0) goto somewhere
2
3
1 b = 7.
2
3
1
2
3
Но когда мы продолжаем декодировать все предположительно допустимые пути выполнения, мы обнаруживаем, что
1 b = 7.
2
3 <--- is a branch destination
1
2
3
это байт кода операции, а не последние байты в инструкции, так что теперь есть конфликт, и хороший дизассемблер скажет вам об этом. Затем человек должен изучить эти пути, чтобы определить, какой из них был действительным: путь a = 0.... или путь b = 7. Предполагая, что a = 0, а последующая условная ветвь была частью действительного дизассемблирования, тогда может показаться, что это действительно безусловная ветвь, и есть пара байтов данных или заполнение или что-то еще, а затем следует какой-то код. Это могло быть преднамеренным, как это было более распространено в то время, чтобы намеренно сбросить дизассемблер, или это могло быть результатом ручного взлома бинарного файла, а не пересборки всего проекта и записи ромов. (прочитайте, я думаю, что это был Defender, взламывавший двоичный файл в гостиничном номере в ночь перед выставкой, а затем на следующий день). Эти байты могли быть другими инструкциями, которые были изменены вручную, чтобы обойти ошибку. 6502 является хорошей отправной точкой, и в некоторых игровых ромах, если вы хотите написать дизассемблер, не так много инструкций, как, скажем, в z80 или 8088/8086, которые с помощью вторых байтов умножили первоначальный потенциал 256 инструкций на более длинный. список. Ранний PIC или msp430 был бы намного проще в качестве первого дизассемблера, поскольку у них всего дюжина или две инструкции. Msp430 имеет отлаженный/поддерживаемый бэкэнд gnu (llvm не отлаживается и не поддерживается, поэтому избегайте его), так что вам будет легко получить доступ к инструментам, если вас интересуют наборы инструкций для изучения.
Когда у вас есть фиксированная длина инструкции, такая как mips, когда 16-битная не используется, или активация, когда 16-битный большой палец не используется. (И в наборе инструкций сказано, что инструкции должны быть выровнены (не risc-v)) Вы можете линейно дизассемблировать через память, некоторые из «инструкций», которые вы найдете, не имеют смысла или не определены, но вы просто перемалываете, человек позже увидит их как данные, а не инструкции, но те, которые являются инструкциями, будут иметь смысл. К сожалению, mips и arm имеют вторичные наборы инструкций, которые декодируются совершенно по-разному и имеют разные правила, поэтому вы также не можете просто дизассемблировать двоичный файл arm, для чего-то, сгенерированного компилятором сегодня, вам также нужно делать это в порядке выполнения, у вас гораздо больше шансов получить большая часть инструкций декодирована, но будут некоторые таблицы переходов, которые сведут на нет все ваши усилия, оставив куски кода неразборчивыми должным образом.
Итак, хотя и многословный, краткий ответ — доверяйте дизассемблеру настолько, насколько вы можете его бросить. И инструкции довольно легко расшифровать, если перейти в порядке выполнения от заведомо верной точки входа и посмотреть документацию на процессор.
person
old_timer
schedule
25.12.2018
FF /6push r/m64в качестве примера. Расшифровка инструкций OpCode x86 является еще одним дубликатом. Все это я нашел в гугле наsite:stackoverflow.com x86-64 register/opcode field- person Peter Cordes schedule 25.12.2018