One Project At A Time, Or A Dozen?

We got a bunch of great food for thought in this week’s ask-us-anything on the Hackaday Podcast, and we all chewed happily. Some of my favorite answers came out of the question about how many projects we all take on at once. Without an exception, the answer was “many”. And while not every one of the projects that we currently have started will eventually reach the finish line, that’s entirely different from saying that none of them ever do. On the contrary, Tom Nardi made the case for having a number of irons simultaneously in the fire.

We all get stuck from time to time. That’s just the nature of the beast. The question is whether you knuckle down and try to brute-force power your way through the difficulty, or whether you work around it. A lot of the time, and this was Dan Maloney’s biggest bugaboo, you lack the particular part or component that you had in mind to get the job done. In that situation, sometimes you just have to wait. And what are you going to do while waiting? Work on Project B! (But take good notes of the state of Project A, because that makes it a lot easier to get back into the swing of things when the parts do arrive.)

Al and I both weighed in on the side of necessity, though. Sometimes, no matter how many attractive other projects you’ve got piled up, one just needs to get out the door first. My recent example was our coffee roaster. Before I start a big overhaul, I usually roast a couple days’ worth of the evil bean. And then the clock starts ticking. No roasting equals two unhappy adults in this household, so it’s really not an option. Time pressure like that helps focus the mind on the top-priority project.

But I’m also with Tom. It’s a tremendous luxury to have a handful of projects in process, and be able to hack on one simply because you’re inspired, or in love with the project at that moment. And when the muse calls, the parts arrive, or you finally figure out what was blocking you on Project A, then you can always get back to it.

Better Living Through Biomedical Engineering

We don’t often think of medicine and engineering as being related concepts, and most of the time, they aren’t. But there’s a point where medicine alone may not be enough to treat a particular ailment or injury, and it might be necessary to blend the mechanical with the biological. When a limb is lost, we don’t have the technology to regrow it, but we can apply engineering principles to build a functional facsimile that can help the patient regain lost independence and improve their quality of life.

The area where these two disciplines overlap is called biomedical engineering (BME), and it’s a field that’s seeing fantastic growth thanks to advances in 3D printing, materials science, and machine learning. It’s also a field where open source principles and DIY are making surprising inroads, as hobbyists look to put their own knowledge and experience to use by creating low-cost assistive devices — something we were honored to help facilitate over the years through the Hackaday Prize.

Continue reading “Better Living Through Biomedical Engineering”

Hackaday Podcast Episode 256: 0, 256, 400, 0x100, And 10000000

For this week’s episode, we did something super special — we all convened to answer your burning questions about your hosts, both as hackers and as humans. We kick things off with a segment featuring a hearty round-table discussion between Elliot, Al, Dan, Kristina, and Tom. What’s on our benches? What do we type on? Go find out!

None of us figured out What’s That Sound though a few of us had some creative guesses. Can you guess the sound? There could be a t-shirt in it for ya.

Kristina and Elliot went on to have a normal podcast too, but since the round table section went so long, we’ll process up that section and put it out early next week.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Download this epic monument of podcasting and savor it for the next 256 weeks.

This Week In Security: Broken Shims, LassPass, And Toothbrushes?

Linux has a shim problem. Which naturally leads to a reasonable question: What’s a shim, and why do we need it? The answer: Making Linux work wit Secure Boot, and an unintended quirk of the GPLv3.

Secure Boot is the verification scheme in modern machines that guarantees that only a trusted OS can boot. When Secure Boot was first introduced, many Linux fans suggested it was little more than an attempt to keep Linux distros off of consumer’s machines. That fear seems to have been unwarranted, as Microsoft has dutifully kept the Linux Shim signed, so we can all run Linux distros on our Secure Boot machines.

So the shim. It’s essentially a first-stage bootloader, that can boot a signed GRUB2 or other target. You might ask, why can’t we just ask Microsoft to sign GRUB2 directly? And that’s where the GPLv3 comes in. That license has an “anti-tivoization” section, which specifies “Installation Information” as part of what must be provided as part of GPLv3 compliance. And Microsoft’s legal team understands that requirement to apply to even this signing process. And it would totally defeat the point of Secure Boot to release the keys, so no GPLv3 code gets signed. Instead, we get the shim.

