Motive: To detect if someone has compromised the MBR of a disk.
Approach: Based on several web links, If I can get a bottom view which I can compare with a top view, this task can be accomplished.
Getting Top view is fine; Problem with bottom view is that the disk.sys is infected so I can not send a IRP to this. Though its mentioned that the callback for read IRP is ClassReadWrite in ClassPnp.sys library, it is not exported and few other ways to retrieve a pointer to this function is already patched.
One easy way is to reverse-engineer the classpnp.sys and discover another point to retrieve the pointer to callback but sooner or later it will be patched like other ways. It may have hooked ClassReadWrite inline so again this approach will not work.
Another is to sit below disk.sys and process the data. (Till date I have no idea abt the complexity involved in this task).
You can send an SRB read request to atapi device under disk.sys in internal
ioctl.
Haibo
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Friday, March 20, 2009 2:30 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Bypassing disk.sys to retrieve a sector from disk.
Motive: To detect if someone has compromised the MBR of a disk.
Approach: Based on several web links, If I can get a bottom view which I can
compare with a top view, this task can be accomplished.
Getting Top view is fine; Problem with bottom view is that the disk.sys is
infected so I can not send a IRP to this. Though its mentioned that the
callback for read IRP is ClassReadWrite in ClassPnp.sys library, it is not
exported and few other ways to retrieve a pointer to this function is
already patched.
One easy way is to reverse-engineer the classpnp.sys and discover another
point to retrieve the pointer to callback but sooner or later it will be
patched like other ways. It may have hooked ClassReadWrite inline so again
this approach will not work.
Another is to sit below disk.sys and process the data. (Till date I have no
idea abt the complexity involved in this task).
Absolutely right!..but for fun you could look into scsi pass-through
mechanisms to get the “bottom view”
While using scsi passthrough, talk to port driver and not to class
driver.
Harish
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Friday, March 20, 2009 3:26 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Bypassing disk.sys to retrieve a sector from disk.
Getting Top view is fine; Problem with bottom view is that the
disk.sys is infected so I can not send a
IRP to this.
If disk.sys is infected, then the whole OS is infected and you can do
nothing but reinstalling the OS.
> Motive: To detect if someone has compromised the MBR of a disk.
Impossible if the OS is booted from the disk in question…
If I can get a bottom view which I can compare with a top view, this task can be accomplished.
Sure - the “only” problem left is how to get this “bottom view” …
Everything depends solely on sophistication level of a rootkit in question. To give you an idea, “well-written” rootkit may operate at sub-OS level. For example, it may hook low-level BIOS calls, including INT 13H, and modify disk controller driver’s image (as well as that of ntoskrnl.exe, hal.dll, and whatever else it may be interested in) well before ntoskrnl.exe is even started, effectively hijacking the OS and making it do whatever the rootkit wants. Therefore, if you try to accomplish your objective from within the OS…sorry, but the only picture you will be able to see is the one that the rootkit wants you to see…
> …especially in Win6 x64 where everything is digitally signed
How naive…
To begin with, you can load an unsigned driver if you make an appropriate choice at the boot time. Apparently, this choice has to be made before ntoskrnl.exe starts execution, so that this info must be recorded in some global variable and subsequently checked by ntoskrnl.exe. Therefore, the only thing rootkit has to do is to do is to present things in such way that would make the system believe that the user chose loading unsigned drivers…
>> …especially in Win6 x64 where everything is digitally signed
How naive…
Am I dreaming or originally hooking ntoskrnl was explicitly mentioned?
Not so naive then…
It is certainly true that unsigned hooligan can wreak any havoc it chooses
[note the “:-)” in the response], but hooking of signed executables is
[almost] impossible.
----- Original Message -----
From: To: “Windows System Software Devs Interest List” Sent: Saturday, March 21, 2009 9:06 AM Subject: RE:[ntdev] Bypassing disk.sys to retrieve a sector from disk.
>> …especially in Win6 x64 where everything is digitally signed > > How naive… > > To begin with, you can load an unsigned driver if you make an appropriate > choice at the boot time. Apparently, this choice has to be made before > ntoskrnl.exe starts execution, so that this info must be recorded in some > global variable and subsequently checked by ntoskrnl.exe. Therefore, the > only thing rootkit has to do is to do is to present things in such way > that would make the system believe that the user chose loading unsigned > drivers… > > > Anton Bassov > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer
> Am I dreaming or originally hooking ntoskrnl was explicitly mentioned?
Well, I don’t know if you were dreaming, but you definitely did not read it careful enough - what was mentioned is hooking INT 13h, rather ntoskrnl.exe. As a result, your rootkit may be able to make ntoskrnl.exe believe that user chose to load unsigned driver; or even that the system is being debugged - once it has an advantage of setting up the environment before kernel starts running, technically there is nothing that stands in its way…
hooking of signed executables is [almost] impossible.
… unless PatchGuard is disabled, and, IIRC, this is exactly what happens when system is being debugged. If the rootkit tricks the OS into believing that it is being debugged, it can do whatever it wants…
> This hardens the rootkit development a lot, given the fact that the tiny update from MS will
render this inoperable.
Well, unless this update writes a new boot sector, I am afraid it may render the machine unbootable as well…
Also note that the recovery CD is a very good idea,
Sure, but this is not what the OP asks about - what he wants to do is to verify the boot sector from the OS that got loaded from the target disk. If he puts his software on the CD, it will be already a different story (and, in such case, it does not have to operate from within the OS either)…
> Well, I don’t know if you were dreaming, but you definitely did not read it careful enough - what was > mentioned is hooking INT 13h, rather ntoskrnl.exe.
Well, let’s see:
“it may hook low-level BIOS calls, including INT 13H, and modify disk controller driver’s image (as well as that of ntoskrnl.exe, hal.dll, and whatever else it may be interested in) well before ntoskrnl.exe is even started”
> "it may hook low-level BIOS calls, including INT 13H, and modify disk controller driver’s image
(as well as that of ntoskrnl.exe, hal.dll, and whatever else it may be interested in) well
before ntoskrnl.exe is even started"
Looks like I was not dreaming, after all.
Please read the above paragraph again - it speaks about hooking only BIOS calls. The very term “hooking” somehow implies that at some point execution flow will eventually reach the actual callee, which, in turn, implies that hooking code gets loaded later than the actual callee. Modifying image is not bound by this limitation, so it may go further than that. For example, rootkit may modify PE header, extend .TEXT section so that its own implementation of some certain exports appear in the image and adjust RVAs accordingly; and do all the above before ntoskrnl.exe’s entry point is invoked…
If you set up environment in such way that the OS believes it is being debugged (this is achievable by hooking BIOS), all subsequent verification checks will be skipped, so that you can do whatever you like…
>>If disk.sys is infected, then the whole OS is infected and you can do nothing but reinstalling the OS.
>Everything depends solely on sophistication level of a rootkit in question. To give you an idea, “well-written” rootkit may operate at sub-OS level…
I agree to all these statements and yes they are 100% true technically.
But currently if I think from the perspective of a developer writing malware detection code; my aim is to detect as much as possible if not *all*. So just because there is a writer who can write 100% detection proof malicious code, I can not stop writing detection code for the malwares which are equally harmful yet detectable? At the end if my tool can detect n% of such malware; I will feel better than 0% any day.
And the objective of this post was to increase that n% to whatever maximum extent I can from all your suggestions & comments.
You will never come close to detecting al! If I can break in to a certain
pont, I can hook anywhere I want, how are you supposed to check that. The
“oh you point out of the current module” has been easily defeated by the
fact that most drivers have space between the segments so you put a jump
there and jump to that so you are still in the driver. Sorry but Malware
cleaning is a joke, you can do security by detection of the attack, this is
the DOD model from many years ago, but you cannot clean with any useful
degree of success once the kernel is infected.
wrote in message news:xxxxx@ntdev… >>>If disk.sys is infected, then the whole OS is infected and you can do >>>nothing but reinstalling the OS. > >>>Everything depends solely on sophistication level of a rootkit in >>>question. To give you an idea, “well-written” rootkit may operate at >>>sub-OS level… > > I agree to all these statements and yes they are 100% true technically. > > But currently if I think from the perspective of a developer writing > malware detection code; my aim is to detect as much as possible if not > all. So just because there is a writer who can write 100% detection > proof malicious code, I can not stop writing detection code for the > malwares which are equally harmful yet detectable? At the end if my tool > can detect n% of such malware; I will feel better than 0% any day. > > And the objective of this post was to increase that n% to whatever maximum > extent I can from all your suggestions & comments. > > Thank you all for your patience and time, > Aditya > > > Information from ESET NOD32 Antivirus, version of virus > signature database 3953 (20090321) > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > >
Information from ESET NOD32 Antivirus, version of virus signature database 3953 (20090321)
>>The “oh you point out of the current module” has been easily defeated by the fact that most drivers have space between the segments so you put a jump there and jump to that so you are still in the driver.
This is a golden point made. Thanks for pointing this.
> but you cannot clean with any useful degree of success once the kernel is infected.
I know I can not clean this and I am not planning for that at all, As Max suggested to reinstall the OS; for this a user needs to know that the system is doomed and now there is nothing left but reinstall. And yes there are rootkits which can not be detected but at same time there exists rotkits which can be identified.
I found few rootkits with our malware research guys which can be fixed by using fixmbr command from recovery console, and they have not patched all paths to ClassReadWrite. So in this case a user can be saved from a OS reinstall.
> But currently if I think from the perspective of a developer writing malware detection code;
my aim is to detect as much as possible if not *all*. So just because there is a writer who can
write 100% detection proof malicious code, I can not stop writing detection code for the malwares
which are equally harmful yet detectable?
Don’t forget that PatchGuard and especially driver signing presented new challenge to rootkit writers. Relatively simplistic malware that can get detected right from the compromised OS is not going to stand a chance on 64-bit system anyway…
In other words, stop relying upon any doc on the topic that you find of the web if it was written more than 2 years ago and/or is based upon earlier-written docs - no matter how useful they were at the time they were written, their current practical usefulness is close to zero…
>>If disk.sys is infected, then the whole OS is infected and you can
do
nothing but reinstalling the OS.
>>Everything depends solely on sophistication level of a rootkit in
question. To give you an idea, “well-written” rootkit may operate at
sub-OS level…
I agree to all these statements and yes they are 100% true
technically.
But currently if I think from the perspective of a developer writing
malware detection code; my aim is to detect as much as possible if not
*all*. So just because there is a writer who can write 100% detection
proof malicious code, I can not stop writing detection code for the
malwares which are equally harmful yet detectable? At the end if my
tool can detect n% of such malware; I will feel better than 0% any
day.
And the objective of this post was to increase that n% to whatever
maximum extent I can from all your suggestions & comments.
I’m curious as to what environment you are running under where it is
okay to consider that there is a n% possibility that you don’t have a
rootkit installed, where n < 100?
If someone comes up with a way to hide a rootkit with 0% chance of
detection, then all future rootkits will use the same techniques, and
your solution will be redundant.
That being said though, there will never be an endgame. It’s always been
a game of leapfrog - a new rootkit comes out that is undetectable by all
known techniques, the detection techniques evolve to be able to detect
it, and then the rootkits evolve to avoid detection by that technique
again. As long as both parties have access to each others code (and they
always will), that’s the way it will always be. So don’t give up
