Menuet OS?

Has anyone tryout this OS?
It fits on a single floppy!
hxxp://www.menuetos.org/

MenuetOS is a hobby Operating System for the PC written entirely in 32bit assembly language, and released under the GPL. It supports 32 bit x86 assembly programming since this allows for smaller, faster and less resource hungry applications to be created.

Hi,
Yeah I have seen it before. You see I was interested in OS coding a while back. Now I am not much interested but may continue soon. I have also coded my own OS. It is not GUI or anything. It is 32-bit has a command line interface, has a minimal FDD driver and a FAT12 driver. It can read and display the contents of a text file in the FDD. It doesn't even need a whople floppy. The whole kernel is ~ 10kB. You can see it at http://www.tomasm.tk/
See the OSDev page. I have also made a 16-bit OS that fits into the bootsector of a floppy i.e 512 bytes

Thomas

Just wondering, is there any significance of such OS on PC platform apart from Hobby.

Don't take me wrong, I am just curious to know any application. mobile platform is is definately not the area since it written using PC/x86 assembly

Visu

[nikola]

I didnt check this out but i remember when there was a copy of QNX on one floppy and it was a good one Had GUI, couple of games and even possibility to connect to internet. Browser too of course

Thomas, i just checked out your site. Is information you put up there correct? Born in 1989? If so you are one fucking crazy kid, and you are killing my will to learn cracking
"I wrote my first OS when i was 15" sheesh

Hi,
BTW I am 15 . About the question by visu, basically such OSes are a help to those coding their own OSes. As to coding OSes, I do it as a hobby and to understand my system more. It helps me to program better. Once you code an OS you find it difficult to blame the poor guys at MS when windows crashes. Right now I am not coding an OS as my interest keeps fluctuating. You see I actually learned programming only because of cracking!! Because you asked I will bore you with some history . About 3 years ago I got a shareware game that I liked very much. Just when I was really getting a hang of it... BOOM You have to reigster this blah blah.... I went mad Opened upthe EXE in Wordpad and saw some rubbish. I searched the net for cracking (I had heard about this word somewhere ). I found a tutorial about cracking with the then version of Hackman Hex Editor . It was written by a guy named Sparkle. I did patching all right. It was when I got really into it when I couldn't figure out what were PUSHes and POPs and REPNZ SCASB were. I wandered around code in SoftICE for a year .Then I looked up Win32asm tutorials and learned it. Then I lost interest in cracking and started programming in win32asm. After two years years I am all okay with programming but not so okay with cracking or reversing. I also coded the OS. Now I begin to lose interest in it and come back to cracking mainly because of another game I found loked with Softwrap. Well you see where I am now. Hope I was not boasting . Thanx if you read thru this long post. Hope The old man doesn't remove it for being off topic

Thomas

[JMI]

Which "old man" might that be????

Regards,

[aldente]

Originally Posted by JMI

Which "old man" might that be????

Age: 59

I have no idea

[JMI]

Good gracious. I didn't realize he was that old.

Why that's even before there was an internet or personal computers or even software to reverse. Imagine a world with no cell phones or TV or that one had to travel to Europe or Asia by boat because that was the only way to get there.

Regards,

[nikola]

JMI, you should probably ban Thomas. We are bad influence on minors. I think they'll double whatever punishment is for cracking, for getting kids hooked on to this

[JMI]

Hey, it is not as bad for you as most other "addictions" and it is benificial in that it exercises the mind and teaches you how to think about "problem solving" and how to apply determination to accomplish a goal one has set for oneself. Both things are good for the brain and for solving other "real life" problems later on.

Not enough people spend enough time trying to learn how to actually "think" about things going on in the world around them because they are often too busy trying to simply "experience" that they see happening around them or that they see others doing in movies or on TV or perhaps they are simply too busy trying to survive in an often cruel and unforgiving world.

Just don't forget that there is also a wide world out there to study and learn about and spending too much time playing on the computer does detract from social interactions with the rest of humanity, another skill set that is necessary for a productive and happy life.

Regards,

[taos]

Originally Posted by JMI

Hey, it is not as bad for you as most other "addictions" and it is benificial in that it exercises the mind and teaches you how to think about "problem solving" and how to apply determination...

CAN YOU EXPLAIN THIS TO MY WIFE?...
Regards.

Originally Posted by nikola

JMI, you should probably ban Thomas. We are bad influence on minors. I think they'll double whatever punishment is for cracking, for getting kids hooked on to this

Hmm,
My membership here seems to rest on slippery grounds.. BTW JMI didn't teach me cracking so he can't be held responsible...

Thomas

[JMI]

taos:

Rule One of Relationships: You can NOT explain to a "significant other" why you might prefer to spend more time sitting in font of a computer screen taking software apart than you do paying attention to "them." And if you do spend more time stairing at the screen, it strongly suggests that there is already something amiss in the relationship. Life IS more important than reversing.... but not much.

Thomas:

Rule One of Responsibility: Being held "responsible" often has nothing at all to do with what one has actually done. Someone nearly always gets the "blame". Sometimes whether they deserve it or not.

And I don't believe anyone can truely be "taught" reversing. They can be helped along the way, but it is a skill set which needs to be "learned" by doing the work, reaching an impass, reading more and/or asking a few questions and trying again. One can always impliment solutions others have provided to a particular problem, but there is no true "learning" without understanding what one has just done and why those particular steps worked in the particular circumstance.

