Hackaday Links: August 23, 2020

August 23, 2020 by Dan Maloney 14 Comments

Apple, the world’s first trillion-dollar company — give or take a trillion — has built a bit of libertarian cachet by famously refusing to build backdoors into their phones, despite the entreaties of the federal government. So it came as a bit of a surprise when we read that the company may have worked with federal agents to build an “enhanced” iPod. David Shayer says that he was one of three people in Apple who knew about the 2005 program, which was at the behest of the US Department of Energy. Shayer says that engineers from defense contractor Bechtel, seemed to want to add sensors to the first-generation iPod; he was never clued in fully but suspects they were adding radiation sensors. It would make sense, given the climate in the early 2000s, walking down the street with a traditional Geiger counter would have been a bit obvious. And mind you, we’re not knocking Apple for allegedly working with the government on this — building a few modified iPods is a whole lot different than turning masses of phones into data gathering terminals. Umm, wait…

A couple of weeks back, we included a story about a gearhead who mounted a GoPro camera inside of a car tire. The result was some interesting footage as he drove around; it’s not a common sight to watch a tire deform and move around from the inside like that. As an encore, the gearhead in question, Warped Perception, did the same trick bit with a more destructive bent: he captured a full burnout from the inside. The footage is pretty sick, with the telltale bubbles appearing on the inside before the inevitable blowout and seeing daylight through the shredded remains of the tire. But for our money, the best part is the slo-mo footage from the outside, with the billowing smoke and shredded steel belts a-flinging. We appreciate the effort, but we’re sure glad this guy isn’t our neighbor.

Speaking of graphic footage, things are not going well for some remote radio sites in California. Some towers that host the repeaters used by public service agencies and ham radio operators alike have managed to record their last few minutes of life as wildfires sweep across the mountains they’re perched upon. The scenes are horrific, like something from Dante’s Inferno, and the burnover shown in the video below is terrifying; watch it and you’ll see a full-grown tree consumed in less than 30 seconds. As bad as the loss of equipment is, it pales in comparison to what the firefighters face as they battle these blazes, but keep in mind that losing these repeaters can place them in terrible jeopardy too.

Continue reading “Hackaday Links: August 23, 2020” →

Seeing The Skill Is Better Than Seeing The Project

August 22, 2020 by Mike Szczys 12 Comments

Pulling off a flashy project that gets the viral-media hug of widespread approval feels great. Getting there is no easy path to walk and often times the craft that went into a finished project doesn’t even take the back seat but gets no mention at all. Often I find I’m more impressed by — or a least my attention is more strongly captured by — the skills put on display as prominently as the finished build.

Case-in-point this week comes from the model railroad work of [Diorama111]. Seeing an OLED screen in the nose of an HO scale locomotive just like the real-life version is impressive, but how many people missed the one-off soldering masterpiece that went into this one? You’ll marvel at the SMD techniques used with through-hole protoboard on this one.

Occasionally we do get to look over the shoulder of the master as decades of skills are shared for the purpose of passing them on. So was the case back in May when we watched as [Leo] walked through his tips and tricks for prototyping at the electronics bench. This included a lot of non-obvious but clever stuff; tips on working with copper tape for solder buses, using Teflon tubing with bare wire instead of stripping PVC-insulated wire, and a deep dive into copper clad prototyping.

So remember all of us hardware geeks when you look to tell the story of your project. We want to know how it was done at least as much as what was done. There was a time when electronic designers were a separate work group from electronic technicians (and wow, those technicians were in a league of their own). These days we all have that technician hat hanging on our workbenches and I’m always interested in packing in yet another unlearnt skill. Throw us a bone!

Hackaday Podcast 081: Mask-apult, Beef Tallow, Grinding Melted Plastic, And Stretching Flowing Metal

August 21, 2020 by Tom Nardi 7 Comments

Hackaday editors Mike Szczys and Tom Nardi chew the beef tallow as they take a tour through some of the best and most interesting articles from the past week, from kicking off another round of the popular Circuit Sculpture contest to building artisan coffee makers. We’ll look at the engineering behind the post-apocalyptic face mask launcher of our nightmares, and stand in awe at the intersection of orbiting spacecraft and lawn emojis. Several tiny remote controlled vehicles will be discussed, and we’ll take an unexpected look at how extruding plastic and aluminum might not be so different after all. Make sure to stick around until the end to learn why a little-known locomotive technology of the 1840s really sucked.

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 or so.)

Continue reading “Hackaday Podcast 081: Mask-apult, Beef Tallow, Grinding Melted Plastic, And Stretching Flowing Metal” →

