Published the security firmware analyzer code FwAnalyzer.

Cruise, a company specializing in autonomous vehicle technology, opened the source code of the project FwAnalyzer, provides tools for analyzing Linux-based firmware images and identifying potential vulnerabilities and data leaks. The code is written in Go and is distributed under the Apache 2.0 license.

supports analysis of images using ext2/3/4, FAT/VFat, SquashFS, and UBIFS file systems. Standard utilities such as e2tools, mtools, squashfs-tools, and ubi_reader are used to extract the image. FwAnalyzer extracts the directory tree from the image and evaluates its contents based on a set of rules. The rules can be tied to file system metadata, file types, and contents. The output is a JSON report summarizing the information extracted from the firmware and providing warnings and a list of files that do not comply with the processed rules.

It supports checking file and directory access rights (e.g., detecting world-writable permissions and incorrect UID/GID settings), identifies executable files with the suid flag and the use of SELinux labels, and detects forgotten encryption keys and potentially dangerous files. The content highlights any leftover engineering passwords and debugging data, provides version information, performs identification/comparison of the contents using SHA-256 hashes, and supports searching with static masks and regular expressions. External analysis scripts can be linked to specific file types. For Android-based firmware, it determines build parameters (e.g., use of ro.secure=1 mode, ro.build.type status, and SELinux activation).

FwAnalyzer can simplify the analysis of security issues in third-party firmware, but its primary purpose is to ensure the quality of one’s own firmware or those supplied by third-party vendors under contract. FwAnalyzer rules allow for creating an accurate specification of the firmware state and identifying unacceptable deviations, such as granting incorrect access rights or leaving behind closed keys and debugging code (e.g., checks allow avoiding situations such as leaving the ssh server used during the testing phase, a predefined engineering password, available read access to /etc/config/shadow or forgotten keys for digital signature generation).

Source: opennet.ru