Start protection method, electronic device, storage medium and computer program product

Abstract

The invention relates to the technical field of terminals, and provides a startup protection method, electronic equipment, a storage medium and a computer program product. In the method, when the electronic equipment detects a startup instruction and runs a first section of startup code in BootRom, if a stack building instruction for a function included in the first section of startup code in BootRom is executed, a random function is called to generate a random value, so that the length of a stack built by the stack building instruction is changed, and the length of the stack built by the stack building instruction is changed. And storing return addresses of other functions called by functions included in the first segment of startup code in the BootRom into the stack of which the length of the stack is changed. Therefore, the actual memory address for storing the return address in the stack can change along with the random value during execution each time, so that an attacker is difficult to determine the return address to be tampered, a malicious program tampered by the attacker can be prevented from being jumped to and executed, and the security of equipment can be improved.

Description

Technical Field

[0001] The present application relates to the field of terminal technology, and in particular to a startup protection method, electronic device, storage medium and computer program product. Background Art

[0002] BootRom is a read-only memory solidified inside the system-on-chip (SOC) for storing the first boot program required for the electronic device to start up. After the electronic device is powered on, the first boot program in BootRom can be run to initialize the software and hardware in the electronic device, such as resetting registers. Then, the image file of the boot loader (such as xloader) can be loaded into the memory, and a signature check can be performed to prevent the boot loader from being tampered with. After the check passes, the boot loader (such as xloader) can be run. After that, the boot loader (such as xloader) can load the fastboot program into the memory and perform a signature check to prevent the fastboot program from being tampered with. After the check passes, the fastboot program can be run, and then the fastboot program can load the kernel image file of the operating system (such as the image file of the Linux kernel) into the memory, and perform a signature check to prevent the operating system from being tampered with. After the check passes, the operating system can be run, and the system's built-in applications or third-party applications can be loaded according to the user's settings or default configuration.

[0003] Therefore, BootRom is the basis for secure booting of electronic devices. However, BootRom currently does not have security protection mechanisms similar to those of operating systems, such as memory isolation and memory overflow prevention. These security vulnerabilities can be exploited by attackers to spread malicious applications, seriously affecting the security of electronic devices. Summary of the invention

[0004] In order to solve the problem that BootRom has no security protection mechanism, which affects the security of electronic devices, the embodiments of the present application provide a boot protection method, an electronic device, a storage medium and a computer program product.

[0005] In a first aspect, an embodiment of the present application provides a startup protection method, which is applied to an electronic device, comprising: detecting a startup instruction of the electronic device; during the Nth running process of the startup program, corresponding to the execution of a first stack building instruction of a first function included in the startup program, calling a random function to generate a first random value, wherein the first stack building instruction is used to indicate the establishment of a first stack with a first length of the first function, and the storage data of the first stack includes a return address, and the return address is the address of a second function that needs to be executed after the first function is executed; based on the first random value, modifying the first length of the first stack to a second length to obtain a second stack; storing the return address in the second stack, wherein the return address has different memory addresses in the first stack and the second stack; and executing the second function based on the return address in the second stack.

[0006] Based on the above scheme, the actual memory address storing the return address in the stack can be changed with a random value each time it is executed, making it difficult for an attacker to determine the return address to be tampered with, thereby preventing the attacker from jumping to a malicious program tampered with by the attacker and executing the malicious program, thereby improving the security of the device.

[0007] It can be understood that detecting the power-on instruction of the electronic device may refer to: detecting that the user presses the power button of the electronic device to power on the electronic device. The power-on program may be the first startup code in the BootRom.

[0008] In some implementations of the first aspect, executing the second function based on the return address in the second stack includes: after the first function completes calling the third function, executing the second function based on the return address in the second stack.

[0009] In some implementations of the first aspect, calling a random function to generate a first random value includes: corresponding to the number of rounds of calling the random function being equal to a preset round threshold, reading a first value from a first memory address; if the first value is less than a boundary memory address of a boot program, determining a second memory address based on the first memory address and the first value; if the first value is greater than the boundary memory address of the boot program, using the first value as the second memory address; and using the second memory address as the first random value.

[0010] For example, when the total number of rounds (i.e., the preset round number threshold mentioned above) is 0 and the current number of rounds (i.e., the number of rounds of calling the random function mentioned above) is 0, the mobile phone 100 can use the function addr=*(addr) to read the value a (i.e., the first numerical value) in the fixed address (i.e., the first memory address mentioned above). If a is less than 0x20000 (i.e., the boundary memory address mentioned above), a+0x20000 can be used as the new address (i.e., the second memory address mentioned above), otherwise a can be used as the new address (i.e., the second memory address mentioned above). At this time, the total number of rounds is equal to the current number of rounds, i.e., counter==num, and the new address a+0x20000 can be returned.

[0011] In some implementations of the first aspect, the method further includes: updating a preset round number threshold in response to determining the second memory address.

[0012] In some implementations of the first aspect, the method further includes: corresponding to determining the second memory address, updating the number of rounds of calling the random function.

[0013] In some implementations of the first aspect, the method also includes: corresponding to the number of rounds of calling the random function being less than a preset round number threshold, reading a first value from a first memory address; if the first value is less than the boundary memory address of the boot program, determining a second memory address based on the first memory address and the first value, and updating the number of rounds of calling the random function; if the first value is greater than the boundary memory address of the boot program, using the first value as the second memory address, and updating the number of rounds of calling the random function; corresponding to the updated number of rounds of calling the random function being equal to the preset round number threshold, reading a second value from the second memory address; if the second value is less than the boundary memory address of the boot program, determining a third memory address based on the second memory address and the second value, and if the second value is greater than the boundary memory address of the boot program, using the second value as the third memory address, and using the third memory address as the first random value.

[0014] For example, when the total number of rounds (i.e., the preset round number threshold mentioned above) is 1 and the current number of rounds (i.e., the number of rounds of calling the random function mentioned above) is 0, the mobile phone 100 can use the function addr=*(addr) to read the value a (i.e., the first numerical value) in the fixed address (i.e., the first memory address mentioned above). If a is less than 0x20000 (i.e., the boundary memory address mentioned above), a+0x20000 can be used as the new address (i.e., the second memory address mentioned above), otherwise a can be used as The new address (i.e., the second memory address in the above text), at this time, the total number of rounds is not equal to the current number of rounds, the function num+=1 can be used to update the current number of rounds, and the value b (i.e., the second value in the above text) in the new address a+0x20000 can be read. If b is less than 0x20000, b+0x20000 can be used as the new address (i.e., the third memory address in the above text), at this time, the total number of rounds is equal to the current number of rounds, that is, counter==num, and the new address b+0x20000 can be returned. At the same time, the total number of rounds counter can be updated to 2.

[0015] For another example, when the total number of rounds is 2 and the current number of rounds is 0, the mobile phone 100 can use the function addr=*(addr) to read the value a in the fixed address. If a is less than 0x20000, a+0x20000 can be used as the new address. At this time, the total number of rounds is not equal to the current number of rounds. The function num+=1 can be used to update the current number of rounds and read the value b in the new address a+0x20000. If b is less than 0x20000, b+0x20000 can be used as the new address. At this time, the total number of rounds is not equal to the current number of rounds. The function num+=1 can be used to update the current number of rounds and read the value c in the new address b+0x20000. If c is less than 0x20000, c+0x20000 can be used as the new address. At this time, the total number of rounds is equal to the current number of rounds, that is, counter==num, and the new address c+0x20000 can be returned. At the same time, the total number of rounds counter can be updated to 3.

