Hackaday Europe 2024 is on! We’re all here in Berlin, and the talks are about to begin.
If you’re not, you can join us in spirit on our livestream! And if you’re following along, drop comments here.
News3281 Articles
This Week In Security: BatBadBut, DLink, And Your TV Too
So first up, we have BatBadBut, a pun based on the vulnerability being “about batch files and bad, but not the worst.” It’s a weird interaction between how Windows uses cmd.exe to execute batch files and how argument splitting and character escaping normally works. And what is apparently a documentation flaw in the Windows API.
When starting a process, even on Windows, the new executable is handed a set of arguments to parse. In Linux and friends, that is a pre-split list of arguments, the argv array. On Windows, it’s a single string, left up to the program to handle. The convention is to follow the same behavior as Linux, but the cmd.exe binary is a bit different. It uses the carrot ^ symbol instead of the backslash \ to escape special symbols, among other differences. The Rust devs took a look and decided that there are some cases where a given string just can’t be made safe for cmd.exe, and opted to just throw an error when a string met this criteria.
And that brings us to the big questions. Who’s fault is it, and how bad is it? I think there’s some shared blame here. The Microsoft documentation on CreateProcess() strongly suggests that it won’t execute a batch file without cmd.exe being explicitly called. On the other hand, This is established behavior, and scripting languages on Windows have to play the game by Microsoft’s rules. And the possible problem space is fairly narrow: Calling a batch file with untrusted arguments.
Almost all of the languages with this quirk have either released patches or documentation updates about the issue. There is a notable outlier, as the Java language will not receive a fix, not deeming it a vulnerability. It’s rather ironic, given that Java is probably the most likely language to actually find this problem in the wild. Continue reading “This Week In Security: BatBadBut, DLink, And Your TV Too”
The Future Looks Bleak For Alexa Skill Development
While the average Hackaday reader is arguably less likely than most to install a megacorp’s listening device in their home, we know there’s at least some of you out there that have an Amazon hockey puck or two sitting on a shelf. The fact is, they offer some compelling possibilities for DIY automation, even if you do have to jump through a few uncomfortable hoops to bend them to your will.
That being said, we’re willing to bet very few readers have bothered installing more than a few Alexa Skills. But that’s not a judgment based on any kind of nerd stereotype — it’s just that nobody seems to care about them. A fact that’s evidenced by the recent revelation that even Amazon looks to be losing interest in the program. In a post on LinkedIn, Skill developer [Mark Tucker] shared an email he received from the mothership explaining they were ending the AWS Promotional Credits for Alexa (APCA) program on June 30th.
Continue reading “The Future Looks Bleak For Alexa Skill Development”
Hackaday Europe Is Almost Here, Last Call For Tickets
By the time this post hits the front page, we’ll be just a few days away from the kickoff of Hackaday Europe 2024!
For those of you joining us in Berlin this weekend, we’ve got an incredible amount of content planned for you. Things get rolling on Friday with a pre-event meetup. But Saturday is when things really kick into high gear. Before the day’s out, we’ll have played host to nearly a dozen speakers and — literally — more workshops than we could fit into the schedule. Two workshops will be “floating” events that will happen once enough interested parties have congregated in one place. We’ll keep things going until well past midnight, which leads directly into Sunday. We want to get a few sessions of lightning talks packed in, so start coming up with your talk ideas now.
In addition, there will be food, music, camaraderie, badge hacking, and the general technolust surrounding a Hackaday event. In our humble and totally unbiased opinion, we put on some of the best and most unique hardware hacking meetups in the world — if you like reading Hackaday, you’ll love living it for a couple of days.
As of this writing, we still have a very few tickets for Hackaday Europe 2024 available. Want one? Head over to the Eventbrite page. But you better hurry. We’re talking a literal handful here, so don’t be surprised if they’ve dried up by the time you read this.
The workshops have all sold out, but as usual, we’ll be running a waiting list right up until the last minute: should anyone have to drop out of a workshop (which happens more than you might think), their spot will go to the person next in line. If you’d like to get on the list, email prize@hackaday.com with your name, ticket number, and the workshop you’re hoping to sneak into, and we’ll see what we can do.
But don’t let the workshops stop you. There’s still plenty to see, do, and experience. See you there!
Ultimate Power: Lithium-Ion Packs Need Some Extra Circuitry
A LiIon pack might just be exactly what you need for powering a device of yours. Whether it’s a laptop, or a robot, or a custom e-scooter, a CPAP machine, there’s likely a LiIon cell configuration that would work perfectly for your needs. Last time, we talked quite a bit about the parameters you should know about when working with existing LiIon packs or building a new one – configurations, voltage notations, capacity and internal resistance, and things to watch out for if you’re just itching to put some cells together.
Now, you might be at the edge your seat, wondering what kind of configuration do you need? What target voltage would be best for your task? What’s the physical arrangement of the pack that you can afford? What are the safety considerations? And, given those, what kind of electronics do you need?
Picking The Pack Configuration
Pack configurations are well described by XsYp:X serial stages, each stage having Y cells in parallel. It’s important that every stage is the same as all the others in as many parameters as possible – unbalanced stages will bring you trouble.
To get the pack’s nominal voltage, you multiply X (number of stages) by 3.7 V, because this is where your pack will spend most of its time. For example, a 3s pack will have 11.1 V nominal voltage. Check your cell’s datasheet – it tends to have all sorts of nice graphs, so you can calculate the nominal voltage more exactly for the kind of current you’d expect to draw. For instance, the specific cells I use in a device of mine, will spend most of their time at 3.5 V, so I need to adjust my voltage expectations to 10.5 V accordingly if I’m to stack a few of them together.
Now, where do you want to fit your pack? This will determine the voltage. If you want to quickly power a device that expects 12 V, the 10.5 V to 11.1 V of a 3s config should work wonders. If your device detects undervoltage at 10.5V, however, you might want to consider adding one more stage.
How much current do you want to draw? For the cells you are using, open their spec sheet yet again, take the max current draw per cell, derate it by like 50%, and see how many cells you need to add to match your current draw. Then, add parallel cells as needed to get the capacity you desire and fit the physical footprint you’re aiming for. Continue reading “Ultimate Power: Lithium-Ion Packs Need Some Extra Circuitry”
Voyager 1 Issue Tracked Down To Defective Memory Chip
After more than forty-six years all of us are likely to feel the wear of time, and Voyager 1 is no different. Following months of harrowing troubleshooting as the far-flung spacecraft stopped returning sensible data, NASA engineers now feel confident that they have tracked down the cause for the problem: a single defective memory chip. Why this particular chip failed is unknown, but possibilities range from wear and tear to an energetic particle hitting it and disrupting its operation.
We’ve covered the Voyager 1 troubleshooting saga so far, with the initial garbled responses attributed to a range of systems, but narrowed down to the Flight Data Subsystem (FDS), which prepares data for transmission by the telemetry modulation unit (TMU). Based on a recent ‘poke’ command that returned a memory dump engineers concluded that the approximately 3% of corrupted data fit with this one memory chip, opening the possibility of a workaround.
Recently NASA engineers have also been working on patching up the firmware in both Voyager spacecraft, against the background of the dwindling energy produced by the radioisotope generators that have kept both spacecraft powered and warm, even in the cold, dark depths of Deep Space far beyond the light of our Sun.
This Week In Security: XZ, ATT, And Letters Of Marque
The xz backdoor is naturally still the top story of the week. If you need a refresher, see our previous coverage. As expected, some very talented reverse engineers have gone to work on the code, and we have a much better idea of what the injected payload does.
One of the first findings to note is that the backdoor doesn’t allow a user to log in over SSH. Instead, when an SSH request is signed with the right authentication key, one of the certificate fields is decoded and executed via a system() call. And this makes perfect sense. An SSH login leaves an audit trail, while this backdoor is obviously intended to be silent and secret.
It’s interesting to note that this code made use of both autotools macros, and the GNU ifunc, or Indirect FUNCtions. That’s the nifty feature where a binary can include different versions of a function, each optimized for a different processor instruction set. The right version of the function gets called at runtime. Or in this case, the malicious version of that function gets hooked in to execution by a malicious library. Continue reading “This Week In Security: XZ, ATT, And Letters Of Marque”
