Get ready to rock around the Christmas tree!
davy wybiral
(exploratory programming and more)
Thursday, December 5, 2019
Interactive (Touch) Musical Christmas Tree
In this video I should how to build a capacitive touch Christmas tree that allows you to play music just by touching the ornaments. All it takes is a little bit of Python code, a Raspberry Pi, and a Bare Conductive Pi Cap.
Get ready to rock around the Christmas tree!
Get ready to rock around the Christmas tree!
Friday, November 22, 2019
ESPlay Micro: Open Source ESP32 Game Console
Today we'll take a look at the ESPlay Micro, an open source game console built around the ESP32 WROVER SoC. Aside from being a lightweight game console for retro emulation these boards also make for a great development platform to learn low level systems programming. The hardware and software are both open source and pretty straightforward.
PS: these would make for an awesome Christmas present for anyone into gaming or making.
Makerfabs: https://www.makerfabs.com/esplay-micro.html
Source code: https://github.com/pebri86/esplay-retro-emulation
Hardware: https://github.com/pebri86/esplay_micro_hardware
Hackaday: https://hackaday.io/project/166707-esplay-micro
Instructables: https://www.instructables.com/id/ESPlay-Micro-Retro-Game-Console-MicroPython/
PS: these would make for an awesome Christmas present for anyone into gaming or making.
Makerfabs: https://www.makerfabs.com/esplay-micro.html
Source code: https://github.com/pebri86/esplay-retro-emulation
Hardware: https://github.com/pebri86/esplay_micro_hardware
Hackaday: https://hackaday.io/project/166707-esplay-micro
Instructables: https://www.instructables.com/id/ESPlay-Micro-Retro-Game-Console-MicroPython/
Saturday, November 9, 2019
Testing 4 Raspberry Pi Gaming Platforms
I've been looking to update my home media center recently and decided to survey the landscape of Raspberry Pi gaming/media platforms. This video compares the four best ones I've been able to find which are: RetroPie, Recalbox, Lakka, and Steamlink.
Friday, May 31, 2019
Always Secure Your localhost Servers
Recently I was surprised to learn that web browsers allow any site you visit to make requests to resources on localhost (and that they will happily allow unreported mixed-content). If you'd like to test this out, run an HTTP server on port 8080 (for instance with python -m http.server 8080) and then visit this page.
You should see "Found: HTTP (8080)" listed and that's because the Javascript on that page made an HTTP GET request to your local server to determine that it was running. Chances are it detected other services as well (for instance if you run Tor or Keybase locally).
There are two implications from this that follow:
For instance, at one point Redis was vulnerable to these types of attacks because its protocol is text-over-TCP (just like HTTP) so any web page you visit could craft an HTTP POST request that mimics normal Redis commands. There's an excellent write-up on this vulnerability here (which has since been fixed).
Similarly, if you run the popular gaming platform Steam on Linux, at the time of writing this the main application opens a TCP listener on port 57343. I have no idea what that port is for but I do know that visiting this web page while Steam is open will cause the entire UI to freeze, as well as most games, until the tab is closed: [WARNING: don't blame me if it crashes your game] https://wybiral.github.io/steam-block/
This works because the favicon on that page is actually an HTTP GET request to the TCP server which never closes, thus blocking their listener. It may even be possible to attack the server in other ways with specifically crafted requests (I was able to crash the application using a large enough payload).
These types of vulnerabilities are widespread mostly because application developers assume that the server will only be locally-accessible and not available to every website the user visits. Hopefully this is enough proof to justify why better security measures need to be taken with local servers even if you don't intend to forward the ports you're using to the outside world.
So, as developers what can we do to prevent this kind of attack?
For HTTP and WebSocket servers you can add authentication, CSRF protection, and restrict access based on the page origin (which browsers should include in the request headers).
For TCP servers it could be harder depending on your application. You can detect HTTP-like request headers and block the connection (this seems to be what Redis is doing now). Or require some sort of handshake/authentication that the browser won't perform and reject connections based on that.
As far as preventing fingerprinting and service discovery this way... I'm not entirely sure what the best way to prevent this would be other than ungracefully failing the requests (which a lot of HTTP frameworks probably don't make easy). If anyone has any ideas here feel free to drop me a tweet @davywtf.
You should see "Found: HTTP (8080)" listed and that's because the Javascript on that page made an HTTP GET request to your local server to determine that it was running. Chances are it detected other services as well (for instance if you run Tor or Keybase locally).
There are two implications from this that follow:
- Website owners could potentially use this to collect information about what popular services are running on your local network.
- Malicious actors could use this to exploit vulnerabilities in those services.
For instance, at one point Redis was vulnerable to these types of attacks because its protocol is text-over-TCP (just like HTTP) so any web page you visit could craft an HTTP POST request that mimics normal Redis commands. There's an excellent write-up on this vulnerability here (which has since been fixed).
Similarly, if you run the popular gaming platform Steam on Linux, at the time of writing this the main application opens a TCP listener on port 57343. I have no idea what that port is for but I do know that visiting this web page while Steam is open will cause the entire UI to freeze, as well as most games, until the tab is closed: [WARNING: don't blame me if it crashes your game] https://wybiral.github.io/steam-block/
This works because the favicon on that page is actually an HTTP GET request to the TCP server which never closes, thus blocking their listener. It may even be possible to attack the server in other ways with specifically crafted requests (I was able to crash the application using a large enough payload).
These types of vulnerabilities are widespread mostly because application developers assume that the server will only be locally-accessible and not available to every website the user visits. Hopefully this is enough proof to justify why better security measures need to be taken with local servers even if you don't intend to forward the ports you're using to the outside world.
So, as developers what can we do to prevent this kind of attack?
For HTTP and WebSocket servers you can add authentication, CSRF protection, and restrict access based on the page origin (which browsers should include in the request headers).
For TCP servers it could be harder depending on your application. You can detect HTTP-like request headers and block the connection (this seems to be what Redis is doing now). Or require some sort of handshake/authentication that the browser won't perform and reject connections based on that.
As far as preventing fingerprinting and service discovery this way... I'm not entirely sure what the best way to prevent this would be other than ungracefully failing the requests (which a lot of HTTP frameworks probably don't make easy). If anyone has any ideas here feel free to drop me a tweet @davywtf.
Saturday, March 30, 2019
Arduino-friendly 240x320 LCD Display Tutorial (ILI9341)
Have you ever needed to add a UI to any of your embedded projects? For instance, maybe you want to display a sensor reading graph or build your own handheld gaming system. In this video I'll take a look at some cheap 240x320 color LCD display devices that you can add to almost any microcontroller or Single Board Computer project.
Friday, February 1, 2019
Nordic nRF52840-Dongle (2.4GHz RF Development Board)
Recently I've gotten into low-power RF technology and have become quite the fan of the nRF52 SoC for that reason. Of all the BLE-capable chips I've used so far these ones reign supreme in terms of functionality and ultra-low power consumption.
One of the more interesting boards I've seen powered by them is the nRF52840 dongle, directly from Nordic Semiconductor. It's tiny, well constructed, and supports a very nice set of specs:
In this video I introduce the Nordic nRF SDK for programming these dongles:
One of the more interesting boards I've seen powered by them is the nRF52840 dongle, directly from Nordic Semiconductor. It's tiny, well constructed, and supports a very nice set of specs:
- 64 MHz Cortex-M4F
- 1 MB Flash
- 256 KB RAM
- 2.4 GHz Transceiver (supports Bluetooth 5 with long range)
In this video I introduce the Nordic nRF SDK for programming these dongles:
Sunday, January 13, 2019
Exploring Sub-GHz Radio With RTL-SDR and GQRX
Today I took a look at some hardware for working with sub-GHz radio transmissions, especially FM. All of which came in a previous HackerBoxes box. My favorite item was definitely the RTL-SDR dongle! I could play around with this thing for hours surfing the radio waves and listening to weird broadcasts. There's even a Python library named pyrtlsdr for working with these devices so you can scan/record radio transmissions programmatically: https://github.com/roger-/pyrtlsdr
Next I'm going to solder together the FM transceivers included in the box and play around with writing Arduino firmware for them. Those things should work similar to the LoRa modules I've been using but they trade in the long range for increased bandwidth. Should be good for streaming data locally and still have much better range than most home WiFi or Bluetooth.
Here's a video overview of the hardware included in HackerBox 0034 as well as a demo of the RTL-SDR dongle using GQRX to visually and audibly explore the radio waves.
The audio in my videos has also improved a bit since being sent this Purple Panda lapel microphone. If you do any audio recording with your laptop or phone this little mic is cheap and it definitely improves the quality over a builtin mic. [Not a sponsor, they did send this for free but it's also only $20. I really needed a mic.]
Next I'm going to solder together the FM transceivers included in the box and play around with writing Arduino firmware for them. Those things should work similar to the LoRa modules I've been using but they trade in the long range for increased bandwidth. Should be good for streaming data locally and still have much better range than most home WiFi or Bluetooth.
Here's a video overview of the hardware included in HackerBox 0034 as well as a demo of the RTL-SDR dongle using GQRX to visually and audibly explore the radio waves.
The audio in my videos has also improved a bit since being sent this Purple Panda lapel microphone. If you do any audio recording with your laptop or phone this little mic is cheap and it definitely improves the quality over a builtin mic. [Not a sponsor, they did send this for free but it's also only $20. I really needed a mic.]
Sunday, December 16, 2018
Nordic Thingy:52 Dev Kit (First impression)
Today I'm playing around with a Nordic Thingy:52 Bluetooth 5 development kit from Nordic Semiconductor.
Monday, December 10, 2018
Build your own IoT Device Hub | Bluetooth | LoRaWAN | Tutorial
In this video I show how easy it is to build an Internet of Things device hub using only a Pixl.js and a little bit of Javascript code. To demonstrate I control a few devices using Bluetooth Low Energy and LoRa (Long Range radio).
Saturday, December 1, 2018
Getting Started with GPS Modules | Tracking Device | Tutorial
Today I took a GPS module and a microcontroller for a walk in the park and wrote a few lines of code to show my GPS coordinates in real-time.
Saturday, November 24, 2018
Concurrency on the Internet of Things (Arduino, MicroPython, Espruino)
In this presentation I talk about what concurrency actually is, why it matters for Internet of Things applications, and which platforms are best at handling it.
Friday, October 19, 2018
Experimenting with Electric Paint
Just recently I got my hands on some electrically conductive paint and decided to put it to the test. It functions well for creating resistive elements like custom potentiometers, and also seems to work really well for capacitive touch elements. At the end of the video I painted a small patch of it on the side of my monitor to add a touch button that can be programmed using a small Python script (included in the video description).
Anyway, here it is:
Anyway, here it is:
Friday, October 12, 2018
LoRa IoT Network Programming | RYLR896
Hey everyone, so I just got some LoRa modules from REYAX to experiment with long range network applications and these things are so cool! So far I've made a long range security alarm, a button to water plants on the other side of my property, and some bridge code to interact with IP and BLE networks.
Just thought I'd do a quick video update on this stuff:
Just thought I'd do a quick video update on this stuff:
The module I wrote is part of the Espruino collection now: https://www.espruino.com/RYLR
I got these LoRa devices from REYAX: https://reyax.com/products/rylr896/
They seem to only sell them on e-bay right now: RYLR896
I got these LoRa devices from REYAX: https://reyax.com/products/rylr896/
They seem to only sell them on e-bay right now: RYLR896
Subscribe to:
Posts (Atom)