Software monitoring method, system and equipment based on byte code replacement and risk perception and medium

Abstract

The invention provides a software monitoring method, system and device based on byte code replacement and risk awareness and a medium, and belongs to the technical field of software security. The method comprises the steps that a special annotation mark in a source code is scanned, a test code entry point is recognized, and metadata information is extracted; performing encryption processing on the metadata and generating a registry file with a digital signature; environment safety data are collected through four monitoring dimensions, and a comprehensive risk score is calculated; generating a grading fusing instruction according to the score; and finally executing the fusing operation of byte code replacement or thread sandbox isolation. According to the invention, accurate identification and real-time protection of the leakage risk of the test code are realized; through a multi-dimensional monitoring and hierarchical fusing mechanism, the system security is ensured, and the influence on the service performance is minimized; and byte code replacement and thread isolation technologies are adopted, so that security protection can be realized without restarting the application, and the availability and the 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, simplified configurations of test environments replace complex configurations of use environments, which easily lead to business logic errors. Configuration class loading layer risks, which load test classes from non-trustworthy paths, such as local temporary folders, leading to test code infiltration. The above monitoring not only cannot discover cross-scene risks, but also makes a large number of security vulnerabilities undetected due to narrow monitoring range, leading to test code leakage and production accidents.

[0005] Moreover, the fuse strategy 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 due to test code threads occupying a large number of resources, without timely isolation leading to resource exhaustion of business threads, which finally cannot 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 realizes controllable, manageable and traceable test code risks in use environments through hierarchical response and specific disposal means, significantly improving the security and stability of the system.

[0007] The method comprises the following steps: S101: special annotation marks in the source code are scanned to extract metadata information corresponding to the special annotation marks; 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; S103: Collecting environment security data through four independent monitoring dimensions; 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; 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; S106: Based on the fuse instruction, a corresponding fuse operation is performed, 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.

[0008] The application also provides a software monitoring system based on bytecode replacement and risk perception, the system comprising: A mark identification module is configured to extract metadata information corresponding to special annotation marks by scanning the special annotation marks in the source code; A security registration module is configured to encrypt the extracted metadata information, generate a binary registry file, and deploy the binary registry file to the use environment, wherein the registry file uses digital signature technology to ensure integrity; A multi-dimensional monitoring module is configured to collect environment security 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 according to the comprehensive risk score, wherein the fuse instruction includes multiple levels, and each level corresponds to different disposal strategies and response intensity; 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.

[0009] According to another embodiment of the application, an electronic device is provided, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the program to implement the steps of the software monitoring method based on bytecode replacement and risk perception.

[0010] According to still another embodiment of the present application, a storage medium is also provided, 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.

[0011] From the above technical solutions, the present application has the following advantages: The software security monitoring method provided by the present application can accurately distinguish 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 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, including entropy analysis, file integrity verification, class loading path detection and thread behavior monitoring, which cover all nodes of software operation to ensure that no security risks are missed.

[0012] 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 according to 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 grading 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 restored accurately based on the state record; after the risk is removed, the business can quickly return to normal, reducing the impact of the fuse on business continuity. BRIEF DESCRIPTION OF DRAWINGS

[0013] 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.

[0014] Figure 1 The flowchart of the software monitoring method based on bytecode replacement and risk perception; Figure 2 The schematic diagram for collecting environmental safety data of four independent monitoring dimensions; Figure 3 The schematic diagram of the electronic device. DETAILED DESCRIPTION

[0015] The software monitoring method based on bytecode replacement and risk perception provided by the application relates to a test code marker identified by a compilation period annotation scanning, and a four-dimensional risk perception model is used to evaluate the environment safety state in the running time, including a configuration file entropy analysis, a file integrity verification, a class loading path detection and a thread behavior monitoring. When the test code is detected to exist in the use environment, the system starts a grading fuse mechanism according to the risk level, and the target method is replaced into a safe implementation through a dynamic bytecode replacement technology, or the dangerous code execution is blocked through a thread sandbox isolation technology. The application realizes the technical leap from the system-level extensive protection to the method-level accurate fuse, effectively solves the data pollution and logic confusion problems caused by the test code remaining in the use environment, and reduces the production accident rate.

[0016] The software monitoring system based on bytecode replacement and risk perception provided by the application can adopt a hierarchical architecture design, and the interfaces between the layers are clearly defined to communicate, forming a complete test code safety protection system.

