Is There A Hidden Backdoor In JMicron Chipset Drivers?

I am opening this up for discussion. Here's the scenerio.

I have a Gigabyte m/b with the JMB336X chipset. Sometime ago I had downloaded the latest Win 7 x64 drivers from the JMIcron site in Taiwan. Verified drivers were Microsoft certified.

After the latest WIN updates, restarted my PC to apply updates. Shortly thereafter checked my NIS 2013 firewall logs. Was surprised to see events in the log immediately after boot that a IE9 connection was established that I did not initiate. Immediately therafter was an outbound ftp connection by searchprotocolhost.exe to IP address 211.75.121.162. That IP is registered to JMicron in Taiwan. I was "floored" to see that NIS actually blocked the 6 connection attempts.

I have researched this and can find no reason why searchprotocolhost.exe should be dialing out via ftp. I changed the firewall rule NIS created to restrict searchprotocolhost.exe to my local subnet. I also added a rule to block any other traffic from it. Have seen no further entries in the firewall log since related to searchprotocolhost.exe.

Anyone have the slightest idea what the ftp connection via searchprotocolhost.exe was about? I am at this point inclined to strongly beleive this connection was initiated by the SMB33X controller driver.

 

JMB336X or JMB36X? I have a JMB36X but cannot find any trace of such activity on my machine. Running driver 1.17.65.11.

 

Yes, that was a type. Should be JMB36X. My version is 1.17.63.1. JMicrom created 1.17.65.1 for WIN 8 support.

I did notice something a bit strange about the JRAID.sys driver. See screen shot. I don't know why 18 references of that registry key exist in the driver details.

 

The Stuxnet rootkit & JMicron are no strangers to each other !

I'm NOT saying that the company themselves were knowingly were involved, but it "seems" likely that @ least someone on the inside was. With that in mind, it's not a far stretch to envisage that same person, and/or someone else, doing other dodgy things there ! Of course this doesn't mean that your driver/s are compromised, or any other software etc of theirs.

Why don't you upload them to Various multiple scanning www's & upload them to http://www.kernelmode.info/forum/viewforum.php?f=16&sid=a919b4b496d2767f7ba35dc3bc1ccb14 for their expert analysis.

 

I did upload JRAID.sys to Virustotal and it came back 100% clean.

The cert. looks good to me. It's countersigned by Verisign whereas the hacked? one on the F-Secure web site was not countersigned.

WebRoot has a very interesting read on JRAID.sys. Although they rate it as under eval., the behavior observed is enough to scare the hell out of you

 

http://www.kernelmode.info/forum/vie...a35dc3bc1ccb14

This site had a few interesting refs. to Stuxnet and stolen JMicron and Realtec certs. Interestingly appears JMicron and Realtec reside in the same office space. Kapersky stated that they had found no evidence that JMicron drivers have been hacked due to the above.

But this brings another issue. I did in the past directly download a NIC driver from Realtec. As I recollect that driver install was a bit flakey but the driver works great. I will check out that driver.

 

Might be more here than meets the eye.

Booted PC today and JRAID.sys hung up the PC. What I didn't mention previously is this has periodically happened in the past. I had attributed it to the fact I have two optical drives; one SATA and one IDE. I had seen previous complaints that there have been issues about IDE drives using the JMicron controller.

Well today the hang took down my network connection. A reboot as usual resolved everything. But I have had it so I downloaded the most recent LAN and GSata drivers from the Gigabyte web site and installed those. The GSata driver appears be the same as that I had installed from the JMicron site; ver. is the same, etc.

Would be interesting to know if the WIN 7 MS ACHI driver will work with the JMicron eSata controller?

 

I don't think that driver even recognizes the controller. My controller does not even show as a recognized device until I load the JMicron driver. I am not a huge fan but I don't get to pick what the manufacturers use.

 

After further testing with the JMicron drivers, I saw other things I did not like so I uninstalled them.

Win 7 will just install its default drivers. For the GSata ports, it will just install the JMicron PATA driver which btw is signed. This driver interfaces with the MS IDE driver and handles my PATA and SATA optical drives fine.

For the JMicron eSata ports, WIN 7 will install its msahci driver which will allow for hot-plugging, etc.

All the above show under IDE Controllers in device manager. There will not be a separate JMB36X Controller entry in device manager

 

I'd like to note asus sabertooth x58 has a different jmicron controller but I have 0 proof of bad just gut and it ties into the "gpu para" stuff (which is how I found the forum)

Realizing I haven't read the Rules here I will do that now and apologize if I derailed thread.