Guarding method, electronic device, storage medium and computer program product

Abstract

The application relates to the terminal technical field and provides a starting protection method, an electronic device, a storage medium and a computer program product. In the method, when the electronic device detects a starting instruction, the first section of starting code in BootRom is run; if a stack building instruction of a function included in the first section of starting code in BootRom is executed, a random function is called to generate a random value, the length of the stack built by the stack building instruction is changed, and the return address of the function included in the first section of starting code in BootRom to another function is stored in the stack after the length of the stack is changed. In this way, the actual memory address of the return address stored in the stack changes with the random value every time the execution is performed, so that an attacker cannot determine the return address to be tampered with, the jump to the malicious program tampered with by the attacker is prevented, the malicious program is executed, and the security of the device can be improved.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a boot protection method, electronic device, storage medium, and computer program product. Background Technology

[0002] BootROM is a read-only memory embedded within a system-on-a-chip (SoC) that stores the initial boot program required for an electronic device to start. After the electronic device powers on, the initial boot program in the BootROM runs, initializing the hardware and software, such as resetting registers. Then, a bootloader image file (e.g., xloader) is loaded into memory and its signature is verified to prevent tampering. After successful verification, the bootloader (e.g., xloader) runs. The bootloader then loads the fastboot program into memory and performs signature verification to prevent tampering. After successful verification, the fastboot program runs, loading the operating system kernel image file (e.g., the Linux kernel image file) into memory and performing signature verification to prevent operating system tampering. After successful verification, the operating system runs, loading pre-installed applications or third-party applications according to user settings or default configurations.

[0003] Therefore, BootROM is the foundation for secure booting of electronic devices. However, BootROM currently lacks security mechanisms similar to those of an operating system, such as memory isolation and memory overflow prevention. These vulnerabilities can be exploited by attackers to spread malicious applications, seriously affecting the security of electronic devices. Summary of the Invention

[0004] To address the issue of BootROM lacking a security protection mechanism, which affects the security of electronic devices, this application provides a boot protection method, an electronic device, a storage medium, and a computer program product.

[0005] In a first aspect, embodiments of this application provide a startup protection method applied to an electronic device, comprising: detecting a power-on command of the electronic device; during the Nth execution of the power-on program, corresponding to the execution of a first stack-building instruction for a first function included in the power-on program, calling a random function to generate a first random value, wherein the first stack-building instruction is used to instruct the creation of a first stack of a first length for the first function, the stored data of the first stack including a return address, the return address being the address of a second function to be executed after the first function has finished executing; modifying 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 memory addresses of the return address in the first stack and the second stack are different; 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 will change with a random value each time it is executed. This makes it difficult for attackers to determine the return address to be tampered with, thereby preventing jumps to malicious programs modified by attackers and execution of malicious programs, thus improving the security of the device.

[0007] It's understandable that detecting the power-on command for an electronic device could mean detecting that the user pressed the power button on the electronic device, thus powering it on. The boot program could be the first piece of startup code in the BootROM.

[0008] In some implementations of the first aspect, the second function is executed based on the return address in the second stack, including: after the first function completes its call to the third function, the second function is executed 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: reading a first value from a first memory address when the number of rounds corresponding to the call to the random function is equal to a preset round threshold; 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; 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 threshold mentioned above) is 0, and the current round number (i.e., the round number of 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 memory address mentioned above) 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 also includes: updating the preset round number threshold corresponding to determining the second memory address.

[0012] In some implementations of the first aspect, the method also includes: updating the number of rounds in which the random function is called in response to determining the second memory address.

[0013] In some implementations of the first aspect, the method further includes: corresponding to the number of rounds in which the random function is called being less than a preset round 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 in which the random function is called; 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 in which the random function is called; corresponding to the updated number of rounds in which the random function is called being equal to the preset round 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; 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 threshold mentioned above) is 1, and the current round number (i.e., the round number of the random function call mentioned above) is 0, the phone 100 can use the function addr = *(addr) to read the value a (i.e., the first memory address mentioned above) from 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) is used. Since 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. The value `b` (the second value mentioned above) at the new address `a + 0x20000` is then read. If `b` is less than `0x20000`, `b + 0x20000` can be used as the new address (i.e., the third memory address mentioned above). At this point, the total number of rounds is equal to the current number of rounds, i.e., `counter == num`. The new address `b + 0x20000` can then be returned. Simultaneously, the total number of rounds `counter` can be updated to 2.

