An application protection method and device based on a Mach kernel and a related medium

Abstract

The application discloses an application program protection method and device based on a Mach kernel and related medium, and the method comprises the following steps: initializing a protection module for interacting with the Mach kernel in a target application program loading stage, and obtaining a kernel-level protection environment object; establishing a system call channel for the Mach kernel by using the kernel-level protection environment object, and obtaining a kernel-mode running environment state object; calling an exception port of the Mach kernel by using the kernel-mode running environment state object, and generating an exception port check state object; performing aggregation analysis on process characteristics in the kernel-mode running environment state object based on the exception port check state object, and outputting an application program running protection state object. The application performs aggregation analysis on the process characteristics in the kernel-mode running environment state object through the exception port check state object, so as to construct a running protection state machine, and in this way, the application program running time can timely identify illegal debugging risks and take protection measures.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method, apparatus and related media for application protection based on the Mach kernel. Background Technology

[0002] In existing technologies, runtime protection for applications typically relies on standard user-space interface call chains to obtain process flags and runtime environment states, and then uses this information for debugging or risk assessment. However, these interface call paths are in user space and are easily intercepted by interface hooking mechanisms, which can return forged state information. This prevents the protection program from obtaining a true and reliable runtime environment state from the kernel space, thus hindering the verification based on abnormal port configurations and the construction of subsequent protection state machines from having a reliable data foundation. Consequently, it becomes difficult to identify illegal debugging risks in a timely manner. Summary of the Invention

[0003] This invention provides a method, apparatus, and related medium for protecting applications based on the Mach kernel, aiming to solve the technical problem that existing application runtime protection methods are unable to promptly identify illegal debugging risks.

[0004] In a first aspect, embodiments of the present invention provide an application protection method based on the Mach kernel, comprising: Obtain the startup information of the target application, and initialize the protection module that interacts with the Mach kernel during the loading phase of the target application to establish the runtime parameter configuration and obtain the kernel-level protection environment object; A system call channel to the Mach kernel is established using the kernel-level protection environment object to obtain the kernel-mode runtime environment state object; The kernel-mode runtime environment state object is used to call the abnormal port of the Mach kernel, and the configuration of the abnormal port is compared with the preset abnormal port baseline to generate an abnormal port verification state object. Based on the abnormal port verification status object, the process characteristics in the kernel-mode runtime environment status object are aggregated and analyzed, and a runtime protection state machine is constructed to output the application runtime protection status object.

[0005] Secondly, embodiments of the present invention provide an application protection device based on the Mach kernel, comprising: The parameter acquisition unit is used to acquire the startup information of the target application and initialize the protection module that interacts with the Mach kernel during the loading phase of the target application to establish the running parameter configuration and obtain the kernel-level protection environment object. The channel invocation unit is used to establish a system invocation channel for the Mach kernel using the kernel-level protection environment object, and to obtain the kernel-mode runtime environment state object. The port comparison unit is used to call the abnormal port of the Mach kernel using the kernel-mode runtime environment status object, and compare the configuration of the abnormal port with the preset abnormal port baseline to generate an abnormal port verification status object. The program protection unit is used to aggregate and analyze the process characteristics in the kernel-mode runtime environment state object based on the abnormal port verification state object, construct a runtime protection state machine, and output the application runtime protection state object.

[0006] Thirdly, embodiments of the present invention provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the Mach kernel-based application protection method of the first aspect.

[0007] Fourthly, embodiments of the present invention provide a computer-readable storage medium, wherein a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, it implements the Mach kernel-based application protection method of the first aspect.

[0008] This invention provides an application protection method based on the Mach kernel, comprising: acquiring the startup information of a target application; initializing a protection module that interacts with the Mach kernel during the loading phase of the target application to establish runtime parameter configuration and obtain a kernel-level protection environment object; establishing a system call channel to the Mach kernel using the kernel-level protection environment object to obtain a kernel-mode runtime environment state object; calling an abnormal port of the Mach kernel using the kernel-mode runtime environment state object and comparing the configuration of the abnormal port with a preset abnormal port baseline to generate an abnormal port verification state object; performing aggregate analysis on the process characteristics in the kernel-mode runtime environment state object based on the abnormal port verification state object, constructing a runtime protection state machine, and outputting an application runtime protection state object. This invention uses the abnormal port verification state object to aggregate and analyze the process characteristics in the kernel-mode runtime environment state object, thereby constructing a runtime protection state machine. This allows the application to promptly identify illegal debugging risks and take protective measures during runtime.

[0009] This invention also provides an application protection device, computer device, and storage medium based on the Mach kernel, which have the same beneficial effects as described above. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A flowchart illustrating an application protection method based on the Mach kernel provided in an embodiment of the present invention; Figure 2 This is a schematic block diagram of an application protection device based on the Mach kernel, provided as an embodiment of the present invention. Detailed Implementation

[0012] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0013] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0014] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0015] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0016] Please see below. Figure 1 , Figure 1 The flowchart of an application protection method based on the Mach kernel provided in this embodiment of the invention specifically includes steps S101 to S104.

