Device Enumeration

NTDEV
1

Env: Windows 2000, VC++ 6, SCSI WORM (Magneto-Optical) Drives

Hi, This is my first message to the list and I’m also writing my first
device driver.

I’m building a driver that talk to SCSI WORM (Magneto-Optical) Drivers and
Juke Boxes.

Questions:

1: At boot time, How does my driver know that these devices exist?

2: I do not want drives under the control of my driver to be mounted to the
OS with a drive letters, But I do want to give them their own device name
(ie: \worm0: \worm1: and so on…) (two part question here)
a: Currently the drives auto mount themselves under Window 2000, How do
I unmount them (drive letter)?
b: How to I assign my own share name to these devices? (ie: \worm1: )

Thanks!
Weston Fryatt

2

have you read the storage section of the DDK documents? what you’re
talking about is a class driver and there should be some stuff there to
get you started.

  1. scsiport sends inquiries to every device on the bus. It collects the
    inquiry data and builds PDOs for each LUN attached. It then reports
    these to the plug & play manager. PNP based on the device ID generated
    by scsiport (which is generated from the inquiry data) and the INF files
    in the system directory determines the “best” driver to control the
    device. That driver is loaded and its AddDevice routine is called.

that said - there are several sample class drivers in the DDK which
would be the best place for you to start from. In particular look at
the disk driver (which is the source for the one windows ships with).
You can build a modified version of this (with a different name) to get
installed for your WORM drive.

a) I’m kind of curious why you don’t want the drives to get drive
letters. You can use these to access the devices as easily as you could
use \.\worm0.

b) read about IoCreateSymbolicLink. However this naming scheme doesn’t
work particularly well in a PNP system. Due to changes in
configurations, updates of drivers and removal of devices the namespace
you’re describing can eaisly become sparse and may not remain consistant
from boot to boot. The better option is to use device interfaces -
these generate ridiculously long and complex symbolic links in the
object directory to your device, but they’re enumerable through the
SetupDI API, can be easily tied to the other SetupDI functions (like
installation, removal, update of drivers, installation of filters,
etc…) and just about always point to the same device boot after boot.

-p

-----Original Message-----
From: Weston Fryatt [mailto:xxxxx@muuf.com]
Sent: Friday, October 18, 2002 8:25 AM
To: NT Developers Interest List
Subject: [ntdev] Device Enumeration

Env: Windows 2000, VC++ 6, SCSI WORM (Magneto-Optical) Drives

Hi, This is my first message to the list and I’m also writing my first
device driver.

I’m building a driver that talk to SCSI WORM (Magneto-Optical) Drivers
and Juke Boxes.

Questions:

1: At boot time, How does my driver know that these devices exist?

2: I do not want drives under the control of my driver to be mounted to
the OS with a drive letters, But I do want to give them their own device
name
(ie: \worm0: \worm1: and so on…) (two part question here)
a: Currently the drives auto mount themselves under Window 2000, How
do I unmount them (drive letter)?
b: How to I assign my own share name to these devices? (ie: \worm1:
)

Thanks!
Weston Fryatt

You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

3

This is just the answer I was looking for … Thanks!

The reason why we don’t want to the devices to have a drive letter… Is that
we dealing with highly sensitive medical data. And we’re trying to prevent
an employee from just reading the data right off the disk… or stealing the
disk… (the data is encrypted and the disk is in its own format) The
application will work with the driver directly… so its not really a problem
there… just trying to keep it as secure as possible…

Thanks again!
Weston

----- Original Message -----
From: “Peter Wieland”
To: “NT Developers Interest List”
Sent: Friday, October 18, 2002 12:33 PM
Subject: [ntdev] RE: Device Enumeration

have you read the storage section of the DDK documents? what you’re
talking about is a class driver and there should be some stuff there to
get you started.

1) scsiport sends inquiries to every device on the bus. It collects the
inquiry data and builds PDOs for each LUN attached. It then reports
these to the plug & play manager. PNP based on the device ID generated
by scsiport (which is generated from the inquiry data) and the INF files
in the system directory determines the “best” driver to control the
device. That driver is loaded and its AddDevice routine is called.

that said - there are several sample class drivers in the DDK which
would be the best place for you to start from. In particular look at
the disk driver (which is the source for the one windows ships with).
You can build a modified version of this (with a different name) to get
installed for your WORM drive.

2)

a) I’m kind of curious why you don’t want the drives to get drive
letters. You can use these to access the devices as easily as you could
use \.\worm0.

b) read about IoCreateSymbolicLink. However this naming scheme doesn’t
work particularly well in a PNP system. Due to changes in
configurations, updates of drivers and removal of devices the namespace
you’re describing can eaisly become sparse and may not remain consistant
from boot to boot. The better option is to use device interfaces -
these generate ridiculously long and complex symbolic links in the
object directory to your device, but they’re enumerable through the
SetupDI API, can be easily tied to the other SetupDI functions (like
installation, removal, update of drivers, installation of filters,
etc…) and just about always point to the same device boot after boot.