[0015] For example, when the total number of rounds is 2 and the current number of rounds is 0, phone 100 can use the function `addr = *(addr)` to read the value `a` from the fixed address. If `a` is less than 0x20000, `a + 0x20000` can be used as the new address. At this point, 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` from the new address `a + 0x20000` can be read. If `b` is less than 0x20000, `b + 0x20000` can be used as the new address. At this point, the total number of rounds is equal to the current number of rounds, i.e., `counter == num`, and the new address `c + 0x20000` can be returned. Simultaneously, the total number of rounds `counter` can be updated to 3.

[0016] In some implementations of the first aspect, the method further includes: during the (N+1)th execution of the boot program, corresponding to the detection of a second stack-building instruction for the 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 instruct the creation of a first stack of a first length for the first function, and the stored data of the first stack includes the return address required by the first function to call the second function; modifying 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 memory addresses of the return address are different in the first stack and the third stack; and executing the call of the first function to the second function based on the return address in the third stack.

[0017] In this embodiment of the application, during each run of the boot program, the actual memory address storing the return address in the stack changes with a random value each time it is executed, making it difficult for attackers to determine the return address to be tampered with. This can prevent jumps to malicious programs tampered with by attackers and execution of malicious programs, thereby improving the security of the device.

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

[0019] It is understandable 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 can be the top of the stack. Since the length of the first stack and the length of the second stack are different, the memory address of the return address in the first stack and the memory address of the return address in the second stack are different.

[0020] It is important to understand that the memory address of the return address can be in the first stack or the memory address of the second stack. Furthermore, since the lengths of the first and second stacks are different, 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, embodiments of this application provide an electronic device, including 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 as mentioned in the first aspect or any of the first aspects.

[0022] Thirdly, embodiments of this application provide a readable storage medium storing instructions that, when executed on an electronic device, cause the electronic device to perform the startup protection method as described in the first aspect or any of the claims in the first aspect.

[0023] Fourthly, embodiments of this application provide a computer program product, which includes computer instructions that, when executed by an electronic device, enable the electronic device to perform a startup protection method as mentioned in the first aspect or any of the first aspects. Attached Figure Description

[0024] Figure 1 Based on some examples of this application, a scenario diagram is shown where a user holds a mobile phone 100 and presses the power button 101;

[0025] Figure 2 Based on some examples of this application, a schematic diagram of the power-on process of a mobile phone is shown;

[0026] Figure 3 Based on some examples of this application, a flowchart of processing a header block is shown;

[0027] Figure 4 Based on some examples of this application, a schematic diagram of an attacker's intrusion process is shown;

[0028] Figure 5 Based on some examples of this application, a schematic diagram of another attacker's intrusion process is shown;

[0029] Figure 6A Based on some examples of this application, a schematic diagram of changing the length of a stack is shown;

[0030] Figure 6B Based on some examples of this application, a flowchart of a method for initiating protection is shown;

[0031] Figure 7 Based on some examples of this application, a schematic diagram of the calling flow of a random function is shown;

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

[0033] Figure 9 Based on some examples of this application, a schematic diagram of a specific implementation of CFI on x86 is shown;

[0034] Figure 10 Based on some examples of this application, a schematic diagram is shown of a situation where the indirect jmp and ret instruction paths are instrumented by CFI.

[0035] Figure 11 Based on some examples of this application, a flowchart of a BootRom control flow integrity protection method is shown;

[0036] Figure 12 Based on some examples of this application, the hardware structure of an electronic device is illustrated. Detailed Implementation

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

[0038] The startup protection method mentioned in the embodiments of this application can be applied to electronic devices. The electronic devices in the embodiments of this application can be referred to as terminals, user equipment (UE), mobile terminals (MT), etc. Terminal devices can be desktop computers, laptops, mobile phones, wearable devices, tablets, computers with wireless transceiver capabilities, etc. For ease of explanation, the following description uses a mobile phone 100 as an example.

[0039] Figure 1 The illustration shows a scenario where a user holds a mobile phone 100 and presses the power button 101. After the user presses the power button 101 of the mobile phone 100, the mobile phone 100 can run the first boot program in the BootROM and enter the boot process.

[0040] After the phone is powered on, such as Figure 2 As shown, the first boot program in BootROM can be run to initialize the hardware and software in the phone 100, such as resetting registers. Then, the image file of a bootloader (e.g., xloader) can be loaded into memory and its signature verified to prevent tampering. After successful verification, the bootloader (e.g., xloader) can run. The bootloader (e.g., xloader) can then load the fastboot program and its signature verified to prevent tampering. After successful verification, the fastboot program can run into memory. The fastboot program can then load the operating system kernel image file (e.g., a Linux kernel image file) into memory and its signature verified to prevent operating system tampering. After successful verification, the operating system can run, loading built-in applications or third-party applications according to user settings or default configurations.

[0041] As mentioned earlier, BootROM currently lacks security protection mechanisms similar to those of an operating system, such as memory isolation and memory overflow prevention, making it prone to security vulnerabilities. These vulnerabilities can be exploited by attackers to spread malicious applications, seriously affecting the security of mobile phones.

[0042] The following section introduces the security vulnerabilities.

[0043] It's understandable that the phone 100 can include two modes: normal boot-up and downloading (i.e., flashing). Downloading is an action that changes the phone 100's operating system, essentially installing a new operating system to replace the old one. After installing the new operating system, pressing the power button on the phone 100 will power it on, allowing the first piece of boot code in the BootROM to run, thus enabling the phone 100 to boot up.

[0044] The following section will first introduce the process of the phone 100 being in download mode.

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

[0046] In some specific implementations, during the flashing process, the flashing device can first send the header chunk of the image file (such as the bootloader image file or kernel image file mentioned above) to the mobile phone 100. This header chunk can 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] Mobile Phone 100 can receive the Head Chunk and process it accordingly. For example, it can verify the Head Chunk. After successful verification, it can set the file download length and download address based on the Head Chunk, and check if the download address matches the pre-set download address. If the download address matches the pre-set download address, it resets the counter variable in the BootRom runtime stack. The specific processing flow will be discussed later. Figure 3 The details are elaborated in the previous section, and will not be repeated here to avoid repetition.

[0048] Because the image file is large, the flashing device cannot send the entire image file to the phone at once. Therefore, the flashing device can split the image file (such as a bootloader image file, kernel image file, etc.) into multiple parts. For example, the flashing device can split the image file into 10 parts, each of which can be 1024 bytes, 512 bytes, or other sizes. Then, the flashing device can send each part of the data to the phone as a data chunk.

[0049] After the flashing device sends the header chunk of the image file to phone 100, it can send each piece of data to phone 100 as a data chunk, until the entire image file is sent to phone 100. Upon receiving the data chunks, phone 100 can write the data from the data chunks to the file download address in its memory.

[0050] After the flashing device sends the entire image file to the mobile phone 100, the flashing device can send a tail chunk to the mobile phone 100 to notify the mobile phone 100 that the download is complete and the subsequent process of signing and verifying the image file can be executed.

[0051] Before the flashing device sends the Tail Chunk (i.e., the end block below) to the phone 100, the flashing device can send an Inquiry Chunk to the phone 100 to check the download progress of the image file.

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

[0053] Table 1

[0054]

[0055] In this context, Command can represent the protocol header, Seq can represent the data sequence number, ~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, and Checksum can represent the checksum. The checksum is used to ensure the integrity of data during transmission.

[0056] Table 2

[0057]

[0058] In this context, 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, Data can represent the data, and Checksum can represent the checksum.

[0059] Table 3

[0060]

[0061] In this context, 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, and Checksum can represent the checksum.

[0062] Table 4

[0063]

[0064] In this context, 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, and Checksum can represent the checksum.

[0065] Security vulnerabilities are generally more likely to occur when the phone is in download mode. The following section details one such vulnerability based on the phone's handling of the Head Chunk.

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

[0067] 301: Verify whether the header block passes the check.

[0068] Understandably, this is done to ensure the integrity and accuracy of the image file and reduce the risk of flashing failure. In some optional instances, after the phone receives the header block sent by the flashing device, it can verify the sequence number (Seq), file type (File-type), and header block message length (msg_len) of the data in the header block. For example, it verifies whether the data sequence number is 0, whether the file type is the same as the file type corresponding to the image file, and whether the header block message length is the preset message length.

[0069] In some optional instances, when the verification passes, for example, if the data sequence number is 0, the file type is the file type corresponding to the image file, and the message length of the header block is the pre-set message length, the process can proceed to step 302 to set the file download length, or to step 303 to set the file download address.

[0070] In some alternative instances, if the verification fails, for example, if the data serial number 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 process can proceed to step 307 to send a verification error response to the flashing device.

[0071] In addition, the protocol header, data sequence number, data inverted sequence number, and checksum in the header block can also be verified, which will not be elaborated here.

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

[0073] In some optional instances, the phone 100 can 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 can 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 represents the file download length and Length represents the length of the image file in the header block.

[0075] 303: The file download address is set to the download address of the mirror file in the header block.

[0076] In some optional instances, the mobile phone 100 can 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 file download address can be set to the download address of the mirror file in the header block using the following code: file_download_address = address, where file_download_address can represent the file download address, and address can represent the download address of the mirror file in the header block.

[0078] It is understood that the sequential execution of steps 302 and 303 can be either step 302 first and then step 303, or step 303 first and then step 302, or steps 302 and 303 can be executed in parallel. This application embodiment does not make specific limitations.

[0079] 304: Check if the file download address matches the pre-set download address.

[0080] It's understandable that the pre-set download address could be agreed upon by the processor manufacturer, operating system vendor, or flashing tool developer of the phone. 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 matches the pre-set download address, the process can proceed 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 does not match the pre-set download address, the process can proceed to step 308 to send an address error response to the flashing device.

[0082] In some optional instances, the following code can be used to determine whether the file download address is consistent with the pre-set download address: address == 0x22000, where address can represent the file download address and 0x22000 can represent the pre-set download address.

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

[0084] It is understandable that, in order to ensure that the counter variables in the BootRom runtime stack have a clear initial state before use, the counter variables 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 pre-set download address.

[0085] It is understandable that the first startup program in BootROM can include multiple instructions. When the first startup program in BootROM runs, a stack is created in memory to store variables and return addresses during the execution process. The variables can include counter variables such as the number of data blocks received, 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 is understandable that when the download address of the image file extracted from the header block matches 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 instances, the number of received data blocks can be initialized using the following code: total_received = 0, where total_received can represent the number of received data blocks.

[0088] In some optional instances, the sequence number of the last received data block can be initialized using the following code: last_seen_seq = 0, where last_seen_seq can represent the sequence number of the last received data block.

[0089] In some optional instances, the total number of transfers can be the total number of parts the flashing device splits the image file into +1, where +1 can represent the tail block. Specifically, the total number of transfers can be initialized using the following code: total_frame_count = ┌Length / 1024┐ + 1, where total_frame_count represents the total number of transfers, Length represents the length of the image file in the header block, 1024 represents the size of each part when the flashing device splits the image file into multiple parts, and ┌┐ represents rounding up.

[0090] In some optional instances, the sequence number of the next received data block can be initialized using the following code: next_seq = 1, where next_seq can represent the sequence number of the next received data block.

[0091] 306: Sends an initialization complete response to the flashing device.

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

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

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

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

[0096] In some optional instances, when verification fails, such as when the data serial number is not 0, the file type is not the same as 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 instances, the mobile phone 100 can send a verification error response to the flashing device using the following code: send_sub_response(xmodem, 0x55), where 0x55 can represent the error code when the file type in the header block is not the same as the file type corresponding to the image file.

[0097] 308: An address error response was sent to the flashing device.

[0098] It is understandable that the address error response is used to notify the flashing device that the download address in the header is inconsistent with the preset download address, and the header 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 preset download address, the mobile phone 100 can send the error code corresponding to the address mismatch to the flashing device using the following code: 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 preset download address.

[0100] However, verifying whether the download address in the header matches the pre-set address only affects whether the counter variable in the BootROM runtime stack is reset; it does not affect setting the file download length to the length of the image file in the header, nor does it affect setting the file download address to the download address in the header. Furthermore, since there is no verification of the length of the image file (e.g., "Length" in Table 1) and the download address of the image file (e.g., "Address" in Table 1) in the header, attackers can write arbitrary lengths in the header, such as the length of a malicious program's (e.g., payload) image file, and can write arbitrary download addresses in the header. This allows attackers to write malicious programs of arbitrary length at any location in memory, thereby tampering with the normal execution logic of instructions in the BootROM and bypassing signature verification, severely impacting the security of the mobile phone.

[0101] It's understandable that the program written by the attacker on the flashing device can be called malware. In some specific implementations, the flashing device can split the entire malware image file into multiple parts and send each part of the data to the phone 100 in the form of a data chunk while the phone 100 is in download mode.

[0102] In some optional instances, if an attacker sets the download address of the image file in the header block to a pre-set download address (e.g., 0x22000), the malware can be downloaded to the pre-set download address in memory.

[0103] In some alternative instances, if an attacker intends to set the download address of the image file in the header block to the target download address, the malware can be downloaded to the target download address in memory. It is worth noting that this demonstration attack uses a pre-set download address for this stage.

[0104] For example, the flashing device first sends the header block A of an image file whose download address matches the pre-set download address to the mobile phone 100 (i.e., the correct header block A). After the mobile phone 100 verifies the header block A, the flashing device sends data blocks to the mobile phone 100. While the flashing device is sending data blocks to the mobile phone 100, the flashing device can also send the header block B corresponding to the image file of a malicious program written by the attacker (i.e., header block B whose download address does not match the pre-set download address).

[0105] The following section describes the attacker's intrusion process. Figure 4 This diagram illustrates an attacker's intrusion process, such as... Figure 4 As shown, the intrusion process may include:

[0106] 401: The flashing device sends header A to phone 100. The download address of the image file in header A is a pre-set download address, and the length of the image file in header A can be arbitrary.

[0107] It is understandable that in the header block A sent by the flashing device to the phone 100, the attacker can set the download address in the header block A to a pre-set download address, such as 0x22000, and can set the length of the image file in the header block A to an arbitrary length, thus resetting the counter variable in the BootRom runtime stack.

[0108] 402: The flashing device sends Header Block B to phone 100 again. The download address of the image file in Header Block B is the target download address. The length of the image file in Header Block B can be arbitrary.

[0109] It is understandable that the target download address can be any download address that the attacker writes in header block B, such as the download address of malicious programs.

[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 the download address of the image file to an arbitrary address. That is, the attacker can write arbitrary length and arbitrary address in the next header block B sent by the flashing device to the mobile phone 100.

[0111] It is understandable that if an attacker intends to download the malicious program to a pre-set download address in memory (e.g., 0x22000), they can execute only step 401 and skip step 402. If the attacker intends to download the malicious program to a non-pre-set download address in memory (i.e., the target download address), they can execute step 401 first, and then step 402. For ease of explanation, the following description uses the example of an attacker intending to download the malicious program to a non-pre-set download address in memory (i.e., the target download address).

[0112] 403: The flashing device sent a data block to phone 100.

[0113] It is understandable that after the flashing device sends two header blocks to the phone 100, it can send data blocks to the phone 100, and the phone 100 can write the data in the data blocks into the target download address in its memory.

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

[0115] The following section continues to describe the attacker's intrusion process, such as... Figure 5 As shown, the intrusion process may include:

[0116] 501: Downloaded image file of malicious program.

[0117] In some optional instances, if an attacker sets the download address of the image file in the header block to a pre-set download address (e.g., 0x22000), then mobile phone 100 can download the malicious program to the pre-set download address in memory.

[0118] In some alternative instances, if an attacker intends to set the download address of the image file in the header block as the target download address, then mobile phone 100 can download the malware to the target download address in memory. It is worth noting that this demonstration attack uses a pre-set download address for this stage.

[0119] 502: End of transmission block.

[0120] It is understandable that the end block refers to the tail block mentioned earlier. After the flashing device sends the entire image file of the malicious program to the phone 100, the flashing device can send the tail block to the phone 100 to notify the phone 100 that the download is complete.

[0121] Understandably, after receiving the entire image file of the malicious program, the phone will perform signature verification on the image file at the pre-set download address. It's important to note that the image file at the pre-set download address must be the image file of the malicious program; any image file not pre-set will inevitably fail verification. After verification failure, the process will proceed to step 503, starting a new round of downloading the malicious program's image file.

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

[0123] As can be understood, as mentioned earlier, an attacker can set the download address of the image file in the header block to an arbitrary address. Therefore, after failing to verify the signature of the downloaded malicious program's image file, they can download another malicious program's image file. It is worth noting that even if the signature verification of the malicious program's image file fails, the downloaded malicious program's image file still retains its download address in memory (e.g., a pre-set download address 0x22000 or the target download address).

[0124] 504: The returned address was modified using an arbitrary download address.

[0125] As mentioned earlier, during the execution of the first startup program in BootROM, a stack is created in memory to store variables and return addresses during the program's execution. The stack refers to a contiguous block of memory that stores variables and return addresses. In other words, the processor in the phone can allocate a contiguous block of memory to store variables and return addresses. The return address refers to the address of the function to be executed after a function call completes. This pre-set address can be agreed upon by the processor manufacturer, operating system vendor, or flashing tool developer in the phone, such as 0x22000. When a function calls a called function, the return address is pushed onto the stack. After the called function completes its execution, the return address is popped from the stack, allowing the processor to jump and execute the function at that return address.

[0126] Typically, processor manufacturers or operating system vendors pre-define that the return address is stored at the top of the stack allocated to BootROM. Thus, if an attacker knows the actual memory address where the return address is stored in BootROM runtime memory (i.e., the stack top mentioned earlier), they can tamper with the return address to the download address of a malicious program, allowing the attacker to jump to and execute the malicious program at the return address after the subroutine finishes execution.

[0127] 505: End of transmission block.

[0128] It is understandable that step 505 can be referenced from step 503; to avoid repetition, it will not be repeated here. It is worth noting that signature verification still fails at this point.

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

[0130] In some optional instances, when the return address on the stack is tampered with to the download address of a malicious program, the execution of the malicious program's image file can be redirected after the function finishes running.

[0131] Therefore, during the execution of functions by the processor of mobile phone 100, there is a possibility that an attacker may maliciously hijack the function control flow. Specifically, an attacker can modify the return address of a sub-function, changing the normal return address to the download address of a malicious program. This causes the processor to jump to the download address of the malicious program after executing the sub-function, thereby executing the malicious program and changing the function control flow, thus compromising the function's control flow integrity (CFI).

[0132] As mentioned earlier, because BootROM lacks security mechanisms similar to those of an operating system, attackers can tamper with the download address of the image file in the header block to any arbitrary address. This allows attackers to write malicious programs of arbitrary length to any download address in memory. Secondly, knowing the actual memory address of the return address (ret address) in the BootROM runtime stack, attackers can tamper with this return address to the download address of a malicious program (e.g., a payload). Thus, after the first startup function in BootROM is executed upon power-up of the phone 100, the processor will jump to the download address of the malicious program and load the image file of the malicious program (e.g., a payload) into memory, disrupting the normal execution logic of BootROM and enabling malicious flashing, spreading malicious application functions, and severely impacting the security of the phone 100.

[0133] It's understandable that when storing the return address mentioned above onto the stack, if the stack length changes, the memory address of the return address on the stack will change accordingly. For example, as... Figure 6A As shown in (a), assuming the length of the stack is A, the memory address of the return address in the stack can be A1.

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

[0135] To address the aforementioned issues, this application provides a boot protection method. In this method, when an electronic device detects a power-on command (e.g., a power button being pressed), it executes the first segment of boot code in the BootROM. If the execution reaches a stack-building instruction for a function included in the first segment of boot code in the BootROM, a random function is called to generate a random value, thereby changing the length of the stack created by the stack-building instruction. The return addresses of other functions called by the functions included in the first segment of boot code in the BootROM are then stored in the stack after the stack length has been changed. This ensures that the actual memory address storing the return address changes with the random value each time the stack-building instruction is executed, making it difficult for an attacker to determine the actual memory address of the return address to be tampered with. This prevents jumps to malicious programs modified by the attacker and execution of malicious programs, thus improving device security.

[0136] For example, in some optional instances, the value 'a' can be read from a fixed address. Each time the random function is called, the current round number can be initialized to 0. If the current round number of the random function call is less than the total number of rounds, and 'a' is less than the code segment boundary address in the BootROM (e.g., 0x20000), 'a' + 0x20000 can be used as the new address. If 'a' is greater than the code segment boundary address in the BootROM (e.g., 0x20000), 'a' can be used as the new address, and the value 'b' at the new address can be read, assigned to 'a', and the current round number incremented by 1. If the current round number of the random function call is still less than the total number of rounds, the above steps can be repeated until the current round number of the random function equals the total number of rounds, at which point the random value 'a' is returned ('a' will change depending on the current round number, such as assigning 'b' to 'a' as mentioned earlier). The random value 'a' represents the length of the changed stack; that is, the length of the stack is increased by the length corresponding to the random value based on the length of the stack created by the stack creation instruction.

[0137] The startup protection method mentioned in the embodiments of this application will be described in detail below. Figure 6B A flowchart illustrating a boot protection method is shown. This method can be executed by an electronic device. Specifically, the boot protection method may include:

[0138] 601: Power-on command detected for electronic device.

[0139] It can be understood that detecting the power-on command of an electronic device can mean detecting that the user has pressed the power button of the electronic device to power it on.

[0140] 602: During the Nth run of the boot program, corresponding to the execution of the stack building instruction for the first function included in the boot program, a random function is called to generate a random value. The stack building instruction is used to instruct the creation of a first stack with a first length for the first function. The storage data of the first stack includes the return address, which is the address of the second function to be executed after the first function has finished executing.

[0141] It's understandable that the boot program can be the first piece of startup code in BootRom.

[0142] The following example illustrates the return address. Assume the first startup program in BootROM includes functions A, B, and C, where function B can be a calling function. The normal execution flow is to execute functions A, B, and C sequentially. Since function B is a calling function, when the processor executes function B, it jumps to the address of the sub-function (the third function mentioned above) corresponding to function B (i.e., the first function mentioned above) and executes the sub-function. To ensure that the processor can correctly return to the address of function C (i.e., the second function mentioned above) after executing the sub-function corresponding to function B, the processor saves the address of function C before executing function B; that is, the processor writes the address of function C as the return address onto the stack.

[0143] In some optional instances, the first random value can be determined as follows: the number of rounds corresponding to the call to the random function is equal to a preset round threshold, and the first value is read from the first memory address; if the first value is less 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] The first memory address is the fixed address mentioned in this application, and the boundary memory address is the boundary address of the code segment in BootRom mentioned in this application. In this way, the first startup code segment in BootRom can be skipped and the next code can be executed.

[0145] In some alternative instances, the first random value can be determined as follows: if the number of rounds in which the random function is called is less than a preset round threshold, the first value is read from the 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 in which the random function is called is updated; if the updated number of rounds in which the random function is called is equal to the preset round threshold, a second value is read from the 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: Based on the first random value, modify the first length of the first stack to the second length to obtain the second stack.

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

[0150] 604: The return address is stored in the second stack, where the memory address of the return address is different in the first stack and the second stack.

[0151] It is understandable 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 can be the top of the stack. Since the length of the first stack and the length of the second stack are different, the memory address of the return address in the first stack and the memory address of the return address in the second stack are different.

[0152] It is important to understand that the memory address of the return address can be in the first stack or the memory address of the second stack. Furthermore, since the lengths of the first and second stacks are different, 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's understandable that after the first function calls the third function, the second function can be read and executed based on the return address in the second stack. It's important to note that the second function is the one executed after the first function has finished its execution sequence.

[0155] The following section introduces how random functions generate random values.

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

[0157] 701: Random function reads global variables.

[0158] It's understandable that the total number of rounds can be a global variable, defaulting to 0, for example, counter = 0. The current round number can be initialized to 0, for example, num = 0. The fixed address can be a memory address that BootRom reads at a fixed time, for example, you can set the fixed address using the following code: addr = fixed address.

[0159] 702: Read the value from a fixed address.

[0160] In some optional instances, the value at a fixed address can be read using the following code: addr = *(addr).

[0161] 703: Determines whether the value at a fixed address is less than the boundary address of the code segment in BootRom.

[0162] In some optional instances, the following code can be used to determine whether the value at the fixed address is less than the boundary address of the code segment in the BootROM: addr < 0x20000, where 0x20000 can represent the boundary address of the code segment in the BootROM. It should be understood that the boundary address of the code segment in the BootROM can be different for different chips; the 0x20000 mentioned in this application embodiment is merely an optional instance.

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

[0164] 704: Reset read address.

[0165] In some optional instances, the read address can be reset using the following code: addr += 0x20000, which means the sum of the value at the fixed address and the boundary address of the code segment in BootRom is used as the new read address.

[0166] 705: Determine if the current round number is equal to the total number of rounds.

[0167] In some optional instances, the following code can be used to determine if the current round number is equal to the total number of rounds: `num == counter`. If the current round number is equal to the total number of rounds, proceed to step 706 to update the total number of rounds, then proceed to step 707 to return to the new address. If the current round number is not equal to the total number of rounds, proceed to step 708 to update the current round number.

[0168] 706: Update total number of rounds.

[0169] In some optional instances, the total number of rounds can be updated using the following code: counter = (counter + 1) % 100.

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

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

[0172] 708: Update the current round number.

[0173] In some optional instances, the current round number can be updated using the following code: num += 1.

[0174] The following example will provide a detailed explanation of the process of generating random values ​​using the random function described above.

[0175] When the total number of rounds is 0 and the current number of rounds is 0, phone 100 can use the function addr = *(addr) to read the value 'a' from 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 equal to the current number of rounds, i.e., counter == num, and the new address a + 0x20000 can be returned. Simultaneously, the total number of rounds counter can be updated to 1. Otherwise, 'a' is returned directly.

[0176] When the total number of rounds is 1 and the current number of rounds is 0, phone 100 can use the function addr = *(addr) to read the value 'a' from 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 also be used as the new address. At this point, 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' from the new address a + 0x20000 can be read. If 'b' is less than 0x20000, b + 0x20000 can be used as the new address; if 'b' is greater than 0x20000, b can also be used as the new address. At this point, the total number of rounds counter is equal to the current number of rounds, i.e., counter == num. The new address b + 0x20000 can then be returned. Simultaneously, the total number of rounds counter can be updated to 2.

[0177] When the total number of rounds is 2 and the current round number is 0, phone 100 can use the function addr = *(addr) to read the value 'a' from 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 round number. The function num += 1 can be used to update the current round number, and the value 'b' in the new address a + 0x20000 can be read. If 'b' is less than 0x20000, 'b + 0x2000' can be used. If 0 is used as the new address, and b is greater than 0x20000, then b can be used as the new address. At this point, 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` at the new address `b + 0x20000` can be read. If `c` is less than 0x20000, then `c + 0x20000` can be used as the new address. If `c` is greater than 0x20000, then `c` can be used as the new address. At this point, the total number of rounds is equal to the current number of rounds, i.e., `counter == num`. The new address `c + 0x20000` can then be returned. Simultaneously, the total number of rounds `counter` can be updated to 3.

