Greetings,
If I need tighter synchronization of a driver to the device’s OROM I’d
like to allow the driver to have easy access to the appropriate OROM
image by embedding it in the driver binary. Is it possible to embed a
binary image (eg: a device’s OROM) in a driver binary?
Thanks, MKE
OROM? Not sure what you mean by that exactly, but if you mean a binary
firmware image that you want or need to download to your device, yes that is
done quite frequently. Of course your device has to be able to function well
enough without it to get itself configured to the point where you can
actually download the image to it. For example, not having a functional PCI
config space until after the download would be a real bad idea.
On Jan 14, 2008 12:53 PM, Eschmann, Michael K
wrote:
> Greetings,
>
> If I need tighter synchronization of a driver to the device’s OROM I’d
> like to allow the driver to have easy access to the appropriate OROM image
> by embedding it in the driver binary. Is it possible to embed a binary
> image (eg: a device’s OROM) in a driver binary?
>
> Thanks, MKE
>
>
>
> —
> 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
>
–
Mark Roddy
Eschmann, Michael K wrote:
Greetings,
If I need tighter synchronization of a driver to the device’s OROM I’d
like to allow the driver to have easy access to the appropriate OROM
image by embedding it in the driver binary. Is it possible to embed a
binary image (eg: a device’s OROM) in a driver binary?
What do you mean by OROM? Can’t be “optical read-only memory”, since
that’s read-only.
We often embed firmware for our FX2 devices into a driver. Drivers
can’t easily access resources, but you can write a little utility to
convert the binary to C code like this:
static int FirmwareSize = 0x2232;
static unsigned char Firmware = {
0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, …
};
Have your utility write that to a .h file, and #include that in one of
the source files.
On the other hand, it’s not hard to have the driver use ZwOpenFile to
open a file that lives in the system32\drivers directory.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Ok, I guess I expected the term “OROM” to be more ubiquitous than it must truly be.
I’m concerned about mismatch or file removal issues that might exist by placing a file on the system (or any) disk, so ZwOpenFile dropped off my list before this thread.
The header creation is a good idea and likely the path I need to go down, but I was hoping there might be quicker method to achieve the same result. Are there any built-in compiler techniques that will automatically embed an object file like device firmware (a.k.a. Option ROM) in a driver, especially based in the use of MSVC++?
Not in the kernel. In user mode, as Tim already mentioned, you could do
this easily by making it a binary resource. But what Tim described
isn’t really that hard either.
mm
xxxxx@intel.com wrote:
Ok, I guess I expected the term “OROM” to be more ubiquitous than it must truly be.
I’m concerned about mismatch or file removal issues that might exist by placing a file on the system (or any) disk, so ZwOpenFile dropped off my list before this thread.
The header creation is a good idea and likely the path I need to go down, but I was hoping there might be quicker method to achieve the same result. Are there any built-in compiler techniques that will automatically embed an object file like device firmware (a.k.a. Option ROM) in a driver, especially based in the use of MSVC++?
> Are there any built-in compiler techniques that will automatically
embed an object file like device firmware (a.k.a. Option ROM) in a driver,
especially based in the use of MSVC++?
I’ve never heard of drivers with RESOURCE section - although the thing you mention (i.e. including raw binary data in an image) is common at the app level, I’ve never heard of anyone doing it with a driver. Furthermore, building drivers with VC,rather that WDK, is not really a good idea, so to say.
In any case, let’s assume you have succeeded. How are you going to access this data from your driver??? There is no system-provided function to reach it it the kernel mode. Therefore, you will have to parse your image’s PE header (which is not that simple in the kernel mode, compared to the user one, because some parts of your driver image may be discarded upon the load), and, in any case, RESOURCE section is not the easiest one to deal with…
In other words, it looks like too much hassle to me - I would rather do it differently. What you can do here is to present everything as simple initialized data array. Imagine that your binary image resides in the array like
unsigned char dataarray [N]={0xa,
0xb,
0xc,
.
.
.
};
In other words, it is just hardcoded into your source. Then you can simply use a standard WDK build without any additional hacks, and access your data without a slightest problem. Write a simple program that generates a source file like that from your binary data (I really hope there is no need to explain to you how to do it - it takes literally less than 5 minutes of work), include it into your SOURCES file, and that’s it…
Anton Bassov
Drivers normally have the version resource embedded in them. It provides
the company name and various version info. It is not normally accessed by
the driver itself, but with the use of Explorer’s Properties dialog for the
file. The external date can easily not match, but the internal version info
should be consistant with what was used at build time.
I can see a use for having a DLL in the driver binary. Let’s say you have
driver and a user mode DLL that interfaces to that driver. You could bind
the DLL into the driver’s binary so that an application that wants to use
the DLL to access the driver can extract the DLL binary to ensure they
match. The app can have a query that the driver answers by providing the
full path name of the driver as passed into DriverEntry. The app could also
check the service key to read the ImagePath, if present, or just default to
system32\drivers otherwise. Either method can work, but I am not sure if
you need admin rights to read the services key in all cases. If you take
this idea to it fullest concept, both the driver and DLL would be embedded
in the application, however this would require the app run with admin
rights.
I do not know of a method to parse the PE file format in kernel mode, but
with available documentation it can be done from a driver. Using the user
mode interfaces is much easier.
wrote in message news:xxxxx@ntdev…
>> Are there any built-in compiler techniques that will automatically
>> embed an object file like device firmware (a.k.a. Option ROM) in a
>> driver,
>> especially based in the use of MSVC++?
>
> I’ve never heard of drivers with RESOURCE section - although the thing you
> mention (i.e. including raw binary data in an image) is common at the app
> level, I’ve never heard of anyone doing it with a driver. Furthermore,
> building drivers with VC,rather that WDK, is not really a good idea, so to
> say.
>
> In any case, let’s assume you have succeeded. How are you going to access
> this data from your driver??? There is no system-provided function to
> reach it it the kernel mode. Therefore, you will have to parse your
> image’s PE header (which is not that simple in the kernel mode, compared
> to the user one, because some parts of your driver image may be discarded
> upon the load), and, in any case, RESOURCE section is not the easiest one
> to deal with…
>
>
> In other words, it looks like too much hassle to me - I would rather do it
> differently. What you can do here is to present everything as simple
> initialized data array. Imagine that your binary image resides in the
> array like
>
>
> unsigned char dataarray [N]={0xa,
> 0xb,
> 0xc,
> .
> .
> .
> };
>
> In other words, it is just hardcoded into your source. Then you can simply
> use a standard WDK build without any additional hacks, and access your
> data without a slightest problem. Write a simple program that generates a
> source file like that from your binary data (I really hope there is no
> need to explain to you how to do it - it takes literally less than 5
> minutes of work), include it into your SOURCES file, and that’s it…
>
> Anton Bassov
>
>
A driver is std PE image, so it definitely can and usually does have a resource section. Open up an inbox driver (say i8042prt.sys) in VS. You will see a resource section that includes both version info as well as a message table (the output of the MC compiler). I have seen quite a few drivers embed other custom resource information into the resource section, getting at it via auxklib is not that hard, but not that trivial either…
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Monday, January 14, 2008 2:30 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Embedding an OROM in a driver binary
Are there any built-in compiler techniques that will automatically
embed an object file like device firmware (a.k.a. Option ROM) in a driver,
especially based in the use of MSVC++?
I’ve never heard of drivers with RESOURCE section - although the thing you mention (i.e. including raw binary data in an image) is common at the app level, I’ve never heard of anyone doing it with a driver. Furthermore, building drivers with VC,rather that WDK, is not really a good idea, so to say.
In any case, let’s assume you have succeeded. How are you going to access this data from your driver??? There is no system-provided function to reach it it the kernel mode. Therefore, you will have to parse your image’s PE header (which is not that simple in the kernel mode, compared to the user one, because some parts of your driver image may be discarded upon the load), and, in any case, RESOURCE section is not the easiest one to deal with…
In other words, it looks like too much hassle to me - I would rather do it differently. What you can do here is to present everything as simple initialized data array. Imagine that your binary image resides in the array like
unsigned char dataarray [N]={0xa,
0xb,
0xc,
.
.
.
};
In other words, it is just hardcoded into your source. Then you can simply use a standard WDK build without any additional hacks, and access your data without a slightest problem. Write a simple program that generates a source file like that from your binary data (I really hope there is no need to explain to you how to do it - it takes literally less than 5 minutes of work), include it into your SOURCES file, and that’s it…
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
> A driver is std PE image, so it definitely can and usually does have a resource section.
Open up an inbox driver (say i8042prt.sys) in VS. You will see a resource section…
Although .sys file is, indeed, a standard PE image on the disk, it is already “not-so-standard” one when it gets loaded into RAM. This is why I said the parsing PE header in the kernel mode is not that easy - some parts of the image may be missing in RAM ( INIT section is the very first example that comes to my mind). Therefore, this is not the question of file layout, but rather of how OS loader treats it. Does the RESOURCE section get loaded into RAM when you load a driver??? I am not sure about it (at least, I haven’t seen anything like that myself, although I may be wrong here)…
Anton Bassov
xxxxx@intel.com wrote:
Ok, I guess I expected the term “OROM” to be more ubiquitous than it must truly be.
I’m concerned about mismatch or file removal issues that might exist by placing a file on the system (or any) disk, so ZwOpenFile dropped off my list before this thread.
We haven’t experienced any problems with that. Most users don’t go
poking around in \windows\system32\drivers, and the ones that do already
know they deserve what they get. The big advantage is that you aren’t
tying up pool memory with the data, as you would with the in-the-binaryt
approach.
The header creation is a good idea and likely the path I need to go down, but I was hoping there might be quicker method to achieve the same result. Are there any built-in compiler techniques that will automatically embed an object file like device firmware (a.k.a. Option ROM) in a driver, especially based in the use of MSVC++?
Not for drivers, no. Applications can use the Resource Compiler to
embed arbitrary binary files in their exes, but drivers don’t have that
option. The binary-to-.h converter is a trivial application to write.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
A more standard technique used in drivers is to, as Tim alluded to, convert
the image into a c source file that consists of an array of hex values that
is the firmware image. There are simple utilities fetched from the vast
googlenets that do this quite well, or one can re-invent the wheel and write
your own.
Here is bin2hex in perl: http://www.chami.com/tips/delphi/052098D.html
You then do not have to muck with fetching resources from drivers, you have
a C array that contains the image,
On Jan 14, 2008 6:34 PM, Doron Holan wrote:
> A driver is std PE image, so it definitely can and usually does have a
> resource section. Open up an inbox driver (say i8042prt.sys) in VS. You
> will see a resource section that includes both version info as well as a
> message table (the output of the MC compiler). I have seen quite a few
> drivers embed other custom resource information into the resource section,
> getting at it via auxklib is not that hard, but not that trivial either…
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
> Sent: Monday, January 14, 2008 2:30 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Embedding an OROM in a driver binary
>
> > Are there any built-in compiler techniques that will automatically
> > embed an object file like device firmware (a.k.a. Option ROM) in a
> driver,
> > especially based in the use of MSVC++?
>
> I’ve never heard of drivers with RESOURCE section - although the thing you
> mention (i.e. including raw binary data in an image) is common at the app
> level, I’ve never heard of anyone doing it with a driver. Furthermore,
> building drivers with VC,rather that WDK, is not really a good idea, so to
> say.
>
> In any case, let’s assume you have succeeded. How are you going to access
> this data from your driver??? There is no system-provided function to reach
> it it the kernel mode. Therefore, you will have to parse your image’s PE
> header (which is not that simple in the kernel mode, compared to the user
> one, because some parts of your driver image may be discarded upon the
> load), and, in any case, RESOURCE section is not the easiest one to deal
> with…
>
>
> In other words, it looks like too much hassle to me - I would rather do it
> differently. What you can do here is to present everything as simple
> initialized data array. Imagine that your binary image resides in the array
> like
>
>
> unsigned char dataarray [N]={0xa,
> 0xb,
> 0xc,
> .
> .
> .
> };
>
> In other words, it is just hardcoded into your source. Then you can simply
> use a standard WDK build without any additional hacks, and access your data
> without a slightest problem. Write a simple program that generates a source
> file like that from your binary data (I really hope there is no need to
> explain to you how to do it - it takes literally less than 5 minutes of
> work), include it into your SOURCES file, and that’s it…
>
> 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
>
> —
> 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
>
–
Mark Roddy
From what I have seen, driver images are always loaded entirely. There are
functions to enumerate all loaded drivers and get their addresses and
lenghts. The lengths are always equal to the file size + a fixed amount of
bytes. However if you want to extract something it makes a lot of sense to
search in the disk image rather than in memory.
/Daniel’
wrote in message news:xxxxx@ntdev…
> Although .sys file is, indeed, a standard PE image on the disk, it is
> already “not-so-standard” one when it gets loaded into RAM. This is why I
> said the parsing PE header in the kernel mode is not that easy - some
> parts of the image may be missing in RAM ( INIT section is the very first
> example that comes to my mind). Therefore, this is not the question of
> file layout, but rather of how OS loader treats it. Does the RESOURCE
> section get loaded into RAM when you load a driver??? I am not sure about
> it (at least, I haven’t seen anything like that myself, although I may be
> wrong here)…
>
> Anton Bassov
>
> Drivers normally have the version resource embedded in them.
Drivers can also have the event log message resource.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Not for drivers, no. Applications can use the Resource Compiler to
embed arbitrary binary files in their exes, but drivers don’t have that
option.
Drivers can contain any resources, but, as it was already told, the kernel has
no API to access the resource sections of the loaded SYS file.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> The lengths are always equal to the file size + a fixed amount of bytes.
Of course - after all, all addresses are logically formed as ImageBase +RVA… The problem is that the above does not mean that a driver is loaded “entirely”, as you say - there may be some “holes” in the loaded image. Therefore, the address you have calculated this way may be just invalid, although it belongs to the range that a driver module occupies. For example, names of all imported functions may go into INIT section that gets discarded from RAM after a driver gets loaded. Therefore, if you decide to enumerate functions that a driver imports you may get BSOD…
Anton Bassov
Right, there is no way to know if those addresses are valid or what you are
looking for is really there. Therefore it’s a better idea to extract things
from the file. BTW I have never even managed to compare in memory code
sections of kernel modules with those on disk.
/Daniel
wrote in message news:xxxxx@ntdev…
> Of course - after all, all addresses are logically formed as ImageBase
> +RVA… The problem is that the above does not mean that a driver is loaded
> “entirely”, as you say - there may be some “holes” in the loaded image.
> Therefore, the address you have calculated this way may be just invalid,
> although it belongs to the range that a driver module occupies. For
> example, names of all imported functions may go into INIT section that
> gets discarded from RAM after a driver gets loaded. Therefore, if you
> decide to enumerate functions that a driver imports you may get BSOD…
>
> Anton Bassov
>
> Drivers can contain any resources,
Well, driver’s *disk* image may,indeed, have any section . The only problem is that driver image
in RAM may appear a bit differently - it may have some “holes” in it, so that a pointer that you have calculated as Base+RVA may be pointing to the middle of nowhere…
the kernel has no API to access the resource sections of the loaded SYS file.
IWell, this set of API is just infeasible in the kernel mode - in order to make it work the OS would have to keep the full driver image in memory, and this is not the kind of thing it seems to be willing to do…
Anton Bassov
At the risk of being repetitively redundant: incorporate the firmware image
as an array of hex values in a C source module. This is trivial to do and
does not wander off into unsupported hackery and is the standard practice
for firmware image management when no user interface can supply the image.
On Jan 15, 2008 8:49 AM, wrote:
> > Drivers can contain any resources,
>
> Well, driver’s disk image may,indeed, have any section . The only
> problem is that driver image
> in RAM may appear a bit differently - it may have some “holes” in it, so
> that a pointer that you have calculated as Base+RVA may be pointing to the
> middle of nowhere…
>
> > the kernel has no API to access the resource sections of the loaded SYS
> file.
>
> IWell, this set of API is just infeasible in the kernel mode - in order
> to make it work the OS would have to keep the full driver image in memory,
> and this is not the kind of thing it seems to be willing to do…
>
> 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
>
–
Mark Roddy
Anton, no there is no need to explain how to do this. I’m curious why
you thought you might need to explain such a simple task? I was just
hunting for a more elegant and safer method for upgrading my device’s
firmware than the two methods that have been discussed so far, and an
embedded binary string in the driver that bypasses any external steps
would have been one way to keep our build process from adding any more
complexity than it already has.
BTW, we’ve been shipping high-volume production drivers for many years
that are built through Visual Studio. I’d rather not get into the
details in this thread, but please note that it isn’t as difficult as
some have made it out to be.
Thank you to all that have chimed-in on this topic.
Regards, MKE.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Monday, January 14, 2008 2:30 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Embedding an OROM in a driver binary
Are there any built-in compiler techniques that will automatically
embed an object file like device firmware (a.k.a. Option ROM) in a
driver,
especially based in the use of MSVC++?
I’ve never heard of drivers with RESOURCE section - although the thing
you mention (i.e. including raw binary data in an image) is common at
the app level, I’ve never heard of anyone doing it with a driver.
Furthermore, building drivers with VC,rather that WDK, is not really a
good idea, so to say.
In any case, let’s assume you have succeeded. How are you going to
access this data from your driver??? There is no system-provided
function to reach it it the kernel mode. Therefore, you will have to
parse your image’s PE header (which is not that simple in the kernel
mode, compared to the user one, because some parts of your driver image
may be discarded upon the load), and, in any case, RESOURCE section is
not the easiest one to deal with…
In other words, it looks like too much hassle to me - I would rather do
it differently. What you can do here is to present everything as simple
initialized data array. Imagine that your binary image resides in the
array like
unsigned char dataarray [N]={0xa,
0xb,
0xc,
.
.
.
};
In other words, it is just hardcoded into your source. Then you can
simply use a standard WDK build without any additional hacks, and access
your data without a slightest problem. Write a simple program that
generates a source file like that from your binary data (I really hope
there is no need to explain to you how to do it - it takes literally
less than 5 minutes of work), include it into your SOURCES file, and
that’s it…
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
Guys,
I know I am risking to divert the thread into a very different direction, plus give Alberto
an incentive to join it a well (unfortunately, it somehow happened that we got a reputation of trolls in this NG, and ,ironically, I risk to move a discussion towards one of his favorite topics), but I just cannot refrain myself from commenting on the statement below:
[begin quote]
BTW, we’ve been shipping high-volume production drivers for many years that are built through Visual Studio. I’d rather not get into the details in this thread, but please note that it isn’t as difficult as some have made it out to be.
[end quote]
Whenever you go for something “unsupported”, normally you try to do something that cannot be done in a “conventional” way, or probably (in most cases mistakenly) believe that “unsupported” way is easier. In either case, I can understand your motivation. However, building
drivers with VC is among those things that I am just unable to understand, no matter how hard I try. In th very best case you are going to get exactly the same driver, but at the cost of doing quite a few adjustments to your project settings. Is not easier to write a SOURCES file
and run ‘build’ utility??? What are expecting to win this way??? Up to this point I am just unable to see any either real or perceived benefit of this approach, but I do see a lot of pain in the arse that it invariably implies. What is your motivation when you do something like that???.
Anton Bassov