Windows 10 signed RNDIS driver for USBNetwork

[Marco77]

【Prerequisites】

• Jailbroken Kindle (tested on PW3 5.6.5)
• KUAL, MRPI
• installed mrpackage kindle-usbnet
• A Windows 10 PC (x64 edition)

【Situation】
On Windows 10, when jailbroken Kindle with enabled USBNet is plugged via USB, it will appear as a "Serial USB device (COM3)" in device manager.
If Windows 10 already recognized your Kindle device as an extra network card, you do not need this driver package :3


【TL;DR】

1. Download & Unzip attachment kindle_rndis.inf_amd64-v1.0.0.1.zip
2. R-click "5-runasadmin_register-CA-cer.cmd" and "Run as administrator"*
3. In Device Manager, expand "Ports (COM & LPT)", R-click "Serial USB device (COM3)" > Update Driver Software...
4. Browse for my computer for driver software > Select extract folder

* You should not run random batch files from untrusted parties usually


【Result】
You should see a new network card Kindle USB RNDIS Device (USBNetwork enabled) in "Network and Sharing Center" > Change adapter settings. Assign a static IP such as 192.168.15.1 and you can ping the device (ping 192.168.15.244).


Note : please +Karma if you found this post useful!

[Marco77]

(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

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:

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.

"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"

"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.

"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":

"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):

-tr http://timestamp.globalsign.com/?signature=sha2 -td sha256

【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.

::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

[knc1]

What is the point?
That is the normal operation for the device.

= = = = = =

And why in the world would you distribute your private key?
Even in Windows, of a Public-Private key-pair, the Private key is kept, well, private.

Now anyone in the world can use your private key to sign a Windows driver, claiming to be yourself.

I think you should pull that archive and re-think (or read the directions) on what its contents should be.

That re-think should include posting a CRL for the (just) compromised key-pair and using a new key-pair to sign the next driver (and then only distribute the public key required to verify the signing of the driver).

[Marco77]

Thanks for the feedback @knc1,

I have pulled the zip archive and published a second version of the package.

To me it's not as huge an issue as stated because the private key is passphrased with a long enough password, but I understand what you mean and generated a fresh set of keys to sign the driver and did not distribute the private key this time

As for it being the normal procedure, that's what I thought before I actually tried; I previously "forced" the RNDIS driver for a tethered android phone in Windows 7 and it worked. However, I don't know if you have a W10 system lying around to test, but if I want to change the driver for this #!@*@ COM port device, unticking the "Show compatible hardware" checkbox won't let me select the RNDIS built-in driver.

It's possible Windows enacts some kind of enforcement and won't allow to set the driver for some unknown VID/PID couple. If you can provide some insight here, I'd gladly take it.

EDIT: the problem is mentioned at the MS forums. Apparently dlech on Sept 1, 2015 nails it:

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.

Apparently, I provide a mix of solutions 3 & 4 (custom inf + self-signed).

[knc1]

OK - I understand now (I think).

The first archive you posted had the complete set of everything you used to create the signed driver (other than the drive's source code).
That looked to me as if it was your personal, backup, archive of your work.
Not the 'end user' archive you intended to publish.

Yes - people here have mentioned that Win10 is more than a bit funky about that driver.

The rndis protocol is used by many, many devices, not just Kindles.
so I would expect that you would post your driver somewhere that Win10 users would find it, rather than only Win10 users of Kindles.

Note: We discourage the posting of closed source software at this site.
If you can give a link to your modified source code for the driver, that would be great.

But in this case, we will not ask that you be banned, just because of the funky terms of some Windows Driver License.

But if the driver code is your own work (or you have a license to publish it) -
then please give us a link to the public repository of your code (including its Open Source license).

You should understand that we get enough closed source code here from Amazon.

[Marco77]

There is no source besides the INF. You may have noticed that it ships with no *.sys device driver. The reason is simple, the file says "okay, I handle devices matching 'VID_0525&PID_A4A2', for this use the system-bundled netrndis.inf / Usb_Rndis.ndi sections."

On the contrary, all steps are outlined and you can generate your own signed "driver" using the posted batch files. The idea is not mine; I thought about it because I already use WinRAID-CA signed Intel drivers. (it's better than disabling driver signature enforcement system-wide)

EDIt: apparently there is a template for that, see https://msdn.microsoft.com/en-us/lib...s_7_and_later_

I don't know what are the benefits for 6.0 drivers vs. 5.1, though.

[knc1]

Sorry, I stopped following Windows internals somewhere between Win-2 and Win-95.

[shamanNS]

Originally Posted by Marco77

However, starting with Vista, Windows has been enforcing a mandatory signing requirement for 64-bit drivers.

Well I've been using this .inf file since Windows 7 32-bit days and I'm using it now on Windows 8.1. 64-bit. Can't really remember if I used USBNetwork while trying Windows 10... but IIRC on Windows 8.1 all I did was point Device Manager/Driver install/update dialog to that linux.inf file.

I've found the link for downloading that driver/inf file somewhere here on Mobileread ... I think that the wiki section used to have the link for downloading Windows driver, but now it's not there anymore.

[Marco77]

I'm not a specialist, but according to http://www.davidegrayson.com/signing/#dp_win8 it should be enforced starting from Win8 and not since Vista. Maybe it was disabled on your computer at some point? I remember when my laptop was on Win8 it would not accept modified INFs for my tethered phone (fortunately, manufacturer -intel- released signed ones later).

[shamanNS]

Well I didn't disable it and I'm the one who did Windows installation and the only person using this PC.
I do remember running a Command Prompt command to enable display of "non present devices" in Device Manager, to be able to delete drivers & devices after I've changed motherboard and CPU. So as to not have to reinstall Windows.
I do have UAC turned off... no idea if that has something to do with this driver(s) thing. I wouldn't expect turning UAC off to "disable" all metro/modern app but it did it, so... who knows with Microsoft

I already have another Windows 8.1 x64 copy running inside VMware so maybe I will try installing RNDIS driver on it to refresh my memory.

edit: I do get that error windows if I just try "right click>install":



On my PC that already has working USBNetwork setup.

[tshering]

With the help of kindle_rndis.inf_amd64-v1.0.0.1.zip I was able to connect to my ereaders (Kobos) via usbNet. Yesterday my pc updated to Windows Version 10.0.14393. After that the ability to use usbnet was lost, the Kindle USB RNDIS Device was gone from the adapter list ( Network and Sharing Center > Change adapter settings). I did not know exactly what to do. I run 5-runasadmin_register-CA-cer.cmd anew, tried to update the driver in the device manager; removed/desinstalled the device in the device manager, repeated those steps several times .... I cannot get it to work. Evidently, I am doing something wrong. I would appreciate any advice.

[knc1]

I read that you tried removing/de-installing the device -
Have you tried removing/de-installing the custom driver (the info file).

Perhaps your recent update included a change to the MS included driver that creates a conflict.

Hmm...
Does your version of Windows still keep a detailed log of all changes made by an update of the system?
If so, perhaps there is something helpful in the list of things the update touched.

Does your version of Windows still set a 'restore point' just prior to begining any update changes?
If so, perhaps rolling back the system to that restore point would get you back to the behavior prior to Windows self-destructing.

Or perhaps you just need to update the OS information in the signed driver -
See second post of this thread, step 3.

Consider what I suggest very carefully before doing anything, my Windows experience is very, very old.

[tshering]

Originally Posted by knc1

I read that you tried removing/de-installing the device -
Have you tried removing/de-installing the custom driver (the info file).

Perhaps your recent update included a change to the MS included driver that creates a conflict.

Hmm...
Does your version of Windows still keep a detailed log of all changes made by an update of the system?
If so, perhaps there is something helpful in the list of things the update touched.

Does your version of Windows still set a 'restore point' just prior to begining any update changes?
If so, perhaps rolling back the system to that restore point would get you back to the behavior prior to Windows self-destructing.

Or perhaps you just need to update the OS information in the signed driver -
See second post of this thread, step 3.

Consider what I suggest very carefully, my Windows experience is very, very old.

Thank you for your response. In the meanwhile I got it working. Unfortunately, I did not protocol the steps I did. Somehow it started working. I do not know what exactly made the difference. But evidently I did something wrong in my previous trials, and did it correctly now by chance.

[knc1]

Somehow it started working. I do not know what exactly made the difference.

So ship it.
That is what MS would do in that situation.

- - - - -

Seriously, thanks for the update, it tells people it is possible to make it work.
Hopefully the next person to get it working will have kept notes.

[marrco]

Using windows 10 on a new computer with version 1607 Anniversary Update there's a known bug that causes windows 10 to crash, but that has been fixed at the beginning of sept 2016. Now kindle is detected and ;un works fine, at least on my computer with a pw3. I'm using Microsoft Windows 10 Pro - OS Version: 10.0.14393 N/A Build 14393

No need to install additional drivers. It just works fine.