One of the interesting things about reversing is that it is, essentially, a never ending contest between the protectionists and the reversers. People spend time and effort to constantly make new challenges for the other side and adopt their techniques and strategies.

However, one fundimental observation I've come to over the many years is that if you can prevent attempts to screw with your debugger and can throw enough time at the disassembly, most problems (except probably REALLY GOOD encryption) can be solved eventually. Many protections depend upon the likelyhood that one is not really that stuborn or the project simply isn't that interesting to be allocated sufficient time to overcome the challenges. Of course the very concept of being willing to spend the time it takes violates "Rule One of Relationships". Fortunately, most of the time, no one forces us to reverse engineer.

Regards,

Originally Posted by JMI

And I don't believe anyone can truely be "taught" reversing. They can be helped along the way, but it is a skill set which needs to be "learned" by doing the work, reaching an impass, reading more and/or asking a few questions and trying again. One can always impliment solutions others have provided to a particular problem, but there is no true "learning" without understanding what one has just done and why those particular steps worked in the particular circumstance.

Hi,
I learnt that rule the hard way . I don't know how many tutorials I read . But all of them say something like... Press F7 or something until you reach so and so code and voila you find the reg code in foobar register. . Thats when I became determined to learn win32asm and UNDERSTAND what is going on. I nowadays understand most of what I am tracing through. But in the realm of packers and protectors I usually lose track of what is going on in the sh*tload of Exceptions, junk code etc. To be honest,I have NEVER understood what has happened in the unpacking code of any packer I have unpacked except for the PUSHAD,POPAD and the final JMP or RETN or CALL to the OEP. Maybe this is why I find it difficult to understand simple topics like Unpacking SoftWrap. . I don't know why but in Win98SE I am using, Olly always dies of an Exception when I press Run before reaching any of the part mentioned in the tutorial : . confused: I guess I will have to use XP or 2k

Thomas

[JMI]

Thomas:

One interesting simple fact of reversing I learned the hard way, about five years before you were born , is that packed and/or encrypted code will (fortunately) not run on a computer. At the time I was working on PACE protection on music software written for the MAC. The code on the disk, was checked to "validate" the software each time it was started. That code was encrypted and, just starting out in reversing, I had no clue what assembly language was or did.

Fortunately, I had a debugger which would at least allow me to "watch" the code executing as I spent hour after hour stepping through the code, watching and trying to understand what was happening. Eventually, it would reach a point where the debugger would just quit and I didn't know why or how this was made to happen. So off to the book store I went and bought a book on programing MACs in assembly language. After study this for a long time and watching more code go by, I eventually figured out how it was breaking the debugger. I had already discovered "where" this was happening through stepping, learning if I stepped over a particular jump or subroutine, the debugger was screwed. Eventually, I figured "what" exactly it was doing to break the debugger and how to "fix" it so I could get past that point. Then I "owned" the software, even if I had not yet figured out how it actually worked.

At that time MACs worked quite differently from the way PCs do. Their code was kept in "code sections" and called only when needed, to reduce memory requirements. All the code sections of my program were encrypted, so all of them had to be "decrypted" before they could be executed by the machine and hence, the program. Eventually I discovered that the encryption was made by using a starting phrase (in this case BEEFABAD) in hex and adding in the hex of each byte in the code section and using that checksum as the starting phrase for the next section, etc, etc, until they reached the end. At the end they had a master checksum hex phrase which the program had to store somewhere to use to "decrypt" the code sections, which had been encrypted using this master checksum hex phrase.

Eventually, I figured out how all this worked and how the decryption process worked. When needed, the encrypted code section was called by the program and the program had hijacked the MAC code section loader to make the encrypted section run through the "decoder" each time it was called to be placed into memory. When it was no longer needed, it was simply "released" and, when needed again, it was loaded through the 'decrypter." Now I had the decryption code and eventually I figured how to run it myself from within the program and forced it to write the decrypted code back to my HD so I then had the decrypted code.

The point of this history lesson, is that the processor can not "execute" encrypted/packed code itself. It needs to decrypt/unpack the code, either entirely or partially or part by part to allow the processor to understand what the "real" opcode is and execute it. This means a "packer" has to unpack the "real" code at some point, if the program is going to actually run. Your job is to find the point where this is/has occurred and then "capture" the "real" code to play with. This also means that "at some point" all the individual tricks the protectors have attempted to make your journey as difficult and tedious as possible "have to fix themselves" or the damn thing isn't going to work as it was intended before the protection was applied.

The protectors job is to make that journey take so long and be so tedious you will give up before you reach your goal. Their best defense is to try to blow up or screw with your debugger or disassembler in some way that you can't see what they are doing to muck with the code. This being true, one of your first lines of "offense" is to try to understand as much as you can about methods of screwing with your "tools of the trade." If you can learn how to protect your tools, you can eventually figure out what they have done.

Even if, at the beginning, you do not completely understant what it was they did to wreck your tools, if you know "where" they did it, you can try to figure some way to get past it. For example, maybe you can bypass a branch or a jump which bombs the debugger. You quickly learn that if you execute "that" particular step you are toast. Try skipping it and see what happens. Screwed again? OK. Go back and single step through the routine and watch what happens and see where things crash your world. When you figure out "what", now you you can work on "why." The more time you spend learning how your tools work, the better prepared you will be to prevent the protection from making you blind. If you can see what they are doing, eventually you can figure out how to "fix' it.

Regards,