One of the unfortunate parts about Menuet OS is that the source is closed and only Ville M. Turjanmaa has the source! It can never grow beyond his hobby.
I agree that it will be better if everything was open, but in the case of MenuetOS, I do not think it is so important ... the OS itself is written in assembler, so the mapping between the final result in the binary of the OS, and its source is probably close to 1:1 .
> the OS itself is written in assembler, so the mapping between the final result in the binary of the OS, and its source is probably close to 1:1
Since Assembly code is pretty much unreadable, human-written Assembly source code tends to be 50-90% comments. Some OS related programming tasks are very handy to write with Assembler macros, that wouldn't be visible in the binary. In addition to the comments, the binaries might not contain variable names, function names and other useful information.
Hell, even white space is important in Assembly sources! Those empty lines that separate a logical block of instructions or beginning and end of a loop, for example.
The source code to a computer program written in Assembly is as important as source code in languages written in any other language. Binary blobs are not (effectively) readable by humans.
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.
> 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.
"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. :-(
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.)
Well, there is another open source x86 assembly OS called KolibriOS and it was forked from Menuet OS back in 2004.
It's not 64bit, but it does pretty much the same job.
I tried Kolibri a couple of years ago while distro hopping, but I completely forgot that is was a fork of Menuet, so when I saw the above comment regarding closed source I looked on the KolibriOS site, and when I got back here I noticed your comment had beat me to it by a mile!
One of the unfortunate parts about Menuet OS is that the source is closed and only Ville M. Turjanmaa has the source! It can never grow beyond his hobby.
There is some source opened, for the applications and drivers: http://www.menuetos.net/64bit.htm
2 points:
1st. This is an excellent example of the level of size optimisation available to programers working directly with assembly code.
2nd. Not being completely open source hampers its use as a teaching tool re: assembly programming.
I agree that it will be better if everything was open, but in the case of MenuetOS, I do not think it is so important ... the OS itself is written in assembler, so the mapping between the final result in the binary of the OS, and its source is probably close to 1:1 .
> the OS itself is written in assembler, so the mapping between the final result in the binary of the OS, and its source is probably close to 1:1
Since Assembly code is pretty much unreadable, human-written Assembly source code tends to be 50-90% comments. Some OS related programming tasks are very handy to write with Assembler macros, that wouldn't be visible in the binary. In addition to the comments, the binaries might not contain variable names, function names and other useful information.
Hell, even white space is important in Assembly sources! Those empty lines that separate a logical block of instructions or beginning and end of a loop, for example.
The source code to a computer program written in Assembly is as important as source code in languages written in any other language. Binary blobs are not (effectively) readable by humans.
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.
> 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.
"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. :-(
Well, the source of the 32bit kernel is open, and anybody can study and learn from it: http://www.menuetos.org/M32.htm
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.)
Apart from the issues brought up by others: did you read the license? http://www.menuetos.net/m64l.txt states:
"Redistribution, reverse engineering, disassembly or decompilation prohibited without permission from the copyright holders."
Yes, I read the license ... in fact I read both of them ...
The license that you pointed, is for the 64bit version.
However the MenuetOS 0.85C, for which the news item is about, is the 32bit version, and it is licensed under the GPL: http://www.menuetos.org/M32.htm
Well, there is another open source x86 assembly OS called KolibriOS and it was forked from Menuet OS back in 2004. It's not 64bit, but it does pretty much the same job.
https://en.wikipedia.org/wiki/KolibriOS
There is an open source (GPLv2) fork called KolibriOS [1].
[1] - http://kolibrios.org/en/
I tried Kolibri a couple of years ago while distro hopping, but I completely forgot that is was a fork of Menuet, so when I saw the above comment regarding closed source I looked on the KolibriOS site, and when I got back here I noticed your comment had beat me to it by a mile!
Haha! Cheers!