Device Driver - Beginner

NTDEV
21

Thanks Tim.

I think instead of asking about my sample programs I should describe the
final project and let experts here answer about feasibility and
complications involved in it. As that is what customer wants to know
currently, and if possible any other means apart from device driver.

*“The Actual Project”*
We deliver encrypted data and corresponding viewer to customer in a CD.
The viewer is written in VC++. The decryption logic stands as a seperate
library so we need to include its dll and call its functions. Since there
are various othr applications of our project which uses decryption logic, so
we need to use same in all projects/upcoming projects.
Now, the new customer says, he has his own viewer [ without any decryption
capability ] but he would still like to use our encrypted cd’s. So we
proposed him following:

  1. Within the CD we will send a “decryption solution driver”.
  2. User is prompted to install the driver, now after installation it should
    appear as a drive next to CD-ROM drive, for eg if D: for CDROM then E: for
    device driver
  3. The customer will now launch its viewer application, and point it to E:
    [By displaying a dialog and taking user input for driver letter]
  4. Now, what ever data has to be requested from CD, will actually first be
    directed to E: with parameters , the driver will
    now go to CD-ROM get that file, decrypt only the required information and
    send back decrypted data to viewer application, which thus launches it.

    Thats it. Now please guide me for whether it is possible with device driver?
    if yes, how deep knowledge of DD is required and what all concepts I need to
    know atleast for a pilot application [without decryption logic]
    If not, then please cite me with reasons.

    Thanks and Regards,
    Simran

    On Wed, Sep 10, 2008 at 10:37 PM, Tim Roberts wrote:

    > Simran Saun wrote:
    > > I’m more confused now.
    >
    > We are very good at that.
    >
    >
    > > @Crispin, Yes thats what I intend to do, but with a device driver, as
    > > Im trying to learn DD with small sample examples.
    > >
    > > As I had mentioned in my very first post that the actual driver which
    > > has to be designed [the actual project] has different functioanlity
    > > but to get a hang of how driver development proceeds, entry point,
    > > function calls, i/o operations etc happens, is why I’m taking up small
    > > examples and understanding the flow of driver development.
    > > When I had first posted here,I was a novice having no knowlede of what
    > > driver development means. Even now im not an expert, I still don’t
    > > know many many manyX100 concepts, I intend to understand driver
    > > develepopment in a step by step way and which can finally help me in
    > > my project work.
    > > Since I was able to load a driver, call its function using a client
    > > application, I call it passing my 1st stage. Now if I do parallels
    > > with actual project, I see that it has to be installed as a drive
    > > letter without any storage “into” that drive. The client application
    > > has to see this virtual drive and invoke one of the method of driver.
    > > So thats Y I came up with my question of how to map a driver to a
    > > drive letter. I hope now my query is comprehensible.
    >
    > Yes, I think so. Allow me to explore why this conversation headed into
    > the drink so quickly.
    >
    > The typical Windows driver is exposed to user mode as a fake file. To
    > talk to a driver, an application will open the driver by file name, then
    > send read, write, and ioctl requests through that file handle. That is
    > how the vast majority of Windows drivers operate: by pretending to be
    > files. It’s easy and fun, and there are lots of samples.
    >
    > Getting a driver to respond as a drive letter is a MUCH more complicated
    > proposition. Now, instead of just being an ordinary driver, you have to
    > be a storage driver, and you have to adhere to a rather complicated and
    > error-prone storage protocol. I’ve been writing Windows drivers for 18
    > years, and I’ve never written one that pretended to be a drive letter.
    > This is quite different from Linux, where it’s not that hard to expose a
    > new fake file system.
    >
    > What the rest of us are suggesting is this: if your final task does not
    > involve a drive letter, then you should forget about trying to
    > experiment with drive letters. You’ll just dive down rat holes that
    > won’t help your overall learning experience. If your final task DOES
    > involve a fake drive letter, there may be ways to accomplish the task
    > that are easier than a driver.
    >
    > –
    > Tim Roberts, xxxxx@probo.com
    > Providenza & Boekelheide, Inc.
    >
    >
    > —
    > 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
    >
22

There are still a couple of missing data points. Is the ‘encrypted data’ with each file encrypted individually or is the entire storage media encrypted at the sector level? The former will require a file system filter driver, while the second will require a storage filter driver. The previous is not completely true in that you could have a storage driver that exposes sectors formatted as e.g. FAT and then you map them into the files on the CD. This is not easy to do, but is probably easier than most active file system filters. As Tony Mason said, an encryption file system filter is the second most difficult driver to write.

“Simran Saun” wrote in message news:xxxxx@ntdev…
Thanks Tim.

I think instead of asking about my sample programs I should describe the final project and let experts here answer about feasibility and complications involved in it. As that is what customer wants to know currently, and if possible any other means apart from device driver.

