Opening the file during Volume Initialization?

NTFSD
1

Hi All,

I want to open my driver file to calculate the checksum and if it
doesn’t match then i don’t want to load my driver.

So i was trying to do this in Driver Entry.

I query the symbolic link object for “sysroot” (using
ZwOpenSymbolicLinkObject) and i got
“\ArcName\multi(0)disk(0)rdisk(0)partition(3)\Windows”

When i pass this to zwcreatefile, which doesn’t like it and give me
error “object_not_found”. I can understand this is too early and
symbolic links are probably not set. Same thing happened when i tried
this during “Instancesetup”.

So i thought may be something wrong in my code, so i tried it on another
volume which is not the boot volume and got
“\Device\Harddisk0\Partition32Windows” as symbolic link object and it
worked fine. So it seems symbolic links and others are fine at this point.

So is there any way to open the file and read it during Instance Setup
or DriverEntry before? Or i will have to perform this check somewhere else?

thanks

2

Why do you think you need to use something less accurate to double check
what the system has already done? If you’re on a 64 bit system the driver
must have a certificate that provides a far better check on your driver than
your piddling little checksum can ever provide, so why do you think running
a checksum on running code is better than what the system already provides?

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Rajesh Gupta
Sent: Thursday, September 02, 2010 1:48 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Opening the file during Volume Initialization?

Hi All,

I want to open my driver file to calculate the checksum and if it doesn’t
match then i don’t want to load my driver.

So i was trying to do this in Driver Entry.

I query the symbolic link object for “sysroot” (using
ZwOpenSymbolicLinkObject) and i got
“\ArcName\multi(0)disk(0)rdisk(0)partition(3)\Windows”

When i pass this to zwcreatefile, which doesn’t like it and give me error
“object_not_found”. I can understand this is too early and symbolic links
are probably not set. Same thing happened when i tried this during
“Instancesetup”.

So i thought may be something wrong in my code, so i tried it on another
volume which is not the boot volume and got
“\Device\Harddisk0\Partition32Windows” as symbolic link object and it worked
fine. So it seems symbolic links and others are fine at this point.

So is there any way to open the file and read it during Instance Setup or
DriverEntry before? Or i will have to perform this check somewhere else?

thanks

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars (including our new fs
mini-filter seminar) 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

3

For certifications.

Some of the security certifications needs this and if anyone tempered
with the file, driver needs to disable the functionality.

thanks

On 9/2/2010 12:15 PM, Gary G. Little wrote:

Why do you think you need to use something less accurate to double check
what the system has already done? If you’re on a 64 bit system the driver
must have a certificate that provides a far better check on your driver than
your piddling little checksum can ever provide, so why do you think running
a checksum on running code is better than what the system already provides?

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Rajesh Gupta
Sent: Thursday, September 02, 2010 1:48 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Opening the file during Volume Initialization?

Hi All,

I want to open my driver file to calculate the checksum and if it doesn’t
match then i don’t want to load my driver.

So i was trying to do this in Driver Entry.

I query the symbolic link object for “sysroot” (using
ZwOpenSymbolicLinkObject) and i got
“\ArcName\multi(0)disk(0)rdisk(0)partition(3)\Windows”

When i pass this to zwcreatefile, which doesn’t like it and give me error
“object_not_found”. I can understand this is too early and symbolic links
are probably not set. Same thing happened when i tried this during
“Instancesetup”.

So i thought may be something wrong in my code, so i tried it on another
volume which is not the boot volume and got
“\Device\Harddisk0\Partition32Windows” as symbolic link object and it worked
fine. So it seems symbolic links and others are fine at this point.

So is there any way to open the file and read it during Instance Setup or
DriverEntry before? Or i will have to perform this check somewhere else?

thanks

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars (including our new fs
mini-filter seminar) 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

4

On 9/2/2010 12:47 PM, Rajesh Gupta wrote:

Hi All,

I want to open my driver file to calculate the checksum and if it
doesn’t match then i don’t want to load my driver.

So i was trying to do this in Driver Entry.

I query the symbolic link object for “sysroot” (using
ZwOpenSymbolicLinkObject) and i got
“\ArcName\multi(0)disk(0)rdisk(0)partition(3)\Windows”

A few things, if your filter is a boot start filter then you won’t be
able to access the system partition within your driver entry routine,
the stack isn’t built yet. Same goes for the mount processing, at least
for legacy and I would imagine the same holds for mini-filters, the
stack just isn’t there, the file system stack that is.

Your options would be to delay load your filter, say Start 1 or 2? You
can be sure that the system partition is built and you can access the file.

If this is a security check, then I would think that Instance Setup is
too late, no? If your driver has already been hacked, or perturbed in
some way you don’t like, it’s already in the system by the time your
InstanceSetup gets called so your check would need to be during DriverEntry.

Pete

