MAX98357A for Radza Zero 3 – Giving Skelly a Voice with I2S and GPIO

When I started my AI Powered Skelly project built with a Radxa Zero 3 I quickly discover that the board does not ship with on‑board audio. This was a problem, because I really wanted to utilize the existing speaker within the 3ft Dancing Skeleton animatronic as a more natural source of audio output. To solve this I choose to use a MAX98357A mono amplifier to drive audio output to small speaker. This article walks you through everything you need to get the MAX98357A working on a Radxa Zero 3, from wiring the pins to enabling I2S software and finally creating the custom device‑tree overlay that makes the kernel aware of the hardware.

 MAX98357A

Why Choose MAX98357A for Radxa Zero 3?

FeatureMAX98357ATypical Alternatives
Power consumption< 100 mW (idle)> 200 mW for many DACs
Output typeMono, 3 W Class‑DStereo, often larger footprint
InterfaceI2S digital audio input onlyPCM/I2C/USB combos
Gain controlFixed (9 dB default) or external pinVariable via software registers
Shutdown pinOptional hardware lineOften not present

Because the amplifier needs only three I2S signals (BCLK, LRCK and DATA) plus power and ground, it can be wired directly to the standard I2S pins on the Radxa Zero 3 without any extra level shifters. The board’s 5 V rail supplies the amplifier’s VIN, while the GND pins provide a clean reference.

GPIO Pinout – Mapping MAX98357A to Radxa Zero 3

The Radxa Zero 3 exposes its I2S‑3 controller (named I2S3_M0) on the following header pins:

MAX98357A pinFunctionRadxa Zero 3 Pin #SoC GPIO name
VIN5 V power2 or 4 5v VDD_5V
GNDGround6, 9, 14, 20, 25, 30, 34, 39GND
BCLKI2S Bit Clock12I2S3_SCLK_M0
DIN (DATA)I2S Serial Data In40I2S3_SDO_M0
LRC (LRCK)I2S Left‑Right Clock35I2S3_LRCK_M0
GAIN (optional)Fixed gain selector – connect to GND for 6 dB, leave floating for default 9 dBany free GND (e.g., 20)GND
SD (Shutdown)Active‑low shutdown – pull low to muteany free GPIO (e.g., 16 with optional PWM)GPIO3_B1/PWM8_M0

Tip: The GAIN and SD pins are optional. For a simple “always on” configuration you can leave them floating. If you need hardware mute, connect the SD pin to a spare GPIO and drive it low when you want silence.

Wiring Diagram

Wiring MAX98357A for Radxa Zero 3
Radxa Zero 3                 MAX98357A
---------------------------  -----------------
Pin 4   (+5 V)               VIN  (Red)
Pins 6/9/... (GND)           GND  (Black)
Pin 12  I2S3_SCLK_M0 (BCLK)  BCLK (Blue)
Pin 40  I2S3_SDO_M0  (DATA)  DIN  (Orange)
Pin 35  I2S3_LRCK_M0 (LRCK)  LRC  (Green)
Pin 16  (optional)           GAIN (Purple Doted)
Pin 18 (optional)            SD   (Black Doted)

All connections are 5 V tolerant on the Radxa Zero 3, and the MAX98357A operates comfortably from 2.7 V up to 5.5 V, so no level shifting is required.

Preparing the Software – Enabling I2S in the Kernel

