This article mainly expands from the following four aspects.
1）. Basic knowledge of smart devices
2）. Ten ideas for extracting firmware
3）. Ideas to discover vulnerabilities from firmware
4）. Reinforcement suggestions for smart devices
I. Basic knowledge of smart devices
This is the composition of a smart device, which is divided into several parts. The smart device must have several things. For example, it must have a CPU, a memory, a flash equivalent to a hard disk, a network, a network port, a serial port, and sometimes an SD card Socket storage devices, and some have display interfaces.
CPU has many architectures, such as X86, MIPS, ARM, etc.; memory is divided into several types. There are also various kinds of storage, such as flash, TF card, mmc card, hard disk; general circuit boards will have serial ports, especially when debugging. The problem that manufacturers have to face when doing maintenance: If a problem occurs in the use of a smart device, the customer requires it to be solved immediately. If the developer does not have a maintenance interface, the developer may not be able to solve the problem when it comes to the site. So these are necessary; sometimes it is a serial port, sometimes it is a network port, and sometimes it is a USB port. The software running in the smart device is also called firmware. The firmware has a part to boot the system. Uboot is commonly used, which occupies a large market share. Linux operating system is used in many cases because it supports the network very well.
Let me introduce to you what a serial port is. Serial ports are generally divided into two types, mainly RS232 or TTL, TTL is 5V or 3.3V, which is equivalent to the voltage of the CPU. The lower left corner is the definition of the serial port. The serial port really refers to three lines, namely RXD, TXD, and DCD. During serial port transmission, when there are three wires, it is transmitted according to a certain timing. This timing has a certain period, and this period is generated asynchronously. Asynchronous transmission has a concept of baud rate: For example, the baud rate of 9600 is converted to about 1000 bytes per second. The higher the baud rate, the faster the transmission.
Flash is more important in the composition of smart devices. There are two types, one is Nor falsh, which is characterized by relatively expensive price, small capacity, separate address lines and data lines, and the advantage is that the CPU can be directly addressed , Because each address line on the circuit diagram is connected individually, and the data line is also connected separately. It is commonly used for code storage. The larger the storage capacity, the more address lines there will be.
Calculate the addressing range of the nor Flash address line in the above figure:
8MB = 0x800000 (hexadecimal)
Converted to binary: 100000000000000000000000
The address line happens to be from addr0-addr22. The maximum address is 22 ones.
There is also Nand Flash, which is cheap and has a large capacity. It is mainly used for data storage, but this thing is generally not addressable and requires a driver.
Let’s talk about Uboot and busybox in the software. Uboot has a function in the embedded boot program, which is used for booting when booting, and another function is used for updating. There are many types of CPUs supported, such as ARM, Linux, Both MIPS and PowerPC support, as well as simple network commands and the like. Busybox integrates more than 300 commonly used Linux commands and tool software. It is very compact, about 1-2 megabytes after compilation, but supports a lot of commands, and can be cut as needed. For example: some of the busybox commands nc, dd, tar, etc. are cropped.
This is the cooperative relationship between the software and hardware of the smart device. Taking the Linux operating system as an example, the upper part is the memory, the lower part is the storage flash, and the middle is the firmware. The Uboot in the firmware is used for booting at startup. It starts up as the kernel, followed by the file system, which includes RAMFS and FALSH FS.
（Maintenance interface for smart devices
1) Download firmware interface (hardware interface: JTAG/SWD port, network protocol: TFTP/FTP, custom protocol)
2) BootLoader upgrade interface
3) SD/TF card upgrade interface
4) USB upgrade interface
1) Network/USB log interface
2) Debug interface (usually TTL serial port; there are also telnet/ssh network protocols, etc.)）
The above is the upgrade interface. We must have a certain understanding of the maintenance interface. Why? Because the interface is very important, one is used for upgrading, the other is used for debugging, and the other is for upgrading firmware. The debugging interface basically has these functions.
I just gave a general introduction to the basics. For example, I want to extract its firmware, and its firmware is stored in the flash. I must have some understanding. There must be research on serial ports and interfaces. In addition, the firmware supports these programs. You must have a certain understanding of the file system and basic small commands. The knowledge and skills can be used to great effect.
II, ten ideas for extracting firmware
These ten ways of thinking are the ten methods I often use, and the other methods do not mean that they do not exist. Firmware extraction methods are simply divided into two types: hardware and software.
Ten ideas for extracting firmware from smart devices:
Here are nine firmware extraction methods, and the last method will give you a surprise!
1. Ask for an upgrade package on the official website or contact after-sales. Not much to say about this.
（Official website or contact after-sales service to get the upgrade package
>Applicable when the official website provides downloading smart device firmware
>Some manufacturers can only provide firmware from agents and official after-sales
>The official website may not provide firmware; or old firmware
>For industrial control equipment, firmware or encrypted firmware is rarely provided
2. Extract the firmware through online upgrade. If there is a mobile phone application or a computer application, you can click “Upgrade”. When you upgrade the firmware, you can capture the firmware by capturing the package. If the download addresses of the old version and the new version of the firmware have a certain naming rule, if the new version is caught, the old version can also be guessed.
（Extract the firmware by online upgrade
>Online upgrade, capture package, analyze firmware address, download firmware
> Both new and old firmware:
>Record the firmware version and name before upgrading
>After upgrading, splice the old firmware address according to the naming rules.
3. Reverse upgrade software, built-in unpacking and communication algorithms. If it is designed to be decrypted on the lower computer, it is slightly safer; if it is decrypted on the upper computer, it can be reversely cracked.
（Reverse upgrade software, software built-in unpacking and communication algorithm
>The manufacturer provides the upper computer to upgrade the software. Before upgrading the software, decrypt the firmware on the upper computer first, and then transfer the unencrypted firmware to the device for upgrade
Decrypt the upgraded firmware part; grab the data package
4. From the debugging interface: Obtain the firmware by JTAG/SWD and other methods.
From the debug interface: get firmware from hardware interfaces such as TAG/SWD
>If there is a ready-made JTAG interface on the circuit board, use JAC to establish a connection and read out the burned firmware.
>Business solutions: Ilink, Xitag>
Open source solutions: GDBs, OpenOCD
>Prerequisite: JTAG interface is required on the circuit board, disadvantages: There are not many circuit boards with JTAG
>Exception: The firmware is stored in the FLASH in the CPU, and encryption is not enabled
5. Disassemble flash, SD/TF card, hard disk, etc., and use programmer/card reader to obtain firmware.
Commonly used is to remove the flash chip, read the firmware with a programmer, and then solder the chip back after reading.
（ Disassemble Flash, SD/TF card, hard disk, etc., use programmer to get firmware
Only three steps are required:
>Remove the flash chip
>Use the programmer to extract the firmware content
>Soldering the FLASH chip back to the circuit board
It should be noted that the chip has a direction. There is a dot on the first pin. When soldering or reading with a programmer, find out the direction of the chip.
6. Obtain the firmware from the serial port (UART) debug port.
（＞Prerequisite: there is a city port debugging connection on the development board, we need to find out the hidden serial port
＞The serial port has two standards according to voltage: RS232 standard and TL standard
RS232 standard: Voltage range: -12V, +12V (negative logic)
TTL standard: Voltage range: 0，5V
Serial port pin identification method: serial port generally has 4 pins
＞ vCc: The power supply voltage is 3.3V or 5V
＞GND: Power supply voltage ground
＞RXD: data receiving pin, the voltage measured by the multimeter is the bottom (it may be high if the hardware is pulled up)
＞TXD: data sending pin, the voltage measured by the multimeter is generally high）
This method is summarized when I help customers test products in security testing.
During the security test, I found a loophole in uboot extracting firmware, and summed up a series of firmware extraction methods.
What I do most often is research on the security of industrial control equipment vulnerabilities. Basically, I can’t get the firmware. The firmware I get is also encrypted, which has troubled me for a long time. After a period of exploration, there are about 10 successful cases of extracting firmware. In terms of cameras this year, ordinary IoT routers, cameras and other similar devices, after practical research and 20 or 30 successful cases, found that the method of extracting firmware through the serial port is the safest and most reliable. Why do you say that? When I went to do a test for a customer, the customer said that it doesn’t matter if you break it, but the sample is only one! I want to remove the flash to extract the firmware, but this is the device. In case the soldering chip breaks the device, the vulnerability cannot be verified later. The key is that an industrial control device costs thousands or tens of thousands of dollars. Once the equipment is broken, it will be more embarrassing. So I slowly figured out some ways to share with you here.
Serial port identification: There are two standards for serial port identification. When the serial port is identified, it is usually after the device is disassembled. The serial port generally has four pins. The first step is to find the ground (GND), which is easy to find. The one connected to the power supply is the ground, or the chip is connected to the ground. After the ground is confirmed, we connect it to the USB interface. I first connect the receiving pin, both pins may be high-voltage, then connect the receiving pin to the ground, and then connect a pin randomly. Once the device is started, if there is output at this time, it is It is connected; then connect the other pin, and the three pins are connected. I usually find the serial port based on the above idea.
The following content is visible to members
[wc_pay_can_read id=’2026,2029,2030′ tishi=’You do not have permission to read this content, click here to become a member and refresh this page to read it’]
7. Obtain sensitive information of firmware by using web pages and communication vulnerabilities.
This will not be a demonstration, as long as it is safe, this is a small problem. The sensitive information can be extracted through the web page, and then the password can be generated through the dictionary to brute force the device password. Generally, the permissions of the embedded system are not properly configured.
8. Use a logic analyzer to monitor flash and ram to obtain information.
Its advantage is that there is no need to dismantle things, just connect this thing, and this thing is also very easy to connect. But the disadvantage is that the current low frequency of the logic analyzer is cheap, but the flash frequency is generally higher, both 100M and 200M. I did an experiment and found that it is indeed possible. These pins need to be brought out, grab data when it starts, and clamp it on the chip with a clip. The red pin is the first pin. After capturing the above, save the transmitted data through the SPI interface.
The previous is the SPI command, and this is the output data in the command. The first one in the front means reading, these three should be addresses, and the latter is data. Here is the command issued, and the other is the received command. The result is that the logic analyzer extracts the same binary value as the firmware in the flash, indicating that this idea is feasible. I found a slower one at the time. The firmware can also be extracted from the selected device.
9. Use tar/dd, nc to extract the firmware.
Using the original hardware interface and then using its original software may achieve a multiplier effect without soldering the board. Here, the serial port is used first, the system permission is obtained through the serial port, and the firmware is transmitted from the network with nc.
（Use tar/dd, nc to extract the firmware
＞1. Have obtained system shell authority (network or serial port)
＞2. The following three commands are available (or equivalent alternative commands)
＞ifconfig (known or configurable IP), Do, tar (eip/d)
＞In the serial port command mode
＞Pack the firmware with tar, or use the dd command to get the firmware
＞Use ifconfig to configure the ip address, and use the nc command to connect to the local machine
＞Transfer the packaged firmware through the nc command
10，Let’s talk about uboot
Speaking of uboot earlier, there is 3 seconds each time it starts. This time can be set. Generally, there are 3 seconds waiting for input (or other shortcut keys, usually with prompts). After entering uboot mode, uboot has help commands , One of these commands caught my attention, that is md. What is the role of md? Display memory, able to display memory. It is found that as long as it is Nor flash, md can display the contents of Nor flash (because nor flash can be directly addressed by the CPU), which is equivalent to the md command to extract the firmware. But the md command needs to know the starting address and length. Knowing the starting address and length can extract the firmware. How do I know the starting address and command? I checked the information of more commands and found that bdinfo and flinfo can check the starting address and capacity of the flash. If you still can’t find it, restart it. Don’t interrupt it to see if it will print more flash address distribution information. You can basically find the starting address and extract the firmware through this information.
The process of extracting firmware from uboot is summarized: The first step is to obtain flash storage information. For example, how big is its flash, what model is it, and what is the address range where the CPU accesses it? In the second step, use the md command to extract the firmware information. The third step is to record it. The fourth step is to analyze the output information and obtain the firmware. But the disadvantage of this method is that it takes a little longer, sometimes half an hour, sometimes 2 hours. But it doesn’t matter, as long as you can extract the firmware stably, don’t damage the hardware, solder 3 wires and it can be done.
I tried it with simple commands and I was able to read the kernel. In the next step, read it all out and extract the firmware. Convert the file to binary, which is the firmware I want.
Next,Let’s talk about:Modify the uboot startup script to enter the password-protected login system. There are 5 items in total, each of which is an idea to enter the system without a password.
(1. Modify Uboot startup parameters, let the embedded system run the modified file system through TFTP, and then extract the firmware after the system is running
2, If you can mount this hard disk with third-party linux, the cracking is very simple, just replace passwd and shadow in the /etc directory, and the root item of shadow-
3, X86 system: use the USB version of linux to hang up, then mount, similar to WinPE intrusion
4, Similar to the solution of the linux system forgetting the password: add a “single” and “init-/bin/sh” to the startup option
5. Let the system execute the delete password command when it starts. Add an init= ＇passwd root -d’ to the startup option)
About the difficulty of extracting firmware，there are many successful cases, and there is no failure case. Summarized into three difficulties (the third difficulty is not mentioned), Level1 is the easiest, it can be done with md, and only Nor flash is used for storage.
Level 2 means that there are other file systems in Nand flash. Here is a command to read nand flash to the memory first, and then use md to read the memory. This simple idea can be used.
Firmware extraction skills: uboot command summary
uboor command: The command to obtain the address storage information of the firmware in the flash is as follows:
printeny, flinfo, ubifsls, iminfa, bdinfo, sf probe, base, etc.
uboot command: The command to read the firmware content in flash to the memory is as follows:
mtdparts default, loada, loadk, cp, sf read, ext4load, fatload
uboot command: The command set for reading memory is as follows:
md, md64, md.b, md.w, md.1, mm
This is my debugging experience at the time, and I found that the above commands can be used to obtain information. The other requires a restart, and the key address information is sometimes printed when restarting.
There is also a read command, which reads the md in the flash directly. If it cannot be read, use other ideas. Reading the storage of the SD card or other file system into the memory, and finally reading it from the memory, is basically this idea.
Uboot extract firmware is not for a certain manufacturer, almost all manufacturers have uboot security issues. 95% of embedded devices use uboot as its startup, which is basically equivalent to a standard configuration of embedded Linux. This method may become a popular method for extracting firmware in the future. I found that the firmware can be extracted basically.
If you get permission through the serial port, if you are lucky, it does not have a login password. If you can enter the system, use this method: execute the copy command and package command through a USB or SD card, and pack this into a U disk or large In the internal memory file system, then copy to the external file system (U disk or TF card).
The second is to find that the echo command can be written into “1234567” in binary mode, binary files are sent by input commands, Trojans are transmitted by commands, and the firmware is output by this Trojan, and the output is recorded through the serial port. This is also an idea. .
Summarize the firmware extraction method: uboot is common in smart devices. If the md-like commands are not blocked, the firmware can be extracted easily. The smart device firmware is stored in the flash, and the flash has no measures to protect the firmware from being illegally read. If FLASH and RAM are integrated on the CPU and encryption is turned on, it is more difficult to extract the firmware. But if it uses another method: (FLASH, RAM, and CPU are independent), it is particularly easy to extract the firmware, because the content in the flash can be read directly by the programmer when the FLASH is removed.
The hardware debugging interface method is convenient for maintenance, but sometimes it is also convenient for hackers. If the software has a back door, it is easy to maintain, but if the password is too simple, it is easy to be cracked or guessed, or easy for others to analyze from the firmware. The conclusion is that the current architecture of some smart devices has certain security risks.
III. Ideas to discover vulnerabilities from firmware
I use binwalk to disassemble the firmware. Some colleagues can’t disassemble it with binwalk, but I can. Why? Because it does not master the installation method of binwalk, binwalk has some dependent software, and all these dependent things must be installed. There is a command (./deps.sh) that needs to be executed, which will install all related dependent software, and extract it after installation. I use the -Me method to extract the firmware.
Here is an example. You can crack the Linux login password by brute force cracking through the password dictionary. If the password is relatively simple, it will be cracked quickly.
If I have no ideas for all the problems, I just think about what the developers will do? What debugging backdoor will he leave behind? What is the interface? After you extract the firmware, can you view the sensitive information of the system in the firmware? Have a look at the manufacturer’s backdoor password for maintenance? It’s easy if there is a backdoor password. After reading these, look at how many network services and network ports there are in total, and whether there are any overflow points in the binary of the network service running. Debug the web call interface to see if there are any problems. Basically these ideas are very simple.
IV, reinforcement suggestions for smart devices
Information hiding is very important. For example, uboot extracts the firmware because it knows what chip it is. If the chip is polished, it may be better, or the package can be changed. This important information should be hidden.
（Critical chip grinding or corrosion marking.
Chip packaging can be customized for large quantities.
Do not expose the purpose of the interface to the PCB board logo.
Don’t be so obvious when entering uboot, only the developer can know the way to enter.
Important firmware is recommended to be released encrypted, do not decrypt the firmware on the upper computer, and decrypt the firmware and flash in the lower computer.）
Can the debug interface be blocked? For example, the debugging interface of software and hardware can be shielded, or can the functions not used in busybox be removed and cut out. For example, smart devices have root privileges to enter the system. If the privileges are too large, there are too many things that can be done. These can be avoided and root privileges are not necessary.
（After burning the firmware, the debug pins are damaged before leaving the factory. Make it not work
Entering the uboot menu requires asymmetric key verification
uboot needs to verify the signature of the firmware
It is recommended to remove the uboot options that are not needed or understood at the moment
The system permissions should be as small as possible and just meet the operating conditions.
Cut out the unused functions of busybox (ncld\tar…)
Other reinforcement suggestions
Do not store passwords in clear text
The password is as complex as possible to avoid guessing the password
Turn off network services that are not related to the application
Each branch of the program has complete and clear processing logic
Validate user input and escape output
Products with high requirements for completeness can be handed over to a professional team for safety testing