Now that we understand the shim, let’s cover how it’s broken. The most serious vulnerability is a buffer overflow in the HTTP file transfer code. The buffer is allocated based on the size in the HTTP header, but a malicious HTTP server can set that value incorrectly, and the shim code would happily write the real HTTP contents past the end of that buffer, leading to arbitrary code execution. You might ask, why in the world does the shim have HTTP code in it at all? The simple answer is to support UEFI HTTP Boot, a replacement for PXE boot.

The good news is that this vulnerability can only be triggered when using HTTP boot, and only by connecting to a malicious server or via a man-in-the-middle attack. With this in mind, it’s odd that this vulnerability is rated a 9.8. Specifically, it seems incorrect that this bug is rated low complexity, or a general network attack vector. In Red Hat’s own write-up of the vulnerability, they argue that the exploitation is high complexity, and is only possible from an adjacent network. There were a handful of lesser vulnerabilities found, and these were all fixed with shim 15.8. Continue reading “This Week In Security: Broken Shims, LassPass, And Toothbrushes?”

The End Of Landlines?

Imagine if, somehow, telephones of all kinds had not been invented. Then, this morning, someone entered a big corporation board room and said, “We’d like to string copper wire to every home and business in the country. We’ll get easements and put the wires on poles mostly. But some of them will go underground where we will dig tunnels. Oh, and we will do it in other countries, too, and connect them with giant undersea cables!” We imagine that executive would be looking for a job by lunchtime. Yet, we built that exact system and with far less tech than we have today. But cell phones have replaced the need for copper wire to go everywhere, and now AT&T is petitioning California to let them off the hook — no pun intended — for servicing landlines.

The use of cell phones has dramatically decreased the demand for the POTS or plain old telephone service. Even if you have wired service now, it is more likely fiber optic or, at least, an IP-based network connection that can handle VOIP.

Continue reading “The End Of Landlines?”

FLOSS Weekly Episode 769: OpenCost — We Spent How Much?

This week Jonathan Bennett and Katherine Druckman talk with Matt Ray about OpenCost. What exactly is Cloud Native? Why do we need a project just for tracking expenses? Doesn’t the cloud make everything cheaper? Is there a use case for the hobbyist?

The cloud is just a fancy way to talk about someone else’s servers — and what may surprise you is that they charge you money for the privilege of using those computers. But how much? And when you have multiple projects, which ones cost how much? That’s where OpenCost comes in. Not only does it help you track down costs in your cloud usage, it can also catch problems like compromised infrastructure sooner. Mining bitcoin in your Kubernetes Cluster makes a really noticeable spike in processor usage after all.
Continue reading “FLOSS Weekly Episode 769: OpenCost — We Spent How Much?”

Friendly Flexible Circuits: The Cables

Flexible cables and flex PCBs are wonderful. You could choose to carefully make a cable bundle out of ten wires and try to squish them to have a thin footprint – or you could put an FFC connector onto your board and save yourself a world of trouble. If you want to have a lot of components within a cramped non-flat area, you could carefully design a multitude of stuff FR4 boards and connect them together – or you could make an FPC.

Flexible cables in particular can be pretty wonderful for all sorts of moving parts. They transfer power and data to the scanner head in your flat-bed scanner, for instance.  But they’re in fixed parts too.  If you have a laptop or a widescreen TV, chances are, there’s an flexible cable connecting the motherboard with one or multiple daughterboards – or even a custom-made flexible PCB. Remember all the cool keypad and phones we used to have, the ones that would have the keyboard fold out or slide out, or even folding Nokia phones that had two screens and did cool things with those? All thanks to flexible circuits! Let’s learn a little more about what we’re working with here.

FFC and FPC, how are these two different? FFC (Flexible Flat Cable) is a pre-made cable. You’ve typically seen them as white plastic cables with blue pieces on both ends, they’re found in a large number of devices that you could disassemble, and many things use them, like the Raspberry Pi Camera. They are pretty simple to produce – all in all, they’re just flat straight conductors packaged nicely into a very thin cable, and that’s why you can buy them pre-made in tons of different pin pitches and sizes. If you need one board to interface with another board, putting an FFC connector on your board is a pretty good idea.

Continue reading “Friendly Flexible Circuits: The Cables”