[0178] It is understandable 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 continuously with the total number of rounds. Therefore, attackers cannot know the exact value of the stack length increase obtained by calling the random function when creating the stack, and thus cannot know the actual memory address where the return address is stored in the stack. This makes it difficult for attackers to tamper with the return address of the stack to change the download address of malicious programs, thereby preventing the program from jumping to the malicious programs tampered with by the attacker and improving the security of the device.

[0179] In some specific implementations, random functions can be inserted into the BootRom source code. The following describes the method of inserting random functions into the BootRom source code in the embodiments of this application.

[0180] like Figure 8As shown, BootROM source code can be instrumented, that is, random functions can be inserted into the BootROM source code, and all jump instructions (such as call instructions, including direct jump instructions and indirect jump instructions) can be searched. For example, an indirect jump instruction could refer to the instruction in the first function calling the third function mentioned above. The stack building code corresponding to the stack building instruction can be determined. This stack building code can call the random function, causing the stack length to increase by a random value. When determining the return address of the randomized stack, that is, when modifying the stack length, since stack building involves decrementing the extended stackpointer register (ESP) at the top of the stack (the stack grows from high address to low address), the ESP needs to be decremented accordingly after the random function call is completed. Furthermore, when modifying and restoring the stack, the changed value at the top of the stack is increased by this random value. Then, BootROM can be compiled, and then it can be programmed into the read-only memory inside the system-on-chip (SOC) (it will melt down after the first programming, and subsequent read-only programming cannot modify it).

