A hardware-assisted cross-application sandbox penetration protection system and method

Abstract

The application provides a hardware-assisted cross-application sandbox penetration protection system and method, and belongs to the technical field of mobile terminal security. The method comprises the following steps: S1, collecting a memory access sequence of a process in real time through a memory label extension module, and collecting a permission combination and inter-process communication data through a kernel interface; S2, calculating a deviation value of the permission combination from a white list based on a cosine similarity, and quantifying a state transition abnormal probability of the memory access sequence by using a Markov chain algorithm; S3, performing feature fusion on the output result of S2 and the inter-process communication data, and inputting the result into a long short-term memory network model to generate a comprehensive risk score; when the score exceeds a threshold value, triggering a dynamic policy arbitration module to perform a hierarchical response action. The application has higher recognition rate and interception rate.

Description

Technical Field

[0001] This invention belongs to the field of mobile terminal security technology, and in particular relates to a hardware-assisted cross-application sandbox penetration protection system and method. Background Technology

[0002] In recent years, cybersecurity issues have become increasingly prominent, with hacker intrusions and cyberattacks on the rise. A full sandbox is an execution environment that restricts program behavior according to security policies. However, traditional sandbox mechanisms rely on Linux kernel namespace isolation, which cannot defend against covert channel attacks based on legitimate system services (such as Binder IPC). Summary of the Invention

[0003] To address the aforementioned technical problems, this invention proposes a hardware-assisted cross-application sandbox penetration protection system and method.

[0004] The first aspect of this invention discloses a hardware-assisted cross-application sandbox penetration protection method, the method comprising:

[0005] Step S1: Collect the memory access sequence of the process in real time through the memory tag extension module, and collect permission combination and inter-process communication data through the kernel interface;

[0006] Step S2: Calculate the deviation between the permission combination and the whitelist based on cosine similarity, and use the Markov chain algorithm to quantify the abnormal probability of state transition in the memory access sequence.

[0007] Step S3: The deviation value, the probability of abnormal state transition, and the inter-process communication data are fused together and input into the long short-term memory network model to generate a comprehensive risk score; when the score exceeds the threshold, the dynamic policy arbitration module is triggered to execute a graded response action.

[0008] Optionally, in step S1, the memory access sequence includes: timestamp, process ID, memory address, access type, and tag.

[0009] Optionally, in step S1, the permission combination data is obtained through one of the following methods:

[0010] Access control lists provided by the kernel-level access control module;

[0011] System call tracing interface captures open, read, or setuid operations; or

[0012] The resource permission monitoring module provides records of system resource permission requests.

[0013] Optionally, in step S1, the inter-process communication data includes the frequency of inter-process communication, the target object, and the temporal variation characteristics of the data volume.

[0014] Optionally, in step S3, the graded response action includes:

[0015] When the risk level is at Level 1: Log and issue an alert;

[0016] When at the second risk level: restrict process privileges or isolate memory regions;

[0017] When the risk level is 3: Terminate the process and block related system calls;

[0018] Among them, the first risk level is lower than the second risk level, and the second risk level is lower than the third risk level.

[0019] Optionally, step S1 may further include: injecting random noise into the collected inter-process communication data.

[0020] A second aspect of this invention discloses a hardware-assisted cross-application sandbox penetration protection system, the system comprising:

[0021] The first processing module is configured to collect the memory access sequence of the process in real time through the memory tag extension module, and collect permission combinations and inter-process communication data through the kernel interface.

[0022] The second processing module is configured to calculate the deviation between the permission combination and the whitelist based on cosine similarity, and to quantify the abnormal probability of state transition of the memory access sequence using the Markov chain algorithm.

[0023] The third processing module is configured to perform feature fusion of deviation values, state transition anomaly probabilities, and inter-process communication data, and input them into a long short-term memory network model to generate a comprehensive risk score.

[0024] The fourth processing module is configured to dynamically trigger the dynamic strategy arbitration module to execute tiered response actions based on the comprehensive risk score.

[0025] A third aspect of this invention discloses an electronic device. The electronic device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of the hardware-assisted cross-application sandbox penetration protection method described in the first aspect of this invention.

[0026] A fourth aspect of this invention discloses a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the hardware-assisted cross-application sandbox penetration protection method described in the first aspect of this invention.

[0027] In summary, the solution proposed in this invention has the following technical advantages: the cross-application protection system combining hardware security modules and dynamic behavior analysis has a higher recognition and interception rate. It provides particularly better protection for applications with high security requirements (such as financial applications). Specifically:

[0028] Hardware and software integration: The Memory Tag Extension Module (MTE) is a hardware monitoring component, while the Long Short-Term Memory (LSTM) network model deployed in the Trusted Execution Environment (TEE) is a software intelligent analysis component. The collaboration between the two can improve security.

[0029] Not afraid of system hacking: Even if the system is controlled by malicious programs, TEE can independently detect and block them because it is independent. Attached Figure Description

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

[0031] Figure 1 This is a flowchart of a hardware-assisted cross-application sandbox penetration protection method according to an embodiment of the present invention;

[0032] Figure 2 This is a structural diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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 embodiments of the present invention, and not all embodiments. 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.

[0034] The first aspect of this invention discloses a hardware-assisted cross-application sandbox penetration protection method, which achieves boundary hardening through a three-layer protection architecture. Please refer to... Figure 1 It combines a multi-layered security protection system at both the software and hardware levels, aiming to detect and block malicious attacks, especially threats to inter-process communication (IPC) and memory security, through the collaborative work of the user layer, kernel layer, and hardware layer.

[0035] The method includes:

[0036] S1 collects the memory access sequence of processes in real time through the Memory Tag Extension Module (MTE) and collects permission combinations and inter-process communication data through the kernel interface;

[0037] Optionally, the memory tag extension module is a memory controller with the following functions:

[0038] Tag assignment: Assign security tags to memory to ensure that only authorized processes can access specific memory regions.

[0039] Sensors that monitor memory access behavior: provide recorded data.

[0040] Hardware anomaly triggering: The access permissions of the initiating process are verified through the MTE memory tag. If the tag does not match, a hardware anomaly is triggered. For example, when illegal memory access is detected (such as buffer overflow or UAF vulnerability), a hardware-level anomaly is triggered directly to terminate the attack.

[0041] To enhance the ability to trigger hardware anomalies, the application sandbox key is dynamically bound to the device PUF response value and geolocation hash. The key update equation is as follows:

[0042] K_new = HMAC(K_old, PUF⊕Geohash(GPS));

[0043] Where K_new is the updated key; HMAC is a hash-based pseudo-random function; K_old is the key before the update; PUF is the Physically Unclonable Function response value; ⊕ is the XOR symbol; Geohash(GPS) is the hash value of the geocoded string, which is the Geohash algorithm (e.g., 12-character precision) output of the device's current GPS coordinates (latitude and longitude), and then compressed by cryptographic hash (e.g., SHA-256).

[0044] In step S1, the memory access sequence includes: timestamp, process ID, memory address, access type, and tag.

[0045] Specifically, the tag records accessed through the MTE memory output information such as time, process ID, memory address, type, tag, and module. This information is then collected by the TEE processes into feature vectors for use in LSTM time series analysis and Markov chain state determination.

[0046] Optionally, in step S1, the permission combination data is obtained in the following way:

[0047] Access control lists provided by the kernel-level access control module;

[0048] System call tracing interface captures open, read, or setuid operations; or

[0049] The resource permission monitoring module provides records of system resource permission requests.

[0050] Specifically, permission combination data can be obtained through kernel-level modules such as DAC and MAC. Additionally, permission combination data can be obtained through system calls / API tracing, such as calls to open, read, write, chmod, and setuid. This also includes access permissions for system resources, such as the camera and microphone, and whether access is granted to high-level permissions only to core system apps. For example, if an app attempts to read data under / system / , this is considered a high-risk operation.

[0051] Optionally, in step S1, the inter-process communication data (i.e., IPC communication data) includes the frequency of inter-process communication, the target object, and the temporal variation characteristics of the data volume.

[0052] IPC communication data can be obtained through both the framework layer and the kernel layer, and information such as the number of IPC requests, the objects, and the size of the transmitted data can be output within the sliding window.

[0053] Optionally, step S1 further includes injecting random noise into the collected inter-process communication data. This step effectively disrupts the stability of adversarial examples through a three-layer defense system of noise injection, semantic verification, and kernel protection. Optionally, the noise intensity is adjusted based on parameter type and historical behavior.

[0054] S2, calculates the deviation between the permission combination and the whitelist based on cosine similarity, and uses the Markov chain algorithm to quantify the abnormal probability of state transition of memory access sequence;

[0055] Markov Chain: This algorithm is used to determine whether memory access paths conform to normal behavior and outputs quantified data. Cosine Similarity: This algorithm is used to output whether permission combinations are normal and outputs quantified data.

