Myria wrote:
If the ImageBase for a given executable is in the kernel range (above 0x7FFE1000 or whatever), from reading the code it seems like no validation will stop it from going above that address. I have no way to try it out because I don't have reactos installed.
MmMapViewOfSection will constrain it, and the image will simply be reported as being loaded at an address different from its preferred address (STATUS_IMAGE_NOT_AT_BASE), requiring the base relocation bloodbath and whatnot. Or that's how the theory goes. And no I don't pull this out of my ass - for example, all drivers have the default DLL base address as their preferred load address, but they certainly aren't mapped in user mode because of that. In general, I don't believe in gratuitous limitations, and my PE loader is very very very liberal, allowing for executables with hopelessly mauled NT headers (e.g. lacking an arbitrary amount of fields, up to and including the whole data directory array) as long as the fields pertinent to the kernel are meaningful
Personally I think reactos should allow user mode programs to shove ntdll and kernel32 out of the way, but that's just me =)
ntdll no, simply won't happen. kernel32 maybe, but requires too much work. One day though I'll enact the "KJK::Hyperion Heresy", revolutionize the Win32 subsystem and remove this and other limitations
MmCreatePeb has an invalid assertion: ASSERT(Peb == (PVOID)0x7FFDF000);
this is wrong and stupid, of course. In fact the PEB location is now even slightly randomized