This Week In Security: It’s Con Season

It must be Blackhat/DEFCON season. Up first in the storm of named vulnerabilities, we have Downfall. The PDF has the juicy details here. It’s quite similar to the Zenbleed issue from last week, in that it abuses speculative execution to leak data via a hidden register. Unlike Zenbleed, this isn’t direct access, but using cache timing analysis to extract individual bytes using a FLUSH+RELOAD approach.

The key to the vulnerability is the gather instruction, which pulls data from multiple locations in memory, often used to run a followup instruction on multiple bytes of data at once. The gather instruction is complex, takes multiple clock cycles to execute, and uses several tricks to execute faster, including managing buffers to avoid multiple reads. In certain cases, that instruction can be interrupted before it completes, leaving the data in the cache. And this data can be speculatively accessed and the values leaked through timing analysis.

This flaw affects 6th generation Intel Core processors through 11th. Mitigations are already rolling out via a microcode update, but do carry a performance hit for gather instructions. Continue reading “This Week In Security: It’s Con Season”

The World ID Orb And The Question Of What Defines A Person

Among the daily churn of ‘Web 3.0’, blockchains and cryptocurrency messaging, there is generally very little that feels genuinely interesting or unique enough to pay attention to. The same was true for OpenAI CEO Sam Altman’s Ethereum blockchain-based Worldcoin when it was launched in 2021 while promising many of the same things as Bitcoin and others have for years. However, with the recent introduction of the World ID protocol by Tools for Humanity (TfH) – the company founded for Worldcoin by Mr. Altman – suddenly the interest of the general public was piqued.

Defined by TfH as a ‘privacy-first decentralized identity protocol’ World ID is supposed to be the end-all, be-all of authentication protocols. Part of it is an ominous-looking orb contraption that performs iris scans to enroll new participants. Not only do participants get ‘free’ Worldcoins if they sign up for a World ID enrollment this way, TfH also promises that this authentication protocol can uniquely identify any person without requiring them to submit any personal data, only requiring a scan of your irises.

Essentially, this would make World ID a unique ID for every person alive today and in the future, providing much more security while preventing identity theft. This naturally raises many questions about the feasibility of using iris recognition, as well as the potential for abuse and the impact of ocular surgery and diseases. Basically, can you reduce proof of personhood to an individual’s eyes, and should you?

Continue reading “The World ID Orb And The Question Of What Defines A Person”

Hackaday Prize 2023: LoShark, The Radio Debugger For LoRa

LoRa, the Long Range wireless protocol is pretty great for trickling data across long distances. There are some great embedded devices based around STM32, NRF52, and ESP32 microcontrollers. What’s been missing for quite a while is a device that allows for full access to a LoRa radio from a more capable CPU. The wait may be over, as there’s now the LoShark. It’s a USB key form factor, with a MIPS processor running a real Linux kernel. Cool!

The way debugging works is interesting, too. The team at SudoMaker is working on their Resonance runtime, which allows interacting with the onboard sx126x radio chip using JavaScript code. That chip can both send and receive, so this device should be capable of more than just capturing traffic. And if JavaScript isn’t your thing, the Linux system on the device means you can knock yourself out with C or C++ code. Who knows, we may even see Meshtastic running on this thing some day.

If this gets you excited, it’s already available for order for a reasonable $59.99. The LoShark ships in 433, 868, and 915 megahertz versions. It’s a really slick looking device, and maybe worth your time to check out. Enjoy!

Break Free From Proprietary Digital Radio

Digital modes are all the rage these days in amateur radio — hams are using protocols like WSPR to check propagation patterns, FT8 to get quick contacts on many bands with relatively low power, and MSK144 to quickly bounce a signal off of a meteor. There’s also digital voice, which has a number of perks over analog including improved audio quality. However, the major downside of most digital voice modes, at least those in use on UHF and VHF, is that they are proprietary with various radio brands having competing digital standards. To get above the noise a more open standard can be used instead.

The M17 standard, originally created by [Wojciech Kaczmarski] aka [SP5WWP], uses Codec 2 to convert voice into a digital format before it is broadcast over the air. Codec 2 is an open standard unlike other audio codecs. M17 also supports reflectors, which can link individual radios or entire repeaters together over the Internet. While you can make purpose-built modules that will interface with most standard radio inputs, it’s also possible to modify existing hardware to support this standard as well. The video below from [Tech Minds] shows this being done to a radio with only a few hardware modifications and the installation of a new firmware.