[0016] In some implementations of the first aspect, the method also includes: during the N+1th execution of the boot program, corresponding to detecting a second stack building instruction for a first function included in the boot program, calling a random function to generate a second random value, wherein the first random value is different from the second random value, wherein the second stack building instruction is used to indicate the establishment of a first stack with a first length of the first function, and the storage data of the first stack includes the return address required for the first function to call the second function; based on the second random value, modifying the first length of the first stack to a third length to obtain a third stack; storing the return address in the third stack, wherein the return address has different memory addresses in the first stack and the third stack; and executing the call of the second function by the first function based on the return address in the third stack.

[0017] In an embodiment of the present application, during each execution of the boot program, the actual memory address of the return address stored in the stack will change with a random value during each execution, making it difficult for an attacker to determine the return address to be tampered with, thereby preventing the attacker from jumping to a malicious program tampered with and executing the malicious program, thereby improving the security of the device.

[0018] In some implementations of the first aspect, the memory address of the return address in the first stack is the top of the stack, and the memory address of the return address in the second stack is the top of the stack.

[0019] It can be understood that the memory address of the return address in the first stack can be the top of the stack, and the memory address of the return address in the second stack is the top of the stack. Since the length of the first stack is different from the length of the second stack, the memory address of the return address in the first stack is different from the memory address in the second stack.

[0020] It should be understood that the memory address of the return address in the first stack may also be in the stack, and the memory address of the return address in the second stack may also be in the stack, and since the length of the first stack is different from the length of the second stack, the memory address of the return address in the first stack is different from the memory address in the second stack.

[0021] In a second aspect, an embodiment of the present application provides an electronic device, comprising a memory for storing instructions executed by one or more processors of the electronic device, and a processor, which is one of the one or more processors of the electronic device, for executing the startup protection method mentioned in the first aspect or any item of the first aspect.

[0022] In a third aspect, an embodiment of the present application provides a readable storage medium, on which instructions are stored. When the instructions are executed on an electronic device, the electronic device executes the startup protection method mentioned in the first aspect or any item of the first aspect.

[0023] In a fourth aspect, an embodiment of the present application provides a computer program product, which includes computer instructions. When executed by an electronic device, the electronic device executes the startup protection method mentioned in the first aspect or any item of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 According to some examples of the present application, a scene diagram is shown in which a user holds a mobile phone 100 and presses a power button 101;

[0025] Figure 2 According to some examples of the present application, a schematic diagram of a mobile phone startup process is shown;

[0026] Figure 3 According to some examples of the present application, a schematic diagram of a process for processing a header block is shown;

[0027] Figure 4 According to some examples of the present application, a schematic diagram of an attacker's intrusion process is shown;

[0028] Figure 5 According to some examples of the present application, another schematic diagram of an attacker's intrusion process is shown;

[0029] Fig. 6A According to some examples of the present application, a schematic diagram of changing the length of a stack is shown;

[0030] Figure 6B According to some examples of the present application, a schematic flow chart of a startup protection method is shown;

[0031] Figure 7 According to some examples of the present application, a schematic diagram of a calling process of a random function is shown;

[0032] Figure 8 According to some examples of the present application, a schematic diagram of inserting a random function into the source code of BootRom is shown;

[0033] Fig. 9 According to some examples of the present application, a schematic diagram of a specific implementation of CFI on X86 is shown;

[0034] Fig.10 According to some examples of the present application, a schematic diagram of a situation where both indirect jmp and ret instruction paths are plugged by CFI is shown;

[0035] Fig.11 According to some examples of the present application, a flowchart of a method for protecting the integrity of a BootRom control flow is shown;

[0036] Fig.12 According to some examples of the present application, the hardware structure of an electronic device is shown. DETAILED DESCRIPTION

[0037] The illustrative embodiments of the present application include, but are not limited to, a startup protection method, apparatus, medium, and computer program product.

[0038] The startup protection method mentioned in the embodiment of the present application can be applied to electronic devices. The electronic devices in the embodiment of the present application can be called terminals, user equipment (UE), mobile terminals (MT), etc. The terminal device can be a desktop computer, a laptop computer, a mobile phone, a wearable device, a tablet computer (Pad), a computer with wireless transceiver function, etc. For ease of explanation, the following description is taken as an example of the electronic device being a mobile phone 100.

[0039] Figure 1 The diagram shows a scenario in which a user holds a mobile phone 100 and presses a power button 101. After the user presses the power button 101 of the mobile phone 100, the mobile phone 100 can run the first startup program in the BootRom and enter the startup process.

[0040] After the mobile phone 100 is powered on, Figure 2 As shown, the first boot program in BootRom can be run to initialize the software and hardware in the mobile phone 100, such as resetting registers. Then, the image file of the boot loader (such as xloader) can be loaded into the memory, and a signature check can be performed to prevent the boot loader from being tampered with. After the check is passed, the boot loader (such as xloader) can be run. After that, the boot loader (such as xloader) can load the fastboot program and perform a signature check to prevent the fastboot program from being tampered with. After the check is passed, the fastboot program can be run into the memory, and then the fastboot program can load the kernel image file of the operating system (such as the image file of the Linux kernel) into the memory, and perform a signature check to prevent the operating system from being tampered with. After the check is passed, the operating system can be run, and the system's built-in applications or third-party applications can be loaded according to the user's settings or default configuration.

[0041] As mentioned above, BootRom currently does not have a security protection mechanism similar to that of an operating system, such as memory isolation, memory overflow prevention, etc., and is prone to security vulnerabilities, which can be exploited by attackers to spread malicious applications, seriously affecting the security of the mobile phone 100.

[0042] The security vulnerabilities are introduced below.

[0043] It can be understood that the mobile phone 100 can include two modes: normal startup and download (i.e. flashing). Downloading is an act of changing the operating system of the mobile phone 100, which is equivalent to installing a new operating system on the mobile phone 100 to replace the old operating system. After the new operating system is installed on the mobile phone 100, the power button of the mobile phone 100 can be pressed to power on the mobile phone 100, thereby running the first startup code in the BootRom to realize the startup of the mobile phone 100.

[0044] The following first introduces the process of the mobile phone 100 being in the download mode.

[0045] In some specific implementations, the mobile phone 100 can be short-circuited first, and the mobile phone 100 can be connected to a flashing device (such as a computer) via a universal serial bus (USB), so that the mobile phone 100 can enter the download mode. The flashing device can send a Head Chunk, a Data Chunk, a Tail Chunk, and an Inquiry Chunk to the mobile phone 100 based on the Xmodem protocol (an asynchronous file transfer protocol).

[0046] In some specific implementations, during the flashing process, the flashing device may first send the head block of the image file (such as the boot loader image file and kernel image file mentioned above) to the mobile phone 100, and the head block may include information such as the length of the image file and the download address of the image file. The download address refers to the memory address used to store the image file.

[0047] The mobile phone 100 can receive the Head Chunk and process the Head Chunk accordingly. For example, the Head Chunk can be verified. After the verification is passed, the file download length and the file download address can be set based on the Head Chunk, and it can be determined whether the file download address is consistent with the preset download address. If the file download address is consistent with the preset download address, the counter variable in the BootRom runtime stack is reset. The specific processing flow will be described in Figure 3 To avoid repetition, it is not described here in detail.

