Re[2]: Inspiration

NTDEV
1

Hello David,

Thursday, March 10, 2005, 1:32:31 AM, you wrote:

DL> The webpage for rootkitreveal mentions doing “raw reads” of the
DL> filesystem (and registry hive) for comparison to the data returned by
DL> normal reads. Please forgive the naive question, but how are raw reads
DL> done?
it’s CreateFile on \.<x>: and then ReadFile on
handle obtained. raw in this case means that the rootkitreveal
interprets the data on his own. it has built in filesystem code that
it uses for file/directory traversal and code that can understand the
hive format. nothin more, nothing less.

but well, ain’t it all written on that page?

–
Best regards,
Ivona Prenosilova

2

David,

The following paragraph is from the rootkitrevealer page:

"
Can a Rootkit hide from RootkitRevealer?
It is theoretically possible for a rootkit to hide from RootkitRevealer.
Doing so would require intercepting RootkitRevealer’s reads of Registry hive
data or file system data and changing the contents of the data such that the
rootkit’s Registry data or files are not present. However, this would
require a level of sophistication not seen in rootkits to date. Changes to
the data would require both an intimate knowledge of the NTFS, FAT and
Registry hive formats, plus the ability to change data structures such that
they hide the rootkit, but do not cause inconsistent or invalid structures
or side-effect discrepancies that would be flagged by RootkitRevealer.
"

My understanding is that the rootkitrevealer simply reads the registry hive
and file system tables from the disk and parses them just like the registry
API and file system driver would. This comes to detect hooking of kernel and
user mode API’s that are related to registry and file system. A disk filter
that fakes the data that is read from the disk will certainly will not be
detected by this tool. Then again you can read the last sentence in the
quoted paragraph - this is not a simple task, not even remotely close in its
difficulty to API hooking.

Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Lavo
Sent: Thursday, March 10, 2005 2:33 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Inspiration

The webpage for rootkitreveal mentions doing “raw reads” of the filesystem
(and registry hive) for comparison to the data returned by normal reads.
Please forgive the naive question, but how are raw reads done?

I ask because yesterday I was trying to read something from a CdRom and
found that all my read requests were blocked by a lower filter driver called
“pfc.sys”. (This was during a rip with DiscJuggler.) I think this is the
Patin-Couffin ASPI-type driver, which apparently offers an “exclusive
access” mode where it blocks all other read requests.

I don’t know whether a raw read mechanism could bypass such filter
manipulations, but it seems like it would be a good thing to know how to do.

Thanks,

David

Norbert Kawulski wrote:

Just another great Utility from sysinternals !!!

http://www.sysinternals.com/ntw2k/freeware/rootkitreveal.shtml

:-)))

Thanks Bryce and Mark.

Norbert.

“Only those who attempt the absurd can achieve the impossible.”

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@safend.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

3

Hi Ivona,

I’m missing something here: CreateFile and ReadFile requests still
traverse the device stack, so the data can be manipulated by filter
drivers (and system or dispatch hooks). How can a rootkit revealer
trust anything returned by ReadFile?

– David

ivona prenosilova wrote:

Hello David,

Thursday, March 10, 2005, 1:32:31 AM, you wrote:

DL> The webpage for rootkitreveal mentions doing “raw reads” of the
DL> filesystem (and registry hive) for comparison to the data returned by
DL> normal reads. Please forgive the naive question, but how are raw reads
DL> done?
it’s CreateFile on \.<x>: and then ReadFile on
> handle obtained. raw in this case means that the rootkitreveal
> interprets the data on his own. it has built in filesystem code that
> it uses for file/directory traversal and code that can understand the
> hive format. nothin more, nothing less.
>
> but well, ain’t it all written on that page?
>

4

Hello David,

Thursday, March 10, 2005, 11:14:00 AM, you wrote:
DL> I’m missing something here: CreateFile and ReadFile requests still
DL> traverse the device stack, so the data can be manipulated by filter
DL> drivers (and system or dispatch hooks). How can a rootkit revealer
DL> trust anything returned by ReadFile?
it cannot. the current assumption is that none of the rootkit authors
is able to fake NTFS data structures or hive data - it’s written on
the page of the revelaer (“However, this would require a level of
sophistication not seen in rootkits to date.”). i give it month or
two. it’s a nice challenge for someone willing to spend his time.

–
Best regards,
Ivona Prenosilova

5

I guess it would be more robust to create a boot disk that reads the raw
device and calculates the MD5 hashes of the files and compares them to a
known signature store? It doesn’t seem like it would be *that* much
harder (he says, having never done anything of the sort :-)…

That would be proof against anything short of a BIOS rootkit…

Shahar Talmi wrote:

David,

The following paragraph is from the rootkitrevealer page:

"
Can a Rootkit hide from RootkitRevealer?
It is theoretically possible for a rootkit to hide from RootkitRevealer.
Doing so would require intercepting RootkitRevealer’s reads of Registry hive
data or file system data and changing the contents of the data such that the
rootkit’s Registry data or files are not present. However, this would
require a level of sophistication not seen in rootkits to date. Changes to
the data would require both an intimate knowledge of the NTFS, FAT and
Registry hive formats, plus the ability to change data structures such that
they hide the rootkit, but do not cause inconsistent or invalid structures
or side-effect discrepancies that would be flagged by RootkitRevealer.
"

My understanding is that the rootkitrevealer simply reads the registry hive
and file system tables from the disk and parses them just like the registry
API and file system driver would. This comes to detect hooking of kernel and
user mode API’s that are related to registry and file system. A disk filter
that fakes the data that is read from the disk will certainly will not be
detected by this tool. Then again you can read the last sentence in the
quoted paragraph - this is not a simple task, not even remotely close in its
difficulty to API hooking.

Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Lavo
Sent: Thursday, March 10, 2005 2:33 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Inspiration

The webpage for rootkitreveal mentions doing “raw reads” of the filesystem
(and registry hive) for comparison to the data returned by normal reads.
Please forgive the naive question, but how are raw reads done?

I ask because yesterday I was trying to read something from a CdRom and
found that all my read requests were blocked by a lower filter driver called
“pfc.sys”. (This was during a rip with DiscJuggler.) I think this is the
Patin-Couffin ASPI-type driver, which apparently offers an “exclusive
access” mode where it blocks all other read requests.

I don’t know whether a raw read mechanism could bypass such filter
manipulations, but it seems like it would be a good thing to know how to do.

Thanks,

David

Norbert Kawulski wrote:

>Just another great Utility from sysinternals !!!
>
>http://www.sysinternals.com/ntw2k/freeware/rootkitreveal.shtml
>
>:-)))
>
>Thanks Bryce and Mark.
>
>Norbert.
>--------
>“Only those who attempt the absurd can achieve the impossible.”

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@safend.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

–
…/ray..

Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.