[0017] S101. Obtain the startup information of the target application, and initialize the protection module that interacts with the Mach kernel during the loading phase of the target application to establish the running parameter configuration and obtain the kernel-level protection environment object. S102. Establish a system call channel for the Mach kernel using the kernel-level protection environment object to obtain the kernel-mode runtime environment state object; S103. Use the kernel-mode runtime environment state object to call the abnormal port of the Mach kernel, and compare the configuration of the abnormal port with the preset abnormal port baseline to generate an abnormal port verification state object. S104. Based on the abnormal port verification status object, perform aggregate analysis on the process characteristics in the kernel-mode runtime environment status object, construct a runtime protection state machine, and output the application runtime protection status object.

[0018] In step S101, the protection module can be executed before the main function during the application loading phase, and the Mach-related interface initialization, preset protection strategy parameter loading, and resource reservation required for runtime environment detection can be completed during the protection module initialization process, thereby obtaining a kernel-level protection environment object.

[0019] In one embodiment, step S101 includes: During the application loading phase, the loading entry point is determined based on the startup information, and the configuration of the protection module is invoked to obtain the protection module invocation configuration object; The protection module calls a configuration object to trigger the protection module to generate running parameters before the preset main function is executed, thus obtaining the protection module running parameters; The kernel interface, policy parameters, and reserved resources are initialized in the constructor based on the operating parameters of the protection module to obtain a kernel-level protection environment object.

[0020] In this embodiment, step S101 is used to complete the pre-loading and initialization of the protection module during the application loading stage, enabling it to intervene in the runtime environment before the main function is executed, and to establish the basic runtime parameters and resources required for interaction with the Mach kernel, so as to obtain a kernel-level protection environment object. This step can complete the loading entry point determination and protection module call configuration based on the startup information, and trigger the execution of the protection module in the early stage of startup by setting the function attribute ((constructor)), thereby forming a layer of runtime environment protection during the application startup stage and preventing LLDB from adding debugging during the startup stage.

[0021] Specifically, during the application loading phase, the loading entry point is determined based on the startup information, and the configuration of the protection module is invoked to obtain a protection module invocation configuration object. The startup information can be used to characterize the loading context of the target application, thereby determining the triggering timing and entry point of the protection module. Based on this, the generated protection module invocation configuration object is used to describe the loading location, invocation entry point, and invocation order constraints of the protection module, enabling the protection module to be identified by the system loading process through the function attribute ((constructor)) and scheduled to be executed before the main function, thus satisfying the pre-triggering requirements of the loading phase.

[0022] Furthermore, the protection module generates runtime parameters by utilizing the configuration object called by the protection module before the execution of the preset main function. Specifically, after the constructor entry marked with `attribute((constructor))` is invoked, the protection module loads the preset parameter framework according to the configuration object called by the protection module and generates runtime parameters that can be used for subsequent kernel interaction and status detection. These runtime parameters may include at least a stage identifier to identify the execution phase of the protection module, policy parameter loading information to constrain the loading of protection policies, and parameter index information for resource scheduling. The parameters are written to and made accessible before the constructor returns, ensuring that the protection module runtime parameters are in a valid state that can be read and referenced when the main function begins execution.

[0023] Furthermore, based on the protection module's operating parameters, the kernel interface, policy parameters, and reserved resources are initialized in the constructor to obtain a kernel-level protection environment object. Specifically, during the constructor's execution, the initialization configuration of the Mach-related interfaces is completed according to the protection module's operating parameters, providing the protection module with the necessary interface calls for subsequent interaction with the kernel. Simultaneously, preset protection policy parameters are loaded, and the necessary resources are reserved for subsequent runtime environment detection and protection actions. These reserved resources may include a cache structure for storing kernel interaction results, a state storage structure for recording early startup environment information, and a context structure for reuse in subsequent detection processes. After completing the above initialization, the initialized kernel interface, policy parameters, and reserved resources are encapsulated to obtain the kernel-level protection environment object.

[0024] In step S102, a system call channel to the Mach kernel is established using the kernel-level protection environment object to obtain runtime environment state information from the kernel side. The dependency on the user-mode standard library call chain can be eliminated, and a direct kernel-oriented call method can be used to trigger critical state reading operations, forming a set of state information that can characterize the kernel-mode runtime environment, thereby obtaining the kernel-mode runtime environment state object.

[0025] In one embodiment, step S102 includes: Based on the kernel-level protection environment object, an inline instruction sequence for triggering system calls is defined, and a system call template object is obtained; The process flag is obtained from the Mach kernel using the system call template object, and the first kernel process status detection result is obtained. Based on the first kernel process status detection result, process control information is obtained to obtain the second kernel process status detection result; The kernel process list is traversed using the results of the second kernel process status detection, and aggregated and analyzed according to the characteristics of debugging tools to obtain the kernel-mode runtime environment state object.

[0026] In this embodiment, step S102 is used to construct a kernel interaction path of "building a direct system call channel (bypassing Hook)" under the constraints of the kernel-level protected environment object, abandoning the dependence on the user-mode standard library call chain, and instead executing key operations such as csops and sysctl in a system call mode oriented towards the Mach kernel, thereby obtaining a basis for outputting state information that can characterize the kernel-mode running environment.

[0027] Specifically, based on the kernel-level protected environment object, an inline instruction sequence for triggering system calls is defined, resulting in a system call template object. This system call template object can be implemented by defining inline assembly macros; for example, for the ARM64 architecture, an assembly code block containing "mov x16, #system call number" and "svc #0x80" is constructed, and this assembly code block is associated and encapsulated with the system call number input parameters, register constraints, and return value carrying method to obtain a reusable system call trigger template for subsequent calls from different kernel query operations.

