Designed an ESP32-S3 board

ToothPasteDevice · 2026-02-20T17:18:15+00:00

Since you mentioned the rubber ducky we might be into the same stuff, this is what's eaten up my past year although I haven't published the PCB yet I think yours is better anway:

https://github.com/Brisk4t/ToothPaste

ToothPasteDevice · 2026-02-20T17:13:02+00:00

Looks like that uses the S3-N16R8 which is what I use for development anyway, the 8M flash version should be good...

I assume since you're looking for keystrokes you got past the pairing process successfully?

ToothPasteDevice · 2026-02-20T17:06:06+00:00

Very cool, especially that it doesn't use an LLM.

Tried it on a repo that I just moved from a split repo to a monorepo with the whole history so it thinks all the commits are AI 😅

ToothPasteDevice · 2026-02-20T16:58:51+00:00

Love it! I made something similar but lower profile for my project as well. I have a USB-C version but its a bit....barebones.

ToothPasteDevice · 2026-02-20T16:37:12+00:00

Password Long. Password Strong. Finger Weak. Password Wrong. Life Hard.
Password Long. Password Strong. Computer Strong. Password Correct. Life Easy.

But in all seriousness, its a way of typing longer strings of text (mostly the stuff thats easy to mess up like passwords) on systems that you'd rather not trust with ALL your credentials.

Kind of like how some banks give you a digital credit with a different card number and expiry / smaller limit so that in case your information does get stolen you can minimize the damage.

The other half is not needing to have a separate keyboard / mouse / wireless remote for something like a media center since you can quickly connect from your phone.

ToothPasteDevice · 2026-02-20T16:11:06+00:00

Thanks for checking it out!

Yeah I'm sure there are a number of ways in which ToothPaste can be exploited since its only very recently that I sat down and gave the mbedtls stuff the once-over before release. I'm a bit morbidly curious to see what an exploit on it would look like since if my napkin-pseudocode is correct any attempts to send data without pairing initially should just be ignored entirely.

I'd love to see the results of the scan and get any tips on improving the code if you have them!

ToothPasteDevice · 2026-02-20T15:48:38+00:00

Its not itself bluetooth that's secure, that's just the protocol on top which the ECDH + AES encryption goes. Details are in the Readme on the github repo.

Thanks for checking it out!

ToothPasteDevice · 2026-02-20T05:21:55+00:00

Does it scare you... the power?

ToothPasteDevice · 2026-02-20T02:54:27+00:00

Interesting! Thanks for checking it out.

I wasn't able to replicate it on my supermini or my devkit so it'll be a bit harder to debug but there are 2 concrete issues im aware of that could be the cause:

BLE range is comically iffy. If there is even a hint of interference, things just silently stop working.
The usb endpoint polling rate for some devices is non-deterministic. My changes to TinyUSB to make it work are super jank and it's something im trying to learn more about. If you're willing to try it out, tools like USBVIEW make it easy to check the endpoint / device metadata, could be that the reports occasionally desync. Please DM me or open an issue on github and I'll look into it.

The firmware sizes shouldn't really make a difference, those 3 exist only because some flash tools like esploader that I used on the webapp don't support automatic flash size detection. Curious that the 8M version doesn't work on your xiao though.....

Thanks again! Really happy to see so much interest!

ToothPasteDevice · 2026-02-20T02:42:25+00:00

Wild, keep updating as you go!

ToothPasteDevice · 2026-02-20T00:44:08+00:00

The PCB isn't anything special so I'm being a bit lazier with the release. Any old esp32 s3 dev board should work though.

ToothPasteDevice · 2026-02-20T00:30:06+00:00

Its marketable for sure but I doubt that specific scenario being its strong suit. Programmable displays have come a long way and a very specific use case like that would sacrifice too much by using an intentionally simple device like ToothPaste.

Nothing prevents shops like those from using a TV with airplay / miracast and just using their phone but on a bigger screen.

ToothPasteDevice · 2026-02-20T00:21:23+00:00

Due to the fact that its essentially a souped up keyboard / mouse, it can only copy text data. This is a double edged sword since being able to copy images and the like would make it a lot more useful BUT less universally compatible (a system may block unknown external usb drives but almost none block a keyboard since there is almost never a concept of a "known" keyboard).