[0017] The prevention layer in the system plays a role in the software compilation phase as the front line of the system. The prevention layer scans the special annotation markers in the source code through the static code analysis technology, and identifies all the test code entry points that need to be monitored. In 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. After the metadata is encrypted, the tamper-proof binary registry file is generated and deployed to the use environment together with the application program. The registry adopts the digital signature technology to ensure the integrity and prevent the runtime from being maliciously modified.

[0018] The perception layer realizes an innovative four-dimensional verification matrix, which comprehensively evaluates the environment safety state through four independent monitoring dimensions. Each dimension adopts 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 the lightweight probe technology, and maximally reduces the influence on the system performance. After the collected raw data is standardized, it is sent to the risk assessment engine for comprehensive analysis.

[0019] The decision layer contains multiple risk assessment models, which can calculate the comprehensive risk score according to the four-dimensional verification results. The decision engine adopts the machine learning algorithm, combines the historical fuse data and the environment characteristics, and continuously optimizes the accuracy of the risk assessment. Based on the risk score, the decision layer generates grading fuse instructions, including five fuse levels from L1 to L5. Each level corresponds to different disposal strategies and response intensity, ensuring that the fuse operation matches the risk level.

[0020] The execution layer includes a bytecode replacement engine and a thread sandbox isolator. The bytecode replacement engine is capable of dynamically modifying the execution logic of a method at runtime without restarting the application or interrupting service. The thread sandbox isolator provides stronger isolation capability, capable of pausing dangerous threads, cleaning up the execution environment, and resetting the context state. The execution layer also includes a rollback mechanism capable of restoring the original code execution after the risk is removed.

[0021] 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 the purpose of limitation, specific details such as specific system structures, techniques, and the like are presented in order to provide a thorough understanding of the embodiments of the present application. However, it should be apparent to those skilled in the art that the present application can be implemented in other embodiments without these specific details.

[0022] 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 preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. The terms "comprise", "contain", "have" and their conjugates mean "including but not limited to", unless otherwise specifically emphasized.

[0023] The phrase "one embodiment" or "some embodiments" appearing in the present application means that the specific feature, structure, or characteristic described in the embodiment is included in one or more embodiments of the present application. Therefore, the phrases "in one embodiment", "in some embodiments", "in other some embodiments", "in yet some embodiments" appearing in different places in the present application do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized.

[0024] The technical solutions in the embodiments of the present application will be described below in conjunction with the accompanying drawings of the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. 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.

[0025] Please refer to Figure 1 The flowchart of the software monitoring method based on bytecode replacement and risk perception in a specific embodiment is shown in FIG. 1. The method includes the following steps: Step S101: Extract metadata information corresponding to the special annotation mark by scanning the special annotation mark in the source code; including method name, parameter type, return type, class information, and unique identifier defined in the annotation.

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

[0027] 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 are recorded; 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 are recorded to ensure that the metadata information is complete and error-free.

[0028] In this embodiment, the special annotation marker 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.

[0029] Step S102: The extracted metadata information is encrypted to generate a binary registry file, which is deployed to the use environment, wherein the registry file uses digital signature technology to ensure integrity.

[0030] 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 identification groups containing sensitive identifiers, and regular encryption for method names and other non-sensitive information.

[0031] In this embodiment, when generating a binary registry file, the encrypted metadata is organized in a pre-set format, a digital signature technology is used to generate a special 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 are bound to the registry file. When deploying, the binary registry file is placed in a dedicated storage path of the use environment, and after deployment, the signature information is read and compared with the registry file to confirm that the file has not been damaged during transmission.

[0032] The metadata encryption of this embodiment ensures data security and prevents sensitive identifier leakage. The binary registry is fast to deploy and adapts to the efficient deployment needs of the use environment; the digital signature ensures the integrity of the registry, and improves the reliability of the entire monitoring system.

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

[0034] It is noted that, as shown in Figure 2 The configured file entropy analysis mode 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 normal use environments 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 security threshold, a risk alert is triggered.

[0035] File integrity verification ensures the integrity and authenticity of key files through advanced chaotic hash algorithms. This algorithm uses dynamic sliding window technology to block sample and mix calculate file content, generating a unique digital fingerprint. Unlike traditional hash algorithms, chaotic hash introduces random noise factors and time variables, so even minor changes in file content will result in significant differences in hash values. The system pre-calculates standard hash values in a secure environment, recalculates and compares them regularly in real time to detect tampered or abnormal files in a timely manner.

[0036] 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. By establishing a class loading whitelist mechanism, it ensures 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 penetration. 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.

