A software monitoring method, system, device and medium based on bytecode replacement and risk perception

Abstract

The application provides a software monitoring method, system, device and medium based on bytecode replacement and risk perception, and belongs to the technical field of software security. The method identifies a test code entry point and extracts metadata information by scanning special annotation marks in source code. Then, the metadata is encrypted and a digitally signed registry file is generated. Environment safety data is collected through four monitoring dimensions and a comprehensive risk score is calculated. A grading fuse instruction is generated according to the score. Finally, a fuse operation of bytecode replacement or thread sandbox isolation is performed. The application realizes accurate identification and real-time protection of test code leakage risks. Through multi-dimensional monitoring and grading fuse mechanism, the system safety is ensured and the impact on business performance is minimized. By using bytecode replacement and thread isolation technology, safety protection can be realized without restarting the application, and the availability and operation and maintenance efficiency of the system are improved.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of software security, and particularly relates to a software monitoring method, system, device and medium based on bytecode replacement and risk perception. BACKGROUND

[0002] With the increase of software system complexity and the diversification of attack means, traditional software security protection technology faces significant challenges. Cross-platform languages represented by Java, whose bytecode files are essentially intermediate forms of source code, are extremely easy to restore to code structures close to source code through decompilation tools. Although existing technologies protect the code through name obfuscation, control flow obfuscation, bytecode encryption and other means.

[0003] In related technologies, when identifying test code entry points, the semantics of annotations are not combined, business code is misjudged as test code, leading to invalid occupation of monitoring resources; and test code without features but with special annotations is missed, so that real risk points are not monitored.

[0004] In related technologies, when monitoring file integrity, configuration layer risks replace complex configurations of the use environment with simplified configurations of the test environment, which easily leads to business logic errors. Configuration class loading layer risks load test classes from untrusted paths, such as local temporary folders, leading to test code infiltration. The above monitoring not only cannot discover cross-scenario risks, but also makes a large number of security vulnerabilities undetected due to narrow monitoring scope, leading to test code leakage and production accidents.

[0005] Moreover, the fuse policy immediately terminates associated threads as soon as the risk exceeds the standard, which does not realize risk level differences, and causes excessive operations in low-risk scenarios, such as terminating payment threads due to slightly low file entropy, leading to large-scale business interruption; and insufficient operations in high-risk scenarios, such as sending alarms for test code threads occupying a large number of resources, without timely isolation leading to resource exhaustion of business threads, ultimately failing to balance the needs of security protection and business continuity. SUMMARY

[0006] The application provides a software monitoring method based on bytecode replacement and risk perception, which solves the problems of insufficient accuracy, weak security and large performance overhead in traditional monitoring technology, and through hierarchical response and specific disposal means, realizes controllable, manageable and traceable test code risks in the use environment, significantly improves the security and stability of the system.

[0007] The method comprises the following steps:

[0008] S101: Marking special annotations in the source code, extracting metadata information corresponding to the special annotations;

[0009] S102: The extracted metadata information is encrypted, a binary registry file is generated, and the binary registry file is deployed to the use environment, wherein the registry file uses digital signature technology to ensure integrity;

[0010] S103: Collecting environment security data through four independent monitoring dimensions;

[0011] S104: Based on the monitoring data collected in step S103, a comprehensive risk score is calculated, wherein the comprehensive risk score is obtained by weighted combination of the evaluation results of the four monitoring dimensions;

[0012] S105: According to the comprehensive risk score, a hierarchical fuse instruction is generated, wherein the fuse instruction includes multiple levels, and each level corresponds to different disposal strategies and response intensity;

[0013] S106: Based on the fuse instruction, the corresponding fuse operation is executed, wherein the fuse operation includes bytecode replacement or thread sandbox isolation, the bytecode replacement is used to modify the execution logic of the method, and the thread sandbox isolation is used to suspend the dangerous thread and clean up the execution environment.

[0014] The application also provides a software monitoring system based on bytecode replacement and risk perception, the system comprising:

[0015] The marking recognition module is used for extracting metadata information corresponding to the special annotation mark by scanning the special annotation mark in the source code;

[0016] The security registration module is used for encrypting the extracted metadata information, generating a binary registry file, and deploying the binary registry file to the use environment, wherein the registry file uses digital signature technology to ensure integrity;

[0017] The multi-dimensional monitoring module is used for collecting environment security data through four independent monitoring dimensions;

[0018] The risk assessment module calculates a comprehensive risk score based on the collected monitoring data, wherein the comprehensive risk score is obtained by weighted combination of the evaluation results of the four monitoring dimensions;

[0019] The fuse decision module is used for generating a hierarchical fuse instruction according to the comprehensive risk score, wherein the fuse instruction includes multiple levels, and each level corresponds to different disposal strategies and response intensity;

[0020] The fuse execution module executes the corresponding fuse operation based on the fuse instruction, wherein the fuse operation includes bytecode replacement or thread sandbox isolation, the bytecode replacement is used to modify the execution logic of the method, and the thread sandbox isolation is used to suspend the dangerous thread and clean up the execution environment.

[0021] According to another embodiment of the present application, an electronic device is provided, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor implementing the steps of the bytecode replacement and risk-aware software monitoring method when executing the program.

[0022] According to yet another embodiment of the present application, a storage medium is also provided, having stored thereon a computer program, the computer program implementing the steps of the bytecode replacement and risk-aware software monitoring method when executed by a processor.

[0023] From the above technical solutions, the present application has the following advantages:

[0024] The software security monitoring method provided by the present application can accurately distinguish between test code and business code by scanning special annotation marks in the source code and extracting complete metadata information including method name, parameter type, return type, etc., and can exclude non-test code and isolated test methods not connected to the business link. The metadata is encrypted and a binary registry file is generated using digital signature technology, which prevents metadata from being stolen during storage and transmission, and ensures that the registry has not been tampered with maliciously through signature verification. Four independent configuration files are defined, namely entropy analysis, file integrity verification, class loading path detection, and thread behavior monitoring, which cover all nodes of software operation and ensure that no security risks are missed.

[0025] By weighting and combining the monitoring data of the four dimensions, the abstract monitoring information is converted into a comprehensive risk score in the 0-1 interval, and the weight can be dynamically adjusted in combination with the historical risk matching degree; the quantitative score makes the risk level intuitive and controllable, and the risks in different business scenarios can be compared horizontally. According to the comprehensive risk score, a hierarchical fuse instruction is generated, which matches the operation of different levels to ensure that the risk can be blocked in high-risk scenarios, and to achieve a balance between security protection and smooth software operation. The original state of the target object is recorded before the fuse is executed, and the effect is verified after the fuse is executed, and the original state can be accurately restored based on the state record when it is restored; it ensures that the business can quickly return to normal after the risk is removed, and reduces the impact of the fuse on business continuity. BRIEF DESCRIPTION OF DRAWINGS

