Monday, October 03, 2011

Implementation Of Drivers in MSI repackaging

Types of Driver and how to analyze for drivers in the source:
  1. Whenever repackaging a driver application the first step is to figure out the type of driver by analyzing the source for driver files and registries.

  1. The driver may be a printer driver, a signed or unsigned driver, driver setup available with the source (MSI or EXE or Command line setup), installation information (.inf) file available with the driver, driver getting implemented via registries(This refers to mainly a system driver with .sys extension which creates and starts the corresponding service related to its function) .

  1. If you can not find ".exe" or ".msi" from source then try to search for driver on Internet by name of company or name of driver for e.g. Broadcom NetXtreme Gigabit Ethernet Driver.

  1. If you can not find Driver setup from Internet. Then again look for the driver related files (.INF, .Sys, .cat, .dll) in initial capture. If original application setup is implementing the driver using the ".INF, .sys, and .Cat" then most of the time you will get these files installed by application under “application folder\Driver" or Under "Windows\System32\Drivers" folder.

Driver Implementation methods

Printer Driver: Use standard Printer Driver implementation technique

    1. Many, if not all, printer settings can be done from Windows 2000's/Windows XP command line using PRINTUI.DLL and RUNDLL32.EXE.
    2. The list of functions on this page was generated using the following command in Windows XP (Professional):


3. Usage:

RUNDLL32 PRINTUI.DLL, PrintUIEntry [options] [@commandfile]

Some Examples:
Run add printer wizard on \\machine:
RUNDLL32 PRINTUI.DLL, PrintUIEntry /il /c\\machine

Run queue view:
RUNDLL32 PRINTUI.DLL, PrintUIEntry /o /n\\machine\printer

Run inf install:
RUNDLL32 PRINTUI.DLL, PrintUIEntry /if /b "Test Printer" /f %windir%\inf\ntprint.inf /r "lpt1:" /m "AGFA-AccuSet v52.3"

