Photo of the head unit , with "Hacked by greenluigi1" in the center of the UI

Hacking A Hyundai Ioniq’s Infotainment System Again After Security Fixes

These days modern cars are nothing if not a grouping of networked software held together by bits of hardware. This is reflected not only in the rapidly increasing number of ECUs, but also infotainment systems and all-glass cockpits. For better or worse, this offers many exciting hacking possibilities, which [greenluigi1] was more than happy to explore with their new 2021 Hyundai Ioniq SEL last year. Naturally, Hyundai then proceeded to ‘fix’ these vulnerabilities, offering the exciting chance to test the Hyundai engineers’ homework, and proceed to bypass it again.

When we last left off in [greenluigi1]’s adventures, the Hyundai D-Audio 2V Linux-based infotainment system (formally called in-vehicle entertainment, or IVI) in question had been convinced to run custom applications after a fair bit of effort to get root access via the Engineering Menu and some firmware image hacking. Joyous hacking and exploration of the car’s CAN network and RPC messaging system ensued. Then Hyundai released a new firmware image, after months of silence and all old firmware images pulled from the download page.

In this new firmware image, big changes were visible right off the bat, with two different ZIP files instead of the single one from before. One of these ZIP files also couldn’t be decrypted any more with the old key. Unfortunately for Hyundai, the curse of backwards compatibility with older IVIs meant that the ZIP targeting headunits running the older firmware also contained the key for the new ZIP file.

Other changes included some further obfuscation to this key and the public key used for firmware hash verification, which also involved using a Micom RPC call via the CAN bus to obtain some vehicle specific information. Unfortunately, this is where Hyundai’s engineered seemed to have stopped copying reference code samples, and used a unique RSA private key to sign firmware images with. Fortunately, they did not bother to check whether the updater actually always verifies the signature, allowing for unsigned code to be installed.

All in all, a fascinating bit of reverse-engineering and sheer stubborn persistence, just so that the IVI that’s in your car can run the applications which you developed. We’re looking forward to the next installments in this series as the ball is once again firmly in Hyundai’s court.

The Integral Molten Salt Reactor And The Benefits Of Having A Liquid Fission Reactor

Although to most the term ‘fission reactor’ brings to mind something close to the commonly operated light-water reactors (LWRs) which operate using plain water (H2O) as coolant and with sluggish, thermal neutrons, there are a dizzying number of other designs possible. Some of these have been in use for decades, like Canada’s heavy water (D2O) reactors (CANDU), while others are only now beginning to take their first step towards commercialization.

These include helium-cooled, high-temperature reactors like China’s HTR-PM, but also a relatively uncommon type developed by Terrestrial Energy, called the Integral Molten Salt Reactor (IMSR). This Canadian company recently passed phase 2 of the Canadian Nuclear Safety Commission’s (CNSC) pre-licensing vendor review. What makes the IMSR so interesting is that as the name suggests, it uses molten salts: both for coolant and the low-enriched uranium fuel, while also breeding fuel from fertile isotopes that would leave an LWR as part of its spent fuel.

So why would you want your fuel to be fluid rather than a solid pellet like in most reactors today?

Continue reading “The Integral Molten Salt Reactor And The Benefits Of Having A Liquid Fission Reactor”

C++17’s Useful Features For Embedded Systems

Although the world of embedded software development languages seem to span somewhere between ASM and C89 all the way to MicroPython, there is a lot to be said for a happy medium between ease of development and features that makes the software more robust without adding overhead or bloat to the final firmware image.

This is where C++ has objectively many advantages over even C99, and as [Çağlayan Dökme] argues in a recent blog post C++17 adds many developer critter comforts to C++98 and the more recent C++11 C++14 standards.