When i pass this to zwcreatefile, which doesn’t like it and give me
error “object_not_found”. I can understand this is too early and
symbolic links are probably not set. Same thing happened when i tried
this during “Instancesetup”.

So i thought may be something wrong in my code, so i tried it on another
volume which is not the boot volume and got
“\Device\Harddisk0\Partition32Windows” as symbolic link object and it
worked fine. So it seems symbolic links and others are fine at this point.

So is there any way to open the file and read it during Instance Setup
or DriverEntry before? Or i will have to perform this check somewhere else?

thanks

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

5

Thanks Scott,

Yes i understand and that’s the reason you gave that why i wanted to
check it in the driver entry. I understand file system stack is not
their yet.

I am writing/debugging the Mini filter, its same as legacy. Stack is not
built yet.

I don’t have option of starting my driver late either, as this is
security product and we need to start filtering asap.

I guess, at the later stage (may be in the create) i may have to deny
the functionality if the check fails. Thats the only solution i can
think of right now. Wait for volume to initialize and then check the
checksum. I hope when i will start getting precreate, stack will be there.

thanks

On 9/2/2010 1:57 PM, Peter Scott wrote:

On 9/2/2010 12:47 PM, Rajesh Gupta wrote:
> Hi All,
>
> I want to open my driver file to calculate the checksum and if it
> doesn’t match then i don’t want to load my driver.
>
> So i was trying to do this in Driver Entry.
>
> I query the symbolic link object for “sysroot” (using
> ZwOpenSymbolicLinkObject) and i got
> “\ArcName\multi(0)disk(0)rdisk(0)partition(3)\Windows”
>

A few things, if your filter is a boot start filter then you won’t be
able to access the system partition within your driver entry routine,
the stack isn’t built yet. Same goes for the mount processing, at least
for legacy and I would imagine the same holds for mini-filters, the
stack just isn’t there, the file system stack that is.

Your options would be to delay load your filter, say Start 1 or 2? You
can be sure that the system partition is built and you can access the file.

If this is a security check, then I would think that Instance Setup is
too late, no? If your driver has already been hacked, or perturbed in
some way you don’t like, it’s already in the system by the time your
InstanceSetup gets called so your check would need to be during
DriverEntry.

Pete

> When i pass this to zwcreatefile, which doesn’t like it and give me
> error “object_not_found”. I can understand this is too early and
> symbolic links are probably not set. Same thing happened when i tried
> this during “Instancesetup”.
>
> So i thought may be something wrong in my code, so i tried it on another
> volume which is not the boot volume and got
> “\Device\Harddisk0\Partition32Windows” as symbolic link object and it
> worked fine. So it seems symbolic links and others are fine at this
> point.
>
> So is there any way to open the file and read it during Instance Setup
> or DriverEntry before? Or i will have to perform this check somewhere
> else?
>
> thanks
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) 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

6

I guess I don’t quite understand how this should work. The assumption I’m
making is that once the driver is loaded the file isn’t used anymore. So
either the file was already modified at the time DriverEntry was called, in
which case there is nothing that would prevent the attacker to disable this
check you’re implementing, or the file is modified later, in which case it
doesn’t matter, since the driver is already loaded…

Thanks,
Alex.

7

>

I guess, at the later stage (may be in the create) i may have to deny
the functionality if the check fails. Thats the only solution i can
think of right now. Wait for volume to initialize and then check the
checksum. I hope when i will start getting precreate, stack will be there.

The stack will definitely be present when you receive the first
pre-create. But while I am answering your direct question, Alex does
bring up a good point.

Pete

thanks

On 9/2/2010 1:57 PM, Peter Scott wrote:
> On 9/2/2010 12:47 PM, Rajesh Gupta wrote:
>> Hi All,
>>
>> I want to open my driver file to calculate the checksum and if it
>> doesn’t match then i don’t want to load my driver.
>>
>> So i was trying to do this in Driver Entry.
>>
>> I query the symbolic link object for “sysroot” (using
>> ZwOpenSymbolicLinkObject) and i got
>> “\ArcName\multi(0)disk(0)rdisk(0)partition(3)\Windows”
>>
>
> A few things, if your filter is a boot start filter then you won’t be
> able to access the system partition within your driver entry routine,
> the stack isn’t built yet. Same goes for the mount processing, at least
> for legacy and I would imagine the same holds for mini-filters, the
> stack just isn’t there, the file system stack that is.
>
> Your options would be to delay load your filter, say Start 1 or 2? You
> can be sure that the system partition is built and you can access the
> file.
>
> If this is a security check, then I would think that Instance Setup is
> too late, no? If your driver has already been hacked, or perturbed in
> some way you don’t like, it’s already in the system by the time your
> InstanceSetup gets called so your check would need to be during
> DriverEntry.
>
> Pete
>
>> When i pass this to zwcreatefile, which doesn’t like it and give me
>> error “object_not_found”. I can understand this is too early and
>> symbolic links are probably not set. Same thing happened when i tried
>> this during “Instancesetup”.
>>
>> So i thought may be something wrong in my code, so i tried it on another
>> volume which is not the boot volume and got
>> “\Device\Harddisk0\Partition32Windows” as symbolic link object and it
>> worked fine. So it seems symbolic links and others are fine at this
>> point.
>>
>> So is there any way to open the file and read it during Instance Setup
>> or DriverEntry before? Or i will have to perform this check somewhere
>> else?
>>
>> thanks
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> For our schedule of debugging and file system seminars
>> (including our new fs mini-filter seminar) 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
>

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