-p

-----Original Message-----
From: Weston Fryatt [mailto:xxxxx@muuf.com]
Sent: Friday, October 18, 2002 8:25 AM
To: NT Developers Interest List
Subject: [ntdev] Device Enumeration

Env: Windows 2000, VC++ 6, SCSI WORM (Magneto-Optical) Drives

Hi, This is my first message to the list and I’m also writing my first
device driver.

I’m building a driver that talk to SCSI WORM (Magneto-Optical) Drivers
and Juke Boxes.

Questions:

1: At boot time, How does my driver know that these devices exist?

2: I do not want drives under the control of my driver to be mounted to
the OS with a drive letters, But I do want to give them their own device
name
(ie: \worm0: \worm1: and so on…) (two part question here)
a: Currently the drives auto mount themselves under Window 2000, How
do I unmount them (drive letter)?
b: How to I assign my own share name to these devices? (ie: \worm1:
)

Thanks!
Weston Fryatt

—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@muuf.com
To unsubscribe send a blank email to %%email.unsub%%

4

note that anyone who could read from Z: could read from \.\WORM0:.
Just changing the name doesn’t provide you with any security, it just
makes it a bit harder for the causal user to accidentally try and read
the data.

and if you don’t have a file system on the WORM then most causal users
won’t try to access it.

however even in this case device interfaces are still the best bet for
your application to get at the data.

-p

-----Original Message-----
From: Weston Fryatt [mailto:xxxxx@muuf.com]
Sent: Friday, October 18, 2002 11:05 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Device Enumeration

This is just the answer I was looking for … Thanks!

The reason why we don’t want to the devices to have a drive letter… Is
that we dealing with highly sensitive medical data. And we’re trying to
prevent an employee from just reading the data right off the disk… or
stealing the disk… (the data is encrypted and the disk is in its own
format) The application will work with the driver directly… so its not
really a problem there… just trying to keep it as secure as
possible…

Thanks again!
Weston

----- Original Message -----
From: “Peter Wieland”
To: “NT Developers Interest List”
Sent: Friday, October 18, 2002 12:33 PM
Subject: [ntdev] RE: Device Enumeration

have you read the storage section of the DDK documents? what you’re
talking about is a class driver and there should be some stuff there to
get you started.

1) scsiport sends inquiries to every device on the bus. It collects the
inquiry data and builds PDOs for each LUN attached. It then reports
these to the plug & play manager. PNP based on the device ID generated
by scsiport (which is generated from the inquiry data) and the INF files
in the system directory determines the “best” driver to control the
device. That driver is loaded and its AddDevice routine is called.

that said - there are several sample class drivers in the DDK which
would be the best place for you to start from. In particular look at
the disk driver (which is the source for the one windows ships with).
You can build a modified version of this (with a different name) to get
installed for your WORM drive.

2)

a) I’m kind of curious why you don’t want the drives to get drive
letters. You can use these to access the devices as easily as you could
use \.\worm0.

b) read about IoCreateSymbolicLink. However this naming scheme doesn’t
work particularly well in a PNP system. Due to changes in
configurations, updates of drivers and removal of devices the namespace
you’re describing can eaisly become sparse and may not remain consistant
from boot to boot. The better option is to use device interfaces -
these generate ridiculously long and complex symbolic links in the
object directory to your device, but they’re enumerable through the
SetupDI API, can be easily tied to the other SetupDI functions (like
installation, removal, update of drivers, installation of filters,
etc…) and just about always point to the same device boot after boot.

-p

-----Original Message-----
From: Weston Fryatt [mailto:xxxxx@muuf.com]
Sent: Friday, October 18, 2002 8:25 AM
To: NT Developers Interest List
Subject: [ntdev] Device Enumeration

Env: Windows 2000, VC++ 6, SCSI WORM (Magneto-Optical) Drives

Hi, This is my first message to the list and I’m also writing my first
device driver.

I’m building a driver that talk to SCSI WORM (Magneto-Optical) Drivers
and Juke Boxes.

Questions:

1: At boot time, How does my driver know that these devices exist?

2: I do not want drives under the control of my driver to be mounted to
the OS with a drive letters, But I do want to give them their own device
name
(ie: \worm0: \worm1: and so on…) (two part question here)
a: Currently the drives auto mount themselves under Window 2000, How
do I unmount them (drive letter)?
b: How to I assign my own share name to these devices? (ie: \worm1:
)

Thanks!
Weston Fryatt

—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@muuf.com
To unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

5

You can use the numbers 0 - 9 as drive letters. Explorer and other
applications will not see these drive letters during an enumeration, but
if you open the file like this: “4:\path\dir\file.ext”, it will work.

Also, under XP, drive letters can be assigned on a process-by-process
basis. So, only your process will see your drive letter.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Weston Fryatt
Sent: Friday, October 18, 2002 11:05 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Device Enumeration