“The Actual Project”
We deliver encrypted data and corresponding viewer to customer in a CD.
The viewer is written in VC++. The decryption logic stands as a seperate library so we need to include its dll and call its functions. Since there are various othr applications of our project which uses decryption logic, so we need to use same in all projects/upcoming projects.
Now, the new customer says, he has his own viewer [without any decryption capability] but he would still like to use our encrypted cd’s. So we proposed him following:
1) Within the CD we will send a “decryption solution driver”.
2) User is prompted to install the driver, now after installation it should appear as a drive next to CD-ROM drive, for eg if D: for CDROM then E: for device driver
3) The customer will now launch its viewer application, and point it to E: [By displaying a dialog and taking user input for driver letter]
4) Now, what ever data has to be requested from CD, will actually first be directed to E: with parameters , the driver will now go to CD-ROM get that file, decrypt only the required information and send back decrypted data to viewer application, which thus launches it.

Thats it. Now please guide me for whether it is possible with device driver? if yes, how deep knowledge of DD is required and what all concepts I need to know atleast for a pilot application [without decryption logic]
If not, then please cite me with reasons.

Thanks and Regards,
Simran

On Wed, Sep 10, 2008 at 10:37 PM, Tim Roberts wrote:

Simran Saun wrote:
> I’m more confused now.

We are very good at that.

> @Crispin, Yes thats what I intend to do, but with a device driver, as
> Im trying to learn DD with small sample examples.
>
> As I had mentioned in my very first post that the actual driver which
> has to be designed [the actual project] has different functioanlity
> but to get a hang of how driver development proceeds, entry point,
> function calls, i/o operations etc happens, is why I’m taking up small
> examples and understanding the flow of driver development.
> When I had first posted here,I was a novice having no knowlede of what
> driver development means. Even now im not an expert, I still don’t
> know many many manyX100 concepts, I intend to understand driver
> develepopment in a step by step way and which can finally help me in
> my project work.
> Since I was able to load a driver, call its function using a client
> application, I call it passing my 1st stage. Now if I do parallels
> with actual project, I see that it has to be installed as a drive
> letter without any storage “into” that drive. The client application
> has to see this virtual drive and invoke one of the method of driver.
> So thats Y I came up with my question of how to map a driver to a
> drive letter. I hope now my query is comprehensible.

Yes, I think so. Allow me to explore why this conversation headed into
the drink so quickly.

The typical Windows driver is exposed to user mode as a fake file. To
talk to a driver, an application will open the driver by file name, then
send read, write, and ioctl requests through that file handle. That is
how the vast majority of Windows drivers operate: by pretending to be
files. It’s easy and fun, and there are lots of samples.

Getting a driver to respond as a drive letter is a MUCH more complicated
proposition. Now, instead of just being an ordinary driver, you have to
be a storage driver, and you have to adhere to a rather complicated and
error-prone storage protocol. I’ve been writing Windows drivers for 18
years, and I’ve never written one that pretended to be a drive letter.
This is quite different from Linux, where it’s not that hard to expose a
new fake file system.

What the rest of us are suggesting is this: if your final task does not
involve a drive letter, then you should forget about trying to
experiment with drive letters. You’ll just dive down rat holes that
won’t help your overall learning experience. If your final task DOES
involve a fake drive letter, there may be ways to accomplish the task
that are easier than a driver.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

—

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

23

Encryption is per file basis, there are few files which are encrypted and
few not.
Also, to addd to it, I do not intend to display decrypted data in E: as taht
calls for security threat. So motive is to have a E: to which viewer send io
request, and taht talks to CDrom drive, no storage medium required.

Im googling for flie filter drivers now :slight_smile:
thanks

On Thu, Sep 11, 2008 at 11:28 AM, David Craig wrote:

> There are still a couple of missing data points. Is the ‘encrypted data’
> with each file encrypted individually or is the entire storage media
> encrypted at the sector level? The former will require a file system filter
> driver, while the second will require a storage filter driver. The previous
> is not completely true in that you could have a storage driver that exposes
> sectors formatted as e.g. FAT and then you map them into the files on the
> CD. This is not easy to do, but is probably easier than most active file
> system filters. As Tony Mason said, an encryption file system filter is the
> second most difficult driver to write.
>
>
> “Simran Saun” wrote in message news:xxxxx@ntdev…
> Thanks Tim.
>
> I think instead of asking about my sample programs I should describe the
> final project and let experts here answer about feasibility and
> complications involved in it. As that is what customer wants to know
> currently, and if possible any other means apart from device driver.
>
> “The Actual Project”
> We deliver encrypted data and corresponding viewer to customer in a CD.
> The viewer is written in VC++. The decryption logic stands as a seperate
> library so we need to include its dll and call its functions. Since there
> are various othr applications of our project which uses decryption logic, so
> we need to use same in all projects/upcoming projects.
> Now, the new customer says, he has his own viewer [without any decryption
> capability] but he would still like to use our encrypted cd’s. So we
> proposed him following:
> 1) Within the CD we will send a “decryption solution driver”.
> 2) User is prompted to install the driver, now after installation it should
> appear as a drive next to CD-ROM drive, for eg if D: for CDROM then E: for
> device driver
> 3) The customer will now launch its viewer application, and point it to E:
> [By displaying a dialog and taking user input for driver letter]
> 4) Now, what ever data has to be requested from CD, will actually first be
> directed to E: with parameters , the driver will
> now go to CD-ROM get that file, decrypt only the required information and
> send back decrypted data to viewer application, which thus launches it.
>
> Thats it. Now please guide me for whether it is possible with device
> driver? if yes, how deep knowledge of DD is required and what all concepts I
> need to know atleast for a pilot application [without decryption logic]
> If not, then please cite me with reasons.
>
> Thanks and Regards,
> Simran
>
>
>
> On Wed, Sep 10, 2008 at 10:37 PM, Tim Roberts wrote:
>
>> Simran Saun wrote:
>> > I’m more confused now.
>>
>> We are very good at that.
>>
>>
>> > @Crispin, Yes thats what I intend to do, but with a device driver, as
>> > Im trying to learn DD with small sample examples.
>> >
>> > As I had mentioned in my very first post that the actual driver which
>> > has to be designed [the actual project] has different functioanlity
>> > but to get a hang of how driver development proceeds, entry point,
>> > function calls, i/o operations etc happens, is why I’m taking up small
>> > examples and understanding the flow of driver development.
>> > When I had first posted here,I was a novice having no knowlede of what
>> > driver development means. Even now im not an expert, I still don’t
>> > know many many manyX100 concepts, I intend to understand driver
>> > develepopment in a step by step way and which can finally help me in
>> > my project work.
>> > Since I was able to load a driver, call its function using a client
>> > application, I call it passing my 1st stage. Now if I do parallels
>> > with actual project, I see that it has to be installed as a drive
>> > letter without any storage “into” that drive. The client application
>> > has to see this virtual drive and invoke one of the method of driver.
>> > So thats Y I came up with my question of how to map a driver to a
>> > drive letter. I hope now my query is comprehensible.
>>
>> Yes, I think so. Allow me to explore why this conversation headed into
>> the drink so quickly.
>>
>> The typical Windows driver is exposed to user mode as a fake file. To
>> talk to a driver, an application will open the driver by file name, then
>> send read, write, and ioctl requests through that file handle. That is
>> how the vast majority of Windows drivers operate: by pretending to be
>> files. It’s easy and fun, and there are lots of samples.
>>
>> Getting a driver to respond as a drive letter is a MUCH more complicated
>> proposition. Now, instead of just being an ordinary driver, you have to
>> be a storage driver, and you have to adhere to a rather complicated and
>> error-prone storage protocol. I’ve been writing Windows drivers for 18
>> years, and I’ve never written one that pretended to be a drive letter.
>> This is quite different from Linux, where it’s not that hard to expose a
>> new fake file system.
>>
>> What the rest of us are suggesting is this: if your final task does not
>> involve a drive letter, then you should forget about trying to
>> experiment with drive letters. You’ll just dive down rat holes that
>> won’t help your overall learning experience. If your final task DOES
>> involve a fake drive letter, there may be ways to accomplish the task
>> that are easier than a driver.
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>> —
>> 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
>>
>
>
> —
> 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
>

24

Simran Saun wrote:

How flexible are your design requirements? What type of encryption is
being used and where is the key
stored? What method is being used to determine if a file is encrypted or
not; header/footer, file table, file extension etc.?

While I think that your proposal to include a driver on the cd isn’t
user friendly at all (will require admin rights to install), I do
understand your reasoning if the customer refuses to modify their viewer
at all.

Perhaps a simpler solution would work; instead of creating a ‘fake
drive’, perhaps you should write a minifilter

  • service app that can detect this alternate viewer. If viewers exe
    name and secure hash check out, let the minifilter know
    to start decrypting for the corresponding PID.

While I haven’t thought this out fully, and perhaps others might have
some input here I think something along these
lines would be 10x’s easier to develop and would be transparent to the
user of the alternate viewer software.

While file system cipher drivers are very difficult, at least you don’t
have to attempt this on any system partition/drive.

Just my 2 cents,

Matt

Encryption is per file basis, there are few files which are encrypted
and few not.
Also, to addd to it, I do not intend to display decrypted data in E:
as taht calls for security threat. So motive is to have a E: to which
viewer send io request, and taht talks to CDrom drive, no storage
medium required.

Im googling for flie filter drivers now :slight_smile:
thanks

