USB-driver....

[Pyr0Mathic]

Lo,

Got the encryption working (for the most part), but now i got to the next part, the usb driver. Have been reading a lot about the usb protocol and the usb part in the intel doc, for chip-set PII4X, i do get it for the most part just dont get how i how can i enumerate usb-devices, or how can i send a msg/packet to a device.

This is my goal, to be able to Read/Write to a simple memory stick, but is there a basic instruction set for all simple memory stick's or do i need to write a driver for each? also dont have an usb-stick yet, so which one's are universal? since i know there is a standard for large mass storage device's, MSC-complianc (Mass Storage Class), do simple memory sticks also fall inside the Mass Storage Class.

i dont need more then USB 1.1, so 12Mbits. should be enough for my goal. also, Dont think that my board supports usb 2.0.

So mainly the question is, did any one already do this? or have any expirience whit this?

Regards.
PyroMathic

[Cjmovie]

Hi,
Most USB devices are compliant to one of a set of well-defined standards. There is the HID standard for things like mouses and keyboards. There is a removeable device standard as well. Sorry, I can't provide any links though.

[Candy]

You're going to have to make an UHCI or OHCI driver. Which you have depends on your mainboard. Since you have (or claim to have) a PIIX4 mainboard, that would be an Intel chipset that has UHCI. Via also uses UHCI, others use OHCI. The UHCI and OHCI devices are present on all systems, even on systems with only USB 2.0 ports. The ports can then be assigned to the EHCI (USB 2.0) controller on its request, but by default they're assigned to the 1.1 controller, so your driver should work without even changing anything.

USB is only a transport protocol. It tells you how to get bytes from A to B (literally) with a certain transport characteristic and at a certain speed. It doesn't tell you what those bytes should be or what the device is telling you.

For USB input devices, there's a pretty common standard called USB HID (Human Interface Devices or Human Input Devices) which encapsulates anything with buttons that just want to tell you they're pressed and directional sensors that want to tell you where they moved. This includes joysticks, remote controls, mice, other rodents, keyboards, special devices that indicate something similar and touch screens. You should read it. It mainly consists of two bits, one which tells the device to explain to you what it's like (description of buttons and how their state is entered into a later to follow stream of packets) and one which tells it to send you packets according to that definition. Using both, you can decode the input accordingly.

[Cody]

Well, actually memory device vendors can implement some private interfaces other than the standard interface used to convey information specific to this device. A private driver can know the details to use it.

One shinning example is Apple's Mac Os can know if a silver or black iPod is inserted into its USB port.

However, there is nothing you can do to prevent manufactures to implement some security property. You have to understand the private interface and pass in some security data before you can start using the standard interfaces.
I am not sure if there is any vendor who really did it this way but it is quite possible from pure technical sense.

If talking about plain memory sticks, AFAIK, some manufacturers such as SONY design their memory stick to use special physical connector/wire so you cannot interchange with sticks from other vendors.

[Kemp]

I'll ignore for the moment that Sony called their flash cards "memory sticks" despite them not being even vaguely related to what everyone else calls that and despite them not even being a stick... ::)

Anywho, I've seen some sticks that have a public "partition" and a private one that only their special drivers can access when supplied with the appropriate password, so this sort of thing is definately possible. However, you'll find virtually every device of this type implements the standard to some extent, at least to the point of being able to say "there are no files here, move along".

[Pyr0Mathic]

Well i bought a memory stick, 512MB Kinston Traveler, so now just try to get the UHCI working. Am currently looking inside linux to find some clues on how to start sending message's/packets to the device's or how to enumbrate the device's on the usb-bus, so basecly how to start

And then hopefully ill be able to implement a driver for the usb-stick itself.

thx, for the replies

Also just curious, but in an other thread i read that usb-device's can read the RAM, but some how i cant find a way how they should be able to do that directly, since the usb-device is connected to the usb-pci device (the Root-hub.. i think), which is able to read whatever he wants from the RAM, since its a simple pci-device. but the device's which are attachted to the usb-bus, so usb-stick/key-board, should only be able to read the data i send them. i is in this case is the kernel driver.
Or am i missing something here?

Regards
PyroMathic

[NoItAll]

If you want a simple way to read/write usb keyfobs, you can do this by first, making sure you are able to boot from usb device, then by using int 13h function from pmode (eg: by going to and from pmode to real mode) you can read/write as if you are read/writing to a floppy disk.
It work great, but 1. it slow (slower than if you were read from a floppy, 2. your need to implement fat16 not fat12, unless you have a very big or small key fob.
If you still Dev you own this may help http://people.freenet.de/dieterp/
you need the usb4dos

[Candy]

It work great, but 1. it slow (slower than if you were read from a floppy, 2. your need to implement fat16 not fat12, unless you have a very big or small key fob.
If you still Dev you own this may help http://people.freenet.de/dieterp/
you need the usb4dos

Not all USB keys need to use FAT, in fact, you can use anything you like. Common USB keys are pre-formatted with FAT so that a non-computerish user can use it. You can just mkfs them, convert them to NTFS in windows or do whatever you like - even partition and use multiple types.

[Pyr0Mathic]

thx, the link seems to be promesing, and a lot better to read then C of the linux files... just dont know yet if ill support any fat, or if ill just dump the raw data on the device, using my own file-system.

Regards
PyroMathic

[Cody]

Also just curious, but in an other thread i read that usb-device's can read the RAM, but some how i cant find a way how they should be able to do that directly, since the usb-device is connected to the usb-pci device (the Root-hub.. i think), which is able to read whatever he wants from the RAM, since its a simple pci-device. but the device's which are attachted to the usb-bus, so usb-stick/key-board, should only be able to read the data i send them. i is in this case is the kernel driver.
Or am i missing something here?

Well, I don't really think a USB device can read from RAM directly. First, it cannot because it hasn't any bus interface installed. Second, if you mean USB Host controll such as UHCI and EHCI, yes, they can but they cannot do it on devices' behavles. According to USB spec, it's the host that is taking control of everything, you prepare you command to be either read or write to the device and send them to the host controller. The host controller will communicate with the device to push and pull date in every time frame.

The host controller, on the other hand, need to access physical rams. Some of these ram (must be physically continuous), are used to story data and command. But all of these goes on automatically. You won't need to direct them to read or write explicitly.

Hope this helps.

Best regards,
Cody