When it comes to keeping in touch with the grandparents, a lack of familiarity with modern technology can get in the way. [palmerabollo] wanted to share photos with his grandmother, but found that it was difficult as she didn’t have a smartphone or an Internet connection to receive photos. Thus, a custom build for grandma was in order! (translated)
To minimise maintenance requirements, the build relies on a thermal receipt printer. Each roll of thermal paper is good for printing off about 150 images before needing a change, so it’s a low-cost, fuss-free solution with no need for ink changeovers.
A Raspberry Pi Zero 2W runs the show, paired with a HAT that provides cellular internet connectivity. Photos are sent over Telegram with some custom Python code that [palmerabollo] put together. The system uses the Python “thermalprinter” library, with the Floyd-Steinberg dithering algorithm baked in allowing nice quality even on the simple thermal printer.
It’s a fun build, and lets [palmerabollo] send his grandmother fun photos and messages without requiring any effort on her part. It’s super cute to see the photos stuck up on the refrigerator, too.
There’s plenty of fun to be had with thermal printers, so don’t be afraid to get stuck in yourself! Video after the break. Continue reading “Sending Pics To Grandma, No Smartphone Needed”
Let’s talk TCP. Specifically, how do the different TCP connections stay distinct, and how is a third party kept from interrupting a connection? One of the mechanisms that help accomplish this feat is the TCP sequence number. Each of the two endpoints of a TCP connection tracks an incrementing 32-bit number, corresponding to the bytes sent in the connection. It’s handy, because each side can use that value to track what parts of the data stream they have received. On missing packets, a message can be sent requesting bytes 7-15 to be resent, for instance.
Each side of the connection sets their own Initial Sequence Number (ISN), and it’s important that this number is unique, as collisions can cause stream confusion. That statement should make your security spidey sense tingle. If a collision can cause problems when it happens by chance, what can a hacker do with it intentionally? Potentially quite a bit. Knowing the current sequence number, as well as a couple other pieces of information, a third party can close a TCP stream or even inject data. The attack has been around for years, originally known as the Mitnick Attack. It was originally possible because TCP implementations used a simple counter to set the ISN. Once the security ramifications of this approach were understood, the major implementations moved to a random number generation for their ISNs.
Now to this week’s story: researchers at Forescout took the time to check 11 TCP/IP stacks for vulnerability to the old Mitnick Attack (PDF Whitepaper). Of the eleven embedded stacks texted, nine have serious weaknesses in their ISN generation. Most of the vulnerable implementations use a system time value as their ISN, while several use a predictable pseudorandom algorithm that can be easily reversed.
CVEs have been assigned, and vendors notified of “NUMBER:JACK”, Forescout’s name for the research. Most of the vulnerable software already has patches available. The problem with embedded systems is that they often never get security updates. The vulnerable network stacks are in devices like IP cameras, printers, and other “invisible” software. Time will tell if this attack shows up as part of a future IoT botnet.
Continue reading “This Week In Security: ISNs, Patch Tuesday, And Clubhouse”
You may have been one of the many of us who received an email from Ubiquiti this week, recommending a password change. The email stated that there was an unauthorized access of Ubiquiti systems, and while there wasn’t evidence of user data being accessed, there was also not enough evidence to say emphatically that user data was not accessed. Ubiquiti has mentioned that the database that may have been accessed contains a user’s name, email address, hashed password, and optionally the mailing address and phone number.
Depending on how the Ubiquiti authentication system is designed, that hashed password may be enough to log in to someone’s account. In any case, updating your password would invalidate the potentially compromised hash. This event underscores a complaint voiced by Ubiquiti users: Ubiquiti has been making it difficult to administrate hardware without a cloud-enabled account. Continue reading “This Week In Security: Ubiquiti, Nissan, Zyxel, And Dovecot”
Everything has to be smart these days, and while smartening things up is a good incentive to tip your own toes into the whole IoT field, many of these undertakings are oftentimes just solutions looking for a problem. Best case, however, you actually make someone’s life easier with it, or help a person in need. For [Guli Morad] and [Dekel Binyamin], it was a bit of both when they built their automated pill dispenser: help people dependent on taking medication, and ease the mind of those worrying whether they actually remembered to.
Using an ESP8266 and a rather simple construct comprised of a set of servos with plastic sheets attached, and a plastic tube with strategically placed cuts for each pill type, a predefined amount of each of the pills can be automatically dispensed into a box — either at a given time, or on demand — using a Node-RED web interface. A reed switch mounted on the box then monitors if it was actually opened within a set time, and if not, informs emergency contacts about it through the Telegram app. Sure, a tenacious medication recipient might easily fool the system, but not even adding a precision scale to make sure the pills are actually taken out could counter a pill-reluctant patient of such kind, so it’s safe to assume that this is primarily about preventing simple forgetfulness.
Their proof of concept is currently limited to only two different types of pills, but with enough PWM outputs to control the servos, this should be easily scalable to any amount. And while the built may not be as sophisticated as some pill dispensers we’ve seen entering the Hackaday Prize a few years back, it still gets its main task done. Plus, when it comes to people’s health, a good-enough solution is always better than a perfect idea that remains unimplemented.
Continue reading “Did Grandma Remember Her Pills? This Dispenser Tells You!”
There’s a huge market for 433 MHz alarm system hardware out there, from PIR motion detectors to door and window sensors. If you want to put them to work, all you need is a receiver, a network-enabled microcontroller, and some code. In his latest video, [Aaron Christophel] shows how easy it can be.
In essence, you connect a common 433 MHz receiver module to an ESP32 or ESP8266 microcontroller, and have it wait until a specific device squawks out. From there, the code on the ESP can fire off using whatever API works for your purposes. In this case [Aaron] is using the Telegram API to send out messages that will pop up with a notification on his phone when a door or window is opened. But you could just as easily use something like MQTT, or if you want to go old-school, have it toggle a relay hooked up to a loud siren.
Even if you aren’t looking to make your own makeshift alarm system, the code and video after the break are a great example to follow if you want to get started with 433 MHz hardware. Specifically, [Aaron] walks the viewer through the process of scanning for new 433 MHz devices and adding their unique IDs to the list the code will listen out for. If you ever wondered how quickly you could get up and running with this stuff, now you’ve got your answer.
In the past we’ve seen the Raspberry Pi fill in as an RF to WiFi gateway for these type of sensors, as well as projects that pulled them all together into a complete home automation system on the cheap.
Continue reading “DIY ESP32 Alarm System Leverages 433 MHz Sensors”
Like many of us, [Zak Kemble] has an indeterminate number of tiny packages coming his way from all over the globe at any given time. Unfortunately, the somewhat unpredictable nature of the postal service where he lives meant he found himself making a lot of wasted trips out to the mailbox to see if any overseas treasures had arrived for him. To solve the problem, he decided to build an Internet-connected mailbox notification system that could work within some fairly specific parameters.
For one thing, the mailbox is too distant to connect directly to it over WiFi. [Zak] mentions that 433 MHz might have been an option, but he decided to skip that entirely and just connect it to the cellular network with an A9G GPRS/GSM module from A.I. Thinker. This device actually has its own SDK that allows you to create a custom firmware for it, but unfortunately the high energy consumption of the radio meant it would chew through batteries too quickly unless it had a little extra help.
Not wanting to have to change the batteries every couple months, [Zak] added a ATtiny402 to handle the notifier’s power management needs. By using a P-MOSFET to completely cut power to the A9G, the notifier can save an incredible amount of energy by only activating the cellular connection once it actually needs to send a notification; which in this case takes the form of an HTTP request that eventually works its way to a Telegram group chat.
To cut a long story short, testing seems to indicate that the notifier can fire off approximately 800 requests before needing its 10440 lithium battery recharged. Given how often [Zak] usually receives mail, he says that should last him around five years.
The A9G module, the ATtiny402, a BME280 environmental sensor (because, why not?), the battery, and all the ancillary support hardware are on a very professional looking PCB. That goes into a relatively rugged enclosure that’s designed to keep the electronics from shorting out on the mailbox’s metal case as well as keeping any particularly weighty parcels from crushing it.
If you’ve got the freedom so mount whatever you want outside, then you can certainly build a more technically impressive mailbox. But considering the limitations [Zak] had to work around, we think he did an excellent job.
Never underestimate the quick and dirty hack. It’s very satisfying to rapidly solve a real problem with whatever you have on hand, and helps to keep your hacking skills sharp for those big beautifully engineered projects. [Guillaume M] needed a way to remotely open his apartment building door for deliveries, so he hacked the ancient intercom to be operated via Telegram, to allow packages to be deposited safely inside his mailbox inside the building’s front too.
[Guillaume] needed to complete the hack in a way that would allow him to return the intercom to its original state when he moves out. Opening the 30-year-old unit, he probed a row of screw terminals and identified a 13V supply, ground, and the connection to the buildings’ door lock. He connected the lock terminals to a relay, which is controlled by a Raspberry Pi Zero W that waits for the “open” command to be sent to a custom Telegram Bot.
To power the Pi, [Guillaume] connected it to the 13V supply on the intercom via a voltage divider circuit. Voltage dividers usually make lousy power supplies, since the output voltage will fluctuate as the load changes, but it looks as though it worked well enough for [Guillaume]. The intercom had a lot of empty space inside, so after testing everything was packed inside the housing.
If you want to achieve the same with an ESP8266, there’s a library for that. Just keep in mind that being dependent on web servers to open critical doors might get you locked out.