Security verification method and device, electronic device, and storage medium

Abstract

A security verification method and device, electronic device, and storage medium, the method comprising: when an initial Init process is started, a verification file is loaded through the initial Init process, the verification file includes verification data corresponding to executable files respectively; when a target executable file is loaded, first verification data is determined according to the file attribute of the target executable file; second verification data corresponding to the target executable file is read from the verification file; the first verification data is compared with the second verification data, and the security verification result of the target executable file is determined according to the comparison result. By implementing the embodiment of the present application, a security verification can be performed as early as possible when the electronic device is turned on, thereby improving the security of the electronic device.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and in particular to a security verification method and device, electronic equipment, and storage medium. Background Art

[0002] Currently, electronic devices, including smartphones, tablets, and wearables, are generally exposed to the risk of executable files being tampered with. Therefore, security verification is often required before running executable files. However, in practice, it has been found that electronic devices often perform security verification tasks only after they are powered on and running stably. This makes security verification untimely, leaving potential security risks and reducing the security of electronic devices. Summary of the Invention

[0003] The embodiments of the present application disclose a security verification method and device, an electronic device, and a storage medium, which can perform a security verification as early as possible when the electronic device is turned on, thereby improving the security of the electronic device.

[0004] The first aspect of the embodiments of the present application discloses a security verification method, including:

[0005] When the initial Init process is started, a verification file is loaded through the initial Init process, wherein the verification file includes verification data corresponding to the executable files respectively;

[0006] When loading a target executable file, determining first verification data according to a file attribute of the target executable file;

[0007] Reading second verification data corresponding to the target executable file from the verification file;

[0008] The first verification data is compared with the second verification data, and a security verification result of the target executable file is determined according to the comparison result.

[0009] As an optional implementation manner, in the first aspect of the embodiment of the present application, when loading the target executable file, determining the first verification data according to the file attributes of the target executable file includes:

[0010] The target executable file is loaded through the initial Init process, and first verification data is determined according to the file attribute of the target executable file.

[0011] As an optional implementation, in the first aspect of the embodiment of the present application, when the initial Init process is started, before the verification file is loaded by the initial Init process, the method further includes:

[0012] Compile the source code file to obtain an executable file;

[0013] Calculate and save the verification data corresponding to the executable file into a verification file;

[0014] The executable file and the verification file are stored in an electronic device.

[0015] As an optional implementation manner, in the first aspect of the embodiment of the present application, when loading the target executable file, determining the first verification data according to the file attributes of the target executable file includes:

[0016] When loading a target executable file, obtaining a target verification identifier of the target executable file;

[0017] According to the target verification identifier, it is determined whether the target executable file needs to be verified. If verification is required, first verification data is determined according to the file attribute of the target executable file.

[0018] As an optional implementation manner, in the first aspect of the embodiment of the present application, before determining whether the target executable file needs to be verified based on the verification identifier, the method further includes:

[0019] Obtaining an executable file verification list, wherein the executable file verification list includes a verification identifier of at least one executable file that needs to be verified;

[0020] The determining, based on the target verification identifier, whether the target executable file needs to be verified includes:

[0021] The target verification identifier is searched for on the executable file verification list, and if the target verification identifier is found, it is determined that the target executable file needs to be verified.

[0022] As an optional implementation manner, in the first aspect of the embodiment of the present application, determining the security verification result of the target executable file according to the comparison result includes:

[0023] If the comparison result is that the first verification data matches the second verification data, determining that the target executable file passes the security verification;

[0024] If the comparison result is that the first verification data does not match the second verification data, it is determined that the target executable file fails the security verification.

[0025] As an optional implementation manner, in the first aspect of the embodiment of the present application, the method further includes:

[0026] When it is determined that the target executable file does not pass the security check, the loading of the target executable file is terminated, and a feedback operation corresponding to the target executable file is triggered, and the feedback operation at least includes recording a security check log and / or sending the security check result to a service device.

[0027] A second aspect of an embodiment of the present application discloses a security verification device, comprising:

[0028] A first loading unit is configured to load a verification file through the initial Init process when the initial Init process is started, the verification file including verification data corresponding to the executable files respectively;

[0029] a first determining unit, configured to determine first verification data according to a file attribute of a target executable file when loading the target executable file;

[0030] a second loading unit, configured to read second verification data corresponding to the target executable file from the verification file;

[0031] The second determining unit is configured to compare the first verification data with the second verification data, and determine a security verification result of the target executable file according to the comparison result.

[0032] A third aspect of the present application discloses an electronic device, including:

[0033] a memory storing executable program code;

[0034] a processor coupled to the memory;

[0035] The processor calls the executable program code stored in the memory to execute all or part of the steps in any one of the security verification methods disclosed in the first aspect of the embodiment of the present application.

[0036] The fourth aspect of the embodiments of the present application discloses a computer-readable storage medium storing a computer program, wherein the computer program enables a computer to execute all or part of the steps in any one of the security verification methods disclosed in the first aspect of the embodiments of the present application.

[0037] The fifth aspect of the embodiments of the present application discloses a computer program product. When the computer program product is run on a computer, the computer is enabled to execute all or part of the steps of any one of the security verification methods in the first aspect of the embodiments of the present application.

[0038] Compared with the prior art, the embodiments of the present application have the following beneficial effects:

[0039] In an embodiment of the present application, the security verification method can be used for an electronic device equipped with an operating system based on the Linux kernel, such as the Android operating system. When the initial Init process is started, a verification file can be loaded through the initial Init process, and the verification file includes verification data corresponding to the executable files respectively; when the target executable file is loaded, the first verification data can be determined according to the file attributes of the target executable file; from the above-mentioned verification file, the second verification data corresponding to the target executable file can be read; the above-mentioned first verification data is compared with the second verification data, and the security verification result of the target executable file can be determined according to the comparison result. It can be seen that the implementation of the embodiment of the present application can perform the security verification task when the electronic device is turned on and the Linux kernel is loaded, that is, through the initial Init process, so that the security verification can be performed as early as possible when the electronic device is turned on, thereby improving the security of the electronic device. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0041] Figure 1 This is a flow chart of a security verification method disclosed in an embodiment of the present application;

[0042] Figure 2 This is a flowchart of a method for obtaining a verification file disclosed in an embodiment of the present application;

[0043] Figure 3 This is a flow chart of another security verification method disclosed in an embodiment of the present application;

[0044] Figure 4 This is a flow chart of another security verification method disclosed in an embodiment of the present application;

[0045] Figure 5 This is a modular schematic diagram of a safety verification device disclosed in an embodiment of the present application;

[0046] Figure 6 This is a modular schematic diagram of an electronic device disclosed in an embodiment of the present application. DETAILED DESCRIPTION

[0047] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0048] It is understood that the terms "first," "second," "third," and "fourth" in the specification and claims of this application are used to distinguish different objects rather than to describe a specific order. The terms "including" and "having," as well as any variations thereof, in the embodiments of this application are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units that are not explicitly listed or are inherent to such process, method, product, or apparatus.

[0049] The embodiments of the present application disclose a security verification method and device, an electronic device, and a storage medium, which can perform a security verification as early as possible when the electronic device is turned on, thereby improving the security of the electronic device.

[0050] The technical solution of this application will be described in detail below with reference to specific embodiments.

[0051] See also Figure 1 , Figure 1 This is a flow chart of a security verification method disclosed in the embodiment of this application. Figure 1 As shown, the security verification method may include the following steps:

[0052] 102. When the initial Init process is started, a verification file is loaded through the initial Init process. The verification file includes verification data corresponding to the executable files respectively.

[0053] In the embodiments of the present application, the security verification method can be used in electronic devices equipped with an operating system based on the Linux kernel, especially embedded electronic devices such as wearable devices, smart phones, tablet computers, etc., which are not specifically limited in the embodiments of the present application. Among them, the above-mentioned operating system based on the Linux kernel refers to an operating system developed on the basis of the Linux kernel, such as Android, Ubuntu Touch, etc., which are not specifically limited in the embodiments of the present application.

[0054] Specifically, for the above-mentioned electronic devices, after power-on, self-test, and initialization of the environment (such as embedded electronic devices can be initialized by loading the BootLoader program, performing tasks including hardware initialization, establishing memory space mapping, calling the kernel, etc.), the Linux kernel can be loaded into the memory of the electronic device and decompressed and initialized. On this basis, the Linux kernel can create and start the initial Init process, which is the first user process started in the operating system. By modifying the initial Init process, the security verification method of the embodiment of the present application can be implemented when the initial Init process is started, so that the security verification can be performed as early as possible when the electronic device is turned on, thereby improving the security of the electronic device.