[0026] In order to more clearly illustrate the technical solutions of the present application, the drawings needed in the description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0027] Figure 1 Flowchart of the bytecode replacement and risk-aware software monitoring method;

[0028] Figure 2 A schematic diagram for collecting environment safety data for four independent monitoring dimensions;

[0029] Figure 3 A schematic diagram for an electronic device. DETAILED DESCRIPTION

[0030] The software monitoring method based on bytecode replacement and risk perception provided by the present application identifies test code markers through compile-time annotation scanning, and uses a four-dimensional risk perception model to evaluate the environment safety state at runtime, including configuration file entropy analysis, file integrity verification, class loading path detection, and thread behavior monitoring. When it is detected that test code exists in the use environment, the system starts a hierarchical fuse mechanism according to the risk level, replaces the target method with a safe implementation through dynamic bytecode replacement technology, or blocks the execution of dangerous code through thread sandbox isolation technology. The present application realizes a technical leap from system-level extensive protection to method-level precise fuse, effectively solves the problem of data pollution and logical confusion caused by the residual test code in the use environment, and reduces the production accident rate.

[0031] The software monitoring system based on bytecode replacement and risk perception provided by the present application can be designed with a layered architecture, and the layers communicate with each other through well-defined interfaces, forming a complete test code safety protection system.

[0032] The prevention layer in the system serves as the front-line defense of the system and plays a role during the software compilation phase. The prevention layer scans special annotation markers in the source code through static code analysis technology to identify all test code entry points that need to be monitored. During the scanning process, the system extracts the complete metadata information of the method, including the method name, parameter type, return type, class information, and unique identifier defined in the annotation. These metadata are encrypted to generate a tamper-proof binary registry file, which is deployed to the use environment together with the application program. The registry uses digital signature technology to ensure integrity and prevent runtime from being maliciously modified.

[0033] The perception layer realizes an innovative four-dimensional verification matrix, which comprehensively evaluates the environment safety state through four independent monitoring dimensions. Each dimension uses a special detection algorithm and risk assessment model to ensure that the test code leakage risk is identified from different angles. The perception layer collects monitoring data through lightweight probe technology, minimizing the impact on system performance. The collected raw data is standardized and sent to the risk assessment engine for comprehensive analysis.

[0034] The decision layer includes a multi-level risk assessment model that can calculate a comprehensive risk score based on the four-dimensional verification results. The decision engine uses machine learning algorithms combined with historical fuse data and environmental characteristics to continuously optimize the accuracy of risk assessment. Based on the risk score, the decision layer generates graded fuse instructions, including five fuse levels from low to high, L1 to L5. Each level corresponds to different handling strategies and response intensity, ensuring that the fuse operation matches the risk level.

[0035] The execution layer includes a bytecode replacement engine and a thread sandbox isolator. The bytecode replacement engine can dynamically modify the execution logic of methods at runtime without restarting the application or interrupting the service. The thread sandbox isolator provides stronger isolation capabilities, enabling the suspension of dangerous threads, cleaning of the execution environment, and resetting of the context state. The execution layer also includes a rollback mechanism that can restore the original code execution after the risk is resolved.

[0036] The software monitoring method based on bytecode replacement and risk perception according to the present application will be described in detail below. For the purpose of illustration but not for limitation, specific details such as particular system structures, techniques, etc. are presented in order to provide a thorough understanding of the embodiments of the present application. However, it will be apparent to one skilled in the art that the present application can be implemented in other embodiments without these specific details.

[0037] It should be understood that when used in the specification, the term "comprises" indicates the presence of the described features, integers, steps, operations, elements, and / or components, but does not exclude one or more other features, integers, steps, operations, elements, components, and / or groups thereof. The terms "comprises", "comprising", "includes", "including" and "has", "having" mean "including but not limited to" unless otherwise specifically specified.

[0038] The phrase "one embodiment" or "some embodiments" appearing in the specification does not necessarily refer to the same embodiment, unless otherwise specifically noted. It should be understood that the phrase "one embodiment" or "some embodiments" refers to "one or more but not all embodiments" of the application unless otherwise specifically noted. The phrase "one embodiment" or "some embodiments" does not necessarily refer to the same embodiment, unless otherwise specifically noted.

[0039] The technical solutions in the embodiments of the present application will be described in detail below with reference to the accompanying drawings of the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, not all. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0040] Referring to Figure 1 FIG. 1 shows a flowchart of a software monitoring method based on bytecode replacement and risk perception in an embodiment, the method comprising:

[0041] Step S101: Extract metadata information corresponding to the special annotation mark in the source code by scanning the special annotation mark; including method name, parameter type, return type, class information, and unique identifier defined in the annotation.

[0042] In some embodiments, code parsing technology is used to traverse all classes and methods of the source code, and code segments containing special annotation marks are screened; in the screening process, valid annotations and invalid annotations are distinguished, and code containing only annotation declarations but not associated with actual test logic is excluded, and the test code entry point that needs to be monitored is located.

[0043] When extracting metadata information in this embodiment, for the identified entry point corresponding method, the fully qualified name of the method name, the specific category of the parameter type, such as int, String in the basic data type, and the fully qualified name of the custom object type; The declaration form of the return type, such as single return type, generic return type, void type without return value, the class name of the class to which it belongs and the parent class inheritance relationship, and the unique identifier defined in the annotation, ensure that the metadata information is complete and error-free.

[0044] In this embodiment, the special annotation mark is used as an identification anchor point to lock the location of the test code in the source code, avoiding misidentification of non-test code, and ensuring that the subsequent operation can accurately locate the target test code.

[0045] Step S102: Encrypt the extracted metadata information to generate a binary registry file, and deploy it to the use environment, wherein the registry file uses digital signature technology to ensure its integrity.

[0046] In some embodiments, when the metadata information extracted in step S101 is encrypted, the metadata is first grouped by category, and each group is processed using an adaptive encryption method, such as high-strength encryption for annotation mark groups containing sensitive identifiers, and regular encryption for method names and other non-sensitive information.

[0047] When generating a binary registry file in this embodiment, the encrypted metadata is organized in a pre-set format, a digital signature technology is used to generate a dedicated signature for the registry file, and the signature information includes the generation time of the registry, the total amount of data, and the check value, which is bound to the registry file. When deploying, place the binary registry file in the dedicated storage path of the use environment, and after deployment, read the signature information and compare it with the registry file to confirm that the file has not been damaged during transmission.

[0048] The metadata encryption of the embodiment guarantees data security and prevents sensitive identification leakage. The binary registry is fast to deploy and is efficient in adapting to the deployment requirements of the use environment; the digital signature ensures the integrity of the registry and improves the reliability of the entire monitoring system.