[0181] Another startup protection method mentioned in the embodiments of this application will be described below.

[0182] Control flow hijacking is a highly dangerous attack method that allows attackers to gain control of a target machine, and even escalate privileges to achieve complete control. Attackers typically consider launching a control flow hijacking attack once they discover a memory error vulnerability in the target program.

[0183] To combat control flow hijacking attacks, existing solutions propose a control flow integrity (CFI) defense mechanism (hereinafter, control flow integrity refers to the solution itself). This mechanism restricts control transfers during program execution, ensuring they remain within the bounds of the original control flow graph. Specifically, it analyzes the program's control flow graph to obtain a whitelist of target addresses for indirect transfer instructions (including indirect jump instructions, indirect call instructions, and function return instructions). During execution, it checks whether the target of each indirect transfer instruction is in the whitelist. If the target address is in the whitelist, the program at that target address in memory is jumped to or called; otherwise, an error is reported.

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

[0185] Combining the two classification methods above:

[0186] The forward jump instructions jmp and call can be further divided into four types based on the addressing mode: direct jmp instruction, indirect jmp instruction, direct call instruction, and indirect call instruction.

[0187] The back jump instruction `ret` has no operands; its target address is determined by the return address on the stack. It is precisely this characteristic of the `ret` instruction that has led to a series of attacks targeting the return address.