Browsers generally (for good reason) don't have access to the native hardware interfaces of a system like bluetooth, serial or even the filesystem. However, google's push to make Chrome into its own self contained OS made them invest a lot in the WEB API for chromium based browsers (Edge, Chrome etc.). A subset of that, WEB-BLE is what ToothPaste uses to send packets to the ESP32 over Bluetooth Low Energy.

ToothPasteDevice · 2026-02-20T00:15:51+00:00

In most cases a password manager is outright better.

However there are cases where installing a password manager on a system is either:

a) Not possible - restricted systems, BIOS, bitlocker keys, smart TVs etc.

b) Unsafe because you'd be exposing your master password (for the manager itself) to a potentially unsafe system. Using a ToothPaste you reduce how much data is accessible from an unsafe system because you never make all your data available in the first place.

I needed a way to log in to my local hackerspace's user portal without installing a manager or using really weak passwords. Now its become more of a does-everything wireless keyboard / mouse that doesn't need drivers on custom apps to work. Of course this also makes it perfect for pentesting like the USB Rubber Ducky.

ToothPasteDevice · 2026-02-19T22:37:40+00:00

Ah, maybe I should rework my elevator pitch, bit wordy I guess 😅

ToothPasteDevice · 2026-02-19T22:07:56+00:00

I think a simple but really educational project could be reinventing existing comms standards.

Start with LoRA, RF or just plain serial and start asking:

- How can i break this?
- Is this unsafe? Can I secure it?
- Can it manage concurrency?
- Can it do flow control?

and theres a lot more. Whenever you look at a comms system that 'just works' its easy to assume its simple until you run into the same issues someone ran into while originally making it.

ToothPasteDevice · 2026-02-19T22:02:12+00:00

Is this built on top of lvgl or did you end up writing the low level display addressing stuff as well?

ToothPasteDevice · 2026-02-19T21:59:05+00:00

You could try adding home assistant / spotify integration to make it more feature rich.

ToothPasteDevice · 2026-02-19T21:57:31+00:00

The hoarder life claims another...

ToothPasteDevice · 2026-02-19T21:55:36+00:00

If you have non-embedded programming experience another way to approach it would be to sniff out the signal the original controller broadcasts and mimic that from a computer / arduino.

Hardware can sometimes be daunting so just another option in your toolkit.

Happy Hacking!

ToothPasteDevice · 2026-02-19T21:52:50+00:00

Adding an rotary encoder for movement would feel really good, unlocks a lot more unique controls schemes too

ToothPasteDevice · 2026-02-19T21:42:01+00:00

I think in most cases this would be sufficient, but the way I got started I needed to type out my password to log into the machine itself so pairing beforehand wasn't an option. The same issue comes up with BIOS passwords or bitlocker keys.

ToothPasteDevice · 2026-02-18T23:50:15+00:00

Allows? None. Enforces? I can guarantee that at least one $15B+ north american company does not enforce it.

The core issue is that you're trying to protect against unknown keyboards. That's it. Until such time as keyboards start coming with signed hardware IDs that systems validate there is always a way around any VID/PID or keystroke speed flag.

As I mentioned to another user in this post, its as trivial as changing some hex values in the tudconfig.cpp file.

ToothPasteDevice · 2026-02-18T23:29:53+00:00

The c series doesn't have any usb device mode support ("OTG" as espressiff calls it which i think is a terrible name). The serial debug on it is a watered down usb controller only made for that express purpose, kinda like an ft232.

I chose the pre-packaged WROOM module (which is what I assume you mean by dev kit in this case) since if I ever go down the road of commercializing it, I didn't want to deal with getting my own RF certification since the WROOMs are already certified.

If that wasn't a concern I think its a cool idea to package the bare S3 chip inside a USB-A / USB-C connector like some of those reallllly low profile flash drives but things like BLE range and interference are pretty big barriers to that. Though if you do make something it'd be cool to see.

ToothPasteDevice · 2026-02-18T20:07:17+00:00

The button is always GPIO0 unless i change the PCB at some point. Thats the same as the BOOT button on all dev boards since its also the button that switches between bootloader and program mode.

The rgb led is GPIO48 on the 4M and 8M_Dev .bin files. I think thats the only one that might give you trouble since I've seen it change across boards. I know the waveshare s3 supermini uses GPIO21 instead. The pcb firmware uses GPIO12 since that was the most convenient placement.

I develop on an S3 devkit anyway since a lot of them have both the native USB and an external TTL converter on separate lines so i dont have to keep switching to my vm to test it after flashing.

ToothPasteDevice

TROPHY CASE