[0049] Step S103: Collect environmental security data through four independent monitoring dimensions, including configuration file entropy analysis, file integrity verification, class loading path detection, and thread behavior monitoring. The collection process uses lightweight probe technology to reduce the impact on system performance.

[0050] It should be noted that, as Figure 2 shown, the configured file entropy analysis method is based on evaluating the security state of the configuration file using information theory principles. The system monitors the information entropy changes of key configuration files and identifies abnormalities by calculating the randomness and complexity of configuration parameters. Configuration files in a normal use environment usually have high entropy values because they contain various complex configuration items; while test configurations often use simplified or fixed values, resulting in significantly lower entropy values. The system establishes a configuration file entropy baseline model and monitors abnormal deviations from the baseline in real time. When the entropy value is detected to be lower than the safety threshold, a risk alert is triggered.

[0051] File integrity verification ensures the integrity and authenticity of key files through advanced chaotic hash algorithms. The algorithm uses dynamic sliding window technology to block sample and mix the file content, generating a unique digital fingerprint. Unlike traditional hash algorithms, chaotic hash introduces random noise factors and time variables, so even a small change in file content will result in a huge difference in hash value. The system pre-calculates the standard hash value in a secure environment, recalculates and compares it regularly during runtime, and detects tampered or abnormal files in a timely manner.

[0052] Class loading path detection monitors the integrity of the class loading mechanism. The system tracks the loading source of each important class, analyzes the class loader hierarchy and class file location information, and establishes a class loading whitelist mechanism to ensure that only classes from trusted paths can be loaded and executed. The system pays special attention to dynamically generated classes and classes loaded through non-standard paths, which are often important channels for test code infiltration. The class pollution index calculation model considers the number, importance, and distribution range of abnormal classes to accurately assess the security state of the class environment.

[0053] Thread behavior monitoring is to identify abnormal behavior patterns by analyzing thread execution characteristics. The system monitors the call stack information, local variable state, execution frequency and resource consumption pattern of the thread. By establishing a thread behavior baseline, abnormal threads executing test code can be detected in a timely manner. Thread stack risk assessment uses a decay weighting algorithm. The closer to the top of the stack, the higher the weight of the call frame, because these frames are more likely to contain test code being executed. The system also monitors the cooperation pattern between threads to find abnormal thread interaction behavior.

[0054] In some embodiments, four independent and complementary monitoring dimensions are constructed to form a comprehensive security perception system. Each dimension first establishes a normal state benchmark: the configuration file entropy value dimension determines the randomness and complexity range of normal configuration parameters through information theory principles to form an entropy value baseline; the file integrity dimension pre-stores standard features of key files in a secure environment; the class loading path dimension establishes a whitelist of trusted class loading sources; and the thread behavior dimension determines the call stack, resource consumption and other behavior characteristics baseline of normal business threads. On this basis, each dimension continuously collects real-time data of the corresponding monitoring object: the configuration file dimension tracks parameter entropy value changes, the file dimension obtains real-time digital fingerprints, the class loading dimension records the loading source and structure of the class, and the thread dimension monitors running characteristics and cooperation patterns. By comparing real-time data with preset benchmarks, abnormalities deviating from the normal state are identified, and finally, abnormal signals are transmitted to subsequent risk disposal links through risk alerts or security state assessments, realizing early perception and accurate identification of software security risks.

[0055] Step S104: Based on the monitoring data collected in step S103, a comprehensive risk score is calculated, wherein the comprehensive risk score is obtained by weighted combination of the evaluation results of the four monitoring dimensions.

[0056] In some embodiments, the file entropy analysis, file integrity verification, class loading path detection and thread behavior monitoring calculate the comprehensive risk score in the following way:

[0057] The risk value R1 of the file entropy analysis dimension is calculated based on the deviation of the configuration file entropy value from the baseline. The configuration entropy value is higher in the normal production environment and lower in the test configuration.

[0058] Calculation formula:

[0059]

[0060] E current is the real-time information entropy of the current configuration file.

[0061] E baseline is the pre-stored normal production environment configuration file entropy baseline, which is obtained by statistical analysis of historical normal data, such as the average entropy value of the risk-free period in the last 30 days.

[0062] If E current greater than or equal to E baseline , then R1 = 0, the entropy value is normal, and there is no risk; if E current less than or equal to E baseline , the lower the entropy value, the closer R1 is to 1, and the higher the risk.

[0063] The file integrity verification dimension risk value R2 is evaluated based on the difference between the real-time file hash and the standard hash. The greater the difference, the higher the probability that the file is tampered with or replaced.

[0064] R2 = D / L; D is the difference in bits between the real-time file chaos hash and the standard hash. L is the total number of bits of the hash value.

[0065] If the file is not tampered with, D = 0, then R2 = 0; if the file is completely replaced, D = L, then R2 = 1; and for partial tampering, the risk value is calculated according to the difference ratio.

[0066] The class loading path detection dimension risk value R3 is evaluated based on the number of abnormal classes loaded by untrusted paths and their importance. The higher the proportion of abnormal classes and the greater the importance, the higher the risk.

[0067] Thread behavior monitoring is to analyze the abnormal behavior of threads, such as frequent context switching and blocking state. The running state, blocking state, death state, and CPU occupancy rate of threads are monitored. Matrix analysis method or historical iteration method considering time decay is used for analysis.

[0068] Based on the four monitoring dimensions, the comprehensive score formula is:

[0069]

[0070] where wd is the weight of the dth dimension, and Rd is the risk value of the corresponding dimension. According to the comprehensive score, the fuse level is divided, and different disposal strategies are corresponding. Here, the comprehensive risk score in the interval [0, 1] is calculated, and the higher the score, the higher the risk degree.

[0071] For example, if the configuration file entropy risk value R1 = 0.6, the file integrity risk value R2 = 0.8, the class loading path risk value R3 = 0.4, the thread behavior risk value R4 = 0.7, the weights w1 = 0.3, w2 = 0.2, w3 = 0.25, and w4 = 0.25, then the comprehensive score = 0.3 x 0.6 + 0.2 x 0.8 + 0.25 x 0.4 + 0.25 x 0.7 = 0.565, triggering the intermediate fuse instruction.

[0072] It can be seen that the dispersed multi-dimensional monitoring data is converted into a unified quantitative risk indicator, the influence of important dimensions on the overall risk is highlighted through weight allocation, and the weight is fine-tuned in combination with historical data to ensure that the score can objectively reflect the actual security state of the software.

[0073] Step S105: generating a grading fuse instruction according to the comprehensive risk score, wherein the fuse instruction includes a plurality of grades, and each grade corresponds to a different disposal strategy and response intensity.