[0056] Markov chains and cosine similarity are used as pre-analyzers for local feature extraction, and the output data or scores are used as part of the LSTM input features. The detection methods for each risk factor are shown in Table 1.

[0057]

[0058] S3. The output of step S2 is fused with the inter-process communication data and input into the long short-term memory network model to generate a comprehensive risk score. When the score exceeds the threshold, the dynamic policy arbitration module is triggered to execute a graded response action.

[0059] Optionally, in step S3, the graded response action includes:

[0060] When the risk level is at Level 1 (low risk): Log and issue an alert;

[0061] When at the second risk level (medium risk): restrict process privileges or isolate memory regions;

[0062] When at risk level 3 (high risk): terminate the process and block related system calls.

[0063] Example of dynamic strategy effect:

[0064] Normal behavior: Open image (permissions and memory access) - process image (memory access) - save image to album (permissions + memory access + IPC communication) --> pass.

[0065] Example of abnormal behavior 1: Opening an image (permissions and memory access) - Attempting to access an illegal address not belonging to this program (memory access) - Changing the UID (permissions) --> Alarm.

[0066] The proposed solution offers the following technical advantages: The cross-application protection system combining hardware security modules and dynamic behavior analysis achieves higher recognition and interception rates. It provides particularly effective protection for applications with high security requirements (such as financial applications).

[0067] A second aspect of this invention discloses a hardware-assisted cross-application sandbox penetration protection system, the system comprising:

[0068] The first processing module is configured to collect the memory access sequence of the process in real time through the memory tag extension module, and collect permission combinations and inter-process communication data through the kernel interface.

[0069] Optionally, the memory tag extension module is a memory controller with the following functions:

[0070] Tag assignment: Assign security tags to memory to ensure that only authorized processes can access specific memory regions.

[0071] Hardware anomaly triggering: The access permissions of the initiating process are verified through the MTE memory tag. If the tag does not match, a hardware anomaly is triggered. For example, when illegal memory access is detected (such as buffer overflow or UAF vulnerability), a hardware-level anomaly is triggered directly to terminate the attack.

[0072] To enhance the ability to trigger hardware anomalies, the application sandbox key is dynamically bound to the device PUF response value and geolocation hash. The key update equation is as follows:

[0073] K_new = HMAC(K_old, PUF⊕Geohash(GPS)).

[0074] The memory access sequence includes: timestamp, process ID, memory address, access type, and tag.

[0075] Specifically, the tag records accessed through the MTE memory output information such as time, process ID, memory address, type, tag, and module. This information is then collected by the TEE processes into feature vectors for use in LSTM time series analysis and Markov chain state determination.

[0076] Optionally, permission combination data can be obtained in the following ways:

[0077] Access control lists provided by the kernel-level access control module;

[0078] System call tracing interface captures open, read, or setuid operations; and

[0079] The resource permission monitoring module provides records of system resource permission requests.

[0080] Specifically, permission combination data can be obtained through kernel-level modules such as DAC and MAC. Additionally, permission combination data can be obtained through system calls / API tracing, such as calls to open, read, write, chmod, and setuid. This also includes access permissions for system resources, such as the camera and microphone, and whether access is granted to high-level permissions only to core system apps. For example, if an app attempts to read data under / system / , this is considered a high-risk operation.

[0081] Optionally, inter-process communication data (i.e., IPC communication data) includes the frequency of inter-process communication, the target object, and the temporal variation characteristics of data volume.

[0082] IPC communication data can be obtained through both the framework layer and the kernel layer, and information such as the number of IPC requests, the objects, and the size of the transmitted data can be output within the sliding window.

[0083] Optionally, the first processing module is further configured to inject random noise into the collected inter-process communication data. This step effectively disrupts the stability of adversarial examples through a three-layer defense system of noise injection, semantic verification, and kernel protection. Optionally, the noise intensity is adjusted based on parameter type and historical behavior.

[0084] The second processing module is configured to calculate the deviation between the permission combination and the whitelist based on cosine similarity, and to quantify the abnormal probability of state transitions in the memory access sequence using a Markov chain algorithm. Markov chain: This algorithm is used to determine whether the memory access route conforms to normal behavior and outputs quantified data. Cosine similarity: This algorithm is used to output whether the permission combination is normal and outputs quantified data.

[0085] Markov chains and cosine similarity are used as pre-analyzers for local feature extraction, and the output data or scores are used as part of the input features of the LSTM.

[0086] The third processing module is configured to perform feature fusion of the output of the second processing module and inter-process communication data, and input the result into the long short-term memory network model to generate a comprehensive risk score.