[0055] In order to implement the verification of the executable file in the electronic device, when the above-mentioned initial Init process is started, the electronic device can load the verification file stored in the electronic device into the memory through the initial Init process. The verification file may include verification data corresponding to the executable files in the electronic device. Among them, the above-mentioned executable file may include an ELF (Executable and Linkable Format) file commonly used in Linux, such as a target bin file (i.e., a target binary file). For example, when there are N executable files in the electronic device, they can correspond one-to-one with N verification data respectively. In one embodiment, the N verification data can be stored in the same verification file, so that the verification file can be directly loaded through the above-mentioned initial Init process; in another embodiment, the N verification data can also be stored separately in N verification files, so that the target verification file corresponding to the target executable file to be verified can be selected from the N verification files through the above-mentioned initial Init process for loading.

[0056] 104. When loading the target executable file, determine first verification data according to the file attributes of the target executable file.

[0057] In an embodiment of the present application, by loading the target executable file into memory, the first verification data corresponding to the target executable file can be determined based on its own file attributes (such as file type, characters contained in the file, etc.) without temporarily running the target executable file. Exemplarily, the verification data of the executable file may include at least one or more of a checksum, a check code, and file length, and the specific algorithm used for each type of verification data is not specifically limited.

[0058] For example, when the executable file is a target binary file, the checksum of the target binary file can be obtained by summing the binary codes in the target binary file. In one embodiment, the above-mentioned summing of the binary code can adopt the method of cyclic summing of the inverse code, that is, cutting the above-mentioned binary code according to a certain number of bits (such as 16 bits, 32 bits, etc.) to obtain at least one code string, adding the inverse codes of each code string bit by bit, and cyclically carrying from the low bit to the high bit to obtain the checksum of the corresponding number of bits. Optionally, the checksum of the entire text of the target binary file can be calculated, or the checksum of only a part of the target binary file (such as the file header, the fragment of a specific address, etc.) can be calculated. It is also possible to calculate multiple checksums for multiple fragments of the target binary file to perform multiple checks at the same time, or randomly select a fragment for random check.

[0059] For another example, when the executable file is a target binary file, a check code, such as MD5 code (Message-Digest Algorithm), CRC code (Cyclic Redundancy Check), etc., can be calculated for the binary code in the target binary file, so that the calculated check code can be used as the verification data of the executable file.

[0060] For another example, by directly calculating the file length of the executable file (ie, the number of characters included in the executable file), the calculated file length can be used as verification data for the executable file.

[0061] In one embodiment, the electronic device can load the target executable file through the above-mentioned initial Init process, and then perform subsequent verification steps through the initial Init process to perform security verification when the electronic device is turned on, which is conducive to timely detection of executable files that may be tampered with and avoid security threats to the electronic device during subsequent operation.

[0062] In another embodiment, after the electronic device completes all boot work through the initial Init process, it can also respond to the opening operation of the target application, load the corresponding target executable file when starting the process corresponding to the target application, and perform subsequent verification steps at the same time. Only when the verification passes will it continue loading to ensure the security of each target executable file loaded, so as to avoid security threats to the electronic device during operation.

[0063] 106. Read second verification data corresponding to the target executable file from the verification file.

[0064] Specifically, the second verification data can be pre-stored in a verification file, and only when executing step 104 to load the target executable file, the second verification data corresponding to the target executable file is read from the verification file. It can be understood that the first verification data is the current data obtained by performing real-time calculations on the target executable file when the target executable file is loaded; and the second verification data is the original data calculated when the target executable file is generated. By comparing the first verification data with the second verification data, it can be determined whether the target executable file has been tampered with after generation, so that tampered executable files can be discovered and processed in a timely manner, reducing the security risks of using electronic devices.

[0065] 108. Compare the first verification data with the second verification data, and determine a security verification result of the target executable file according to the comparison result.

[0066] In an embodiment of the present application, by comparing the above-mentioned first verification data with the second verification data, when the first verification data and the second verification data match, it can be indicated that the above-mentioned target executable file has not been tampered with, and the security verification passes; when the first verification data and the second verification data do not match, it can be indicated that the above-mentioned target executable file may have been tampered with, and the security verification fails. For example, if the first verification data and the second verification data are checksums corresponding to the target executable file, respectively, when the first verification data and the second verification data are equal, it can be confirmed that the two match and the security verification passes; when the first verification data and the second verification data are not equal, it can be confirmed that the two do not match and the security verification fails.

