The first part of [Mikhail Davidov] and [Baron Oldenburg]’s article is a review of some of the basics of exploring the RF emissions of computers using software-defined radio (SDR) dongles. Most readers can safely skip ahead a bit to section 9, which gets into the process they used to sniff for potentially compromising RF leaks from an air-gapped test computer. After finding a few weak signals in the gigahertz range and dismissing them as attack vectors due to their limited penetration potential, they settled in on the GPU card, a Radeon Pro WX3100, and specifically on the power management features of its ATI chipset.
With a GPU benchmarking program running, they switched the graphics card shader clock between its two lowest power settings, which produced a strong signal on the SDR waterfall at 428 MHz. They were able to receive this signal up to 50 feet (15 meters) away, perhaps to the annoyance of nearby hams as this is plunk in the middle of the 70-cm band. This is theoretically enough to exfiltrate data, but at a painfully low bitrate. So they improved the exploit by forcing the CPU driver to vary the shader clock frequency in one megahertz steps, allowing them to implement higher throughput encoding schemes. You can hear the change in signal caused by different graphics being displayed in the video below; one doesn’t need much imagination to see how malware could leverage this to exfiltrate pretty much anything on the computer.
On the 3rd of June 2019, a 1U CubeSat developed by students of the AGH University of Science and Technology in Kraków was released from the International Space Station. Within a few hours it was clear something was wrong, and by July 30th, the satellite was barely functional. A number of problems contributed to the gradual degradation of the KRAKsat spacecraft, which the team has thoroughly documented in a recently released paper.
We all know, at least in a general sense, that building and operating a spacecraft is an exceptionally difficult task on a technical level. But reading through the 20-pages of “KRAKsat Lessons Learned” gives you practical examples of just how many things can go wrong.
It all started with a steadily decreasing battery voltage. The voltage was dropping slowly enough that the team knew the solar panels were doing something, but unfortunately the KRAKsat didn’t have a way of reporting their output. This made it difficult to diagnose the energy deficit, but the team believes the issue may have been that the tumbling of the spacecraft meant the panels weren’t exposed to the amount of direct sunlight they had anticipated.
This slow energy drain continued until the voltage dropped to the point that the power supply shut down, and that’s were things really started going south. Once the satellite shut down the batteries were able to start charging back up, which normally would have been a good thing. But unfortunately the KRAKsat had no mechanism to remain powered down once the voltage climbed back above the shutoff threshold. This caused the satellite to enter into and loop where it would reboot itself as many as 150 times per orbit (approximately 90 minutes).
The paper then goes into a laundry list of other problems that contributed to KRAKsat’s failure. For example, the satellite had redundant radios onboard, but the software on them wasn’t identical. When they needed to switch over to the secondary radio, they found that a glitch in its software meant it was unable to access some portions of the onboard flash storage. The team also identified the lack of a filesystem on the flash storage as another stumbling block; having to pull things out using a pointer and the specific memory address was a cumbersome and time consuming task made all the more difficult by the spacecraft’s deteriorating condition.
Like many of us, [Zak Kemble] has an indeterminate number of tiny packages coming his way from all over the globe at any given time. Unfortunately, the somewhat unpredictable nature of the postal service where he lives meant he found himself making a lot of wasted trips out to the mailbox to see if any overseas treasures had arrived for him. To solve the problem, he decided to build an Internet-connected mailbox notification system that could work within some fairly specific parameters.
For one thing, the mailbox is too distant to connect directly to it over WiFi. [Zak] mentions that 433 MHz might have been an option, but he decided to skip that entirely and just connect it to the cellular network with an A9G GPRS/GSM module from A.I. Thinker. This device actually has its own SDK that allows you to create a custom firmware for it, but unfortunately the high energy consumption of the radio meant it would chew through batteries too quickly unless it had a little extra help.
Not wanting to have to change the batteries every couple months, [Zak] added a ATtiny402 to handle the notifier’s power management needs. By using a P-MOSFET to completely cut power to the A9G, the notifier can save an incredible amount of energy by only activating the cellular connection once it actually needs to send a notification; which in this case takes the form of an HTTP request that eventually works its way to a Telegram group chat.
To cut a long story short, testing seems to indicate that the notifier can fire off approximately 800 requests before needing its 10440 lithium battery recharged. Given how often [Zak] usually receives mail, he says that should last him around five years.
The A9G module, the ATtiny402, a BME280 environmental sensor (because, why not?), the battery, and all the ancillary support hardware are on a very professional looking PCB. That goes into a relatively rugged enclosure that’s designed to keep the electronics from shorting out on the mailbox’s metal case as well as keeping any particularly weighty parcels from crushing it.
When the Raspberry Pi 4 was first launched, one of its few perceived flaws was that it had a propensity to get extremely hot. It’s evidently something the Pi people take very seriously, so in the months since they have addressed the problem with a set of firmware updates. Now they’ve taken a look at the effect of the fixes in a piece on the Raspberry Pi web site, and it makes for an interesting comparison.
The headline figure is that all updates together remove about a watt of power from the load, a significant quantity for what is still a board that can run from a capable phone charger. Breaking down the separate parts of the updates is where the meat of this story lies though, as we see the individual effects of the various USB, memory, power management and clocking updates. In temperature terms they measure an on-load drop from 72.1 °C to 58.1 °C, which should be a significant improvement for any Pi 4 owner.
There is a debate to be had over in what role a computer such as a Pi should serve. As successive revisions become ever more desktop-like in their capabilities, do they run the risk of abandoning the simplicity of a cheap Linux box as a component that makes us come back for more? It’s a possibility, but one they have very well addressed by developing the Pi Zero. They have also successfully avoided the fate of the Arduino — inexorably tied to its ATmega powered original line despite newer releases. As we have frequently said when reviewing Raspberry Pi competitors, it’s the software support that sets them apart from the herd, something this power-draw story demonstrates admirably.