• State
  • Locked Locked
  • Replies 29 replies
  • Subscribers 82 subscribers
  • Views 12122 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Microcontroller : USB Peripheral in promiscuous mode in order to sniff USB data

Jorge Miguel
Expert 1020 points

Dear all,

I need to capture the USB traffic in a USB communication. I want to capture the traffic on the bus in high impedance so that I do not affect the communications between master and slave.

After that, I need some device (a microcontroller with a built-in USB) which listens to USB frames and decode them for me so that I get the payload of all USB traffic.

The problem is that the USB of the microcontroller will not be host/slave of any device since it will listen the signals in high impedance (with a high impedance differential amplifier). Thus I need that the USB can be configured in promiscuous mode. That means, listening everything and send it up to the driver.

Is that possible with some microcontroller of TI portfolio?

Many thanks in advance.

Regards,
Jorge.

  • 0
    Guru 33653 points
    There is free software tool for Windows (and I guess for other OS's too) that will log all transferred USB packets, so I don't understand why you need to have this as dedicated hardware device, when it is already covered by OS software.
  • 0 in reply to zrno soli
    Expert 1020 points
    Hi,

    Thanks for the tip but I need to monitor and record a USB communication between two devices without affecting the communication.

    That means I need a USB peripheral that listens all USB traffic and captures it.
    Is it possible to operate the USB of any TI USB microcontroller this way? Anyone?

    Regards,
  • 0 in reply to Jorge Miguel
    Guru 33653 points

    For analyzing USB transfer between PC and USB device can be used software on PC side. If it is related to communication without PC than hardware tool can be used (I guess something like http://www.adafruit.com/products/708). MSP430 device are not fast enough for this task, or I am not aware of any native USB mode for enabling this.

  • 0 in reply to zrno soli
    Expert 1020 points
    Hi,

    Thanks for the answer. Unfortunately I do not have any access either the slave or the host PC so that I have no way of using a PC tool.

    I heard about Beagle product but I find it quite expensive and I would like to do it myself. I just need a USB access that reads all without transmitting.

    Regards,
    Jorge
  • 0 in reply to Jorge Miguel
    Guru 46710 points

    Which USB you want to analyze? 480 Mbps, 12 Mbps or 1.5 Mbps?
    I find your statement to build USB analyzer because 400$ instrument is too expensive, rather bold (to say it politely).

    There' s one you might find useful

  • 0 in reply to Ilmars
    Expert 1020 points
    Hello,

    Ok, for full-USB logic analyzer could be a fair price or even a cheap one. I don't argue that.
    However I just to capture some data from slave devices which could be a keyboard and I would need to know which keys have been pressed.

    For that purpose I cannot afford a 400$ device. All I need is a USB peripheral in receive-all configuration and then I would decode the raw data.

    I want to analyze 12Mbps USB bus.

    Many thanks for your feedback.
  • 0 in reply to Jorge Miguel
    Guru 46710 points

    Oh, I see - you are building spy tools :)

    I agree to what zrno said - there are no (known) microcontroller with USB peripheral allowing to intercept USB traffic. You possibly can build sniffer out of USB PHY like TUSB1210 and FPGA.

  • 0 in reply to Ilmars
    Expert 1020 points
    You call it spy tools I call it security tools :)

    It seems you have spotted it on. There are open CORES wich implement the whole USB standard in an FPGA. However for speed reasons an external USB PHY is required:

    opencores.org/project,usb

    Some implementations in commercial analyzers:

    www.summitsoftconsulting.com/UsbAnalyzers.htm

    It sounds doable, not easy though.
    Thanks !
  • 0 in reply to Jorge Miguel
    Guru 46710 points

    If your project is just about USB 1.1 HID receive, then you can do it in software.

  • 0
    Guru 227245 points
    The concept of the USB bus prevents this by design. Unlike a network hub, USB communication goes up or down in a straight line. Another device attached to an USB HUB won't see the traffic of the other, like a managed switch.
    To capture the traffic, you'll need to be in the data stream. So you must be the HUB. Or you play host for the device under test and mimic the device for the host.
    Of course you can simply attach as a logic analyzer to the D+ and D- lines, just making a D/A conversion of the signals and interpreting them. It will still require you to physically attach to the line between device and HUB/PC. And it requires a fast A/D converter and an even faster processor.
    That's why those USB analyzers aren't available for $10.
  • 0 in reply to Jens-Michael Gross
    Expert 1020 points

    Hi Jens,

    Thanks for your answer.

    It seems that the expensive logic analyzers do implement my suggested mode of operation.

    See images from here:  www.summitsoftconsulting.com/UsbAnalyzers.htm

    As you can see, they bypass USB in and USB out and then with a USB PHY they capture the data to be transferred to a SW analysis through an FPGA.

    So somehow they are able to listen in parallel all USB frames that are transmitted from host to slave and from slave to host.

    So I think there must be a way..... (besides your ADC option which could be a nightmare)

    Regards,

  • 0 in reply to Jorge Miguel
    Guru 46710 points
    Yes, you can use USB PHY to sniff USB bus signals. Problem is that microcontollers with USB peripheral (inside) have not only PHY but also USB controller (otherwise known as MAC). Most microcontrollers /w USB I am aware of, do not allow to use/access USB PHY directly, nor have promiscuous mode of controller you are looking for.
  • 0 in reply to Ilmars
    Expert 1020 points

    Hi Ilmars,

    That is why I am considering using just a USB PHY which takes the serial data and gives the ULPI parallel data to a microcontroller/FPGA. Then I need to capture all ULPI data and parse it in order to get the real information of the frames (that means discarding token frames, handshake frames, etc..)

    My concern is about how to connect my USB PHY in order not to disturb the electrical characteristics of the bus.

    Any idea? Just direct parallel connection? with differential amplifiers in between?

    Many thanks for your answer,

    Jorge 

  • 0 in reply to Jorge Miguel
    Guru 46710 points
    Not a good idea to use PHY with microcontroller chip having no external bus as msp430 do. No wonder they use FPGA.
    Before going "PHY way" consider to use "pure software sampling approach": www.obdev.at/.../index.html
    As most keyboards are low speed peripherals, this could work. I would not bother to port it to msp430, use original chip instead. Thou I would add differential->cmos buffer for better bus impedance matching and better signal integrity.
  • 0 in reply to Ilmars
    Expert 1020 points
    Hi Ilmars,

    I meant to use a USB PHY and then capture the ULPI parallel data with GPIOS for the 8 data lines and an interrupt to the clock line. I would not use the USB peripheral of the microcontroller. (Sorry if I wasn't clear enough).

    "Before going "PHY way" consider to use "pure software sampling approach""
    By using a PHY I do not have to worry about USB encapsulation. I think a 100% software solution would be even more difficult. However if the solution from ATMEL is open SW and I can use most of the code in order to implement my USB driver (which would just read every frame without writing) could be a good starting point.

    As I understand it both options are very similar. The first one takes parallel data as input and the second one takes serial data as input which would require more CPU speed in order to process the information (although with LS devices such as keyboard or mouse could be feasible). Am I right?

    "I would add differential->cmos buffer for better bus impedance matching and better signal integrity"
    I guess that will prevent affecting the electrical characteristics of the bus,.
    However would the USB PHY (or the SW solution) be able to receive the data? I mean, from the buffers, would it be able to pull-up or pull-down the bus as required by the host in order to have different logic levels on the bus so that a '1' or a '0' can be transmitted from the buffers to the PHY / SW solution?

    Thanks for your comments,
    Jorge.
  • 0 in reply to Jorge Miguel
    Guru 46710 points

    >However if the solution from ATMEL is open SW and I can use most of the code in order to implement my USB driver
    Take it or leave it :) You shall check it yourself to see what is good for _you_ and what's not.

    >As I understand it both options are very similar.
    Software solution is seemingly harder way, however it's ready and working. You just need to tweak receive part and throw out transmit part. ULPI have it's drawbacks: 1) it's extra chip 2) high speed interface! Not every uC can handle such using CPU-assisted GPIO access.

    >I guess that will prevent affecting the electrical characteristics of the bus
    Yes, that's the main purpose. Of course PHY have differential buffer in it, you just shall ensure that it never switches on it's transmitter part.

  • 0 in reply to Ilmars
    Expert 1020 points
    Ilmars,

    Of course I will check whether or not the SW solution you mentioned is useful for me and I thank you for the tip.

    For the SW implementation: are all keyboards / mice ALWAYS Low speed? That is something I cannot find..

    For the extra PHY solution: Yes you are right, extra hardware and the ability to read from a 60MHz interface. I wonder how fast a microcontroller must be in order to capture data from that interface....at least twice?

    It would be nice to find a USB PHY with another interface different from ULPI (just for low and full speed) but unfortunately I cannot find it. Does is exits or all of them are ULPI/UTMI (30MHz) ?

    >>I guess that will prevent affecting the electrical characteristics of the bus
    >Yes, that's the main purpose. Of course PHY have differential buffer in it, you just shall ensure that it never switches on its transmitter part.
    I am confused. Do the built-in PHY differential buffers do the job or do I have to connect extra buffers between the USB bus to be listened and the PHY ?

    Many thanks for your help,
    Jorge
  • 0 in reply to Jorge Miguel
    Guru 46710 points

    > I wonder how fast a microcontroller must be
    You simply don't connect 60MHz peripherals using GPIO. Ever. You need external bus with DMA.

    >Do the built-in PHY differential buffers do the job
    Don't confuse, check. Did you read any of the PHY datasheets? There shall be reference designs too. Obviously PHY do not need any external differential buffers, they are built-in. In case you use AVR software solution - _then_ you would want to use buffer - to not load USB data pair with CMOS inputs, to avoid any potential impedance matching problems which could lead to USB data errors that in result causes debunking exposing of your "security device".

  • 0 in reply to Ilmars
    Expert 1020 points
    >Obviously PHY do not need any external differential buffers, they are built-in.
    Yes, I read PHY documentation and I know they have built-in buffers. However I wasn't sure if I would need external ones very close to the bus in order to avoid errors on it. Now it is clear to me that there is no need of that.

    >> I wonder how fast a microcontroller must be
    >You simply don't connect 60MHz peripherals using GPIO. Ever. You need external bus with DMA.
    Ok. I need to configure the DMA of the microcontroller to capture 8 signals each triggered by the 60MHz ULPI clock.
    I have no experience with DMAs. Is it feasible with a non-expensive microcontroller?
    Is it feasible to capture two ULPI interfaces with a single microcontroller if it has two DMA channels ?

    You are very helpul
    Many thanks,
  • 0 in reply to Jorge Miguel
    Guru 25210 points
    You are well out of the realm of anything that you are going to do with an MSP430 or probably any 16-bit microcontroller. And DMA or not, you're not going to be capturing 60MHz stuff using GPIO lines. You need a CPU with an external memory bus and put something between it and the ULPI that will buffer the data from the ULPI on one side and feed it to the CPU on the other as a memory interface. Then you let DMA get the data from the external memory into your high-speed processing path.

    I'm not sure what your experience level is, but my thought is that you are better served buying a piece of equipment to do this. It is not trivial.
  • 0 in reply to Jorge Miguel
    Guru 46710 points
    >Is it feasible to capture two ULPI interfaces with a single microcontroller if it has two DMA channels ?

    Why do you need TWO interfaces? DMA channels alone will not help, you need external bus too. Even in such case throughful investigation of PHY and uC bus signalling needed to be done. During investigation do not forget that ULPI bus is unusual, aimed to be connected to USB controller, not CPU. - PHY (not CPU/uC) decides when and which one will be bus master. Probably "glue" CPLD will be needed to couple USB PHY into "generic" bus of CPU/uC.

    To cut it short: if you want to use PHY for your sniffer then consider to drop microcontroller idea but use FPGA instead - as proper USB bus analyzers do, with all the price, complexity and size consequences.
  • 0 in reply to Brian Boorman
    Expert 1020 points
    Ok, you suggest to use an FPGA and external memory in order to capture the 60MHz signal.

    Thanks for your suggestion about dropping my design idea because I do not have it clear but if I were sure about how to do it I would not be asking here.

    Thanks,
  • 0 in reply to Ilmars
    Expert 1020 points
    Hi Ilmars,

    I need two interfaces. One for keyboard and one for mouse. They could be connected to a hub and then I would only have one interface (the upstream to the CPU) but I just want to capture the signals as they are. That means host-keyboard and host-mouse so that is why I am considering to USB interfaces.

    I asked about reading from the PHY directly with a microcontoller since keyboard and mouse are low speed devices but no matter their speed the ULPI interface is going to give me 60MHz data so the low speed of my devices does not ease the design.

    However that low speed feature does ease the design by making possible the all-SW sollution.

    By the way I am not 100% sure if all keyboards and mice are low speed. Are they?

    So my options are:
    - Two all SW interfaces (feasible with one or two microcontrollers provided that USB is always low speed)
    - Two PHY interfaces with FPGA and external memory along with a microcontroller.
  • 0 in reply to Jorge Miguel
    Guru 46710 points

    Hi!
    >I need two interfaces. One for keyboard and one for mouse.
    Mouse?? What kind of useful information you are hoping to extract from mouse USB traffic? Just fact that user moves it?

    >Two all SW interfaces (feasible with one or two microcontrollers provided that USB is always low speed)
    Definitely you need single sniffer having signle uC per peripheral of interest.

  • 0 in reply to Brian Boorman
    Prodigy 40 points
    I'm considering doing something similar and have a few more questions. In my case I need to pick out USB data packets that are flying by (by basically looking for pre-determined data patterns) when I see them, I just need to pass the data through a CRC and grab 4 bytes of data (I'll throw away the data if the CRC fails). The result is stuffed into an A2D. I can't use the host processor that the packets are being sent to because the latency is way too long. So in this case would a ULPI and an FPGA work?

    Thanks,
    Rich
  • 0 in reply to Richard Gagliardo
    Prodigy 40 points
    Arrrggghhh. Hate it when I do that.

    ....result is stuffed into a D2A, not an A2D....
  • 0 in reply to Richard Gagliardo
    Guru 46710 points
    >So in this case would a ULPI and an FPGA work?
    Maybe. If you want to capture Low Speed USB (1.5Mbps), then perhaps you can do it using fast enough microcontroller . Anyway I am afraid that you are consulting wrong forum
  • 0 in reply to Richard Gagliardo
    Expert 1020 points

    Hi Richard,

    For USB 1.1 (1.5Mbps) a SW based detection can be implemented on a microcontroller. See:

    www.obdev.at/.../index.html

    For 12Mbps or 480Mbps I am afraid you must read it with a dedicated USB transceiver. ULPI USB PHY + FPGA would do the job.

    Regards,

  • 0 in reply to Ilmars
    Prodigy 40 points

    Thanks Ilmars. Yeah - I found this topic came the closest to what I needed. 

    Jorge - it's likely to be High Speed rather than Full Speed, so I think I'll need the ULPI + FPGA solution. I'll give that a shot anyway. Thanks for the response.

    Rich

**Attention** This is a public forum