Re: [pyusb-users] Reverse Engineering an evaluation board

[Shailendra Paliwal]

On Sat, Feb 24, 2018 at 8:50 AM, Xiaofan Chen  wrote:

> On Sat, Dec 23, 2017 at 3:43 PM, Shailendra Paliwal
>  wrote:
> > Hello,
> >
> > I'm trying to communicate with an Analog Devices evaluation board
> (SDP-H1).
> > AD has a windows software that initializes the board and can be used to
> read
> > the data coming from the USB connection with the board.
> >
> > I have been trying to write something in pyusb that can do the same and
> work
> > with my Raspberry Pi. So far, I have figured out how to initialize the
> > board. I need help in understanding the protocol used in fetching data
> from
> > it.
> >
> > Device Descriptor: http://shailendra.me/USB.html
>
> Page not available.
>
Thanks, I have managed to make a USB driver that works nicely so far.
Coincidentally I took down that page *only* a few hours ago of your email!
Here's a copy of the page from an older commit, link



>
> > Here is the PCAP file of the USB trace:
> > https://github.com/vcidst/vcidst.github.io/blob/master/
> sdph1-data_clean.pcap
> > (you can use wireshark to open pcap files)
>
This link has been removed too.


> >
> > I've read a lot of write-ups of people reverse engineering USB protocols
> > which mostly include looking at the control transfers. However, this
> device
> > only has two bulk endpoints and all the communication is done with bulk
> > transfers.
> >
> > Quick facts about the PCAP file:
> > * Replaying packets 1-108 initialize the board.
> > * At packet 109 (use filter frame.time_relative >= 40), In the windows
> > software I chose sample size 1048576 and press Continuous Capture button.
> > * Packets 109 to 119 prepare the capture from SDP-H1.
> > * From packet 120, 6 packets of similar structure are sent/received again
> > and again.
> > * After that, I see 6 packets of different structure at
> (frame.time_relative
> >>= 41.059593)
> > * Packets after (frame.time_relative >=41.073968) are of different
> structure
> > again until the end.
> > * Towards the end, I stop the capture from the windows software thus the
> > last few packets should be stop packets .
> >
> > My questions now are,
> > 1. Is this device following any standard USB protocol format that I am
> not
> > familiar with?
>
> Most likely it uses vendor specific protocols not falling into standard
> USB device class definitions.
>
> > 2. I'm currently replaying the packets to initialize the device, is
> there a
> > better way to do this?
>
> If you do not know the protocol, this seems to be the only way.
>
> > 3. (a basic question that I still don't understand) in USB Communication,
> > after I have sent Bulk Write request. Do I need to send a bulk read
> request
> > if I need to read some data? Can the program just not read whatever the
> > device sends without me sending the device anything?
>
> No. USB does not work that way. The device does not automatically send
> data to the host without host initiate the communication.
>
> > 4. The data packets here are huge and I was wondering if I need to send
> the
> > entire packets whenever sending a bulk write request. Is there a way I
> can
> > figure out what is essential information in the packet and what is not?
>
> If you do not know the protocol, I do not think you have a way to know
> what is essential and what is not. You have to look into the huge data
> and then try to understand. All in all the efforts required may be huge.
>
> > (I have read the Bulk Transfer section from USB in a Nutshell but still
> > didn't understand why it has to be this way unlike say, RS232
> communication
> > where the device can keep on sending data in continuous mode)
>
> USB is much more complicated than serial communication.
>
> On the other hand, there is probably an easier way out without using
> the SDP-H1 if your interests are to connect your Raspberry Pi to a
> paticular
> daughter board. Quite some of them using SPI protocol. The schematics
> and documentations of the daughter boards are available.
>

I considered that option but the daughter board made the results available
on a single low voltage differential signaling self clocked interface. The
data rate required is as much as ~20 MBPS so I worked directly with their
evaluation kit first.

Thanks for your inputs. I think I will write a blog post soon detailing my
process and the tools I made use of.


>
>
>
> --
> Xiaofan
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> pyusb-users mailing list
> pyusb-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>
--
Check out the vibrant tech communit

Re: [pyusb-users] Reverse Engineering an evaluation board

[Xiaofan Chen]

On Sat, Dec 23, 2017 at 3:43 PM, Shailendra Paliwal
 wrote:
> Hello,
>
> I'm trying to communicate with an Analog Devices evaluation board (SDP-H1).
> AD has a windows software that initializes the board and can be used to read
> the data coming from the USB connection with the board.
>
> I have been trying to write something in pyusb that can do the same and work
> with my Raspberry Pi. So far, I have figured out how to initialize the
> board. I need help in understanding the protocol used in fetching data from
> it.
>
> Device Descriptor: http://shailendra.me/USB.html

Page not available.

> Here is the PCAP file of the USB trace:
> https://github.com/vcidst/vcidst.github.io/blob/master/sdph1-data_clean.pcap
> (you can use wireshark to open pcap files)
>
> I've read a lot of write-ups of people reverse engineering USB protocols
> which mostly include looking at the control transfers. However, this device
> only has two bulk endpoints and all the communication is done with bulk
> transfers.
>
> Quick facts about the PCAP file:
> * Replaying packets 1-108 initialize the board.
> * At packet 109 (use filter frame.time_relative >= 40), In the windows
> software I chose sample size 1048576 and press Continuous Capture button.
> * Packets 109 to 119 prepare the capture from SDP-H1.
> * From packet 120, 6 packets of similar structure are sent/received again
> and again.
> * After that, I see 6 packets of different structure at (frame.time_relative
>>= 41.059593)
> * Packets after (frame.time_relative >=41.073968) are of different structure
> again until the end.
> * Towards the end, I stop the capture from the windows software thus the
> last few packets should be stop packets .
>
> My questions now are,
> 1. Is this device following any standard USB protocol format that I am not
> familiar with?

Most likely it uses vendor specific protocols not falling into standard
USB device class definitions.

> 2. I'm currently replaying the packets to initialize the device, is there a
> better way to do this?

If you do not know the protocol, this seems to be the only way.

> 3. (a basic question that I still don't understand) in USB Communication,
> after I have sent Bulk Write request. Do I need to send a bulk read request
> if I need to read some data? Can the program just not read whatever the
> device sends without me sending the device anything?

No. USB does not work that way. The device does not automatically send
data to the host without host initiate the communication.

> 4. The data packets here are huge and I was wondering if I need to send the
> entire packets whenever sending a bulk write request. Is there a way I can
> figure out what is essential information in the packet and what is not?

If you do not know the protocol, I do not think you have a way to know
what is essential and what is not. You have to look into the huge data
and then try to understand. All in all the efforts required may be huge.

> (I have read the Bulk Transfer section from USB in a Nutshell but still
> didn't understand why it has to be this way unlike say, RS232 communication
> where the device can keep on sending data in continuous mode)

USB is much more complicated than serial communication.

On the other hand, there is probably an easier way out without using
the SDP-H1 if your interests are to connect your Raspberry Pi to a paticular
daughter board. Quite some of them using SPI protocol. The schematics
and documentations of the daughter boards are available.



-- 
Xiaofan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
pyusb-users mailing list
pyusb-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pyusb-users