It Ain’t Broke, But Should I Fix It?

February 20, 2021 by Elliot Williams 76 Comments

Five years ago, I wrote a series on getting started with your own MQTT-based home information/automation network. Five years is a long while in Hackaday time. Back then, the ESP8266 was a lot newer, and the 8266 Arduino port wasn’t fully in shape yet, and the easiest software framework to get MQTT up and running was NodeMCU; so that’s what I used for the article series, and as a consequence a handful of devices around my house run minor modifications of that basic “hello world”, but doing useful stuff.

Since then, NodeMCU has changed a bunch of its libraries and the ESP32 has replaced the ESP8266 in my parts drawer. If you tried to run my code, you’d find that it won’t run on an ESP8266 without porting or compiling an old version of NodeMCU for yourself anyway, and it won’t run on an ESP32 at all. When [Chris Lott] tried to follow my guide, he discovered that Micropython is probably a better language choice in 2021. To minimize lines of code, I’d agree, although the Arduino and Espressif’s own native IDF have grown into the job just about as well. In short, anything but NodeMCU.

Built in an hour, survived for five years.

But my home automation system doesn’t care. Those little guys are running 24/7, flipping bits like it was still 2016. Thermometers, light sensors, and power meters haven’t changed much in five years, and although I’ve revamped the databasing, display, and user control a number of times since then, using a fixed communication transport protocol means that they’re still talking the same language. Indeed, even if NodeMCU is dead to me, the MQTT content of my original series is all still valid, and installing a broker on a Raspberry Pi has only become easier in the intervening five years.

So I’ve got a bunch of legacy code running within the walls of my own home, and it makes me nervous. If the devices fail, or maybe when they eventually fail, it’s not going to be “just flash another ESP8266 and replace it”, because even though I have some ancient NodeMCU binaries sitting around, I know when to throw in the towel. But there’s no good reason to pull them down and start reflashing either. Except that it makes me a little bit itchy, just knowing that there’s orphaned, dead-end code running all around me. Surrounding me. Staring deep into my hacker’s heart.

I know better than to tear down a running system, even though I could do it one device at a time, and each module would surely be a simple, independent fix; even though I’d love the excuse to play around with Micropython and its MQTT implementation on the ESP8266, or maybe even swap some of them out for ESP32s; even though these were all temporary quick hacks that have somehow served for five (5!) years. I certainly know better, right? (Right?)

Hackaday Podcast 106: Connector Kerfuffle, Tuning Fork Time, Spinach Contact Prints, And Tesla’s Permanent Memory

February 19, 2021 by Mike Szczys 1 Comment

Hackaday editors Elliot Williams and Mike Szczys recount the coolest hacks from the past week. Most clocks keep time with a quartz crystal, but we discuss one that uses a tuning fork… like the kind you use to tune a piano. Ghidra is a powerful reverse engineering tool developed by the NSA that was recently put to good use changing an embedded thermometer display from Celsius to Fahrenheit. We talk turkey on the Texas power grid problems and Tesla’s eMMC failures. And of course there’s some room for nostalgia as we walk down memory lane with the BASIC programming language.

Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Direct download (~60 MB)

Places to follow Hackaday podcasts:

Continue reading “Hackaday Podcast 106: Connector Kerfuffle, Tuning Fork Time, Spinach Contact Prints, And Tesla’s Permanent Memory” →

This Week In Security: ISNs, Patch Tuesday, And Clubhouse

February 19, 2021 by Jonathan Bennett 4 Comments

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” →

James West Began 40 Years At Bell Labs With World-Changing Microphone Tech

February 17, 2021 by Mike Szczys 27 Comments

I’d be surprised if you weren’t sitting within fifty feet of one of James Edward Maceo West’s most well-known inventions — the electret microphone. Although MEMS microphones have seen a dramatic rise as smartphone technology progresses, electret microphones still sit atop the throne of low-cost and high-performance when it comes to capturing audio. What’s surprising about this world-changing invention is that the collaboration with co-inventor Gerhard Sessler began while James West was still at university, with the final version of the electret springing to life at Bell Labs just four years after his graduation.

A Hacker’s Upbringing

James’ approach to learning sounds very familiar: “If I had a screwdriver and a pair of pliers, anything that could be opened was in danger. I had this need to know what was inside.” He mentions a compulsive need to understand how things work, and an inability to move on until he has unlocked that knowledge. Born in 1931, an early brush with mains voltage started him on his journey.

Continue reading “James West Began 40 Years At Bell Labs With World-Changing Microphone Tech” →

Minimal MQTT With Micropython

February 17, 2021 by Chris Lott 16 Comments

I have been meaning to play around with MQTT for some time now, and finally decided to take the plunge one evening last week. I had three cheap home temperature and humidity sensors, and was bothered that they often didn’t agree. Surprisingly, while the analog one had a calibration adjustment in the back, I have no idea how to calibrate the two digital ones. I took this as a sign that it was time to learn MQTT and be able to install my own, accurate sensors. Of course, I began by ordering the cheapest sensors I could find, but I can always upgrade later on.

While we have written quite a bit about MQTT in Hackaday, I had to go all the way back to 2016 to find this introductory four-part series by Elliot Williams. Five years is a long time in the tech world, but I decided to give it a try anyway. Continue reading “Minimal MQTT With Micropython” →

Hackaday Links: February 16, 2021

February 16, 2021 by Dan Maloney 12 Comments