[0048] Since the image file has a large amount of data, the flashing device cannot send all the image files to the mobile phone 100 at one time. Therefore, the flashing device can split the image file (such as the image file of the boot loader, the kernel image file, etc.) into multiple copies. For example, the flashing device can split the image file into 10 copies, and the size of each copy of data can be 1024 bytes, 512 bytes, or other bytes. Then, the flashing device can send each copy of data to the mobile phone 100 in the form of a data chunk.

[0049] After the flashing device sends the Head Chunk of the image file to the mobile phone 100, the flashing device can send each piece of data in the form of a Data Chunk to the mobile phone 100 until the entire image file is sent to the mobile phone 100. After the mobile phone 100 receives the Data Chunk, the mobile phone 100 can write the data in the Data Chunk to the file download address in the memory.

[0050] After the flashing device sends the entire image file to the mobile phone 100, the flashing device may send a Tail Chunk to the mobile phone 100 to notify the mobile phone 100 that the download is complete and that the subsequent process of performing signature verification on the image file may be executed.

[0051] Before the flashing device sends a Tail Chunk (hereinafter referred to as an end block) to the mobile phone 100, the flashing device may send an Inquiry Chunk to the mobile phone 100 to inquire about the download progress of the image file.

[0052] In some optional instances, the data format of the header block Head Chunk can adopt the data format as shown in Table 1, the data format of the data block Data Chunk can adopt the data format as shown in Table 2, the data format of the tail block Tail Chunk can adopt the data format as shown in Table 3, and the data format of the Inquiry Chunk can adopt the data format as shown in Table 4.

[0053] Table 1

[0054]

[0055] Among them, Command can represent the protocol header, Seq can represent the sequence number of the data, ~Seq can represent the inverted sequence number of the data, File-type can represent the file type, Length can represent the length of the image file, Address can represent the download address of the image file, Checksum can represent the checksum, and Checksum can be used to ensure the integrity of the data during the transmission process.

[0056] Table 2

[0057]

[0058] Among them, Command can represent a protocol header, Seq can represent a sequence number of data, ~Seq can represent a reverse sequence number of data, Data can represent data, and Checksum can represent a checksum.

[0059] Table 3

[0060]

[0061] Among them, Command can represent a protocol header, Seq can represent a sequence number of data, ~Seq can represent a reverse sequence number of data, and Checksum can represent a checksum.

[0062] Table 4

[0063]

[0064] Among them, Command can represent a protocol header, Seq can represent a sequence number of data, ~Seq can represent a reverse sequence number of data, and Checksum can represent a checksum.

[0065] Generally, security loopholes are prone to occur when the mobile phone 100 is in download mode. Based on the process in which the mobile phone 100 processes the Head Chunk, a security loophole is described in detail below.

[0066] like Figure 3 As shown, the process of the mobile phone 100 processing the Head Chunk includes:

[0067] 301: Check whether the header block passes.

[0068] It can be understood that in order to ensure the integrity and accuracy of the image file and reduce the risk of flashing failure, in some optional instances, after the mobile phone 100 receives the header block sent by the flashing device, the sequence number (Seq), file type (File-type), and length (msg_len) of the header block data can be checked. For example, whether the sequence number of the check data is 0, whether the file type is the file type corresponding to the image file, and whether the message length of the header block is the preset message length.

[0069] In some optional instances, when the verification passes, for example, the serial number of the data is 0, the file type is the file type corresponding to the mirror file, and the message length of the header block is a preset message length, you can go to step 302 to set the file download length, or you can go to step 303 to set the file download address.

[0070] In other optional instances, when the verification fails, for example, the serial number of the data is not 0, or the file type is not the file type corresponding to the image file, or the message length of the header block is not the preset message length, you can go to step 307 and send a verification error response to the flashing device.

[0071] In addition, the protocol header, the serial number of the data, the inverted serial number of the data, and the checksum in the header block may also be checked, which will not be described in detail here.

[0072] 302: Set the file download length to the length of the image file in the header block.

[0073] In some optional examples, the mobile phone 100 may extract the length of the image file from the header block, and set the file download length to the length of the image file extracted from the header block.

[0074] Specifically, the file download length may be set to the length of the image file in the header block using the following code: file_download_legth=Length, where file_download_legth may represent the file download length, and Length may represent the length of the image file in the header block.

[0075] 303: Set the file download address to the download address of the image file in the header block.

[0076] In some optional examples, the mobile phone 100 may extract the download address of the image file from the header block, and set the parameter corresponding to the file download address as the download address of the image file in the header block.

[0077] Specifically, the following code may be used to set the file download address to the download address of the mirror file in the header block: file_download_address=address, wherein file_download_address may represent the file download address, and address may represent the download address of the mirror file in the header block.

[0078] It can be understood that the order of execution of step 302 and step 303 can be to execute step 302 first and then step 303, or to execute step 303 first and then step 302, or to execute step 302 and step 303 in parallel, which is not specifically limited in the embodiments of the present application.

[0079] 304: Determine whether the file download address is consistent with the pre-set download address.

[0080] It is understandable that the preset download address may be agreed upon by the processor manufacturer, operating system supplier or developer of the flashing tool in the mobile phone 100, for example, 0x22000.

[0081] In some optional instances, the download address of the image file extracted from the header block can be compared with the pre-set download address. When the download address of the image file extracted from the header block is consistent with the pre-set download address, the process can go to step 305 to reset the counter variable in the BootRom runtime stack. When the download address of the image file extracted from the header block is inconsistent with the pre-set download address, the process can go to step 308 to send an address error response to the flashing device.

[0082] In some optional examples, the following code may be used to determine whether the file download address is consistent with a preset download address: address == 0x22000, where address may represent the file download address and 0x22000 may represent the preset download address.

[0083] 305: Reset the counter variable in the BootRom runtime stack.

[0084] It can be understood that in order to ensure that the counter variable in the BootRom runtime stack has a clear initial state before use, the counter variable in the BootRom runtime stack can be initialized when the download address of the image file extracted from the header block is consistent with the preset download address.

[0085] It can be understood that the first startup program in the BootRom may include multiple instructions. When the first startup program in the BootRom runs, a stack is created in the memory to store variables and return addresses during the running process. The variables may include counter variables such as the number of received data blocks, the sequence number of the last received data block, the total number of transmissions, and the sequence number of the next received data block.

[0086] It can be understood that when the download address of the image file extracted from the header block is consistent with the pre-set download address, the counter variables in the BootRom runtime stack can be reset, such as initializing the number of received data blocks, the sequence number of the last received data block, the total number of transmissions, and the sequence number of the next received data block.

[0087] In some optional examples, the following code may be used to initialize the number of received data blocks: total_received=0, where total_received may represent the number of received data blocks.

[0088] In some optional examples, the following code may be used to initialize the sequence number of the last received data block: last_seen_seq=0, where last_seen_seq may represent the sequence number of the last received data block.

[0089] In some optional instances, the total number of transmissions may be the total number of copies that the flashing device splits the image file into + 1, where + 1 may represent the tail block. Specifically, the following code may be used to initialize the total number of transmissions: total_frame_count = ┌Length / 1024┐+1, where total_frame_count may represent the total number of transmissions, Length may represent the length of the image file in the header block, 1024 may represent the size of each copy of the data when the flashing device splits the image file into multiple copies, and ┌┐ may represent rounding up.

[0090] In some optional examples, the following code may be used to initialize the sequence number of the data block to be received next time: next_seq=1, where next_seq may represent the sequence number of the data block to be received next time.