On Thu, Sep 11, 2008 at 11:28 AM, David Craig > mailto:xxxxx> wrote:
>
> There are still a couple of missing data points. Is the
> ‘encrypted data’ with each file encrypted individually or is the
> entire storage media encrypted at the sector level? The former
> will require a file system filter driver, while the second will
> require a storage filter driver. The previous is not completely
> true in that you could have a storage driver that exposes sectors
> formatted as e.g. FAT and then you map them into the files on the
> CD. This is not easy to do, but is probably easier than most
> active file system filters. As Tony Mason said, an encryption
> file system filter is the second most difficult driver to write.
>
></mailto:xxxxx>

25

How flexible are your design requirements?
I would call it in feasibility phase, i.e. they just want us to check
whether its feasible by us to develop such driver and deliver.

What type of encryption is being used and where is the key stored?
I do not have much details on type of encryption, as its done on backend.
For keys there is a separate installer which installs key into user
specified directory and the path is updated in registry.
What method is being used to determine if a file is encrypted or not;
header/footer, file table, file extension etc.?
Within cd we send a signtr.txt file which tells which key to use, which
algorithm to use and a data field. Together they helps in decrypting
file/folder. Also to add, we have specific folders and files which are
encrypted, so the library can distinguish if we need to decrypt this
file/folder or not.
While I think that your proposal to include a driver on the cd isn’t user
friendly at all (will require admin rights to install), I do
understand your reasoning if the customer refuses to modify their viewer at
all.
Yes I agree. And thats what even customer agrees for as we install all our
application with admin privs Also, in case we deliver such driver, then
would not the viewer require same changes as we make in our client
application ?

Thanks for your inputs, really appreciated. However I would require help for
mini filter and service approach that you pointed out. And that makes me go
back to google and exploring sample codes :slight_smile:

On Thu, Sep 11, 2008 at 1:03 PM, Matt wrote:

> Simran Saun wrote:
>
> How flexible are your design requirements? What type of encryption is being
> used and where is the key
> stored? What method is being used to determine if a file is encrypted or
> not; header/footer, file table, file extension etc.?
>
> While I think that your proposal to include a driver on the cd isn’t user
> friendly at all (will require admin rights to install), I do
> understand your reasoning if the customer refuses to modify their viewer at
> all.
>
> Perhaps a simpler solution would work; instead of creating a ‘fake drive’,
> perhaps you should write a minifilter
> + service app that can detect this alternate viewer. If viewers exe name
> and secure hash check out, let the minifilter know
> to start decrypting for the corresponding PID.
>
> While I haven’t thought this out fully, and perhaps others might have some
> input here I think something along these
> lines would be 10x’s easier to develop and would be transparent to the user
> of the alternate viewer software.
>
> While file system cipher drivers are very difficult, at least you don’t
> have to attempt this on any system partition/drive.
>
> Just my 2 cents,
>
> Matt
>
>> Encryption is per file basis, there are few files which are encrypted and
>> few not.
>> Also, to addd to it, I do not intend to display decrypted data in E: as
>> taht calls for security threat. So motive is to have a E: to which viewer
>> send io request, and taht talks to CDrom drive, no storage medium required.
>> Im googling for flie filter drivers now :slight_smile:
>> thanks
>>
>> On Thu, Sep 11, 2008 at 11:28 AM, David Craig >> xxxxx@yoshimuni.com>> wrote:
>>
>> There are still a couple of missing data points. Is the
>> ‘encrypted data’ with each file encrypted individually or is the
>> entire storage media encrypted at the sector level? The former
>> will require a file system filter driver, while the second will
>> require a storage filter driver. The previous is not completely
>> true in that you could have a storage driver that exposes sectors
>> formatted as e.g. FAT and then you map them into the files on the
>> CD. This is not easy to do, but is probably easier than most
>> active file system filters. As Tony Mason said, an encryption
>> file system filter is the second most difficult driver to write.
>>
>>
>
>
> —
> 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
>

26

My point was to try and help you think of a way to make an alternate
viewer read encrypted data without modification; your application could use
the same method if you like, kinda depends upon your preference. After
all, your application depends on how you ‘want it to
work’. I was only speaking to code you do not own or can change.

Don’t Google minifilter examples, look in the wdk ‘src/filesystem’
directory. Look specifically at how the ‘scanner’ example
handles PID’s in it’s behavior, along with how the ‘swap buffers’ sample
COULD handle encryption. Regarding the ‘scanner’
sample, look at how it communicates with usermode (perhaps as a service).

Google for code that shows you how to turn a PID into a file path. Look
up and read about the PsSetLoadImageNotifyRoutine
DDI. Search out ‘secure hashes’ and ‘keyed hashes’.

Using different types of cryptography together, there are all types of
layers you can add, depending on how valuable you think your
data is.

Matt

While I think that your proposal to include a driver on the cd isn’t
user friendly at all (will require admin rights to install), I do
understand your reasoning if the customer refuses to modify their
viewer at all.
Yes I agree. And thats what even customer agrees for as we install all
our application with admin privs Also, in case we deliver such driver,
then would not the viewer require same changes as we make in our
client application ?