[0037] Thread behavior monitoring identifies abnormal behavior patterns by analyzing thread execution characteristics. The system monitors thread call stack information, local variable state, execution frequency and resource consumption patterns. By establishing a thread behavior baseline, it can detect abnormal threads executing test code in a timely manner. Thread stack risk assessment uses a decay weighting algorithm, with closer call frames to the stack top having higher weights because these frames are more likely to contain test code being executed. The system also monitors inter-thread collaboration patterns to detect abnormal thread interaction behavior.

[0038] 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 behavior characteristics baseline of normal business threads such as call stack and resource consumption. 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 classes, 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.

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

[0040] In some embodiments, the comprehensive risk score of file entropy analysis, file integrity verification, class loading path detection, and thread behavior monitoring is calculated in the following way: 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 normal production environment and lower in test configuration.

[0041] Calculation formula:

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

[0043] 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 past 30 days.

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

[0045] The risk value R2 of the file integrity verification dimension is based on the difference between the real-time file hash and the standard hash to evaluate the risk. The larger the difference, the higher the probability of file tampering or replacement.

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

[0047] If the file is not tampered, D = 0, then R2 = 0; if the file is completely replaced, D = L, then R2 = 1; if partially tampered, the risk value is calculated according to the difference ratio.

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

[0049] 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.

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

[0051] Among them, 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 the corresponding disposal strategy is determined. Here, the comprehensive risk score in the interval of 0-1 is calculated, and the higher the score represents the higher the risk degree.

[0052] 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, 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.

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

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

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

[0056] In this embodiment, a special treatment strategy is set for each fuse level, the L1 level corresponds to "only sending risk alarm information", the L2 level corresponds to "bytecode replacement, returning a safe default value", the L3 level corresponds to "bytecode replacement", and the L4 level corresponds to "thread sandbox isolation". When the fuse instruction is generated, the instruction content includes the fuse level, target object information, and treatment 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.

[0057] The fuse instruction of this embodiment contains complete execution information, which ensures that the execution end can accurately execute without additional judgment, and realizes the standardization of risk response.

[0058] Step S106: based on the fuse instruction, a corresponding fuse operation is performed, 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.

[0059] In some embodiments, when the bytecode replacement operation is performed, for L2 or L3 level instructions, the method to be replaced by the bytecode is located, the L2 level 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 level modifies the method execution logic to "directly throw a safe exception", and the exception information includes the fuse level and risk reason. After replacement, the calling method is tested to confirm that the modified logic executes normally.

[0060] When the thread sandbox isolation operation is performed, for L4 level instructions, the thread to be isolated is located through the thread identifier first, the thread 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, and the thread state is checked after isolation to ensure that it is in the suspended state and has no resource occupation. The abnormal execution of the high-risk method is blocked through bytecode replacement, and the dangerous thread is terminated and the risk data is cleaned up through thread sandbox isolation.

[0061] In an embodiment of the present application, based on step S106, a possible embodiment will be given below to non-restrictively illustrate the specific implementation scheme. Step S106 further includes the following steps: S1061: Determine the associated impact level corresponding to the fuse operation, sort out the software modules to which the test code entry point involved in the fuse instruction belongs, and according to the running process interruption of the software module and the number of dependencies of the software module by other software modules, mark the associated impact level of each software module, and exclude the fuse operation without clear software module attribution.

[0062] In this embodiment, the software modules to which the test code entry point involved in the fuse instruction belongs 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 module is collected, the business loss caused by the 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 influence coefficient = interruption loss proportion x dependency weight is used to divide the level, dependency influence coefficient >= 0.6 is marked as high impact level, 0.3 <= dependency influence coefficient < 0.6 is marked as medium impact level, and dependency influence 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 execute, so as to avoid resource waste.

[0063] S1062: Based on the fuse level and the associated impact level of the fuse instruction, determine the specific execution parameters of the fuse operation; for bytecode replacement operation, determine the range of the method to be replaced and the type of the default value after replacement; for thread sandbox isolation operation, determine the thread data item to be cleaned and the resource release range after thread suspension.

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

[0065] S1063: Before executing the fuse operation, record the key state information of the target object, that is, the method to be replaced bytecode and the thread to be isolated; record the original bytecode logic snapshot, the fully qualified name of the method belonging to the class; record the thread identification, the value of the current local variable, and the frame data of the call stack, and store the state information and the unique identifier of the fuse instruction.

[0066] In this embodiment, for the method to be replaced bytecode, the binary storage is used to record the original bytecode logic snapshot, which includes the complete instruction sequence of the method, the fully qualified name of the method belonging to the class, the number and type of method parameters; for the thread to be isolated, the thread unique identifier, the current local variable table data, and the call stack frame details are recorded; the state information is processed 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 corresponding state data and improves recovery efficiency.

