V1 Unpatched Switch ESP32-S3 payload injector

[mcPickleRick]

thanks for the detailed response. i have the amoled 1.8 V1...will have to lookup the waveshare examples at somepoint in the future. on another note, i used the latest code on a seeed studio esp32-s3 and am able to get into the web interface and load payloads. i added a battery to the device (it has battery terminals onboard) and can access the web interface when on battery but plugging it into my switch does not inject the payload. i confirmed im on RCM by connecting to my PC and checking TegraRCMGui. is there anything special that needs to be done to inject the payload?

 

[snuffbot1]

thanks for the detailed response. i have the amoled 1.8 V1...will have to lookup the waveshare examples at somepoint in the future. on another note, i used the latest code on a seeed studio esp32-s3 and am able to get into the web interface and load payloads. i added a battery to the device (it has battery terminals onboard) and can access the web interface when on battery but plugging it into my switch does not inject the payload. i confirmed im on RCM by connecting to my PC and checking TegraRCMGui. is there anything special that needs to be done to inject the payload?

I had a look at the pinouts for that board and there's d+ and d- pinouts on the back of the board and also the d+ and d- that are used to program it, I don't know how they are mapped so you need to check the data sheet for that board to see how they are wired. There's loads of different versions of esp32-s3 so you'll need to make sure you are using the correct boards file for the version you are using. If you soldered to the d+ and d- on the back of the board to inject, then you can plug the board into a pc at the same time and check the console debug logs to see what's happening. (you might need to temp recompile with enable cdc on boot to see the logs - this should be set to off (disabled) normaly or injection won't work).

See here for boards file: https://wiki.seeedstudio.com/xiao_esp32s3_getting_started/

 

[mcPickleRick]

is this normal even though i set the USB CDC on Boot setting to disabled?:

 

[snuffbot1]

is this normal even though i set the USB CDC on Boot setting to disabled?:
View attachment 587373

Yes don't worry about that, it depends on the board. Original code was done on a dev board with 2 usb ports and the code below works fine. On some boards it works differently (your boards file probably doesn't define this - ARDUINO_USB_MODE
), as long as when you compiled you make sure you disabled cdc it stops you sending serial data which would interfere with payload injection bytes. CDC enabled is only useful for debugging, which breaks injection code from working so make sure it's disabled when flashing the esp32-s3.

You can alter the logic in this code section, depending on what your board code uses, but it's not needed as it's only for UI stuff which doesn't effect injection at all.

#ifdef ARDUINO_USB_MODE
        bool usb_cdc_enabled = ARDUINO_USB_MODE;
    #else
        bool usb_cdc_enabled = false;
    #endif

    #ifdef USBCON
        usb_cdc_enabled = true;
    #endif
    #if !CONFIG_IDF_TARGET_ESP32S2
        doc["usb"]["cdc_enabled"] = usb_cdc_enabled;
        doc["usb"]["serial_connected"] = Serial ? true : false;
        doc["usb"]["vid"] = USB_VID ? USB_VID : 0x303a;
        doc["usb"]["pid"] = USB_PID ? USB_PID : 0x1001;
    #endif

Here's what's wrong with the code and how to fix it:

USBCON Defined whenever the board/variant has any native USB support compiled in. It does not mean CDC is enabled.

Your code does this:
Sets usb_cdc_enabled = ARDUINO_USB_MODE → correctly gets 0 or 1
Then #ifdef USBCON → overwrites it with true regardless of the actual mode So on any board where the variant defines USBCON (most ESP32-S3 boards do), you always report CDC enabled even when the board is in OTG mode (ARDUINO_USB_MODE=0).

Why it varies by board
Different board definitions (in boards.txt / variants/) set these macros differently:
Some define USBCON in the variant headers
Some don't

The "USB Mode" menu in Arduino IDE (or your PlatformIO build_flags) controls ARDUINO_USB_MODE
So boards from one manufacturer may define USBCON while others don't, causing the inconsistent behavior you're seeing.

The fix
Use ARDUINO_USB_MODE as the authoritative source when it exists, and only fall back to USBCON when it doesn't:

bool usb_cdc_enabled = false;

#ifdef ARDUINO_USB_MODE
    usb_cdc_enabled = (ARDUINO_USB_MODE == 1);
#elif defined(USBCON)
    usb_cdc_enabled = true;
#endif

If you also want to account for the "CDC on Boot" setting specifically, you can add:

#ifdef ARDUINO_USB_CDC_ON_BOOT
    usb_cdc_enabled = usb_cdc_enabled && ARDUINO_USB_CDC_ON_BOOT;
#endif

Bottom line: USBCON means "USB is present," not "CDC is enabled." Don't let it override ARDUINO_USB_MODE.

So to summerize, this is what your fixed code section should look like:

doc["mac"]["ap"] = macStr2;
    doc["mac"]["base"] = baseMacStr;
 
    bool usb_cdc_enabled = false;
 
    #ifdef ARDUINO_USB_MODE
    usb_cdc_enabled = (ARDUINO_USB_MODE == 1);
  #elif defined(USBCON)
    usb_cdc_enabled = true;
  #endif
 
  #ifdef ARDUINO_USB_CDC_ON_BOOT
    usb_cdc_enabled = usb_cdc_enabled && ARDUINO_USB_CDC_ON_BOOT;
  #endif

    #if !CONFIG_IDF_TARGET_ESP32S2
        doc["usb"]["cdc_enabled"] = usb_cdc_enabled;
        doc["usb"]["serial_connected"] = Serial ? true : false;
        doc["usb"]["vid"] = USB_VID ? USB_VID : 0x303a;
        doc["usb"]["pid"] = USB_PID ? USB_PID : 0x1001;
    #endif

Settings should look like this:

If you are still having issues after this, you probably have an issue with the usb cable/wires you are using either being soldered wrongly or not thick enough. So try a differen't usb cable and make sure to that gnd wire is connected between your chip and usb gnd on the switch.

 

[Jacoghi]

Thanks for the info @snuffbot1 ! I wasn't even aware of this new VUE thing yet, so is it worth it when compared to exfathax?
As for the dongle here, I haven't had luck actually with the supermini working on its own, it doens't turn on by itself when in RCM mode (I tried the Basic array code without all bells and whistles to try to lower the power requirement and still didn't work. - I was expecting the RCM mode to provide enough power to turn the board on from some other comments in the thread) Any suggestions when it comes to that? My next alternative is gonna be wiring a 5V to the board and cutting the power power line between the Switch and the board, and connecting it to a USB charger, since I've very sporadically need this and normally don't have an Android phone with Rekado to do this process. I won't use it as a modchip so just a dongle whenever for some reason the Switch is stuck in Auto RCM mode.
Thanks