This Week In Security: Bluetooth Hacking, NEC Phones, And Malicious Tor Nodes

August 21, 2020 by Jonathan Bennett 4 Comments

One of the fun things about vulnerability research is that there are so many places for bugs to hide. Modern devices have multiple processors, bits of radio hardware, and millions of lines of code. When [Veronica Kovah] of Dark Mentor LLC decided to start vulnerability research on the Bluetooth Low Energy protocol, she opted to target the link layer itself, rather than the code stack running as part of the main OS. What’s interesting is that the link layer has to process data before any authentication is performed, so if a vulnerability is found here, it’s guaranteed to be pre-authentication. Also of interest, many different devices are likely to share the same BLE chipset, meaning these vulnerabilities will show up on many different devices. [Veronica] shares some great info on how to get started, as well as the details on the vulnerabilities she found, in the PDF whitepaper. (Just a quick note, this link isn’t to the raw PDF, but pulls up a GitHub PDF viewer.) There is also a video presentation of the findings, if that’s more your speed.

The first vuln we’ll look at is CVE-2019-15948, which affects a handful of Texas Instruments BT/BLE chips. The problem is in how BLE advertisement packets are handled. An advertisement packet should always contain a data length of at least six bytes, which is reserved for the sending device address. Part of the packet parsing process is to subtract six from the packet length and do a memcpy using that value as the length. A malicious packet can have a length of less than six, and the result is that the copy length integer underflows, becoming a large value, and overwriting the current stack. To actually turn this into an exploit, a pair of data packets are sent repeatedly, to put malicious code in the place where program execution will jump to.

The second vulnerability of note, CVE-2020-15531 targets a Silicon Labs BLE chip, and uses malformed extended advertisement packets to trigger a buffer overflow. Specifically, the sent message is longer than the specification says it should be. Rather than drop this malformed message, the chip’s firmware processes it, which triggers a buffer overflow. Going a step further, this chip has non-volatile firmware, and it’s possible to modify that firmware permanently. [Veronica] points out that even embedded chips like these should have some sort of secure boot implementation, to prevent these sort of persistent attacks.
Continue reading “This Week In Security: Bluetooth Hacking, NEC Phones, And Malicious Tor Nodes” →

ESP32 Altair Emulator Gets Split Personality

August 20, 2020 by Al Williams 36 Comments

If you wanted me to demo CP/M running on an emulated Altair 8800, I’d pull out a tiny board from my pocket. You might wonder how I wound up with an Altair 8800 that runs CP/M (even WordStar), that fits in your pocket and cost less than $10. Turns out it’s a story that goes back to 1975.

When the Altair 8800 arrived back in 1975, I wanted one. Badly. I’d been reading about computers but had no hands-on experience. But back then, as far as I was concerned, the $400 price tag might as well have been a million bucks. I was working for no real pay in my family’s store, though in all fairness, adjusted into today’s money that was about $2,000.

I’d love to buy one now, but a real Altair costs even more today than it did back then. They also take up a lot of desk space. Sure, there are replicas and I’ve had a few. I even helped work the kinks out of Vince Briel’s clone which I’ve enjoyed. However, the Briel computer has two problems. First, it takes a little work to drive a serial port (it uses a VGA and a PS/2 keyboard). Second, while it’s smaller than a real Altair, it is still pretty large — a byproduct of its beautiful front panel.

So to quickly show off CP/M to someone, you need to haul out a big box and find a VGA monitor and PS/2 keyboard — both of which are becoming vanishing commodities. I made some modifications to get the serial port working, but it is still a lot to cart around. You could go the software route with a simulator like SIMH or Z80pack, but now instead of finding a VGA monitor and a PS/2 keyboard, you need to find a computer where you can install the software. What I really wanted was a simple and portable device that could boot CP/M.

Continue reading “ESP32 Altair Emulator Gets Split Personality” →

Russell Kirsch: Pixel Pioneer And The Father Of Digital Imaging

August 20, 2020 by Kristina Panos 28 Comments

It’s true what they say — you never know what you can do until you try. Russell Kirsch, who developed the first digital image scanner and subsequently invented the pixel, was a firm believer in this axiom. And if Russell had never tried to get a picture of his three-month-old son into a computer back in 1957, you might be reading Hackaday in print right now. Russell’s work laid the foundation for the algorithms and storage methods that make digital imaging what it is today.

Russell reads SEAC’s last printout. Image via TechSpot