The Radxa Zero 3 runs a Debian‑based OS (or Ubuntu) with a Linux kernel that already contains an I2S controller driver (i2s-axg). However, the default device tree does not expose the I2S3_M0 peripheral for audio output. To make it usable you must:

  1. Install the overlay tooling – Radxa provides rsetup and a set of scripts to compile and install custom overlays.
   sudo apt-get update
   sudo apt-get install rsetup device-tree-compiler
  1. Disable any conflicting overlay – The board ships with an i2s3-m0 overlay that is intended for microphone input. You need to remove or disable it before loading your speaker overlay.
   sudo rsetup overlay disable i2s3-m0
  1. Compile the custom overlay (shown in the next section) and install it:
   sudo rsetup overlay add radxa-zero3-max98357a.dts
  1. Reboot to let the kernel load the new device‑tree node.
   sudo reboot
  1. Verify that the I2S PCM device appears under /dev.
   aplay -l
   # You should see something like:
   # card 0: Rockchip [rockchip i2s], device 0: I2S3 PCM [...]
  1. Test audio playback – Use aplay with a raw PCM file or any WAV that matches the default format (16‑bit, 44.1 kHz, mono).
   aplay -D plughw:0,0 /usr/share/sounds/alsa/Front_Center.wav

If you hear sound from your speaker, the hardware and software stack are correctly configured.

The Custom Device‑Tree Overlay – radxa-zero3-max98357a.dts

Below is the complete overlay source that tells the kernel to expose I2S3_M0 as a PCM output and optionally controls the GAIN and SD pins as GPIOs.

/dts-v1/;
/plugin/;

#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/rockchip.h>

/ {
    metadata {
        title = "Enable MAX97357A on I2S3-M0";
        compatible = "radxa,zero3";
        category = "audio";
        description = "Enable MAX97357A on I2S3-M0";
        exclusive = "GPIO3_A0", "GPIO3_A3", "GPIO3_A4", "GPIO3_A5", "GPIO3_A6", "i2s3_2ch";
    };
};

&{/} {
    max98357a_codec: max98357a {
        #sound-dai-cells = <0>;
        compatible = "maxim,max98357a";
        sdmode-gpios = <&gpio3 RK_PA0 GPIO_ACTIVE_HIGH>;
        sdmode-delay = <5>;
        status = "okay";
    };

    sound_ext_card: sound-ext-card {
        #address-cells = <1>;
        #size-cells = <0>;
        status = "okay";
        compatible = "simple-audio-card";
        simple-audio-card,format = "i2s";
        simple-audio-card,mclk-fs = <256>;
        simple-audio-card,name = "snd_max98357a_dac";
        simple-audio-card,dai-link@0 {
            reg = <0>;
            format = "i2s";
            cpu {
                sound-dai = <&i2s3_2ch>;
            };
            codec {
                sound-dai = <&max98357a_codec>;
            };
        };
    };
};

&i2s3_2ch {
    pinctrl-0 = <&i2s3m0_lrck &i2s3m0_sclk &i2s3m0_sdi &i2s3m0_sdo>;
    status = "okay";
};

How the Overlay Is Applied

  1. Compilersetup overlay add radxa-zero3-max98357a.dts runs dtc -@ -I dts -O dtb internally and places the resulting .dtbo file under /boot/overlays.
  2. Activate – The same command updates /boot/extlinux/extlinux.conf to load the overlay at boot.
  3. Boot – During kernel initialization, the overlay patches the base device tree, making the simple-audio-card node visible to ALSA.

Controlling Shutdown from Userspace

Because we exposed the optional pins as standard Linux GPIOs, you can manipulate them with the sysfs interface or via the newer libgpiod library.

Using sysfs (quick test)

# Export GPIO11 (shutdown) and keep high (amp on)
echo 16 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio16/direction
echo 1 > /sys/class/gpio/gpio16/value  # 1 = not shutdow

Using libgpiod (modern approach)

#include <gpiod.h>

int main(void) {
    struct gpiod_chip *chip;
    struct gpiod_line *sd;

    chip = gpiod_chip_open_by_name("gpiochip3");
    sd   = gpiod_chip_get_line(chip, 1);    // GPIO16

    gpiod_line_request_output(sd,   "max98357a_sd",   1);

    /* ... later you can toggle them */
    gpiod_line_set_value(sd,   0); // shutdown amp
}

Container‑Friendly Deployment

If you are running audio workloads inside Docker on the Radxa Zero 3, keep the following in mind:

RequirementHow to satisfy
Access to /dev/sndAdd --device /dev/snd:/dev/snd (Docker) or mount the device in the pod spec.
GPIO controlMount /sys/class/gpio read‑write or use the gpiod socket (/run/gpiod).
Real‑time scheduling (optional)Use --cap-add SYS_NICE and set ulimit -r 99.
Overlay persistenceThe overlay is applied at boot, so containers do not need to modify it. Just ensure the host kernel has loaded the PCM device before container start.

A minimal Dockerfile for an audio player might look like:

FROM debian:bookworm-slim

RUN apt-get update && \
    apt-get install -y alsa-utils libgpiod2 && \
    rm -rf /var/lib/apt/lists/*

COPY myplayer.sh /usr/local/bin/
ENTRYPOINT ["/usr/local/bin/myplayer.sh"]

Run it with:

docker run --rm -it \
  --device /dev/snd:/dev/snd \
  -v /sys/class/gpio:/sys/class/gpio:rw \
  my-audio-player

Now your container can play back WAV files through the MAX98357A and mute/unmute using GPIO.

Troubleshooting Checklist

SymptomLikely CauseFix
No sound, aplay returns “Invalid argument”I2S node not enabledVerify overlay loaded (dmesg | grep i2s3) and run aplay -l.
Crackling or clicksClock mismatch or bad power supplyEnsure VIN is stable 5 V, add a decoupling capacitor (10 µF) near the amplifier.
Speaker only plays one channelLRC pin mis‑wired or wrong pinmuxDouble‑check that Pin 35 is connected to LRC and i2s3_m0_pins includes it.
Amplifier stays silent even after GPIO highSD pin tied lowRemove the shutdown connection or set GPIO16 value to 1.
Gain not changingGAIN pin left floating while expecting -6 dBConnect GAIN to a GPIO and drive it low, or permanently tie to GND for fixed gain.

Use journalctl -k to see kernel messages about the audio card; any “probe failed” lines usually indicate a mis‑matched overlay.

Security Considerations

Even though this guide focuses on hardware integration, running audio services on an edge device still raises security questions:

  1. GPIO Exposure – Unrestricted access to /sys/class/gpio allows any local user (or compromised container) to toggle the amplifier’s pins, potentially causing denial‑of‑service or odd behavior. Restrict GPIO permissions using Linux capabilities or mount namespaces.
  2. Audio Injection – If your device accepts network streams, validate source authenticity (TLS, signed manifests) before feeding data to ALSA.
  3. Kernel Attack Surface – Custom overlays modify the kernel’s view of hardware. Ensure only trusted administrators can write overlay files; use immutable boot partitions where possible.

Conclusion

The MAX98357A for Radxa Zero 3 offers a lightweight, low‑cost way to add mono audio output to any project that runs on this SBC. By wiring three I2S pins and enabling the I2S controller through a custom device‑tree overlay I was able to give the AI Skelly the power to speak.

Up next we look at how to programmatic trigger an event, in order to capture an image from a simple attached webcam. Then how to process the image via a standard openAI style API call to a local AI service like ollama serve or LMStuido server. In order to ask targeted questions about the capture image, such as the Halloween costumes in frame. The we can use the prompt response to generate a unique voice line response with services like piper. All while keeping everything completely offline for privacy and security.

Bringing Skelly to Life: A Radxa Zero 3W Powered AI Halloween Skeleton

Halloween is my favorite time of year, and I love creating interactive experiences for trick-or-treaters. Last year, Alex Volkov’s project on Weights & Biases – building an AI-powered skeleton using a Raspberry Pi – sparked an idea. This year, I wanted to take that concept further, aiming for a smaller footprint and increased processing power by leveraging the Radxa Zero 3W single board computer. This blog post details my journey of transforming a standard Home Depot 3ft Halloween Classics Animated LED Dancing Skeleton into a locally AI-driven greeter. We’ll cover everything from dismantling the original animatronic, wiring up the Radxa Zero 3W, and setting the stage for integrating local vision models to recognize costumes.

The Inspiration & Goals

Volkov’s project was brilliant: using online AI services like Google AI Studio, ElevenLabs (for voice), Cartesia, and ChatGPT to create a responsive skeleton that could greet trick-or-treaters. However, relying on cloud services introduces latency, requires a stable internet connection, and could raise privacy concerns – not ideal for the often chaotic Halloween night. My goal was to replicate the interactive experience but move all processing local, using a more compact and powerful board than the Raspberry Pi 4. The Radxa Zero 3W seemed like the perfect fit. It packs significant punch in a tiny form factor, offering Wi-Fi connectivity, Bluetooth, and ample GPIO pins for controlling the animatronic components.

Disassembly & Component Identification: Getting to Know Skelly

The first step was understanding how the original skeleton worked. This involved carefully dismantling the 3ft dancing skeleton. Start by removing the back of the skull and chest plate; this provides access to the control board, battery pack, motors, and speaker. Be gentle – these animatronics aren’t built for extensive tinkering!

Inside the skull, you’ll find a DC motor controlling the mouth movement (yellow positive, white ground wires) and LEDs illuminating the eyes (red positive, black ground wires).

Photo of the skeleton's internal components after removing the skull backplate. Highlight the mouth motor and eye LEDs

Under the chest plate you will see a hardware speaker with two blue wires and another DC motor powering the body/arm movements (positive red, ground black). All these wires converge on a small control board.

Photo of the skeleton's internal components after removing the chest backplate. Highlight the control board, battery pack,  body motor, and speaker

It’s crucial to document everything as you go. I took numerous photos and created a wiring diagram to ensure I could reassemble everything correctly (or at least understand where things went if something went wrong!).

Close-up documenting the Home Depot 3ft Halloween Classics Animated LED Dancing Skeleton control board wiring

The original manufacturer uses transistors and capacitors to compensate for the fluctuating battery voltage – typically between 1.4V and 1.66V with three AA batteries in parallel, reaching around 5V. This is a good reminder that relying solely on the battery pack’s power output isn’t ideal; we’ll address this later.

Wiring Up the Radxa Zero 3W: The Heart of the Operation

The plan was to intercept the signals going to each component – mouth motor, eye LEDs, body motor, and speaker – and control them via the Radxa Zero 3W’s GPIO pins. This required carefully unsoldering these wires from the original control board.

Once unsolder, I connected each wire to a set of jumper pins, allowing me to easily breadboard and test connections before committing to permanent soldering. This also provides flexibility for future modifications.

Note: I included a 220 Ohm inline to help prevent the eye LEDs from burning out. Its not required, but its recommended to avoid burning out the LEDs during tinkering.

Close-up photo showing the wires from the skeleton's components connected to jumper cables.

Here’s the GPIO pinout I utilized on the Radxa Zero 3W (gpiochip3):

  • PIN_7 (gpiochip3 20) – Mouth motor open/close
  • PIN_11 (gpiochip3 1) – Eye LEDs illumination
  • PIN_15 (gpiochip3 8) – Body motor for dancing movement

The Radxa Zero 3W’s official documentation outlines the 40-pin GPIO interface. Since we’re using pins 12, 40 and 35 for our mono amp (more on that later), this leaves a good selection of readily available pins on gpiochip3 to control relays.

  • Pin 7: GPIO3_C4 (also PWM14_M0)
  • Pin 11: GPIO3_A1
  • Pin 15: GPIO3_B0
  • Pin 16: GPIO3_B1 (also PWM8_M0)

Note: PWM (Pulse-Width Modulation) can be used on Pin 7 and Pin 16 by enabling the correct device tree overlay using rsetup and/or u-boot. This allows for finer control over LEDs (dimming) and DC motor speeds, but wasn’t necessary for this initial implementation.

Powering Skelly: The Radxa Zero 3W to the Rescue

Initially, I considered powering the components directly from the battery pack. However, as mentioned earlier, the inconsistent voltage proved problematic. The solution? Leverage the Radxa Zero 3W’s 5V GPIO power rails! This provides a stable and reliable power source for all components.

To manage the current requirements of the motors and LEDs, I incorporated relays inline with each component’s wiring. Relays act as electrically controlled switches, allowing the Radxa Zero 3W to control the flow of power from its 5V output to the skeleton’s components.

showing how the Radxa Zero 3W controls the skeleton's components via relays

Relay Implementation: The Switching Mechanism

Each relay requires a control pin on the GPIO, which when activated, allows power to flow through it. The wiring is as follows:

  1. Connect the Radxa Zero 3W’s 5V output to both sides of each relay.
  2. Ground each relay and component to the Radxa Zero 3W’s ground pins.
  3. Connect the control pin on the GPIO to the relay’s control input.
  4. The output power of each relay connects to the corresponding component’s jumper (mouth motor, body motor, eye LEDs).

When the GPIO pin is set HIGH (active state), the relay closes, allowing power to flow from the Radxa Zero 3W to the component. When the pin is LOW, the relay opens, cutting off the power supply. This effectively gives us programmatic control over each animatronic function.

Breadboarding & Testing: Bringing it All Together

I started by breadboarding everything – connecting the Radxa Zero 3W, relays, jumpers, and a temporary power source to verify functionality. This is where patience is key! Double-check all connections before applying power. A multimeter is your best friend during this phase. Once I confirmed that each component responded correctly to the GPIO signals, I removed the breadboard and connected everything directly to the jumper wires for a more permanent connection.

Mounting & Final Assembly: Skelly Gets an Upgrade

With the wiring complete, it was time to mount the Radxa Zero 3W inside the skeleton’s chest cavity. I repurposed the original control board’s mounting point and used some 2.5mm standoffs to secure the Radxa Zero 3W in place. This ensured a snug fit without interfering with any existing components.

 Photo showing the Radxa Zero 3W and relays mounted inside the skeleton’s chest cavity

I then stuffed all the “guts” back into the body, wrote a simple web control page, using Flask, to test the functionality remotely, and ran through final testing. Success! Skelly was now responding to commands from my computer, ready for the next phase: AI integration.

The Next Phase: Local Vision Models & Costume Recognition

With Skelly reasonably buttoned up and his basic movements working, I’m moving on to the most exciting part of the project – leveraging a connected camera and locally hosted/trained vision models to determine trick-or-treaters’ costumes. This will involve using services like LMStuido on an AMD AI workstation to leverage models like Gemma 3 for vision to text. I plan to document this process in a future blog post, so stay tuned! But up next a deep dive on how to leverage device tree overlays and I2S via GPIO, to power an existing hardware speaker with a MAX98357A mono amp.

Resources & Further Exploration

This project has been a fantastic learning experience, combining hardware tinkering with software development and AI integration. The Radxa Zero 3W proved to be an excellent platform for this application, offering the power and flexibility needed to bring Skelly to life. I hope this blog post inspires you to create your own interactive Halloween experiences!

Giving a Blackwidow it’s “Teensy” Fangs with Arduino

How to Install Arduino Backdoors within Modern Keyboards

TLDR; It is very possible to place a Teensy Arduino within modern keyboards and mice as a hardware backdoors in order to implant a Trojan on a targets computer.

Warning #1: Please understand that working with electrical equipment and components is inherently dangerous. Burns, shocks, and electrical fires are fairly common when attempting to manipulate commercial/consumer grade electronics.

Warning #2: The author of this article claims no responsibility for personal harm or damage to personal property. This information is provided as is and without merit or warranty.

Problem

Some of our tougher targets have gotten very good at detecting and shutting down our normal social engineering attack vectors. In fact several are now able to systematically detect and shutdown our classic, emails, phone calls, and media drops Trojans. Once a client has established a strong defense against our standard attack vectors we are at somewhat of a loss as to how to approach social engineering. This has forced our team to come up with new and innovative ways to get in and get access.

Solution

My innovative idea is a new twist on an older poly idea, the hardware backdoor. Where one actually solders malicious hardware into another hardware system to gain access. This is normally done to subvert security controls such as drive encryption or to maintain access to a computing system.

However I’m not the NSA, nor am I am electrical engineering, so instead of attempting to compromise an entire computing system, I set out to simply place a hardware device within a keyboard. The idea being that I could purchase a few higher end keyboards, backdoor them, and send them out as gifts to targeted individuals. I quickly discovered a cheap Arduino based keyboard controller called Teensy and set out on my quest.

After conducting some further research, I quickly realized why we don’t see this attack vector being used in the wild. I won’t go into complete detail on every discovered issue, but a brief list is as follows.

  • Most keyboards are now soft-key using two sheets of conductive plastic and a rubber boot to trigger a key-press.
  • Space is normally very limited and many keyboard types such as soft-key don’t handle added pressure well.
  • Creating a custom keyboard or even a DYI 60% (uses a modern PCB with built in controller), is very time consuming and expensive.
  • Keyboards now use proprietary layouts and controllers which make tampering with them difficult.
  • Almost all mechanical and soft-touch keyboards are now made with a dual or triple layer PCB, adding literally layers of complexity.
  • Simply splicing a device in the middle of the USB connection creates added complexity by requiring the handling of serial timing, errors, and interrupters.

Needless to say, I had to simplify my plan even further. So I narrowed my focus to Cherry MX mechanical keyboards with built in USB hub ports. Since the Cherry MX keys are extremely sought after and conveniently take up quite a bit of space, it should be fairly easy to tuck the quarter sized Teensy into some free space. Additionally, if there is already a USB hub built into the keyboard controller, I can simply add the device inside by soldering the Teensy directly to the internal leads.

Note: Using this method is quick and dirty. It will take over said USB ports communication path and power channel. If another USB is plugged into the target port, best case scenario one of the two devices doesn’t power up, worst case you have yourself a nice little electrical fire. As such I would recommend clipping the pins or putting a plastic cover over the original USB hole.

The last step is simply programing the Teensy, which is somewhat out of the scope of this article, due to complexity and lack of one size fits all payload. However the Social Engineering Toolkit (SET) contains a great of code to use as a starting point (linked bellow in references).

Note: Creating payloads requires the Arduino IDE with the Teensy library’s, modules, and extensions installed. You also require direct access to the Teensy via a micro-USB cable. Meaning VMware and the aforementioned hub setup should be avoided when compiling and uploading your payload.

Blackwidow Photos

Unfortunately the project for which I backdoored the Razer Blackwidow Ultimate had a fairly tight time table and did not allow for me to get very good photos. Nonetheless, I’ve included two of the better photos I have of the Blackwidow, to show that the same techniques can be successfully applied to modern keyboards as well.

Showing the completed build out of the Blackwidow with the Micro-USB attached to the single set of USB leads on the builtin controller.

Teensy within Blackwidow

This photo shows the limited space within the Blackwidow shell. In fact the cable as to be flush with the PCB corner in order to get the case to close. Then the Teensy itself  has to be firmly placed in an angle between the row of F-keys and the back wall of the lower plastic frame. In future builds I’ll likely just shave/grind down the plastic frame and or PCB to make things fit more precisely.

Teensy tucked within Blackwidow

About the Teensy Arduino

The Teensy is a quarter sized fully programmable keyboard controller based on the open Arduino hardware standards. The Teensy allows for complete control over the keyboard, mouse, and touch screen via pseudo C code. It allows for roughly 30,000 lines of compiled code and roughly 60MB of on board storage, so we can accomplish quite a bit. It also is designed and built in such a way to allow for it to be easily extensible by offering 54 leads/pins for project flexibility. The Teensy also operates at as low as 3.3 volts with .25 amps and as high as 6 volts with 1 amp, making it robust enough to be connected directly to a powered or unpowered USB hub/port within a keyboard or mouse.

Teensy Board Layout

A Simplified How To Guide

The photos below are of a generic HP console keyboard being backdoored. This is simply because I happened to have it laying around and it awarded me the time and error tolerance required to provide detailed photos and guidance. As stated, they same steps can generally be followed on a Blackwidow, however the components are quite a bit smaller and space is more limited, making it much harder to work with and display.

The first step is fairly simple, just take all the screws out of the back of the keyboard and pop the back cover off. Just be very careful to not damage any of the components or parts, including the tiny plastic tabs that normally seal the edges.

Opening a Modern keyboard

Next identify the USB port to target by considering surrounding space and ease of access. Here I’ve chosen to use the forward set of pins since there is more space and avoids the lower screw hole/ground

Viewing Configuration of onboard USB Hub

Next review the orientation and contacts of the female USB port to identify each lead against the USB standard. In this case the leads were on the lower portion of separator within the female USB port.These leads are just copper or aluminum that normally just have a 90 degree bend and connects straight down on the bottom of the board. In my case the leads simply passed straight through to the bottom USB port and were arranged in order from 1 to 4.

Viewing Pin-out of onboard USB Hub

Next cut a micro USB cable to the needed length, remove the shielding, remove the netting, untwist the wires, and strip the ends of each of the four wires. Then be sure to cut away all of the excess shielding and netting, so it doesn’t get in the way going forward.

Preparing USB wires for Teensy

In my case, each of the striped wires had dozens of tiny aluminum wires within them, instead of a single copper core. This can make keeping these wires together while soldering really annoying, but can also be used to your advantage by soldering the smaller wires together into a nice single bundle. The bundle makes soldering easier and the excess solder soaked up by the wires, normal removed to need to add additional solder when connecting the wires.

Combining Aluminum Wires Together

Once all the bundles are complete, they should all be soldered together and have a small ball on the ends. The ball on the end is used to quickly heat up each joint with the soldering iron and to quickly set the wire on the lead by holding it in place for a few seconds. If you are sensitive to heat, you may want to use some metal clips or helping hands.

Preparing Aluminum Wires

Be sure to double and triple check your solders against the USB wiring standard before testing, to avoid electrical fires.

USB Standards

Note: For those who may not know how to solder or need a refresher, I’ve included a info-graphic bellow that I think provides enough information to hit the group running.

Solder Guidance


Once all the wires are soldered into place, simply make sure none of the surrounding leads are jumped or damaged and then run some tests to verify the system works as intended. In my case I had an issue with the ground initially and the Teensy was not receiving power, so always test thoroughly.

Connecting Teensy to USB Hub


Once everything tests okay, find the best placement for the Teensy and secure the cable, Teensy, and solders with hot glue and/or electrical tape. In my case I had originally wanted to place my Teensy on the left side of the USB but the cable was too large for the sharp corner. Instead I carefully adjusted the cable over to the right under the USB hub cable.

Cleaning up Teensy Cable Connections


Once the Teensy and cable are secured in place, run some additional tests, to ensure nothing was damage then button everything up. Just note as stated earlier, you will need to remove the Teensy in order to properly connect it directly for development of your payload.

Hiding Teensy under USB Cable


The next image shows the Teensy hidden away under the USB hub cable. Just be careful about placing the Teensy on its face, as seen here, due to the payload launch button on the face. If its compressed it will continuously fire the payload until power is removed or all of the Teensy’s resources are locked up.

Teensy Under USB Hub Cable

References

As always I want to include references as a massive thank you to the community at large. I couldn’t have done this without their help, support, and knowledge.

PJRC makers of the Teensy: https://www.pjrc.com/store/teensy32.html

USB Standard Pin-outs: http://pinouts.ws/usb-pinout.html

Teensy Payloads by TrustedSec: https://github.com/trustedsec/social-engineer-toolkit/tree/master/src/teensy

Blackwidow Disassembly video: https://www.youtube.com/watch?v=2UwAgsLNa1Q

How to Solder: https://learn.sparkfun.com/tutorials/how-to-solder—through-hole-soldering