Why dism.exe in Windows 7 SP1 RTM is still SP0 (6.1.7600.16385)

Discussion in 'Windows 7' started by dvda2k, Jan 26, 2011.

  1. throbber

    throbber MDL Addicted

    Mar 13, 2008
    585
    32
    30
    .........welcome back :)
    and yes i totally agree
     
  2. Squall-Leonhart

    Squall-Leonhart MDL Member

    Jul 23, 2009
    172
    44
    10
    #42 Squall-Leonhart, Feb 14, 2011
    Last edited by a moderator: Apr 20, 2017
    I can answer this one.

    The sys file has 2 versioning points, at 2 seperate placements. the one that appears in the details tab comes from the Resource tables, while the misreported version in device manager comes from the file header, which happens to be where the first part of the signing tables are stored.

    when you move the file, the signature is being read from the file itself, whilst as long as its in the system32 folder, it is pulled from the registry info. (32bit apps can't directly access system32)
     
  3. Enigma256

    Enigma256 MDL Senior Member

    Jan 17, 2011
    357
    309
    10
    #43 Enigma256, Feb 14, 2011
    Last edited by a moderator: Apr 20, 2017
    That is incorrect. The resources at the end of the PE file is the one and only place where versioning information is stored in a PE file (and a sys driver file does follow the standard PE format). Now, the headers at the beginning do have three version fields, for OS, subsystem, and image versions, but those are very rudimentary: 2 WORDs each for major and minor, so the most you can get out of that is a "6.1". No 7600. No 17514. And certainly not the string version with the "rtm" tag.

    That, too, is incorrect. While it is true that most 32-bit apps cannot read from Wow64-virtualized locations like system32, that redirection layer can be disabled, and in fact, sigcheck does call Wow64DisableWow64FsRedirection to do precisely that (you can see that from a disassembly; it's, of course, GetProcAddress'ed, so it won't show up in the import tables). And you can verify that sigcheck is indeed reading the file itself by placing a test file in that location and seeing if sigcheck can pick it up.

    Now, the signature itself is not stored in the .sys file; it's stored in the security catalog. So for the signature verification, sigcheck does indeed refer to the security catalog. But it's referring to the security catalog regardless of the location of the file, so the fact that it gets the signature externally should not have an effect (plus, AFAIK, there is no version information stored in the security catalog).

    To put the location issue to rest once and for all, consider this, which I ran from an elevated command prompt:
    Code:
    C:\Windows\System32\drivers>copy usbport.sys usbport2.sys
            1 file(s) copied.
    
    C:\Windows\System32\drivers>sigcheck -q -h usbport*
    C:\Windows\System32\drivers\usbport.sys:
            Verified:       Signed
            Signing date:   13:37 2010-11-20
            Publisher:      Microsoft Corporation
            Description:    USB 1.1 & 2.0 Port Driver
            Product:        Microsoft« Windows« Operating System
            Version:        6.1.7600.16385
            File version:   6.1.7600.16385 (win7_rtm.090713-1255)
            MD5:    b6d64ee607637301ff8c33139b4950de
            SHA1:   d00083a979962b9c24274683bafc0e22c519fee6
            SHA256: e7fe3ec3da3cabdbbe2c23baa5fe3cd64da01ff73b4b4c2f077224a607e688dd
    
    C:\Windows\System32\drivers\usbport2.sys:
            Verified:       Signed
            Signing date:   13:37 2010-11-20
            Publisher:      Microsoft Corporation
            Description:    USB 1.1 & 2.0 Port Driver
            Product:        Microsoft« Windows« Operating System
            Version:        6.1.7601.17514
            File version:   6.1.7601.17514 (win7sp1_rtm.101119-1850)
            MD5:    b6d64ee607637301ff8c33139b4950de
            SHA1:   d00083a979962b9c24274683bafc0e22c519fee6
            SHA256: e7fe3ec3da3cabdbbe2c23baa5fe3cd64da01ff73b4b4c2f077224a607e688dd