The 2024 Business Card Challenge Starts Now

If you want to make circuits for a living, what better way to impress a future employer than to hand them a piece of your work to take home? But even if you’re just hacking for fun, you can still turn your calling into your calling card.

We are inviting you to submit your coolest business card hacks for us all to admire, and the top three entries will win a $150 DigiKey shopping spree.  If your work can fit on a business card, create a project page for it over on Hackaday.io and enter it in the 2024 Business Card Contest. Share your tiny hacks!

To enter, create a project for your hacked business card over at Hackaday IO, and then enter it into the 2024 Business Card Challenge by selecting the pulldown on the left. It’s that easy.

Continue reading “The 2024 Business Card Challenge Starts Now”

Google Removes RISC-V Support From Android

Last year the introduction of  RISC-V support to the Android-specific, Linux-derived Android Common Kernel (ACK) made it seem that before long Android devices might be using SoCs based around the RISC-V ISA, but it would seem that these hopes are now dashed. As reported by Android Authority, with a series of recently accepted patches this RISC-V support was stripped again from the ACK. While this doesn’t mean that Android cannot be made to work on RISC-V, any company interested would have to do all of the heavy lifting themselves, which might include Qualcomm with their recently announced RISC-V-based smartwatch Snapdragon SoC.

No reason was provided by Google for this change, and the official statement from Google to Android Authority says that Google is not ready to provide a single supported Android Generic Kernel Image (GKI), but that ‘Android will continue to support RISC-V’. This change however, removes RISC-V kernel support from the ACK, and since Google only certifies Android builds which ship with a GKI featuring an ACK, this effectively means that RISC-V is not supported at this point, and likely won’t be for the foreseeable future.

As discussed on Hacker News, a potential reason might be the very fragmentary nature of the RISC-V ISA, which makes a standard RISC-V kernel very complicated if you want to support more than a (barebones) profile. This is also supported by a RISC-V mailing list thread, where ‘expensive maintenance’ is mentioned for why Google doesn’t want to support RISC-V.

This Week In Security: Default Passwords, Lock Slapping, And Mastodown

The UK has the answer to all our IoT problems: banning bad default passwords. Additionally, the new UK law requires device makers to provide contact info for vulnerability disclosures, as well as a requirement to advertise vulnerability fix schedules. Is this going to help the security of routers, cameras, and other devices? Maybe a bit.

I would argue that default passwords are in themselves the problem, and complexity requirements only nominally help security. Why? Because a good default password becomes worthless once the password, or algorithm leaks. Let’s lay out some scenarios here. First is the static default password. Manufacturer X makes device Y, and sets the devices to username/password admin/new_Complex_P@ssword1!. Those credentials make it onto a default password list, and any extra security is lost.

What about those devices that have a different, random-looking password for each device? Those use an algorithm to derive that password from the MAC address and/or serial number. That may help the situation, but the algorithm can be retrieved from the firmware, and most serial numbers are predictable in one way or another. This approach is better, but not a silver bullet.

So what would a real solution to the password problem look like? How about no default password at all, but no device functionality until the new password passes a cracklib complexity and uniqueness check. I have seen a few devices that do exactly this. The requirement for a disclosure address is a great idea, which we’ve talked about before regarding the similar EU legislation.

Continue reading “This Week In Security: Default Passwords, Lock Slapping, And Mastodown”

Pssst… Wanna Buy An Old Supercomputer?

If you spend your time plotting evil world domination while stroking your fluffy white cat in your super-villain lair, it’s clear that only the most high-performance in computing is going to help you achieve your dastardly aims. But computers of that scale are expensive, and not even your tame mad scientist can whistle one out of thin air. Never mind though, because if your life lacks a supercomputer, there’s one for sale right now in Wyoming.

The Cheyenne Supercomputer was ranked in the top 20 of global computing power back in 2016, when it was installed to work on atmospheric simulation and earth sciences. There’s a page containing exhaustive specs, but overall we’re talking about a Silicon Graphics ICE XA system with 8,064 processors at 18 cores each for a total of 14,5152 cores, and a not inconsequential 313,344 GB of memory. In terms of software it ran the SuSE Linux Enterprise Server OS, but don’t let that stop you from installing your distro of choice.

It’s now being sold on a government auction site in a decommissioned but able to be reactivated state, and given that it takes up a LOT of space we’re guessing that arranging the trucks to move it will cost more than the computer itself. If you’re interested it’s standing at a shade over $40,000 at the time of writing with its reserve not met, and you have until the 3rd of May to snag it.