[0028] Furthermore, the process flags are obtained from the Mach kernel using the system call template object to obtain the first kernel process status detection result. Specifically, the CSOPS system call is executed based on the system call template object, passing in system call number 169 (csops) and opcode CS_OPS_STATUS to directly obtain the process status flags in the kernel; the returned flags are then parsed to at least determine whether the CS_DEBUGGED (0x10000000) flag is included, thereby generating the first kernel process status detection result associated with the process debugging state.

[0029] Furthermore, process control information is obtained based on the first kernel process state detection result to obtain the second kernel process state detection result. Specifically, based on the first kernel process state detection result, the process control dimensions that need to be further read are determined, and the SYSCTL system call is executed using the system call template object, passing in system call number 202 (sysctl), constructing the MIB array {CTL_KERN, KERN_PROC, KERN_PROC_PID, getpid()} to directly read the process control structure kinfo_proc from the kernel; subsequently, the p_flag field in kinfo_proc is parsed to at least determine whether it contains the P_TRACED flag, and the second kernel process state detection result is output accordingly.

[0030] Furthermore, the kernel process list is traversed using the second kernel process status detection result, and aggregated and analyzed according to debugging tool characteristics to obtain a kernel-mode runtime environment state object. Based on the second kernel process status detection result, the global process list is retrieved and traversed. The global process list can be obtained via sysctl, and process names can be traversed to detect the presence of typical tool processes such as frida, debugserver, and lldb. Simultaneously, the process name matching results are aggregated with the second kernel process status detection result to obtain a comprehensive state record representing process list characteristics and process control information, thus obtaining the kernel-mode runtime environment state object. Moreover, since the instruction sequence can be directly executed on the CPU and enter kernel mode, it is difficult for attackers to intercept or detect the system call process through API hooks set in user mode, thereby ensuring the consistency of the state source of the kernel-mode runtime environment state object.

[0031] In step S103, the abnormal port of the Mach kernel is invoked using the kernel-mode runtime environment state object, and the configuration of the abnormal port is compared with a preset abnormal port baseline. The abnormal port configuration of the current task can be obtained through the Mach kernel interface, and the port set is checked for consistency in combination with the preset abnormal port baseline to determine whether there is any abnormal port that has been illegally taken over or deviated from the baseline, thereby generating an abnormal port verification state object.

[0032] In one embodiment, step S103 includes: Based on the kernel-mode runtime environment status object, query the abnormal port to obtain the abnormal port configuration object; Based on the abnormal port configuration object, the target application is compared with the whitelist and suspicious abnormal types are marked to obtain the abnormal port determination object; The abnormal port determination object is used to call the port switching interface to replace the suspicious abnormal port, thereby obtaining the abnormal port replacement configuration object; The abnormal port replacement configuration object triggers a breakpoint exception in the test scenario, and the signal receiving port is compared to generate an abnormal port verification status object.

[0033] In this embodiment, step S103 is used to take over and verify the exception handling entry point of the target application at the Mach level, so as to obtain an exception port verification status object that can be used to determine whether there is illegal debugging takeover. In specific implementation, after obtaining the kernel-mode runtime environment status object, a query on the current Mach Task exception port configuration can be triggered based on the object, and integrity verification, port preemption, and effect verification can be performed around the port occupancy status of key exception types.

[0034] Specifically, the abnormal port is queried based on the kernel-mode runtime environment state object to obtain the abnormal port configuration object. In practice, `task_get_exception_ports` is called to obtain the abnormal port information of the current Mach Task. This can be done by obtaining the corresponding port list based on `EXC_MASK_ALL`, and then the port handling handle information associated with each exception mask in the port list is structurally encapsulated to obtain the abnormal port configuration object, which serves as input for subsequent verification and replacement.

[0035] After obtaining the abnormal port configuration object, the target application is compared with the whitelist based on the abnormal port configuration object, and suspicious exception types are marked to obtain the abnormal port judgment object. In implementation, the port set in the abnormal port configuration object can be traversed, and a whitelist judgment benchmark can be constructed based on whether the port's Handler is MACH_PORT_NULL or the system default handling handle. When a port configuration related to breakpoints or software exceptions is detected to deviate from the whitelist, the corresponding exception type is marked as a suspicious exception type. Since debuggers such as LLDB can perform debugging by replacing the ports of EXC_BREAKPOINT (breakpoint exception) and EXC_SOFTWARE, if it is found that the port of the above-mentioned exception type is occupied by a non-system process or its Handler does not meet the whitelist conditions, the suspicious mark and its corresponding port location and exception type information are recorded in the abnormal port judgment object.

[0036] Furthermore, the port switching interface is invoked using the aforementioned abnormal port determination object to replace suspicious abnormal ports, resulting in an abnormal port replacement configuration object. In implementation, for abnormal port types marked as suspicious in the abnormal port determination object (such as critical exceptions like EXC_BREAKPOINT), task_swap_exception_ports is called to perform port switching: the abnormal ports identified as suspicious are replaced with application-defined dummy ports or left empty, and the replaced port configuration result is encapsulated to obtain the abnormal port replacement configuration object for subsequent verification and status output.

