Writing a driver for DFU (Device Firmware upgrade) mode

NTDEV
1

Hi,

I have a costumer request which I am not quite sure is valid and would like
to get information from anyone that may have an idea about this scenario.

My costumer have a USB device which support DFU. he would like to have a
driver which will be installed by windows update (it will be windows logo
certified) and when the driver gets installed while the device in DFU
state, a new firmware will be uploaded to the device.

what woories me is that the driver package should include the firmware
itself and should upload the firmware when windows update finish installing
the driver package. therefore it should be kind of “one-time-operation” per
firmware,

I am not quite sure about :

  1. Does it make sense to run the DFU upload while installing the driver.
    This should be a one shot operation.

  2. When a new firmware is ready, in theory there should be a new driver
    package in windows update. That is really sounds bad to me because the user
    will have to manually choose “upgrade driver”. Is there any way to bypass
    that ?

I am still figuring out the DFU mode which I was unfamiliar with
development-wise. but I assume that if they would like to use the windows
update for such a task, it would be better to install one DFU driver ( I
assume based on WinUSB) with an application that will check the net for new
firmwares and will have no need to install a new DFU driver each time ,but
an application which will download the firmwares from the net. Is that
they right want to do it ?

Thanks in advance.

2

> Hi,

I have a costumer request which I am not quite sure is valid and would
like
to get information from anyone that may have an idea about this scenario.

My costumer have a USB device which support DFU. he would like to have a
driver which will be installed by windows update (it will be windows logo
certified) and when the driver gets installed while the device in DFU
state, a new firmware will be uploaded to the device.

what woories me is that the driver package should include the firmware
itself and should upload the firmware when windows update finish
installing
the driver package. therefore it should be kind of “one-time-operation”
per
firmware,

I am not quite sure about :

  1. Does it make sense to run the DFU upload while installing the driver.
    This should be a one shot operation.

Only if the device is actually connected; otherwise, when it is next
plugged in.

  1. When a new firmware is ready, in theory there should be a new driver
    package in windows update. That is really sounds bad to me because the
    user
    will have to manually choose “upgrade driver”. Is there any way to bypass
    that ?

In a similar thread, it was pointed out that from a security viewpoint
this would be necessary, since the signing would also certify the firmware
bits; otherwise, it would be too easy for malware to compromise the
firmware (and if you don’t believe this can be a problem, I have one word
to remind you: StuxNet). So the tradeoff is one of guaranteeing that
/all/ the bits have a certified point of origin, and that doesn’t seem
like a bad idea at all.

I am still figuring out the DFU mode which I was unfamiliar with
development-wise. but I assume that if they would like to use the windows
update for such a task, it would be better to install one DFU driver ( I
assume based on WinUSB) with an application that will check the net for
new
firmwares and will have no need to install a new DFU driver each time ,but
an application which will download the firmwares from the net. Is that
they right want to do it ?

Note that Windows Update will notice the new driver package, and thus be
proactive in informing the custoers that an update is available, and note
that in both the scenarios you have, a download has to take place, so it
is not clear to me exactly what maintaining a separate and unsigned
firmware download is going to solve, while having a new, fully-signed
distribution buys you both security and proactive notification.
joe

Thanks in advance.

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

3

I was unaware that windows update will notify the user when it will have a
new driver package available. Never seen this happen on my end with my
driver.

Thanks.

On Mon, Dec 16, 2013 at 1:12 PM, wrote:

