Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


MmMapIoSpace Failing

MunchMunch Member Posts: 2

Hey! I am pretty new to a lot of these topics and am trying to achieve something relatively simple:
1. Translate a Virtual Address to Physical
2. Read the Physical Address Into a Virtual Buffer

This has all been perfectly fine with my current method of reading which is using MmMapIoSpace and memcpy, given what I already know this solution should work completely fine. Here's the thing though, when entering a (known) valid physical address, like the MZ of a module this solution works perfectly fine but the problem shows itself whenever I try to translate the address, and given my little knowledge the only explanation I could come up with was that the memory was shadowed and protected in some way from MmMapIoSpace because thats the one function that always returns zero when trying to access the PFN of the PLM4 entry. Any help much appreciated.

Comments

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,754

    First of all, what is 'the MZ of a module'?

    I don't understand what you are trying to accomplish by (incorrectly) translating a virtual address to physical. and then re-mapping (incorrectly) that physical address to a virtual address.

    However the manual translation of a buffer starting at VA n to a PA for the VA n is NOT a translation of all of the PAs that constitute the entire buffer. There is no guarantee that an arbitrary VA buffer maps to a contiguous set of PAs. You can use MmProbeAndLockPages to get an array of PFns. Those PFns can then be individually translated to a PA.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,836

    If you try to create a new mapping for an address that already has a mapping, the cache setting must match the existing mapping.

    Tim Roberts, [email protected]
    Software Wizard Emeritus

  • MunchMunch Member Posts: 2
    1. The MZ of a module is the PE+ Header Identifier, I am reading the first two bytes of the modules base address. Which is a very reliable way to validate whether or not the read functioned, like I stated previously when I give it an already translated address (which I found using some tool I did not make) the physical address read functions perfectly, however when I try to translate that modules given virtual address into physical the very first read (attempting to access the PFN of the target PLM4 entry) fails at MmMapIoSpace and I don't know why, I don't want to have to resort to using different functions if there is an easy solution that I am missing

    2. There is no pre-existing mapping I don't think, it would not make sense as every successful map I unmap the space as soon as I am finished with it

    Read Physical Memory Code:
    PHYSICAL_ADDRESS TargetPhysicalAddress = { 0 };
    TargetPhysicalAddress.QuadPart = (LONGLONG)TargetAddress;

    PVOID MappedMemory = MmMapIoSpaceEx(TargetPhysicalAddress, Size, PAGE_READWRITE);
    if (!MappedMemory)
    return (NTSTATUS)3;

    memcpy(Buffer, MappedMemory, Size);

    MmUnmapIoSpace(MappedMemory, Size);

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,836

    Of course there is an existing mapping. If there wasn't, where did you get a physical address to map?

    Tim Roberts, [email protected]
    Software Wizard Emeritus

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 13-17 May 2024 Live, Online
Developing Minifilters 1-5 Apr 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 20-24 May 2024 Live, Online