reverse engineering of firmware for parrot skycontroller uav

Introduction

Parrot skycontroller is a long-distance flying drone, sometimes sold to the real estate industry for 3D modeling work. It integrates the smartphone and tablet client, carries out flight control through WiFi connection, and allows real-time data transmission from the UAV to the control terminal. In other words, skycontroller acts as an intermediary between the aircraft control software (Smartphone / tablet) and the actual UAV. In this article, we'll learn how to reverse the firmware of skycontroller so that we can see the contents of the internal operating system and understand its internal working principle.

Content

Parrot skycontroller's firmware seems to be a well-defined structure that can be reused in multiple products of the company. The firmware contains two types of structure headers and a sequence of "data items.". The header file is located at the beginning of the file, followed by multiple entries containing configuration and file system information. We will discuss these two structures below.

The firmware header starts with four magic bytes and outputs "PLF! ". Therefore, these can be used to identify valid parrot firmware files. Here is a python snippet as an example

Immediately after the magic byte, a sequence of thirteen 32-bit unsigned integers provides additional information about the firmware. It is defined as a · C file. The header file is as follows:

The header file specifies the type of format to use for the firmware header. In the skycontroller firmware, the value of this field is "0x0D", which may indicate that there are 14 changes in the header file. The header file size provides the number of bytes included in the header, while the entry header file size specifies the number of bytes in the header of an entry within the firmware. The next five integers are undefined, just like the last one before. One of them may be the CRC32 checksum. Dwversionmajor, dwversionminor, and dwversionrevision define the version of the firmware. Finally, the header contains the size of the file in bytes.

Entry

Each entry has a constant size header specified by the dwentrysize value in the firmware header. In skycontroller, each entry consists of 20 bytes, as follows:

Byte type specifies the type of data contained in the entry. These data can be configuration data, partition details, or file information. These will be explained in more detail in the text below. The entry size contains the number of bytes in the entry, regardless of empty byte padding. This field is followed by a CRC32 value. It is not clear how this value is calculated. The last known integer is the size of the uncompressed data. If this value is 0, the content is not compressed. Each type of entry has additional fields defined, and these are explained below.

Firmware entry

There are many types of entries in the firmware. In this section, we will describe one of the documents we encountered in our analysis.

Boot loader and boot configuration (0x03, 0x07)

Entry 0x03 contains a binary file that appears to be based on the system's boot loader for the strings contained in it, but requires more analysis to see how it actually works. In skycontroller, a PLF file was observed, but in the PLF file, the entry has binary data. For another example, entry 0x07 also seems to be related to the boot process, as shown in the string "ecos bootloader-p7-start-246-ge30badf", and "eCos" refers to the eCos operating system.

File system data (0x09)

Each file contained in the firmware has a file system data entry. Therefore, this entry is the most common. Depending on whether the file is compressed or not, the structure of this entry is slightly different: when its contents are not compressed, this entry starts with the file name (or directory name), which is a zero terminated string. The name is followed by three char free integers.

The first integer contains the flag for the specified file type, which can be a directory, a normal file, or a symbolic link. This is specified by reading bits 12 through 15. The other 12 bits contain permissions for the file. Convert to octal, the last 12 bits will provide the same format as used in Linux. For example:

Extract file permissions from firmware entries

When compressed, the flag is in gzip compressed data. Therefore, you must first decompress the data, and then use the same process: the filename will be a string ending in an empty character, with the first containing type and permission after three unsigned integers. The remaining bytes are the contents of the file. In the following example, the filename is system / pulsar / etc / boxinit.hosted. The flag is 0x000081a0 (small end), and the content of the file starts from 0x32.

Partition data (0x0b)

The 0x0b entry contains information about the partition on the device. The title of this entry consists of 10 values. The first four integers are version information, the next five are unknown, and the last unsigned integer is the number of partitions defined in the entry.

For each partition defined within an entry, you can use subentries that contain more information about the partition: device ID, volume data, and mount points on the target device. The definition structure of this entry is:

Volume types can be raw, static, and dynamic. The original partition does not contain any file systems, such as swap partitions. Static partitions are read-only, such as boot partitions. Finally, dynamic partitions are read-write and contain modifiable files.

Installation data (0x0c)

This entry is already included in the file and contains another PLF file in its data. This PLF file contains 0x00 entries, unknown, 0x03 entries, and 0x07 entries. 0x07 entry contains boot options:

conclusion

I've uploaded a python program that contains information and files extracted from skycontroller firmware. It has also successfully extracted a bebop2 firmware file, which I think will apply to other recent firmware. For other compilation work, it may also be able to reverse the old version of firmware. Repacking the uncompressed firmware should be possible, but I don't have any devices to test. Before you do this, you need to determine how to calculate the CRC values for the header file and each entry. Future work will include testing additional firmware files and implementing programs to repackage unpacked and modified firmware. Finally, you can read the eCos documentation to see many unrecognized values.

Original: http://thecyberrece.net/2017/01/09/reversing-the-parrot-skycontroller-firmware/

This article is compiled by linso

Hacking Book | Free Online Hacking Learning