Thanks for your inputs, really appreciated. However I would require
help for mini filter and service approach that you pointed out. And
that makes me go back to google and exploring sample codes :slight_smile:

27

> I would call it in feasibility phase, i.e. they just want us to check whether its feasible

by us to develop such driver and deliver.

Encryption is per file basis, there are few files which are encrypted and few not.
Also, to addd to it, I do not intend to display decrypted data in E: as taht calls for security threat.
So motive is to have a E: to which viewer send io request, and taht talks to CDrom drive,
no storage medium required.

It is plainly infeasible task for you - the project like that will take even an experienced driver writer quite a while to accomplish . You will have to write FS filter ( plus virtual storage in case if you are just desperate to see a drive letter), and neither type of driver has a reputation of being something easy, particularly the former one - encryption FS filter is one of the most complex drivers in existence The task like that requires the level of knowledge SIGNIFICANTLY above the one that your questions suggest…

Anton Bassov

28

The task like that requires the level of knowledge SIGNIFICANTLY above the
one that your questions suggest…
I never called my self an expert. Im novice to device driver, I had accepted
that, but I do belive if one is willing to learn, there is no stopping. And
ofcourse I see your post suggesting that my capabilities doesnot match skill
level required for building such drievr, so I would like to say that “No one
is born expert, u learn things slowly, gradually and at times at a higher
pace”. Now that you questioned me, I would definitely like to question you
that were you able to write a best ever program or ask a significatnly
intelligent question related to DD when you had just initiated learning it
or were you a born genious to writing device driver ?

Regards,
Simran !

On Thu, Sep 11, 2008 at 4:50 PM, wrote:

> > I would call it in feasibility phase, i.e. they just want us to check
> whether its feasible
> > by us to develop such driver and deliver.
>
>
> > Encryption is per file basis, there are few files which are encrypted and
> few not.
> > Also, to addd to it, I do not intend to display decrypted data in E: as
> taht calls for security threat.
> > So motive is to have a E: to which viewer send io request, and taht talks
> to CDrom drive,
> > no storage medium required.
>
> It is plainly infeasible task for you - the project like that will take
> even an experienced driver writer quite a while to accomplish . You will
> have to write FS filter ( plus virtual storage in case if you are just
> desperate to see a drive letter), and neither type of driver has a
> reputation of being something easy, particularly the former one - encryption
> FS filter is one of the most complex drivers in existence The task like that
> requires the level of knowledge SIGNIFICANTLY above the one that your
> questions suggest…
>
> 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
>

29

Dear Simran,

I’m sure Mr. Bassov is a gentleman, he obviously didn’t mean to offend
you. But real life pojects tend to have a strict schedule.
Unlikely that we’ll be given opportunity to learn slowly,
gradually etc.

So, this project is not feasible for your company:
it doesn’t have local workers with needed skills,
and can’t afford those who has the skills.

Regards,
–PA

Simran Saun wrote:

The task like that requires the level of knowledge SIGNIFICANTLY above
the one that your questions suggest…
I never called my self an expert. Im novice to device driver, I had
accepted that, but I do belive if one is willing to learn, there is no
stopping. And ofcourse I see your post suggesting that my capabilities
doesnot match skill level required for building such drievr, so I would
like to say that “No one is born expert, u learn things slowly,
gradually and at times at a higher pace”. Now that you questioned me, I
would definitely like to question you that were you able to write a best
ever program or ask a significatnly intelligent question related to
DD when you had just initiated learning it or were you a born genious
to writing device driver ?

Regards,
Simran !

On Thu, Sep 11, 2008 at 4:50 PM, > mailto:xxxxx> wrote:
>
> > I would call it in feasibility phase, i.e. they just want us to
> check whether its feasible
> > by us to develop such driver and deliver.
>
>
> > Encryption is per file basis, there are few files which are
> encrypted and few not.
> > Also, to addd to it, I do not intend to display decrypted data in
> E: as taht calls for security threat.
> > So motive is to have a E: to which viewer send io request, and
> taht talks to CDrom drive,
> > no storage medium required.
>
> It is plainly infeasible task for you - the project like that will
> take even an experienced driver writer quite a while to accomplish .
> You will have to write FS filter ( plus virtual storage in case if
> you are just desperate to see a drive letter), and neither type of
> driver has a reputation of being something easy, particularly the
> former one - encryption FS filter is one of the most complex drivers
> in existence The task like that requires the level of knowledge
> SIGNIFICANTLY above the one that your questions suggest…
>
> 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
>
></mailto:xxxxx>

30

> And ofcourse I see your post suggesting that my capabilities doesnot match skill level

required for building such drievr, so I would like to say that “No one is born expert,
u learn things slowly, gradually and at times at a higher pace”.

