rebuilding the driver? I don't get it.

--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/hwdev/driver/kb-drv.mspx

The binaries are included when the driver is built by adding a few lines to
the driver's .RC file, (text of file follows message).

I then wrote a user app that uses BeginUpdateResource, UpdateResource, and
EndUpdateResource to replace the resources with a newer versions of the
resources that were built later. This sort of thing is done routinely to
localize .exe and .dll files by replacing string table resources with other
language versions. I've discovered that this can also be done to .SYS
files.

The last missing bit is how to get at the resource data from my driver init
routine.

-- Andy


<.RC file>
/************************************************** **********************
* Copyright (c) 2003, 3DSP Corporation, all rights reserved. Duplication or
* reproduction of any part of this software (source code, object code or
* comments) without the expressed written consent by 3DSP Corporation is
* forbidden. For further information please contact:
*
* 3DSP Corporation
* 16271 Laguna Canyon Rd
* Irvine, CA 92618
* www.3dsp.com
************************************************** ***********************/

#ifdef RC_INVOKED
#include <windows.h>
#include <ntverp.h>
#endif

//-----------------------------------------------
// the following lines are specific to this file
//-----------------------------------------------

// VER_FILETYPE, VER_FILESUBTYPE, VER_FILEDESCRIPTION_STR
// and VER_INTERNALNAME_STR must be defined before including COMMON.VER
// The strings don't need a '\0', since common.ver has them.

#define VER_FILETYPE VFT_DRV

#define VER_FILESUBTYPE VFT2_DRV_NETWORK

// Undefine the MS company name
#ifdef VER_COMPANYNAME_STR
#undef VER_COMPANYNAME_STR
#endif

// Undefine the MS product name
#ifdef VER_PRODUCTNAME_STR
#undef VER_PRODUCTNAME_STR
#endif

// Define our own company and product name
#define VER_COMPANYNAME_STR COMPANYNAME
#define VER_PRODUCTNAME_STR PRODUCTNAME

// Define our own file name and description
#define VER_FILEDESCRIPTION_STR FILEDESCRIPTION
#define VER_INTERNALNAME_STR INTERNALNAME
#define VER_ORIGINALFILENAME_STR ORIGINALFILENAME

// Undefine the MS copyright years
#ifdef VER_LEGALCOPYRIGHT_YEARS
#undef VER_LEGALCOPYRIGHT_YEARS
#endif

#define COMPANYNAME "3DSP Corporation"

#define PRODUCTNAME "Driver for 3DSP Wireless LAN Adapters"

#define FILEDESCRIPTION "NDIS 5.0 driver"

#define INTERNALNAME "WL3DSP2K.SYS"
#define ORIGINALFILENAME "WL3DSP2K.SYS"

#define LEGALCOPYRIGHT "3DSP Corp."

#define VENDORDESCRIPTOR PRODUCTNAME

// Define our own copyright years
#define VER_LEGALCOPYRIGHT_YEARS "2001-2003"

// Define our own copyright string
#define VER_LEGALCOPYRIGHT_STR "Copyright " VER_LEGALCOPYRIGHT_YEARS ", "
LEGALCOPYRIGHT " All Rights Reserved."

// Define our driver version
#define VER_FILEVERSION 1,01,00,0000
#define VER_FILEVERSION_STR "1.01.00.0000"

#undef VER_PRODUCTVERSION_STR
#define VER_PRODUCTVERSION_STR VER_FILEVERSION_STR

#ifdef RC_INVOKED
////////////////////////////////////////////////////////////////////////////
/
// Neutral resources

#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_NEU)
#ifdef _WIN32
LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL
#pragma code_page(1252)
#endif //_WIN32

////////////////////////////////////////////////////////////////////////////
/
//
// BIN
//

IDR_BIN_AMEM BIN DISCARDABLE "res\\gpio_Amem.bin"
IDR_BIN_BMEM BIN DISCARDABLE "res\\gpio_Bmem.bin"
IDR_BIN_EMEM BIN DISCARDABLE "res\\gpio_Emem.bin"
IDR_BIN_PMEM BIN DISCARDABLE "res\\gpio_Pmem.bin"
#endif // Neutral resources

#include "common.ver"
// put the next line inside this ifdef because
// we include this file in request.c
// This supplies the GUID support
NdisMofResource MOFDATA wl3dsp.bmf
#endif











"Eliyas Yakub [MSFT]" <eliyasy@online.microsoft.com> wrote in message
news:ubtshlfYDHA.2236@TK2MSFTNGP10.phx.gbl...