8

I understand what you are saying Alex.

We are trying to implement FIPS specifications and i think they don’t
protect from the hackers. But they certify that algorithms used are
standard encryption algorithms and no one tampered with the module after
certification. If we make any changes or fix any bug, we need the
certificate again. :slight_smile:

infact i asked the questions, " if someone find out the location of
checksum and update the checksum and binary". Answer was “we don’t care
about that. :slight_smile: Its user responsibility. User needs to check the audit
logs frequently to make sure module is performing FIPS check and its
passing.”

So if checksum fails just deny the functionality. This is how most of
the opensource modules implement fips specification.

i hope it clarifies.

thanks for the reply
Raj

On 9/2/2010 2:13 PM, Alex Carp wrote:

I guess I don’t quite understand how this should work. The assumption I’m
making is that once the driver is loaded the file isn’t used anymore. So
either the file was already modified at the time DriverEntry was called, in
which case there is nothing that would prevent the attacker to disable this
check you’re implementing, or the file is modified later, in which case it
doesn’t matter, since the driver is already loaded…

Thanks,
Alex.

9

Well, it still doesn’t make sense to me. Even the reply “we don’t care about
that. :slight_smile: Its user responsibility. User needs to check the audit logs
frequently to make sure module is performing FIPS check and its passing.”
doesn’t really address the issue, because it relies on the module telling
the auditing subsystem whether it’s performing well… As dr. Peter Gutmann
puts it, it’s like “asking the drunk if he’s drunk”.

As a suggestion, you could use code similar to this one, which has the same
security guarantees and is quite heavily optimized for performance:

If (1 != 1) {

Return STATUS_INVALID_IMAGE_FORMAT;
}

Kidding aside, I guess there isn’t much that you can do other than point out
the contradiction to the person responsible for making the decision.

I think you could wait for instance setup, because in the instance setup
callback you can access files on the volume and before that you’re not in a
position to deny any operations on the volume anyway because there won’t be
any (at least as far as you’re concerned), so there’s nothing for your to
fail…

Thanks,
Alex.

10

Raj,

I know from when we had our crypto core FIPS approved that you are fine
to rely on the system provided image verification, just make sure you
sign your driver with a valid code signing certificate. Self-Test is
something else and should be carried out when the algorithms are going
to be used.

We left it to the operating system to validate the image and provide a
standalone executable for the end user to use in order to validate the
hash of the binary. The expected hash is then published on our website
for the end user to validate against.

The hash of the binary is also written to a signature file that is
installed along with the driver. This is also verified as part of the
self-test/module init.

This ticked all the FIPS boxes and the certification was awarded with
only a few revisions having to be made.

We abstracted the core functionality of the crypto away from the rest of
our system so that it could be validated as a separate entity, much like
FIPS.SYS was abstracted by Microsoft. This simplified the approval
substantially. Maybe this is something you could consider.

Regards

Ben Lewis
Head of Software Development
Data Encryption Systems Ltd.
Silver Street House
Silver Street
Taunton
Somerset
TA1 3DL

Email: xxxxx@des.co.uk

Web: www.deslock.com | www.deskey.co.uk

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Rajesh Gupta
Sent: 02 September 2010 23:23
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Opening the file during Volume Initialization?

I understand what you are saying Alex.

We are trying to implement FIPS specifications and i think they don’t
protect from the hackers. But they certify that algorithms used are
standard encryption algorithms and no one tampered with the module after
certification. If we make any changes or fix any bug, we need the
certificate again. :slight_smile:

infact i asked the questions, " if someone find out the location of
checksum and update the checksum and binary". Answer was “we don’t care
about that. :slight_smile: Its user responsibility. User needs to check the audit
logs frequently to make sure module is performing FIPS check and its
passing.”

So if checksum fails just deny the functionality. This is how most of
the opensource modules implement fips specification.

i hope it clarifies.

thanks for the reply
Raj

On 9/2/2010 2:13 PM, Alex Carp wrote:

I guess I don’t quite understand how this should work. The assumption

