4 ms·

What is your opinion on reversing highly optimized compiled high level code vs reversing manually written assembly code, starting from the resulting binary ? H

What is your opinion on reversing highly optimized compiled high level code vs reversing manually written assembly code, starting from the resulting binary ? Having comments and human readable symbols like variable and function names is sure nice though.

exDM69 13y ago
> What is your opinion on reversing highly optimized compiled high level code vs reversing manually written assembly code, starting from the resulting binary ? I don't want to do reverse-engineer either but I'd rather read the human written and compiled asm code. It's a little but not much better. I might read (and write) some assembly source code for fun, but I would not read the binaries so I'm going to stay away from this project.
techdragon 13y ago
"Having comments and human readable symbols like variable and function names is sure nice though." Yes, and unfortunately given how unforgiving hard it can be for many programers to really sink their teeth into anything of significance using just assembly, those niceties are pretty much whats needed for anything of this size to be a practical example. Reverse engineering tools are not the nicest place to learn new programming techniques. :-(
- delian66 13y ago
  Well, the source of the 32bit kernel is open, and anybody can study and learn from it: http://www.menuetos.org/M32.htm http://www.menuetos.org/M32.htm
comex 13y ago
In IDA, Menuet would probably be really easy to reverse engineer for a two main reasons: - Very, very little code. Everything is implemented in the most minimal way possible. This is extremely important - you can literally read through all the code in the kernel from top to bottom and be sure you haven't missed any functionality. Good luck doing that with some 1MB C program. - Almost no indirection. Few indirect jumps, almost no use of malloc (!). In IDA this makes it very easy to name functions and variables and easily see where they are used, which isn't possible for anything dynamically allocated, as in idiomatic C. This is to some degree IDA's fault: a smarter tool could do a decent job at automatically inferring the types signatures of C functions and provide similar functionality for struct fields, but IDA does not. However, it does make the problem more tractable in general. Note that reading the actual assembly, at a local level, is missing from that list. If anything, compiler generated assembly is probably easier to read, due to recognizable idioms, although there are exceptions such as repetitive code in inline functions or templates that would never be written by a human. (The fun thing is, with a decompiler you can actually read the code in question as C.)

exDM69 13y ago

> What is your opinion on reversing highly optimized compiled high level code vs reversing manually written assembly code, starting from the resulting binary ? I don't want to do reverse-engineer either but I'd rather read the human written and compiled asm code. It's a little but not much better. I might read (and write) some assembly source code for fun, but I would not read the binaries so I'm going to stay away from this project.

techdragon 13y ago

"Having comments and human readable symbols like variable and function names is sure nice though." Yes, and unfortunately given how unforgiving hard it can be for many programers to really sink their teeth into anything of significance using just assembly, those niceties are pretty much whats needed for anything of this size to be a practical example. Reverse engineering tools are not the nicest place to learn new programming techniques. :-(

delian66 13y ago
Well, the source of the 32bit kernel is open, and anybody can study and learn from it: http://www.menuetos.org/M32.htm http://www.menuetos.org/M32.htm

comex 13y ago

In IDA, Menuet would probably be really easy to reverse engineer for a two main reasons: - Very, very little code. Everything is implemented in the most minimal way possible. This is extremely important - you can literally read through all the code in the kernel from top to bottom and be sure you haven't missed any functionality. Good luck doing that with some 1MB C program. - Almost no indirection. Few indirect jumps, almost no use of malloc (!). In IDA this makes it very easy to name functions and variables and easily see where they are used, which isn't possible for anything dynamically allocated, as in idiomatic C. This is to some degree IDA's fault: a smarter tool could do a decent job at automatically inferring the types signatures of C functions and provide similar functionality for struct fields, but IDA does not. However, it does make the problem more tractable in general. Note that reading the actual assembly, at a local level, is missing from that list. If anything, compiler generated assembly is probably easier to read, due to recognizable idioms, although there are exceptions such as repetitive code in inline functions or templates that would never be written by a human. (The fun thing is, with a decompiler you can actually read the code in question as C.)