> > Hi,
> >
> > I have a costumer request which I am not quite sure is valid and would
> > like
> > to get information from anyone that may have an idea about this scenario.
> >
> > My costumer have a USB device which support DFU. he would like to have a
> > driver which will be installed by windows update (it will be windows logo
> > certified) and when the driver gets installed while the device in DFU
> > state, a new firmware will be uploaded to the device.
> >
> > what woories me is that the driver package should include the firmware
> > itself and should upload the firmware when windows update finish
> > installing
> > the driver package. therefore it should be kind of “one-time-operation”
> > per
> > firmware,
> >
> > I am not quite sure about :
> > 1. Does it make sense to run the DFU upload while installing the driver.
> > This should be a one shot operation.
> >
> Only if the device is actually connected; otherwise, when it is next
> plugged in.
>
> > 2. When a new firmware is ready, in theory there should be a new driver
> > package in windows update. That is really sounds bad to me because the
> > user
> > will have to manually choose “upgrade driver”. Is there any way to bypass
> > that ?
> >
> In a similar thread, it was pointed out that from a security viewpoint
> this would be necessary, since the signing would also certify the firmware
> bits; otherwise, it would be too easy for malware to compromise the
> firmware (and if you don’t believe this can be a problem, I have one word
> to remind you: StuxNet). So the tradeoff is one of guaranteeing that
> /all/ the bits have a certified point of origin, and that doesn’t seem
> like a bad idea at all.
>
> > I am still figuring out the DFU mode which I was unfamiliar with
> > development-wise. but I assume that if they would like to use the windows
> > update for such a task, it would be better to install one DFU driver ( I
> > assume based on WinUSB) with an application that will check the net for
> > new
> > firmwares and will have no need to install a new DFU driver each time
> ,but
> > an application which will download the firmwares from the net. Is that
> > they right want to do it ?
>
> Note that Windows Update will notice the new driver package, and thus be
> proactive in informing the custoers that an update is available, and note
> that in both the scenarios you have, a download has to take place, so it
> is not clear to me exactly what maintaining a separate and unsigned
> firmware download is going to solve, while having a new, fully-signed
> distribution buys you both security and proactive notification.
> joe
> >
> > Thanks in advance.
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
> >
> > OSR is HIRING!! See http://www.osr.com/careers
> >
> > 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
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

4

There are numerous ways to do what your client wants. Some are quite nice, others can be hideous.

One thing for sure: I would not ship the firmware IN the driver code. Instead, I’d make it a separate file that’s part of the driver package.

Or… better yet… a downloadable file from your customer’s web site. Have a service check for the most recent version of the firmware, download it, and flash it to the device each time the device is restarted. Or something.

Peter
OSR

5

Thanks peter for your response.

The firmware will be a separate file. I wasn’t plan to keep it in the
source code.
I also planed to go with your option to check over a website , but newcomer
just gave a valid reason why I should create a different driver package for
each firmware. security-wise , it will make sure that no man-in-the-middle
or anything like that may replace my firmware.

What do you think about having a new driver package in windows update for
each firmware even that the driver that will handle the DFU upload will not
change it all, only the firmware file.

Thanks for your help !

On Mon, Dec 16, 2013 at 4:12 PM, wrote:

>


>
> There are numerous ways to do what your client wants. Some are quite
> nice, others can be hideous.
>
> One thing for sure: I would not ship the firmware IN the driver code.
> Instead, I’d make it a separate file that’s part of the driver package.
>
> Or… better yet… a downloadable file from your customer’s web site.
> Have a service check for the most recent version of the firmware, download
> it, and flash it to the device each time the device is restarted. Or
> something.
>
> Peter
> OSR
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

6

Iirc WU will only push a new driver package if it is marked as critical, otherwise it is a user initiated operation to pull it down. I don’t think you can get this marked as critical

d

Bent from my phone

From: Jimmailto:xxxxx
Sent: ?12/?16/?2013 7:26 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re: [ntdev] Writing a driver for DFU (Device Firmware upgrade) mode

Thanks peter for your response.

The firmware will be a separate file. I wasn’t plan to keep it in the source code.
I also planed to go with your option to check over a website , but newcomer just gave a valid reason why I should create a different driver package for each firmware. security-wise , it will make sure that no man-in-the-middle or anything like that may replace my firmware.

What do you think about having a new driver package in windows update for each firmware even that the driver that will handle the DFU upload will not change it all, only the firmware file.

Thanks for your help !

On Mon, Dec 16, 2013 at 4:12 PM, > wrote:



There are numerous ways to do what your client wants. Some are quite nice, others can be hideous.

One thing for sure: I would not ship the firmware IN the driver code. Instead, I’d make it a separate file that’s part of the driver package.

