Access to \device\physicalmemory
 

Hi!
I have a question:
How can i store some bytes in physical memory address like
00c0000? (video bios information). Is it possible.
Note: Running on NT2000, Admin access. Platform: Delphi/Asm.
If can, does this data can be accessed by other programs using
ntmapxxxxxxxxxx () functions to read \device\physicalMemory??
hank you!

get KmdKit By Four-F and go through them he also has a sample code on
PhysMemViewer ObjectManger etc also some basic drivers and thier code sources
look through them probably you may get an answer to your query
also visit FasmBoard there are some interesting threads that deal with PhysMem
and such

edit
i actually didnt have the link at the time i posted so i edit here
take a look at
http://www.security.org.sg/code/sdtrestore.html

this tool supposedly writes to devphysmem (get the pdf and the tool and reverse it to find how it is coded :)

btw take a look at credits and find posts by the ppl :)

Snippet from the famous Gary Nebbett:

h??p://groups.google.com/groups?selm=01bdc5f2%24e2ec33d0%241eadf6a8%40caopi2&oe=utf-8

Here you can find a great Phrack Article about it:
-> http://www.phrack.org/phrack/59/p59-0x10.txt
The code is written in C but it's well commented so you should understand it too.

Thanks.
i've read this. but at this address $c0000 is video card firmware and i can't write to it...
Can it be possible to intercept read attempts to such address and return the data bytes other than original???

you have read what the phrack article or from the link i posted
any way here is a dump from my old little comp using physmembrowser

so i can read it it seems :) and dump it and the sdrestore can restore my symantec av hooking of ZwCLose and 7 other hooks back to original
so it must be possible in your case too i would assume :) any way good luck

Example of reading descriptor tables using PhysicalMemory:
http://ry.pl/~omega/asm/sdt.zip

Example of writing to PhysicalMemory:
http://ry.pl/~omega/asm/ring0nt.zip

heh, thanks to omega_red.
enjoed with bsod.. no prob..

Suggestion to all Ring0-jumperz:
Don't use Call_Gates, they are incompatible with Win-Ring0-stack
architecture..(designed for INTs only)

simple use INTs

I've tried something similar but the only thing i managed was to destroy my bios and it recognized only HDD and not CD-r and floppy

But you can't insert a new int from user-mode or how do you mean that?
(Even in Kernel-Mode you must edit CR0 to play with the IDT)
Argh,... sure,... we have \device\physicalmemory ^^,... but no sidt!?

of course, using same tool you can setup one IDT-entry (instead of GDT),
& go to Ring0. in XP from 42h to FFh INTs are reserved, so enjoy with them.

huh, why you need CR0 for write in IDT?? nop

[edit]:
forgot, when you will in Ring0, perform same action, wich does other system INTs..
save in same order registers, load then in FS-reg 30h..then only can be STI..
(stack should lowered on 68h or more from entered position)

so, a get into ring0 by driver, (TVICHHW for Delphi) and trying to write into \\device\physicalmemory.... but exception Access violation popups....
Trying to change bytes at physical address $c0000 with SoftIce - if changed, after second they will be the same as original....
May be i need to intercept some native API???

Video BIOS (like any other BIOS) usually resides in ROM (Read-Only Memory). So, you can't write in it.

In DOS times there was some trick used by chpset to speed-up BIOS access (EEPROM was much slower that RAM). BIOS was copied into RAM and that RAM region was marked as Read-only and mapped in address space instead of BIOS. And for some chpsets there was known way to unlock mapped region of RAM, modify its content (e.g. replace font characters bitmap) and lock region back. But mapping of RAM instead of BIOS ROM was supported by chipset, not by CPU itself...

but is it possible to emulate read attempts to that addresses???
Which tools can be useful to determine, which API used to read this memory area?
API SPY does not show it... in code there called ntMapOfView...

I'm not too good in kernel stuff but here are two theoretical ideas (may be wrong):
- use hardware breakpoint to catch read attempt at some address and handle it
- if you know how exactly (by means of which function) video BIOS is mapped in address space of calling process, intercept that function and return pointer to some other region containing any data.