[0091] 306: Send an initialization completion response to the flashing device.

[0092] It can be understood that the initialization completion response is used to notify the flashing device to send the image file to the mobile phone 100 in the form of data blocks.

[0093] It can be understood that after resetting the counter variable in the BootRom runtime stack, the mobile phone 100 can send an initialization completion response to the flashing device. In some optional examples, the mobile phone 100 can use the following code to send an initialization completion response to the flashing device: send_sub_response(xmodem, 0xaa), where 0xaa can represent an initialization completion code.

[0094] 307: Send a verification error response to the flashing device.

[0095] It can be understood that the verification error response is used to notify the flashing device that the header block verification has failed and the header block needs to be resent.

[0096] In some optional examples, when the verification fails, for example, the serial number of the data is not 0, or the file type is not the file type corresponding to the image file, or the message length of the header block is not the preset message length, the mobile phone 100 can send a verification error response to the flashing device. In some optional examples, the mobile phone 100 can use the following code to send a verification error response to the flashing device: send_sub_response(xmodem, 0x55), where 0x55 can represent an error code when the file type in the header block is not the file type corresponding to the image file.

[0097] 308: Send an address error response to the flashing device.

[0098] It can be understood that the address error response is used to notify the flashing device that the download address in the header block is inconsistent with the preset download address and the header block needs to be resent.

[0099] In some optional instances, when the download address of the image file extracted from the header block is inconsistent with the pre-set download address, the mobile phone 100 can use the following code to send an error code corresponding to the inconsistent address to the flashing device: send_sub_response(xmodem, 0x07), where 0x07 can represent the error code when the download address of the image file in the header block is inconsistent with the pre-set download address.

[0100] However, checking whether the download address in the header block is consistent with the pre-set address only affects whether to reset the counter variable in the BootRom runtime stack, and does not affect setting the file download length to the length of the image file in the header block, nor does it affect setting the file download address to the download address in the header block. In addition, since there is no verification of the length of the image file in the header block (such as "Length" in Table 1) and the download address of the image file (such as "Address" in Table 1), the attacker can write any length in the header block, such as the length of the image file of a malicious program (such as payload), and can write any download address in the header block, so that a malicious program of any length can be written at any location in the memory, and then the normal execution logic of the instructions in the BootRom can be tampered with, and the signature verification can be bypassed, which seriously affects the security of the mobile phone 100.

[0101] It is understandable that the program written by the attacker on the flashing device can be called a malicious program. In some specific implementations, the flashing device can split the entire malicious program image file into multiple copies, and when the mobile phone 100 is in download mode, each copy of data is sent to the mobile phone 100 in the form of a data chunk.

[0102] In some optional instances, if the attacker sets the download address of the image file in the header block to a preset download address (eg, 0x22000), the malicious program can be downloaded to the preset download address in the memory.

[0103] In some other optional examples, if the attacker prepares to set the download address of the image file in the header block as the target download address, the malicious program can be downloaded to the target download address in the memory. It is worth noting that this demonstration attack uses a pre-set download address in this link.

[0104] For example, the flashing device first sends the head block A of the image file whose download address is consistent with the preset download address to the mobile phone 100, that is, the correct head block A, and after the mobile phone 100 verifies the head block A, the flashing device sends the data block to the mobile phone 100. While the flashing device sends the data block to the mobile phone 100, the flashing device can send the head block B corresponding to the image file of the malicious program written by the attacker to the mobile phone 100, that is, the head block B whose download address is inconsistent with the download address of the pre-set device.

[0105] The following is an introduction to the attacker's intrusion process. Figure 4 A schematic diagram of an attacker's intrusion process is shown in FIG. Figure 4 As shown, the intrusion process can include:

[0106] 401: The flashing device sends a header block A to the mobile phone 100. The download address of the image file in the header block A is a preset download address. The length of the image file in the header block A can be any length.

[0107] It can be understood that in the header block A sent by the flashing device to the mobile phone 100, the attacker can set the download address in the header block A to a preset download address, such as 0x22000, and can set the length of the image file in the header block A to any length, so as to reset the counter variable in the BootRom runtime stack.

[0108] 402: The flashing device sends the header block B to the mobile phone 100 again. The download address of the image file in the header block B is the target download address. The length of the image file in the header block B can be any length.

[0109] It can be understood that the target download address can be any download address written by the attacker in the header block B, such as a download address of a malicious program.

[0110] In some optional instances, in the header block B sent by the flashing device to the mobile phone 100, the attacker can set the length of the image file to an arbitrary length, and can set the download address of the image file to an arbitrary address, that is, the attacker can write an arbitrary length and an arbitrary address in the second header block B sent by the flashing device to the mobile phone 100.

[0111] It can be understood that if the attacker intends to download the malicious program to a download address preset in the memory (e.g., 0x22000), only step 401 may be performed without executing step 402. If the attacker intends to download the malicious program to a download address not preset in the memory (i.e., the target download address), step 401 may be performed first, and then step 402. For ease of explanation, the following description is based on the example that the attacker intends to download the malicious program to a download address not preset in the memory (i.e., the target download address).

[0112] 403: The flashing device sends a data block to the mobile phone 100.

[0113] It can be understood that after the flashing device sends two header blocks to the mobile phone 100, it can send a data block to the mobile phone 100, and the mobile phone 100 can write the data in the data block to the target download address in the memory.

[0114] It can be understood that the above actually implements a primitive: the attacker has the ability to write to any address.

[0115] The following is an introduction to the attacker's intrusion process. Figure 5 As shown, the intrusion process can include:

[0116] 501: Download the image file of a malicious program.

[0117] In some optional examples, if the attacker sets the download address of the image file in the header block to a preset download address (eg, 0x22000), the mobile phone 100 may download the malicious program to the preset download address in the memory.

[0118] In some other optional examples, if the attacker prepares to set the download address of the image file in the header block as the target download address, the mobile phone 100 can download the malicious program to the target download address in the memory. It is worth noting that the pre-set download address is used in this link of the attack demonstration.

[0119] 502: Transfer end block.

[0120] It can be understood that the end block may refer to the tail block mentioned above. After the flashing device sends the entire image file of the malicious program to the mobile phone 100, the flashing device may send the tail block to the mobile phone 100 to notify the mobile phone 100 that the download is complete.

[0121] It is understandable that after the mobile phone 100 receives the image file of the entire malicious program, it will perform a signature verification on the image file in the preset download address. It is worth noting that the image file in the preset download address is the image file of the malicious program, and the image file that is not preset will inevitably fail the verification. After the verification fails, it can go to step 503 to enter a new round of downloading the image file of the malicious program.

[0122] 503: Enter a new round of downloading malicious program image files.

[0123] It is understandable that, as mentioned above, the attacker can set the download address of the image file in the header block to any address. Therefore, after the signature verification of the downloaded image file of the malicious program fails, the image file of another malicious program can be downloaded again. It is worth noting that even if the signature verification of the image file of the malicious program fails, the downloaded image file of the malicious program is still retained at the file download address in the memory (for example, the pre-set download address 0x22000 or the target download address).

[0124] 504: Use any download address to write a tampered return address.