[0037] Finally, the abnormal port replacement configuration object is used to trigger a breakpoint exception in a test scenario, and the signal receiving port is compared to generate an abnormal port verification status object. A test scenario for triggering a breakpoint exception can be constructed, causing the debugger to attempt to set a breakpoint, thereby generating an abnormal signal corresponding to EXC_BREAKPOINT. Then, based on the abnormal port replacement configuration object, it is compared whether the actual receiving port of the abnormal signal falls into the application-preempted port (not the debugger port). If the abnormal signal is sent to the application-replaced port (including a dummy port or a null port) and the debugger cannot capture the breakpoint, the result is written to the abnormal port verification status object to indicate that the port replacement configuration has taken effect and can be used for risk assessment and state machine driving in subsequent processes.

[0038] In step S104, the process characteristics in the kernel-mode runtime environment state object are aggregated and analyzed based on the abnormal port verification state object, and a runtime protection state machine is constructed. The flag information obtained from the system call channel, the process list characteristics, and the judgment results obtained from the abnormal port verification are summarized to obtain an environment feature set; then, the environment feature set is evaluated according to preset comprehensive evaluation rules, and the runtime protection state machine is driven to output a state, thereby obtaining the application runtime protection state object.

[0039] In one embodiment, step S104 includes: Based on the abnormal port verification status object and the kernel-mode runtime environment status object, the flag information and the abnormal judgment results are summarized to obtain the environment feature set object. A comprehensive environmental feature assessment is performed on the aforementioned set of environmental features to obtain a safety assessment result object. The security assessment result object is used to drive the operation protection state machine, and protection measures are selected and configured according to the security level in the security assessment result object to obtain the operation protection strategy object. The target application's data access is constrained by the runtime protection policy object, while abnormal data is recorded and the application runtime protection status object is output.

[0040] In this embodiment, step S104 is used to perform a fusion evaluation of the kernel-mode observable debugging flags, process list features and abnormal port determination results after the abnormal port verification is completed, and drive the running protection state machine to output the application running protection state object accordingly, so as to realize the graded response and strategic handling of runtime risks.

[0041] Specifically, based on the abnormal port verification status object and the kernel-mode runtime environment status object, the flag information and abnormal judgment results are summarized to obtain an environment feature set object. In implementation, the process status flag information and process list features obtained through csops and sysctl in step S102 can be aggregated together with the abnormal port judgment results in step S103 to obtain a unified environment feature set. The environment feature set may include at least: the presence of the CS_DEBUGGED flag, whether P_TRACED is set, whether typical debugging / hook tool processes are found, and whether suspicious abnormal port configurations exist. These features are then written into the environment feature set object as structured fields.

[0042] After obtaining the environmental feature set object, a comprehensive environmental feature assessment is performed on the environmental feature set object to obtain a security assessment result object. In implementation, the environmental feature set can be comprehensively assessed according to preset rules or scoring models to output a security level, and the security level and its judgment basis can be encapsulated into a security assessment result object; for example, the environment can be divided into multiple security levels from level 0 to level 3, where level 0 indicates a normal environment, level 1 indicates a slight risk (such as only P_TRACED is set but no abnormal ports), level 2 indicates a moderate risk (suspicious ports exist but no typical tool processes are found), and level 3 indicates a high risk (suspicious ports and typical tool processes / CS_DEBUGGED, etc., appear simultaneously).

[0043] Furthermore, the security assessment result object is used to drive the operational protection state machine. Simultaneously, protection measures are selected and configured based on the security level in the security assessment result object to obtain an operational protection policy object. In implementation, the operational protection state machine can be driven to switch between normal, observation, and protection states based on the security assessment result object. When the state machine switches to the protection state or a higher-level protection state, a simple exit method is not used. Instead, one or more protection measures are selected and configured according to the security level to form an operational protection policy object. These protection measures may include, but are not limited to: implementing sensitive function restriction policies for high-risk operations; protecting or clearing long-term resident keys / tokens / sensitive caches in memory and switching them to temporary session keys or server-side encryption; and coupling environmental characteristics with business logic to introduce Context Factors to participate in critical operations (e.g., AES key = original key ^ Context Factor), thereby ensuring an executable association between the operational policy and environmental characteristics.

[0044] Finally, the runtime protection policy object is used to constrain the data access of the target application, while recording abnormal data and outputting an application runtime protection state object. In implementation, the runtime protection policy object can be distributed to the target application's critical data access and critical business paths to impose policy constraints on sensitive data reading, decryption, signing, and other processes. Upon detecting a serious abnormal event, the abnormal data is written to the local log or reported to the security backend for subsequent risk control analysis and account handling, thereby outputting an application runtime protection state object corresponding to the current state machine state.

[0045] In one embodiment, the step of performing a comprehensive environmental feature assessment on the set of environmental features to obtain a safety assessment result object includes: Based on the environmental feature set object, risk scores are calculated for each environmental feature according to a preset scoring model to obtain an environmental risk score set. The environmental risk score set is compared with a preset threshold to determine the safety level identifier and obtain the safety level identifier object; The environment is divided into multiple security levels using the security level identifier object, resulting in a security level definition object; The security level definition object is processed by level arrangement, and the security assessment result object is output.