[0087] The Long Short-Term Memory (LSTM) network model is deployed in the Trusted Execution Environment (TEE) module, receiving memory access sequences, system permission combination data, and inter-process communication (IPC) data to perform multi-dimensional risk assessment.

[0088] The fourth processing module is configured to dynamically trigger the dynamic strategy arbitration module to execute tiered response actions based on the comprehensive risk score.

[0089] Tiered response actions include:

[0090] When the risk level is at Level 1: Log and issue an alert;

[0091] When at the second risk level: restrict process privileges or isolate memory regions;

[0092] When at risk level 3: Terminate the process and block related system calls.

[0093] A third aspect of this invention discloses an electronic device. The electronic device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of the hardware-assisted cross-application sandbox penetration protection method described in the first aspect of this invention.

[0094] Figure 2 This is a structural diagram of an electronic device according to an embodiment of the present invention, such as... Figure 2 As shown, the electronic device includes a processor, memory, communication interface, display screen, and input device connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, Near Field Communication (NFC), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input device can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the device's casing, or an external keyboard, touchpad, or mouse.

[0095] Those skilled in the art will understand that Figure 2The structure shown is merely a structural diagram of the part related to the technical solution of this disclosure and does not constitute a limitation on the electronic device to which the solution of this application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0096] A fourth aspect of this invention discloses a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the hardware-assisted cross-application sandbox penetration protection method described in the first aspect of this invention.

[0097] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein, and such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A hardware-assisted cross-application sandbox penetration protection method, characterized in that, The method includes: Step S1: Collect the memory access sequence of the process in real time through the memory tag extension module, and collect permission combination and inter-process communication data through the kernel interface; Step S2: Calculate the deviation between the permission combination and the whitelist based on cosine similarity, and use the Markov chain algorithm to quantify the abnormal probability of state transition in the memory access sequence. Step S3 involves fusing the deviation value, state transition anomaly probability, and inter-process communication data, and inputting this data into a Long Short-Term Memory (LSTM) network model deployed in a trusted execution environment to generate a comprehensive risk score. When the score exceeds a threshold, the dynamic policy arbitration module is triggered to execute a tiered response action. The tiered response action in step S3 includes: When the risk level is at Level 1: Log and issue an alert; When at the second risk level: restrict process privileges or isolate memory regions; When the risk level is 3: Terminate the process and block related system calls; Among them, the first risk level is lower than the second risk level, and the second risk level is lower than the third risk level.

2. The method according to claim 1, characterized in that, In step S1, the memory access sequence includes: timestamp, process ID, memory address, access type, and tag.

3. The method according to claim 1, characterized in that, In step S1, the permission combination is obtained through one of the following methods: Access control lists provided by the kernel-level access control module; System call tracing interface captures open, read, or setuid operations; or The resource permission monitoring module provides records of system resource permission requests.

4. The method according to claim 1, characterized in that, In step S1, the inter-process communication data includes the frequency of inter-process communication, the target object, and the temporal variation characteristics of the data volume.

5. The method according to any one of claims 1-4, characterized in that, Step S1 also includes injecting random noise into the collected inter-process communication data.

6. A hardware-assisted cross-application sandbox penetration protection system, characterized in that, The system includes: The first processing module is configured to collect the memory access sequence of the process in real time through the memory tag extension module, and collect permission combinations and inter-process communication data through the kernel interface. The second processing module is configured to calculate the deviation between the permission combination and the whitelist based on cosine similarity, and to quantify the abnormal probability of state transition of the memory access sequence using the Markov chain algorithm. The third processing module is configured to perform feature fusion of deviation values, state transition anomaly probabilities, and inter-process communication data, and input them into a long short-term memory network model deployed in a trusted execution environment to generate a comprehensive risk score. The fourth processing module is configured to dynamically trigger the dynamic strategy arbitration module to execute tiered response actions based on the comprehensive risk score; the tiered response actions include: When the risk level is at Level 1: Log and issue an alert; When at the second risk level: restrict process privileges or isolate memory regions; When the risk level is 3: Terminate the process and block related system calls; Among them, the first risk level is lower than the second risk level, and the second risk level is lower than the third risk level.

7. An electronic device, characterized in that, The electronic device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of the hardware-assisted cross-application sandbox penetration protection method according to 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, which, when executed by a processor, implements the steps of the hardware-assisted cross-application sandbox penetration protection method according to any one of claims 1 to 5.

Images