Look - there is a HUGE difference between learning and production, because in the latter case you have strict deadlines that have to be met. Therefore, this is just the question of how long your company can afford to wait. Judging from the way you have presented your question, this is a commercial project, so that you will be put under a fixed deadline. To make things worse for you, judging from your questions, no one in your company has a clue about writing drivers. so that they may expect it to be written at a pace web/detabase apps are written. As a result, they may present a deadline that is plainly infeasible even for the experienced IN A GIVEN FIELD driver writer . When they see that you are unable to meet this deadline, they are going to blame it on you, rather on some objective circumstances…

Now that you questioned me,
I would definitely like to question you that were you able to write a best ever program or ask
a significatnly intelligent question related to DD when you had just initiated learning it or
were you a born genious to writing device driver ?

I was learning it in a bit different situation - I did not have a strict deadline, by which I had to present a production-grade driver code…

Anton Bassov

31

Anton is very correct here. You are at the stage of “not knowing what you
do not know”, in other words you don’t know the basics enough to understand
the problems to ask the questions to get a handle on things. From what I
know personally and others folks who have been in the file system world, I
will tell you the best estimate for what you are asking with your knowledge
level, is this will be over 3 calendar years till you have a product you
could consider to put into production. Is that really viable for your firm?

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
>> And ofcourse I see your post suggesting that my capabilities doesnot
>> match skill level
>> required for building such drievr, so I would like to say that “No one is
>> born expert,
>> u learn things slowly, gradually and at times at a higher pace”.
>
> Look - there is a HUGE difference between learning and production, because
> in the latter case you have strict deadlines that have to be met.
> Therefore, this is just the question of how long your company can afford
> to wait. Judging from the way you have presented your question, this is a
> commercial project, so that you will be put under a fixed deadline. To
> make things worse for you, judging from your questions, no one in your
> company has a clue about writing drivers. so that they may expect it to be
> written at a pace web/detabase apps are written. As a result, they may
> present a deadline that is plainly infeasible even for the experienced IN
> A GIVEN FIELD driver writer . When they see that you are unable to meet
> this deadline, they are going to blame it on you, rather on some objective
> circumstances…
>
>
>> Now that you questioned me,
>> I would definitely like to question you that were you able to write a
>> best ever program or ask
>> a significatnly intelligent question related to DD when you had just
>> initiated learning it or
>> were you a born genious to writing device driver ?
>
> I was learning it in a bit different situation - I did not have a strict
> deadline, by which I had to present a production-grade driver code…
>
> Anton Bassov
>
>
>
>

32

> I will tell you the best estimate for what you are asking with your knowledge level, is this will

be over 3 calendar years till you have a product you could consider to put into production.

Actually, even for an experienced developer I would not estimate it anywhere below a year - he wants to write am encryption FS filter (i.e one of the most complex projects in existence that, in terms of complexity, gets pretty close to writing FSD itself), plus a virtual disk. However, they may request him to do it in a month or so…

Anton Bassov

33

Making a generic drive letter filter driver and and basic service routines for it seems to be a solved problem many times over.

Is there a good, succinct, and complete information source that would allow a motivated person to take a year or however long it takes to learn how to do this, without requiring them to reinvent the wheel, and having to figure out all the nuances and pitfalls by trial and error themselves?

If documentation, training/guidance from gurus such as yourselves, and tutorials for this are is not widely accessible, would referring to an open source project like the drive letter stuff from truecrypt help out any, or does it work better for this to stay an ivory tower skill? Not that there’s anything wrong with ivory towers.

34

The problem the OP wants to solve cannot be done by TrueCrypt. Your need
for a “a good, succinct, and complete information source” is completely
contraditory. There is some good information in “Windows NT file systems
internals” and the samples, but this is far from succinct since this is a
very broad area with many nuances, finally none of these are complete they
involve both a moving target in technology.

The long estimates are because we have someone who has never worked in the
Windows kernel, who is comming in and looking to work in the most complex
and demanding area of kernel programming. The OP does not even know the
basic terms to ask the basic questions, yet wants a product in a short time.
This would be equivilant of going to MIT without a high school degree and
expecting your masters in one year.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
> Making a generic drive letter filter driver and and basic service routines
> for it seems to be a solved problem many times over.
>
> Is there a good, succinct, and complete information source that would
> allow a motivated person to take a year or however long it takes to learn
> how to do this, without requiring them to reinvent the wheel, and having
> to figure out all the nuances and pitfalls by trial and error themselves?
>
> If documentation, training/guidance from gurus such as yourselves, and
> tutorials for this are is not widely accessible, would referring to an
> open source project like the drive letter stuff from truecrypt help out
> any, or does it work better for this to stay an ivory tower skill? Not
> that there’s anything wrong with ivory towers.
>

35

If the OP really wanted to learn how to do this, having the source of truecrypt, even if it doesn’t directly solve his problem, I would think is an advantage.

From an engineering perspective a succinct specification allows you to have a functionally correct and complete interface. From what I have seen the "Windows NT file systems internals’ cover a fraction of the work and in any case haven’t been updated in a while.

