I have seen it said that decompiling of obfuscated C# and Java is simplified by presence of calls to framework api, like to String. But, this doesn’t quite make sense to me because shouldn’t a C program also have obvious calls to some standard libraries, which would be equivalent of C# apis?
I have also seen it said that somehow the distinction between register machine (the hardware that will run assembly from C) and stack machine (virtual machine that will run bytecode) is important for complexity of decompilation.
So is stack/register machine issue the main one here? Let’s say if CLR virtual machine were reimplemented as register machine, would C# bytecode all of a sudden become just as hard to decompile as is C executable? Or are there some other major complexity differences that will not go away on such platform overhaul?
There is no difference between stack and register machines, it is relatively easy to deconstruct the expression trees from both representations.
.NET and JVM are so easy to decompile mainly because of the metadata: types and methods names, etc.
With a stripped native executable you’ll have all the fun: no meaningful names for the functions, no explicit data types, loads of the inlined (and then severely mutilated by the further optimisation) code, unrolled loops, irreducible control flow, unrolled tail calls, etc.
In a bytecode, most of this kind of optimisations have not been done (leaving them to the JIT), so it is much closer to an original source than it would have been with the metadata removed and optimisations applied. No matter, stack machine, register-based, threaded Forth code or whatever else.