[0067] As an optional embodiment, if there are multiple first verification data and second verification data to be compared, the multiple comparison results can be counted, and the security verification result of the target executable file can be determined based on the statistical results. For example, taking the first verification data and the second verification data as the checksum as an example, by selecting M fragments to be verified in the target executable file, the M checksums can be calculated for each of the M fragments to be verified to determine M first verification data; then, M second verification data corresponding to the M fragments to be verified can be read from the verification file; finally, the M first verification data are compared with the corresponding M second verification data to obtain M comparison results. When the number of matching results in the M comparison results is greater than a first matching threshold (such as 1 / 2 times M, 2 / 3 times M, etc.), it can be determined that the target executable file has passed the security verification; otherwise, it fails. Optionally, when the number of mismatching results in the M comparison results is less than a second matching threshold (such as 1, 3, etc.), it can be confirmed that the target executable file has passed the security verification; otherwise, it fails. The M fragments to be verified can be marked and distinguished in the target executable file by the fragment starting address (e.g., byte 0, byte 4, etc.) and the fragment length (e.g., 8 bytes, 16 bytes, etc.). By implementing the above method, multiple fragments of the target executable file can be verified, reducing possible errors in the verification process and improving the reliability of the security verification results.

[0068] As an optional implementation, if there are multiple types of first verification data and second verification data to be compared, the multiple comparison results can be sorted by weight according to the pre-set weights of different types of verification data; on this basis, the security verification result of the above-mentioned target executable file can be determined according to the sorting results. For example, if the first verification data and the second verification data respectively include a checksum, a check code and a file length, and the weight corresponding to the checksum is a, the weight corresponding to the check code is b, and the weight corresponding to the file length is c, then the comparison results corresponding to each type of verification data can be sorted according to the above weights. For example, when a>b>c, the comparison result corresponding to the checksum (such as the first verification data and the second verification data match) is ranked highest, so it can be determined based on the comparison result that the above-mentioned target executable file has passed the security verification. By implementing the above method, it is possible to assign corresponding weights to various verification data based on experience or historical verification records, so that when multiple verification data are obtained, the verification data with the highest reliability can be selected from them, and compared based on the verification data with the highest reliability to eliminate possible error interference and further improve the reliability of the security verification result of the target executable file.

[0069] It can be seen that the implementation of the security verification method described in the above embodiment can perform the security verification task when the electronic device is turned on and the Linux kernel is loaded, that is, through the initial Init process, so that the security verification can be performed as early as possible when the electronic device is turned on, thereby improving the security of the electronic device, and improving the reliability of the security verification results by statistics and screening of verification data.

[0070] like Figure 2 As shown, in one embodiment, before the above step 102, the following steps may be performed:

[0071] 1011. Compile the source code file to obtain an executable file.

[0072] In this embodiment, a source code file refers to a source code file for an electronic device that has not been processed by a compiler. By compiling the source code file, an executable file in a specified target format can be obtained. Furthermore, by compiling the source code file of the entire operating system, a system image for the electronic device can be obtained.

[0073] 1012. Calculate and obtain verification data corresponding to the executable file, and save the data into a verification file.

[0074] After compiling the executable file, verification data corresponding to the executable file can be calculated based on the file attributes of the executable file. For example, the verification data of the executable file can include at least one or more of a checksum, a checksum, and a file length, and its calculation algorithm is exactly the same as the method for determining the first verification data of the target executable file in step 104. On this basis, the verification data can be saved to a verification file, which can be saved at a specified address in the system image. The specified address can be written to the modified initial Init process, so that when the electronic device starts the initial Init process, the verification file can be loaded through the initial Init process.

[0075] 1013. Store the executable file and the verification file in an electronic device.

[0076] Specifically, the above steps 1011 and 1012 can be performed on a development device other than the electronic device. After the system image is obtained by compilation, the system image can be burned to the electronic device through a burning device to store the above executable file and the verification file in a designated location of the electronic device. Optionally, the above steps 1011 and 1012 can also be performed on the electronic device itself, so that the above executable file and the verification file can be directly stored in the original location, and when the compiled operating system is run through the virtual machine, the security verification method in the above embodiment can be verified.

[0077] By implementing the above method, the timeliness and accuracy of obtaining verification data can be ensured, providing a reference basis for subsequent security verification of executable files of electronic devices.

[0078] See also Figure 3 , Figure 3 This is a flow chart of another security verification method disclosed in the embodiment of this application, which can be used for the above-mentioned electronic equipment. Figure 3 As shown, the security verification method may include the following steps:

[0079] 302. When the initial Init process is started, a verification file is loaded through the initial Init process. The verification file includes verification data corresponding to the executable files respectively.

[0080] Among them, step 302 is similar to the above step 102 and will not be repeated here.

[0081] 304. When loading the target executable file, obtain a target verification identifier of the target executable file.