[0067] S1064: After the fusing operation is completed, the execution effect of the fusing operation is verified; it is checked whether the method to be replaced bytecode is modified according to the preset execution parameter, whether the thread to be isolated is in a suspended state and has no resource occupation; the comprehensive risk score of step S104 is called to confirm whether the current risk score is lower than that before fusing, and the decline amplitude meets the preset requirement.

[0068] It should be noted that the verification of the bytecode replacement effect is to call the modified target method, pass in the test parameter, and check whether the return result meets the preset execution parameter; the method instruction sequence is viewed through the 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 view the dangerous thread state through the system thread monitoring tool to confirm that it is in a suspended state; the thread resource occupation is checked to confirm that there is no resource leakage; the comprehensive risk score before fusing and the current score are called to calculate the decline amplitude, and if the decline amplitude is greater than or equal to the preset threshold, it is determined that the risk reduction meets the standard; if any verification item fails, the execution parameter is rechecked, and the fusing operation is performed again until all verification items pass.

[0069] S1065: Based on the monitoring data of step S103, the recovery trigger condition of the fusing operation is judged; the recovery trigger threshold is set, when the monitoring data meets the threshold, the fusing recovery operation is triggered; during the recovery process, the key state information stored in step S1063 is called to restore the original state of the target object, and after the recovery, it is checked whether the original function of the target object is normal.

[0070] The embodiment safeguards the recovery safety of the core software module by adapting the importance of the software, and the recovery efficiency of the low-importance software module; based on the snapshot recovery, the function of the target object is accurately returned to the original state to avoid new exceptions after recovery.

[0071] It should be noted that the fusing operation specifically includes the following contents: Step S701: Based on the comprehensive risk score, the type of fusing strategy to be executed is determined, the fusing strategy type includes low-risk fusing strategy, medium-risk fusing strategy and high-risk fusing strategy, and different fusing strategy types correspond to preset security protection operations.

[0072] The preset comprehensive risk score of the embodiment corresponds to the interval of the fuse strategy type, for example, the low-risk fuse strategy corresponds to the comprehensive risk score <0.3, the medium-risk fuse strategy corresponds to the comprehensive risk score 0.3≤<0.6, and the high-risk fuse strategy corresponds to the comprehensive risk score ≥0.6. The preset security protection operation is determined for each strategy type, the low-level strategy is associated with "bytecode replacement to return a safe default value", the medium-level strategy is associated with "bytecode replacement to throw a security exception", and the high-level strategy is associated with "thread sandbox isolation"; when the strategy type is determined, the comprehensive risk score generated in step S104 is read first, the interval to which the score belongs is judged, the corresponding fuse strategy type is matched, and then the list of preset security protection operations of the strategy type is called, 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.

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

[0074] According to the target method information determined in step S701, the target method to be replaced with bytecode is located, the original execution logic of the target method is read through a bytecode analysis tool, and the return type of the method is recorded, such as void, String, int, and boolean. The corresponding safe default value logic is generated according to the return type: 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 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 a class redefinition mechanism to ensure that the target method is called subsequently to execute the modified logic, and the key information of the replacement operation is recorded.

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

[0076] The embodiment locates the target method of the to-be-modified bytecode, and explicitly indicates the execution entry position of the method. The content of a specific security exception is constructed, the exception information needs to include the fuse reason, the risk indicator, and the disposal suggestion, and 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 directly throwing the custom security exception at the method execution entry is replaced, so that the exception is triggered immediately when the target method is called.

[0077] S704: When it is determined that the fuse policy type is the advanced risk fuse policy, a sandbox isolation operation is performed on the dangerous thread: first, the dangerous thread is suspended, then the local variables and call stack frames of the dangerous thread are cleaned up, then the dangerous classes related to the dangerous thread are unloaded, and finally, the context class loader of the dangerous thread is reset.

[0078] According to the dangerous thread identifier determined in step S701, the dangerous thread is located through a system thread management tool, and a thread suspension interface is called to suspend the dangerous thread. 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. The classes associated with the thread are scanned, and the dangerous classes are unloaded through a class unloading mechanism to cut off the execution dependency of the risk code. Finally, the context class loader of the thread is reset to the system default class loader, so that only trusted classes can be loaded when the thread is subsequently restored and run. During the entire isolation process, the results of each operation are recorded to ensure that the operations are traceable and the stability of the system security state is ensured.

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

