Application program loading method, electronic equipment and storage medium

Abstract

The invention discloses an application program loading method, electronic equipment and a storage medium, and the method comprises the steps: carrying out the signature verification of a signature database file corresponding to an application program through a preset digital signature, and determining the successfully verified application program as a target application program, the signature database file is determined by utilizing a first digest value corresponding to a loading class contained in the application program, and the first digest value is generated when the application program is packaged; a second abstract value corresponding to a to-be-loaded target loading class of the target application program is obtained, and the second abstract value is generated when the target loading class needs to be loaded; in response to the fact that the second digest value is consistent with the corresponding first digest value, loading the target loading class, and then completing loading of the target application program; according to the method and the device, malicious loading classes are effectively identified and blocked, the situations of false report and missing report are reduced, the detection accuracy is improved, and the cost is reduced.

Description

Technical Field

[0001] The present application relates to the technical field of software detection, and in particular to an application loading method, electronic device, and storage medium. Background Art

[0002] With the explosive growth of computer applications and the continuous increase in the number of applications, Java, with its powerful ecosystem, cross-platform capabilities, security, stability, and reliability, has become the mainstream development language for enterprise applications and has gained extremely widespread adoption. Consequently, malicious attacks targeting Java applications have also emerged one after another, with the typical malware attack method being to execute malicious code through Java application vulnerabilities.

[0003] Current technologies typically detect and defend against malicious program attacks by extracting features of the Java class to be loaded and comparing them with known malicious samples. If the comparison is successful, an alert or blocking is issued. Alternatively, machine learning is used to train a detection model using malicious and normal samples. The model is then used to infer the Java class to be loaded and identify the malicious Java class. However, these methods are only suitable for detecting known malicious samples. For unknown malicious samples, the features vary greatly, making detection complex and difficult. These methods are prone to false positives and false negatives, impacting detection effectiveness and increasing costs. Summary of the Invention

[0004] The technical solution to the technical problem mainly solved by the present application is to provide an application loading method, an electronic device and a storage medium, verify the application signature through a signature database file, determine that the target application is successfully verified, and determine a trusted target application, wherein the signature database file contains a first digest value corresponding to the loading class of the application, and the first digest value is generated when the application is encapsulated; then obtain a second digest value corresponding to the target loading class to be loaded by the target application, and the second digest value is generated when the target loading class needs to be loaded; then compare the first digest value and the second digest value, and when the second digest value is consistent with the corresponding first digest value, load the target loading class, determine the trusted target loading class, effectively identify and block malicious loading classes, reduce the occurrence of false alarms and missed alarms, and improve detection accuracy.

[0005] In order to solve the above technical problems, a technical solution adopted in this application is: to provide an application loading method, including: using a preset digital signature to perform signature verification on the signature database file corresponding to the application, and determining the successfully verified application as the target application, wherein the signature database file is determined by using the first digest value corresponding to the loading class contained in the application, and the first digest value is generated when the application is encapsulated; obtaining the second digest value corresponding to the target loading class to be loaded by the target application, wherein the second digest value is generated when the target loading class needs to be loaded; in response to the second digest value being consistent with the corresponding first digest value, loading the target loading class, thereby completing the loading of the target application.

[0006] In some embodiments, the use of a preset digital signature to perform signature verification on the signature database file corresponding to the application, and determining the successfully verified application as the target application, includes: obtaining the first summary values ​​of all loaded classes that the application depends on, and obtaining the name information of each loaded class; using the name information and the first summary value to determine the signature database file corresponding to the application; signing the signature database file to obtain the preset digital signature; in response to the application being ready to load, further using the preset digital signature to perform signature verification on the signature database file, and determining the target application as the application corresponding to the successfully verified signature database file.

[0007] In some embodiments, the use of the name information and the first summary value to determine the signature database file corresponding to the application includes: using the name information and the first summary value of each loaded class as a key-value pair, and then determining the signature database file corresponding to all loaded classes of the application.

[0008] In some embodiments, signing the signature database file to obtain the preset digital signature includes: separately digitally signing the signature database file to obtain the preset digital signature; in response to the application being ready to load, using the preset digital signature to verify the signature of the signature database file, and determining the application corresponding to the successfully verified signature database file as the target application, including: before the application is started, using the preset digital signature to verify the signature of the signature database file; and using the application that has passed the signature visa as the target application; and using the application that has not passed the signature verification as an untrusted application and refusing to start it.

[0009] In some embodiments, the obtaining of the second digest value corresponding to the target loading class to be loaded by the target application, wherein the second digest value is generated when the target loading class needs to be loaded, includes: obtaining the target loading class to be loaded corresponding to the target application, wherein a loading class to be loaded having a first digest value is used as the target loading class; when loading the target loading class, calculating the second digest value corresponding to each target loading class to be loaded using a preset digest value calculation method.