[0046] In this embodiment, the environmental feature set object may include at least the following environmental feature fields: presence of the CS_DEBUGGED flag, whether P_TRACED is set, whether a typical debugging / Hook tool process is found, and whether a suspicious abnormal port configuration exists. These fields serve as input for subsequent scoring and grading. Specifically, based on the environmental feature set object, a risk score is calculated for each environmental feature according to a preset scoring model to obtain an environmental risk score set. In implementation, each environmental feature in the environmental feature set object can be mapped to a scoring item, and the corresponding risk score value can be calculated according to the preset scoring model. For example, "CS_DEBUGGED flag present," "P_TRACED set," "typical tool process hit," and "suspicious abnormal port configuration hit" can be treated as independent scoring items, and the risk score for each scoring item can be output. The risk score for each scoring item can be associated and encapsulated with its triggering basis (corresponding environmental feature field value or hit record) to form an environmental risk score set for subsequent threshold comparison and grade determination.

[0047] After obtaining the environmental risk score set, the set is compared with a preset threshold to determine the safety level identifier, thus obtaining a safety level identifier object. The environmental risk score set can be compared and judged according to a preset threshold system. This comparison and judgment can be performed on a single score to determine the threshold hit, or on a range judgment for a summary score. When one or more scores reach the corresponding threshold condition, a corresponding safety level identifier is generated, and the determination path of the safety level identifier (including the triggered threshold condition, the triggered score item, and its score value) is recorded in the safety level identifier object to ensure consistency and traceability between the level determination result and the input features.

[0048] Furthermore, the environment is divided into multiple security levels using the security level identifier object, resulting in a security level definition object. In implementation, the security levels can be divided into at least four levels, and the definition conditions and exemplary combinations of each security level are written into the security level definition object; for example: Level 0 corresponds to "normal environment"; Level 1 corresponds to "minor risk (e.g., only P_TRACED is set but no abnormal ports)"; Level 2 corresponds to "moderate risk (suspicious ports exist, but no typical tool processes are found)"; Level 3 corresponds to "high risk (suspicious ports + typical tool processes / CS_DEBUGGED, etc.)". Here, "suspicious ports", "typical tool processes", "CS_DEBUGGED", and "P_TRACED" are all key judgment elements in the level definition object, ensuring a one-to-one correspondence between the multiple security levels and the fields in the environment feature set object.

[0049] Finally, the safety level definition object is processed by level arrangement to output a safety assessment result object. The safety level definition object and the safety level identifier object can be combined and arranged: on the one hand, the currently determined safety level identifier is bound to its corresponding level definition entry; on the other hand, the scoring items, triggering criteria, and hit records related to the safety level in the environmental risk scoring set are summarized and arranged, thus forming a structured output of safety level + level definition + scoring details + judgment criteria in the safety assessment result object, which serves as the driving input for the subsequent operation of the protection state machine.

[0050] In one embodiment, the step of selecting and configuring protection measures based on the security level in the security assessment result object to obtain an operational protection policy object includes: Determine the security level and identify the types of protection measures to be enabled, thus obtaining the protection measure type selection object; By using the protection measure type selection object, high-risk operations of the target application are identified and additional verification or disabling policies are configured to obtain a high-risk operation restriction configuration object; By using the protection measure type selection object, the key and sensitive buffer of the target application are cleaned and replaced with encrypted storage to obtain a sensitive data protection configuration object; Using the protection measure type selection object, environmental factors are injected into the target application during business operations, and a target key is generated by bitwise XOR, thus obtaining a target key configuration object; By integrating the high-risk operation restriction configuration object, the sensitive data protection configuration object, and the target key configuration object, a runtime protection policy object is obtained.

[0051] In this embodiment, the security level in the security assessment result object is first determined, and the types of protection measures to be enabled are identified, resulting in a protection measure type selection object. The protection measure type selection object can record: the current security level identifier, the set of protection measure types associated with that security level, the enabling conditions and priorities of each protection measure, and the policy loading entry associated with the target application. The set of protection measure types can include at least three categories: restricting sensitive functions, protecting / cleaning sensitive data, and coupling environmental characteristics with business logic. It allows the same security level to enable at least one or more of these categories to meet the policy combination requirement of "adopting one or more of the following protection measures".

[0052] After obtaining the protection measure type selection object, the high-risk operations of the target application are identified using the protection measure type selection object, and additional verification or disabling policies are configured to obtain a high-risk operation restriction configuration object. Operations defined as high-risk operations are identified in the function list and call path of the target application, and these are bound to restriction rules. For example, operations such as "key export, payment, risk control policy distribution, and debugging information printing" are marked as high-risk operations, and restriction policies of "adding additional verification" or "directly disabling" are configured for each operation. Simultaneously, the triggering conditions (corresponding to security level or state machine state), interception location (corresponding to interface entry point or key call point), and policy parameters of the restriction policies are recorded, thereby forming a high-risk operation restriction configuration object.

[0053] Furthermore, by using the protection measure type selection object to clean up the key and sensitive buffer of the target application and replace them with encrypted storage, a sensitive data protection configuration object is obtained. Based on the sensitive data policy enabled in the protection measure type selection object, long-term resident keys, tokens, or sensitive caches in the target application's runtime memory can be cleared, and sensitive data to be used subsequently can be switched to temporary session keys or server-side encryption methods. Simultaneously, important data structures can be changed from plaintext to a form that is only generated and used in a trusted environment, and the cleanup scope, replacement method, data structure conversion rules, and corresponding security level conditions are recorded in the sensitive data protection configuration object.