[0080] After the fuse operation is completed, the safety state is checked according to the scene: if the bytecode is replaced, the target method is called and test parameters are input, and it is checked whether the execution result meets the preset requirement, and the bytecode logic of the target method is verified through a bytecode analysis tool whether it is consistent with the modification requirement; if the thread sandbox is isolated, it is checked through a thread monitoring tool whether the dangerous thread is in a suspended state.

[0081] The embodiment also calls the comprehensive risk score calculation logic of step S104, recalculates the risk score based on the current monitoring data, confirms that the score decreases by ≥ a preset value compared with before the fuse, and the current score is in a safe interval; if all check items meet the requirements, it is determined that the fuse operation achieves the preset effect; if there are items that do not meet the requirements, the corresponding fuse operation is re-executed until the check passes, so that the system truly enters a safe state.

[0082] In an embodiment of the present application, based on step S101, a possible embodiment will be given below to specifically illustrate the non-limiting embodiment. Step S101 specifically includes the following manner: Step S1011: traversing the abstract syntax tree structure of the source code, locating all nodes marked with special annotations, synchronously analyzing the inheritance relationship of the unique identifier of the annotation and the annotation scope, and establishing a multi-dimensional recognition list of annotation features.

[0083] In some embodiments, through the deep traversal of the abstract syntax tree, not only the nodes marked with @TestHook are located, but also whether @Inherited meta-annotation is included, whether the monitoring priority is specified, and whether the annotation of the parent class method in the code is 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.

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

[0085] In some embodiments, the synchronous analysis method during extraction can use the following example: software CV is called by software BN, and software CV calls software JK. 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.

[0086] Step S1013: The extended metadata set generated in step S1012 is classified and processed, the encryption level is divided according to the sensitive information type contained in the metadata, and the metadata is encrypted using the asymmetric encryption algorithm corresponding to the encryption level.

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

[0088] Step S1014: The metadata encrypted in 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 the signature value is generated.

[0089] It should be noted that the data block assembly involves performing a SHA-512 hash calculation on the concatenated value, and then using the private key to perform an RSA signature on the hash value. Before use, verify that the signatures match to ensure the data has not been tampered with. Also, check that the environmental characteristics are consistent with the production environment.

[0090] Step S1015: Before deploying the registry file to the usage environment, perform a pre-adaptation verification operation: compare the class name and software name recorded in the registry with the actual class and software under the usage environment's classpath, verify whether the unique identifier in the registry matches the whitelist configured in the usage environment's security policy, and deploy the registry file that passes the verification along with the application.

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

[0092] In one embodiment of the present invention, based on step S102, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner. Step S102 specifically includes the following methods: S1021: Classify and label the extracted metadata information according to preset rules. The preset rules include defining high / medium / low as the security level of the module to which the metadata belongs, the frequency range of historical calls of the method corresponding to the metadata, and adding a unique classification identifier to each type of metadata.

[0093] S1022: Encryption processing is adopted for metadata of different classification identifiers. High-security metadata uses asymmetric encryption algorithm, medium-security metadata uses symmetric encryption algorithm, and low-security metadata uses hash encryption algorithm. An encrypted data block corresponding to each type of metadata is generated, and the encryption algorithm type and key identifier of each type of metadata are recorded.

[0094] It should be noted that for high-security metadata, an asymmetric encryption algorithm is used to generate a public key and a private key pair. The public key is used to encrypt the metadata, and the private key is stored securely on a secure storage device. For medium-security metadata, a symmetric encryption algorithm is used to generate a unique symmetric key. This key is used to encrypt the metadata, and the key is associated with the corresponding category identifier. For low-security metadata, a hash encryption algorithm is used to calculate the hash value of the metadata as the encrypted data block. During the encryption process, the name of the encryption algorithm used for each type of metadata and the unique identifier of the key are recorded.

[0095] S1023: generating an independent sub-signature for each encrypted data block, and generating 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; the sub-signature, the total signature, and the encryption algorithm type and key identifier are integrated into a signature-data association group with the corresponding encrypted data block.

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

[0097] S1024: grouping the signature-data association groups according to the classification identifier, and grouping the association groups with the same classification identifier into a data block, adding a block index and block check information to each data block; integrating 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.

[0098] It should be noted that the binary registry file structure is clear through classification blocking, thereby improving deployment efficiency and verification speed; the block check information can quickly determine whether the block data is complete.