[0010] In some embodiments, before obtaining the second digest value, it also includes: using the name information to obtain the first digest value corresponding to the loading class; in response to the non-existence of the first digest value, the loading class without the first digest value is treated as an untrusted loading class and the loading is refused; in response to the existence of the first digest value, the loading class with the first digest value is treated as the target loading class and the loading is performed.

[0011] In some embodiments, in response to the second digest value being consistent with the corresponding first digest value, the target loading class is loaded, thereby completing the loading of the target application, including: using the first digest value and the second digest value to compare and obtain a comparison result; in response to the first digest value being inconsistent with the second digest value, the loading class corresponding to the second digest value is an untrusted loading class, and loading is refused; in response to the first digest value being consistent with the second digest value, the loading class corresponding to the second digest value is the target loading class.

[0012] In some embodiments, it also includes: obtaining the loading risk corresponding to each loading type; in response to the loading risk of the loading class being less than a preset risk threshold, determining the loading type of the loading class to be a first loading class; and using a preset loader to perform loading on the first loading class.

[0013] To solve the above technical problems, another technical solution adopted in this application is: to provide an electronic device, the electronic device comprising a memory and a processor coupled to the memory, the memory storing at least one computer program, and the at least one computer program, when loaded and executed by the processor, is used to implement the application loading method as described above.

[0014] To solve the above technical problems, another technical solution adopted in this application is: providing a computer-readable storage medium, wherein the computer-readable storage medium has at least one program, and when the at least one program is loaded and executed by the processor, it is used to implement the application loading method as described above.

[0015] Different from the current technology, the application loading method provided by the present application includes: using a preset digital signature to perform signature verification on the signature database file corresponding to the application, and determining the successfully verified application as the target application, wherein the signature database file is determined by using the first digest value corresponding to the loading class contained in the application, and the first digest value is generated when the application is encapsulated; obtaining the second digest value corresponding to the target loading class to be loaded by the target application, wherein the second digest value is generated when the target loading class needs to be loaded; in response to the second digest value being consistent with the corresponding first digest value, loading the target loading class, thereby completing the loading of the target application; that is, in the present application, the signature database file is used to verify the signature of the target application. Application signature verification determines that the target application has been successfully verified, and determines the trusted target application, wherein the signature database file contains the first digest value corresponding to the loading class of the application, and the first digest value is generated when the application is encapsulated; then obtains the second digest value corresponding to the target loading class to be loaded by the target application, and the second digest value is generated when the target loading class needs to be loaded; then compares the first digest value and the second digest value, and when the second digest value is consistent with the corresponding first digest value, loads the target loading class, determines the trusted target loading class, effectively identifies and blocks malicious loading classes, reduces the occurrence of false alarms and missed alarms, improves detection accuracy, and reduces costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without inventive efforts. Among them:

[0017] Figure 1 This is a flowchart of an embodiment of the application loading method in this application;

[0018] Figure 2 This is an overall flow chart of an embodiment of the application loading method in this application;

[0019] Figure 3 This is a structural diagram of an embodiment of an application loading system in this application;

[0020] Figure 4 This is a schematic structural diagram of an embodiment of an electronic device in this application;

[0021] Figure 5 It is a structural diagram of an embodiment of a computer-readable storage medium in this application. DETAILED DESCRIPTION

[0022] The present invention will be described in further detail below with reference to the accompanying drawings and examples. It is particularly noted that the following examples are intended only to illustrate the present invention and are not intended to limit the scope of the present invention. Similarly, the following examples are only some embodiments of the present invention and are not intended to be all embodiments. All other embodiments obtained by those of ordinary skill in the art without creative effort are intended to fall within the scope of protection of the present invention.

[0023] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present invention. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute a separate or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0024] Traditional application loading methods, to prevent the loading of malicious classes, typically extract features of the Java class to be loaded (the Java class being loaded), compare these features with known malicious samples, and issue an alert and block if the comparison is successful. Alternatively, machine learning is used to train a detection model using malicious and normal samples. The model is then used to infer the Java class to be loaded and identify malicious Java classes. However, these methods are only suitable for detecting known malicious samples. For unknown malicious samples, the features vary greatly, making detection complex and difficult, and prone to false positives and false negatives, which affects detection effectiveness and increases costs.