[0188] Therefore, in some alternative instances, code can be inserted to determine the control flow path for 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 if the target address ID is valid. If valid, allow indirect jump; otherwise, report an error.

[0191] Figure 9 It is a specific implementation of CFI on x86:

[0192] Original state: exc stores the target address, jmp exc indirectly jumps to the target address to execute.

[0193] Instrumentation 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 result is yes (valid), indirectly jump to the address [exc+4] to execute the original target instruction. If the result is no (invalid), report an error.

[0194] Instrumentation method (b): Based on instrumentation method (a), an optimization is made. A 4-byte label instruction prefetchnta + 4-byte ID "12345678h" is inserted at the target address. A stub function is inserted before the jmp jump. The stub function is used to determine whether the value at address [exc+4] is 12345678h. If the result is yes (valid), the jump is indirectly made to address [ecx] to execute the label instruction. If the result is no (invalid), an error is reported.

[0195] Figure 10 This illustrates a scenario where both the indirect call and ret instruction paths are instrumented by CFI. For details on the jump methods, please refer to [reference needed]. Figure 9 To avoid repetition, this will not be elaborated upon here.

[0196] For CFI to be realized, the following three assumptions are crucial:

[0197] UNQ. Unique ID: After CFI detection, the bit pattern selected as the ID must not appear anywhere in the code memory, except for the ID and ID check. This property can be easily achieved by making the ID large enough (e.g., 32 bits, for reasonably sized software) and by selecting the IDs so that they do not conflict with opcode bytes in the rest of the software.