[0074] In some embodiments, the fuse grade interval is divided, such as that the comprehensive risk score <0.3 corresponds to the L1 grade, 0.3≤score <0.6 corresponds to the L2 grade, 0.6≤score <0.8 corresponds to the L3 grade, and score≥0.8 corresponds to the L4 grade, which can be set to the L5 grade as needed.

[0075] In this embodiment, a special disposal strategy is set for each fuse grade, the L1 grade corresponds to “only sending risk alarm information”, the L2 grade corresponds to “bytecode replacement, returning a safe default value”, the L3 grade corresponds to “bytecode replacement”, and the L4 grade corresponds to “thread sandbox isolation”. When the fuse instruction is generated, the instruction content includes the fuse grade, target object information, disposal strategy details such as default value type, exception information, and isolation resource cleaning range. The instruction unique identifier is used for subsequent tracking and verification to ensure that the execution end can accurately obtain the execution requirements.

[0076] The fuse instruction of this embodiment includes complete execution information, ensuring that the execution end can accurately execute without additional judgment, and realizing the standardization of risk response.

[0077] Step S106: executing a corresponding fuse operation based on the fuse instruction, wherein the fuse operation includes bytecode replacement or thread sandbox isolation, the bytecode replacement is used to modify the execution logic of the method, and the thread sandbox isolation is used to suspend the dangerous thread and clean up the execution environment.

[0078] In some embodiments, when the bytecode replacement operation is executed, the method of the bytecode to be replaced is located for the L2 or L3 grade instruction. The L2 grade modifies the method execution logic to “return a safe default value”, exemplarily, the object type returns null, the numerical value type returns 0, and the Boolean type returns false. The L3 grade modifies the method execution logic to “directly throw a safe exception”, and the exception information includes the fuse grade and risk reason. After replacement, the calling method is tested to confirm that the modified logic executes normally.

[0079] When performing the thread sandbox isolation operation, for the L4 level instruction, the thread to be isolated is located through the thread identifier, the thread running is suspended, the local variables, call stack frames and context class loaders of the thread are cleaned up, the memory resources and network connection resources occupied by the thread are released, the thread state is checked after isolation to ensure that the thread is in a suspended state and does not occupy resources. The abnormal execution of high-risk methods is blocked through bytecode replacement, and the dangerous thread is terminated and the risk data is cleaned up through the thread sandbox isolation.

[0080] In an embodiment of the present application, based on step S106, a possible embodiment will be given below to specifically and non-limitingly illustrate the implementation thereof. Step S106 further comprises the following steps:

[0081] S1061: Determine the associated impact level corresponding to the fuse operation, sort out the software modules to which the test code entry points involved in the fuse instruction belong, mark the associated impact level of each software module according to the number of interruptions in the running process of the software module and the number of dependencies of the software module by other software modules, and exclude the fuse operation without clear software module attribution.

[0082] In this embodiment, the software modules to which the test code entry points involved in the fuse instruction belong are sorted out, the module division is clearly defined through the software architecture document, and the isolated modules not associated with any business function are excluded; the historical running interruption data of the software modules are collected, the business loss caused by a single interruption of each software module for 1 hour is counted, the upper limit of the single interruption loss that the system can bear is set, and the interruption loss proportion of each software module is calculated. The number of dependencies of each software module is counted, and the dependency impact coefficient = interruption loss proportion x dependency weight is used to divide the level, the dependency impact coefficient >= 0.6 is marked as high impact level, 0.3 <= dependency impact coefficient < 0.6 is marked as medium impact level, and dependency impact coefficient < 0.3 is marked as low impact level; for the fuse operation without clear module attribution, it is determined that it is not necessary to be executed, so as to avoid resource waste.

[0083] S1062: Based on the fuse level and the associated impact level of the fuse instruction, the specific execution parameters of the fuse operation are determined; for the bytecode replacement operation, the range of the method to be replaced and the type of the default value after replacement are determined; for the thread sandbox isolation operation, the thread data items to be cleaned up and the resource release range after the thread is suspended are determined.

[0084] It should be noted that the association of the fuse level and the associated impact level through the two-dimensional matching table enables the execution parameters to adapt to the risk and execution demand at the same time, and realizes the precision of the fuse operation.

[0085] S1063: Before performing the fuse operation, record the key state information of the target object, i.e., the method to be replaced by the bytecode, and the thread to be isolated; record the original bytecode logic snapshot, the fully qualified name of the method, the thread identifier, the current local variable value, and the frame data of the call stack; and store the state information and the unique identifier of the fuse instruction.

[0086] In this embodiment, the method to be replaced by the bytecode is recorded in binary to record the original bytecode logic snapshot, including the complete instruction sequence of the method, the fully qualified name of the method, the number and type of method parameters; for the thread to be isolated, record the unique identifier of the thread, the current local variable table data, and the call stack frame details; and process the state information in the format of instruction unique identifier-target object type-state data. In this way, the information is bound to the instruction identifier, which facilitates subsequent quick positioning of the corresponding state data and improves the recovery efficiency.

[0087] S1064: After completing the fuse operation, verify the execution effect of the fuse operation; check whether the method to be replaced by the bytecode is modified according to the preset execution parameter, and whether the thread to be isolated is in a suspended state and has no resource occupation; call the comprehensive risk score of step S104 to confirm whether the current risk score is lower than that before the fuse, and whether the decline meets the preset requirement.

[0088] It should be noted that verifying the bytecode replacement effect is to call the modified target method, pass in the test parameters, and check whether the return result meets the preset execution parameter; and the method instruction sequence is checked by a bytecode analysis tool to confirm that the original instruction has been replaced by the preset logic. The verification of the thread sandbox isolation effect is to check the state of the dangerous thread by a system thread monitoring tool to confirm that it is in a suspended state; check the thread resource occupation to confirm that there is no resource leakage; call the comprehensive risk score before the fuse and the current score to calculate the decline amplitude, and if the decline amplitude ≥ the preset threshold, it is determined that the risk is reduced to the standard; if any verification item fails, the execution parameter is checked again, and the fuse operation is performed again until all verification items pass.

[0089] S1065: Based on the monitoring data of step S103, determine the recovery trigger condition of the fuse operation; set a recovery trigger threshold, and when the monitoring data meets the threshold, trigger the fuse recovery operation; during the recovery process, call the key state information stored in step S1063 to restore the original state of the target object, and check whether the original function of the target object is normal after the recovery.

[0090] In this embodiment, the threshold is adapted to the importance of the software to ensure the safety of the recovery of the core software module and the efficiency of the recovery of the low-importance software module; and the snapshot-based recovery ensures the accurate regression of the function of the target object to the original state, avoiding new exceptions after the recovery.

[0091] It should be noted that the fuse operation specifically includes the following contents:

[0092] Step S701: Based on the comprehensive risk score, determine the type of the fuse policy to be executed, which includes low-risk fuse policy, medium-risk fuse policy and high-risk fuse policy, and different fuse policy types correspond to preset security protection operations.

[0093] The preset corresponding interval of the comprehensive risk score and the fuse policy type in this embodiment, for example, the low-risk fuse policy corresponds to the comprehensive risk score <0.3, the medium-risk fuse policy corresponds to 0.3≤comprehensive risk score <0.6, and the high-risk fuse policy corresponds to the comprehensive risk score ≥0.6. For each type of policy, the preset security protection operation is clear, the low-level policy is associated with "bytecode replacement to return a safe default value", the medium-level policy is associated with "bytecode replacement to throw a security exception", and the high-level policy is associated with "thread sandbox isolation"; when determining the policy type, first read the comprehensive risk score generated in step S104, judge the interval to which the score belongs, match the corresponding fuse policy type, and then call the preset security protection operation list of the policy type, which contains the identification rule of the operation object and the core requirement of the operation execution, to ensure that the subsequent operation has clear execution basis.

[0094] S702: When the determined fuse policy type is the low-risk fuse policy, perform bytecode replacement operation on the target method, and replace the execution logic of the target method with the logic of returning a safe default value; wherein, according to the return type of the target method, select the corresponding safe default value, the void type target method corresponds to the null value, the object return type target method corresponds to the null value, the numerical value return type target method corresponds to the zero value, and the boolean return type target method corresponds to the false value.

[0095] According to the target method information determined in step S701, the embodiment locates the target method to be replaced by bytecode, reads the original execution logic of the target method through the bytecode analysis tool, and records the return type of the method, such as void, String, int, and boolean. According to the return type, the corresponding safe default value logic is generated: if it is a void type, the method execution logic is replaced with "an empty instruction sequence without any business operation"; if it is an object return type, it is replaced with "an instruction for directly returning a null value"; if it is a numerical value return type, it is replaced with "an instruction for returning a zero value"; if it is a boolean return type, it is replaced with "an instruction for returning a false value"; after the replacement is completed, the bytecode of the target method is updated through the class redefinition mechanism to ensure that the modified logic is executed when the target method is called subsequently, and the key information of the replacement operation is recorded.

[0096] S703: When the determined fuse policy type is a medium-risk fuse policy, modify the bytecode of the target method to make the target method throw a specific security exception during execution; the security exception contains the fuse reason, risk indicator, and disposal suggestion; at the same time, record the fuse log, which contains the exception stack information, environment state information, and request context information.

[0097] The embodiment locates the target method to be modified bytecode and explicitly specifies the execution entry position of the method. The content of the specific security exception is constructed, and the exception information needs to contain the fuse reason, risk indicator, and disposal suggestion. The exception information is encapsulated as a custom security exception conforming to the system exception specification. The bytecode logic of the target method is modified, the original business execution instruction is deleted, and the instruction sequence of "method execution entry directly throwing the custom security exception" is replaced, to ensure that the target method is called to trigger an exception immediately.

[0098] S704: When the determined fuse policy type is a high-risk fuse policy, perform sandbox isolation operation on the dangerous thread: first suspend the dangerous thread, then clean up the local variables and call stack frame of the dangerous thread, then unload the dangerous classes related to the dangerous thread, and finally reset the context class loader of the dangerous thread.

[0099] The embodiment locates the dangerous thread according to the dangerous thread identifier determined in step S701, suspends it by calling the thread suspension interface. Thread data is cleaned up, the local variable table of the thread is read, sensitive data stored in the table is deleted, and the call stack frame of the thread is emptied. Scan the classes associated with the thread, unload these dangerous classes through the class unloading mechanism, and cut off the execution dependency of the risk code; finally, reset the context class loader of the thread to the system default class loader, to ensure that the thread can only load trusted classes if it is resumed for subsequent running. During the entire isolation process, the results of each operation are recorded to ensure that the operation is traceable and the stability of the system security state is ensured.

[0100] S705: After completing the above fuse operation, check the execution logic state of the target method or the running state of the dangerous thread to confirm that the target method or the dangerous thread is in a safe state, and ensure that the fuse operation achieves the preset security protection effect.

[0101] After the fuse operation is completed, the embodiment checks the security state according to the scene: if the bytecode is replaced, the target method is called and test parameters are passed in to check whether the execution result meets the preset requirements, and the bytecode analysis tool is used to verify whether the bytecode logic of the target method is consistent with the modification requirement; if the thread sandbox is isolated, the thread monitoring tool is used to check whether the dangerous thread is in a suspended state.

[0102] The embodiment also invokes the comprehensive risk score calculation logic of step S104 to recalculate the risk score based on the current monitoring data, confirms that the score decreases by ≥ a preset value before the fusing, and the current score is in the safe interval; if all the check items meet the requirements, it is determined that the fusing operation achieves the preset effect; if there are non-compliant items, the corresponding fusing operation is re-executed until the check passes, ensuring that the system truly enters a safe state.

[0103] In an embodiment of the present application, based on step S101, a possible embodiment will be given below to illustrate the non-limiting specific implementation. Step S101 specifically includes the following modes:

[0104] Step S1011: Traverse the abstract syntax tree structure of the source code, locate all nodes annotated with special annotations, synchronously analyze the inheritance relationship of the unique identifier of the annotation and the annotation scope, and establish a multi-dimensional recognition list of annotation features.

[0105] In some embodiments, through the deep traversal of the abstract syntax tree, not only the nodes annotated with @TestHook are located, but also whether @Inherited meta-annotation is included, whether the monitoring priority is specified, and whether the annotations of the parent class method in the code are automatically passed to the child class method are analyzed, a multi-dimensional annotation feature list is established to ensure that the identification of the monitoring entry point covers more complex code structure scenarios.

[0106] Step S1012: For the nodes identified in step S1011, the metadata information is extracted synchronously associated with the code features of the software to form an extended metadata set.

[0107] In some embodiments, the synchronous analysis mode during extraction can use the following examples: software CV is called by software BN, and software CV calls software JK, then the information of software BN and JK is attached to the metadata of software CV as associated data of software execution. This associated information can be used to quickly locate the call link of the test code in the use environment.

[0108] Step S1013: Classify and grade the extended metadata set generated in step S1012, divide the encryption level according to the sensitive information type contained in the metadata, and use the asymmetric encryption algorithm corresponding to the encryption level to encrypt the metadata.

[0109] It should be noted that if the method parameter contains user information such as an ID card number, the parameter type field in its metadata is marked as “highly sensitive” and uses RSA-4096 asymmetric encryption; if the software is only used for internal logging, its metadata is marked as not sensitive and uses AES-256 symmetric encryption. The encryption key is generated by the master key derivation to ensure the security of the encryption process.