[0082] In an embodiment of the present application, each executable file can correspond to a different verification identifier, so that when the target executable file is loaded, the target verification identifier corresponding to the target executable file can be obtained based on the target executable file, and then the target verification identifier can be used to uniquely determine the above-mentioned target executable file.

[0083] Exemplarily, the verification identifier can be an identification number corresponding to the executable file. In one embodiment, the identification number can be assigned sequentially based on the executable file's storage location on the electronic device. For example, the electronic device reads data starting from the initial address of the memory and in ascending order. The executable files can be numbered "0001," "0002," and so on, based on the order in which the executable files were read. Thus, the above numbers can be used as the identification numbers of the executable files, thereby achieving unique identification numbers assigned based on the executable file's storage location. It is understood that when the executable file is moved to another storage location, its identification number can be retained, or a new identification number can be assigned based on its current storage location. In another embodiment, the identification numbers can also be assigned sequentially based on the creation time of the executable files. For example, after the executable file is compiled and created, its creation timestamp can be retained, and the executable files can be numbered "0001," "0002," and so on, based on the creation timestamp from the earliest to the latest, and this number can then be used as the identification number of the executable file. Optionally, the code corresponding to the above creation timestamp can also be directly used as the identification number of the executable file. For example, "September 15, 2020 21:19:20" can correspond to the code "20200915211920"; for executable files created at the same time (here within the same second), a sequential code can also be added after the code corresponding to its creation timestamp for distinction.

[0084] For example, the verification identifier may be a unique identification code calculated based on the executable file. It is understandable that the verification identifier does not require very strict uniqueness, but only needs to meet uniqueness in most cases. Therefore, the MD5 code, CRC code, etc. corresponding to the executable file may be directly used.

[0085] 306. Obtain an executable file verification list, where the executable file verification list includes a verification identifier of at least one executable file that needs to be verified.

[0086] Specifically, the executable file checklist can be pre-stored in another designated location of the electronic device. When the electronic device executes step 302 and loads the checklist from the designated location via the initial Init process, the executable file checklist can also be loaded from the further designated location via the initial Init process. Alternatively, the executable file checklist can be loaded from the further designated location only after the electronic device executes step 304 and obtains the target checklist identifier for the target executable file.

[0087] The executable file verification list can be created by adding verification identifiers for specific executable files that require verification to the list when the executable files are compiled. Alternatively, each compiled executable file can be verified to ensure comprehensive security verification. Alternatively, only a subset of essential executable files with a high risk of tampering can be verified, thereby improving security verification efficiency, reducing boot-up wait time, and enhancing the user experience of electronic devices.

[0088] 308. Search the executable file verification list for the target verification identifier. If the target verification identifier is found, determine that the target executable file needs to be verified, and determine first verification data according to the file attributes of the target executable file.

[0089] Specifically, the electronic device can search for the target verification identifier on the executable file verification list by looking up the table, thereby determining whether the target executable file needs to be verified based on the verification identifier. It is understood that the executable file verification list can include any container with update and query functions, such as a linked list, a heap, a tree, etc., and the embodiments of the present application are not specifically limited thereto.

[0090] 310. Read second verification data corresponding to the target executable file from the verification file.

[0091] 312. Compare the first verification data with the second verification data, and determine a security verification result of the target executable file according to the comparison result.

[0092] Among them, steps 310 to 312 are similar to the above steps 106 to 108 and will not be repeated here.

[0093] It can be seen that the implementation of the security verification method described in the above embodiment can determine whether a specific target executable file needs to be verified based on the verification identifier of the executable file, so that only some basic executable files with high tampering risks need to be verified, which is conducive to saving verification time and improving verification efficiency.

[0094] See also Figure 4 , Figure 4 This is a flow chart of another security verification method disclosed in the embodiment of this application, which can be used for the above-mentioned electronic equipment. Figure 4 As shown, the security verification method may include the following steps:

[0095] 402. When the initial Init process is started, a verification file is loaded through the initial Init process. The verification file includes verification data corresponding to the executable files respectively.

[0096] 404. When loading the target executable file, obtain a target verification identifier of the target executable file.

[0097] 406. Obtain an executable file verification list, where the executable file verification list includes a verification identifier of at least one executable file that needs to be verified.

[0098] 408. Search the executable file verification list for the target verification identifier. If the target verification identifier is found, determine that the target executable file needs to be verified, and determine first verification data according to the file attributes of the target executable file.

[0099] 410. Read second verification data corresponding to the target executable file from the verification file.

[0100] Among them, steps 402 to 410 are similar to the above steps 302 to 310 and are not repeated here.

