Я понимаю, что мы можем выгрузить эквивалентную сборку из кода C ++, используя много отладчиков и тому подобное.
Но как насчет двоичного кода? Форматирование битов в каждом байте (ях), которые составляют фактические машинные инструкции, которые (могут) составлять микропрограммы (если микроархитектура имеет один).
Если каждая строка кода C ++ ДОЛЖНА быть каким-то образом преобразована в машинный код и в какой-то момент в программе (например, плавающий элемент может быть определен в C ++, но он бесполезен, пока не помещен в стек, поэтому он может не преобразовывать 1: 1 для всего машинного кода, построчно, но будет использоваться независимо), каждый оператор и т. Д. Можно отследить. Но отладчики не выводят формирование битов, занимающих каждую отдельную инструкцию (и).
Если каждая программа становится отформатированной инструкцией для байтов / битовых комбинаций для CPU, должна быть возможность (я полагаю) отследить весь код, который вы пишете, до фактических битов на уровне схемы.
Но для полной гарантии, возможно ли сделать это в той степени, в которой я здесь описываю? Современные отладчики / программное обеспечение не предлагают эту функцию, и даже те, которые, по-видимому, не дают ясного для разработчика полного двоичного представления каждой инструкции.
PS: Это, конечно, предполагается, что скомпилированный код легко выполняется с инструкциями для предполагаемой архитектуры (а не с каким-то интерпретируемым языком или байт-кодом, который нуждается в другой программе для дальнейшего перевода для него).
You can use a disassembler to convert compiled binary code back to assembly language. That would allow you to "read" (with difficulty) software distributed only in binary.
For the other part of your question, you seem to want some sort of hardware decompiler which gives more detailed information about how the cpu executes a particular binary instruction. I don't know of any tool to do this. You'll probably have to read the hardware manuals and do this sort of analysis in your head.
No.
Well, maybe, but there's no guarantee because the code that goes into the compiler is rarely the same as the code that comes out for two reasons: humans are terrible at writing efficient code, and humans don't think about code in the same way that a CPU needs to process it in. Because of this, compilers will optimize source code before converting it to assembly/binary. This can lead to statements being reordered, useless statements being removed, and entire functions being inlined.
For example, given the following pseudocode:
int x = 3; x = 3*3; x = 4; function mult4(number) { return number * 4; } x = mult4(x); can be completely reduced to
int x = 16; by a good optimizing compiler, which doesn't correspond at all to the source. This is why when debugging, you often have to disable compiler optimizations. With all compiler optimizations disabled, the compiler will try to output assembly that matches the source code 1-for-1.