On Wed, 13 Aug 2003 17:43:00 -0700, "AndyC" <acappon@3dsp.com> wrote:

Well I'm missing something as well. If you modify anything associated
with your driver exe your driver becomes (and rightly so) unsigned.

But wouldn't it be easier to take the more traditional approach and
simply have the firmware in a file that can be downloaded (using your
driver) from an application? This way everything is documented and
supported and you de-couple your driver image and its digital
signature from your firmware image.

If you don't want to (or can't) rely on an app you can always open the
file directly from the driver. Once again - this separates your
firmware image from your driver image, avoiding signing issues, and is
documented and supported.



=====================
Mark Roddy
Windows XP/2000/NT Consulting, Microsoft DDK MVP
Hollis Technology Solutions 603-321-1032
www.hollistech.com
markr@hollistech.com
For Windows Device Driver Training: see www.azius.com

This require a rebuild anyway. A separate file is better if you have "no
rebuild" requirement.

Parse the PE file yourself.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

On Wed, 13 Aug 2003 19:18:08 -0700, "Alexander Grigoriev"
<alegr@earthlink.net> wrote:

There are easy ways to get around that. Simply don't include the file
in the installation package. Have an installation application that
provides the file. Otherwise you have new versions with different
names and you use the registry to inform the driver which file it
ought to be using.





=====================
Mark Roddy
Windows XP/2000/NT Consulting, Microsoft DDK MVP
Hollis Technology Solutions 603-321-1032
www.hollistech.com
markr@hollistech.com
For Windows Device Driver Training: see www.azius.com

"Mark Roddy" <mroddy@tellink.net> wrote in message
news:d7umjvoprrjeosletrkrvi4nephrq96dei@4ax.com...
Or you can store it in the registry as a REG_BINARY. If it's too big for
one value, use multiple values and congeal them into a single image in
memory. Once you go there, you can even have multiple images in memory, and
select the one you want at init time. Been there, done that. It's never
been used in product, as far as I know, but the technique is valid. David's
caveats about behavioral changes are very gremane here.

That said, firmware *should* be resident on the device, if at all possible.

Phil
--
Philip D. Barila Windows DDK MVP
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.
E-mail address is pointed at a domain squatter. Use reply-to instead.

Using a separate file or obtaining the firmware code from the registry
defeats the purpose of digitally signing. For deployment I want the driver
to be able to count on an exact version of firmware loaded in the device.



The convenience of updating is for collaboration during development. The
firmware code is developed by a different group of programmers. This way I
can periodically deliver stable executable binaries that they can use as
context for their day to day debugging of the firmware code. If they have
to rebuild the driver every time they could be affected every time a source
file is updated in our configuration management setup. We can get around
this by tagging specific sets of source code as stable in the CM system, but
this is far from foolproof.



In case it matters, this is an NDIS miniport driver, and I only need file
access during my driver initialization. My current implementation allows
firmware development to proceed based on opening and mapping a separate file
as suggested, but I was hoping to find a more elegant solution here.



Thanks to all who have responded. This is by far the most interest I've had
yet in posting to this group.









"Mark Roddy" <mroddy@tellink.net> wrote in message
news:0snljvo6vv8q2ggllij2agt9fhqvc20v1e@4ax.com...

For one my driver, I have a "basic functionality" built-in firmware image, that enables
the driver to just start the device and do basic things.
Immediately after PnP install, or even before it, user copies a current firmware file.
When the driver finds this file on startup, it uses it instead of built-in image.
This file is not part of the signed package. Updating it won't cause problems - except
that it cannot be rolled back automatically.

What do you think of this?

- PA

"Mark Roddy" <mroddy@tellink.net> wrote in message
news:60umjvs7k21mpvk9u6m2c8v9a8knuve468@4ax.com...

Have a separate file that is signed with the RSA private key and the
driver/install have the public key. Any one could then check the file if
they grabbed the key, but wouldn't be able to modify it. The only advantage
to using a resource in the driver is that you can be certain that when your
driver is copied, the firmware goes with it. You could also use the signed
files as the resources so you can be certain of immunity from tampering.
Don't bother to encrypt them, because if you can decrypt them, someone can
reverse engineer it since all the pieces are there.

"AndyC" <acappon@3dsp.com> wrote in message
news:uacPW0nYDHA.1056@TK2MSFTNGP10.phx.gbl...