Or… better yet… a downloadable file from your customer’s web site. Have a service check for the most recent version of the firmware, download it, and flash it to the device each time the device is restarted. Or something.

Peter
OSR

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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 Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers 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></mailto:xxxxx>

7

On 12/16/2013 3:38 AM, Jim wrote:

I was unaware that windows update will notify the user when it will
have a new driver package available. Never seen this happen on my end
with my driver.

Thanks.

After you get the WHQL certification for your driver you need to go to
the control panel in Hardware Central (I think that’s what they’re
calling it now), and tell WHQL that you want the driver distributed on
Windows Update. Then there are settings on the client machine that can
affect if the driver gets pushed.

What do you think about having a new driver package in windows update
for each firmware even that the driver that will handle the DFU upload
will not change it all, only the firmware file.
This kind of depends on your device. Windows Update recognizes devices
based on their hardware ID (In this case USB VID/PID). As long as each
firmware package is associated with a unique hardware ID, you will be
able to have a separate WU package per firmware package. If, however,
you have a single hardware ID and you’re planning on determining which
firmware package is needed by talking to the device then you’re not
going to be able to have one WU package for each firmware package.
Basically, you can have one or more unique hardware ID’s per firmware
package, but you can’t have multiple firmware packages per hardware ID.

8

Thanks for clarify Doron, I suspected that I cant just initiate a driver
update notification for any driver.

On Mon, Dec 16, 2013 at 5:38 PM, Doron Holan wrote:

> Iirc WU will only push a new driver package if it is marked as critical,
> otherwise it is a user initiated operation to pull it down. I don’t think
> you can get this marked as critical
>
> d
>
> Bent from my phone
> ------------------------------
> From: Jim
> Sent: 12/16/2013 7:26 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Writing a driver for DFU (Device Firmware upgrade)
> mode
>
> Thanks peter for your response.
>
> The firmware will be a separate file. I wasn’t plan to keep it in the
> source code.
> I also planed to go with your option to check over a website , but
> newcomer just gave a valid reason why I should create a different driver
> package for each firmware. security-wise , it will make sure that no
> man-in-the-middle or anything like that may replace my firmware.
>
> What do you think about having a new driver package in windows update
> for each firmware even that the driver that will handle the DFU upload will
> not change it all, only the firmware file.
>
> Thanks for your help !
>
>
>
> On Mon, Dec 16, 2013 at 4:12 PM, wrote:
>
>>


>>
>> There are numerous ways to do what your client wants. Some are quite
>> nice, others can be hideous.
>>
>> One thing for sure: I would not ship the firmware IN the driver code.
>> Instead, I’d make it a separate file that’s part of the driver package.
>>
>> Or… better yet… a downloadable file from your customer’s web site.
>> Have a service check for the most recent version of the firmware, download
>> it, and flash it to the device each time the device is restarted. Or
>> something.
>>
>> Peter
>> OSR
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> 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 Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers 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
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

9

Thanks Thomas,
But Correct me if I am wrong. If the user will initiate a “Upgrade driver”
in the device manager , and we set a new firmware package with the same
hardware ID, the upgrade driver functionality *will* find a new driver. am
I correct ? even that the physical driver file will not changed but only a
data file.

On Mon, Dec 16, 2013 at 5:42 PM, Thomas Swann wrote:

> On 12/16/2013 3:38 AM, Jim wrote:
> > I was unaware that windows update will notify the user when it will
> > have a new driver package available. Never seen this happen on my end
> > with my driver.
> >
> > Thanks.
> >
> After you get the WHQL certification for your driver you need to go to
> the control panel in Hardware Central (I think that’s what they’re
> calling it now), and tell WHQL that you want the driver distributed on
> Windows Update. Then there are settings on the client machine that can
> affect if the driver gets pushed.
> >
> > What do you think about having a new driver package in windows update
> > for each firmware even that the driver that will handle the DFU upload
> > will not change it all, only the firmware file.
> This kind of depends on your device. Windows Update recognizes devices
> based on their hardware ID (In this case USB VID/PID). As long as each
> firmware package is associated with a unique hardware ID, you will be
> able to have a separate WU package per firmware package. If, however,
> you have a single hardware ID and you’re planning on determining which
> firmware package is needed by talking to the device then you’re not
> going to be able to have one WU package for each firmware package.
> Basically, you can have one or more unique hardware ID’s per firmware
> package, but you can’t have multiple firmware packages per hardware ID.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

