NDSS 2023 highlights. Part 3

NDSS 2023 highlights. Part 3

In this part, you will find out how to:

  1. Reverse engineer an OS not supported by existing tools
  2. Drive away someone else's Tesla 3
  3. Paralyse drones


An OS-agnostic Approach to Memory Forensics by Andrea Oliveri , Matteo Dell'Amico , and Davide Balzarotti presents an elegant and efficient solution to recovering forensics data structures (such as process list) from memory dumps of OSes not supported by tools like Volatility. The existing tools rely on manual reverse engineering to create a profile of the specific OS. Even these manual efforts are not enough for custom-built Linux kernels, not to mention many different IoT devices and gadgets, RTOSes, microkernels, and more...

No alt text provided for this image


The core idea of this paper is to reconstruct the forensics-relevant data structures based on their topology (double-linked lists, arrays, trees) and the fact that they all store pointers. The work starts by identifying all potential pointers in the dump (filtering out values that do not fall into the kernel address space). A fully-automated analysis of the collected pointers, their addresses, and the offsets between them allows for identifying the data structure types (lists, arrays) the pointers belong to. The last piece is to determine the boundaries of the structs holding the pointers (e.g., to find where a node in the linked lists starts and ends, given its field pointing to the next node). This is done using statistical analysis based on the observation that the fields at the same offset should contain the same type of data and the same values' distribution.

What can you do with all these anonymous structures? It turns out that having a single seed (a known value, e.g., a name of some process) is enough to find the structure describing or pointing to this seed of interest and to recover the rest of the pieces of data from the same type (e.g., the list of running processes). The authors were able to extract process lists for 16 different OSes, including the closed source (Windows), real-time (vxWorks), and microkernel-based (Helen-OS) - in a completely automated and OS-agnostic way. For many other details of this challenging work, please refer to the paper and monitor the repo, which is still empty at this point, but will contain this interesting tool. It would be interesting to see if and how these ideas can be applied to code written in languages like Rust, but this is not a practical problem yet, just interesting research to be done.




Access Your Tesla without Your Awareness: Compromising Keyless Entry System of Model 3 by a group of researchers from SHANGHAI FUDAN MICROELECTRONICS GROUP CO., LTD provides very interesting insights into the design and vulnerabilities of the new way of unlocking Tesla Model 3 - and even demonstrates how these can be exploited.

The paper describes Tesla's Passive Keyless Entry and Start (PKES) protocols - unlocking the car with Key Cards and the mobile app's Phone Key. These details were not publicly available and were discovered by reversing of the mobile app and sniffing the RFID and Bluetooth (BLE) communication. It turns out that Tesla is using ECDH public-private keys for authenticating the device and then AES_GCM to encrypt the data. The car and the KeyCard keep their keys in a secure element(SE), which is a pretty strong security measure. The protocol itself uses counters to prevent replay attacks. However, the keys are not authenticated. This means that one can build or buy an unofficial key card opening doors for further vehicle manipulation. But there is more - the PhoneApp allows for a well-known relay attack, where the attacker passes the communication messages between the car and the owner's phone using two phones.

No alt text provided for this image
No alt text provided for this image


This is possible due to 1) unencrypted BLE, which allows for protocol sniffing and parsing, and 2) combining messages, thus avoiding latency detection (a common practice for detecting relay attacks). Consider an owner who left the car in the parking lot and entered a nearby coffee shop. The attacker uses two phones,s one (A) near the car, and another (B) near the owner. The attack starts with device A sniffing the car's MAC address (which is broadcasted), passing it to B, and B changing its MAC to the one of the car. Now B pairs with the owner's phone forwarding the phone's messages to A, A forwarding them to the car and returning the responses. Neither A nor B can understand the passed messages, as they are encrypted but do not need to.

The authors have implemented this attack by modifying standard Android Bluetooth stack behavior to be able to spoof and fix the MAC address (they also describe how exactly. If it is your thing - look in the paper). With the help of the malicious app holding the attacker's logic, they unlocked a real Tesla 3 car in 15 seconds.

As for countermeasures - the two most prominent are 1) using PIN to drive (albeit it does not prevent entering the car and is counter to the idea of Keyless Start) and 2) measuring the time of flight to detect the relay attack.

Even though relay attacks are well-known, I appreciate the hard work put into reversing and building a real-world attack and making all the information public so we can learn from others' mistakes.



Paralyzing Drones via EMI Signal Injection on Sensory Communication Channels by a team of Prof. Yongdae Kim from KAIST presents a novel way to shoot down drones.

No alt text provided for this image


The key idea is simple: to corrupt the communication between the drone's sensors and its controller. Drones rely on their inertial measurement unit (IMU) to orient in space. Previous research has attacked IMUs using acoustic waves that resonated with the frequency of the mechanical sensors of IMU. Such attacks require precise calibration, knowledge of the attacked drone's sensors and can be easily thwarted by plastic shielding. This paper shows how to distort the signals passed from IMU using electromagnetic inference (EMI). Such attacks were proposed previously but deemed unpractical. This work presents the first EMI attack on real-world drones without requiring high power (< 100W).

One important aspect to realize is that the effect of EM waves on a circuit depends on the circuit design. The circuit (its resistors and capacitors) becomes an antenna and absorbs these EM waves. Thus each drone's control board circuit has some frequency where it is significantly more sensitive to the EM waves transmitted onto it (the sensor's model makes less difference). So the attackers need to identify the target drone and detect its frequency in advance.

No alt text provided for this image

The paper presents a detailed description of the experiments and their reasoning. The authors attacked both I2C and SPI communication protocols.


No alt text provided for this image

An I2C SDA and SCL signals are shown in the picture to the left. Voltage above 2.3 V means 1, below 0.9 - 0. It is easy to see that the distorted SDA has lots of bits flipped.



The attack is especially interesting as it is targeted (each board has its EMI-sensible frequency) and immediate (the drones crash instantly). However, it is still relatively short range: the experiments were conducted at a few meters, and according to calculations, it will require about 300kW to crash a DJI drone at 100 meters. As for countermeasures, shielding will help, but it has severe heat implications and interferes with the drone's magnetometer. The paper has more interesting ideas, and I strongly recommend reading it.

If you find it useful, please give it a like and/or repost.

The previous part of the NDSS review is here.


要查看或添加评论,请登录

Moshe Kravchik的更多文章

社区洞察

其他会员也浏览了