[0110] Step S1014: The encrypted metadata of step S1013 is bound with the pre-stored code compilation environment features, specifically the compiler version, dependent library hash value, and source code modification timestamp, to generate a data block combination containing the metadata body, encrypted information, and environment feature binding. The overall integrity of the data block combination is verified through digital signature technology, and a registry file containing a signature value is generated.

[0111] It should be noted that the data block combination is subjected to SHA-512 hash calculation on the splicing value, and then the hash value is RSA signed using a private key. Before use, verify whether the signature matches to ensure that the data has not been tampered with. At the same time, check whether the environment features are consistent with the production environment.

[0112] Step S1015: Before deploying the registry file to the use environment, perform pre-adaptation verification operation: compare the class name and software name recorded in the registry with the classes and software in the actual class path of the use environment to verify whether the annotation unique identifier in the registry matches the white list configured by the security policy of the use environment. The verified registry file is deployed with the application.

[0113] It should be noted that the registry records whether the corresponding process actually exists in the file of the use environment before deployment. If the production environment security policy specifies that only annotations with monitoring identifiers SEC-001 to SEC-099 are allowed, then the annotation identifier of all @TestHook in the registry must be within this range, otherwise the registry file is rejected.

[0114] In an embodiment of the present application, based on step S102, a possible embodiment will be given below to illustrate the specific implementation scheme. Step S102 specifically includes the following modes:

[0115] S1021: The extracted metadata information is classified and labeled according to the preset rules, which include defining high / medium / low as the security level for the metadata belonging to the module, and adding a unique classification identifier to each type of metadata.

[0116] S1022: Different classification identifiers of metadata are subjected to encryption processing, high security level metadata uses asymmetric encryption algorithm, medium security level metadata uses symmetric encryption algorithm, and low security level metadata uses hash encryption algorithm, to generate encrypted data blocks corresponding to each type of metadata, and record the encryption algorithm type and key identifier of each type of metadata.

[0117] It should be noted that for high security level metadata, an asymmetric encryption algorithm is selected to generate a pair of public key and private key, the metadata is encrypted by the public key, and the private key is properly stored in a secure storage device; for medium security level metadata, a symmetric encryption algorithm is selected to generate a unique symmetric key, and the metadata is encrypted by the key, and the key is associated to the corresponding classification identifier; for low security level metadata, a hash encryption algorithm is selected, and the hash value of the metadata is calculated as an encrypted data block; during the encryption process, the encryption algorithm name and the unique identifier of the key used by each type of metadata are recorded.

[0118] S1023: Generate an independent sub-signature for each encrypted data block, and generate a total signature for the overall set of all encrypted data blocks; the sub-signature is bound to the classification identifier of the corresponding encrypted data block, and the total signature contains the digest information of all sub-signatures; integrate the sub-signature, the total signature, the encryption algorithm type, and the key identifier into a signature-data association group corresponding to the encrypted data block.

[0119] The present embodiment ensures the integrity of a single encrypted data block through a sub-signature, ensures the consistency of all encrypted data blocks through a total signature, and improves the accuracy of signature verification.

[0120] S1024: Group the signature-data association groups according to the classification identifier, and group the association groups with the same classification identifier into a data block, add a block index and a block check information to each data block; integrate all data blocks and block index tables to generate a binary registry file, and the block index table records the classification identifier, block index, and storage location of each block.

[0121] It should be noted that by classifying and blocking, the structure of the registry file is clear, and the deployment efficiency and verification speed are improved; the block check information can quickly determine whether the block data is complete.

[0122] S1025: After deploying the binary registry file to the specified storage path of the use environment, read the block index table, call each data block one by one, and verify whether the block check information and the actual block data are consistent; verify the sub-signature of each encrypted data block and the total signature of the overall set to confirm the validity of the signature; if the block check or signature verification fails, redeploy the corresponding data block or the entire registry file.

[0123] It should be noted that after deploying the binary registry file to the specified path of the use environment, read the block index table, call each data block according to the storage location recorded in the table, compare whether the actual byte length, the number of association groups, and the feature hash value of the block are consistent with the block check information, and if they are not consistent, the block is determined to be damaged. In the present embodiment, for each encrypted data block, the key matching the corresponding key identifier and the encryption algorithm type are used to verify whether the sub-signature is valid.

[0124] The embodiment verifies whether the total signature and the sub-signature digest information match by using the root key; if the block is damaged or the signature is invalid, the damaged block is redeployed; if multiple blocks are damaged or the total signature is invalid, the entire registry file is redeployed, thereby improving the reliability of the registry deployment.

[0125] In an embodiment of the present application, based on step S104, a possible embodiment will be given below to specifically and non-limitingly illustrate the specific implementation thereof. Step S104 specifically comprises the following manner:

[0126] S1041: The monitoring data of the four monitoring dimensions collected in step S103 is classified according to risk correlation degrees, the risk correlation degrees including three levels of high, medium and low, the classification basis being the correlation degree of each dimension data with the software module, and the correlation level identifier of each type of data is marked, and invalid monitoring data without an explicit correlation level is excluded.

[0127] It should be noted that by classifying according to risk correlation degrees, the influence of the software module related monitoring data is prioritized, non-core business data dilutes the risk signal is avoided, and the sensitivity of the score to the core risk is improved.

[0128] S1042: Initial weights are set for the four monitoring dimensions, the matching situation of the evaluation results of each dimension with the actual risk events in the historical period is collected, that is, the proportion of the number of accurate evaluations to the total number of evaluations, and the weights of each dimension are adjusted in combination with the usage frequency of the evaluation results of each dimension.

[0129] It should be noted that the initial weights are set to 25% for each of the four dimensions; the historical period is selected as the past 90 days, and the number of accurate evaluations of each dimension is counted: for example, the configuration file entropy analysis dimension has a total of 120 evaluations in 90 days, of which 102 evaluation results are consistent with the actual risk events, that is, the risk actually occurs when the evaluation is high risk, and the risk does not occur when the evaluation is low risk, and the matching situation of this dimension is 85%.

[0130] The usage frequency of each dimension is counted in the embodiment: for example, the class loading path detection dimension participates in 110 times of score calculation in 90 days, and the thread behavior monitoring dimension participates in 105 times, and the total usage frequency of the four dimensions is 430 times; the adjusted weight is calculated according to the formula: adjusted weight = initial weight x (matching situation x 0.7 + dimension usage frequency / total usage frequency x 0.3). Alternatively, if the matching situation of a certain dimension is less than 50%, the weight of the dimension is additionally reduced by 10% to avoid interference of the low-efficiency dimension to the score and improve the rationality of the weight and the accuracy of the score.

