[enhancement] Changeable USB VID & PID

[exploitagency]

[enhancement] Changeable USB VID & PID

[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.

[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!

[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.