jumping to random memory locations

I am posting this because I wonder if this is a flaw in windows internal
protection scheme.
If your a c++ programmer than you surely
would know that the following code

Code:

unsigned int *p const = 0xf0000000;
void (*fp) () = p;
fp();

would likely NOT reboot the system from
a 32-bit protected mode environment.
In fact if you compile and execute this type of
code it will result in a GPF.

Alas!
try doing a jump from debug using assemble command

Code:

c:\>debug
-a 100
0bd2:100 jmp bfff:0
0bd2:105
-g
*CRASH!!!!!!!!*

your results may vary but on my system it dumps the OS!
On every system I've tried (7 at school) random jumps to memory
between a0000-cffff crashes the whole system..ie
mouse ,kybrd,everything locaks up and requires me to
hold the power button in for 10 secs to powerdown.
jumps to a000(video RAM) results in a quite dazzling
color display and the onlookers thought I was doing some sort of
evil black magic, lol ...
anyway this shouldnt happen in a GUI environment!
I could easily make a .bat file to do this...or worse!
The NTVDM does a good job at preventing priviledged instructions
but it apparently does not stop one from jumping into the abyss
oh btw this seems to only work when the cmd window is fullscreen.
I could easily create a c program that spwans a shell in fullscreen and executes my evil assembly
Any feedback would be welcome
thanks

Paul

 

This code is invalid from user mode. No fair accessing kernel memory from user space. This will DrWatson every time, by design, as a direct and desirable result of the win32 memory architecture.

Paul, I have tested this assembly on both 2000 and XP, and I cannot reproduce your results. On both OSs i get an NTVDM exception, I tried full screen and in a window. You posted this in the XP forum, are you testing on win98?

 

Hi Ben,

I tested this on my home PC running XP home Service Pack 2 and also
7 PCs in a lab which all run 2000 Pro.
All tests delivered the same results: total system instability
However! -- Yesterday I tried this on my mother's PC which
is an Athlon XP and the NTVDM properly kicks in....so I dunno,
sounds like a hardware issue.
It seems enough of a bug that warrants inspection yet
it's not likely to ever happen in production code since
user space coders dont initialize pointers to absolute
memory.
In any caSE ,like you said , kernel pages can only be mapped,moved,
written to,etc from an NT driver or a security hole.
I dunno...

yeah 98 sucked -- BSOD 5x a day ...thank Gawd those days are over

 

Well, Lets talk about what your really doing here..

You are loading the VDM, virtual dos machine, an emulator designed to emulate old programs, and expose expected interfaces. The segment A000-BFFF is reserved for Video bios. By running the command JMP BFFF:0 you are telling the VDM to move the instruction pointer to this address and execute it.

Code:

-d bfff:0
BFFF:0000  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
BFFF:0010  55 AA 54 EB 4B 37 34 30-30 E9 4C 19 77 CC 56 49   U.T.K7400.L.w.VI
BFFF:0020  44 45 4F 20 0D 00 00 00-F0 00 E1 10 00 00 49 42   DEO ..........IB
BFFF:0030  4D 20 56 47 41 20 43 6F-6D 70 61 74 69 62 6C 65   M VGA Compatible
BFFF:0040  01 00 00 00 80 10 F5 A1-30 38 2F 32 39 2F 30 31   ........08/29/01
BFFF:0050  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
BFFF:0060  E9 F5 65 00 DE 10 70 00-E9 27 10 E9 2E 10 50 4D   ..e...p..'....PM
BFFF:0070  49 44 58 00 5B 00 00 00-00 A0 00 B0 00 B8 00 C0   IDX.[...........

-u bfff:0
BFFF:0000 0000          ADD     [BX+SI],AL
BFFF:0002 0000          ADD     [BX+SI],AL
BFFF:0004 0000          ADD     [BX+SI],AL
BFFF:0006 0000          ADD     [BX+SI],AL
BFFF:0008 0000          ADD     [BX+SI],AL

On my 'no repro' machine, this is whats contained at that location. Since its all 000000s, it will just throw an exception and die trying to store AL into a dereferenced BX+SI. My guess is that on these machine you have that repro it, there is something there, and it is making it run some crazy assembly command thats hosing up the video bios, which in turn can hose the whole machine if it puts the video card into some undefined state.

My guess is that when you are full screen(alt-enter), you are relying on the video bios to give you updates, and when you mess with it, your box falls over. This is a direct result of VDM trying to let you do what you asked it to do.

I wouldnt classify this as a bug, this is just a 'broken program' that has a way to bust up the video subsystem on certain machine configurations. Its not the only way you could do this. You could death spiral win32 with bad programming. Check out MSDN on 'ghost windows'. Or read windows internals and learn how regmon can dynamically load a dynamic device driver and talk to it in kernel, from a single .exe file.

Ultimately, the education you are now working on will build a solid foundation in programming for good. Keep exploring and pushing the system to understand why things work the way they do.

 

Thanks Ben!
Yeah I kinda came to a similar conclusion...I looked at what was AT the locations that I was jumping to..an obvious place to explore!
I was still left with the ?: "how can these instructions hose my system
from PM? "
Your responce makes it more plausible.
Anyway, like I said it's not likely to happen. But virus writers are always finding new holes- maybe the NTVDM is a minel of gold for the determined hacker!
regards,
Paul
ps- if it can be broken it will be eventually