notsoanonimus / orchidos_x86 Goto Github PK

When calling the debugging command COMMAND_DUMP during the boot process, or during a BSOD (Blue-Screen-of-Death) event on boot failure, there is no output and the ASCII strings have no register information written to them by the system.

Any other BSODs or DUMPs after system initialization will output normally and provide correct information.

An image of the bug in action during the boot process.

The parser can be exploited to provide the result of a specific command by just using the last four characters of the command's name. For example, executing the command "REBOOT" can be done by doing the following (where X represents any valid ASCII keyboard value): "XXBOOT". The same applies to any command over 4 characters in width: "X[n]BBBB", where B is the last four characters of the targeted command.

FIX: Rebuild the parser, its structure, and its methods of obtaining a proper command.

The INPUT_BUFFER is defined as a preprocessor constant that equals KERNEL_OFFSET+inputBuffer, where KERNEL_OFFSET is the base address of the system kernel and inputBuffer is the label of the 256-byte buffer's start address. The problem is that instead of writing to ~0x10024 as it should, it's adding the offset of 0x10000 and writing to 0x20024 with every keypress.

The obvious issue is that, though it works for user I/O, it is trashing the parts of the kernel that are loaded in memory at 0x20000+ during boot. This was not an issue when the shell display/UI wrappers were designed because the kernel was so small at the time.

One would think that it would only require the address of the variables to be changed, but that has been tried and it is completely tearing the shell apart for some reason. This whole section just needs to be redesigned.