[0101] 412. Compare the first verification data with the second verification data. If the comparison result is that the first verification data matches the second verification data, determine that the target executable file passes the security verification; if the comparison result is that the first verification data does not match the second verification data, determine that the target executable file fails the security verification.

[0102] Specifically, the matching of the first verification data and the second verification data may mean that the first verification data and the second verification data are equal, thereby confirming that the current target executable file is identical to the original target executable file obtained after compilation, i.e., has not been tampered with. Exemplarily, the first verification data and the second verification data may each be multiple or of multiple types, including but not limited to a checksum, a check code, a file length, etc.

[0103] 414. When it is determined that the target executable file does not pass the security check, the loading of the target executable file is terminated, and a feedback operation corresponding to the target executable file is triggered. The feedback operation at least includes recording a security check log and / or sending a security check result to a service device.

[0104] Exemplarily, when it is determined that the target executable file does not pass the security check, the target executable file can be deleted from the memory and the next loading can be refused. Optionally, the electronic device can immediately isolate the target executable file in an independent storage space to avoid damage to other files. On this basis, the electronic device can obtain the verification identifier of the target executable file and generate a security verification log based on the verification identifier, which is used to confirm the security verification result of the target executable file by querying the security verification log when the target executable file is loaded next time. Furthermore, the electronic device can also send the security verification result to the service device, such as sending the above-mentioned security verification log, so that the situation that the target executable file does not pass the security verification can be reported to obtain further operation instructions.

[0105] As an optional implementation, the electronic device can send a security verification log containing a verification identifier of the target executable file to a service device, and download the corresponding original target executable file from the service device based on the verification identifier to replace the target executable file on the electronic device that may have been tampered with. For example, if the target executable file is "a.bin" and its corresponding verification identifier is "0001", when the target executable file fails the security verification, the electronic device can generate a security verification log containing the verification identifier "0001" and send the security verification log to the service device when connecting to the network; then, the service device receives the security verification log, can obtain the verification identifier "0001" from it, and directly obtain the corresponding target executable file "a.bin" from the resource library of the service device, or extract the corresponding target executable file "a.bin" from the system image, package it and send it to the electronic device; after the electronic device receives the target executable file "a.bin" sent by the service device, it can directly use it to replace the original target executable file "a.bin" on the electronic device, thereby repairing the tampered executable file, improving the repair capability of the electronic device and further improving security.

[0106] Furthermore, after the electronic device sends the security verification log containing the verification identifier of the target executable file to the service device, the service device can also query the developer corresponding to the verification identifier and directly feedback the above-mentioned security verification log to the developer, so as to quickly notify the corresponding developer to review and process it, which is conducive to helping developers optimize the target executable file, reduce the risk of tampering, and further improve the security of the electronic device.

[0107] As an optional implementation, after determining that the target executable file fails the security check, the electronic device may further determine to invoke security software to determine the specific reason why the target executable file fails the security check. For example, the electronic device may invoke the security software to scan and analyze the target executable file and the storage area of ​​the target executable file. In one embodiment, the electronic device may also perform further security operations based on the analysis results, which may include isolating the target executable file, deleting the target executable file, entering safe mode, restarting, etc.

[0108] It can be seen that the implementation of the security verification method described in the above embodiment can determine whether to terminate the loading of the target executable file based on the security verification result of the electronic device and perform further feedback operations, so that the target executable file that may be tampered with can be processed in time, which is conducive to quickly resolving the security risks of the electronic device and improving the safety of using the electronic device.

[0109] See also Figure 5 , Figure 5 This is a modular schematic diagram of a safety verification device disclosed in an embodiment of the present application. Figure 5 As shown, the security verification device may include a first loading unit 501, a first determining unit 502, a second loading unit 503, and a second determining unit 504, wherein:

[0110] A first loading unit 501 is configured to load a verification file through the initial Init process when the initial Init process is started, the verification file including verification data corresponding to each executable file;

[0111] Exemplarily, the verification data of the executable file may include at least one or more of a checksum, a check code, a file length, etc., and the specific algorithm used for each verification data is not specifically limited.

[0112] A first determining unit 502 is configured to determine first verification data according to a file attribute of a target executable file when loading the target executable file;

[0113] The second loading unit 503 is configured to read second verification data corresponding to the target executable file from the verification file;

[0114] The second determining unit 504 is configured to compare the first verification data with the second verification data, and determine a security verification result of the target executable file according to the comparison result.