Russell A. Kirsch was born June 20, 1929 in New York City, the son of Russian and Hungarian immigrants. He got quite an education, beginning at Bronx High School of Science. Then he earned a bachelor’s of Electrical Engineering at NYU, a Master of Science from Harvard, and attended American University and MIT.

In 1951, Russell went to work for the National Bureau of Standards, now known as the National Institutes of Science and Technology (NIST). He spent nearly 50 years at NIST, and started out by working with one of the first programmable computers in America known as SEAC (Standards Eastern Automatic Computer). This room-sized computer built in 1950 was developed as an interim solution for the Census Bureau to do research (PDF).

Standards Eastern Automatic Computer (SEAC) was the first programmable computer in the United States. Credit: NIST via Wikimedia

Like the other computers of its time, SEAC spoke the language of punch cards, mercury memory, and wire storage. Russell Kirsch and his team were tasked with finding a way to feed pictorial data into the machine without any prior processing. Since the computer was supposed to be temporary, its use wasn’t as tightly controlled as other computers. Although it ran 24/7 and got plenty of use, SEAC was more accessible than other computers, which allowed time for bleeding edge experimentation. NIST ended up keeping SEAC around for the next thirteen years, until 1963.

The Original Pixel Pusher

This photo of Russell’s son Walden is the first digitized image. Public Domain via Wikimedia

The term ‘pixel’ is a shortened portmanteau of picture element. Technically speaking, pixels are the unit of length for digital imaging. Pixels are building blocks for anything that can be displayed on a computer screen, so they’re kind of the first addressable blinkenlights.

In 1957, Russell brought in a picture of his son Walden, which would become the first digital image (PDF). He mounted the photo on a rotating drum scanner that had a motor on one end and a strobing disk on the other. The drum was coupled to a photo-multiplier vacuum tube that spun around on a lead screw. Photo-multipliers are used to detect very low levels of light.

As the drum slowly rotated, a photo-multiplier moved back and forth, scanning the image through a square viewing hole in the wall of a box. The tube digitized the picture by transmitting ones and zeros to SEAC that described what it saw through the square viewing hole — 1 for white, and 0 for black. The digital image of Walden is 76 x 76 pixels, which was the maximum allowed by SEAC.

Variable-Shaped Pixels

If Russell Kirsch had any regrets, it is that he designed pixels to be square. Ten years ago at the age of 81, he started working on a variable-shaped pixels with the hope of improving the future of digital imaging. He wrote a LISP program to explore the idea, and simulated triangular and rectangular pixels using a 6×6 array of square pixels for each.

Alternative pixel geometries. Image via Cloudseed Films

In in the video below, Russell discusses the idea and proves that variable pixels make a better image with more information than square pixels do, and with significantly fewer pixels overall. It takes some finagling, as pixel pairs of triangles and rectangles must be carefully chosen, rotated, and mixed together to best represent the image, but the image quality is definitely worth the effort. Following that is a video of Russell discussing SEAC’s hardware.

Russell retired from NIST in 2001 and moved to Portland, Oregon. As of 2012, he could be found in the occasional coffeehouse, discussing technology with anyone he could engage. Unfortunately, Russell developed Alzheimer’s and died from complications on August 11, 2020. He was 91 years old.

Continue reading “Russell Kirsch: Pixel Pioneer And The Father Of Digital Imaging” →

How To Get Into Cars: Aero Mods For More Grip

August 19, 2020 by Lewin Day 32 Comments

In 1960, Enzo Ferrari said “Aerodynamics are for people who can’t build engines”. It’s a quote that’s been proven laughably wrong in decades since. Aerodynamics are a key consideration for anyone serious about performance in almost any branch of motorsport. Today, we’ll take a look at how aero influences the performance of your car, and what modifications you might undertake to improve things.

Gains To Be Had

Improving the aerodynamics of your vehicle can mean wildly different things, depending on what your end goal is. Aerodynamics affects everything from top speed, to fuel economy, to grip, and optimizing for these different attributes can take wildly different routes. Often, it’s necessary to find a balance between several competing factors, as improvements in one area can often be detrimental in another.

To understand aerodynamics with regards to cars, we need to know about the forces of lift (or downforce), and drag. Drag is the force that acts against the direction of motion, slowing a vehicle down. Lift is the force generated perpendicular to the direction of motion. In the context of flight, the lift force is generated upwards with respect to gravity, lofting planes into the air. In an automotive context, we very much prefer to stay on the ground. Wings and aerodynamic surfaces on cars are created to create lift in the opposite direction, pushing the vehicle downwards and creating more grip. We refer to this “downwards lift” as downforce.

Continue reading “How To Get Into Cars: Aero Mods For More Grip” →