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

Home NTDEV

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/


Before Posting...

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

ntoskrnl.exe memory scanning

elderorbelderorb Member Posts: 2

Hi,

I need to scan memory occupied by ntoskrnl.exe to find some specific data based on some pattern. It mostly works, but fails with 'paged fault in non-paged area'
if verifier is enabled or if amount of memory on test environment is less than 2GB. Do I understand correctly this is because windows unloads some of ntoskrnl.exe pages
or the root cause if different? I thought ntoskrnl.exe is one of most important components which should never be unloaded, no?

Anyway, I've made an experiment and wrapped all the access to ntoskrnl memory with MmIsAddressValid so that if memory is invalid - code just skips this particular byte
and searches starting from the next one. And... It stopped crashing but also stopped finding what I need under verifier.

The question: what is the right way of scanning all the memory occupied by ntoskrnl.exe ? If this is not possible at all, I probably could get what I need via loading another instance of ntoskrnl.exe and searching it. But in this case, do I understand correctly that I have to load it to non-paged memory? Or lock memory somehow? Is there any links which could help me?

Thanks!

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,411

    what is the right way of scanning all the memory occupied by ntoskrnl.exe ?

    There is no “right way” to examine arbitrary kernel memory. Basically, it’s not anything you should be interested in, unless you’re writing malware.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • ThatsBerkanThatsBerkan Member Posts: 56

    The correct way to scan a module is to parse its section headers and scan each sections data.

    Pseudo code would be:

    auto Sections = GetSectionsOfModule("ntoskrnl.exe");
    
    foreach (SectionHeader in Sections)
    {
        if (SectionHeader->Characteristics IS DISCARDABLE)
           skip;
    
        auto VirtualAddress = NtoskrnlBase + SectionHeader->VirtualAddress;
        auto VirtualSize = SectionHeader->Misc.VirtualSize;
    
        Scan(VirtualAddress, Size);
    }
    
  • Don_BurnDon_Burn Member - All Emails Posts: 1,728

    Don't encourage people who as Peter pointed out are basically writing malware. Even if they think they are doing it for good, they are destabilizing the system.

    As a note, by the way your simple model will not work correctly in the kernel. At least it had flaws that I know of for NT3.5 through Windows 8.1, I never had reason to check Win10 but one assumes that it still will have the problems.

  • elderorbelderorb Member Posts: 2

    First of all, thanks ThatsBerkan, I'll give it a try!

    2Peter_Viscarola_(OSR) and Don_Burn: Much worse than malware, but a security product. Also, I don't get it - malware or not, this forum is devoted to system development, drivers etc. My question is valid, so what's the point? Do you think driver development is VIP club or something? Do you really want to keep 'simple mortals' in a dark while looking with superiority from your Ivory Towers? This is not gonna work guys. You can't hide knowledge, just delay its spread.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,411

    @elderorb Before you lecture anybody, I suggest you take the requisite five minutes to get a feel for those you are lecturing. ME? Not willing to share info? Given that OSR has been providing definitive technical expertise regarding Windows internals and driver development for more than 20 years... via books, articles, lectures, and numerous free publications such as The NT Insider and more recently our dev blog, I think your arrogant lecture about info sharing is somewhat misdirected.

    We decided, many years ago, that this community would not knowingly contribute to the development of malware. We view this as a responsibility. This isn’t a university where all knowledge is good. it is a community of professional, commercial, software engineers. Intent matters.

    So, clue up and explain what you’re trying to accomplish and convince us that you’re not a bad actor. Or go somewhere else with your accusations and childish project. Or, stay here... arrogant and annoying... and get banned. The choice is yours.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • anton_bassovanton_bassov Member MODERATED Posts: 5,245

    Do I understand correctly this is because windows unloads some of ntoskrnl.exe pages

    Correct....

    Some pages/sections may be needed only during the initialisation, so that they may get subsequently discarded by the system ( a driver's INIT section with its DriverEntry() routine is the very first example that gets into my head).

    In any case, as it has been already pointed out by the other posters, poking at random memory locations in the kernel is a pretty stupid and unsafe approach, so that a question concerning " how to do it properly" is guaranteed to raise the suspicions in this NG

    Anton Bassov

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

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!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 2 August 2021 Live, Online
Kernel Debugging 27 Sept 2021 Live, Online