[0025] Therefore, an application loading method is provided, which verifies the application signature through a signature database file, determines that the target application is successfully verified, and determines a trusted target application, wherein the signature database file contains a first digest value corresponding to the loading class of the application, and the first digest value is generated when the application is encapsulated; then obtains a second digest value corresponding to the target loading class to be loaded by the target application, and the second digest value is generated when the target loading class needs to be loaded; then compares the first digest value and the second digest value, and when the second digest value is consistent with the corresponding first digest value, loads the target loading class, determines a trusted target loading class, effectively identifies and blocks malicious loading classes, reduces the occurrence of false positives and missed positives, improves detection accuracy, and reduces costs.

[0026] See also Figure 1 , Figure 1 This is a flow chart of an embodiment of the application loading method in this application; it should be noted that if there is a substantial result, the method of this application is not based on Figure 1 The process sequence shown is limited.

[0027] like Figure 1As shown, the application loading method of the present application may include the following steps.

[0028] S10. Use a preset digital signature to verify the signature of the signature database file corresponding to the application, and determine the successfully verified application as the target application, wherein the signature database file is determined by using the first digest value corresponding to the loading class contained in the application, and the first digest value is generated when the application is encapsulated.

[0029] Among them, the preset digital signature refers to a string of numbers that can only be generated by the sender of the information and cannot be forged, which is used to effectively prove the authenticity of the information sent by the sender; the application refers to a computer program used to complete one or more specific tasks, running on the client for interaction; the signature database file refers to a file for digital signatures stored in the digital signature database, including at least a first digest value, which is used to verify the signature of the application; the target application refers to an application that has been successfully verified; the loading class refers to a class used to encapsulate data (attributes or fields) and operations performed on these data, such as a Java class; the first digest value refers to the digest value generated by the loading class when the application is encapsulated, which is used to represent the loading class when the application is encapsulated.

[0030] Specifically, the application to be verified is obtained, and the signature database file corresponding to each application is obtained, as well as the first digest value generated by the loading class contained in the application when it is encapsulated; then the signature database file corresponding to each application is signed and verified using the preset digital signature. A successful verification means that the verified application is complete and the source is trustworthy. Therefore, the application that has successfully been verified can be used as the target application; if the verification fails, it means that the verified application is incomplete or has been modified, and therefore it is determined that the source is untrustworthy, that is, the application that failed the verification is determined to be an untrustworthy application, and then it is refused to be started.

[0031] In some embodiments, the first digest value can be calculated using a preset digest calculation method, for example, the first digest value can be calculated using the SHA256 (Secure Hash Algorithm 256-bit) digest algorithm, the SM3 (senior middle 3) security digest algorithm, etc.; specifically, the digest value corresponding to the bytecode of the loaded class is calculated.

[0032] It is understandable that the preset digital signature can be obtained in advance. For example, the digital signature verification tool first determines the preset digital signature, and then directly uses the digital signature verification tool to verify the signature of the signature database file corresponding to the application.

[0033] S20: Obtain a second digest value corresponding to the target loading class to be loaded by the target application, wherein the second digest value is generated when the target loading class needs to be loaded.

[0034] The target loading class refers to a loading class that has passed verification, that is, a trusted loading class; and the second digest value refers to a digest value generated when the target loading class needs to be loaded.

[0035] Specifically, after determining the target application, the loading class included in each target application is obtained, and the loading class with the first digest value is used as the target loading class; and the second digest value generated by the target loading class to be loaded during the current loading is obtained.

[0036] In some embodiments, the second digest value can be calculated using a preset digest calculation method, for example, the second digest value can be calculated using the SHA256 (Secure Hash Algorithm 256-bit) digest algorithm, the SM3 (senior middle 3) security digest algorithm, etc.

[0037] S30 : In response to the second digest value being consistent with the corresponding first digest value, loading the target loading class, thereby completing the loading of the target application.

[0038] Among them, if the second digest value is consistent with the corresponding first digest value, it means that the second digest value and the first digest value correspond to the same target loading class and have not changed, which means that the current target loading class has not been modified and is trustworthy. Therefore, the current target loading class can be loaded, and the loading of the target application can be completed.

[0039] Specifically, after obtaining the second digest value of the target loading class, verify whether the target loading class with the second digest value has the first digest value. If the first digest value exists, compare the second digest value with the first digest value. If the comparison results are consistent, load the target loading class with the consistent second digest value and the first digest value, and then complete the loading of the current target application.

[0040] In this embodiment, the application signature is verified through a signature database file, and the target application that has been successfully verified is determined to be a trusted target application, wherein the signature database file contains a first digest value corresponding to the loading class of the application, and the first digest value is generated when the application is encapsulated; then the second digest value corresponding to the target loading class to be loaded by the target application is obtained, and the second digest value is generated when the target loading class needs to be loaded; then the first digest value and the second digest value are compared, and when the second digest value is consistent with the corresponding first digest value, the target loading class is loaded to determine the trusted target loading class, effectively identifying and blocking malicious loading classes, reducing the occurrence of false alarms and missed alarms, improving detection accuracy, and reducing costs.

