Proxmark3 community

cjbrigato

Contributor

Registered: 2016-09-04

Posts: 52

[USB] Making CDC_Device of PM3 compatible with Others MCU's

Hello,

As I'm working a lot by extending the device possibilty withouth being centered on the client,
I'm using it a lot to be interfaced to other's MCU's.

What I was immediately slaped with is that MCU's manufacturer provided HAL or BSP are a lot of time, if not always, Incompatible with the CDC Implementation of the PM3.

Depending on CDC-Host implementation of targeted MCU, problem is reported with different reason, but always at the same point during enumation.

Gracefully, it is very simple to be solved, and if in any way it would be usefull to anyone, or if it is to make it's way to the builds , here it is :

https://gist.github.com/cjbrigato/ef7fc18119f7c4900efbbef9bda0eb0f

These modifications have no problematic impact on working cdc-host implemantation, be it on linux or osx.
If they have, please report.

These modification have arguable values. But hey have made the device compatible with the most Implementation I'm working withs, and where able to let the OTG's strange implementations of some device accept these as the only way to provide enough current through OTG port, if not being limited by something else in the way.

For the detail,

+       0xFD,      // SerialNumber
This could be anything else than 0x00 in near any device where the 0x00 is the problem

+       0xFA,   // CMaxPower
This could be anything else than 0x00 in near any device where it consider a power of 0 is enought to consider the device a dummy device not having to be at all be thought of supporting any Class at all. (yeah.. there are very weird CDC_host libraries here).
Some relies on this value as to be needed for the regulator of OTG's VBUS, so the most acurate it is, the best it is.
Mine is not accurate at all but being as near as FF as possible and still working with everything.

+       0x01, // bInterfaceProtocol
This one is the most important, as I didn't find any CDC_host implementation on my MCU's which accepted 0x00 as bInterfaceProtocol of the CDC CLass Interface Descriptor.

+       0x02, // bmCapabilities
Same as the former but for the Header Functional descriptor, as the Device was often reported to "not supporting the Cdc Class" at all when the bmCapabilities where at 0x00

I will refrain on what I think of a lot of USB-Host implementation of well known MCU's manufacturer, as having working CDC-Host implementation near-ready is being lucky enough.

any feedback would be appreciated on this.

iceman

Administrator

Registered: 2013-04-25

Posts: 9,537

Website

Re: [USB] Making CDC_Device of PM3 compatible with Others MCU's

Sweet work bro!,
When I look the usb_cdc.c it looks like a example from a manual. I think I've once change the descriptors to identify it as USB2.0 and not 1.1..

I pushed it into my fork.  When added windows found and added a new device.

cjbrigato

Contributor

Registered: 2016-09-04

Posts: 52

Re: [USB] Making CDC_Device of PM3 compatible with Others MCU's

Thanks a lot iceman,
Priority is to confirm not breaking too bad on windows, as I'm quite confident for OSx and Linux.

The implementation is OK, easy to find from where, and should have worked in that state, even if it was by falling back to this as default case.

There are a lot of difference in being riguorous on the USB Enumeration from a CDC_host implementation to another.
This is what I came at "Best Chance of working" with still "Nothing changed for Main OSes", and having nothing to change but the descriptor.
I Was lurking through the enumaration functions but ... no.

Please let me now as soon as any probleme is reported from this change, and if you have some MCU's around with a CDC_host library ready to be flashed and to test this also works, it's cool