As far as I can tell, it is a matter of CMD/Command not keeping correct tabs of where the pointer (cursor) is located. You can visualize this if you type in the original "code" and put a sleep(1) in it. You will notice that the cursor slowly moves backwards in your command prompt(and incorrectly deletes text on its way, shame on you Microsoft for coding that). When the cursor reaches the top of the command buffer (top left of your screen) it should stop, but apparently they failed the good'ol' if point<=0 :) and it continues on to a negative value and overwrites whatever is in the memory next to the memory allocated for the command prompt. The next is purely guesswork, since I don't have the means of verifying it, I hope someone will correct me if I am wrong (which I hope I am). Windows NT has undergone quite a few optimization steps from it's birth to the Windows 2000 monstrosity we see before us now (no disrespect intended). One is to put as much into the kernel as possible to improve performance. I'm wondering if the command memory allocated is in kernel space (next to it)? The reboot signifies a major problem, such as a kernel failure, so I wouldn't call it far-fetched. My problem here is, that I tested the overwriting with a normal user account on my Windows 2000 (yes, I use it myself) and it worked, meaning the machine rebooted... If it is possible to correctly overwrite the memory content, would it be possible to get code executed? If so, it appears a normal user can do it. If it's simply a problem with a command subroutine that doesn't handle negative pointers, why doesn't it just cause a dr. watson? Peter Gründl
This archive was generated by hypermail 2b30 : Mon Nov 05 2001 - 09:23:19 PST