[0041] In some embodiments, S10 performs signature verification on a signature database file corresponding to an application using a preset digital signature, and determines the application that has been successfully verified as a target application, which may include the following operations.

[0042] First, the first summary values ​​of all loaded classes that the application depends on are obtained, and the name information of each loaded class is obtained.

[0043] Each application may depend on one or more loaded classes; the name information refers to the name of the loaded class, such as a fully qualified name (Fully Qualified Name).

[0044] Specifically, all applications are determined, and the loading classes that each application depends on are determined; and before the application is started, the first summary values ​​of all the loading classes that each application depends on are calculated through a preset summary calculation method, and the name information corresponding to each loading class is obtained, that is, the fully qualified name of each loading class; if an application depends on three loading classes, then the application has three corresponding first summary values.

[0045] In some embodiments, a digest value calculation module may be constructed, for example, a Java class bytecode file digest value calculation module for calculating the digest values ​​of all Java class bytecode files that the Java application depends on, that is, calculating the first digest value.

[0046] Specifically, the bytecode file of the Java class is placed in the directory tree constructed by the package name of the Java class. Taking the JsonEncoding class in the jackson-core-2.13.5.jar component as an example, its package name is com.fasterxml.jackson.core, and its bytecode file JsonEncoding.class is stored in the com / fasterxml / jackson / core / directory; when packaging the Java application, traverse the relevant directories. If it is a jar package, it needs to be decompressed first and the digest value of each Java class bytecode file is calculated. The digest algorithm can use a secure digest algorithm such as SHA256 and SM3.

[0047] In some embodiments, the loaded classes that each application depends on may also include third-party Java classes, such as Java classes in a third-party jar package.

[0048] Next, the signature database file corresponding to the application is determined using the name information and the first digest value.

[0049] The signature database file refers to a file stored in a signature database, and the signature database is a database established to store related files.

[0050] Specifically, a signature database is first created, and then the first summary value obtained when the application is encapsulated and the name information corresponding to each loaded class are stored in the signature database, and the name information of one or more loaded classes corresponding to each application and the corresponding first summary value are stored in the same storage table as the signature database file of the current application; if there are multiple loaded classes that the current application depends on, there are corresponding multiple columns of information in the corresponding signature database file; if there are multiple applications, there are multiple signature database files in the signature database, that is, each application corresponds to a signature database file.

[0051] Furthermore, the name information and the first digest value of each loaded class are used as a key-value pair to determine the signature database files corresponding to all loaded classes of the application.

[0052] Among them, a key-value pair refers to a primary key and the value corresponding to the primary key. The primary key represents the index, and the value corresponding to the primary key represents the data stored and read.

[0053] Specifically, the name information of the loaded class is used as the primary key, and the first summary value is used as the value corresponding to the primary key to form a key-value pair; because each application can have one or more loaded classes, there can be one or more key-value pairs, that is, each key-value pair represents the name information and the first summary value of a loaded class, which are constructed into a storage table, that is, there are multiple columns in the storage table, each column corresponds to a key-value pair, and there are multiple rows in the storage table, each row includes the name information and the first summary value of a loaded class; and then the storage table constructed by multiple key-value pairs is used as the signature database file corresponding to all loaded classes of the current application.

[0054] Then, the signature database file is signed to obtain a preset digital signature.

[0055] Among them, the signature refers to a digital signature, which serves as the identification information and anti-counterfeiting label of the signature database file and is used to ensure the authenticity, integrity and correctness of the signature database file.

[0056] Specifically, after determining the signature database file of each application, the signature database file corresponding to each application is signed separately to obtain the corresponding preset digital signature to clarify the marking information of each signature database file, and use the preset digital signature as an anti-counterfeiting label.

[0057] For example, a signature database is created for a Java application. The digest value calculated when the Java application is packaged or encapsulated is used as the first digest value of the Java class bytecode and stored in the signature database. The signature database can use a high-performance file-based database such as SQLite. The storage table in the signature database is the signature database file. The signature database file uses the fully qualified name of the Java class as the primary key. The first digest value is stored as a hexadecimal string or directly sampled in binary format. This can further reduce the size of the signature database file and improve the performance of subsequent digest value comparisons. To prevent the signature database file from being tampered with, after saving the first digest values ​​of all Java class bytecode files, the entire signature database file is separately digitally signed.

[0058] Further, performing a separate digital signature on the signature database file to obtain a preset digital signature;

