ntoskrnl.exe memory scanning

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!

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

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);
}
1 Like

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.

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.

1 Like

@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

1 Like

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