[0125] As mentioned above, when the first startup program in BootRom runs, a stack will be created in the memory to store variables and return addresses during the running process. Among them, the stack refers to a continuous memory address that can store variables and return addresses during the program running process. That is, the processor in the mobile phone 100 can allocate a continuous memory address to store variables and return addresses. Among them, the return address refers to the address of the function to be executed after the function calls the called function. The pre-set download address can be agreed upon by the processor manufacturer, operating system supplier or developer of the flashing tool in the mobile phone 100. For example, 0x22000. When a function calls a called function, the return address can be pushed into the stack. When the called function is executed, the return address can be popped out from the stack, so that the processor can jump to execute the function in the return address.

[0126] Generally, processor manufacturers or operating system vendors will predefine that the return address is stored at the top of the stack allocated to the BootRom. In this way, when the attacker knows the actual memory address of the return address stored in the memory when the BootRom is running (i.e., the top of the stack mentioned above), the return address can be tampered with to the download address of the malicious program, so that after the subroutine is executed, the execution can jump to the malicious program in the return address.

[0127] 505: Transfer end block.

[0128] It is understandable that step 505 can refer to step 503, and in order to avoid repetition, it will not be described here. It is worth noting that the signature verification still fails at this time.

[0129] 506: Jump to the address specified by the malicious program for execution.

[0130] In some optional instances, when the return address in the stack is tampered with to the download address of the malicious program, after the function is completed, the execution can jump to the image file of the malicious program.

[0131] Therefore, during the process of the processor of the mobile phone 100 running a function, an attacker may maliciously hijack the function control flow. Specifically, the attacker may modify the return address of the sub-function, and modify the normal return address to the download address of the malicious program, so that the processor jumps to the download address of the malicious program after executing the sub-function to execute the malicious program, thereby achieving the purpose of changing the function control flow, thereby destroying the control flow integrity (CFI) of the function.

[0132] As mentioned above, since BootRom does not have a security protection mechanism similar to that of an operating system, an attacker can tamper with the download address of the image file in the header block to an arbitrary address, so that the attacker can write a malicious program of any length at any download address in the memory. Secondly, when the return address (ret address) in the BootRom runtime stack is clearly in the actual memory address in the memory, the attacker can tamper with the return address to the download address of the malicious program (such as payload). In this way, after the mobile phone 100 is powered on and runs the first startup function in BootRom, the processor will jump to the download address of the malicious program and load the image file of the malicious program (such as payload) into the memory, destroying the normal execution logic of BootRom, and then maliciously flashing the machine and spreading malicious application functions, seriously affecting the security of the mobile phone 100.

[0133] It is understandable that when the return address mentioned above is stored in the stack, if the length of the stack changes, the memory address of the return address in the stack will change accordingly. Fig. 6A As shown in (a), assuming that the length of the stack is A, the memory address of the return address in the stack can be A1.

[0134] If the length of the stack becomes B, such as Fig. 6A As shown in (b), the memory address of the return address at the top of the stack changes from A1 to B1.

[0135] In order to solve the above problems, an embodiment of the present application provides a startup protection method. In this method, when the electronic device detects a power-on instruction (for example, detecting that the power button is pressed, etc.), the first startup code in BootRom is run. If the stack building instruction of the function included in the first startup code in BootRom is executed, a random function is called to generate a random value to change the length of the stack established by the stack building instruction, and the return address of the function included in the first startup code in BootRom calling other functions is stored in the stack after the length of the stack is changed. In this way, the actual memory address storing the return address in the stack will change with the random value each time the stack building instruction is executed, thereby making it difficult for an attacker to determine the actual memory address of the return address to be tampered with, thereby preventing the attacker from jumping to the malicious program tampered with by the attacker and executing the malicious program, which can improve the security of the device.

[0136] For example, in some optional instances, the value a in a fixed address can be read. Each time the random function is called, the current round number can be initialized to 0. In the case where the current round number of the random function is called is less than the total round number, if a is less than the code segment boundary address in BootRom (e.g., 0x20000), a+0x20000 can be used as the new address. If a is greater than the code segment boundary address in BootRom (e.g., 0x20000), a can be used as the new address, and the value b in the new address can be read, and b can be assigned to a, and the current round number +1. At this time, if the current round number of the random function is still less than the total round number, the above steps can be repeated until the current round number of the random function is equal to the total round number, and the random value a is returned (for different values ​​of the current round number, a will change, such as the assignment of b to a mentioned above). The random value a is the length of the stack change, that is, on the basis of the length of the stack established by the stack building instruction, the length corresponding to the random value is increased to obtain the length of the changed stack.

[0137] The startup protection method mentioned in the embodiment of the present application is introduced in detail below. Figure 6B A schematic flow chart of a startup protection method is shown, which can be executed by an electronic device. Specifically, the startup protection method may include:

[0138] 601: A power-on instruction of an electronic device is detected.

[0139] It can be understood that detecting a power-on instruction of the electronic device may refer to: detecting that a user presses a power button of the electronic device to power on the electronic device.

[0140] 602: During the Nth execution of the boot program, corresponding to the execution of the stack building instruction of the first function included in the boot program, a random function is called to generate a random value, wherein the stack building instruction is used to indicate the establishment of a first stack with a first length of the first function, and the storage data of the first stack includes a return address, and the return address is the address of a second function that needs to be executed after the first function is executed.

[0141] It can be understood that the boot program can be the first startup code in BootRom.

[0142] The return address is explained below with a specific example. Assume that the first startup program in BootRom includes: function A, function B and function C, where function B can be a calling function, and the normal execution process can be to execute function A, function B and function C in sequence. Since function B is a calling function, when the processor executes function B, it will jump to the address of the sub-function (that is, the third function mentioned above) corresponding to function B (that is, the first function mentioned above) and execute the sub-function. In order to ensure that the processor can correctly return to the address of function C (that is, the second function mentioned above) after executing the sub-function corresponding to function B, the processor will save the address of function C before executing function B, that is, the processor will write the address of function C into the stack as the return address.

[0143] In some optional instances, the first random value can be determined in the following manner: corresponding to the number of rounds of calling the random function being equal to a preset round threshold, a first value is read from the first memory address; if the first value is smaller than the boundary memory address of the boot program, the second memory address is determined based on the first memory address and the first value; if the first value is greater than the boundary memory address of the boot program, the first value is used as the second memory address, and then the second memory address is used as the first random value.

[0144] Among them, the first memory address is also the fixed address mentioned in this application, and the boundary memory address is also the boundary address of the code segment in BootRom mentioned in this application. In this way, the first startup code in BootRom can be jumped out and the next code can be executed.

[0145] In some other optional instances, the first random value can be determined in the following manner: corresponding to the number of rounds of calling the random function being less than a preset round number threshold, a first value is read from a first memory address; if the first value is less than the boundary memory address of the boot program, a second memory address is determined based on the first memory address and the first value, and the number of rounds of calling the random function is updated; corresponding to the updated number of rounds of calling the random function being equal to the preset round number threshold, a second value is read from a second memory address; if the second value is less than the boundary memory address of the boot program, a third memory address is determined based on the second memory address and the second value, and the third memory address is used as the first random value.

[0146] If the first value is greater than the boundary memory address of the boot program, the first value is used as the second memory address.

[0147] If the second value is greater than the boundary memory address of the boot program, the second value is used as the third memory address, and the third memory address is used as the first random value.

[0148] 603: Modify the first length of the first stack to a second length based on the first random value to obtain a second stack.

[0149] In some optional examples, the first random value may be used as the second length to obtain a second stack.

[0150] 604: Store the return address in the second stack, wherein the return address has different memory addresses in the first stack and the second stack.