First stepping back a generation (technically two, with C++20 also being a thing already), the addition of binary literals (e.g. 0b1010'1100) in C++14 and the expanded use of constexpr is addressed, with the latter foreshadowing C++17’s increased focus on compile time optimizations. A new attribute in C++17 that is part of this is [[nodiscard]], which when added before to the return type of a function or method requires the return value to be used in some manner, much like with functions in Ada (contrasted with procedures).

As [Çağlayan] notes, the biggest strength of compile-time checks is that it can save a lot of deploy-test-fix round-trips, with the total number of issues caught after deployment that could have been caught during compilation ideally being zero. Here C++17 streamlines the static_assert() mechanism and simplifies using if constexpr to instantiate code depending on compile-time conditions. Beyond compile-time optimizations there are a few other niceties, such as C++17 guaranteeing copy elision (return value optimization) when an object is returned directly, which is a welcome feature in hard real-time environments.

With today even MCUs having enough grunt to run multi-threaded applications and potentially firmware compiled from a many-thousand LoC codebase, picking a programming language that assists the developer with such an arduous task is very important, with Ada being the primary choice for high-reliability embedded platforms, but C++ along with C enjoying the most widespread (free) compiler support. Even if C++ isn’t supported on every single MCU out there (8051-based and most PIC MCUs mostly), whenever it is an option, it’s a pretty solid choice, especially with knowledge of these new language features.

Overall design of retina-inspired NB perovskite PD for panchromatic imaging. (Credit: Yuchen Hou et al., 2023)

Perovskite Sensor Array Emulates Human Retina For Panchromatic Imaging

The mammalian retina is a complex system consisting out of cones (for color) and rods (for peripheral monochrome) that provide the raw image data which is then processed into successive layers of neurons before this preprocessed data is sent via the optical nerve to the brain’s visual cortex. In order to emulate this system as closely as possible, researchers at Penn State University have created a system that uses perovskite (methylammonium lead bromide, MAPbX3) RGB photodetectors and a neuromorphic processing algorithm that performs similar processing as the biological retina.

Panchromatic imaging is defined as being ‘sensitive to light of all colors in the visible spectrum’, which in imaging means enhancing the monochromatic (e.g. RGB) channels using panchromatic (intensity, not frequency) data. For the retina this means that the incoming light is not merely used to determine the separate colors, but also the intensity, which is what underlies the wide dynamic range of the Mark I eyeball. In this experiment, layers of these MAPbX3 (X being Cl, Br, I or combination thereof) perovskites formed stacked RGB sensors.

The output of these sensor layers was then processed in a pretrained convolutional neural network, to generate the final, panchromatic image which could then be used for a wide range of purposes. Some applications noted by the researchers include new types of digital cameras, as well as artificial retinas, limited mostly by how well the perovskite layers scale in resolution, and their longevity, which is a long-standing issue with perovskites. Another possibility raised is that of powering at least part of the system using the energy collected by the perovskite layers, akin to proposed perovskite-based solar panels.

(Heading: Overall design of retina-inspired NB perovskite PD for panchromatic imaging. (Credit: Yuchen Hou et al., 2023) )

ChatGPT V. The Legal System: Why Trusting ChatGPT Gets You Sanctioned

Recently, an amusing anecdote made the news headlines pertaining to the use of ChatGPT by a lawyer. This all started when a Mr. Mata sued the airline where years prior he claims a metal serving cart struck his knee. When the airline filed a motion to dismiss the case on the basis of the statute of limitations, the plaintiff’s lawyer filed a submission in which he argued that the statute of limitations did not apply here due to circumstances established in prior cases, which he cited in the submission.

Unfortunately for the plaintiff’s lawyer, the defendant’s counsel pointed out that none of these cases could be found, leading to the judge requesting the plaintiff’s counsel to submit copies of these purported cases. Although  the plaintiff’s counsel complied with this request, the response from the judge (full court order PDF) was a curt and rather irate response, pointing out that none of the cited cases were real, and that the purported case texts were bogus.

The defense that the plaintiff’s counsel appears to lean on is that ChatGPT ‘assisted’ in researching these submissions, and had assured the lawyer – Mr. Schwartz – that all of these cases were real. The lawyers trusted ChatGPT enough to allow it to write an affidavit that they submitted to the court. With Mr. Schwartz likely to be sanctioned for this performance, it should also be noted that this is hardly the first time that ChatGPT and kin have been involved in such mishaps.

Continue reading “ChatGPT V. The Legal System: Why Trusting ChatGPT Gets You Sanctioned”

The CCTV Cameras That Recorded The Chernobyl Disaster And Aftermath

The Soviet KTP-63-based remote controlled camera system, including switch and control panel. (Credit: Chernobyl Family on YouTube)
The Soviet KTP-63-based remote-controlled camera system, including switch and control panel. (Credit: Chernobyl Family on YouTube)

When we picture the Chernobyl Nuclear Power Plant disaster and its aftermath, we tend to recall just the commonly shared video recorded by television crews, but the unsung heroes were definitely the robotic cameras that served to keep an eye on not only the stricken reactor itself but also the sites holding contaminated equipment and debris. These camera systems are the subject of a recent video by the [Chernobyl Family] channel on YouTube, as they tear down, as well as plug in these pinnacles of 1980s vidicon-based Soviet engineering.

When the accident occurred at the #4 reactor at the Chernobyl Nuclear Power Plant (ChNPP) in 1986, engineers not only scrambled to find ways to deal with the immediate aftermath but also to monitor and enter radioactive areas without exposing squishy human tissues. This is where the KTP-63 and KTP-64  cameras come into play. One is reminiscent of your typical security camera, while the other is a special model that uses a mirror instead of directly exposing the lens and tube to radiation. As a result, the latter type was quite hardy. Using a central control panel, multiple cameras could be controlled.

When mounted to remotely controlled robots, these cameras were connected to an umbilical cord that gave operators eyes on the site without risking any lives, making these cameras both literally life-savers and providing a solid template for remote-controlled vehicles in future disaster zones.

Editor’s note: Historically, the site was called Чернобыль, which is romanized to Chernobyl, but as a part of Ukraine, it is now Чорнобиль or Chornobyl. Because the disaster and the power plant occurred in 1986, we’ve used the original name Chernobyl here, as does the YouTube channel.

Continue reading “The CCTV Cameras That Recorded The Chernobyl Disaster And Aftermath”

Hacking A “Smart” Electric Toothbrush To Reset Its Usage Counter

The visible circuitry inside the brush head.
The visible circuitry inside the brush head.

Following the trend of stuffing more electronics in everyday devices, the new Philips Sonicare electric toothbrush that [Cyrill Künzi] purchased ended up having a ‘brush head replacement reminder’ feature that wasn’t simply a timer in the handle or base of the unit, but ended up involving an NFC chip embedded in every single brush head containing the usage timer for that particular head. Naturally, this asked for it to be solidly reverse-engineered and hacked.

The NFC chip inside the brush head turned out to be an NXP NTAG213, with the head happily communicating with the NFC reader in a smartphone and the NFC Tools app. This also revealed the memory layout and a few sections that had write access protected by a password, one of which was likely to be the counter. This turned out to be address 0x24, with a few experiments showing the 32-bit value at this address counting the seconds the brush head had been used.

Continue reading “Hacking A “Smart” Electric Toothbrush To Reset Its Usage Counter”