10

On 12/16/2013 7:51 AM, Jim wrote:

Thanks Thomas,
But Correct me if I am wrong. If the user will initiate a “Upgrade
driver” in the device manager , and we set a new firmware package with
the same hardware ID, the upgrade driver functionality *will* find a
new driver. am I correct ? even that the physical driver file will
not changed but only a data file.

As long as the INF for the new driver binary has a newer date with
client will see the new package on WU as a potential upgrade. Just to
be clear you can’t just touch the inf file. You have to change the
DriverVer field inside the inf file, create a new catalog file, and
re-submit to WHQL. I think you’ll have to re-run your WHQL tests too
(because I think those test results are tied to the cryptographic hash
of the driver package), but I’m not 100% sure on this.

11

Yes, that make sense … thanks !

On Mon, Dec 16, 2013 at 6:09 PM, Thomas Swann wrote:

> On 12/16/2013 7:51 AM, Jim wrote:
> > Thanks Thomas,
> > But Correct me if I am wrong. If the user will initiate a “Upgrade
> > driver” in the device manager , and we set a new firmware package with
> > the same hardware ID, the upgrade driver functionality will find a
> > new driver. am I correct ? even that the physical driver file will
> > not changed but only a data file.
> >
> As long as the INF for the new driver binary has a newer date with
> client will see the new package on WU as a potential upgrade. Just to
> be clear you can’t just touch the inf file. You have to change the
> DriverVer field inside the inf file, create a new catalog file, and
> re-submit to WHQL. I think you’ll have to re-run your WHQL tests too
> (because I think those test results are tied to the cryptographic hash
> of the driver package), but I’m not 100% sure on this.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

12

Unless your updates are REALLY infrequent (like once per year or two), I think it’s a very silly waste of time.

It takes time, money, and effort to release a driver via WU. There’s no reason to do that when what you want to do is update the device firmware.

There’s a well-established path in the world for upgrading versions software things: You check for updates on a web site, if there’s an update you then tell the user that there’s an update available. This is a path that users understand and expect.

If you’re paranoid, sign the download with a private key and check the signature after you download the new firmware file.

OTOH, if your firmware updates are rare… then going the path of using WU might be reasonable. In that sort of time frame, there’s a likelihood that you’ll need or want to make a change to your driver code in any case, so doing a WU update will be worth the effort.

Peter
OSR

13

If you put the firmware in a separate file, then you need a way to verify
the authenticity of that file each time you send it to your firmware. If
you magically incorporate it into your driver binary (for example, by
using a binary-to-C translator program to create a source module for your
driver) then you cane be certain that the signing cannot have been
tampered with. In a separate thread there has been a debate about making
this data into paged pool vs. nonpaged pool. I have no idea what, if any,
mechanisms exist in the kernel for checking a signature on an arbitrary
file, but that’s what you’ll need to make sure that you firmware bits have
not been tampered with post-installation. But I’m way outside my
expertise here; others who know about signing should jump in here at this
point.
joe

Thanks peter for your response.

The firmware will be a separate file. I wasn’t plan to keep it in the
source code.
I also planed to go with your option to check over a website , but
newcomer
just gave a valid reason why I should create a different driver package
for
each firmware. security-wise , it will make sure that no man-in-the-middle
or anything like that may replace my firmware.

What do you think about having a new driver package in windows update for
each firmware even that the driver that will handle the DFU upload will
not
change it all, only the firmware file.

Thanks for your help !

On Mon, Dec 16, 2013 at 4:12 PM, wrote:
>
>>