[0115] It can be seen that the security verification device described in the above embodiment can perform the security verification task when the electronic device is turned on and the Linux kernel is loaded, that is, through the initial Init process, so that the security verification can be performed as early as possible when the electronic device is turned on, thereby improving the security of the electronic device, and improving the reliability of the security verification results by statistics and screening of verification data.

[0116] As an optional implementation, the above-mentioned first determination unit 502 can be specifically used to load the target executable file through the above-mentioned initial Init process, and determine the first verification data according to the file attributes of the target executable file, so that a security check can be performed when the electronic device is turned on, which is conducive to timely detection of executable files that may be tampered with, and avoid security threats to the electronic device during subsequent operation.

[0117] As an optional implementation, the security verification device may further include a compilation unit, a calculation unit, and a storage unit (not shown), wherein:

[0118] A compiling unit, configured to compile the source code file to obtain an executable file before the first loading unit 501 loads the verification file through the initial Init process;

[0119] A calculation unit, configured to calculate and obtain verification data corresponding to the executable file and save the data into a verification file;

[0120] The storage unit is used to store the above executable file and verification file in the electronic device.

[0121] It is understandable that the above-mentioned compiling unit, computing unit and storage unit can be applied to a development device other than the electronic device, and can also be applied to the electronic device itself.

[0122] The security verification device described in the above embodiment can ensure the timeliness and accuracy of obtaining verification data, and provide data support and reference basis for subsequent security verification of executable files of electronic devices.

[0123] As an optional implementation, the first determining unit 502 may further include a first obtaining subunit and a judging subunit (not shown), wherein:

[0124] A first obtaining subunit is used to obtain a target verification identifier of the target executable file when loading the target executable file;

[0125] The judgment subunit is used to judge whether the target executable file needs to be verified according to the above-mentioned target verification identifier, and if verification is required, determine the first verification data according to the file attribute of the target executable file.

[0126] The security verification device described in the above embodiment can determine whether a specific target executable file needs to be verified based on the verification identifier of the executable file, so that only some basic executable files with high tampering risks need to be verified, which is conducive to saving verification time and improving verification efficiency.

[0127] As an optional implementation, the first determining unit 502 may further include a second obtaining subunit (not shown), configured to obtain an executable file verification list before the determining subunit determines whether the target executable file needs to be verified based on the target verification identifier, the executable file verification list including the verification identifier of at least one executable file that needs to be verified.

[0128] The judgment subunit may be specifically configured to search for the target verification identifier on the executable file verification list, and if the target verification identifier is found, determine the first verification data according to the file attributes of the target executable file.

[0129] By using the security verification device described in the above embodiment, it is possible to query the target verification identifier from a fixed executable file verification list. The steps are simple and easy to execute, which is conducive to improving the efficiency of security verification.

[0130] As an optional implementation manner, when the second determining unit 504 determines the security verification result of the target executable file based on the comparison result, if the comparison result indicates that the first verification data matches the second verification data, it can be determined that the target executable file passes the security verification; otherwise, it can be determined that the target executable file fails the security verification;

[0131] The above-mentioned security verification device may also include a feedback unit not shown in the figure, which is used to terminate the loading of the target executable file when the above-mentioned second determination unit 504 determines that the target executable file does not pass the security verification, and trigger a feedback operation corresponding to the target executable file. The feedback operation at least includes recording a security verification log and / or sending the above-mentioned security verification result to the service device.

[0132] The security verification device described in the above embodiment can determine whether to terminate the loading of the target executable file based on the security verification result of the electronic device and perform further feedback operations, so that the target executable file that may be tampered with can be processed in time, which is conducive to quickly resolving the security risks of the electronic device and improving the safety of using the electronic device.

[0133] See also Figure 6 , Figure 6 This is a modular schematic diagram of an electronic device disclosed in an embodiment of the present application. Figure 6As shown, the electronic device may include:

[0134] A memory 601 storing executable program code;

[0135] a processor 602 coupled to the memory 601;

[0136] The processor 602 calls the executable program code stored in the memory 601 to execute all or part of the steps in any one of the security verification methods in the above embodiments.

[0137] The memory 601 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 601 may also include a non-transitory computer-readable storage medium. The memory 601 may be used to store instructions, programs, codes, code sets, or instruction sets, and includes a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for at least one function, instructions for implementing each of the above-mentioned method embodiments, etc.; the data storage area may store data created based on the use of the server, etc.