Assuming that the OP can handle a nuance/pitfall a day and is willing to slog through three years of learning the kernel with trial and error work, you’re suggesting that he can succeed. But there might be a better way.

There was a discussion a few weeks ago that to turn from an art to an engineering, this kind of work has to develop further and become more systematic. The example of a Boeing is right on the money. There is no engineer that understands every single nut and bolt of the plane, but there is complete understanding of the interfaces, such that if the new engineer wants to attach a different engine on the wing, we can give him sufficient information to make it work. It might take a long time but it can work.

In this case one cannot even examine the current engine. You might find a few turbine blades and bolts scattered around to look at and a book or two but the interface specification is very far from complete, hence you need to watch out for the nuances and pitfalls like artists. At the end every single nut and bolt in the plane is known by some engineer, but no one needs to know all the tricks in the plane, because the specs are complete and reliable.

Like any complex thing, it’s fair to require that any beginner should invest the cost in learning the system. But there are always better ways of learning things.

What seems to me here, that you are suggesting that the OP do a combination of reading and “reverse” engineering, like the samba people have done, since the available documentation is not complete in defining all the nuances and pitfalls, and that’s a big reason why it takes three years to learn it enough to make something that works.

I’m not to criticizing the way of doing things in ntfs driver world, but just trying to understand the landscape and how high the cliffs are. My feeling is that making things defined, predictable and controllable is more conducive to true innovation that we care about, like in the competing OS space. Unless of course driver writers are more like irreplaceable highly skilled and artistic mechanics trying to make new engines for airplanes by trial and error, by seeing if the plane falls out of the sky with the new cobbled together engine, as opposed to interchangeable engineers working in CATIA on their workstations with full specs of the interfaces.

36

To use a car analogy, you are suggesting he learn all about the
differential, when he needs to build an engine. TrueCrypt may appear to do
something similar but is at a totally different point in the driver stack
than what the OP has stated he needs. There is little in the way of
commonality of a disk filter and a file system filter, the interface you
talk about is not the one the OP needs to do his work.

Your claims of that you cannot examine the engine are in the case of the
OP’s problem completely false. The OP wants to deal with CD/DVD media, and
the complete source of the CDFS is in WDK. I am not suggesting reverse
engineering anything, and this would be true even if it was a file system
for a disk. Here Microsoft gives you the source of the FAT file system,
which will show 98% of what anyone needs to understand, yes there are a few
things missing there, but that is when you ask questions.

Do not try to hide ignorance of the problem space, by complaining about the
lack of source. It is ironic you invoke Boeing as a good example, many
years ago I worked for the Army Corp of Engineers, one of my tasks was
assembing data to help the army’s case that Boeing was intentionally
obscuring specifications delivered to us to force follow on contracts to go
to Boeing. In the end the firm paid millions in fines.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntdev…
> If the OP really wanted to learn how to do this, having the source of
> truecrypt, even if it doesn’t directly solve his problem, I would think is
> an advantage.
>
> From an engineering perspective a succinct specification allows you to
> have a functionally correct and complete interface. From what I have seen
> the "Windows NT file systems internals’ cover a fraction of the work and
> in any case haven’t been updated in a while.
>
> Assuming that the OP can handle a nuance/pitfall a day and is willing to
> slog through three years of learning the kernel with trial and error work,
> you’re suggesting that he can succeed. But there might be a better way.
>
> There was a discussion a few weeks ago that to turn from an art to an
> engineering, this kind of work has to develop further and become more
> systematic. The example of a Boeing is right on the money. There is no
> engineer that understands every single nut and bolt of the plane, but
> there is complete understanding of the interfaces, such that if the new
> engineer wants to attach a different engine on the wing, we can give him
> sufficient information to make it work. It might take a long time but it
> can work.
>
> In this case one cannot even examine the current engine. You might find a
> few turbine blades and bolts scattered around to look at and a book or two
> but the interface specification is very far from complete, hence you need
> to watch out for the nuances and pitfalls like artists. At the end every
> single nut and bolt in the plane is known by some engineer, but no one
> needs to know all the tricks in the plane, because the specs are complete
> and reliable.
>
>
>
>
> Like any complex thing, it’s fair to require that any beginner should
> invest the cost in learning the system. But there are always better ways
> of learning things.
>
> What seems to me here, that you are suggesting that the OP do a
> combination of reading and “reverse” engineering, like the samba people
> have done, since the available documentation is not complete in defining
> all the nuances and pitfalls, and that’s a big reason why it takes three
> years to learn it enough to make something that works.
>
> I’m not to criticizing the way of doing things in ntfs driver world, but
> just trying to understand the landscape and how high the cliffs are. My
> feeling is that making things defined, predictable and controllable is
> more conducive to true innovation that we care about, like in the
> competing OS space. Unless of course driver writers are more like
> irreplaceable highly skilled and artistic mechanics trying to make new
> engines for airplanes by trial and error, by seeing if the plane falls out
> of the sky with the new cobbled together engine, as opposed to
> interchangeable engineers working in CATIA on their workstations with full
> specs of the interfaces.
>
>