[0198] NWC. No-Write Code: The program must be unable to modify the code memory at runtime; otherwise, an attacker might be able to bypass CFI, for example, by overriding ID checks.

[0199] NXD. Non-executable data: The program must not be able to execute data like code; otherwise, an attacker could potentially execute data with the expected ID.

[0200] However, NWC exists in the BootRom runtime environment, and the code is read-only, but NXD is not feasible because it requires loading and running subsequent image files. Therefore, the existing CFI cannot be directly ported to BootRom.

[0201] As mentioned earlier, the problem with direct porting is that attackers can forge tags to bypass CFI. Therefore, this application provides a method for protecting the control flow integrity of BootRom.

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

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

[0204] In this way, even if CFI is bypassed through a forged tag, it can still be identified because the target address has been tampered with. The target address can refer to the address of the second function that needs to be executed after the first function calls the third function, as described above.

[0205] When executing xloader via BootRoom jump, the above operation is not performed on this BootRoom jump instruction (although the target address is writable, this is a necessary special case).

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

[0207] The hardware structure of electronic devices will be introduced below. Figure 12 A schematic diagram of the structure of the electronic device 100 is shown.

[0208] 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, antenna 1, antenna 2, a mobile communication module (2G / 3G / 4G / 5G) 150, a wireless communication module (BT / WLAN / GNSS / NFC / IR / FM) 160, an audio module 170, a sensor module 180, buttons 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 understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0210] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0211] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

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

