The ESP32 Bluetooth Backdoor That Wasn’t

Recently there was a panicked scrambling after the announcement by [Tarlogic] of a ‘backdoor’ found in Espressif’s popular ESP32 MCUs. Specifically a backdoor on  the Bluetooth side that would give a lot of control over the system to any attacker. As [Xeno Kovah] explains, much about these claims is exaggerated, and calling it a ‘backdoor’ is far beyond the scope of what was actually discovered.

To summarize the original findings, the researchers found a number of vendor-specific commands (VSCs) in the (publicly available) ESP32 ROM that can be sent via the host-controller interface (HCI) between the software and the Bluetooth PHY. They found that these VSCs could do things like writing and reading the firmware in the PHY, as well as send low-level packets.

The thing about VSCs is of course that these are a standard feature with Bluetooth controllers, with each manufacturer implementing a range of these for use with their own software SDK. These VSCs allow for updating firmware, report temperatures and features like debugging, and are generally documented (except for Broadcom).

Effectively, [Xeno] makes the point that VSCs are a standard feature in Bluetooth controllers, which – like most features – can also be abused. [Tarlogic] has since updated their article as well to distance themselves from the ‘backdoor’ term and instead want to call these VSCs a ‘hidden feature’. That said, if these VSCs in ESP32 chips are a security risk, then as [Xeno] duly notes, millions of BT controllers from Texas Instruments, Broadcom and others with similar VSCs would similarly be a security risk.

Fixing An Unpleasant SD Card Slot Issue In A NanoVNA

SD cards & the much smaller microSD cards are found on many devices, with the card often accessible from outside the enclosure. Unfortunately there’s a solid chance that especially small microSD cards will find their way past the microSD card reader slot and into the enclosure. This is what happened to [Rob] of the SevenFortyOne Radios and Repairs channel on YouTube with a NanoVNA unit. While shaking the unit, you can clearly hear the microSD card rattling inside, courtesy of the rather large gap above the card slot.

After a quick teardown and extracting the lost microSD card, the solution to prevent this is a simple bit of foam stuck on top of the microSD card slot, so that the too large opening in the enclosure is now fully blocked. It’s clearly a bit of a design fail in this particular NanoVNA unit, worsened by the tiny size of the card and having to use a fingernail to push the card into the slot as it’s so far inside the enclosure.

While [Rob] seems to blame himself for this event, we’d chalk it mostly up to poor design. It’s an issue that’s seen with certain SBC enclosures and various gadgets too, where losing a microSD card is pretty much a matter of time, and hugely fiddly at the best of times. That said, what is your preferred way of handling microSD card insertion & removal in devices like these?

Continue reading “Fixing An Unpleasant SD Card Slot Issue In A NanoVNA”

Writing An OLED Display Driver In MicroZig

Although most people would use C, C++ or MicroPython for programming microcontrollers, there are a few more obscure options out there as well, with MicroZig being one of them. Recently [Andrew Conlin] wrote about how to use MicroZig with the Raspberry Pi RP2040 MCU, showing the process of writing an SSD1306 OLED display driver and running it. Although MicroZig has since published a built-in version, the blog post gives a good impression of what developing with MicroZig is like.

Zig is a programming language which seeks to improve on the C language, adding memory safety, safe pointers (via option types), while keeping as much as possible of what makes C so useful for low-level development intact. The MicroZig project customizes Zig for use in embedded projects,  targeting platforms including the Raspberry Pi MCUs and STM32.  During [Andrew]’s usage of MicroZig it was less the language or supplied tooling that tripped him up, and more just the convoluted initialization of the SSD1306 controller, which is probably a good sign. The resulting project code can be found on his GitHub page.

Run Xbox 360 Games On Your PC With XenonRecomp

Inspired by the N64: Recompiled project, XenonRecomp does something similar, except for the PowerPC-equipped Microsoft Xbox 360 game console. Based around the triple-core IBM CPU codenamed ‘Xenon‘, the Xbox 360 was released in 2005 and generally quite successful over its lifespan despite its Red Ring of Death issues. Although the current Xbox Series X supports running a number of Xbox 360 games, this is done via emulation and only 632 games out of 2,155 are supported.