37

I am sorry I wasn’t referring to the specific OPs problem of CD/DVD based encryption. I am more interested in the general problem such as making a drive letter with an arbitrary filesystem that was mentioned a few posts up, and what it would take to do something general purpose FUSE like here.

I didn’t say I know much if anything about the problem space, nor that I am an expert in the field. I am only asking what the sources of information are, and how well the nuances/pitfalls are documented. If it makes you feel better think of me as a PHB.

I agree that it was criminal for boeing to hide/obfuscate specs. and the fine was well deserved. By the same logic do you agree that the specs here should also be completely exposed?

38

> This would be equivilant of going to MIT without a high school degree and expecting

your masters in one year.

This is just a wrong example, simply because information required to reach the above goal is openly available and easily presented - this is just the question of how fast you are able to digest it. However, when it comes to writing Windows drivers, there are plenty of details that you can learn only with experience (i.e. either the “hard way” on your own or via discussions in NGs if someone has already did the above and wants to share his experience with the rest of us) at a rate of, probably, one thing a month if you are really lucky, and there is absolutely no way you can write a production-grade driver without knowing these things.

This is what makes practical work different from academical studies. The goal that you have described can be achieved almost 100% by reading books with very little hands-on experience, so that I don’t see anything particularly infeasible here for someone who is really bright and deadly determined. Similarly, assuming that the person in question has Nagar’s book and WDK samples, I don’t see anything particularly infeasible for someone who is really bright and deadly determined to write a simple workable FSD for in-the-lab use within relatively short timeframe, even if he has no prior experience writing drivers. However, this FSD is not going to be a production-grade one because he does not know “these nasty little things” that are not mentioned anywhere…

Anton Bassov

39

Allright, Keeping aside the aspect that a person learning device driver can
not go and make a production grade driver, but for a personal learning, I
hope people here can help me. At the least by guiding me to correct path to
follow instead of me searching for things in forest of device driver.

forgetting what all sample types I mentioned, here’s the kind of device
driver I 'd like to develop:

Driver should receive signals sent to CD-Rom i.e. it should catch io signals
which are sent to CD.
If there is a “signtr.txt” file present in CD rom, it should not send back
anything
If signtr.txt file is not present, then it should send back data as
requested i.e. the normal operation.

Considering that I’m new to driver development, kindly help me with what
type of driver would such driver be called ? and what are key areas that I
need to focus on.

Regards,
Simran

On Sat, Sep 13, 2008 at 9:41 PM, wrote:

> > This would be equivilant of going to MIT without a high school degree and
> expecting
> > your masters in one year.
>
> This is just a wrong example, simply because information required to reach
> the above goal is openly available and easily presented - this is just the
> question of how fast you are able to digest it. However, when it comes to
> writing Windows drivers, there are plenty of details that you can learn only
> with experience (i.e. either the “hard way” on your own or via discussions
> in NGs if someone has already did the above and wants to share his
> experience with the rest of us) at a rate of, probably, one thing a month if
> you are really lucky, and there is absolutely no way you can write a
> production-grade driver without knowing these things.
>
>
> This is what makes practical work different from academical studies. The
> goal that you have described can be achieved almost 100% by reading books
> with very little hands-on experience, so that I don’t see anything
> particularly infeasible here for someone who is really bright and deadly
> determined. Similarly, assuming that the person in question has Nagar’s book
> and WDK samples, I don’t see anything particularly infeasible for someone
> who is really bright and deadly determined to write a simple workable FSD
> for in-the-lab use within relatively short timeframe, even if he has no
> prior experience writing drivers. However, this FSD is not going to be a
> production-grade one because he does not know “these nasty little things”
> that are not mentioned anywhere…
>
>
> 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
>

40

Quoting Simran Saun :

> Driver should receive signals sent to CD-Rom i.e. it should catch io signals
> which are sent to CD.
> If there is a “signtr.txt” file present in CD rom, it should not send back
> anything
> If signtr.txt file is not present, then it should send back data as
> requested i.e. the normal operation.
>
>
> Considering that I’m new to driver development, kindly help me with what
> type of driver would such driver be called ? and what are key areas that I
> need to focus on.
>
> Regards,
> Simran
>

I would probably implement it as a cdrom(class) lower filter driver.
You will need to know the scsi cdrom model. You can download mmc6r02.pdf
from www.t10.org
You will need to know the ISO9660 file system eqivalent to ECMA-119. You
can download this standard from www.ecma-international.org

By monitoring and sending your own scsi requests you can block or hide
the cd from windows.

Note that blocking cdroms from rippers is a harder task.

Good luck.

-------------------------------------------------
Visit Pipex Business: The homepage for UK Small Businesses

Go to http://www.pipex.co.uk/business-services