[0099] S1025: after deploying the binary registry file to the specified storage path of the use environment, reading the block index table, sequentially calling each data block, verifying whether the block check information is consistent with the actual block data, verifying the sub-signature of each encrypted data block and the total signature of the overall set, and confirming the validity of the signature; if the block check or signature verification fails, the corresponding data block or the entire registry file is redeployed.

[0100] It should be noted that after deploying the binary registry file to the specified path of the use environment, reading the block index table, calling each data block according to the storage location recorded in the table, comparing 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 determining that the block is damaged if they are inconsistent. In the embodiment, for each encrypted data block, the sub-signature is verified to be valid by using the key matched with the corresponding key identifier and the encryption algorithm type.

[0101] In the embodiment, the root key is used to verify whether the total signature and the sub-signature digest information match; 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.

[0102] In an embodiment of the present application, based on step S104, a possible embodiment will be given below to non-restrictively describe the specific implementation scheme. Step S104 specifically includes the following manner: S1041: Classify the monitoring data of the four monitoring dimensions collected in step S103 according to risk correlation degree, which includes three levels of high, medium and low. The classification is based on the correlation degree of each dimension data and the software module, and the correlation level identifier of each type of data is marked. Invalid monitoring data without clear correlation level is excluded.

[0103] It should be noted that by classifying according to risk correlation degree, the influence of software module related monitoring data is prioritized, avoiding dilution of risk signals by non-core business data, and improving the sensitivity of scoring to core risks.

[0104] S1042: Set initial weights for the four monitoring dimensions, collect the matching situation of each dimension evaluation result and actual risk event in the historical period, that is, the proportion of accurate evaluation times to total evaluation times, and adjust the weight of each dimension according to the usage frequency of each dimension evaluation result.

[0105] It should be noted that the initial weight is 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 evaluations are consistent with the actual risk event. Here, the evaluation is high risk when the actual risk occurs, and the evaluation is low risk when the risk does not occur, so the matching situation of this dimension is 85%.

[0106] This embodiment counts the usage frequency of each dimension: for example, the class loading path detection dimension participates in 110 times of scoring calculation in 90 days, and the thread behavior monitoring dimension participates in 105 times, with a total usage frequency of 430 times for the four dimensions; the adjusted weight is calculated as: adjusted weight = initial weight × (matching situation × 0.7 + dimension usage frequency / total usage frequency × 0.3). Alternatively, if the matching situation of a certain dimension is less than 50%, the weight of that dimension is additionally reduced by 10% to avoid interference of inefficient dimensions and improve the rationality of the weight and the accuracy of the score.

[0107] S1043: Check if there is an exception in the classified monitoring data, if there is an exception, query the corresponding dimension historical monitoring data of the same type of historical environment as the current software running environment, select the value close to the current time in the historical data to supplement to the abnormal data position, and form a monitoring data set.

[0108] It should be noted that the normal range of each dimension data is preset, such as the normal range of configuration file entropy value being 3.0-6.5, and the normal result of file integrity verification being "consistent hash value". If a certain dimension data is 2.2 or the hash value is inconsistent and there is no file update record, it is determined to be abnormal.

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

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

[0111] 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.

[0112] The following is an embodiment of a software monitoring system based on bytecode replacement and risk perception provided by the present disclosure. The system and the above-mentioned software monitoring method based on bytecode replacement and risk perception 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-mentioned embodiment of the software monitoring method based on bytecode replacement and risk perception.

[0113] The system comprises: 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. 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. The multi-dimensional monitoring module is configured to collect environment security data through four independent monitoring dimensions. The risk assessment module is configured to calculate a comprehensive risk score based on the monitoring data collected in step S103, wherein the comprehensive risk score is obtained by weighting and combining the evaluation results of the four monitoring dimensions. The fuse decision module is configured to generate a hierarchical fuse instruction according to the comprehensive risk score, wherein the fuse instruction comprises multiple levels, and each level corresponds to different disposal strategies and response intensities. The fuse execution module is 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.

[0114] As Figure 3 shown in the accompanying drawings and described in the detailed description, the present application provides a method for software monitoring based on bytecode replacement and risk perception. The method comprises the following steps: receiving a software program; determining a risk level of the software program; if the risk level is higher than a threshold, replacing a bytecode of the software program with a bytecode of a software monitoring program; and monitoring the software program based on the bytecode replacement.

[0115] In 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 processors, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections, and relationships, and their functions, are meant to be examples only, and are not intended to limit implementations of the present application as described and / or claimed in this document.

