Hello All,
I was curious to know if USB devices can have their own drivers embedded so that when they plug into any OS on any platform they can pass on the drivers to the system.
Sometime on Thursday 14 Jun 2007, Rony said:
Hello All,
I was curious to know if USB devices can have their own drivers embedded so that when they plug into any OS on any platform they can pass on the drivers to the system.
Isnt this a chicken and egg situation? How will the OS read the drivers stored in the unknown USB device if it doesnt know how to read the device?
Anurag
Anurag wrote:
Sometime on Thursday 14 Jun 2007, Rony said:
I was curious to know if USB devices can have their own drivers embedded so that when they plug into any OS on any platform they can pass on the drivers to the system.
Isnt this a chicken and egg situation? How will the OS read the drivers stored in the unknown USB device if it doesnt know how to read the device?
You could theoretically store the drivers on a generic storage area which can be read by all OSes supporting USB thumb drives. You would then develop a protocol to read the drivers and install them to access the rest of the device.
Drivers would then have to be stored for every operating system, which means the vendor will then have to support every OS...
In which case, you could just download the drivers from the vendor's website just as easily.
-- Anant
Anurag wrote:
Sometime on Thursday 14 Jun 2007, Rony said:
Hello All,
I was curious to know if USB devices can have their own drivers embedded so that when they plug into any OS on any platform they can pass on the drivers to the system.
Isnt this a chicken and egg situation? How will the OS read the drivers stored in the unknown USB device if it doesnt know how to read the device?
A universal multi-platform utility could be created to read such embedded drivers. The utility needs to be installed only once.
Hi,
Isnt this a chicken and egg situation? How will the OS read the drivers stored in the unknown USB device if it doesnt know how to read the device?
The idea/assumption is to have USB Mass storage support enabled by default on the host platform.
So, when the device is plugged in, the USB Mass storage is detected, and some application on the host platform copies the drivers from the device and installs it.
With loadable driver modules, it is quite possible with GNU/Linux.
SK
-- Shakthi Kannan http://www.shakthimaan.com
____________________________________________________________________________________ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/
On 6/15/07, Rony ronbillypop@yahoo.co.uk wrote:
A universal multi-platform utility could be created to read such embedded drivers. The utility needs to be installed only once.
Wouldn't it be more feasible to standardize on a USB file system format than to go about trying to create a utility and then expect manufacturers to standardize on that?
Siddhesh Poyarekar wrote:
On 6/15/07, Rony ronbillypop@yahoo.co.uk wrote:
A universal multi-platform utility could be created to read such embedded drivers. The utility needs to be installed only once.
Wouldn't it be more feasible to standardize on a USB file system format than to go about trying to create a utility and then expect manufacturers to standardize on that?
What is the significance of the file system? The interface should work with any usb ported device, not just pen drives. Cameras, IR, bluetooth, printer, scanner, multi-function, modem etc. USB is quite a popular format for many devices. Universal plug and play utilities dedicated to the individual OSes could make driver writing universal too. The hard part will be to develop the interfaces for each OS, but once that is done, making common drivers will not be a problem for the manufacturers.
On 6/16/07, Rony ronbillypop@yahoo.co.uk wrote:
Siddhesh Poyarekar wrote:
I have a self-loading USB driver. It is called Resik.A, and has made a home for itself in my XP laptop, my USB pen drive, and my linux smartphone's memory card. It loads through XP's exciting Autoplay functionality, resides in a /Recycled folder, and uses two files: driveinfo.exe and voinfo.dll.
I got infected when I used somebody's unscanned drive (or was it an ipod?). XP charmingly told me that my new software had been installed and would be loaded when I restart the machine.
So much for auto-loading software.
Nishit Dave wrote:
I got infected when I used somebody's unscanned drive (or was it an ipod?). XP charmingly told me that my new software had been installed and would be loaded when I restart the machine.
So much for auto-loading software.
Did you complain to M$ about it?
On Saturday 16 June 2007 16:36, Rony wrote:
Nishit Dave wrote:
I got infected when I used somebody's unscanned drive (or was it an ipod?). XP charmingly told me that my new software had been installed and would be loaded when I restart the machine.
So much for auto-loading software.
Did you complain to M$ about it?
Self loading anything is a big security hole. Even if it is restricted to userspace. A device driver on most of today's os loads into kernel space and could freak out on your machine. We have enough problems from userland on some of the crap that label themselves os without the added joy of autoloading various crap suitably trojaned. It is a daft suggestion.
jtd wrote:
On Saturday 16 June 2007 16:36, Rony wrote:
Nishit Dave wrote:
I got infected when I used somebody's unscanned drive (or was it an ipod?). XP charmingly told me that my new software had been installed and would be loaded when I restart the machine.
So much for auto-loading software.
Did you complain to M$ about it?
Self loading anything is a big security hole. Even if it is restricted to userspace. A device driver on most of today's os loads into kernel space and could freak out on your machine.
Even in Linux?
On 6/17/07, Rony ronbillypop@yahoo.co.uk wrote:
Even in Linux?
Yes. Since a driver loads into kernel space means that it has rights to do anything. This is alright for drivers you have the sources for and trust, since you (or many others, if you're not tech literate) have seen the code. But in case of drivers for any random chinese USB drive, mp3 player, etc, loading the binary blindly is like keeping your doors open for everybody.
Siddhesh Poyarekar wrote:
On 6/17/07, Rony ronbillypop@yahoo.co.uk wrote:
Even in Linux?
Yes. Since a driver loads into kernel space means that it has rights to do anything. This is alright for drivers you have the sources for and trust, since you (or many others, if you're not tech literate) have seen the code. But in case of drivers for any random chinese USB drive, mp3 player, etc, loading the binary blindly is like keeping your doors open for everybody.
Wouldn't the same risk be possible through driver CDs?
On 6/17/07, Rony ronbillypop@yahoo.co.uk wrote:
Wouldn't the same risk be possible through driver CDs?
Yes, but it's a bit more difficult to get it this way. It's sort of like the difference between using a root account regularly and using sudo when required.
For devices that require drivers off a CD, you need to trust the device manufacturer or better, have access to the code. For others, the driver is in the OS distribution (be it Windows, Linux or anything else) and since you trust the OS to do all your work, you ought to trust the drivers they provide as well.
With auto-loading USB devices, you do not know what the USB device has loaded onto your system since that process is completely transparent.
Siddhesh Poyarekar wrote:
On 6/17/07, Rony ronbillypop@yahoo.co.uk wrote:
Wouldn't the same risk be possible through driver CDs?
Yes, but it's a bit more difficult to get it this way. It's sort of like the difference between using a root account regularly and using sudo when required.
Even CD based driver installation will require admin privileges.
For devices that require drivers off a CD, you need to trust the device manufacturer or better, have access to the code. For others, the driver is in the OS distribution (be it Windows, Linux or anything else) and since you trust the OS to do all your work, you ought to trust the drivers they provide as well.
With auto-loading USB devices, you do not know what the USB device has loaded onto your system since that process is completely transparent.
Since the user is logged in as 'user', anyway the OS would ask for root privileges to load the auto-loading drivers. That security part if not existing today, can be added in the interpretors that are created for each OS and installed once.
On 6/17/07, Rony ronbillypop@yahoo.co.uk wrote:
Since the user is logged in as 'user', anyway the OS would ask for root privileges to load the auto-loading drivers. That security part if not existing today, can be added in the interpretors that are created for each OS and installed once.
True. But visualize the scenario in both cases:
For self-loading USB: You plug in the device and you get a message "Please enter your root password so that I can install the drivers for this device". That device could be your new MP3 player or your camera. Then again it could also be your friends USB memory stick that may have dirtied itself somewhere and is actually asking you for root password to get its dirt on you rather than just the driver. You will not know the difference.
A corollary to the above -- A virus is loaded into this friends USB memory stick that asks for root password every time the device is plugged in. The user will assume that the device wasn't installed 'properly' and hence unwittingly give away his password.
For the regular process: The driver installation takes place from a trusted media -- the manufacturers CD or from the OS's repository. So while installing the driver you get asked for your root password. The process of installing an external driver is hence distinctly different from the way in which the device would be used regularly. This more or less eliminates (or at least, makes difficult) another infection route.
Siddhesh Poyarekar wrote:
For self-loading USB: You plug in the device and you get a message "Please enter your root password so that I can install the drivers for this device". That device could be your new MP3 player or your camera. Then again it could also be your friends USB memory stick that may have dirtied itself somewhere and is actually asking you for root password to get its dirt on you rather than just the driver. You will not know the difference.
The problem can be eliminated by storing the drivers on ROM. Now, if you trust the manufacturer of the device, you can trust the drivers - the same scenario as divers on a CD.
-- Anant
On 6/17/07, Anant Narayanan anant@kix.in wrote:
The problem can be eliminated by storing the drivers on ROM. Now, if you trust the manufacturer of the device, you can trust the drivers - the same scenario as divers on a CD.
It isn't. Again, it doesn't clearly distinguish between a driver installation activity and any other activity. My second scenario would still hold -- an on-device virus could still fake a driver installation routine and get in. The user wouldn't have a clue.
Siddhesh Poyarekar wrote:
It isn't. Again, it doesn't clearly distinguish between a driver installation activity and any other activity. My second scenario would still hold -- an on-device virus could still fake a driver installation routine and get in. The user wouldn't have a clue.
...which is no different than a driver CD faking a trojan install. You could easily develop a protocol to instruct the OS to only listen to what the program on the ROM says, probably with a checksum to verify its integrity.
The bottom-line is that you have to trust the manufacturer of your product.
-- Anant
On 6/18/07, Anant Narayanan anant@kix.in wrote:
...which is no different than a driver CD faking a trojan install. You could easily develop a protocol to instruct the OS to only listen to what the program on the ROM says, probably with a checksum to verify its integrity.
You're spot on in case of a new device you'll install. Consider a situation where you're using a device for which you already have a driver installed, has been used elsewhere and has been infected. The device is plugged in and the user gets a pop-up saying that it needs to install the driver for the device to work. The user will simply assume that the driver somehow got corrupt and will gladly put in the password to get the pop-up off his face.
In case of drivers separate on CD, the driver installation procedure is completely different from normal usage procedure, hence it is difficult (impossible?) to mix the two. Also, if you have a trojan'ed CD then you've not used the original manufacturers CD.
The bottom-line is that you have to trust the manufacturer of your product.
Best, use a Free (mukt) driver or device that uses a mukt driver.
Siddhesh Poyarekar wrote:
You're spot on in case of a new device you'll install. Consider a situation where you're using a device for which you already have a driver installed, has been used elsewhere and has been infected. The device is plugged in and the user gets a pop-up saying that it needs to install the driver for the device to work. The user will simply assume that the driver somehow got corrupt and will gladly put in the password to get the pop-up off his face.
A valid argument. Perhaps why the idea hasn't been implemented.
-- Anant
On Monday 18 June 2007 00:34, Siddhesh Poyarekar wrote:
On 6/18/07, Anant Narayanan anant@kix.in wrote:
...which is no different than a driver CD faking a trojan install. You could easily develop a protocol to instruct the OS to only listen to what the program on the ROM says, probably with a checksum to verify its integrity.
You're spot on in case of a new device you'll install. Consider a situation where you're using a device for which you already have a driver installed, has been used elsewhere and has been infected.
Or the original autoloaded driver needs a vital bug fix - which imo is the norm.
On Sunday 17 June 2007 22:58, Anant Narayanan wrote:
Siddhesh Poyarekar wrote:
For self-loading USB: You plug in the device and you get a message "Please enter your root password so that I can install the drivers for this device". That device could be your new MP3 player or your camera. Then again it could also be your friends USB memory stick that may have dirtied itself somewhere and is actually asking you for root password to get its dirt on you rather than just the driver. You will not know the difference.
The problem can be eliminated by storing the drivers on ROM. Now, if you trust the manufacturer of the device, you can trust the drivers - the same scenario as divers on a CD.
It is not the storage medium but the ability to autoload which is the problem. The other risks noted in this thread are common to all os's and / or the medium used for delivering content with a device driver being a specially dangerous case. Trusting anyone without an open review process is a strict no no. Further the act of verification has to be manual because an automated process has exactly the same set of vulnerabilities that the verification is trying to mitigate. Which defeats the purpose of automated driver loading. Complex methods have evolved for such verification certs being one such.
jtd wrote:
It is not the storage medium but the ability to autoload which is the problem. The other risks noted in this thread are common to all os's and / or the medium used for delivering content with a device driver being a specially dangerous case. Trusting anyone without an open review process is a strict no no. Further the act of verification has to be manual because an automated process has exactly the same set of vulnerabilities that the verification is trying to mitigate. Which defeats the purpose of automated driver loading. Complex methods have evolved for such verification certs being one such.
OK. So auto-loading USB drivers is a risk. Idea canceled. :)
Sometime on Saturday 16 Jun 2007, Rony said:
Nishit Dave wrote:
I got infected when I used somebody's unscanned drive (or was it an ipod?). XP charmingly told me that my new software had been installed and would be loaded when I restart the machine.
So much for auto-loading software.
Did you complain to M$ about it?
I thought he was being sarcastic in his reply :P
Anurag
Anurag wrote:
Sometime on Saturday 16 Jun 2007, Rony said:
Nishit Dave wrote:
I got infected when I used somebody's unscanned drive (or was it an ipod?). XP charmingly told me that my new software had been installed and would be loaded when I restart the machine.
So much for auto-loading software.
Did you complain to M$ about it?
I thought he was being sarcastic in his reply :P
I know. No one actually complains to M$. But viruses are a way of life in doze. ;)
On 6/16/07, Rony ronbillypop@yahoo.co.uk wrote:
I know. No one actually complains to M$. But viruses are a way of life in doze. ;)
Out of curiosity: Do you get a useful response if you complain? Assuming of course, that you are using a non-pirated copy of MSW. Or do you have to pay up extra?
Regards, Mohan S N
Mohan Nayaka wrote:
On 6/16/07, Rony ronbillypop@yahoo.co.uk wrote:
I know. No one actually complains to M$. But viruses are a way of life in doze. ;)
Out of curiosity: Do you get a useful response if you complain? Assuming of course, that you are using a non-pirated copy of MSW. Or do you have to pay up extra?
I had once called up M$'s toll free helpline in Mumbai (All India) to inquire about a client's free Vista upgrade coupon that came with his XP pro that I had provided. They are polite and take time to explain various licenses and their limitations and are not too concerned with OEM or Full pack as long as you use an original copy. They record everything that has transacted between the CC operator and the caller and announce this before the call is answered.
I use XP pro legal in my system. As a precaution, my system is loaded with anti-viirus, firewall, anti-spyware and is regularly kept up to date with security updates from M$. I don't chat or orkut. However since 3 years this OS is used only for devices that don't work in Linux.
On Sunday 17 June 2007 00:19, Rony wrote:
Anurag wrote:
Sometime on Saturday 16 Jun 2007, Rony said:
Nishit Dave wrote:
I got infected when I used somebody's unscanned drive (or was it an ipod?). XP charmingly told me that my new software had been installed and would be loaded when I restart the machine.
So much for auto-loading software.
Did you complain to M$ about it?
I thought he was being sarcastic in his reply :P
I know. No one actually complains to M$. But viruses are a way of life in doze. ;)
since the day billy baba decided jumping to the middle of an opcode was great programming practice. On a less sarcastic note, the M$ business model dictates backward compatability. The problems in doze are because of design. Any change would mean revamping the entire codebase and destroying backward compatability and most likely the company. They have painted themseleves into the corner of a deep well. So much for the much touted business abilities of the company.
On Monday 18 Jun 2007 10:40:20 jtd wrote:
On a less sarcastic note, the M$ business model dictates backward compatability. The problems in doze are because of design. Any change would mean revamping the entire codebase and destroying backward compatability and most likely the company. They have painted themseleves into the corner of a deep well. So much for the much touted business abilities of the company.
What has all this got to do with the email to which this is a reply?
On Monday 18 June 2007 11:09, Mrugesh Karnik wrote:
On Monday 18 Jun 2007 10:40:20 jtd wrote:
On a less sarcastic note, the M$ business model dictates backward compatability. The problems in doze are because of design. Any change would mean revamping the entire codebase and destroying backward compatability and most likely the company. They have painted themseleves into the corner of a deep well. So much for the much touted business abilities of the company.
What has all this got to do with the email to which this is a reply?
Sigh... the root of the reason why complaining wont help and why it's a way of life in the doze world... because the big boss had a deeply flawed technical "vision" and forced the rest of his team down the years onto a path that can never be corrected.
On Monday 18 Jun 2007 11:37:37 jtd wrote:
On Monday 18 June 2007 11:09, Mrugesh Karnik wrote:
On Monday 18 Jun 2007 10:40:20 jtd wrote:
On a less sarcastic note, the M$ business model dictates backward compatability. The problems in doze are because of design. Any change would mean revamping the entire codebase and destroying backward compatability and most likely the company. They have painted themseleves into the corner of a deep well. So much for the much touted business abilities of the company.
What has all this got to do with the email to which this is a reply?
Sigh... the root of the reason why complaining wont help and why it's a way of life in the doze world... because the big boss had a deeply flawed technical "vision" and forced the rest of his team down the years onto a path that can never be corrected.
I think the only people with a genuine right to make these comments are Microsoft employees.
On Monday 18 June 2007 11:48, Mrugesh Karnik wrote:
On Monday 18 Jun 2007 11:37:37 jtd wrote:
On Monday 18 June 2007 11:09, Mrugesh Karnik wrote:
On Monday 18 Jun 2007 10:40:20 jtd wrote:
On a less sarcastic note, the M$ business model dictates backward compatability. The problems in doze are because of design. Any change would mean revamping the entire codebase and destroying backward compatability and most likely the company. They have painted themseleves into the corner of a deep well. So much for the much touted business abilities of the company.
What has all this got to do with the email to which this is a reply?
Sigh... the root of the reason why complaining wont help and why it's a way of life in the doze world... because the big boss had a deeply flawed technical "vision" and forced the rest of his team down the years onto a path that can never be corrected.
I think the only people with a genuine right to make these comments are Microsoft employees.
Wish granted. His tech foibles have been well publicised by his employess / partners but under the guise of tech master strokes.
Rony wrote:
What is the significance of the file system? The interface should work with any usb ported device, not just pen drives. Cameras, IR, bluetooth, printer, scanner, multi-function, modem etc. USB is quite a popular format for many devices. Universal plug and play utilities dedicated to the individual OSes could make driver writing universal too. The hard part will be to develop the interfaces for each OS, but once that is done, making common drivers will not be a problem for the manufacturers.
How would the OS to read the drivers from the storage area of the USB device if it doesn't know what filesystem it is formatted in?
-- Anant
Anant Narayanan wrote:
Rony wrote:
What is the significance of the file system? The interface should work with any usb ported device, not just pen drives.
How would the OS to read the drivers from the storage area of the USB device if it doesn't know what filesystem it is formatted in?
Hmm.
Sometime on Jun 17, Anant Narayanan assembled some asciibets to say:
How would the OS to read the drivers from the storage area of the USB device if it doesn't know what filesystem it is formatted in?
Anyone can tell what filesystem it is formatted in - just look at the file system id. How to read the filesystem though is a different matter.
Philip Tellis wrote:
How would the OS to read the drivers from the storage area of the USB device if it doesn't know what filesystem it is formatted in?
Anyone can tell what filesystem it is formatted in - just look at the file system id. How to read the filesystem though is a different matter.
Indeed. By "know", I meant the knowledge of how to read a filesystem. Thanks for the clarification.
-- Anant
I was curious to know if USB devices can have their own drivers embedded so that when they plug into any OS on any platform they can pass on the drivers to the system.
Yes, technically possible. The default behavior of USB device will be mass storage device. The PC will read and install the driver. Once PC runs the driver, the USB device will activate its native function. No, Commercially it will add up cost and nothing else. If all the driver can be given on Rs. 5 CD, why add MSD and increase cost of USB device.
Warm Regards,
Mukund Deshmukh, Beta Computronics Pvt Ltd. 10/1 IT Park, Parsodi, Nagpur -440022 India. Web site - http://betacomp.com
-
Anant Narayanan -
Anurag -
jtd -
Mohan Nayaka -
Mrugesh Karnik -
Mukund Deshmukh -
Nishit Dave -
Philip Tellis -
Rony -
Shakthi Kannan -
Siddhesh Poyarekar