It’s clear that the world of supercomputing is a fast-moving one and this computer has been superseded. So whoever buys it won’t be joining the big boys any time soon — even though it remains one heck of a machine by mere mortal standards. We’re curious then who would buy an old supercomputer, if anyone. Would its power consumption for that much computing make it better off as scrap metal, or is there still a place for it somewhere? Ideas? Air them in the comments.

Farewell MFJ

We were sad to hear that after 52 years in operation, iconic ham radio supplier MFJ will close next month. On the one hand, it is hard not to hear such news and think that it is another sign that ham radio isn’t in a healthy space. After all, in an ideal world, [Martin Jue] — the well-known founder of MFJ — would have found an anxious buyer. Not only is the MFJ line of ham radio gear well regarded, but [Martin] had bought other ham radio-related companies over the years, such as Ameritron, Hygain, Cushcraft, Mirage, and Vectronics. Now, they will all be gone, too.

However, on a deeper reflection, maybe we shouldn’t see it as another nail in ham radio’s coffin. It is this way in every industry. There was a time when it was hard to imagine ham radio without, say, Heathkit. Yet they left, and the hobby continued. We could name a slew of other iconic companies that had their day: Eico, Hammarlund, Hallicrafters, and more. They live on at hamfests, their product lines are frozen in time, and we’re sure we’ll see a used market for MFJ gear well into the next century.

Continue reading “Farewell MFJ”

Welcome Back, Voyager

In what is probably the longest-distance tech support operation in history, the Voyager mission team succeeded in hacking their way around some defective memory and convincing their space probe to send sensor data back to earth again. And for the record, Voyager is a 46-year old system at a distance of now 24 billion kilometers, 22.5 light-hours, from the earth.

While the time delay that distance implies must have made for quite a tense couple days of waiting between sending the patch and finding out if it worked, the age of the computers onboard probably actually helped, in a strange way. Because the code is old-school machine language, one absolutely has to know all the memory addresses where each subroutine starts and ends. You don’t call a function like do_something(); but rather by loading an address in memory and jumping to it.

This means that the ground crew, in principle, knows where every instruction lives. If they also knew where all of the busted memory cells were, it would be a “simple” programming exercise to jump around the bad bits, and re-write all of the subroutine calls accordingly if larger chunks had to be moved. By “simple”, I of course mean “incredibly high stakes, and you’d better make sure you’ve got it right the first time.”

In a way, it’s a fantastic testament to simpler systems that they were able to patch their code around the memory holes. Think about trying to do this with a modern operating system that uses address space layout randomization, for instance. Of course, the purpose there is to make hacking directly on the memory harder, and that’s the opposite of what you’d want in a space probe.

Nonetheless, it’s a testament to careful work and clever software hacking that they managed to get Voyager back online. May she send for another 46 years!

This Week In Security: Cisco, Mitel, And AI False Flags

There’s a trend recently, of big-name security appliances getting used in state-sponsored attacks. It looks like Cisco is the latest victim, based on a report by their own Talos Intelligence.

This particular attack has a couple of components, and abuses a couple of vulnerabilities, though the odd thing about this one is that the initial access is still unknown. The first part of the infection is Line Dancer, a memory-only element that disables the system log, leaks the system config, captures packets and more. A couple of the more devious steps are taken, like replacing the crash dump process with a reboot, to keep the in-memory malware secret. And finally, the resident installs a backdoor in the VPN service.

There is a second element, Line Runner, that uses a vulnerability to arbitrary code from disk on startup, and then installs itself onto the device. That one is a long term command and control element, and seems to only get installed on targeted devices. The Talos blog makes a rather vague mention of a 32-byte token that gets pattern-matched, to determine an extra infection step. It may be that Line Runner only gets permanently installed on certain units, or some other particularly fun action is taken.

Fixes for the vulnerabilities that allowed for persistence are available, but again, the initial vector is still unknown. There’s a vulnerability that just got fixed, that could have been such a vulnerability. CVE-2024-20295 allows an authenticated user with read-only privileges perform a command injection as root. Proof of Concept code is out in the wild for this one, but so far there’s no evidence it was used in any attacks, including the one above. Continue reading “This Week In Security: Cisco, Mitel, And AI False Flags”