View Single Post
Old 03-19-2016, 11:15 PM   #2
Marco77
Connoisseur
Marco77 can illuminate an eclipseMarco77 can illuminate an eclipseMarco77 can illuminate an eclipseMarco77 can illuminate an eclipseMarco77 can illuminate an eclipseMarco77 can illuminate an eclipseMarco77 can illuminate an eclipseMarco77 can illuminate an eclipseMarco77 can illuminate an eclipseMarco77 can illuminate an eclipseMarco77 can illuminate an eclipse
 
Posts: 55
Karma: 8430
Join Date: Mar 2016
Device: PW3, Clara HD, PB740
(Following is technical explanation; left for informative / educational purposes)

【Original issue】
· On Windows 10 specifically (version 1511 / TH2 as of this writing), the OS recognizes the Kindle with USBNetwork (Linux USB Gadget productId 0x0525, vendorId 0xA4A2) as a "Serial USB device" instead of a "Linux-USB Ethernet/RNDIS Gadget" (or an unknown device which would require drivers)
See: http://answers.microsoft.com/en-us/w...5590447?auth=1

Quote:
Originally Posted by dlech at MS Forums
The Linux rndis gadget function has USB class of 2 and subclass of 2, which matches "USB\Class_02&SubClass_02" in the usbser.inf file. This is why for some people, their device is initially detected as a COM port instead of RNDIS.
With some quick googling, it seems some VM users do not encounter this issue, perhaps because the class / subclass pair is tampered when it is presented to the guest?

Anyway, as a consequence, if you try to update its drivers, Windows will only show compatible drivers i.e. serial port drivers


【Rationale】

The solution is to provide a driver that will specifically handle USB\PID_0525&VID_A4A2. It is just a dummy driver that will tell the OS our "Linux USB Gadget" should be handled as a remote NDIS device. Windows has been shipping with the RNDIS driver bundled in for quite some time now, so it's basically a matter of a simple declaration.

However, starting with Vista (EDIT: probably Windows 8 as mentioned below), Windows has been enforcing a mandatory signing requirement for 64-bit drivers.
What it means is, every part of the driver bundle must be hashed and referenced in a catalog file (*.cat); this catalog itself is cryptographically signed to ensure authenticity and integrity.
For WHQL drivers, Microsoft is the one who signs the catalog (after a bunch of tests).
You can see installed drivers by running "pnputil -e". Most of them should be signed by "Microsoft Windows Hardware Compatibility Publisher".
If you open the Computer Certificate Store (Run: certlm.msc) and browse to "Trusted Publisher", you may see others, depending on your PC brand.

The idea is to generate a Code-Signing Keypair (Private-Key + Certificate), which will be "self-signed" (issuer == subject). The idea came to me because I use custom drivers signed by Fernando's WinRAID certificate authority.
As stated on their thread:
Quote:
All my "mod+signed" drivers can easily been installed even while running Win8/10 without disabling the "Driver Signature Enforcement".
It is a critical point. You don't want random people to install kernel-mode drivers without some sort of check, both for stability (bsods) and for integrity (tampering/rootkits).

In our specific case, the "driver" is merely an .inf file.
What it basically says is, "hey, treat this kindle as a RNDIS device (a USB/Ethernet adapter); drivers are already in Windows (and signed) so you don't need to copy anything."

【Generating the Code-Signing Keypair】
We will now create a keypair. Usually, you would use an offline machine to do that, because you don't want people to obtain your private key and distribute malware while impersonating you or your company. (Recent example, sony)

Requirements are the driver package in first post, and the Enterprise WDK from Microsoft. You can download it at https://msdn.microsoft.com/en-us/win...enterprise-wdk after accepting the EULA.

After obtaining the kit, extract it to C:\EWDK.
We actually only need a very very small subset of the kit, in C:\EWDK\Program Files\Windows Kits\10\bin\x86 (~50 MiB out of 1.5 GiB), maybe we could only fetch the relevant parts of the ZIP remotely like some do at reboot.pro/ but it is out of scope of this tutorial.

Open "1-create_CA.cmd" in a text editor.
Code:
"C:\EWDK\Program Files\Windows Kits\10\bin\x86\makecert.exe" ^
  -r -pe -n "CN=MobileRead-CodeSigning-CA,O=MobileRead Forums,OU=Marco77" -ss My -sr CurrentUser ^
  -a sha256 -cy end -sky signature -sv MobileRead-CodeSigning-CA.pvk -eku 1.3.6.1.5.5.7.3.3 -len 2048 ^
  MobileRead-CodeSigning-CA.cer

It will generate the Code-Signing Keypair (prompting you for a passphrase multiple times) and store the public part (certificate) in your personal store.

Let's run down the options here:
  • -r Create a self signed certificate
  • -pe Mark generated private key as exportable
  • -n <X509name> Certificate subject X500 name (eg: CN=Fred Dews)
  • -ss <store> Subject's certificate store name that stores the output certificate
  • -sr <location> Subject's certificate store location.
  • -a <algorithm> The signature's digest algorithm. AFAIK MS won't accept SHA1 code-signing certificates issued in 2016.
  • -cy <certType> Certificate types. End-user here even if self-signed.
  • -sky <keytype> Subject key type
  • -sv <pvkFile> Subject's PVK file; To be created if not present
  • -eku <oid[<,oid>]> Comma separated enhanced key usage OIDs (1.3.6.1.5.5.7.3.3 = code signing)
  • -len <number> Generated Key Length (Bits). 2048 is enough for RSA for now.
  • [outputCertificateFile]

