Is it safe to rely upon ntoskrnl.exe–or rather, the currently-chosen kernel–to be the first entry in the list returned by EnumDeviceDrivers / NtQuerySystemInformation(SystemModuleInformation)? I’m just wondering whether it’s guaranteed that the kernel will always be the first entry in that list, because relying upon the filename to identify the kernel is bad.
Note that AuxKlibQueryModuleInformation is NtQuerySystemInformation(SystemModuleInformation) in disguise; Microsoft can’t change the SystemModuleInformation info class because AuxKlibQueryModuleInformation because aux_klib is a static library linked into many drivers now. EnumDeviceDrivers in user mode just uses the same info class, but that implementation detail is changeable.
(BTW, I personally think that for security’s sake that SystemModuleInformation that the base addresses of drivers should be returned as zero for processes with integrity below High. I think that’s currently true for Low in 8.0 and 8.1, but I don’t see why Medium-integrity processes need that information.)
There is no guarantee it is the first, although ntoskrnl.exe is the only name used for the kernel in any release you would care about, there is no longer a up vs mp version. It would probably be the only module listed with a .exe extension though
d
Bent from my phone
From: xxxxx@gmail.commailto:xxxxx Sent: ?5/?4/?2014 3:10 PM To: Windows System Software Devs Interest Listmailto:xxxxx Subject: [ntdev] Safe to rely upon first module being ntoskrnl.exe?
Is it safe to rely upon ntoskrnl.exe–or rather, the currently-chosen kernel–to be the first entry in the list returned by EnumDeviceDrivers / NtQuerySystemInformation(SystemModuleInformation)? I’m just wondering whether it’s guaranteed that the kernel will always be the first entry in that list, because relying upon the filename to identify the kernel is bad.
Note that AuxKlibQueryModuleInformation is NtQuerySystemInformation(SystemModuleInformation) in disguise; Microsoft can’t change the SystemModuleInformation info class because AuxKlibQueryModuleInformation because aux_klib is a static library linked into many drivers now. EnumDeviceDrivers in user mode just uses the same info class, but that implementation detail is changeable.
(BTW, I personally think that for security’s sake that SystemModuleInformation that the base addresses of drivers should be returned as zero for processes with integrity below High. I think that’s currently true for Low in 8.0 and 8.1, but I don’t see why Medium-integrity processes need that information.)
You can change the name of the kernel using bcdedit, I routinely do this as
part of installing a partially checked build. Something else for the OP to
add to the heuristic.
“Doron Holan” wrote in message news:xxxxx@ntdev… There is no guarantee it is the first, although ntoskrnl.exe is the only name used for the kernel in any release you would care about, there is no longer a up vs mp version. It would probably be the only module listed with a .exe extension though
d
Bent from my phone From: xxxxx@gmail.com Sent: ý5/ý4/ý2014 3:10 PM To: Windows System Software Devs Interest List Subject: [ntdev] Safe to rely upon first module being ntoskrnl.exe?
Is it safe to rely upon ntoskrnl.exe–or rather, the currently-chosen kernel–to be the first entry in the list returned by EnumDeviceDrivers / NtQuerySystemInformation(SystemModuleInformation)? I’m just wondering whether it’s guaranteed that the kernel will always be the first entry in that list, because relying upon the filename to identify the kernel is bad.
Note that AuxKlibQueryModuleInformation is NtQuerySystemInformation(SystemModuleInformation) in disguise; Microsoft can’t change the SystemModuleInformation info class because AuxKlibQueryModuleInformation because aux_klib is a static library linked into many drivers now. EnumDeviceDrivers in user mode just uses the same info class, but that implementation detail is changeable.
(BTW, I personally think that for security’s sake that SystemModuleInformation that the base addresses of drivers should be returned as zero for processes with integrity below High. I think that’s currently true for Low in 8.0 and 8.1, but I don’t see why Medium-integrity processes need that information.)
Needing to know the kernel image base is fairly atypical (MmGetSystemRoutineAddress can be used to resolve kernel exports). What is being done here that is believed to necessitate special casing the kernel image base ?
S (Msft)
From: Scott Noonemailto:xxxxx Sent: ?5/?6/?2014 8:41 To: Windows System Software Devs Interest Listmailto:xxxxx Subject: Re:[ntdev] Safe to rely upon first module being ntoskrnl.exe?
You can change the name of the kernel using bcdedit, I routinely do this as part of installing a partially checked build. Something else for the OP to add to the heuristic.
“Doron Holan” wrote in message news:xxxxx@ntdev… There is no guarantee it is the first, although ntoskrnl.exe is the only name used for the kernel in any release you would care about, there is no longer a up vs mp version. It would probably be the only module listed with a .exe extension though
d
Bent from my phone From: xxxxx@gmail.com Sent: ?5/?4/?2014 3:10 PM To: Windows System Software Devs Interest List Subject: [ntdev] Safe to rely upon first module being ntoskrnl.exe?
Is it safe to rely upon ntoskrnl.exe–or rather, the currently-chosen kernel–to be the first entry in the list returned by EnumDeviceDrivers / NtQuerySystemInformation(SystemModuleInformation)? I’m just wondering whether it’s guaranteed that the kernel will always be the first entry in that list, because relying upon the filename to identify the kernel is bad.
Note that AuxKlibQueryModuleInformation is NtQuerySystemInformation(SystemModuleInformation) in disguise; Microsoft can’t change the SystemModuleInformation info class because AuxKlibQueryModuleInformation because aux_klib is a static library linked into many drivers now. EnumDeviceDrivers in user mode just uses the same info class, but that implementation detail is changeable.
(BTW, I personally think that for security’s sake that SystemModuleInformation that the base addresses of drivers should be returned as zero for processes with integrity below High. I think that’s currently true for Low in 8.0 and 8.1, but I don’t see why Medium-integrity processes need that information.)