[0054] Furthermore, by utilizing the protection measure type selection object, an environment factor is injected into the target application during business operations, and a target key is generated by bitwise XOR, resulting in a target key configuration object. In implementation, the Context Factor can be mixed into the operation process as an environment factor in critical business logic (e.g., decrypting user data, generating network request signatures), and the source, loading location, and participation rules of the environment factor are defined in the target key configuration object. Specifically, the environment factor can be configured according to the security level. In a secure environment, the protection factor can take the correct value to participate in the operation, while in a high-risk environment, the protection factor can be set to an incorrect value to participate in the operation, thereby generating different keys or intermediate values ​​for the same business operation path under different security levels. As an example, the target key can be generated by bitwise XOR, satisfying: AES key = original key ^ Context Factor, and this XOR rule, participating fields, and key derivation timing are written into the target key configuration object.

[0055] Finally, the high-risk operation restriction configuration object, sensitive data protection configuration object, and target key configuration object are integrated to obtain the runtime protection policy object. During implementation, the three types of configuration objects can be encapsulated according to a unified policy structure to obtain a runtime protection policy object containing a "set of protection measure types - set of policy parameters - set of trigger conditions - set of loading entry points," and the relationships between the configuration objects can be established within it: for example, the sensitive data cleanup process can be triggered only when the high-risk operation restriction policy is enabled, or the target key derivation rule can be bound to a specified critical computation entry point when the business logic coupling policy is enabled, thereby enabling the runtime protection policy object to be directly loaded and executed by the runtime protection state machine.

[0056] In summary, compared with existing technologies, this application establishes a kernel-level protection environment during the application loading phase, constructs a direct system call channel for the Mach kernel, performs verification of abnormal ports and necessary port handling, and aggregates and evaluates multi-dimensional environment features through a running protection state machine. This enables the identification and handling of Hook-based dynamic injection behavior and Mach abnormal port takeover debugging behavior, thereby improving the integrity and reliability of runtime protection.

[0057] The detection and judgment path of this application obtains the runtime environment status by directly interacting with the kernel, and combines the key detection and control logic with the system call process, making it difficult for attackers to block or forge the detection link by simply using general user-mode hooking methods; at the same time, the relevant detection logic can be distributed and integrated with the program execution path as needed, thereby increasing the difficulty of resisting binary tampering and bypass.

[0058] This application classifies environmental risks into different security levels by running a protection state machine, and selects and configures differentiated protection measures according to the security level, thereby avoiding the use of a single "detect and exit" approach. In a lower-risk environment, it can maintain the basic availability of the application, while in a higher-risk environment, it can implement stricter constraints and protections on sensitive operations and sensitive data. Furthermore, by optionally using a strategy that couples environmental characteristics with business logic, attackers are required to simultaneously restore the environmental detection link and the critical business operation relationship, further improving the protection strength of core business assets.

[0059] Furthermore, this application relies on the public interfaces and system call mechanisms provided by the Mach kernel to achieve runtime protection, without depending on private interfaces or specific framework environments. It has good versatility and portability, making it easy to integrate into different types of applications and adapt to different versions of macOS and iOS runtime environments.

[0060] Combination Figure 2 As shown, Figure 2A schematic block diagram of an application protection device based on the Mach kernel provided in this embodiment of the invention. The application protection device 200 based on the Mach kernel includes: The parameter acquisition unit 201 is used to acquire the startup information of the target application and initialize the protection module that interacts with the Mach kernel during the loading phase of the target application to establish the running parameter configuration and obtain the kernel-level protection environment object. Channel invocation unit 202 is used to establish a system invocation channel for the Mach kernel using the kernel-level protection environment object, and to obtain a kernel-mode runtime environment state object; The port comparison unit 203 is used to call the abnormal port of the Mach kernel using the kernel-mode runtime environment status object, and compare the configuration of the abnormal port with the preset abnormal port baseline to generate an abnormal port verification status object. The program protection unit 204 is used to perform aggregate analysis on the process characteristics in the kernel-mode runtime environment state object based on the abnormal port verification state object, construct a runtime protection state machine, and output the application runtime protection state object.

[0061] In this embodiment, the parameter acquisition unit 201 acquires the startup information of the target application and initializes the protection module that interacts with the Mach kernel during the loading phase of the target application to establish the running parameter configuration and obtain a kernel-level protection environment object; the channel call unit 202 uses the kernel-level protection environment object to establish a system call channel for the Mach kernel and obtains a kernel-mode running environment state object; the port comparison unit 203 uses the kernel-mode running environment state object to call the abnormal port of the Mach kernel and compares the configuration of the abnormal port with a preset abnormal port baseline to generate an abnormal port verification state object; the program protection unit 204 performs aggregate analysis on the process characteristics in the kernel-mode running environment state object based on the abnormal port verification state object, constructs a running protection state machine, and outputs the application running protection state object.