[0131] S1043: It is checked whether the classified monitoring data is abnormal, if the monitoring data is abnormal, the corresponding historical monitoring data of the same type of historical environment as the current software running environment is queried, the values close to the current time in the historical data are selected to supplement the abnormal data positions, and a monitoring data set is formed.

[0132] It should be noted that the preset normal range of each dimension data is, for example, the normal range of the profile entropy value is 3.0-6.5, and the normal result of the file integrity verification is "consistent hash value", if the dimension data is 2.2 or the hash value is inconsistent and there is no file update record, it is determined to be abnormal.

[0133] When the embodiment queries the same type of historical software usage environment, the historical usage environment with the same software type code and consistent deployment architecture is screened, and the record with a time difference between the historical data time and the current time ≤24 hours is selected in the usage environment, to ensure the integrity and reliability of the data set.

[0134] It should be noted that the four dimension monitoring data sets collected in step S103 are evaluated respectively, and each dimension data is converted into a dimension risk value in the interval of 0-1. The comprehensive risk score is calculated by comprehensive risk score = profile entropy dimension risk value x corresponding weight + file integrity dimension risk value x corresponding weight + class loading path dimension risk value x corresponding weight + thread behavior dimension risk value x corresponding weight, and the comprehensive risk score in the interval of 0-1 is obtained. The higher the score, the higher the risk degree.

[0135] It should be understood that the size of the serial number of each step in the above embodiment does not mean the order of execution, and the execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application.

[0136] The following is an embodiment of a software monitoring system based on bytecode replacement and risk perception provided by the embodiment of the present disclosure. The system and the software monitoring method based on bytecode replacement and risk perception of each of the above embodiments belong to the same inventive concept. Details not described in the embodiment of the software monitoring system based on bytecode replacement and risk perception can be referred to the above embodiment of the software monitoring method based on bytecode replacement and risk perception.

[0137] The system comprises:

[0138] The mark identification module is configured to extract metadata information corresponding to the special annotation mark by scanning the special annotation mark in the source code.

[0139] The security registration module is configured to encrypt the extracted metadata information, generate a binary registry file, and deploy the binary registry file to the usage environment, wherein the binary registry file adopts a digital signature technology to ensure the integrity.

[0140] The multi-dimensional monitoring module is configured to collect environment security data through four independent monitoring dimensions.

[0141] a risk assessment module configured to calculate a comprehensive risk score based on the monitoring data collected in step S103, wherein the comprehensive risk score is obtained by weighted combination of the evaluation results of the four monitoring dimensions;

[0142] a fuse decision module configured to generate a hierarchical fuse instruction according to the comprehensive risk score, wherein the fuse instruction comprises a plurality of levels, each level corresponds to a different disposal strategy and response intensity;

[0143] a fuse execution module configured to execute a corresponding fuse operation based on the fuse instruction, wherein the fuse operation comprises bytecode replacement or thread sandbox isolation, the bytecode replacement is used to modify the execution logic of the method, and the thread sandbox isolation is used to suspend the dangerous thread and clean up the execution environment.

[0144] As shown in Figure 3 The present application also provides an electronic device, comprising a display module 103, a memory 102, a processor 101, and a computer program stored in the memory and executable on the processor 101, wherein the processor 101 implements the steps of the software monitoring method based on bytecode replacement and risk perception when executing the program.

[0145] In the embodiments of the present application, the electronic device includes but is not limited to a laptop computer, a desktop computer, a workstation, a personal digital assistant, a server, a blade server, a mainframe computer, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are merely examples, and are not intended to limit the implementation of the embodiments described herein and / or claimed.

[0146] In the embodiments of the present application, the processor 101 can be implemented by using at least one of application specific integrated circuits, programmable logic devices, field programmable gate arrays, processors, controllers, microcontrollers, microprocessors, electronic units designed to perform the functions described herein, and in some cases, such implementations can be implemented in a controller. For software implementation, the implementation of processes or functions can be implemented with separate software modules that allow at least one function or operation to be performed. The software code can be implemented by a software application (or program) written in any appropriate programming language, which can be stored in a memory and executed by a controller.

[0147] The display module 103 is used to display information input by the user or information provided to the user. The display module 103 can include a display panel, which can be configured in the form of a liquid crystal display, an organic light emitting diode, etc.

[0148] Memory 102 can be used to store software programs as well as various data. Memory 102 can include high-speed random access memory, and can also include nonvolatile memory such as at least one magnetic disk storage device, flash memory device, or other nonvolatile solid-state storage device.

[0149] The application also provides a storage medium, which stores a computer program, and the computer program is executed by a processor to implement the steps of the software monitoring method based on bytecode replacement and risk perception.

[0150] The storage medium can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium may, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or apparatus, or any combination thereof. More specific examples (non-exhaustive list) of readable storage media include an electrical connection having one or more wires, a portable disc, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0151] In the storage medium, the readable signal medium can include a data signal carried in a baseband or as a part of a carrier wave, in which readable program codes are borne. Such a propagated data signal can take on many forms, including but not limited to electro-magnetic signal, optical signal, or any suitable combination thereof. The readable signal medium can also be any readable medium that can send, propagate, or transmit program codes for use by or in connection with an instruction execution system, apparatus, or device.

[0152] The above description of disclosed embodiments enables a person skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to these embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A software monitoring method based on bytecode replacement and risk perception, characterized in that, The method comprises: S101: Extract metadata information corresponding to the special annotation mark by scanning the special annotation mark in the source code; Traverse the abstract syntax tree structure of the source code, locate all nodes annotated with special annotations, parse the inheritance relationship between the unique identifier of the annotation and the annotation scope, and establish a multi-dimensional recognition list of annotation characteristics; For the identified nodes, extract their metadata information while synchronously associating the code characteristics of the software to form an extended metadata set; Classify and process the extended metadata set, divide the encryption level according to the sensitive information type contained in the metadata, and encrypt the metadata using the asymmetric encryption algorithm corresponding to the encryption level; Based on the encrypted metadata and the pre-stored code compilation environment characteristics, generate a registry file containing a signature value; Before deploying the registry file to the use environment, perform a pre-adaptation verification operation: compare the class name and software name recorded in the registry with the class name and software name in the actual class path of the use environment, verify whether the annotation unique identifier in the registry matches the white list configured in the use environment security policy, and deploy the verified registry file with the application; S102: Encrypt the extracted metadata information to generate a binary registry file, and deploy it to the use environment, wherein the registry file uses digital signature technology to ensure integrity; S103: Collect environment security data through four independent monitoring dimensions; S104: Calculate the comprehensive risk score based on the monitoring data collected in step S103, wherein the comprehensive risk score is obtained by weighting the evaluation results of the four monitoring dimensions; S105: Generate a hierarchical fuse instruction according to the comprehensive risk score, wherein the fuse instruction includes multiple levels, each level corresponds to a different disposal strategy and response intensity; S106: Based on the fuse instruction, execute the corresponding fuse operation, wherein the fuse operation includes bytecode replacement or thread sandbox isolation, bytecode replacement is used to modify the execution logic of the method, and thread sandbox isolation is used to suspend the dangerous thread and clean up the execution environment; The fuse operation specifically includes: Based on the comprehensive risk score, determine the type of fuse strategy to be executed, the fuse strategy type includes low-risk fuse strategy, medium-risk fuse strategy and high-risk fuse strategy; When the determined fuse strategy type is a low-risk fuse strategy, perform a bytecode replacement operation on the target method to replace the execution logic of the target method with a logic that returns a safe default value; When the determined fuse strategy type is a medium-risk fuse strategy, modify the bytecode of the target method so that the target method throws a specific security exception during execution; When the determined fuse strategy type is a high-risk fuse strategy, perform a sandbox isolation operation on the dangerous thread: suspend the dangerous thread, clean up the local variables and call stack frames of the dangerous thread, unload the dangerous classes related to the dangerous thread, and reset the context class loader of the dangerous thread; After completing the fuse operation, check the execution logic state of the target method or the running state of the dangerous thread to confirm that the target method or the dangerous thread is in a safe state, and ensure that the fuse operation achieves the preset security protection effect; The four monitoring dimensions include profile entropy analysis, file integrity verification, class loading path detection and thread behavior monitoring.