This is just the answer I was looking for … Thanks!

The reason why we don’t want to the devices to have a drive letter… Is
that
we dealing with highly sensitive medical data. And we’re trying to
prevent
an employee from just reading the data right off the disk… or stealing
the
disk… (the data is encrypted and the disk is in its own format) The
application will work with the driver directly… so its not really a
problem
there… just trying to keep it as secure as possible…

Thanks again!
Weston

----- Original Message -----
From: “Peter Wieland”
To: “NT Developers Interest List”
Sent: Friday, October 18, 2002 12:33 PM
Subject: [ntdev] RE: Device Enumeration

have you read the storage section of the DDK documents? what you’re
talking about is a class driver and there should be some stuff there to
get you started.

1) scsiport sends inquiries to every device on the bus. It collects the
inquiry data and builds PDOs for each LUN attached. It then reports
these to the plug & play manager. PNP based on the device ID generated
by scsiport (which is generated from the inquiry data) and the INF files
in the system directory determines the “best” driver to control the
device. That driver is loaded and its AddDevice routine is called.

that said - there are several sample class drivers in the DDK which
would be the best place for you to start from. In particular look at
the disk driver (which is the source for the one windows ships with).
You can build a modified version of this (with a different name) to get
installed for your WORM drive.

2)

a) I’m kind of curious why you don’t want the drives to get drive
letters. You can use these to access the devices as easily as you could
use \.\worm0.

b) read about IoCreateSymbolicLink. However this naming scheme doesn’t
work particularly well in a PNP system. Due to changes in
configurations, updates of drivers and removal of devices the namespace
you’re describing can eaisly become sparse and may not remain consistant
from boot to boot. The better option is to use device interfaces -
these generate ridiculously long and complex symbolic links in the
object directory to your device, but they’re enumerable through the
SetupDI API, can be easily tied to the other SetupDI functions (like
installation, removal, update of drivers, installation of filters,
etc…) and just about always point to the same device boot after boot.

-p

-----Original Message-----
From: Weston Fryatt [mailto:xxxxx@muuf.com]
Sent: Friday, October 18, 2002 8:25 AM
To: NT Developers Interest List
Subject: [ntdev] Device Enumeration

Env: Windows 2000, VC++ 6, SCSI WORM (Magneto-Optical) Drives

Hi, This is my first message to the list and I’m also writing my first
device driver.

I’m building a driver that talk to SCSI WORM (Magneto-Optical) Drivers
and Juke Boxes.

Questions:

1: At boot time, How does my driver know that these devices exist?

2: I do not want drives under the control of my driver to be mounted to
the OS with a drive letters, But I do want to give them their own device
name
(ie: \worm0: \worm1: and so on…) (two part question here)
a: Currently the drives auto mount themselves under Window 2000, How
do I unmount them (drive letter)?
b: How to I assign my own share name to these devices? (ie: \worm1:
)

Thanks!
Weston Fryatt

—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@muuf.com
To unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%

6

you can use them, but that’s no different from using \.\Tape0:, and
still provides no actual security.

in XP drive letters can be assigned per session. They are not per
process.

-p

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Friday, October 18, 2002 11:18 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Device Enumeration

You can use the numbers 0 - 9 as drive letters. Explorer and other
applications will not see these drive letters during an enumeration, but
if you open the file like this: “4:\path\dir\file.ext”, it will work.

Also, under XP, drive letters can be assigned on a process-by-process
basis. So, only your process will see your drive letter.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Weston Fryatt
Sent: Friday, October 18, 2002 11:05 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Device Enumeration

This is just the answer I was looking for … Thanks!

The reason why we don’t want to the devices to have a drive letter… Is
that we dealing with highly sensitive medical data. And we’re trying to
prevent an employee from just reading the data right off the disk… or
stealing the disk… (the data is encrypted and the disk is in its own
format) The application will work with the driver directly… so its not
really a problem there… just trying to keep it as secure as
possible…

Thanks again!
Weston

----- Original Message -----
From: “Peter Wieland”
To: “NT Developers Interest List”
Sent: Friday, October 18, 2002 12:33 PM
Subject: [ntdev] RE: Device Enumeration

have you read the storage section of the DDK documents? what you’re
talking about is a class driver and there should be some stuff there to
get you started.

1) scsiport sends inquiries to every device on the bus. It collects the
inquiry data and builds PDOs for each LUN attached. It then reports
these to the plug & play manager. PNP based on the device ID generated
by scsiport (which is generated from the inquiry data) and the INF files
in the system directory determines the “best” driver to control the
device. That driver is loaded and its AddDevice routine is called.

that said - there are several sample class drivers in the DDK which
would be the best place for you to start from. In particular look at
the disk driver (which is the source for the one windows ships with).
You can build a modified version of this (with a different name) to get
installed for your WORM drive.

2)

a) I’m kind of curious why you don’t want the drives to get drive
letters. You can use these to access the devices as easily as you could
use \.\worm0.