This is where XenonRecomp not only promises turning the games into native (x86) software, but also allowing for a range of graphical improvements. Best of all, it allows for Xbox 360 games to be preserved instead of linked to an obsolete console. That said, much like with N64Recomp, it’s not a simple matter of running a tool over the PPC binary. You’re expected to have in-depth systems knowledge, with the tools in XenonRecomp assisting with the decompilation (into C++) and the recompilation into x86 binaries, but support for PPC instructions, VMX (vector instructions) and aspects like jump table conversion and (currently missing) MMIO support are likely to present an enterprising developer with hours of fun to implement and debug when issues arise.

Continue reading “Run Xbox 360 Games On Your PC With XenonRecomp”

GNSS Signals Tracked On The Moon By LuGRE

As part of the payloads on the Firefly Blue Ghost Mission 1 (BGM1) that recently touched down on the Moon, the Lunar GNNS Receiver Experiment (LuGRE) has become the first practical demonstration of acquiring and tracking Earth orbital GNSS satellites. LuGRE consists of a weak-signal GNSS receiver, a high-gain L-band patch antenna the requisite amplification and filter circuits, designed to track a number of GPS and Galileo signals.

Designed by NASA and the Italian Space Agency (ISA), the LuGRE payload’s goal was to demonstrate GNSS-based positioning, navigation and timing at the Moon. This successful demonstration makes it plausible that future lunar missions, whether in orbit or on the surface, could use Earth’s GNSS satellites to navigate and position themselves with. On the way to the lunar surface, LuGRE confirmed being able to track GNSS at various distances from the Earth.

Both LuGRE and BGM1 are part of NASA’s Commercial Lunar Payload Services (CLPS) program, with BGM1 delivering a total of ten payloads to the Moon, each designed to study a different aspect of the lunar environment, as well as hardware and technologies relevant to future missions.

The Long Goodbye: More Instruments Shut Down On The Voyagers As End Nears

Saying farewell is hard, and in the case of the Voyager 1 & 2 spacecraft doubly so, seeing as how they have been with us for more than 47 years. From the highs of the 1970s and 1980s during their primary mission in our Solar System, to their journey into the unknown of Deep Space, every bit of information which their instruments record and send back is something unique that we could not obtain any other way. Yet with the shutting down of two more instruments, both spacecraft are now getting awfully close to the end of their extended missions.

Last February 25 the cosmic ray system (CRS) on Voyager 1 was disabled, with the Low Energy Charged Particle Instrument (LECP) on Voyager 2 to follow on March 24. With each spacecraft losing about 4 watts of available power per year from their RTGs, the next few instruments to be turned off are already known. Voyager 1’s LECP will be turned off next year, with that same year Voyager 2’s CRS also getting disabled.

This would leave both spacecraft with only their magnetometer (MAG) and plasma wave subsystem (PWS). These provide data on the local magnetic field and electron density, respectively, with at least one of these instruments on each spacecraft likely to remain active until the end of this decade, possibly into the next. With some luck both spacecraft will see their 50th birthday before humanity’s only presence in Deep Space falls silent.

Thanks to [Mark Stevens] for the tip.

China Claims Commercial Nuclear Fusion By 2050 As Germany Goes Stellarator

Things are heating up in the world of nuclear fusion research, with most fundamental issues resolved and an increasing rate of announcements being made regarding commercial fusion power. China’s CNNC is one of the most recent voices here, with their statement that they expect to have commercial nuclear fusion plants online by 2050. Although scarce on details, China is one of the leading nations when it comes to nuclear fusion research, with multiple large tokamaks, including the HL-2M and the upcoming CFETR which we covered a few years ago.

Stellaris stellarator. (Credit: Proxima Fusion)

In addition to China’s fusion-related news, a German startup called Proxima Fusion announced their Stellaris commercial fusion plant design concept, with a targeted grid connection by the 2030s. Of note is that this involves a stellarator design, which has the major advantage of inherent plasma stability, dodging the confinement mode and Greenwald density issues that plague tokamaks. The Stellaris design is an evolution of the famous Wendelstein 7-X research stellarator at the Max Planck Institute.

While Wendelstein 7-X was not designed to produce power, it features everything from the complex coiled design and cooled divertors plus demonstrated long-term operation that a commercial reactor would need. This makes it quite likely that the coming decades we’ll be seeing the end spurt for commercial fusion power, with conceivably stellarators being the unlikely winner long before tokamaks cross the finish line.