0

I realize we can dump equivalent assembly from C++ code using many debuggers and such.

But what about binary code? The formatting of bits in each byte(s) that make up the actual machine instructions, which (may) make up the microprograms(if the microarchitecture has one).

If each line of C++ code HAS to be converted to machine code in some way and at some point along the program (e.g. a float may be defined in C++, but has no use until pushed on the stack, so it may not convert 1:1 to all machine code, line-by-line, but will be used regardless), each statement, etc., can be traced. But debuggers don't output the formation of bits occupying each individual instruction(s).

If each program becomes formatted byte/bit pattern instructions for the CPU, it must be possible (I assume) to trace all the code you write to the actual bits on the circuit-level.

But for the fullest assurance possible, is it possible to do this to the extent I'm describing here? Modern debuggers/software do not offer this feature, and even the ones that do seem to not give the entire binary representation of each instruction clear to the developer.

PS: This is, of course, assuming the compiled-code is readily executable with instructions for the intended architecture (and not some interpreted language, or bytecode which needs another program to further translate for it).

bertieb
  • 7,543

2 Answers2

1

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.

luser droog
  • 413
1

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.

Darth Android
  • 38,658