[0151] It can be understood that the memory address of the return address in the first stack can be the top of the stack, and the memory address of the return address in the second stack is the top of the stack. Since the length of the first stack is different from the length of the second stack, the memory address of the return address in the first stack is different from the memory address in the second stack.

[0152] It should be understood that the memory address of the return address in the first stack may also be in the stack, and the memory address of the return address in the second stack may also be in the stack, and since the length of the first stack is different from the length of the second stack, the memory address of the return address in the first stack is different from the memory address in the second stack.

[0153] 605: Execute the second function based on the return address in the second stack.

[0154] It is understandable that after the first function executes and calls the third function, the second function can be read and executed based on the return address in the second stack. It should be noted that the second function is the function that needs to be executed after the first function is executed in the function execution sequence.

[0155] The following is an introduction to how random functions generate random values.

[0156] Figure 7 A schematic diagram of a calling process of a random function is shown, and the calling process of the random function may include:

[0157] 701: Random function reads global variables.

[0158] It can be understood that the total round number can be a global variable, which defaults to 0, such as counter = 0. The current round number can be initialized to 0, such as num = 0. The fixed address can be a memory address that is fixedly read when the BootRom is running. For example, the fixed address can be set using the following code: addr = fixed address.

[0159] 702: Read the value in the fixed address.

[0160] In some optional examples, the following code may be used to read the value in the fixed address: addr=*(addr).

[0161] 703: Determine whether the value in the fixed address is smaller than the boundary address of the code segment in the BootRom.

[0162] In some optional examples, the following code can be used to determine whether the value in the fixed address is less than the boundary address of the code segment in BootRom: addr<0x20000, where 0x20000 can represent the boundary address of the code segment in BootRom. It should be understood that for different chips, the boundary address of the code segment in BootRom can be different values, and 0x20000 mentioned in the embodiment of the present application is only an optional example.

[0163] In some optional examples, when the value in the fixed address is less than the boundary address of the code segment in the BootRom, the process may proceed to step 704 to reset the read address. When the value in the fixed address is greater than or equal to the boundary address of the code segment in the BootRom, the process may proceed to step 705 to determine whether the current round number is equal to the total round number.

[0164] 704: Reset the read address.

[0165] In some optional examples, the following code may be used to reset the read address: addr+=0x20000, that is, the sum of the value in the fixed address and the boundary address of the code segment in the BootRom is used as the new read address.

[0166] 705: Determine whether the current round number is equal to the total round number.

[0167] In some optional examples, the following code may be used to determine whether the current round number is equal to the total round number: num == counter. When the current round number is equal to the total round number, the process may proceed to step 706 to update the total round number, and then proceed to step 707 to return a new address. When the current round number is not equal to the total round number, the process may proceed to step 708 to update the current round number.

[0168] 706: Update the total number of rounds.

[0169] In some optional examples, the following code may be used to implement updating the total number of rounds: counter=(counter+1)%100.

[0170] It is worth noting that the total number of rounds is a global variable and can be used by new calls.

[0171] 707: Return a new address, where the new address is a 32-bit random value.

[0172] 708: Update the current round number.

[0173] In some optional examples, the following code may be used to update the current round number: num+=1.

[0174] The following is a specific example to introduce in detail the process of generating random values ​​by the random function mentioned above.

[0175] When the total round number is 0 and the current round number is 0, the mobile phone 100 can use the function addr=*(addr) to read the value a in the fixed address. If a is less than 0x20000, a+0x20000 can be used as the new address. At this time, the total round number is equal to the current round number, that is, counter==num, and the new address a+0x20000 can be returned. At the same time, the total round number counter can be updated to 1. Otherwise, a is returned directly.

[0176] When the total round number is 1 and the current round number is 0, the mobile phone 100 can use the function addr=*(addr) to read the value a in the fixed address. If a is less than 0x20000, a+0x20000 can be used as the new address. If a is greater than 0x20000, a+0x20000 can be used as the new address. At this time, the total round number is not equal to the current round number. The function num+=1 can be used to update the current round number and read the value b in the new address a+0x20000. If b is less than 0x20000, b+0x20000 can be used as the new address. If b is greater than 0x20000, b can be used as the new address. At this time, the total round number is equal to the current round number, that is, counter==num, and the new address b+0x20000 can be returned. At the same time, the total round number counter can be updated to 2.

[0177] When the total number of rounds is 2 and the current number of rounds is 0, the mobile phone 100 can use the function addr=*(addr) to read the value a in the fixed address. If a is less than 0x20000, a+0x20000 can be used as the new address. If a is greater than 0x20000, a can be used as the new address. At this time, the total number of rounds is not equal to the current number of rounds. The function num+=1 can be used to update the current number of rounds and read the value b in the new address a+0x20000. If b is less than 0x20000, b+0x2000 can be used. 0 is used as the new address. If b is greater than 0x20000, b can be used as the new address. At this time, the total number of rounds is not equal to the current number of rounds. The function num+=1 can be used to update the current number of rounds, and the value c in the new address b+0x20000 can be read. If c is less than 0x20000, c+0x20000 can be used as the new address. If c is greater than 0x20000, c can be used as the new address. At this time, the total number of rounds is equal to the current number of rounds, that is, counter==num, and the new address c+0x20000 can be returned. At the same time, the total number of rounds counter can be updated to 3.

[0178] It can be understood that the random values ​​generated by the random function (such as a, a+0x20000, b, b+0x20000, c, c+0x20000, etc. mentioned above) are affected by the random values ​​after power-on (such as a, b, c mentioned above), and change with the total number of rounds. Therefore, the attacker cannot clearly know the value of the stack length increase obtained by calling the random function when creating the stack, and thus cannot clearly know the actual memory address of the return address stored in the stack, making it difficult for the attacker to tamper with the return address of the stack into the download address of the malicious program, thereby preventing the program from jumping to the malicious program tampered by the attacker, and improving the security of the device.

[0179] In some specific implementations, a random function may be inserted into the source code of the BootRom. The following describes a method for inserting a random function into the source code of the BootRom in an embodiment of the present application.

[0180] like Figure 8As shown, the source code of BootRom can be plugged, that is, a random function is inserted into the source code of BootRom, and all jump instructions (such as call instructions, including direct jump instructions and indirect jump instructions) can be searched. For example, the indirect jump instruction can refer to the call instruction of the first function to the third function in the above text, and the stack building code corresponding to the stack building instruction is determined. The stack building code can call the random function so that the length of the stack increases by a random value. When determining the return address of the randomized stack, that is, when modifying the stack length, since the stack building is the reduction of the extended stack pointer register (extended stackpointer, esp) at the top of the stack (the stack grows from a high address to a low address), the random function call needs to be completed to reduce esp accordingly. And when modifying the stack recovery, the change value at the top of the stack increases the random value. Then the BootRom can be compiled, and then it can be burned into the read-only memory inside the system-level chip (system on chip, SOC) (it will be blown after the first burning, and the subsequent read-only cannot be modified).

[0181] Another startup protection method mentioned in the embodiment of the present application is introduced below.

[0182] Control flow hijacking is a very harmful attack method. Attackers can use control flow hijacking to gain control of the target machine, or even perform privilege escalation operations to fully control the target machine. When attackers have mastered the memory error vulnerability of the attacked program, they generally consider launching a control flow hijacking attack.