[0213] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 receives charging input from the wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 receives wireless charging input via the wireless charging coil of the electronic device 100. While charging the battery 142, the charging management module 140 can also supply power to the electronic device via the power management module 141.

[0214] The power management module 141 connects 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, supplying power to the processor 110, internal memory 121, display 194, camera 193, and wireless communication modules such as BT / WLAN / GNSS / NFC / IR / FM160. The power management module 141 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance). In some other embodiments, the power management module 141 may also be located within the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may be housed in the same device.

[0215] The external storage 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 storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

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

[0217] Pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. In some embodiments, pressure sensor 180A can be disposed on display screen 194. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors. A capacitive pressure sensor may include at least two parallel plates with conductive material. When force is applied to pressure sensor 180A, the capacitance between the electrodes changes. Electronic device 100 determines the pressure intensity based on the change in capacitance. When a touch operation is applied to display screen 194, electronic device 100 detects the intensity of the touch operation based on pressure sensor 180A. Electronic device 100 can also calculate the touch position based on the detection signal from pressure sensor 180A. In some embodiments, touch operations applied to the same touch position but with different touch operation intensities can correspond to different operation commands. For example, when a touch operation with an intensity less than a first pressure threshold is applied to the SMS application icon, a command to view an SMS is executed. When a touch operation with an intensity greater than or equal to the first pressure threshold is applied to the SMS application icon, a command to create a new SMS is executed.