[0138] The processor 602 may include one or more processing cores and utilize various interfaces and circuits to connect various components within the server. It executes instructions, programs, code sets, or instruction sets stored in the memory 601, as well as accesses data stored in the memory 601, to perform various server functions and process data. Optionally, the processor 602 may be implemented using at least one of the following hardware forms: a digital signal processing (DSP), a field-programmable gate array (FPGA), or a programmable logic array (PLA). The processor 602 may integrate one or a combination of a central processing unit (CPU) and a modem. The CPU primarily processes the operating system and application programs, while the modem handles wireless communications. It is understood that the modem may not be integrated into the processor 602 and may be implemented as a separate chip.

[0139] In addition, an embodiment of the present application further discloses a computer-readable storage medium that stores a computer program for electronic data exchange, wherein the computer program enables a computer to execute all or part of the steps in any one of the security verification methods in the above embodiments.

[0140] In addition, an embodiment of the present application further discloses a computer program product, which, when running on a computer, enables the computer to execute all or part of the steps in any one of the security verification methods in the above embodiments.

[0141] Those skilled in the art will appreciate that all or part of the steps in the various methods of the above embodiments can be completed by instructing related hardware through a program. The program can be stored in a computer-readable storage medium, and the storage medium includes a read-only memory (ROM), a random access memory (RAM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), a one-time programmable read-only memory (OTPROM), an electronically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, magnetic disk storage, magnetic tape storage, or any other computer-readable medium capable of carrying or storing data.

[0142] The above is a detailed introduction to a security verification method and device, electronic device, and storage medium disclosed in the embodiments of the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for those skilled in the art, based on the ideas of the present application, there may be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A security verification method, characterized in that: Applicable to electronic devices equipped with Linux kernel-based operating systems, including: When the initial Init process is started, a verification file is loaded through the initial Init process, the verification file includes verification data corresponding to the executable files respectively, and the initial Init process is the first user process started in the operating system; When the target executable file is loaded through the initial Init process, a target verification identifier of the target executable file is obtained; an executable file verification list is obtained, the executable file verification list includes a verification identifier of at least one executable file that needs to be verified; the target verification identifier is searched on the executable file verification list, if the target verification identifier is found, it is determined that the target executable file needs to be verified, and first verification data is determined according to the file attribute of the target executable file; Reading second verification data corresponding to the target executable file from the verification file; The first verification data is compared with the second verification data, and a security verification result of the target executable file is determined according to the comparison result.

2. The method according to claim 1, characterized in that When the initial Init process is started, before the verification file is loaded by the initial Init process, the method further includes: Compile the source code file to obtain an executable file; Calculate and obtain verification data corresponding to the executable file, and save it in a verification file; The executable file and the verification file are stored in the electronic device.

3. The method according to claim 1 or 2, characterized in that: Determining the security verification result of the target executable file according to the comparison result includes: If the comparison result is that the first verification data matches the second verification data, determining that the target executable file passes the security verification; If the comparison result is that the first verification data does not match the second verification data, it is determined that the target executable file does not pass the security verification.

4. The method according to claim 3, characterized in that The method further comprises: When it is determined that the target executable file does not pass the security check, the loading of the target executable file is terminated, and a feedback operation corresponding to the target executable file is triggered, and the feedback operation at least includes recording a security check log and / or sending the security check result to a service device.

5. A safety verification device, characterized in that: Applicable to electronic devices equipped with Linux kernel-based operating systems, including: A first loading unit, configured to load a verification file through an initial Init process when the initial Init process is started, wherein the verification file includes verification data corresponding to the executable files respectively, and the initial Init process is the first user process started in the operating system; A first determination unit, configured to load a target executable file through the initial Init process, and determine first verification data according to a file attribute of the target executable file; A second loading unit, configured to read second verification data corresponding to the target executable file from the verification file; a second determination unit, configured to compare the first verification data with the second verification data, and determine a security verification result of the target executable file according to the comparison result; The first determination unit includes a first acquisition subunit, a second acquisition subunit and a judgment subunit; The first acquisition subunit is used to acquire a target verification identifier of the target executable file when the target executable file is loaded through the initial Init process; The second acquisition subunit is used to acquire an executable file verification list, where the executable file verification list includes a verification identifier of at least one executable file that needs to be verified; The judgment subunit is used to search for the target verification identifier on the executable file verification list, and if the target verification identifier is found, it is determined that the target executable file needs to be verified, and the first verification data is determined according to the file attribute of the target executable file.

6. An electronic device, characterized in that: include: A memory storing executable program code; a processor coupled to the memory; The processor calls the executable program code stored in the memory to execute the method according to any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program enables a computer to execute the method according to any one of claims 1 to 4.

Images