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”

Amazon’s ‘Just Walk Out’ Shopping Is Out, Moves To Dash Carts At Its Grocery Stores

After a few years of Amazon promoting a grocery shopping experience without checkout lines and frustrating self-checkout experiences, it is now ditching its Just Walk Out technology. Conceptualized as a store where you can walk in, grab the items you need and walk out with said items automatically charged to your registered payment method, it never really caught much traction. More recently it was revealed that the technology wasn’t even as automated as portrayed, with human workers handling much of the tedium behind the scenes. This despite claims made by Amazon that it was all powered by deep machine learning and generative AI.

An Amazon Dash Cart's user interface, with scanner and display. (Credit: Amazon)
An Amazon Dash Cart’s user interface, with scanner and display. (Credit: Amazon)

Instead of plastering the ceilings of stores full with cameras, it seems that Amazon instead wishes to focus on smart shopping carts that can keep track of what has been put inside them. These so-called Dash Carts are equipped with cameras and other sensors to scan barcodes on items, as well as weigh unlabeled items (like fruit), making them into somewhat of a merging of scales at the vegetable and fruit section of stores today, and the scanning tools offered at some grocery stores to help with self-checkout.

As the main problem with the Just Walk Out technology was that it required constant (700 out of 1,000 sales in 2022) human interaction, it will be interesting to see whether the return to a more traditional self-service and self-checkout model (albeit with special Dash Lanes) may speed things along. Even so, as Gizmodo notes, Amazon will still keep the Just Walk Out technology running across locations in the UK and elsewhere. Either this means the tech isn’t fully dead yet, or we will see a revival at some point in time.

Screenshot of eBay listings with Gigaset IoT devices being sold, now basically useless

A Giga-Sunset For Gigaset IoT Devices

In today’s “predictable things that happened before and definitely will happen again”, we have another company in the “smart device” business that has just shuttered their servers, leaving devices completely inert. This time, it’s Gigaset. The servers were shuttered on the 29th of March, and the official announcement (German, Google Translate) states that there’s no easy way out.

It appears that the devices were locked into Gigaset Cloud to perform their function, with no local-only option. This leaves all open source integrations in the dust, whatever documentation there was, is now taken down. As the announcement states, Gigaset Communications Gmbh has gotten acquired due to insolvency, and the buyer was not remotely interested in the Smart Home portion of the business. As the corporate traditions follow, we can’t expect open sourcing of the code or protocol specification or anything of the sort — the devices are bricks until someone takes care of them.

If you’re looking for smart devices on the cheap, you might want to add “Gigaset” to your monitored search term list — we’ll be waiting for your hack submissions as usual. After all, we’ve seen some success stories when it comes to abandoned smart home devices – like the recent Insteon story, where a group of device owners bought out and restarted the service after the company got abruptly shut down.

We thank [Louis] for sharing this with us!

Espressif’s ESP32-P4 Application Processor: Details Begin To Emerge

Every now and then there’s a part that comes along which is hotly anticipated, but which understandably its manufacturer remains tight-lipped about in order to preserve maximum impact surrounding its launch. Right now that’s Espressif’s ESP32-P4: a powerful application processor with dual-core 400 MHz and a single-core low power 40 MHz RISC-V processors. Interestingly it doesn’t appear to have the radios which have been a feature of previous ESP parts, but it makes up for those with a much more comprehensive array of peripherals.

Some details are beginning to emerge, whether from leaks or in preparation for launch, including the first signs of support in their JTAG tool, and a glimpse in a video from another Chinese company of a development board. We got our hopes up a little when we saw the P4 appearing in some Espressif documentation, but on closer examination there’s nothing there yet about the interesting new peripherals.

Looking at the dev board and the video we can see some of what the thing is capable of as it drives a large touchscreen and a camera. There are two MIPI DSI/CSI ports on  the PCB, as well as three USB ports and a sound codec. A more run-of-the-mill ESP32-C3 is present we think to provide wireless networking, and there’s a fourth USB port which we are fairly certain is in fact only for serial communications via a what our best blurry photograph reading tells us is a Silicon Labs USB-to-serial chip. Finally there’s large Raspberry Pi-style header which appears to carry all the GPIOs and other pins. We’ve placed the video below the break, if you see anything we’ve missed please tell us in the comments.

We first covered this chip back in January, and then as now we’re looking forward to seeing what our community does with it.

Continue reading “Espressif’s ESP32-P4 Application Processor: Details Begin To Emerge”

Flipper Zero Panic Spreads To Oz: Cars Unaffected

A feature of coming to adulthood for any young person in the last quarter of the twentieth century would have been the yearly warnings about the danger of adulterated Halloween treats. Stories were breathlessly repeated of apples with razor blades in them, or of chocolate bars laced with rat poison, and though such tales often carried examples of kids who’d died horrible deaths in other far-away places, the whole panic was (as far as we know) a baseless urban legend.

It’s difficult not to be reminded of those times today then, as we read news from Australia warning about the threat from the Flipper Zero wireless hacking tool. It has the same ingredients, of an imaginary threat earnestly repeated by law enforcement officers, and lapped up by a credulous media with little appetite for verifying what they print.

This is a story which first appeared in mid-February in Canada, when a government minister singled out the Flipper Zero as a car theft tool and promised to ban it. This prompted a storm of derision from tech-savvy Canadians and others who immediately pointed out that vehicle security has long ago eclipsed the capabilities of the Flipper, and that there are far more pertinent threats such as those from CAN bus attacks or even RF boosters. Despite this debunking, it seems to have spread. Where will Flipper Mania pop up next?

Canada and Australia are both countries with a free press; that press should be doing their job on these stories by fact-checking and asking pertinent questions when the facts don’t fit the story. When it comes to technology stories it seems not doing this has become the norm.

Thanks [Peter Caldwell] for the tip.

Security Alert: Potential SSH Backdoor Via Liblzma

In breaking news that dropped just after our weekly security column went live, a backdoor has been discovered in the xz package, that could potentially compromise SSH logins on Linux systems. The most detailed analysis so far seems to be by [Andres Freund] on the oss-security list.

The xz release tarballs from 5.6.0 in late February and 5.6.1 on March 9th both contain malicious code. A pair of compressed files in the repository contain the majority of the malicious patch, disguised as test files. In practice, this means that looking at the repository doesn’t reveal anything amiss, but downloading the release tarballs gives you the compromised code.

This was discovered because SSH logins on a Debian sid were taking longer, with more CPU cycles than expected. And interestingly, Valgrind was throwing unexpected errors when running on the liblzma library. That last bit was first discovered on February 24th, immediately after the 5.6.0 release. The xz-utils package failed its tests on Gentoo builds.

Continue reading “Security Alert: Potential SSH Backdoor Via Liblzma”