[0059] A detached digital signature is one in which the signature element and the signed data are separated, with no inclusion or inclusion relationship between the two. This signature method ensures the independence and integrity of the signature and is suitable for scenarios requiring high security. It also meets the need for separate storage and transmission of all sent and received messages. A detached signature allows for separate processing of the signature and message, ensuring their independence and facilitating management and verification.

[0060] Then, in response to the application being ready to load, the signature database file is verified using a preset digital signature, and the application corresponding to the successfully verified signature database file is determined as a target application.

[0061] In response to the application being ready to load, that is, before the application is loaded, signature verification is performed to verify trusted applications and untrusted applications, and the target application is a trusted application.

[0062] Specifically, before loading the application, the preset digital signature is used to verify the signature of each application's signature database file, that is, the preset digital signature and the signature carried by the signature database file itself are compared. A successful comparison means that the verification is successful, and the application corresponding to the successfully verified signature database file is determined as the target application, and the target application is used as the trusted application for subsequent loading.

[0063] Furthermore, before the application is started, the signature database file is verified using a preset digital signature. Applications that pass the signature verification are used as target applications; applications that fail the signature verification are treated as untrusted applications and are refused to start.

[0064] That is, the preset digital signature is compared with the signature carried by the signature database file itself. A successful comparison means successful verification, and the application corresponding to the successfully verified signature database file is determined as the target application, and the target application is subsequently loaded as a trusted application; the application corresponding to the signature database file that fails verification is determined as an untrusted application and is refused to be loaded.

[0065] In this embodiment, all applications are signature verified by pre-setting digital signatures to screen out trusted applications as target applications, reducing the loading of malicious applications, effectively identifying and blocking malicious programs, reducing the occurrence of false positives and missed negatives, and improving detection accuracy.

[0066] In some embodiments, S20 obtains a second digest value corresponding to a target loading class to be loaded by the target application, wherein the second digest value is generated when the target loading class needs to be loaded, and may include the following operations.

[0067] First, a target loading class to be loaded corresponding to the target application is obtained, wherein a loading class to be loaded having a first digest value is used as the target loading class.

[0068] There may be one or more target applications, that is, multiple applications have passed the signature verification and have been successfully verified; the target loading class refers to the loading class that the target application depends on and has the first digest value.

[0069] Specifically, after verifying the application and determining the target application, the loading class that each target application depends on is obtained, and the first digest value of the obtained loading class is verified. If the first digest value exists, it is determined to be the target loading class; if the first digest value does not exist, it is determined to be an untrusted loading class.

[0070] Then, before loading the target loading class, a preset digest value calculation method is used to calculate the second digest value corresponding to each target loading class to be loaded.

[0071] The preset digest value calculation method may be a preset digest algorithm, such as the SHA256 (Secure Hash Algorithm 256-bit) digest algorithm, the SM3 (senior middle 3) security digest algorithm, and the like.

[0072] Specifically, after determining the target loading class of the target application and before loading the target loading class, a preset digest algorithm is used to calculate the corresponding second digest value for each target loading class to be loaded. The specific calculation process is not limited here.

[0073] It can be understood that the calculation of the first digest value also adopts the preset digest value calculation method. Therefore, if the loaded class has not been modified or the content has not been added, the first digest value and the second digest value corresponding to the same loaded class are consistent, which ensures that the loaded class has not been modified or malicious content has been added, thereby ensuring that the loaded class is trustworthy.

[0074] In some embodiments, before obtaining the second digest value, the following operations may also be included:

[0075] The name information is used to obtain the first digest value corresponding to the loaded class.

[0076] Among them, because the signature database file includes at least one application, and each application includes at least one loading class, each loading class has corresponding name information and a first summary value as a key-value pair. Therefore, the name information of the loading class can be used to obtain the first summary value corresponding to the loading class.

[0077] Specifically, in the signature database file, the name information of the loaded class is used as the primary key, and before obtaining the second summary value, the first summary value of the loaded class on which the target application depends is verified, that is, the name information of the current loaded class is used to obtain the first summary value that matches the name information of the current loaded class in the signature database file of the signature database.

[0078] In response to the first digest value not existing, the loading class without the first digest value is regarded as an untrusted loading class and is refused to be loaded.

[0079] Among them, if there is no first summary value matching the name information of the current loaded class in the signature database file of the signature database, it indicates that the current loaded class is not the loaded class recorded in the signature database file, and there may be risks. Therefore, it is determined to be an untrusted loaded class and the loading of this type of loaded class is refused.

[0080] In response to the existence of the first digest value, the loading class having the first digest value is used as the target loading class and loading is performed.