I’m making is that once the driver is loaded the file isn’t used
anymore. So either the file was already modified at the time
DriverEntry was called, in which case there is nothing that would
prevent the attacker to disable this check you’re implementing, or the

file is modified later, in which case it doesn’t matter, since the
driver is already loaded…

Thanks,
Alex.

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars (including our
new fs mini-filter seminar) 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

11

> So is there any way to open the file and read it during Instance Setup

or DriverEntry before? Or i will have to perform this check somewhere else?

Of DriverEntry of the boot driver? no reliable ways.

More so: x64 post-Vista OS will do the thing for you, and I think there can be some ways to force x86 post-Vista OS to do the same.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

12

> Yes i understand and that’s the reason you gave that why i wanted to

check it in the driver entry. I understand file system stack is not
their yet.

BTW - why do you need a file for this? In DriverEntry, you have the whole image in memory, just look at it image base (some undoc field in driver object), find the section table in the header, and then do the checksumming section by section.

And yes, IIRC all Windows versions check the PE checksum for boot drivers (as also for KnownDLLs).

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

13

Thanks a lot Maxim. I will definitely explore this. This sounds
promising. I really appreciate this help.

thanks

On 9/3/2010 3:53 AM, Maxim S. Shatskih wrote:

> Yes i understand and that’s the reason you gave that why i wanted to
> check it in the driver entry. I understand file system stack is not
> their yet.

BTW - why do you need a file for this? In DriverEntry, you have the whole image in memory, just look at it image base (some undoc field in driver object), find the section table in the header, and then do the checksumming section by section.

And yes, IIRC all Windows versions check the PE checksum for boot drivers (as also for KnownDLLs).

14

Thanks a lot Ben. If this is true then it would make my life easier. I
will definately talk to the FIPS certification team and explore this.

i really appreciate your help.

thanks

On 9/3/2010 1:40 AM, Ben Lewis wrote:

Raj,

I know from when we had our crypto core FIPS approved that you are fine
to rely on the system provided image verification, just make sure you
sign your driver with a valid code signing certificate. Self-Test is
something else and should be carried out when the algorithms are going
to be used.

We left it to the operating system to validate the image and provide a
standalone executable for the end user to use in order to validate the
hash of the binary. The expected hash is then published on our website
for the end user to validate against.

The hash of the binary is also written to a signature file that is
installed along with the driver. This is also verified as part of the
self-test/module init.

This ticked all the FIPS boxes and the certification was awarded with
only a few revisions having to be made.

We abstracted the core functionality of the crypto away from the rest of
our system so that it could be validated as a separate entity, much like
FIPS.SYS was abstracted by Microsoft. This simplified the approval
substantially. Maybe this is something you could consider.

Regards

Ben Lewis
Head of Software Development
Data Encryption Systems Ltd.
Silver Street House
Silver Street
Taunton
Somerset
TA1 3DL

Email: xxxxx@des.co.uk

Web: www.deslock.com | www.deskey.co.uk

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Rajesh Gupta
Sent: 02 September 2010 23:23
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Opening the file during Volume Initialization?

I understand what you are saying Alex.

We are trying to implement FIPS specifications and i think they don’t
protect from the hackers. But they certify that algorithms used are
standard encryption algorithms and no one tampered with the module after
certification. If we make any changes or fix any bug, we need the
certificate again. :slight_smile:

infact i asked the questions, " if someone find out the location of
checksum and update the checksum and binary". Answer was “we don’t care
about that. :slight_smile: Its user responsibility. User needs to check the audit
logs frequently to make sure module is performing FIPS check and its
passing.”

So if checksum fails just deny the functionality. This is how most of
the opensource modules implement fips specification.

i hope it clarifies.

thanks for the reply
Raj

On 9/2/2010 2:13 PM, Alex Carp wrote:
> I guess I don’t quite understand how this should work. The assumption

> I’m making is that once the driver is loaded the file isn’t used
> anymore. So either the file was already modified at the time
> DriverEntry was called, in which case there is nothing that would
> prevent the attacker to disable this check you’re implementing, or the

> file is modified later, in which case it doesn’t matter, since the
driver is already loaded…
>
> Thanks,
> Alex.
>
>

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars (including our
new fs mini-filter seminar) 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

15

> I think you could wait for instance setup, because in the instance setup

callback you can access files on the volume and before that you’re not in a
position to deny any operations on the volume anyway because there won’t be
any (at least as far as you’re concerned), so there’s nothing for your to
fail…

Sorry for the delayed reply, as i was pulled into other issue.

Hi Alex,

As you mentioned that i can access the files on the volume in the
instance setup. But when my boot volume is being initialized, i can’t
access the file on the volume. But once boot volume is initialized i can
access the files on other volume, as expected as they are already
initialized.

Is there anything i am missing here?

I was thinking about, if my check fails then i will not attach my driver
to the volume as i have to deny the functionality.

thanks