Implementation using information file (.inf)[rundll.exe{16-bit} or rundll32.exe{32-bit}] interface
  1. 1.The rundll32.exe process is responsible for running DLLs and placing its libraries in the memory. The rundll32.exe process is known as a command line utility program, and it performs its embedded functions along with the rundll.exe file. Rundll32.exe works by invoking a function that is exported from a specific 16-bit or 32-bit DLL module. However the only DLLs that you can call with the rundll.exe and rundll32.exe files are the ones that are only specified to be accessed by these processes.
  2. The rundll32.exe file operates by parsing the command line. The specified DLL is then loaded through the function LoadLibrary (). Afterwards, from the function, it gets the addresses through GetProcAddress (). The command line tail is passed when it is called. Next, the DLL is unloaded upon the return of. Finally, the rundll32.exe file exits. The following command can be used for driver implementation using the driver's standard .Inf file:
    "%SystemRoot%\System32\rundll32.exe setupapi, InstallHinfSection <SectionName> 132 %1"

    This is to be decided as per each driver and will refer to its installation section within the .INF file
    This parameter refers to the full path of the installation .Inf file

    Implementation Using .SYS files(Implementation via hardware registries)[ALREADY POSTED IN PREVIOUS POST]

    1. Some drivers are unsigned and do not have any .inf file for installation. In this case the drivers are implemented through .sys files.
    2. These drivers can be seen in Device Manager by clicking show hidden drivers.
    3. Most of the times one can see the hidden drivers under non plug and play drivers tab
    4. To implement these drivers within the MSI, use the registry values under

    <drivername> in many cases will be the .sys file name.

    Include these registries in the MSI. System needs reboot after installing the MSI. After reboot these drivers will get configured by themselves.
    Example: To implement VPN-1 SecureClient Adapter, the registries that are included in the package are shown below:

     As per as my experience of repackaging a  .sys files involved a custom action to run in system context to start the corresponding service offered by the driver file as:

    Create and start a service that runs the .sys driver

    sc create npf binPath= system32\drivers\<filename>.sys type= kernel start= auto error= normal tag= no DisplayName= "<DisplayName>"

    Implementation using command line from source EXE or MSI
    1. Check the source whether driver related exe is present or not. Most of the time you will find driver related ".exe" or ".msi" in the one of the source folder.
    1. If you find such ".exe" or ".msi" then use the same file to implement Driver in your MSI Package. Write a Custom Action "Execute program from Installation" in Deferred Execution/Immediate execution with silent (-s, /quite, /silent etc.) option.

    3. Most of the time you can find the command line getting written at C:\Windows\setupapi.log file.

    Implementation using Setupapi.dll

    1.       Certain driver related applications when installed have information like PNF, INF, CAT file at location “C:\Windows\inf”.As per the driver, this are by default name to oemXX.pnf or oemXX.inf where XX stands for the number .E.g. oem1.INF, oem1.PNF and so on. As a result whenever a driver application is repackaged containing this information, the XX value is hardcoded and it does affect other driver information files which are already present on the target machine.
    2.       To overcome the above issue we write certain custom actions using the file ‘setupapi.dll’  in such a way that it checks for the maximum XX value present on the machine and accordingly installs the PNF or INF file of the repackaged application.
    1. This method is time consuming as it requires creating multiple custom actions for copying oem/pnf files. In the next method will discuss "DPInst.exe" related to driver based packages.
    2. Setupapi.log located at C:\Wnidows records the driver’s related specifications. The following are some important functions as part of the Setup API.

    ·         SetupAddToSourceList Function

    1.       The SetupAddToSourceList function appends a value to the list of installation sources for either the current user or the system. If the value already exists, it is removed first, so that duplicate entries are not created.

    2.       A caller of this function is required to have administrative privileges, otherwise the function fails.

    3.       Unicode Implemented as SetupAddToSourceListW (Unicode) and SetupAddToSourceListA (ANSI).

    4.       In our DB environment we use ANSI format hence our Function name will be SetupAddToSourceListA

    ·         SetupCopyOEMInf function

    1.       The SetupCopyOEMInf function copies a specified .inf file into the %windir%\Inf directory. SetupCopyOEMInf does not recopy the file if it finds that a binary image of the specified .inf file already exists in the INF directory with the same name or a name of the form OEM*.inf. When SetupCopyOEMInf copies a file, it renames the copied file to OEM*.inf. Name provided is unique and cannot be predicted.

    2.       SetupCopyOEMInf uses the following procedure to determine if the .inf file already exists in the Inf directory:

    3.       All .inf files with names of the form OEM*.inf are enumerated and any files that have the same file size as the specified .inf file are binary compared.

    4.       The Inf directory is searched for the source filename of the .inf file. If an .inf file of the same name exists and is the same size as that of the specified .inf file, the two files are binary compared to determine if they are identical.

    5.       If the specified .inf file already exists a further check is performed to determine if the specified .inf file contains a CatalogFile= entry in its [Version] section. If it does, the .inf file’s %windir%\Inf primary filename with a ".cat" extension is used to determine if the catalog is already installed. If there is a catalog installed, but it is not the same as the catalog associated with the source .inf, this is not considered to be a match and enumerations continue. It is possible to have multiple identical .inf files with unique catalogs contained in %windir%\Inf directory. If an existing match is not found, the .inf and .cat files are installed under a new and unique name.

    6.       OEM .inf files that do not specify a CatalogFile= entry are considered invalid with respect to digital signature verification.

    7.       In cases where the .inf file must be copied to the %windir%\Inf directory, any digital signature verification failures are reported.

    8.       If the .inf and .cat files already exist, these existing filenames are used and the file replacement behavior is based on the specified CopyStyle flags. Replacement behavior refers only to the source media information stored in the .pnf. Existing .inf, .pnf, and .cat files are not modified.


        • Create a folder and install the driver files to this folder. This folder can be in INSTALLDIR too.
        • In the Execute Deferred section sequence an If Statement custom action after the InstallFiles action. Make the execution of this action only apply on install by giving it the condition "NOT Installed"
        • To this If Statement add a "Call Custom DLL From Destination" custom action with the settings: 
    1.       Custom Action Name: SETUPADDTOSOURCELISTA
    2.       DLL File: [SystemFolder]setupapi.dll
    3.       Function Name: SetupAddToSourceListA
    4.       Parameter: dword, Constant, 00000100
    5.       Parameter: string pointer, Constant, <Path to driver.inf file>. (Don't enclose paths in double quotes)
    6.       Return Value Type: dword
    7.       Return Property: DLLRETURN (Pre creating a property has more consistent results) 
    ·         Add a second "Call Custom DLL From Destination" custom action within the same If\End statement with the settings:

    1.       Custom Action Name: SETUPCOPYOEMINF
    2.       DLL File: [SystemFolder]setupapi.dll
    3.       Function Name: SetupCopyOEMInfA
    4.       Parameter: string pointer, Constant, <Path to driver.inf file> (Don't enclose paths in double quotes)
    5.       Parameter: long, Constant, NULL
    6.       Parameter: dword, Constant, 1
    7.       Parameter: long, Constant, NULL
    8.       Parameter: long, Constant, NULL
    9.       Parameter: dword, Constant, 0
    10.   Parameter: long, Constant, NULL
    11.   Parameter: long, Constant, NULL
    12.   Return Value Type: dword
    13.   Return Property: DLLRETURN

    ·         SetupUninstallOEMInf Function

    1.       The SetupUninstallOEMInf function uninstalls a specified .inf file and any associated .pnf file. If the .inf file was installed with a catalog for signing drivers, the catalog is also removed. A caller of this function must have administrative privileges, otherwise the function fails.
    2.       The SetupUninstallOEMInf function first checks whether there are any devices installed using the .inf file. A device does not need to be present to be detected as using the .inf file.

    3.       If this flag is not set and the function finds a currently installed device that was installed using this .inf file, the .inf file is not removed.

    4.       If this flag is set, the .inf file is removed whether the function finds a device that was installed with this .inf file.

    ·         Uninstallation Custom Action
    1.       In the Execute Deferred section sequence an If Statement custom action prior to the RemoveFiles action. Make the execution of this action only apply on uninstall by giving it the condition REMOVE~="ALL"
    2.       To this If Statement add a "Call Custom DLL From Destination" custom action with the settings:
    3.       Custom Action Name: SETUPREMOVEFROMSOURCELISTA
    4.       DLL File: [SystemFolder]setupapi.dll
    5.       Function Name: SetupRemoveFromSourceListA
    6.       Parameter: dword, Constant, 00000100
    7.       Parameter: string pointer, Constant, <Path to driver.inf file> (Don't enclose paths in double quotes)
    8.       Return Value Type: dword
    9.       Return Property: DLLRETURN

    Implementation Using DPInst.exe tool
    1.       DPInst is a component of the Microsoft Windows Driver Install Frameworks (DIFx) that simplifies and customizes the installation of driver packages for devices that are not yet installed on a computer (commonly known as a software-first installation). DPInst also automatically updates the drivers for any installed devices that are supported by the newly installed driver packages.

    2.       How Packages Install using DPInst

    3.       By default, when the Microsoft® Windows® Driver Package Installer (DPInst) runs, it runs in a wizard-install mode that displays a sequence of wizard pages. In wizard-install mode, DPInst first displays a welcome page, and then displays an end-user license agreement (EULA) page. After the user accepts the licensing agreement on the EULA page, DPInst displays an installation page, and then performs the following steps to install Plug and Play (PnP) function drivers:
    ·         Locates the INF files. DPInst searches the directory where the DPInst executable (DPInst.exe) is located. DPInst also searches vendor-specified subdirectories under the directory where DPInst.exe is located. A vendor specifies the subdirectories by using the search and subDirectory XML elements in an optional DPInst descriptor file (DPInst.xml)
    ·         Authenticates the driver packages.
    ·         Preinstalls driver packages in the driver store.
    ·         Adds an Add or Remove Program entry in Control Panel that represents a driver package. (DPInst does not support this feature on Windows Longhorn.)
    ·         Installs the driver packages on matching devices that are connected to a computer.
    4.       After DPInst completes the installation of a driver package, DPInst displays a finish page that informs the user of the status of the installation.
    5.       DPInst supports a suppress-wizard mode that suppresses the display of wizard pages and other user messages that DPInst generates. It also supports command-line options that control the display of its wizard pages and other DPInst operations.
    6.       For general information about INF files and driver packages, see "Providing a Driver Package" in the Microsoft Windows Driver Development Kit (WDK).
    Steps to Follow in MSI package
    Step 1: Search for "*.inf" files in the captured folder.
    Step 2: Cross check the contents of this file (step 1) with the contents of "*.inf" files under "[WindowsFolder]INF" folder.
    Step 3: Delete the file "oemXX.inf" from "[WindowsFolder]INF" folder from your package.
    Step 4: Copy DPInst.exe under the location where you get the ".inf" file.
    Step 5: Write a custom action as shown below.

    Fig 1

    Fig 2

    Fig 3
    Repeat the above steps from 1 to 5 for each oemXX.inf files.
    Now the MSI package created will be able to install the driver files without affecting the pre-existent application's functionality as well as the operating system.
    Features of DPInst:
    • Localization. There are two versions of DPInst: an English-only version and a multi-language version that supports many of the commonly used languages that Windows supports.
    • Driver installation customization. You can localize and customize the text, icon, and bitmaps that are displayed on wizard pages. You can include branding, an optional EULA, and control whether wizard pages are displayed.
    • Automatic driver package removal. For each driver package that is installed by DPInst, DPInst adds an entry to Add or Remove Programs (in Control Panel) where a user can remove the driver package from their computer. If the user removes a driver package, the package is removed from the driver store, the corresponding INF file is removed from the system INF file directory, and all devices that were previously supported by the package are updated with the next best available driver.
    • Installation error logs. DPInst logs high-level messages in the DPInst log file (%windir%\DPINST.LOG). The log file is a plain-text file that contains information and error messages and identifies the driver package that was being installed when an error occurred.
    Driver Package Installer (DPInst)
    DPInst Command-Line Switches

    Implementation Using Microsoft DIFx tool

    1. If you are able to find all driver related files i.e.  .INF, .Sys, .cat Then use DIFFAx tool (Microsoft Tool having Custom Action to implement Driver). To use the DIFFAx tool install the msi DriverInstallationTools.EXE
    Here I will discuss the Windows XP installation for a Signed Driver: ‘ClassFilter Driver’ with Wise Package Studio.

    Step by Step - Creating a driver installation with DIFx using Wise Package Studio

    1.  Create a new Windows Installer (WSI) file

    Work bench –> Tools –> Windows Installer Editor

    If you do not get the ‘New Installation File’ window shown below, select File –> New from the main menu inside Windows Installer Editor
    (By default, the last edited .WSI file will be opened).
    Select Windows Application

    As this will be a Driver only installation we are renaming the default Wise feature from ‘Complete’ to ‘Drivers’.
    Note: If your own installation is to also contain non driver files (e.g. captured application files). Ensure there is a SEPARATE feature which will contain these.

    Installation Expert –> Features
    Rename the default feature from ‘Complete’ to ‘Drivers’

    2.  Next, we add the DIFxApp Merge Module to the ‘Drivers’ Feature

    Merge Modules –> Add

    Select the DIFxApp Merge Module and click Next then Finish
    (if the Module is not present select ‘Download’ then ‘Wise Web Site’ to obtain it)

    Note: Make sure you are using at least version 2.0 of DIFxApp Merge Module.

    The DIFxApp Merge Module should then be visible.

    3.  Create a folder EXCLUSIVELY for driver files.

    Note: If there is more than one driver (not the case with our example), there must be a SEPARATE folder for EACH driver and associated files.

    Open the Files view, then in the bottom window Right Click on ‘Program Files’ and select ‘New Folder’  

    4.  Add the relevant driver files

    To save experiencing a common problem (this issue will be detailed later), ensure the ClassAFilterDriver.inf file is added FIRST. Doing this step ensures the .inf file becomes the KeyPath for the component to contain the driver files.

    Highlight the ‘ClassFilterDriver’ folder in the bottom left window, then select ONLY the ClassAFilterDriver.inf.inf file in the top window and click the Add File button.

    The ClassAFilterDriver.inf file should be visible in the bottom right window as shown below.
    Next, add the remaining files to the ‘ClassFilterDrive’ folder:

    Check the ‘ClassFilterDrive’ folder is highlighted in the bottom left window, then select the remaining files in the top right window and click the Add File button.

    All files for a specific driver need to be in one root folder along with the .inf file for a successful installation via DifX.

    5.  Configure Driver Installation Options

    Double click on the ClassAFilterDriver.inf file in the bottom right window to set driver options.

    Installation Expert –> Files –>

    Select the Driver tab

    What to do if there is no Driver tab
    Note: If the Driver tab IS present, skip to the next section: ‘Configure Driver Installation Options (Continued)’
    This is a common problem with a relatively straight forward solution.
    Open Setup Editor from the bottom of your screen and select the Components tab at the top of the left window.
    Expand out each component in the left window and look in the relevant Files section until you find the ClassAFilterDriver.inf file.

    In our example below, the component containing the .inf file is called ClassAFilterDriver.inf. We can see that there is a small yellow key icon beside the in the ClassAFilterDriver.inf file in top of the right window.
    This means that the file is the KEYPATH for the component it is in.

    Setup Editor –> Components

    If the yellow key is NOT present beside the .inf file then it needs to be enabled:
    Right Click on the ClassAFilterDriver.inf file and click Set as Key

    Note: If you are familiar with using the MSI Tables, the same as above can be achieved there: Reference ClassAFilterDriver.inf in the File table to find the relevant component name.
    Then, edit the KeyPath of the matching entry in the Component table.

    Configure Driver Installation Options (Continued)

    Under the Driver tab, ensure the ‘Use DIFxApp to install this driver file’ option is enabled.

    Enable the DIFxApp Installation Options to meet your preferences (these are described below).

    DIFxApp Installation Options

    Retain better-matching Pnp function drivers
    Enabling this option will keep an existing Plug and Play driver on the computer if it is seen to be a better match (“better match” means if there is a signed and/or newer driver already on the computer this will be retained and the driver in this installation will not be installed).
    If you clear this checkbox, the installation's driver will be installed and over-ride any existing driver on the computer.

    Prompt for missing device
    Enabling this option gives a prompt and the end of the installation. This will occur if the matching device to the driver is NOT connected to the computer.
    Note: Even if this option is enabled, the prompt will NOT appear under a silent install.

    Create entry under Add/Remove Programs
    This will add an entry under Add/Remove Programs for the driver(s) installed in ADDITION to the standard entry for the MSI installed.

    Configure the above DIFxApp Installation Options to your preferences then click OK to confirm.

    OS Specific Launch Condition
    Once all the steps above have been completed, consider what version of OS the driver is intended for. An ‘accidental’ rollout of out a Windows XP Driver Package to a Windows 2000 PC may not give very desirable results!

    The best safeguard is to condition the installation so it will only install on the intended OS.
    This can be achieved through setting System Requirements.

    Under Installation Expert in the left window select System Requirements.
    The relevant options to configure are Windows Version and Windows NT Version. These are shown highlighted in the right window below. Double click to edit them.

    In the case of our example our driver is intended for Windows XP, so we have set Windows Version (i.e. Windows 95, Windows 98 etc) to ‘Not supported’.
    Also the Windows NT Version has been set to ‘Windows XP’.

    The Message Text field defines the actual message to display if the OS Condition is NOT met.

    Installation Expert –> System Requirements

    Once this has been completed, compile your MSI and the Driver Package is ready to go!

    For Reference Only

    The key table involved for a driver installation using DifX is the MsiDriverPackages table. The use of each column is as follows:

    Should have the name of the component containing the .inf file for the driver.

    A number which defines the type of driver to be installed, (Signed or Unsigned) along with the specific Installation Options.

    Controls then install order of drivers (if there is more than one driver, lowest number installs first).

    Setup Editor –> Tables –> MsiDriverPackages

    The following are common examples of values for the Flags column:

    Signed Driver Installation

    7 = Signed driver install (Standard install with no options configured)
    6 = Signed driver install + “Retain better-matching PnP function drivers”
    5 = Signed driver install + “Prompt for missing device”
    3 = Signed driver install + “Create entry under Add/Remove Programs”

    Unsigned Driver Installation

    8 = Unsigned driver install (Standard install with no options configured)
    14 = Unsigned driver install + “Retain better-matching PnP function drivers”
    13 = Unsigned driver install + “Prompt for missing device”
    11 = Unsigned driver install + “Create entry under Add/Remove Programs”

    Note: Officially, the valid range that can be used in the Flags column is a number between 0 – 7.
    Because unsigned driver installations are ‘unsupported’ by Microsoft, the range for unsigned driver installations is 8 and above. Any of these options will show up as a table error (in addition it will appear as an ICE error if a validation is run). This is normal.

    Tip: For an unsigned driver installation you won’t be able to set the options via the interface in Wise (using the Driver tab of the .INF file). You will need to go into the MsiDriverPackages table and set the Flags value directly.


Owen said...

This is in error.

"Tip: Some drivers have several different folders containing the relevant files. If this appears to be the case, check the entries of the .inf file to see if there are references to files in a subfolder(s). If so, you may need to modify the file path entries in the .inf file, to allow all the files to be in ONE root folder.
All files for a specific driver need to be in one root folder along with the .inf file for a successful installation via DifX. "

In fact, if you modify the INF file it will BREAK the code signing. As far as I can tell, the inf file works fine and the drivers are recognized regardless of folder structure - assuming of course that it is a legit signed driver and the INF file is correct.

The rest of the article is right on, though. Very helpful.

Owen Gilmore
Packaging Systems Analyst

D Entertainment said...

đồng tâm
game mu
cho thuê phòng trọ
cho thuê phòng trọ
nhac san cuc manh
tổng đài tư vấn luật miễn phí
văn phòng luật
số điện thoại tư vấn luật
thành lập công ty