For anyone who has been frustrated that there’s no real universal standard for digital voice in VHF and above, M17 could be a game-changer if enough people get tired of their friends being on other proprietary digital systems. There’s plenty of supported hardware out there that most hams probably already have already, including a number of TNC devices like the Mobilinkd and the DigiRig, so it shouldn’t be too hard to get started. If you’re more into networking over radio, though, take a look at this method for sending high-bandwidth IP networking over the UHF band. Continue reading “Break Free From Proprietary Digital Radio”

DisplayPort: Taming The Altmode

The DisplayPort altmode is semi-proprietary, but it can absolutely be picked apart if we try. Last time, we found a cool appnote describing the DisplayPort altmode in detail, switched the FUSB302 into packet sniffing mode and got packet captures, learned about PD VDMs (vendor-defined messages), and successfully replayed the captured messages to switch a USB-C port into the DisplayPort altmode. Today, we will go through the seven messages that summon the DisplayPort altmode, implement them, and tie them all into a library – then, figure out the hardware we need to have DisplayPort work in the wild.

For a start, as you might have seen from the diagram, a single command can be either a request or a response. For instance, if you get a Discover Identity REQ (request), you reply to it with a Discover Identity ACK (response), adding your identity data to your response along the way. With some commands, the DP source will add some data for you to use; for most commands, your DP sink will have to provide information instead – and we’ll do just that, armed with the PDF provided and the packet captures.

We have seven commands we need to handle in order to get DisplayPort out of a compatible USB-C port – if you need a refresher on these commands, page 13 of the ST’s PDF on the DP altmode will show you the message sequence. These commands are: Discover Identity, Discover SVIDs, Discover Modes, Enter Mode, DP Status Update, DP Configure, and Attention. Out of these, the first four are already partially described in the base USB PD standard, the two DP commands afterwards are DisplayPort-altmode-specific but sufficiently described in the PDF we have, and the Attention command is from the base standard as well, mostly helpful for reporting state of the HPD pin. Let’s start with the first two! Continue reading “DisplayPort: Taming The Altmode”

The Past, Present, And Future Of CircuitPython

Modern microcontrollers like the RP2040 and ESP32 are truly a marvels of engineering. For literal pocket change you can get a chip that’s got a multi-core processor running at hundreds of megahertz, plenty of RAM, and more often than not, some form of wireless connectivity. Their capabilities have been nothing short of revolutionary for the DIY crowd — on any given day, you can see projects on these pages which simply wouldn’t have been possible back when the 8-bit Arduino was all most folks had access to.

Limor Fried

Thanks to the increased performance of these MCUs, hackers and makers now even have a choice as to which programming language they want to use. While C is still the language of choice for processor-intensive tasks, for many applications, Python is now a viable option on a wide range of hardware.

This provides a far less intimidating experience for newcomers, not just because the language is more forgiving, but because it does away with the traditional compile-flash-pray workflow. Of course, that doesn’t mean the more experienced MCU wranglers aren’t invited to the party; they might just have to broaden their horizons a bit.

To learn more about this interesting paradigm shift, we invited the fine folks at Adafruit to the Hack Chat so the community could get a chance to ask questions about CircuitPython, their in-house Python variant which today runs on more than 400 devices.

Continue reading “The Past, Present, And Future Of CircuitPython”

Closing In On A PC Enabled PSVR2

When the PlayStation VR2 headset was released, people wondered whether it would be possible to get the headset to work as a PC VR headset. That would mean being able to plug it into a PC and have it work as a VR headset, instead of it only working on a PS5 as Sony intended.

Enthusiasts were initially skeptical and at times despondent about the prospects, but developer [iVRy]’s efforts recently had a breakthrough. A PC-compatible VR2 is looking more likely to happen.

So far [iVRy] is claiming they have 6 DOF SLAM (Simultaneous Localisation and Mapping), Prox sensor, and stereo camera data.

Most of the juicy bits are paywalled behind [iVRy]’s Patreon.  We’re hoping the jailbreak process will eventually be open-sourced.

The PS VR2 headset is quite unlike a PC VR headset in a number of ways, and it has not been historically easy to work with Sony’s products from a reverse-engineering perspective, whether it’s an attempt to improve the user experience of an annoying headset, or an attempt to understand the not-even-remotely-sanely-designed protocols behind the Sony Memory Stick. Getting the PS VR2 headset to work in a way it wasn’t intended was expected to be an uphill battle.

It’s not a finished job, but judging by the progress regularly shared on [iVRy]’s Twitter account, it might only be a matter of time.