[enhancement] Changeable USB VID & PID

[whid-injector]

Implement the Changeable USB VID / PID feature in order to let user decide its favorite VID/PID, in order to bypass endpoint restrictions.

[exploitagency]

This is easy enough to do by the end user. If I were to implement this feature it would involve ditching the Arduino IDE thus limiting ease of use for a lot of people. I think a "how-to" is better for this, even if I wrote some sort of patch there are still many different OS/Non standard Arduino Installations/etc... I try my best to be cross-platform.

Find and edit boards.txt, it may be located at Linux: /root/.arduino15/packages/arduino/hardware/avr/1.6.19/ or Windows: C:\Users\USER\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.6.19\ or somewhere else...

Add the below quote to the end of boards.txt, RESTART THE ARDUINO IDE(boards.txt is loaded at startup I believe), select Cactus WHID under boards instead of LilyPadUSB when you upload the Arduino_32u4_Code sketch.

##############################################################

CactusWHID.name=Cactus WHID CactusWHID.vid.0=0x1B4F CactusWHID.pid.0=0x9207 CactusWHID.vid.1=0x1B4F CactusWHID.pid.1=0x9208

CactusWHID.upload.tool=avrdude CactusWHID.upload.protocol=avr109 CactusWHID.upload.maximum_size=28672 CactusWHID.upload.maximum_data_size=2560 CactusWHID.upload.speed=57600 CactusWHID.upload.disable_flushing=true CactusWHID.upload.use_1200bps_touch=true CactusWHID.upload.wait_for_upload_port=true

CactusWHID.bootloader.tool=avrdude CactusWHID.bootloader.low_fuses=0xff CactusWHID.bootloader.high_fuses=0xd8 CactusWHID.bootloader.extended_fuses=0xce CactusWHID.bootloader.file=caterina-LilyPadUSB/Caterina-LilyPadUSB.hex CactusWHID.bootloader.unlock_bits=0x3F CactusWHID.bootloader.lock_bits=0x2F

CactusWHID.build.mcu=atmega32u4 CactusWHID.build.f_cpu=8000000L CactusWHID.build.vid=0x0000 CactusWHID.build.pid=0xFFFF CactusWHID.build.usb_product="Cactus WHID" CactusWHID.build.usb_manufacturer="April Brother" CactusWHID.build.board=AVR_LILYPAD_USB CactusWHID.build.core=arduino CactusWHID.build.variant=leonardo CactusWHID.build.extra_flags={build.usb_flags}

Replace this portion with your spoofed VID/PID.

CactusWHID.build.vid=0x0000 CactusWHID.build.pid=0xFFFF CactusWHID.build.usb_product="Cactus WHID" CactusWHID.build.usb_manufacturer="April Brother"

On Apple Devices I believe you can bypass the unknown keyboard hurdle by spoofing an Apple VID/PID thus running payload upon insertion vs having to identify the keyboard first.

I believe the below will work.

CactusWHID.build.vid=0x05ac CactusWHID.build.pid=0x021e CactusWHID.build.usb_product="Aluminum Keyboard IT USB" CactusWHID.build.usb_manufacturer="Apple Inc."

[whid-injector]

Cool solution! I never had time (or need yet) to dig into this, and didn't want it to get lost in the issues. (reason why I opened here, since ESPloit V2 will be delivered with Cactus WHID by default). Glad I opened the issue and you immediately proposed a solution! Nice job man!

[exploitagency]

No problem, I modified my above answer slightly too, speaking of which ask April Brother to ship with the latest firmware as I set it up to connect to my server when you go to Update Firmware and check for updated releases on Github, display if an update is available, then download the update and apply it if the user chooses to. I am not a 5-9er by anymeans but my uptime is usually pretty good.

This will make it simple for an end user to keep in the loop without needing any knowledge about Arduino or Github etc... all the old features are retained, this is just a bonus. Plus it really helps April Brother out on having to reflash devices, as its ok for them to ship with an older firmware unless there are changes in the 32u4 code.

If I change the 32u4 I may make some sort of alert to the user that the new firmware requires the user to manually update it to gain any new functionality. Trying my best not to make any changes get sloppy/break things for new users or those with less experience in general.

[whid-injector]

This feature is very cool and I like it! However, might be better to be configurable on the UI (i.e. enable/disable autoupdate check) Imagine the scenario where a Cactus WHID is deployed during an engagement and is using the client wifi network as Client and the attacker is controlling it within the same LAN... With your auto-update feature on... it would start to generate outbound traffic to the internet (i.e. your server) that would be logged and likely traverse target's IPS/IDS/FW. Ideally, is always better to keep these devices as silent and stealthy as possible from a network activity perspective.

[exploitagency]

It should only be triggered if someone browses to the DEVICES-IP/firmware url. Then the update will only be applied if the user chooses. I think we are still good to go. I have a feeling that a lot of people buying these will never update the firmware if it requires installing the Arduino IDE and cloning the Repo compiling and uploading the code, etc. Although thats the only solution I see to update the 32u4 code. April Brother will need to reflash for that or me make an alert system that firmwares don't match.

 server.on("/firmware", [](){
    latestversion = "";
    http.begin("http://legacysecuritygroup.com/esploit.php");
    int httpCode = http.GET();
    if (httpCode > 0) {
      latestversion = http.getString();
    }
    http.end();

[whid-injector]

Now I got it! So is triggered only under user's action. Cool then! Yeah, is definitely the best solution indeed! Well actually the dealing-with-Arduino stuff... was mainly to not keep things that simple, that everyone will be able to use it immediately (the so called plug-n-hack) =P

[whid-injector]

Forgot to close the ticket :)

[exploitagency]

I will actually leave this one open so people can find it easier until I get around to adding it to the readme or figuring out how I want to document things like this along with changing keyboard layouts.