[0081] Among them, if there is a first digest value that matches the name information of the current loading class in the signature database file of the signature database, it indicates that the current loading class is the loading class recorded in the signature database file and has not been modified or added. It is the original loading class. Therefore, the loading class with the first digest value is used as the target loading class, that is, as the trusted loading class, and then the corresponding loading is executed.

[0082] In this embodiment, by verifying the first digest value of the target application after signature verification, it is determined whether the loading class on which the target application depends is a trusted loading class, which can effectively ensure that the loading class has not been modified or added with malicious content, thereby ensuring that the loading class is trustworthy; by screening out the trusted loading class as the target loading class, the loading of malicious loading classes is reduced, the malicious loading classes are effectively identified and blocked, the occurrence of false alarms and missed alarms is reduced, and the detection accuracy is improved.

[0083] In some embodiments, S30 loads the target loading class in response to the second digest value being consistent with the corresponding first digest value, thereby completing the loading of the target application, which may include the following operations.

[0084] First, the first digest value and the second digest value are compared to obtain a comparison result.

[0085] The first digest value and the second digest value are for the same loaded class.

[0086] Specifically, after verifying the loading class of the target application and obtaining the target loading class, and obtaining the second digest value of the target loading class, because the target loading class will also have a corresponding first digest value when the aforementioned application is encapsulated, that is, the target loading class has a corresponding second digest value and first digest value, therefore, the comparison result between the second digest value and the first digest value can be used to determine the credibility of the loading class.

[0087] Then, in response to the first digest value being inconsistent with the second digest value, the target loading class corresponding to the second digest value is deemed an untrusted loading class and is refused to be loaded.

[0088] Among them, the inconsistency between the first digest value and the second digest value indicates that the content of the corresponding loading class has changed, such as added content, rather than the loading class when the application is encapsulated. It is very likely that malicious content has been added, and the loading risk has increased. Therefore, in response to the inconsistency between the first digest value and the second digest value, the target loading class corresponding to the second digest value is regarded as an untrusted loading class and is refused to be loaded.

[0089] Then, or in response to the first digest value being consistent with the second digest value, the target loading class corresponding to the second digest value is determined to be a trusted loading class and is loaded.

[0090] Among them, the first digest value is consistent with the second digest value, indicating that the content of the corresponding loading class has not changed, and it is still the loading class when the application is encapsulated, and the corresponding loading risk has not increased. Therefore, in response to the consistency between the first digest value and the second digest value, the loading class corresponding to the second digest value is used as a trusted loading class and loaded.

[0091] In some embodiments, if it is a third-party loaded class, it is determined whether the current loaded class is the original third-party loaded class, ie, a third-party loaded class with no content modification, addition or reduction.

[0092] In this embodiment, in the first stage of the Java class life cycle, that is, the loading stage, by comparing the first digest value corresponding to the loading class to be loaded with the second digest value, it can be determined whether the current target loading class is the loading class when the application is encapsulated. It does not rely on the detection feature library or detection model, and effectively and in real time identifies and blocks malicious loading classes, reduces the occurrence of false alarms and missed alarms, improves detection accuracy, and reduces costs.

[0093] To more clearly illustrate the application loading process, the following describes the overall trusted loading flow chart.

[0094] See also Figure 2 , Figure 2 This is an overall flow chart of an embodiment of the application loading method in this application.

[0095] like Figure 2 As shown, the first step: when the application is encapsulated, the first digest value of the loaded class that the application depends on is calculated, that is, when the Java application is packaged, the digest value of the bytecode of all Java classes that the Java application depends on is calculated; the second step: using the first digest value and the name information of the loaded class to build a signature database file and store it in the signature database, that is, for each Java class, the fully qualified name of the Java class is used as the primary key, and the first digest value of the corresponding Java class is used as the value of the key-value pair, which are written together into the signature database file of the application and stored in the database file; the third step: signing the signature database file corresponding to the application, determining the preset digital signature to ensure the integrity and source credibility of the signature database file; the fourth step: before the application is started, the signature database file is signed using the preset digital signature, that is, before the Java application is started, the signature database file of the Java application is signed and verified using a digital signature verification tool. If the signature verification passes, it means that the application is a trusted application and the next step is performed. If the signature verification fails, it means that the application is an untrusted application and is rejected; the fifth step: starting the application and intercepting the loading process of the loaded class in the process, that is, using Java Agent technology starts the Java application and intercepts the loading process of the Java class in the JavaAgent; Step 6: Before formal loading, use the name information of the loading class to be loaded to obtain the corresponding first digest value in the signature database file, and then judge the first digest value. If the first digest value does not exist, the current loading class is judged to be an untrusted loading class and the loading is rejected. If the first digest value exists, proceed to the next step; Step 7: Calculate the second digest value corresponding to the target loading class to be loaded by the target application, and compare the second digest value with the corresponding first digest value. If the second digest value is consistent with the corresponding first digest value, the target loading class corresponding to the second digest value is a trusted loading class, and subsequent loading is performed. If the second digest value is inconsistent with the corresponding first digest value, the target loading class corresponding to the second digest value is an untrusted loading class, an alarm is issued, and the loading is rejected.

