# Communication-Traffic-Assisted Mining and Exploitation of Buffer Overflow Vulnerabilities in ADASs
## 4 Practical Results and Physical World Threats
### Traffic-Assisted BOF Vulnerability Mining in ADASs  
The first step is firmware extraction. We dismantled the binary data from the device's flash storage chip and used a programmer to read the chip. Then, we used binwalk to extract and decompress the firmware, which allowed us to obtain the files in the firmware. Afterward, we conducted a firmware and system analysis. We conducted a port scan of the device and discovered that the device's SSH port (TCP 22) was open and using a username and password for login. We obtained the device's login credentials using hashcat to brute-force the /etc/shadow file extracted from the firmware. After logging into the device, we examined the system's port listening and corresponding processes, thus locating the binary program. By confirming the source through various means, such as the program name and digital signature, and combining it with the device's network communication flow, we determined that the \"adas_app\" program within the system directory was the relevant business program. The next crucial step was to locate the risk points with the communication traffic. In this case, the \"adas_app\" program listens on two ports, 8080 and 8081. Combining the ADAS communication flow fields, we identified the corresponding functions for each port. Port 8081 was the data receive/send port, while port 8080 was the command receive/send port. We recorded the corresponding port listening functions and examined the parameter passing process to analyze the subsequent data flow and more specific business processing functions. Through a static analysis of the decompiled code of the monitoring section, we discovered that the 8081 port was mainly responsible for receiving the data portion corresponding to the command. We found no security vulnerabilities in this section. The 8080 port was mainly responsible for processing incoming commands. The data structure corresponding to the communication data packet of the 8080 port is shown below. The functions in this section mainly perform validity checks on the \"check\" field and enter different processing branches based on the \"cmd\" field. #pragma pack(1) typedef struct { BYTE cmd; // CMD No DWORD param; // exec param DWORD version; // version id: 1.2.1/1.2.3 BYTE check; // 0 xaa }ADAS_CMD; #pragma pack()  
Specifically, in this business program (in Figure 5), when the \"cmd\" is 6, the program will perform the following data processing operations:  
Figure 5: Business program decompiled code (stack overflow pseudo-code). 1. Receive 12 bytes, take the first byte to represent the \"type\", and multiply the following DWORD values, denoted as A, which represents the number of bytes to be received next. 2. Enter the corresponding function for data reception, and in this function, first, receive A bytes, and then receive 4 bytes again as the data size, denoted as B. 3. Receive B bytes of data. During the execution of step (3), the program will allocate a receiving buffer in the stack, and the length of the buffer is less than 2M. During this process, if a data packet is artificially constructed and the value of the \"B\" field is set to be greater than 2M, the server will wait for and receive the length of data we set, leading to a stack BOF. It is not difficult to see that the program will take the values of A and B from the network communication packet as the size of the buffer allocated subsequently. This defect can be exploited through malicious packet construction to cause a BOF. We attempt to construct a malicious packet of 0 \(\times\) 1,000,000 bytes as a PoC program to trigger the corresponding vulnerability and observe the program's execution results. If a BOF vulnerability exists, the business program will crash and exit, and the corresponding port listener will also be released.