[0183] In order to deal with control flow hijacking attacks, existing solutions propose a control flow integrity (CFI) defense mechanism (the following control flow integrity refers to the solution), which limits the control transfer during program operation so that it is always within the scope defined by the original control flow graph. The specific method is to obtain a whitelist of target addresses of indirect transfer instructions (including indirect jump instructions, indirect call instructions, and function return instructions) by analyzing the control flow graph of the program, and check whether the target of the indirect transfer instruction is in the whitelist during operation. When the target address of the indirect transfer instruction is in the whitelist, the program in the target address in the memory is jumped or called. When the target of the indirect transfer instruction is not in the whitelist, an error is reported.

[0184] It can be understood that the transfer method that directs control to a new location in the program is called a forward transfer, such as the jmp instruction and the call instruction, and the transfer method that returns control to the previous location is called a backward transfer, such as the ret instruction.

[0185] Combining the above two classification methods:

[0186] Forward transfer instructions jmp and call can be divided into four types according to different addressing modes: direct jmp instructions, indirect jmp instructions, direct call instructions and indirect call instructions.

[0187] The backward transfer instruction ret has no operands, and its target address is determined by the return address in the stack. It is precisely because of the characteristics of the ret instruction that a series of attacks targeting the return address are triggered.

[0188] To this end, in some other optional instances, codes may be inserted to determine the control flow paths of indirect jmp, indirect call, and ret instructions:

[0189] 1. Insert a unique label ID at the target address of indirect call and ret instructions.

[0190] 2. Insert a stub code before the indirect call and ret instructions to check whether the ID of the target address is legal. If it is legal, the indirect jump is allowed. If it is illegal, an error is reported.

[0191] Fig. 9 It is a specific implementation of CFI on X86:

[0192] Original state: exc saves the target address, and jmp exc indirectly jumps to the target address for execution.

[0193] Stub method (a): First, insert a 4-byte ID "12345678h" at the target address, and insert a stub function before the jmp jump. Use the stub function to determine whether the target address is 12345678h. If the judgment result is yes, that is, legal, it will indirectly jump to the [exc+4] address to execute the original destination instruction. If the judgment result is no, that is, illegal, it will report an error.

[0194] Insertion method (b): Based on the insertion method (a), it is optimized by inserting a 4-byte label instruction prefetchnta+4-byte ID "12345678h" at the target address, inserting a stub function before the jmp jump, and using the stub function to determine whether the value of the [exc+4] address is 12345678h. If the judgment result is yes, that is, legal, it indirectly jumps to the [ecx] address to execute the label instruction. If the judgment result is no, that is, illegal, an error is reported.

[0195] Fig.10 This shows that both the indirect call and ret instruction paths are plugged by CFI. For details on how to jump, refer to Fig. 9 , in order to avoid repetition, it will not be repeated here.

[0196] In order to achieve CFI, it is critical that the following three assumptions hold true:

[0197] UNQ. Unique ID: The bit pattern chosen as ID must not appear anywhere in code memory except for ID and ID checking after CFI detection. This property can be easily achieved by making the IDs large enough (e.g. 32 bits, for software of reasonable size), and by choosing IDs so that they do not collide with opcode bytes in the rest of the software.

[0198] NWC. Non-Writable Code: It must be impossible for a program to modify code memory at runtime, otherwise, an attacker might be able to bypass CFI, for example by overwriting the ID check.

[0199] NXD. Non-executable data: The program must not be able to execute data as code, otherwise an attacker could cause the execution of data marked with an expected ID.

[0200] However, in the operating environment of BootRom, NWC exists and the code is read-only, but NXD is not feasible because subsequent image files need to be loaded and run. Therefore, the existing CFI cannot be directly transplanted to BootRom.

[0201] As mentioned above, the problem with direct transplantation is that an attacker can forge a TAG, thereby bypassing CFI. To this end, an embodiment of the present application provides a control flow integrity protection method for BootRom.

[0202] like Fig.11 As shown, during the BootRom compilation process, all transfer instructions can be searched first to obtain a control flow graph (CFG), and then the CFI TAG judgment can be added before the indirect jmp, indirect call, ret instructions and the jump target address, as well as the judgment of whether the target address is writable.

[0203] Specifically, if the TAGs are not equal, or the target address is writable (the writable address belongs to the non-BootRom code area, and the BootRom code area, that is, the memory address smaller than the boundary address is not writable), no jump is performed and error handling is entered.

[0204] In this way, even if the CFI is bypassed by a forged TAG, it can be identified because the target address is tampered. The target address may refer to the address of the second function to be executed after the first function calls the third function in the above text.

[0205] When executing xloader for BootRom jump, the above operation is not performed for this BootRoom jump instruction (although the target address can be written, this is a necessary special case).

[0206] Then, the BootRoom can be assembled and burned into the SoC.

[0207] The hardware structure of the electronic device is introduced below. Fig.12 A schematic structural diagram of an electronic device 100 is shown.

[0208] The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 2G / 3G / 4G / 5G 150, a wireless communication module BT / WLAN / GNSS / NFC / IR / FM160, an audio module 170, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, etc.

[0209] It is to be understood that the structure illustrated in the embodiment of the present invention does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer components than shown in the figure, or combine some components, or separate some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0210] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0211] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

[0212] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0213] The charging management module 140 is used to receive charging input from a charger. The charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 may receive charging input from a wired charger through the USB interface 130. In some wireless charging embodiments, the charging management module 140 may receive wireless charging input through a wireless charging coil of the electronic device 100. While the charging management module 140 is charging the battery 142, it may also power the electronic device through the power management module 141.

[0214] The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, and provides power to the processor 110, the internal memory 121, the display screen 194, the camera 193, and the wireless communication module BT / WLAN / GNSS / NFC / IR / FM160. The power management module 141 can also be used to monitor parameters such as battery capacity, battery cycle number, battery health status (leakage, impedance), etc. In some other embodiments, the power management module 141 can also be set in the processor 110. In other embodiments, the power management module 141 and the charging management module 140 can also be set in the same device.

[0215] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function, such as storing music, video and other files in the external memory card.

[0216] The internal memory 121 can be used to store computer executable program codes, which include instructions. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created during the use of the electronic device 100 (such as audio data, a phone book, etc.), etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 110 executes various functional applications and data processing of the electronic device 100 by running instructions stored in the internal memory 121, and / or instructions stored in a memory provided in the processor.

[0217] The pressure sensor 180A is used to sense the pressure signal and can convert the pressure signal into an electrical signal. In some embodiments, the pressure sensor 180A can be set on the display screen 194. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, capacitive pressure sensors, etc. The capacitive pressure sensor can be a parallel plate including at least two conductive materials. When a force acts on the pressure sensor 180A, the capacitance between the electrodes changes. The electronic device 100 determines the intensity of the pressure according to the change in capacitance. When a touch operation acts on the display screen 194, the electronic device 100 detects the touch operation intensity according to the pressure sensor 180A. The electronic device 100 can also calculate the touch position according to the detection signal of the pressure sensor 180A. In some embodiments, touch operations acting on the same touch position but with different touch operation intensities can correspond to different operation instructions. For example: when a touch operation with a touch operation intensity less than the first pressure threshold acts on the short message application icon, an instruction to view the short message is executed. When a touch operation with a touch operation intensity greater than or equal to the first pressure threshold acts on the short message application icon, an instruction to create a new short message is executed.

[0218] The key 190 includes a power key, a volume key, etc. The key 190 may be a mechanical key or a touch key. The electronic device 100 may receive key input and generate key signal input related to user settings and function control of the electronic device 100.