b) read about IoCreateSymbolicLink. However this naming scheme doesn’t
work particularly well in a PNP system. Due to changes in
configurations, updates of drivers and removal of devices the namespace
you’re describing can eaisly become sparse and may not remain consistant
from boot to boot. The better option is to use device interfaces -
these generate ridiculously long and complex symbolic links in the
object directory to your device, but they’re enumerable through the
SetupDI API, can be easily tied to the other SetupDI functions (like
installation, removal, update of drivers, installation of filters,
etc…) and just about always point to the same device boot after boot.

-p

-----Original Message-----
From: Weston Fryatt [mailto:xxxxx@muuf.com]
Sent: Friday, October 18, 2002 8:25 AM
To: NT Developers Interest List
Subject: [ntdev] Device Enumeration

Env: Windows 2000, VC++ 6, SCSI WORM (Magneto-Optical) Drives

Hi, This is my first message to the list and I’m also writing my first
device driver.

I’m building a driver that talk to SCSI WORM (Magneto-Optical) Drivers
and Juke Boxes.

Questions:

1: At boot time, How does my driver know that these devices exist?

2: I do not want drives under the control of my driver to be mounted to
the OS with a drive letters, But I do want to give them their own device
name
(ie: \worm0: \worm1: and so on…) (two part question here)
a: Currently the drives auto mount themselves under Window 2000, How
do I unmount them (drive letter)?
b: How to I assign my own share name to these devices? (ie: \worm1:
)

Thanks!
Weston Fryatt

—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@muuf.com
To unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

7

From my read, he is not interested in high-level security, just
something to keep the average user from directly accessing the data. He
also states that the data is encrypted.

If he just wants to protect his users from themselves, hiding a drive
letter may do the trick.

>in XP drive letters can be assigned per session. They are not per
process.<<

Interesting… How can I be so wrong? I better investigate.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Friday, October 18, 2002 11:39 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Device Enumeration

you can use them, but that’s no different from using \.\Tape0:, and
still provides no actual security.

in XP drive letters can be assigned per session. They are not per
process.

-p

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Friday, October 18, 2002 11:18 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Device Enumeration

You can use the numbers 0 - 9 as drive letters. Explorer and other
applications will not see these drive letters during an enumeration, but
if you open the file like this: “4:\path\dir\file.ext”, it will work.

Also, under XP, drive letters can be assigned on a process-by-process
basis. So, only your process will see your drive letter.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Weston Fryatt
Sent: Friday, October 18, 2002 11:05 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Device Enumeration

This is just the answer I was looking for … Thanks!

The reason why we don’t want to the devices to have a drive letter… Is
that we dealing with highly sensitive medical data. And we’re trying to
prevent an employee from just reading the data right off the disk… or
stealing the disk… (the data is encrypted and the disk is in its own
format) The application will work with the driver directly… so its not
really a problem there… just trying to keep it as secure as
possible…

Thanks again!
Weston

----- Original Message -----
From: “Peter Wieland”
To: “NT Developers Interest List”
Sent: Friday, October 18, 2002 12:33 PM
Subject: [ntdev] RE: Device Enumeration

have you read the storage section of the DDK documents? what you’re
talking about is a class driver and there should be some stuff there to
get you started.

1) scsiport sends inquiries to every device on the bus. It collects the
inquiry data and builds PDOs for each LUN attached. It then reports
these to the plug & play manager. PNP based on the device ID generated
by scsiport (which is generated from the inquiry data) and the INF files
in the system directory determines the “best” driver to control the
device. That driver is loaded and its AddDevice routine is called.

that said - there are several sample class drivers in the DDK which
would be the best place for you to start from. In particular look at
the disk driver (which is the source for the one windows ships with).
You can build a modified version of this (with a different name) to get
installed for your WORM drive.

2)

a) I’m kind of curious why you don’t want the drives to get drive
letters. You can use these to access the devices as easily as you could
use \.\worm0.

b) read about IoCreateSymbolicLink. However this naming scheme doesn’t
work particularly well in a PNP system. Due to changes in
configurations, updates of drivers and removal of devices the namespace
you’re describing can eaisly become sparse and may not remain consistant
from boot to boot. The better option is to use device interfaces -
these generate ridiculously long and complex symbolic links in the
object directory to your device, but they’re enumerable through the
SetupDI API, can be easily tied to the other SetupDI functions (like
installation, removal, update of drivers, installation of filters,
etc…) and just about always point to the same device boot after boot.

-p

-----Original Message-----
From: Weston Fryatt [mailto:xxxxx@muuf.com]
Sent: Friday, October 18, 2002 8:25 AM
To: NT Developers Interest List
Subject: [ntdev] Device Enumeration

Env: Windows 2000, VC++ 6, SCSI WORM (Magneto-Optical) Drives

Hi, This is my first message to the list and I’m also writing my first
device driver.

I’m building a driver that talk to SCSI WORM (Magneto-Optical) Drivers
and Juke Boxes.