[0116] In embodiments of the present application, the processor 101 can be implemented by using at least one of an application-specific integrated circuit, a programmable logic device, a field programmable gate array, a processor, a controller, a microcontroller, a microprocessor, an electronic unit designed to perform the functions described herein, and in some cases, such implementation can be implemented in a controller. For software implementation, the implementation of such as processes or functions can be implemented with separate software modules allowing at least one function or operation to be performed, and the software code can be implemented by a software application (or program) written in any suitable programming language, which can be stored in the memory and executed by the controller.

[0117] The display module 103 is used to display information input by a 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.

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

[0119] The present application also provides a storage medium having a computer program stored thereon, wherein the computer program is executed by a processor to implement the steps of the method for software monitoring based on bytecode replacement and risk perception.

[0120] The storage medium can be any available medium that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or other

[0121] In this document, the terms "computer-readable medium" or "computer- readable media" is intended to include all medium that can be accessed by a computer. By way of example, and not limitation, computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or other

[0122] The foregoing description of the disclosed embodiments enables a person skilled in the art to implement or use the application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and generic principles defined herein can be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded 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 methods include: S101: Extract the metadata information corresponding to the special annotation markers by scanning the special annotation markers in the source code; S102: Encrypt the extracted metadata information, generate a binary registry file, and deploy it to the usage environment. The registry file uses digital signature technology to ensure its integrity. S103: Collect environmental safety data through four independent monitoring dimensions; S104: Based on the monitoring data collected in step S103, calculate the comprehensive risk score, which is obtained by weighted combination of the evaluation results of the four monitoring dimensions; S105: Generate tiered circuit breaker orders based on comprehensive risk scores. The circuit breaker orders include multiple levels, each corresponding to different handling strategies and response strengths. S106: Based on the circuit breaker instruction, execute the corresponding circuit breaker operation, which 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 dangerous threads and clean up the execution environment.

2. The software monitoring method based on bytecode replacement and risk perception according to claim 1, characterized in that, The circuit breaker operation specifically includes: Based on the comprehensive risk score, the type of circuit breaker strategy to be executed is determined. The circuit breaker strategy types include low-risk circuit breaker strategy, medium-risk circuit breaker strategy and high-risk circuit breaker strategy. When the determined circuit breaker policy type is a low-risk circuit breaker policy, a bytecode replacement operation is performed on the target method to replace the execution logic of the target method with the logic of returning a safe default value. When the determined circuit breaker policy type is a medium-risk circuit breaker policy, modify the bytecode of the target method to make the target method throw a specific security exception during execution; When the determined circuit breaker policy type is an advanced risk circuit breaker policy, a sandbox isolation operation is performed on the dangerous thread: the dangerous thread is suspended, the local variables and call stack frames of the dangerous thread are cleaned up, the dangerous classes associated with the dangerous thread are unloaded, and the context class loader of the dangerous thread is reset. After the circuit breaker operation is completed, check the execution logic state of the target method or the running state of the dangerous thread to confirm that the target method or dangerous thread is in a safe state, and ensure that the circuit breaker operation achieves the preset security protection effect.

3. The software monitoring method based on bytecode replacement and risk perception according to claim 1, characterized in that, The four monitoring dimensions include configuration file entropy analysis, file integrity verification, class loading path detection, and thread behavior monitoring.

4. The software monitoring method based on bytecode replacement and risk perception according to claim 1, characterized in that, Step S101 specifically includes the following methods: Traverse the abstract syntax tree structure of the source code, locate all nodes marked with special annotations, parse the inheritance relationship between the unique identifier of the annotation and the scope of the annotation, and establish a multi-dimensional identification list of annotation features. For the identified nodes, when extracting their metadata information, the code characteristics of the associated software are synchronized to form an extended metadata set; The extended metadata set is classified and graded, and the encryption level is divided according to the type of sensitive information contained in the metadata. The metadata is then encrypted using an asymmetric encryption algorithm corresponding to the encryption level. The encrypted metadata is combined with the pre-stored code compilation environment characteristics to generate a registry file containing the signature value; Before deploying the registry file to the usage environment, a pre-adaptation verification operation is performed: the class name and software name recorded in the registry are compared with the actual class and software in the usage environment's classpath to see if they exist, and the unique identifier in the registry annotations is verified to match the whitelist configured in the usage environment's security policy. Registry files that pass the verification are deployed with the application.