[0219] The various embodiments of the mechanism disclosed in the present application can be implemented in hardware, software, firmware or a combination of these implementation methods. The embodiments of the present application can be implemented as a computer program or program code executed on a programmable system, which includes at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device and at least one output device.

[0220] Program code can be applied to input instructions to perform the functions described in this application and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, a processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit, or a microprocessor.

[0221] Program code can be implemented with high-level programming language or object-oriented programming language to communicate with the processing system. When necessary, program code can also be implemented with assembly language or machine language. In fact, the mechanism described in this application is not limited to the scope of any specific programming language. In either case, the language can be a compiled language or an interpreted language.

[0222] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried or stored on one or more temporary or non-temporary machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, instructions may be distributed over a network or through other computer-readable media. Therefore, machine-readable media may include any mechanism for storing or transmitting information in a machine (e.g., computer) readable form, including, but not limited to, floppy disks, optical disks, optical disks, read-only memories (CD-ROMs), magneto-optical disks, read-only memories (ROMs), random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, flash memory, or a tangible machine-readable memory for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in electrical, optical, acoustic, or other forms of propagation signals. Therefore, machine-readable media include any type of machine-readable media suitable for storing or transmitting electronic instructions or information in a machine (e.g., computer) readable form.

[0223] The above describes the hardware structure that the electronic device may have. It is understood that the structure illustrated in the embodiments of the present application does not constitute a specific limitation on the electronic device. In other embodiments of the present application, the electronic device may include more or fewer components than shown in the figure, or combine certain components, or split certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0224] In the accompanying drawings, some structural or method features may be shown in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order may not be required. Instead, in some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. In addition, the inclusion of structural or method features in a particular figure does not mean that such features are required in all embodiments, and in some embodiments, these features may not be included or may be combined with other features.

[0225] The various embodiments of the mechanism disclosed in the present application can be implemented in hardware, software, firmware or a combination of these implementation methods. The embodiments of the present application can be implemented as a computer program or program code executed on a programmable system, which includes at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device and at least one output device.

[0226] Program code can be applied to input instructions to perform the functions described in this application and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, a processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit, or a microprocessor.

[0227] Program code can be implemented with high-level programming language or object-oriented programming language to communicate with the processing system. When necessary, program code can also be implemented with assembly language or machine language. In fact, the mechanism described in this application is not limited to the scope of any specific programming language. In either case, the language can be a compiled language or an interpreted language.

[0228] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried or stored on one or more temporary or non-temporary machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, instructions may be distributed over a network or through other computer-readable media. Therefore, machine-readable media may include any mechanism for storing or transmitting information in a machine (e.g., computer) readable form, including, but not limited to, floppy disks, optical disks, optical disks, read-only memories (CD-ROMs), magneto-optical disks, read-only memories (ROMs), random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, flash memory, or a tangible machine-readable memory for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in electrical, optical, acoustic, or other forms of propagation signals. Therefore, machine-readable media include any type of machine-readable media suitable for storing or transmitting electronic instructions or information in a machine (e.g., computer) readable form.

[0229] It should be noted that the units / modules mentioned in the various device embodiments of the present application are all logical units / modules. Physically, a logical unit / module can be a physical unit / module, or a part of a physical unit / module, or can be implemented as a combination of multiple physical units / modules. The physical implementation method of these logical units / modules themselves is not the most important. The combination of functions implemented by these logical units / modules is the key to solving the technical problems proposed by the present application. In addition, in order to highlight the innovative part of the present application, the above-mentioned device embodiments of the present application do not introduce units / modules that are not closely related to solving the technical problems proposed by the present application, which does not mean that there are no other units / modules in the above-mentioned device embodiments.

[0230] It should be noted that in the examples and description of this patent, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "including one" do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0231] Although the present application has been illustrated and described with reference to certain preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the present application.

Claims

1. A startup protection method, applied to electronic equipment, characterized in that: include: detecting a power-on instruction of the electronic device; During the Nth running process of the boot program, corresponding to the execution of a first stack building instruction for a first function included in the boot program, a random function is called to generate a first random value, wherein the first stack building instruction is used to instruct the establishment of a first stack with a first length of the first function, and the storage data of the first stack includes a return address, and the return address is the address of a second function to be executed after the first function is executed; Modify the first length of the first stack to a second length based on the first random value to obtain a second stack; storing the return address in the second stack, wherein the return address has different memory addresses in the first stack and the second stack; Based on the return address in the second stack, the second function is executed.

2. The method according to claim 1, characterized in that The executing the second function based on the return address in the second stack includes: After the first function completes calling the third function, the second function is called based on the return address in the second stack.

3. The method according to claim 1, characterized in that The calling of a random function to generate a first random value comprises: Corresponding to the number of rounds of calling the random function being equal to a preset round number threshold, reading a first value from the first memory address; If the first value is smaller than the boundary memory address of the boot program, determining a second memory address according to the first memory address and the first value; If the first value is greater than the boundary memory address of the boot program, use the first value as the second memory address; The second memory address is used as the first random value.

4. The method according to claim 3, characterized in that The method further comprises: Corresponding to determining the second memory address, the preset round number threshold is updated.

5. The method according to claim 4, characterized in that The method further comprises: Corresponding to determining the second memory address, the number of rounds of calling the random function is updated.

6. The method according to claim 1, characterized in that The method further comprises: Corresponding to the number of rounds of calling the random function being less than a preset round number threshold, reading a first value from a first memory address; If the first value is smaller than the boundary memory address of the boot program, determine the second memory address according to the first memory address and the first value, and update the number of rounds of calling the random function; If the first value is greater than the boundary memory address of the boot program, the first value is used as the second memory address, and the number of rounds of calling the random function is updated; Corresponding to the updated number of rounds of calling the random function being equal to the preset round number threshold, reading a second value from the second memory address; If the second value is smaller than the boundary memory address of the boot program, a third memory address is determined according to the second memory address and the second value, If the second value is greater than the boundary memory address of the boot program, the second value is used as the third memory address. The third memory address is used as the first random value.

7. The method according to claim 1, characterized in that The method further comprises: During the N+1th running process of the boot program, corresponding to detecting a second stack building instruction for a first function included in the boot program, calling the random function to generate a second random value, wherein the first random value is different from the second random value, The second stack building instruction is used to instruct to build a first stack of the first function with a first length, and the storage data of the first stack includes the return address required by the first function to call the second function; Modify the first length of the first stack to a third length based on the second random value to obtain a third stack; storing the return address in the third stack, wherein the return address has different memory addresses in the first stack and the third stack; Based on the return address in the third stack, the first function calls the second function.

8. The method according to any one of claims 1 to 7, characterized in that: The memory address of the return address in the first stack is the top of the stack, The memory address of the return address in the second stack is the top of the stack.

9. An electronic device, characterized in that: include: a memory for storing instructions executed by one or more processors of the electronic device, and a processor, which is one of the one or more processors of the electronic device, configured to control the electronic device to execute the method as claimed in any one of claims 1 to 8.

10. A readable storage medium, characterized in that: The readable storage medium stores instructions, and when the instructions are executed on an electronic device, the electronic device executes the method according to any one of claims 1 to 8.

11. A computer program product, characterized in that The computer program product comprises computer instructions, and when executed by an electronic device, the electronic device performs the method according to any one of claims 1 to 8.

Images