Questions:

1: At boot time, How does my driver know that these devices exist?

2: I do not want drives under the control of my driver to be mounted to
the OS with a drive letters, But I do want to give them their own device
name
(ie: \worm0: \worm1: and so on…) (two part question here)
a: Currently the drives auto mount themselves under Window 2000, How
do I unmount them (drive letter)?
b: How to I assign my own share name to these devices? (ie: \worm1:
)

Thanks!
Weston Fryatt

—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@muuf.com
To unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%

8

“Jamey Kirby” wrote in message news:xxxxx@ntdev…
>
> You can use the numbers 0 - 9 as drive letters. Explorer and other
> applications will not see these drive letters during an enumeration, but
> if you open the file like this: “4:\path\dir\file.ext”, it will work.
>

I didn’t know that!?

Seriously, that’s one of the funniest things I’ve read on this list in a
while… While certainly only “security though obscurity”, that’s a great
tip!

Thanks Jamey!

Peter
OSR

9

Right now… I’m accessing the device via \.\SCSI2: and so on… it works
for my testing… but how can I make a driver to where only my application
could access it? I really don’t have to make it impossible… I just want to
make it very difficult to keep the data secure. I’m sure if a true hack
were to get a hold it the disk… it would be a no brainier to crack it… But
that would be very unlikely to happen… Just trying to keep your average Joe
Doe user and system administrator out of the data they shouldn’t be in.

Thanks
Weston

----- Original Message -----
From: “Peter Wieland”
To: “NT Developers Interest List”
Sent: Friday, October 18, 2002 1:13 PM
Subject: [ntdev] RE: Device Enumeration

note that anyone who could read from Z: could read from \.\WORM0:.
Just changing the name doesn’t provide you with any security, it just
makes it a bit harder for the causal user to accidentally try and read
the data.

and if you don’t have a file system on the WORM then most causal users
won’t try to access it.

however even in this case device interfaces are still the best bet for
your application to get at the data.

-p

-----Original Message-----
From: Weston Fryatt [mailto:xxxxx@muuf.com]
Sent: Friday, October 18, 2002 11:05 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Device Enumeration

This is just the answer I was looking for … Thanks!

The reason why we don’t want to the devices to have a drive letter… Is
that we dealing with highly sensitive medical data. And we’re trying to
prevent an employee from just reading the data right off the disk… or
stealing the disk… (the data is encrypted and the disk is in its own
format) The application will work with the driver directly… so its not
really a problem there… just trying to keep it as secure as
possible…

Thanks again!
Weston

----- Original Message -----
From: “Peter Wieland”
To: “NT Developers Interest List”
Sent: Friday, October 18, 2002 12:33 PM
Subject: [ntdev] RE: Device Enumeration

have you read the storage section of the DDK documents? what you’re
talking about is a class driver and there should be some stuff there to
get you started.

1) scsiport sends inquiries to every device on the bus. It collects the
inquiry data and builds PDOs for each LUN attached. It then reports
these to the plug & play manager. PNP based on the device ID generated
by scsiport (which is generated from the inquiry data) and the INF files
in the system directory determines the “best” driver to control the
device. That driver is loaded and its AddDevice routine is called.

that said - there are several sample class drivers in the DDK which
would be the best place for you to start from. In particular look at
the disk driver (which is the source for the one windows ships with).
You can build a modified version of this (with a different name) to get
installed for your WORM drive.

2)

a) I’m kind of curious why you don’t want the drives to get drive
letters. You can use these to access the devices as easily as you could
use \.\worm0.

b) read about IoCreateSymbolicLink. However this naming scheme doesn’t
work particularly well in a PNP system. Due to changes in
configurations, updates of drivers and removal of devices the namespace
you’re describing can eaisly become sparse and may not remain consistant
from boot to boot. The better option is to use device interfaces -
these generate ridiculously long and complex symbolic links in the
object directory to your device, but they’re enumerable through the
SetupDI API, can be easily tied to the other SetupDI functions (like
installation, removal, update of drivers, installation of filters,
etc…) and just about always point to the same device boot after boot.

-p

-----Original Message-----
From: Weston Fryatt [mailto:xxxxx@muuf.com]
Sent: Friday, October 18, 2002 8:25 AM
To: NT Developers Interest List
Subject: [ntdev] Device Enumeration

Env: Windows 2000, VC++ 6, SCSI WORM (Magneto-Optical) Drives

Hi, This is my first message to the list and I’m also writing my first
device driver.

I’m building a driver that talk to SCSI WORM (Magneto-Optical) Drivers
and Juke Boxes.

Questions:

1: At boot time, How does my driver know that these devices exist?

2: I do not want drives under the control of my driver to be mounted to
the OS with a drive letters, But I do want to give them their own device
name
(ie: \worm0: \worm1: and so on…) (two part question here)
a: Currently the drives auto mount themselves under Window 2000, How
do I unmount them (drive letter)?
b: How to I assign my own share name to these devices? (ie: \worm1:
)