[0062] In one embodiment, the parameter acquisition unit 201 is specifically used for: During the application loading phase, the loading entry point is determined based on the startup information, and the configuration of the protection module is invoked to obtain the protection module invocation configuration object; The protection module calls a configuration object to trigger the protection module to generate running parameters before the preset main function is executed, thus obtaining the protection module running parameters; The kernel interface, policy parameters, and reserved resources are initialized in the constructor based on the operating parameters of the protection module to obtain a kernel-level protection environment object.

[0063] In one embodiment, the channel calling unit 202 is specifically used for: Based on the kernel-level protection environment object, an inline instruction sequence for triggering system calls is defined, and a system call template object is obtained; The process flag is obtained from the Mach kernel using the system call template object, and the first kernel process status detection result is obtained. Based on the first kernel process status detection result, process control information is obtained to obtain the second kernel process status detection result; The kernel process list is traversed using the results of the second kernel process status detection, and aggregated and analyzed according to the characteristics of debugging tools to obtain the kernel-mode runtime environment state object.

[0064] In one embodiment, the port comparison unit 203 is specifically used for: Based on the kernel-mode runtime environment status object, query the abnormal port to obtain the abnormal port configuration object; Based on the abnormal port configuration object, the target application is compared with the whitelist and suspicious abnormal types are marked to obtain the abnormal port determination object; The abnormal port determination object is used to call the port switching interface to replace the suspicious abnormal port, thereby obtaining the abnormal port replacement configuration object; The abnormal port replacement configuration object triggers a breakpoint exception in the test scenario, and the signal receiving port is compared to generate an abnormal port verification status object.

[0065] In one embodiment, the program protection unit 204 is specifically used for: Based on the abnormal port verification status object and the kernel-mode runtime environment status object, the flag information and the abnormal judgment results are summarized to obtain the environment feature set object. A comprehensive environmental feature assessment is performed on the aforementioned set of environmental features to obtain a safety assessment result object. The security assessment result object is used to drive the operation protection state machine, and protection measures are selected and configured according to the security level in the security assessment result object to obtain the operation protection strategy object. The target application's data access is constrained by the runtime protection policy object, while abnormal data is recorded and the application runtime protection status object is output.

[0066] In one embodiment, the program protection unit 204 is further specifically used for: Based on the environmental feature set object, risk scores are calculated for each environmental feature according to a preset scoring model to obtain an environmental risk score set. The environmental risk score set is compared with a preset threshold to determine the safety level identifier and obtain the safety level identifier object; The environment is divided into multiple security levels using the security level identifier object, resulting in a security level definition object; The security level definition object is processed by level arrangement, and the security assessment result object is output.

[0067] In one embodiment, the program protection unit 204 is further specifically used for: Determine the security level and identify the types of protection measures to be enabled, thus obtaining the protection measure type selection object; By using the protection measure type selection object, high-risk operations of the target application are identified and additional verification or disabling policies are configured to obtain a high-risk operation restriction configuration object; By using the protection measure type selection object, the key and sensitive buffer of the target application are cleaned and replaced with encrypted storage to obtain a sensitive data protection configuration object; Using the protection measure type selection object, environmental factors are injected into the target application during business operations, and a target key is generated by bitwise XOR, thus obtaining a target key configuration object; By integrating the high-risk operation restriction configuration object, the sensitive data protection configuration object, and the target key configuration object, a runtime protection policy object is obtained.

[0068] Since the embodiments of the apparatus and the embodiments of the method correspond to each other, please refer to the description of the embodiments of the method for the embodiments of the apparatus, which will not be repeated here.

[0069] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed, can perform the steps provided in the above embodiments. The storage medium may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0070] This invention also provides a computer device, which may include a memory and a processor. The memory stores a computer program, and when the processor calls the computer program in the memory, it can implement the steps provided in the above embodiments. Of course, the computer device may also include various network interfaces, a power supply, a graphics card, etc., to utilize the graphics card's performance to operate the model, such as for inference and training.

[0071] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

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

Claims

1. A method for protecting applications based on the Mach kernel, characterized in that, include: Obtain the startup information of the target application, and initialize the protection module that interacts with the Mach kernel during the loading phase of the target application to establish the runtime parameter configuration and obtain the kernel-level protection environment object; A system call channel to the Mach kernel is established using the kernel-level protection environment object to obtain the kernel-mode runtime environment state object; The kernel-mode runtime environment state object is used to call the abnormal port of the Mach kernel, and the configuration of the abnormal port is compared with the preset abnormal port baseline to generate an abnormal port verification state object. Based on the abnormal port verification status object, the process characteristics in the kernel-mode runtime environment status object are aggregated and analyzed, and a runtime protection state machine is constructed to output the application runtime protection status object. The step of establishing a system call channel to the Mach kernel using the kernel-level protection environment object to obtain a kernel-mode runtime environment state object includes: defining an inline instruction sequence for triggering system calls based on the kernel-level protection environment object to obtain a system call template object; obtaining process flags from the Mach kernel using the system call template object to obtain a first kernel process state detection result; obtaining process control information based on the first kernel process state detection result to obtain a second kernel process state detection result; and traversing the kernel process list and aggregating and analyzing it according to debugging tool characteristics using the second kernel process state detection result to obtain a kernel-mode runtime environment state object. The process feature aggregation analysis based on the abnormal port verification status object and the process feature aggregation analysis in the kernel-mode runtime environment status object, and the construction of a runtime protection state machine, outputting an application runtime protection state object, includes: summarizing flag information and abnormal judgment results based on the abnormal port verification status object and the kernel-mode runtime environment status object to obtain an environment feature set object; performing a comprehensive environmental feature evaluation on the environment feature set object to obtain a security evaluation result object; using the security evaluation result object to drive the runtime protection state machine, and simultaneously selecting and configuring protection measures according to the security level in the security evaluation result object to obtain a runtime protection policy object; using the runtime protection policy object to constrain the data access of the target application, while recording abnormal data, and outputting an application runtime protection state object.