5. The software monitoring method based on bytecode replacement and risk perception according to claim 1, characterized in that, Step S102 specifically includes the following methods: The extracted metadata information is categorized and labeled according to preset rules; The metadata for different categories is encrypted. High-security metadata uses an asymmetric encryption algorithm, medium-security metadata uses a symmetric encryption algorithm, and low-security metadata uses a hash encryption algorithm. Encrypted data blocks are generated for each type of metadata, and the encryption algorithm type and key identifier for each type of metadata are recorded. Generate an independent sub-signature for each encrypted data block, and generate a total signature for the entire set of all encrypted data blocks; bind the sub-signature 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-signatures, total signature, encryption algorithm type, key identifier and corresponding encrypted data block into a signature-data association group; The signature-data association groups are grouped according to the category identifier. Association groups with the same category identifier are grouped into one data block. 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 deploying the binary registry file to the specified storage path of the usage environment, the block index table is read, each data block is retrieved one by one, and the block verification information is verified to be consistent with the actual data of the block; the sub-signature of each encrypted data block and the total signature of the entire set are verified to confirm the validity of the signature; If block verification or signature verification fails, redeploy the corresponding data block or the entire registry file.

6. The software monitoring method based on bytecode replacement and risk perception according to claim 1, characterized in that, Step S104 specifically includes the following methods: The monitoring data collected in step S103 for the four monitoring dimensions are classified according to the degree of risk correlation. The degree of risk correlation includes three levels: high, medium and low. The classification is based on the degree of correlation between the data of each dimension and the software module. The correlation level of each type of data is marked, and invalid monitoring data without a clear correlation level is excluded. Initial weights are set for the four monitoring dimensions, the matching results of each dimension assessment and actual risk events are collected in the historical period, and the weights of each dimension are adjusted based on the frequency of use of the assessment results of each dimension, generating the adjusted weight values. Check if there are any anomalies in the categorized monitoring data. If anomalies are found, query the corresponding dimension of the historical monitoring data of the same historical environment as the current software operating environment, select the values ​​in the historical data that are close to the current time to supplement the abnormal data position, and form a monitoring dataset.

7. The software monitoring method based on bytecode replacement and risk perception according to claim 1, characterized in that, Step S106 further includes the following steps: Determine the associated impact level of the circuit breaker operation, sort out the software modules to which the test code entry points involved in the circuit breaker instruction belong, and mark the associated impact level of each software module based on the interruption during the operation of the software module and the number of dependencies of the software module by other software modules; Based on the circuit breaker level and associated impact level of the circuit breaker instruction, determine the specific execution parameters of the circuit breaker operation; for bytecode replacement operation, determine the scope of the method to be replaced and the type of the default value after replacement; for thread sandbox isolation operation, determine the thread data items to be cleaned up and the scope of resource release after thread suspension. Before executing the circuit breaker operation, key state information is recorded for the target object, namely the method whose bytecode is to be replaced and the thread to be isolated; a snapshot of the original bytecode logic and the fully qualified name of the class to which the method belongs are also recorded. For each thread, record the thread identifier, the value of the current local variable, and the frame data of the call stack, and bind and store the status information with the unique identifier of the circuit breaker instruction; After completing the circuit breaker operation, verify the effectiveness of the circuit breaker operation. Check whether the method of the bytecode to be replaced has been modified according to the preset execution parameters, and whether the thread to be isolated is in a paused state and has no resource consumption; Retrieve the comprehensive risk score from step S104 to confirm whether the current risk score has decreased compared to before the circuit breaker was triggered, and whether the decrease meets the preset requirements.

8. 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 as described in any one of claims 1 to 7; The system includes: The marker recognition module is used to extract metadata information corresponding to special annotation markers by scanning special annotation markers in the source code; The secure registration module is used to encrypt the extracted metadata information, generate a binary registry file, and deploy it to the usage environment. The registry file uses digital signature technology to ensure its integrity. The multi-dimensional monitoring module is used to collect environmental safety data through four independent monitoring dimensions; The risk assessment module calculates a comprehensive risk score based on the collected monitoring data. The comprehensive risk score is obtained by weighted combination of the assessment results of four monitoring dimensions. The circuit breaker decision module is used to generate tiered circuit breaker instructions based on the comprehensive risk score. The circuit breaker instructions include multiple levels, each corresponding to different handling strategies and response strengths. The circuit breaker execution module executes corresponding circuit breaker operations based on circuit breaker instructions. These operations include bytecode replacement or thread sandbox isolation. Bytecode replacement is used to modify the execution logic of a method, while thread sandbox isolation is used to suspend dangerous threads and clean up the execution environment.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the software monitoring method based on bytecode replacement and risk perception as described in any one of claims 1 to 7.

10. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the software monitoring method based on bytecode replacement and risk perception as described in any one of claims 1 to 7.

Images