Thanks!
Weston Fryatt

—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@muuf.com
To unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@muuf.com
To unsubscribe send a blank email to %%email.unsub%%

10

but since any average Joe Doe user or the system administrator could
just run your application (perhaps under the debugger or hacked so the
data is dumped to an unprotected file) what’s the advantage of trying to
tie the driver to your app?

security is based around the identity of the user running the
application or requesting the data. There are methods to keep Joe Doe
user from getting the data. System Administrator is harder since they
can override any security settings you set, but with auditing enabled
it’s very hard to get rid of all the fingerprints indicating that this
was done.

you could go beyond this and encrypt the data. now you have to keep all
your keys secret as well as all the unencrypted data, but that’s
possible if the machine has been configured correctly by the admin.

so who is allowed to read the data on the disk?

-p

-----Original Message-----
From: Weston Fryatt [mailto:xxxxx@muuf.com]
Sent: Friday, October 18, 2002 12:06 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Device Enumeration

Right now… I’m accessing the device via \.\SCSI2: and so on… it
works for my testing… but how can I make a driver to where only my
application could access it? I really don’t have to make it
impossible… I just want to make it very difficult to keep the data
secure. I’m sure if a true hack were to get a hold it the disk… it
would be a no brainier to crack it… But that would be very unlikely to
happen… Just trying to keep your average Joe Doe user and system
administrator out of the data they shouldn’t be in.

Thanks
Weston

----- Original Message -----
From: “Peter Wieland”
To: “NT Developers Interest List”
Sent: Friday, October 18, 2002 1:13 PM
Subject: [ntdev] RE: Device Enumeration

note that anyone who could read from Z: could read from \.\WORM0:. Just
changing the name doesn’t provide you with any security, it just makes
it a bit harder for the causal user to accidentally try and read the
data.

and if you don’t have a file system on the WORM then most causal users
won’t try to access it.

however even in this case device interfaces are still the best bet for
your application to get at the data.

-p

-----Original Message-----
From: Weston Fryatt [mailto:xxxxx@muuf.com]
Sent: Friday, October 18, 2002 11:05 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Device Enumeration

This is just the answer I was looking for … Thanks!

The reason why we don’t want to the devices to have a drive letter… Is
that we dealing with highly sensitive medical data. And we’re trying to
prevent an employee from just reading the data right off the disk… or
stealing the disk… (the data is encrypted and the disk is in its own
format) The application will work with the driver directly… so its not
really a problem there… just trying to keep it as secure as
possible…

Thanks again!
Weston

----- Original Message -----
From: “Peter Wieland”
To: “NT Developers Interest List”
Sent: Friday, October 18, 2002 12:33 PM
Subject: [ntdev] RE: Device Enumeration

have you read the storage section of the DDK documents? what you’re
talking about is a class driver and there should be some stuff there to
get you started.

1) scsiport sends inquiries to every device on the bus. It collects the
inquiry data and builds PDOs for each LUN attached. It then reports
these to the plug & play manager. PNP based on the device ID generated
by scsiport (which is generated from the inquiry data) and the INF files
in the system directory determines the “best” driver to control the
device. That driver is loaded and its AddDevice routine is called.

that said - there are several sample class drivers in the DDK which
would be the best place for you to start from. In particular look at
the disk driver (which is the source for the one windows ships with).
You can build a modified version of this (with a different name) to get
installed for your WORM drive.

2)

a) I’m kind of curious why you don’t want the drives to get drive
letters. You can use these to access the devices as easily as you could
use \.\worm0.

b) read about IoCreateSymbolicLink. However this naming scheme doesn’t
work particularly well in a PNP system. Due to changes in
configurations, updates of drivers and removal of devices the namespace
you’re describing can eaisly become sparse and may not remain consistant
from boot to boot. The better option is to use device interfaces -
these generate ridiculously long and complex symbolic links in the
object directory to your device, but they’re enumerable through the
SetupDI API, can be easily tied to the other SetupDI functions (like
installation, removal, update of drivers, installation of filters,
etc…) and just about always point to the same device boot after boot.

-p

-----Original Message-----
From: Weston Fryatt [mailto:xxxxx@muuf.com]
Sent: Friday, October 18, 2002 8:25 AM
To: NT Developers Interest List
Subject: [ntdev] Device Enumeration

Env: Windows 2000, VC++ 6, SCSI WORM (Magneto-Optical) Drives

Hi, This is my first message to the list and I’m also writing my first
device driver.

I’m building a driver that talk to SCSI WORM (Magneto-Optical) Drivers
and Juke Boxes.

Questions:

1: At boot time, How does my driver know that these devices exist?

2: I do not want drives under the control of my driver to be mounted to
the OS with a drive letters, But I do want to give them their own device
name
(ie: \worm0: \worm1: and so on…) (two part question here)
a: Currently the drives auto mount themselves under Window 2000, How
do I unmount them (drive letter)?
b: How to I assign my own share name to these devices? (ie: \worm1:
)