2. The software monitoring method based on bytecode replacement and risk perception according to claim 1, characterized in that, The step S102 specifically comprises the following manners: The extracted metadata information is classified and marked according to preset rules; Different metadata classification identifiers are subjected to encryption processing, high-security-level metadata is subjected to asymmetric encryption algorithm, medium-security-level metadata is subjected to symmetric encryption algorithm, and low-security-level metadata is subjected to hash encryption algorithm, to generate encrypted data blocks corresponding to each type of metadata, record the encryption algorithm type and key identifier of each type of metadata; An independent sub-signature is generated for each encrypted data block, and a total signature is generated for the overall collection of all encrypted data blocks; the sub-signature is bound to the classification identifier of the corresponding encrypted data block, and the total signature contains the digest information of all sub-signatures; the sub-signature, the total signature, the encryption algorithm type, the key identifier and the corresponding encrypted data block are integrated into a signature-data association group; The signature-data association groups are grouped according to the classification identifiers, the association groups of the same classification identifier are grouped into one data block, and a block index and block verification information are added to each data block; all data blocks and block index tables are integrated to generate a binary registry file; After the binary registry file is deployed to a specified storage path of a use environment, the block index table is read, each data block is called one by one, and it is verified whether the block verification information is consistent with the actual data of the block; the sub-signature of each encrypted data block and the total signature of the overall collection are verified to confirm the validity of the signature; If the block verification or signature verification fails, the corresponding data block or the entire registry file is redeployed.

3. The software monitoring method based on bytecode replacement and risk perception according to claim 1, characterized in that, The step S104 specifically comprises the following manners: The monitoring data of the four monitoring dimensions collected in the step S103 is classified according to risk correlation degrees, the risk correlation degrees include three levels of high, medium and low, the classification basis is the association degree of the dimension data and the software module, the association level identifier of each type of data is marked, and invalid monitoring data without an explicit association level is excluded; Initial weights are set for the four monitoring dimensions, the matching situation of the evaluation results of each dimension and the actual risk events in a historical period is collected, the weights of the dimensions are adjusted in combination with the use frequency of the evaluation results of the dimensions, and adjusted weight values are generated; It is checked whether there is an exception in the classified monitoring data, if there is an exception, the corresponding dimension historical monitoring data of a historical environment similar to the current software running environment is queried, values close to the current time in the historical data are selected and supplemented to the position of the abnormal data, and a monitoring data set is formed.

4. The software monitoring method based on bytecode replacement and risk perception according to claim 1, characterized in that, The step S106 further comprises the following steps: An association impact level corresponding to the fuse operation is determined, the software modules to which the test code entry points involved in the fuse instruction belong are combed, and the association impact level of each software module is marked according to the interruption data in the running process of the software module and the number of dependencies of the software module on other software modules; Based on the fuse level and the association impact level of the fuse instruction, specific execution parameters of the fuse operation are determined; for the bytecode replacement operation, the range of the method to be replaced and the type of the default value after replacement are determined; for the thread sandbox isolation operation, the thread data items to be cleaned and the resource release range after thread suspension are determined; Before performing the fuse operation, record key state information of the target object, i.e., the method to be replaced by the bytecode, and the thread to be isolated; record the original bytecode logic snapshot, the fully qualified name of the class to which the method belongs; for the thread to be isolated, record the thread identifier, the current local variable value, and the call stack frame data, and store the recorded information and the unique identifier of the fuse instruction after binding; After completing the fuse operation, verify the execution effect of the fuse operation; Check whether the method to be replaced by the bytecode is modified according to the preset execution parameter, and whether the thread to be isolated is in a suspended state and has no resource occupation; Call the comprehensive risk score of step S104 to confirm whether the current risk score decreases compared to before the fuse and whether the decrease amplitude meets the preset requirement.

5. A software monitoring system based on bytecode replacement and risk perception, characterized in that, The system is used to implement the software monitoring method based on bytecode replacement and risk perception according to any one of claims 1 to 4. The system comprises: A label identification module is configured to extract metadata information corresponding to the special annotation label by scanning the special annotation label in the source code; A security registration module is configured to encrypt the extracted metadata information, generate a binary registry file, and deploy it to the use environment, wherein the registry file uses digital signature technology to ensure its integrity; A multi-dimensional monitoring module is configured to collect environmental safety data through four independent monitoring dimensions; A risk assessment module is configured to calculate a comprehensive risk score based on the collected monitoring data, wherein the comprehensive risk score is obtained by weighted combination of the evaluation results of the four monitoring dimensions; A fuse decision module is configured to generate a hierarchical fuse instruction based on the comprehensive risk score, wherein the fuse instruction comprises multiple levels, each level corresponding to different disposal strategies and response intensities; A fuse execution module is configured to perform a corresponding fuse operation based on the fuse instruction, wherein the fuse operation includes bytecode replacement or thread sandbox isolation, the bytecode replacement is used to modify the execution logic of the method, and the thread sandbox isolation is used to suspend the dangerous thread and clean up the execution environment.

6. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the program to implement the steps of the software monitoring method based on bytecode replacement and risk perception according to any one of claims 1 to 4.

7. A storage medium having stored thereon a computer program, characterized in that The computer program is executed by the processor to implement the steps of the software monitoring method based on bytecode replacement and risk perception according to any one of claims 1 to 4.

Images