2. The application protection method based on the Mach kernel according to claim 1, characterized in that, The process of obtaining the startup information of the target application and initializing the protection module that interacts with the Mach kernel during the target application loading phase to establish runtime parameter configuration and obtain a kernel-level protection environment object includes: During the application loading phase, the loading entry point is determined based on the startup information, and the configuration of the protection module is invoked to obtain the protection module invocation configuration object; The protection module calls a configuration object to trigger the protection module to generate running parameters before the preset main function is executed, thus obtaining the protection module running parameters; The kernel interface, policy parameters, and reserved resources are initialized in the constructor based on the operating parameters of the protection module to obtain a kernel-level protection environment object.

3. The application protection method based on the Mach kernel according to claim 1, characterized in that, The step of using the kernel-mode runtime environment state object to call the abnormal port of the Mach kernel, and comparing the configuration of the abnormal port with a preset abnormal port baseline to generate an abnormal port verification state object includes: Based on the kernel-mode runtime environment status object, query the abnormal port to obtain the abnormal port configuration object; Based on the abnormal port configuration object, the target application is compared with the whitelist and suspicious abnormal types are marked to obtain the abnormal port determination object; The abnormal port determination object is used to call the port switching interface to replace the suspicious abnormal port, thereby obtaining the abnormal port replacement configuration object; The abnormal port replacement configuration object triggers a breakpoint exception in the test scenario, and the signal receiving port is compared to generate an abnormal port verification status object.

4. The application protection method based on the Mach kernel according to claim 1, characterized in that, The process of performing a comprehensive environmental feature assessment on the set of environmental features to obtain a safety assessment result object includes: Based on the environmental feature set object, risk scores are calculated for each environmental feature according to a preset scoring model to obtain an environmental risk score set. The environmental risk score set is compared with a preset threshold to determine the safety level identifier and obtain the safety level identifier object. The environment is divided into multiple security levels using the security level identifier object, resulting in a security level definition object; The security level definition object is processed by level arrangement, and the security assessment result object is output.

5. The application protection method based on the Mach kernel according to claim 1, characterized in that, The step of selecting and configuring protection measures based on the security level in the security assessment result object to obtain the running protection strategy object includes: Determine the security level and identify the types of protection measures to be enabled, thus obtaining the protection measure type selection object; By using the protection measure type selection object, high-risk operations of the target application are identified and additional verification or disabling policies are configured to obtain a high-risk operation restriction configuration object; By using the protection measure type selection object, the key and sensitive buffer of the target application are cleaned and replaced with encrypted storage to obtain a sensitive data protection configuration object; Using the protection measure type selection object, environmental factors are injected into the target application during business operations, and a target key is generated by bitwise XOR, thus obtaining a target key configuration object; By integrating the high-risk operation restriction configuration object, the sensitive data protection configuration object, and the target key configuration object, a runtime protection policy object is obtained.

6. An application protection device based on the Mach kernel, characterized in that, include: The parameter acquisition unit is used to acquire the startup information of the target application and initialize the protection module that interacts with the Mach kernel during the loading phase of the target application to establish the running parameter configuration and obtain the kernel-level protection environment object. The channel invocation unit is used to establish a system invocation channel for the Mach kernel using the kernel-level protection environment object, and to obtain the kernel-mode runtime environment state object. The port comparison unit is used to call the abnormal port of the Mach kernel using the kernel-mode runtime environment status object, and compare the configuration of the abnormal port with the preset abnormal port baseline to generate an abnormal port verification status object. The program protection unit is used to aggregate and analyze the process characteristics in the kernel-mode runtime environment state object based on the abnormal port verification state object, construct a runtime protection state machine, and output the application runtime protection state object. The channel invocation unit is specifically used for: defining an inline instruction sequence for triggering system calls based on the kernel-level protection environment object to obtain a system call template object; obtaining a process flag from the Mach kernel using the system call template object to obtain a first kernel process status detection result; obtaining process control information based on the first kernel process status detection result to obtain a second kernel process status detection result; and traversing the kernel process list using the second kernel process status detection result and aggregating and analyzing it according to debugging tool characteristics to obtain a kernel-mode runtime environment status object. The program protection unit is specifically used to: based on the abnormal port verification status object and the kernel-mode runtime environment status object, summarize the flag information and the abnormal judgment result respectively to obtain an environment feature set object; A comprehensive environmental feature assessment is performed on the environmental feature set object to obtain a safety assessment result object; the safety assessment result object is used to drive the operation protection state machine, and protection measures are selected and configured according to the safety level in the safety assessment result object to obtain an operation protection strategy object; The target application's data access is constrained by the runtime protection policy object, while abnormal data is recorded and the application runtime protection status object is output.

7. A computer device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the Mach kernel-based application protection method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the Mach kernel-based application protection method as described in any one of claims 1 to 5.

Images