>>
>> There are numerous ways to do what your client wants. Some are quite
>> nice, others can be hideous.
>>
>> One thing for sure: I would not ship the firmware IN the driver code.
>> Instead, I’d make it a separate file that’s part of the driver package.
>>
>> Or… better yet… a downloadable file from your customer’s web site.
>> Have a service check for the most recent version of the firmware,
>> download
>> it, and flash it to the device each time the device is restarted. Or
>> something.
>>
>> Peter
>> OSR
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> 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
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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

14

One of the key points here is how you sign your firmware,and as I
indicated earlier, you need to verify this signature each time you upload
new firmware to your device. OTOH, if you are controlling
nuclear-separation centrifuges or something equivalent, the added cost of
WU is unnoticeable compared to te potential damage.

Engineering is all about cost/benefit tradeoffs, and finding the best
solution that meets the non-negotiable goals (and if it is too expensive,
re-negotiating those goals. Oh, wait a minute…you can’t do that with
non-negotiable goals. Unless they weren’t…)
joe

Unless your updates are REALLY infrequent (like once per year or two), I
think it’s a very silly waste of time.

It takes time, money, and effort to release a driver via WU. There’s no
reason to do that when what you want to do is update the device firmware.

There’s a well-established path in the world for upgrading versions
software things: You check for updates on a web site, if there’s an
update you then tell the user that there’s an update available. This is a
path that users understand and expect.

If you’re paranoid, sign the download with a private key and check the
signature after you download the new firmware file.

OTOH, if your firmware updates are rare… then going the path of using WU
might be reasonable. In that sort of time frame, there’s a likelihood
that you’ll need or want to make a change to your driver code in any case,
so doing a WU update will be worth the effort.

Peter
OSR

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

15

If you WHQL your driver, the entire driver package gets signed (via the CAT file)? So, the code need not be IN the driver… the package is signed, and this is a guarantee that it’s not tampered with.

But, again… in his case, he doesn’t need to go through WHQL and WU just to update his firmware. He can quite easily check the signature on his binary, or decrypt it, or whatever.

Peter
OSR

16

Having the firmware into the driver binary ensures that the signature is checked when the driver is loaded. Adding it as a file in the driver package will ensure that the file wasn’t tampered with at install time, but provides no guarantee for the driver when it tries to load the file from disk directly. For that the driver would need to have its own signature checking code (which would then be protected from tampering by the signature on the driver binary)

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Monday, December 16, 2013 1:51 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Writing a driver for DFU (Device Firmware upgrade) mode

If you WHQL your driver, the entire driver package gets signed (via the CAT file)? So, the code need not be IN the driver… the package is signed, and this is a guarantee that it’s not tampered with.

But, again… in his case, he doesn’t need to go through WHQL and WU just to update his firmware. He can quite easily check the signature on his binary, or decrypt it, or whatever.

Peter
OSR

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

17

That’s a good point.

Of course, a user would have to have admin privs to tamper with such a file. So…

Peter
OSR

18

However, trusting that someone who can never escalate privileges is not
always safe. The old “trust, but verify” model is more conservative, and
is based on the “just in case” model. If the sole purpose of the
privilege escalation (and never rule out social engineering as the best
path) is to cause the embedded device to self-destruct, it is nice tohave
a double-check on the integrity.
joe

That’s a good point.

Of course, a user would have to have admin privs to tamper with such a
file. So…

Peter
OSR

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

19

For adding it as a file in the driver package , you could add PnpLockDown=1
in .inf file , to prevent other one changing the firmware patch file.

2013/12/17

> However, trusting that someone who can never escalate privileges is not
> always safe. The old “trust, but verify” model is more conservative, and
> is based on the “just in case” model. If the sole purpose of the
> privilege escalation (and never rule out social engineering as the best
> path) is to cause the embedded device to self-destruct, it is nice tohave
> a double-check on the integrity.
> joe
>
> >


> >
> > That’s a good point.
> >
> > Of course, a user would have to have admin privs to tamper with such a
> > file. So…
> >
> > Peter
> > OSR
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
> >
> > OSR is HIRING!! See http://www.osr.com/careers
> >
> > 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
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

–
Danny