This is it; after a relatively short transit time of eight months, the Mars 2020 mission carrying the Perseverance rover has almost reached the Red Planet. The passage has been pretty calm, but that’s all about to end on Thursday as the Entry Descent and Landing phase begins. The “Seven Minutes of Terror”, which includes a supersonic parachute deployment, machine-vision-assisted landing site navigation, and a “sky-crane” to touch the rover down gently in Jezero crater, will all transpire autonomously 480 million km away. We’ll only learn about how it goes after the eleven-minute propagation delay between Mars and Earth, but we’ll be glued to the NASA YouTube live stream nonetheless. Coverage starts on February 18, 2021 at 11:15 AM Pacific Standard Time (UTC-8). We’ve created a handy time zone converter and countdown so you don’t miss the show.

As amazing as the engineering on display Thursday will be, it looks like the US Navy has plans to unveil technology that will make NASA as relevant as a buggy-whip company was at the turn of the last century. That is, if you believe the “UFO Patents” are for real. The inventor listed on these patents, Dr. Salvatore Pais, apparently really exists; he’s had peer-reviewed papers published in mainstream journals as recently as 2019. Patents listed to Dr. Pais stretch back to 2004, when he invented a laser augmented turbojet propulsion system, which was assigned to defense contractor Northrup Grumman. The rest of the patents are more recent, all seemingly assigned to the US Navy, and cover things like a “high-frequency gravitational wave generator” and a “craft using an inertial mass-reduction device”. There’s also a patent that seems to cover a compact fusion generator. If any of this is remotely true, and we remain highly skeptical, the good news is that maybe we’ll get things like the Epstein Drive. Of course, that didn’t end well for Solomon Epstein. Or for Manéo Jung-Espinoza.

Of course, if you’re going to capitalize on all these alien patents, you’re going to need some funding. If you missed out on the GME short squeeze megabucks, fret not — there’s still plenty of speculative froth to go around. You might want to try your hand at cryptocurrency mining, but with GPUs becoming near-unobtainium, you’ll have to get creative, like throwing together a crypto mining farm with a bunch of laptops. It looks like the Weibo user who posted the photos has laptops propped up on every available surface of their apartment, and there’s also a short video showing a more industrial setup with rack after rack of laptops. These aren’t exactly throw-aways from some grade school, either — they appear to be brand new laptops that retail for like $1,300 a pop. The ironic part is that the miner says this is better than the sweatshop he used to work in. Pretty sure with all that power being dissipated in his house, it’ll still be a sweatshop come summer.

A lot of people have recently learned the hard lesson that when the service is free, you’re the product, and that what Google giveth, Google can taketh away in a heartbeat, and for no discernable reason. Indie game studio Re-Logic and its lead developer Andrew Spinks found that out last week when a vaguely worded terms-of-service violation notice arrived from Google. The developer of the popular game Terraria was at a loss to understand the TOS violation, which resulted in a loss of access to all the company’s Google services. He spent three weeks going down the hell hole of Google’s automated support system, getting nothing but canned messages that were either irrelevant to his case or technically impossible; kinda hard to check your Gmail account when Google has shut it down. The lesson here is that building a business around services that can be taken away on a whim is perhaps not the best business plan.

And finally, we watched with great interest Big Clive’s secrets to getting those crisp, clean macro shots that he uses to reverse-engineer PCBs. We’ve always wondered how he accomplished that, and figured it involved some fancy ring-lights around the camera lens or a specialized lightbox. Either way, we figured Clive had to plow a bunch of that sweet YouTube cash into the setup, but we were surprised to learn that in true hacker fashion, it’s really just a translucent food container ringed with an LED strip, with a hole cut in the top for his cellphone camera. It may be simple, but you can’t argue with the results.

Continue reading “Hackaday Links: February 16, 2021” →

Signal Conditioning Hack Chat This Wednesday

February 15, 2021 by Dan Maloney 4 Comments

Join us on Wednesday, February 17 at noon Pacific for the Signal Conditioning Hack Chat with Jonathan Foote!

The real world is a messy place, because very little in it stays in a static state for very long. Things are always moving, vibrating, heating up or cooling down, speeding up or slowing down, or even changing in ways that defy easy description. But these changes describe the world, and understanding and controlling these changes requires sensors that can translate them into usable signals — “usable” being the key term.

Making a signal work for you usually requires some kind of signal processing — perhaps an amplifier to boost a weak signal from a strain gauge, or a driver for a thermocouple. Whatever the case, pulling a useful signal that represents a real-world process from the background noise of all the other signals going on around it can be challenging, as can engineering systems that can do the job in sometimes harsh environments. Drivers, filters, amplifiers, and transmitters must all work together to get the clearest picture of what’s going on in a system, lest bad data lead to bad decisions.

To help us understand the world of signal conditioning, Jonathan Foote will drop by the Hack Chat. You may remember Jonathan as the “recovering scientist” who did a great Remoticon talk on virtual modular synthesizers. It turns out that synths are just a sideline for Dr. Foote, who has a Ph.D. in Electrical Engineering and a ton of academic experience. He’s a bit of a Rennaissance man when it comes to areas of interest — machine learning, audio analysis, robotics, and of course, signal processing. He’ll share some insights on how to pull signals from the real world and put them to work.

Our Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, February 17 at 12:00 PM Pacific time. If time zones have you tied up, we have a handy time zone converter.

Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.

Continue reading “Signal Conditioning Hack Chat This Wednesday” →