5 ms·

Although in this case, the object code may have been deliberately obscured. On reflection, I can't help wondering how much of the seemingly pointless diddling

by rst 16y ago

Although in this case, the object code may have been deliberately obscured. On reflection, I can't help wondering how much of the seemingly pointless diddling of local variables is the result of turning a naive decompiler on a bytestream where the actual instructions are somehow encrypted or masked.

viraptor 16y ago
I really don't think so. The decompilation result is genuinely silly. For example look at: if (*(int*)(local2 + global0) == 0x4550) { local5 = *(unsigned short*)(local2 + global0 + 20); Either local2 or global0 are pointers to a structure. Neither is detected. Most sensible decompilers would change the names and just make it `local5 = global0[local2].blah` instead. Advanced decompilers also can avoid gotos in almost any case. It also uses function calls without parameters or output, assuming some stack layout probably. It's a really really bad output, not a result of obscured compilation.
- DCoder 16y ago
  I've seen HexRays do the same thing - most of the time you need to actually tell it that a variable is a pointer before it tries to do that. Stating the function type explicitly also helps it display the right arguments given to it. This output could be significantly improved if the assembly version were available as well.
- updog 16y ago
  This came from one of the better known commercial decompilers. Which ones do you consider 'advanced'?
  - viraptor 16y ago
    Pointed out before: http://news.ycombinator.com/item?id=2214052 http://news.ycombinator.com/item?id=2214052 - this is from boomerang - not a known commercial decompiler really.
- NateLawson 16y ago
  Hex-rays is much much better than this. You'll have to see the actual output to understand, but at least here are some examples. It does not do such a bad job with type identification, although it certainly isn't perfect. http://www.hex-rays.com/hexcomp11.shtml http://www.hex-rays.com/hexcomp11.shtml
sp332 16y ago
You could compile the decompiled code with an optimizing compiler, then decompile that, or use GCC's C backend, or something to automatically simplify the program?
- mukyu 16y ago
  No. There is just too much information lost going from source to binary and when you use optimization the results are more information lost, not less. The idea works well enough if you just want get optimized asm though. http://events.ccc.de/congress/2010/Fahrplan/events/4096.en.html http://events.ccc.de/congress/2010/Fahrplan/events/4096.en.h...
bigmac 16y ago
Stuxnet didn't really do anything to actively thwart reverse engineering. See here: http://rdist.root.org/2011/01/17/stuxnet-is-embarrassing-not-amazing/ http://rdist.root.org/2011/01/17/stuxnet-is-embarrassing-not... Truly obfuscated code will just plain cause the Hex-Rays decompiler to crash, producing absolutely no output at all.
- NateLawson 16y ago
  I don't think it would necessarily crash, unless you intentionally wrote code to target a specific bug in Hex-rays itself. You can certainly get Hex-rays to output confusing information on purpose without actually targeting it. If this was obfuscated, you'd expect that would be much more likely.

by rst 16y ago

viraptor 16y ago

I really don't think so. The decompilation result is genuinely silly. For example look at: if (*(int*)(local2 + global0) == 0x4550) { local5 = *(unsigned short*)(local2 + global0 + 20); Either local2 or global0 are pointers to a structure. Neither is detected. Most sensible decompilers would change the names and just make it `local5 = global0[local2].blah` instead. Advanced decompilers also can avoid gotos in almost any case. It also uses function calls without parameters or output, assuming some stack layout probably. It's a really really bad output, not a result of obscured compilation.

DCoder 16y ago
I've seen HexRays do the same thing - most of the time you need to actually tell it that a variable is a pointer before it tries to do that. Stating the function type explicitly also helps it display the right arguments given to it. This output could be significantly improved if the assembly version were available as well.
updog 16y ago
This came from one of the better known commercial decompilers. Which ones do you consider 'advanced'?
- viraptor 16y ago
  Pointed out before: http://news.ycombinator.com/item?id=2214052 http://news.ycombinator.com/item?id=2214052 - this is from boomerang - not a known commercial decompiler really.
NateLawson 16y ago
Hex-rays is much much better than this. You'll have to see the actual output to understand, but at least here are some examples. It does not do such a bad job with type identification, although it certainly isn't perfect. http://www.hex-rays.com/hexcomp11.shtml http://www.hex-rays.com/hexcomp11.shtml

sp332 16y ago

You could compile the decompiled code with an optimizing compiler, then decompile that, or use GCC's C backend, or something to automatically simplify the program?

mukyu 16y ago
No. There is just too much information lost going from source to binary and when you use optimization the results are more information lost, not less. The idea works well enough if you just want get optimized asm though. http://events.ccc.de/congress/2010/Fahrplan/events/4096.en.html http://events.ccc.de/congress/2010/Fahrplan/events/4096.en.h...

bigmac 16y ago

Stuxnet didn't really do anything to actively thwart reverse engineering. See here: http://rdist.root.org/2011/01/17/stuxnet-is-embarrassing-not-amazing/ http://rdist.root.org/2011/01/17/stuxnet-is-embarrassing-not... Truly obfuscated code will just plain cause the Hex-Rays decompiler to crash, producing absolutely no output at all.

NateLawson 16y ago
I don't think it would necessarily crash, unless you intentionally wrote code to target a specific bug in Hex-rays itself. You can certainly get Hex-rays to output confusing information on purpose without actually targeting it. If this was obfuscated, you'd expect that would be much more likely.