Viva StackOverflow! http://stackoverflow.com/questions/8...ing-on-windows

After executing, if you open your personal store (Run: certmgr.msc), you will see your certificate, and in the folder, the (pvk, cer) keypair files.

Next, open the second batch "2-make_pfx.cmd"
Code:
"C:\EWDK\Program Files\Windows Kits\10\bin\x86\pvk2pfx.exe" ^
  -pvk MobileRead-CodeSigning-CA.pvk -spc MobileRead-CodeSigning-CA.cer ^
  -f -pfx MobileRead-CodeSigning-CA.pfx
This command combines your keypair in a single passphrased pfx (analogue to a PKCS #12 container)
  • -pvk <pvk-file> - input PVK file name.
  • -spc <spc-file> - input SPC file name.exportable
  • -f - force overwrite existing PFX file.
  • -pfx <pfx-file> - output PFX file name.

【Signing the Driver】
It's a two-stage operation: enumerate files into a catalog (*.cat), sign the catalog.

Step 3, "3-build_cat.cmd" will inspect the INF file and produce a catalog of signed files.

Code:
"C:\EWDK\Program Files\Windows Kits\10\bin\x86\Inf2Cat.exe" /driver:. /os:8_X64 /v
  • /driver:path Indicates the path to the driver package follows.
  • /os:operatingSystem1[,os2] - Indicates the operating system(s) targeted by the driver package follows.
  • /verbose (/v) Displays detailed console output.

Inf2cat is a new command in Enterprise WDK, maybe WDK8's makecat.exe works too.

On to step 4, "4-sign_cat.cmd":
Code:
"C:\EWDK\Program Files\Windows Kits\10\bin\x86\signtool.exe" sign /v ^
  /f MobileRead-CodeSigning-CA.pfx ^
  /fd sha256 /tr http://timestamp.comodoca.com/?td=sha256 /td sha256 ^
  kindle_rndisamd64.cat
  • sign -- Sign files using an embedded signature
  • /v Print verbose success and status messages. This may also provide slightly more information on error.
  • /f <file> Specify the signing cert in a file. If this file is a PFX with
    a password, the password may be supplied with the "/p" option.
    If the file does not contain private keys, use the "/csp" and "/kc"
    options to specify the CSP and container name of the private key.
  • /fd Specifies the file digest algorithm to use for creating file
    signatures. (same remark as above)
  • /tr <URL> Specifies the RFC 3161 timestamp server's URL. If this option (or /t) is not specified, the signed file will not be timestamped.
    A warning is generated if timestamping fails. This switch cannot be used with the /t switch.
  • /td <alg> Used with the /tr or /tseal switch to request a digest algorithm used by the RFC 3161 timestamp server.
  • <filename(s)>

An alternative to comodo timestamping (untested):

【Register the code-signing public certificate】
The last step is registering the code-signer as a trusted party.
The batch needs to be run as admin because it modifies the Computer certificate store.

Code:
::run as admin

cd /d %~dp0

call %SYSTEMROOT%\System32\certutil.exe -f -addstore "Root" MobileRead-CodeSigning-CA.cer

call %SYSTEMROOT%\System32\certutil.exe -f -addstore "TrustedPublisher" MobileRead-CodeSigning-CA.cer

pause
Et voilą! You can now update the device drivers with the provided INF+CAT driver.




【Bonus:verify cat on the commandline】
"C:\EWDK\Program Files\Windows Kits\10\bin\x86\signtool.exe" verify /v /pa kindle_rndisamd64.cat

Verifying: kindle_rndisamd64.cat
Signature Index: 0 (Primary Signature)
Hash of file (sha256): A00949E21571B0998155AAE120B6C03F0113334D490E8E1CC3 7EB2BC09D985C2

Signing Certificate Chain:
Issued to: MobileRead-CodeSigning-CA
Issued by: MobileRead-CodeSigning-CA
Expires: Sun Jan 01 00:59:59 2040
SHA1 hash: 58E285D47509E810DCCFA865A8F6D99B8A297FA5

The signature is timestamped: Sun Mar 20 12:38:06 2016
Timestamp Verified by:
Issued to: UTN-USERFirst-Object
Issued by: UTN-USERFirst-Object
Expires: Tue Jul 09 19:40:36 2019
SHA1 hash: E12DFB4B41D7D9C32B30514BAC1D81D8385E2D46

Issued to: COMODO SHA-256 Time Stamping Signer
Issued by: UTN-USERFirst-Object
Expires: Tue Jul 09 19:40:36 2019
SHA1 hash: 36527D4FA26A68F9EB4596F1D99ABB2C0EA76DFA


Successfully verified: kindle_rndisamd64.cat

Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0

Last edited by Marco77; 03-20-2016 at 11:11 AM.
Marco77 is offline   Reply With Quote