Thanks!
Weston Fryatt

—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@muuf.com
To unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@muuf.com
To unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

11

> I’m building a driver that talk to SCSI WORM (Magneto-Optical)
Drivers and

Juke Boxes.

Questions:

1: At boot time, How does my driver know that these devices exist?

WORMs will be just disks or CD-ROMs for the OS, unless you have
extremely weird INQUIRY data.

2: I do not want drives under the control of my driver to be mounted
to the
OS with a drive letters, But I do want to give them their own device
name
(ie: \worm0: \worm1: and so on…) (two part question here)

Looks like you need a SCSI bus filter above SCSIPORT and below class
drivers. A tough task.
I would better refuse any weird “special” semantics and implement
WORMs as CD-RWs, using standard OS and app software.

Max

12

You are correct… I’m more after keeping the users out of the data than
making it impossible for them… The application will allow the user access
to the data that they need… but nothing else…

Thanks,
Weston

----- Original Message -----
From: “Jamey Kirby”
To: “NT Developers Interest List”
Sent: Friday, October 18, 2002 1:51 PM
Subject: [ntdev] RE: Device Enumeration

> From my read, he is not interested in high-level security, just
> something to keep the average user from directly accessing the data. He
> also states that the data is encrypted.
>
> If he just wants to protect his users from themselves, hiding a drive
> letter may do the trick.
>
> >>in XP drive letters can be assigned per session. They are not per
> process.<<
>
> Interesting… How can I be so wrong? I better investigate.
>
> Jamey
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
> Sent: Friday, October 18, 2002 11:39 AM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Device Enumeration
>
> you can use them, but that’s no different from using \.\Tape0:, and
> still provides no actual security.
>
> in XP drive letters can be assigned per session. They are not per
> process.
>
> -p
>
> -----Original Message-----
> From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
> Sent: Friday, October 18, 2002 11:18 AM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Device Enumeration
>
>
> You can use the numbers 0 - 9 as drive letters. Explorer and other
> applications will not see these drive letters during an enumeration, but
> if you open the file like this: “4:\path\dir\file.ext”, it will work.
>
> Also, under XP, drive letters can be assigned on a process-by-process
> basis. So, only your process will see your drive letter.
>
> Jamey
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Weston Fryatt
> Sent: Friday, October 18, 2002 11:05 AM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Device Enumeration
>
> This is just the answer I was looking for … Thanks!
>
> The reason why we don’t want to the devices to have a drive letter… Is
> that we dealing with highly sensitive medical data. And we’re trying to
> prevent an employee from just reading the data right off the disk… or
> stealing the disk… (the data is encrypted and the disk is in its own
> format) The application will work with the driver directly… so its not
> really a problem there… just trying to keep it as secure as
> possible…
>
> Thanks again!
> Weston
>
> ----- Original Message -----
> From: “Peter Wieland”
> To: “NT Developers Interest List”
> Sent: Friday, October 18, 2002 12:33 PM
> Subject: [ntdev] RE: Device Enumeration
>
>
> have you read the storage section of the DDK documents? what you’re
> talking about is a class driver and there should be some stuff there to
> get you started.
>
> 1) scsiport sends inquiries to every device on the bus. It collects the
> inquiry data and builds PDOs for each LUN attached. It then reports
> these to the plug & play manager. PNP based on the device ID generated
> by scsiport (which is generated from the inquiry data) and the INF files
> in the system directory determines the “best” driver to control the
> device. That driver is loaded and its AddDevice routine is called.
>
> that said - there are several sample class drivers in the DDK which
> would be the best place for you to start from. In particular look at
> the disk driver (which is the source for the one windows ships with).
> You can build a modified version of this (with a different name) to get
> installed for your WORM drive.
>
> 2)
>
> a) I’m kind of curious why you don’t want the drives to get drive
> letters. You can use these to access the devices as easily as you could
> use \.\worm0.
>
> b) read about IoCreateSymbolicLink. However this naming scheme doesn’t
> work particularly well in a PNP system. Due to changes in
> configurations, updates of drivers and removal of devices the namespace
> you’re describing can eaisly become sparse and may not remain consistant
> from boot to boot. The better option is to use device interfaces -
> these generate ridiculously long and complex symbolic links in the
> object directory to your device, but they’re enumerable through the
> SetupDI API, can be easily tied to the other SetupDI functions (like
> installation, removal, update of drivers, installation of filters,
> etc…) and just about always point to the same device boot after boot.
>
> -p
>
>
>
>
>
> -----Original Message-----
> From: Weston Fryatt [mailto:xxxxx@muuf.com]
> Sent: Friday, October 18, 2002 8:25 AM
> To: NT Developers Interest List
> Subject: [ntdev] Device Enumeration
>
>
> Env: Windows 2000, VC++ 6, SCSI WORM (Magneto-Optical) Drives
>
>
> Hi, This is my first message to the list and I’m also writing my first
> device driver.
>
> I’m building a driver that talk to SCSI WORM (Magneto-Optical) Drivers
> and Juke Boxes.
>
> Questions:
>
> 1: At boot time, How does my driver know that these devices exist?
>
> 2: I do not want drives under the control of my driver to be mounted to
> the OS with a drive letters, But I do want to give them their own device
> name
> (ie: \worm0: \worm1: and so on…) (two part question here)
> a: Currently the drives auto mount themselves under Window 2000, How
> do I unmount them (drive letter)?
> b: How to I assign my own share name to these devices? (ie: \worm1:
> )
>
> Thanks!
> Weston Fryatt
>
>
>
>
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@microsoft.com To
> unsubscribe send a blank email to %%email.unsub%%
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@muuf.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> unsubscribe send a blank email to %%email.unsub%%
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@microsoft.com To
> unsubscribe send a blank email to %%email.unsub%%
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@muuf.com
> To unsubscribe send a blank email to %%email.unsub%%
>