[0218] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch-sensitive buttons. Electronic device 100 can receive button input and generate key signal inputs related to user settings and function control of electronic device 100.

[0219] The various embodiments of the mechanisms disclosed in this application can be implemented in hardware, software, firmware, or a combination of these implementation methods. Embodiments of this application can be implemented as computer programs or program code executable on a programmable system, the programmable system including 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 execute 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, the processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0221] The program code can be implemented using a high-level procedural language or an object-oriented programming language to communicate with the processing system. Assembly language or machine language can also be used when needed. In fact, the mechanisms described in this application are not limited to any particular 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 thereon 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, the instructions may be distributed via a network or through other computer-readable media. Therefore, machine-readable media may include any mechanism for storing or transmitting information in a machine-readable (e.g., computer-readable) form, including but not limited to floppy disks, optical disks, CD-ROMs, magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, flash memory, or tangible machine-readable storage for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in the form of electrical, optical, acoustic, or other propagation signals. Therefore, machine-readable media include any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.

[0223] The above describes the possible hardware structures of electronic devices. It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device. In other embodiments of this application, the electronic device may include more or fewer components than illustrated, or combine certain components, or split certain components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of both.

[0224] In the accompanying drawings, some structural or methodological 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 necessary. Rather, in some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. Furthermore, the inclusion of structural or methodological features in a particular figure does not imply that such features are required in all embodiments, and in some embodiments, these features may be omitted or may be combined with other features.

[0225] The various embodiments of the mechanisms disclosed in this application can be implemented in hardware, software, firmware, or a combination of these implementation methods. Embodiments of this application can be implemented as computer programs or program code executable on a programmable system, the programmable system including 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 execute 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, the processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0227] The program code can be implemented using a high-level procedural language or an object-oriented programming language to communicate with the processing system. Assembly language or machine language can also be used when needed. In fact, the mechanisms described in this application are not limited to any particular 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 thereon 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, the instructions may be distributed via a network or through other computer-readable media. Therefore, machine-readable media may include any mechanism for storing or transmitting information in a machine-readable (e.g., computer-readable) form, including but not limited to floppy disks, optical disks, CD-ROMs, magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, flash memory, or tangible machine-readable storage for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in the form of electrical, optical, acoustic, or other propagation signals. Therefore, machine-readable media include any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.

[0229] It should be noted that all units / modules mentioned in the device embodiments of this application are logical units / modules. Physically, a logical unit / module can be a physical unit / module, a part of a physical unit / module, or a combination of multiple physical units / modules. The physical implementation of these logical units / modules themselves is not the most important factor; the combination of functions implemented by these logical units / modules is the key to solving the technical problems proposed in this application. Furthermore, to highlight the innovative aspects of this application, the above-described device embodiments of this application have not introduced units / modules that are not closely related to solving the technical problems proposed in this application. This does not mean that the above-described device embodiments do not contain other units / modules.

[0230] It should be noted that in the examples and description of this patent, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0231] Although this application has been illustrated and described with reference to certain preferred embodiments thereof, those skilled in the art will understand that various changes in form and detail may be made thereto without departing from the scope of this application.

Claims

1. A startup protection method, applied to electronic devices, characterized in that, include: A power-on command for the electronic device was detected; During the Nth run of the boot program, corresponding to the execution of the first stack building instruction for the first function included in the boot program, a random function is called to generate a first random value. The first stack building instruction is used to instruct the creation of a first stack with a first length for the first function. The storage data of the first stack includes a return address, which is the address of the second function to be executed after the first function has finished executing. Based on the first random value, the first length of the first stack is modified to the second length to obtain the second stack; The return address is stored in the second stack, wherein the memory addresses of the return address are different in the first stack and the second stack; The second function is executed based on the return address in the second stack.

2. The method according to claim 1, characterized in that, The execution of the second function based on the return address in the second stack includes: After the first function finishes 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 step of calling the random function to generate the first random value includes: The first value is read from the first memory address when the number of rounds in which the random function is called is equal to the preset round threshold. If the first value is less 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; Use the second memory address as the first random value.

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

5. The method according to claim 4, characterized in that, The method further includes: Corresponding to the determination of the second memory address, the number of rounds in which the random function is called is updated.

6. The method according to claim 1, characterized in that, The method further includes: If the number of rounds in which the random function is called is less than a preset round threshold, a first value is read from the first memory address. If the first value is less 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, and the number of rounds in which the random function is called is updated. 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 in which the random function is called is updated. The number of rounds corresponding to the updated call to the random function is equal to the preset round threshold, and the second value is read from the second memory address; If the second value is less than the boundary memory address of the boot program, the third memory address is determined based on 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. Use the third memory address as the first random value.

7. The method according to claim 1, characterized in that, The method further includes: During the (N+1)th execution of the boot program, corresponding to the detection of a second stack-building instruction for the first function included in the boot program, the random function is called 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 the creation of a first stack with a first length for the first function, and the data stored in the first stack includes the return address required by the first function to call the second function; Based on the second random value, the first length of the first stack is modified to the third length to obtain the third stack; The return address is stored in the third stack, wherein the memory address of the return address is different 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-7, characterized in that, The return address is located at the top of the first stack. The return address is located at the top of the second stack.

9. An electronic device, characterized in that, include: Memory for storing instructions executed by one or more processors of the electronic device. And a processor, which is one or more processors of the electronic device, for controlling the electronic device to perform the method as described in any one of claims 1-8.

10. A readable storage medium, characterized in that, The readable storage medium stores instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1-8.

11. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed by an electronic device, enable the electronic device to perform the method as described in any one of claims 1-8.

Images