switching usb type in software (mouse-keyboard-mouse)

[NewGuy]

Hi,

First of all, excuse me for bad English and stupid questions but I'm a beginner to learn.

creating a project. In this project, teens change USB type in software.

1) teensy registers as mouse (mouse only)
2) after some time (some "if" condition) ... teensy re-register as a keyboard (only keyboard).
3) Teensy registers back as a mouse

If someone tried a similar project I will be very grateful for the code, advice.

Teensy 3.2

 

[defragster]

The only close thing I saw was during boot the Teensy decided which set of device descriptors to present.

After boot the USB is established using those parameters and there is no provision AFAIK to shut down and restart USB with different set of descriptors.

At a minimum you'd have to find that thread - now at least a year old where at boot before USB_init happens a selection is made - IIRC it was done setting an EEPROM value.

When a change was desired the EEPROM would be updated and the Teensy restarted to see the desired USB type to present before USB_Init and arrange to use the desired descriptors.

 

[NewGuy]

I have to create a badusb just for proof of concept (non-malicious usage). It's a school project, so I try to use Teens to create this badusb.

I read the concept that usb can have 2 descriptors.
1) Regular usb device (mouse descriptor).
After 15 seconds Teensy reboot itself.
2) Loading a new descriptor (keyboard decscriptor).


I don't know, is it possible?

 

[PaulStoffregen]

It really depends on what you mean by "possible".

If using only the USB code we publish for Teensy, doing everything from the comfort of simple Arduino programming, then no, not possible. The existing USB code is designed around a single set of USB descriptors.

If you're willing and able to edit the USB code, then yes, of course this is possible. But some pretty deep edits in the code would be needed. Fortunately the descriptors are accessed from only 1 place that responds when the host requests them, and it uses a table to match the hosts request against a list of all the descriptors, so you could perhaps create 2 tables or extend the table somehow.

You'll also need the code which actually implements the communication the USB descriptors advertise to the host. The current built process conditionally compiles only what's needed, so you'll have to edit some of those #ifdef checks. If the endpoints you use for both configs are mutually exclusive, you can get away with just having both built into the program and depend on the fact that the host won't try to use the endpoints which weren't mentioned in the descriptors you send.

In you decide to fully reboot Teensy, you can do that by writing to the SCB_AIRCR register. Search for that name on this forum to find threads where it's been discussed. If using Teensy 4.0, a bug affecting soft reboot was recently fixed, so look for that on this forum or github. The fix will be in 1.50 (likely starting beta next week). Not an issue if using Teensy 3.2.

The tricky part about rebooting is maintaining state. The RTC offers a small amount of memory for storing info that persists between reboots (and while power is off, if you connect the coin cell to keep the RTC going). Or you could just set the RTC date/time in various ways, as it persists across reboots.

This is all possible, but only with a pretty good amount of edits to the code. Hopefully this message will give you a good start on where to make those edits.

 

[defragster]

As Paul noted this isn't trivial - it will take core edits and care if no conflicts. If that post referred to in p#2 were found many of those issues were resolved to a working dual boot solution - and the suggestion to use EEPROM worked in the way the RTC RAM could be used. It was tested that EEPROM could be read before USB init to know the desired behavior.

Not sure how to search that post from long ago - came up empty with more context - and I have about 2,000 sketches from last 5 years and search didn't come up with that one working out the selective EEPROM boot that was part of the conditional USB Init.

 

[defragster]

Found it - short thread from 2018 that user got it working with EEPROM selectivity to toggle second usb_descriptor_list_t : pjrc.com/threads/53608-Configure-USB-after-sketch-has-already-loaded

Just a quick update to this thread. I tested making a second usb_descriptor_list_t and softcoded NUM_ENDPOINTS and NUM_INTERFACES, and was able to selectively load two separate device descriptors--extremely cool stuff. Thank-you for all your help.

Very short thread - but that detail should get you started on your project ideally to a good end if you can make sense of it. There are lots of other posts on USB_DESC that might provide a shortcut to the needed details.