13

The app is a client/server application where the user must log into it and
then every item of data in the app has a specific security bit assigned to
it.
So if the user doesn’t have access to an item of data, They won’t even know
that it exist. The server (or servers) will be lock in a secured server
room. The WORM drives or JukeBoxes will only be connected to these
server(s) and won’t be shared on the network. So its pretty safe already…
I’m just trying to prevent a user or an administrator that has access to the
server from looking at data on these disks.

I’m using a simple encryption to mainly scramble the data on the disk and
the disk are written in my own format (not NTFS or UDF or any other standard
file system).

You have to consider … you won’t want your medical data to be public
knowledge… and that the reason for all of the security.

Thanks,
Weston

----- Original Message -----
From: “Peter Wieland”
To: “NT Developers Interest List”
Sent: Friday, October 18, 2002 2:29 PM
Subject: [ntdev] RE: Device Enumeration

but since any average Joe Doe user or the system administrator could
just run your application (perhaps under the debugger or hacked so the
data is dumped to an unprotected file) what’s the advantage of trying to
tie the driver to your app?

security is based around the identity of the user running the
application or requesting the data. There are methods to keep Joe Doe
user from getting the data. System Administrator is harder since they
can override any security settings you set, but with auditing enabled
it’s very hard to get rid of all the fingerprints indicating that this
was done.

you could go beyond this and encrypt the data. now you have to keep all
your keys secret as well as all the unencrypted data, but that’s
possible if the machine has been configured correctly by the admin.

so who is allowed to read the data on the disk?

-p

14

if you’re not using an NT recognized file system on the disk then leave
the drive letter exposed. The users’s won’t see any files and won’t be
able to get at any of the data through explorer. You’ll still be
stopping casual use.

-p

-----Original Message-----
From: Weston Fryatt [mailto:xxxxx@muuf.com]
Sent: Friday, October 18, 2002 2:36 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Device Enumeration

The app is a client/server application where the user must log into it
and then every item of data in the app has a specific security bit
assigned to it. So if the user doesn’t have access to an item of data,
They won’t even know that it exist. The server (or servers) will be
lock in a secured server room. The WORM drives or JukeBoxes will only
be connected to these
server(s) and won’t be shared on the network. So its pretty safe
already… I’m just trying to prevent a user or an administrator that has
access to the server from looking at data on these disks.

I’m using a simple encryption to mainly scramble the data on the disk
and the disk are written in my own format (not NTFS or UDF or any other
standard file system).

You have to consider … you won’t want your medical data to be public
knowledge… and that the reason for all of the security.

Thanks,
Weston

----- Original Message -----
From: “Peter Wieland”
To: “NT Developers Interest List”
Sent: Friday, October 18, 2002 2:29 PM
Subject: [ntdev] RE: Device Enumeration

but since any average Joe Doe user or the system administrator could
just run your application (perhaps under the debugger or hacked so the
data is dumped to an unprotected file) what’s the advantage of trying to
tie the driver to your app?

security is based around the identity of the user running the
application or requesting the data. There are methods to keep Joe Doe
user from getting the data. System Administrator is harder since they
can override any security settings you set, but with auditing enabled
it’s very hard to get rid of all the fingerprints indicating that this
was done.

you could go beyond this and encrypt the data. now you have to keep all
your keys secret as well as all the unencrypted data, but that’s
possible if the machine has been configured correctly by the admin.

so who is allowed to read the data on the disk?

-p

—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

15

> > You can use the numbers 0 - 9 as drive letters. Explorer and other

> applications will not see these drive letters during an
enumeration, but
> if you open the file like this: “4:\path\dir\file.ext”, it will
work.
>

I didn’t know that!?

Seriously, that’s one of the funniest things I’ve read on this list
in a
while… While certainly only “security though obscurity”, that’s a
great
tip!

IoCreateSymbolicLink allows this, dunno of user-mode DefineDosDevice.

Max