[0096] In some embodiments, the following operations may also be included:

[0097] First, obtain the loading risk corresponding to each loading type.

[0098] Among them, each loading class has a corresponding loading type. Some loading types have higher loading risks, such as the loading types corresponding to loading classes for content modification or addition; while some loading types have lower loading risks, such as loading core classes and extension classes, such as the loading classes corresponding to Java core class libraries and extension class libraries.

[0099] Specifically, for all loaded classes of the application, determine the loading type, and then determine the loading risk corresponding to each loading type based on the loading type; for example, the loading risk corresponding to the loading type of the loading class that modifies or adds content is high risk, the loading risk corresponding to loading core classes and extension classes is low risk, and the loading risk of other loading classes is medium risk.

[0100] Next, in response to the loading risk of the loaded class being less than a preset risk threshold, the loading type of the loaded class is determined to be a first loading type.

[0101] The preset risk threshold can be set according to needs, and the first loading type is set to a loading type of a loading class corresponding to low risk.

[0102] Specifically, taking medium risk as the preset risk threshold as an example, when the loading risk corresponding to the loading class is less than the medium risk, the loading risk corresponding to the loading class is low risk, and then it can be determined that the loading type of the current loading class is the first loading type, that is, the loading risk of the first loading type is low risk.

[0103] Then, loading is performed for the first loading type using the preset loader.

[0104] The preset loader refers to a loader dedicated to the first loading type.

[0105] Specifically, after obtaining the first loading type with low risk, the loading class of the first loading type with low risk is loaded through a preset loader that is set in advance.

[0106] Optionally, the preset loader can be specifically set for a certain loading type. For example, the first loading type can include Java core loading classes and extension classes, and the corresponding preset loaders are the BootstrapClassLoader and the ExtensionClassLoader. That is, the BootstrapClassLoader loads the Java core loading classes, and the ExtensionClassLoader loads the extension classes. The application's own loading classes and third-party loading classes are loaded by the Application ClassLoader (AppClassLoader) or a custom class loader, and the above-mentioned detection process is performed.

[0107] In this embodiment, the loading class of the first loading type with a lower loading risk can be directly released to reduce the impact on the original loading process.

[0108] This application also provides an application loading system.

[0109] See also Figure 3 , Figure 3 It is a structural diagram of an embodiment of an application loading system in this application.

[0110] like Figure 3 As shown, the application loading system 400 includes: a verification module 410, an acquisition module 420 and a comparison module 430; wherein, the verification module 410 uses a preset digital signature to perform signature verification on the signature database file corresponding to the application, and determines the successfully verified application as the target application, wherein the signature database file is determined by the first digest value corresponding to the loading class contained in the application, and the first digest value is generated when the application is encapsulated; the acquisition module 420 is used to obtain the second digest value corresponding to the target loading class to be loaded by the target application, wherein the second digest value is generated when the target loading class needs to be loaded; the comparison module 430 loads the target loading class in response to the second digest value being consistent with the corresponding first digest value, thereby completing the loading of the target application.

[0111] In some embodiments, the acquisition module 420 may further acquire the first digest value corresponding to the loaded class included in the application, that is, calculate and acquire the first digest value corresponding to each loaded class included in the application when the application is packaged.

[0112] In some embodiments, a signature database may also be included to store signature database files; for example, a high-performance file-based database such as SQLite is used to store the first summary value of the Java class bytecode using the fully qualified name of the Java class as the primary key.

[0113] In this application, an electronic device is also provided.

[0114] See Figure 4 , Figure 4 FIG1 is a schematic diagram of the structure of an electronic device according to an embodiment of the present application. The electronic device can execute the steps of the application loading method in the above method.

[0115] The electronic device 500 includes a memory 520, a processor 510 coupled to the memory, and at least one computer program stored in the memory 520 and executable on the processor 510. When the processor 510 loads and executes the at least one computer program, it implements the steps of the application loading method described above. For details, please refer to the detailed description of the method described above and will not be repeated here.

[0116] This application also includes a computer-readable storage medium.

[0117] See also Figure 5 , Figure 5 It is a structural diagram of an embodiment of a computer-readable storage medium in this application.

