hi. ok, under NT you don't have access to the gdt or idt under ring3. so you can't modify anything in the gdt and you can't modify one of the gate descriptors in the idt either. so what other possibilities are there to jump from ring3 to ring0? could i maybe patch some dll or vxd file that is loaded from NT at bootstrap into ring0? i could maybe patch a dll file by "adding" a special routine that gives the calling process ring0 privileges and just call that routine. would that be possible for example?
You must have admin privilege to install ring-0 drivers. and VxD just doesn't work on NT
yeah, but what if i patch the kernel itself or some other driver (like the mouse driver, which is - i think - loaded into ring0)? wouldn't that be possible? or does NT do some checks on the drivers loaded into ring0?
Hello. I think it's possible ! The Native API's are all called via the 02Eh interrupt. There's also one for calling drivers. I saw one time code of that kind, so it should be possible !
I'm sure this is possible... CIH (that nasty virus) did it.... but I don't know how
CIH only operates under win9x as it relies on the lack of IDT protection to hook and subsequently call an interrupt to obtain ring 0. Under NT/2k, since they are secure operating systems, there is no such hack and they have been designed to prevent any unpriviledged ring3 to ring0 jump because doing that would compromise all system security and integrity. You must use a device driver if you want to obtain ring 0 under NT/2k.. even then, device drivers are controlled by priviledge tokens (most of the time they can't be dynamically loaded by anyone without administrative rights). If you had some reason you couldn't use a device driver, you could concievably parastically attach to the physical image of a kernel component (say NTOSKRNL.EXE or NTDLL.DLL) (copy to a temp file and have it replaced at boot if necessary), hooking an export or something so that you would have your own attached code running at ring0 the next time the system is booted. This is, of course, riskier and not as easy as device driver development. I think the NT/2k rootkit does something similar, best I recall (modifies the kernel with hooks so that it can grant elevated priviledges in the background on subsequent system boots). Of course, the file system may be protected.
Oh, and yea you could physically attach to an existing device driver and have your code loaded with it at boot. However, under NT/2k make absolutely sure you adjust the checksum field in the PE header, as it is validated for all drivers and kernel components that are loaded at boot. An incorrrect checksum on a kernel component will yield a BSOD STOP.