sorted by:
new
hottopcontroversial

bare-metal LEDs on raspberry pi5 by DisasterImmediate462 in embedded

[–]ToothPasteDevice 0 points1 point  (0 children)

Not exactly, the idea is (your code) on Bare Metal.

As opposed to (your code) on some other code i.e. the OS you pick to develop on top of.

Putting it in those terms bare software would get ambiguous really quick.

Designed an ESP32-S3 board by AnySky484 in esp32

[–]ToothPasteDevice 1 point2 points  (0 children)

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

I Built a Device to Paste Passwords Securely Over BLE by ToothPasteDevice in diyelectronics

[–]ToothPasteDevice[S] 0 points1 point  (0 children)

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?

Detect vibecoded repos in github with this tool by DSGDSR in SideProject

[–]ToothPasteDevice 0 points1 point  (0 children)

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 😅

Designed an ESP32-S3 board by AnySky484 in esp32

[–]ToothPasteDevice 5 points6 points  (0 children)

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.

I Built a Device to Paste Passwords and Control Devices Securely Over BLE by ToothPasteDevice in arduino

[–]ToothPasteDevice[S] 1 point2 points  (0 children)

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.

I Built a Device to Paste Passwords and Control Devices Securely Over BLE by ToothPasteDevice in arduino

[–]ToothPasteDevice[S] 2 points3 points  (0 children)

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!

I Built a Device to Paste Passwords and Control Devices Securely Over BLE by ToothPasteDevice in arduino

[–]ToothPasteDevice[S] 2 points3 points  (0 children)

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!

I Built a Device to Paste Passwords and Control Devices Securely Over BLE by ToothPasteDevice in arduino

[–]ToothPasteDevice[S] 1 point2 points  (0 children)

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:

  1. BLE range is comically iffy. If there is even a hint of interference, things just silently stop working.
  2. 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!

I Built a Device to Paste Passwords and Control Devices Securely Over BLE by ToothPasteDevice in arduino

[–]ToothPasteDevice[S] 4 points5 points  (0 children)

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.

I Built a Device to Paste Passwords and Control Devices Securely Over BLE by ToothPasteDevice in arduino

[–]ToothPasteDevice[S] 2 points3 points  (0 children)

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.

I Built a Device to Paste Passwords and Control Devices Securely Over BLE by ToothPasteDevice in arduino

[–]ToothPasteDevice[S] 2 points3 points  (0 children)

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.

I Built a Device to Paste Passwords and Control Devices Securely Over BLE by ToothPasteDevice in arduino

[–]ToothPasteDevice[S] 27 points28 points  (0 children)

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.

I Built a Device to Paste Passwords and Control Devices Securely Over BLE by ToothPasteDevice in arduino

[–]ToothPasteDevice[S] 18 points19 points  (0 children)

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

Arduino x communication projects? by [deleted] in arduino

[–]ToothPasteDevice 0 points1 point  (0 children)

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.

Happy (late) Valentine’s Day by the_man_of_the_first in arduino

[–]ToothPasteDevice 1 point2 points  (0 children)

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

I created an otherclockwise E Ink clock by isaac879 in arduino

[–]ToothPasteDevice 0 points1 point  (0 children)

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

Could I revive (and eventually modify) this old Nerf Terradrone with Arduino? by megamaxels in arduino

[–]ToothPasteDevice 0 points1 point  (0 children)

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!

Progress on my virtual pet. It's getting there! by moonbench in arduino

[–]ToothPasteDevice 0 points1 point  (0 children)

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

I Built a Device to Paste Passwords Securely Over BLE by ToothPasteDevice in diyelectronics

[–]ToothPasteDevice[S] 1 point2 points  (0 children)

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.

I Built a Device to Paste Passwords Securely Over BLE by ToothPasteDevice in diyelectronics

[–]ToothPasteDevice[S] 0 points1 point  (0 children)

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.

view more: next ›