[0118] The computer-readable storage medium 600 stores at least one program 610. When the at least one program 610 is loaded and executed by the processor, it is used to implement the steps of the application loading method in the above method. For related content, please refer to the detailed description of the above method, which will not be repeated here.

[0119] The above scheme verifies the signature of the application through the signature database file, determines that the target application is successfully verified, and determines the trusted target application, wherein the signature database file contains the first digest value corresponding to the loading class of the application, and the first digest value is generated when the application is encapsulated; then obtains the second digest value corresponding to the target loading class to be loaded by the target application, and the second digest value is generated when the target loading class needs to be loaded; then compares the first digest value and the second digest value, and when the second digest value is consistent with the corresponding first digest value, loads the target loading class to determine the trusted target loading class, effectively identifies and blocks malicious loading classes, reduces the occurrence of false alarms and missed alarms, and improves detection accuracy.

[0120] In the several embodiments provided by the present invention, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0121] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of this embodiment.

[0122] In addition, the functional units in various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0123] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) or a processor to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0124] The above description is only an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made by using the contents of the description and drawings of the present invention, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A method for loading an application, characterized in that: include: Performing signature verification on a signature database file corresponding to the application using a preset digital signature, and determining the application that successfully verified as a target application, wherein the signature database file is determined using a first digest value corresponding to a loaded class included in the application, the first digest value being generated when the application is encapsulated; Obtaining a second digest value corresponding to a target loading class to be loaded by the target application, wherein the second digest value is generated when the target loading class needs to be loaded; In response to the second digest value being consistent with the corresponding first digest value, the target loading class is loaded, thereby completing the loading of the target application.

2. The method according to claim 1, characterized in that The method of using a preset digital signature to verify the signature database file corresponding to the application and determining the application that has successfully been verified as the target application includes: Obtaining first summary values ​​of all loaded classes that the application depends on, and obtaining name information of each loaded class; Determining the signature database file corresponding to the application program using the name information and the first digest value; Signing the signature database file to obtain the preset digital signature; In response to the application being ready to be loaded, the signature database file is signature verified using the preset digital signature, and the application corresponding to the successfully verified signature database file is determined as the target application.

3. The method according to claim 2, characterized in that The determining the signature database file corresponding to the application program by using the name information and the first digest value includes: The name information of each loaded class and the first digest value are used as a key-value pair to determine the signature database file corresponding to all loaded classes of the application.

4. The method according to claim 2, characterized in that The step of signing the signature database file to obtain the preset digital signature includes: Performing a separate digital signature on the signature database file to obtain the preset digital signature; In response to the application being ready to load, performing signature verification on the signature database file using the preset digital signature, and determining the application corresponding to the successfully verified signature database file as the target application, includes: Before the application is started, the signature database file is verified using the preset digital signature; and taking the application that has passed the signature visa as the target application; Applications that fail signature verification are treated as untrusted applications and are refused to start.

5. The method according to claim 1, wherein The obtaining of a second digest value corresponding to a target loading class to be loaded by the target application program includes: Obtaining a target loading class to be loaded corresponding to the target application, wherein a loading class to be loaded having a first digest value is used as the target loading class; Before loading the target loading class, a second digest value corresponding to each target loading class to be loaded is calculated using a preset digest value calculation method.

6. The method according to claim 5, characterized in that Before obtaining the second digest value, it also includes: Obtaining a first digest value corresponding to the loaded class using the name information; In response to the first digest value not existing, treating the loading class without the first digest value as an untrusted loading class and refusing to load it; or In response to the existence of the first digest value, the loading class having the first digest value is used as the target loading class and loading is performed.

7. The method according to claim 1, characterized in that In response to the second digest value being consistent with the corresponding first digest value, loading the target loading class, thereby completing the loading of the target application, includes: Comparing the first digest value with the second digest value to obtain a comparison result; In response to the first digest value being inconsistent with the second digest value, the target loading class corresponding to the second digest value is deemed an untrusted loading class and is refused to be loaded; or In response to the first digest value being consistent with the second digest value, the target loading class corresponding to the second digest value is a trusted loading class, and loading is performed.

8. The method according to claim 1, characterized in that Also includes: Obtain the loading risk corresponding to each loading type; In response to the loading risk corresponding to the loading class being less than a preset risk threshold, determining the loading type of the loading class as a first loading type; The loading class of the first loading type is loaded using a preset loader.

9. An electronic device, characterized in that: The electronic device includes a memory and a processor coupled to the memory, the memory stores at least one computer program, and when the at least one computer program is loaded and executed by the processor, it is used to implement the method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium has at least one program, and when the at least one program is loaded and executed by the processor, it is used to implement the method according to any one of claims 1 to 8.

Images