Method and system for integrated management and control of permissions of mobile devices and emergency response

Abstract

The application relates to a mobile device permission centralized management and emergency response integrated method and system, which comprises the following steps: generating a trusted benchmark snapshot of a target mobile device; issuing and configuring an atomized control strategy to a hardware abstraction layer of the target mobile device to obtain a configured atomized control strategy; generating software and hardware interaction behavior data based on the configured atomized control strategy; generating a real-time risk research and judgment result; executing an automatic emergency response action matching a risk level at the hardware abstraction layer according to a preset hierarchical treatment logic, so that the target mobile device enters a defense protection state; extracting an intercepted log and risk feature data generated by the target mobile device in the defense protection state, feeding back the intercepted log and risk feature data to a server to generate a strategy update package, and iteratively updating the atomized control strategy according to the strategy update package. The application can realize the permission centralized management and emergency response integration of the mobile device.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to an integrated method and system for centralized control of permissions and emergency response of mobile devices. Background Technology

[0002] With the widespread application of mobile smart terminals in enterprise offices and sensitive industries, the security management and data leakage prevention of mobile applications have become crucial aspects of information technology infrastructure development. Existing technologies typically employ application sandboxes, virtualized proxies, or general policy detection mechanisms to achieve security protection. For example, Chinese patent application CN201910794016.7 discloses a method and apparatus for monitoring mobile applications. This method encapsulates mobile applications by constructing a virtual security domain or proxy layer, achieving monitoring and statistics by intercepting application interaction behavior without modifying the operating system kernel. Another example is Chinese patent application CN202110356209.1, which proposes a security detection method, apparatus, device, and computer storage medium. This method continuously collects terminal operation data and matches it with preset security policies to detect and perform basic processing of risk events. These existing solutions, in general scenarios, achieve a certain degree of visualized monitoring and basic compliance management of mobile application behavior.

[0003] However, the aforementioned existing technologies still have significant shortcomings when facing the stringent control requirements of high-security scenarios. First, existing solutions are mostly limited to monitoring application-layer software interface calls, lacking deep integration with the underlying operating system and hardware drivers (cameras, NFC, storage, etc.), making it difficult to achieve fine-grained centralized control of permissions through a combination of software and hardware. Second, existing "auditing" and "response" mechanisms are often fragmented, focusing on post-event log accumulation and manual analysis, lacking an integrated mechanism that deeply integrates "dynamic security policy distribution" and "automated emergency response to abnormal behavior." When unauthorized app installation, sensitive image capture, or unauthorized external connections occur, existing technologies often cannot achieve millisecond-level real-time blocking and adaptive policy adjustment, resulting in the inability to promptly contain data leakage risks. Summary of the Invention

[0004] This invention addresses the technical problems existing in the prior art by providing a method and system for centralized management of permissions and emergency response of mobile devices, which can improve the integrated effect of centralized management of permissions and emergency response of mobile devices.

[0005] The technical solution of the present invention to solve the above-mentioned technical problems is as follows: This invention provides an integrated method for centralized permission management and emergency response of mobile devices, the method comprising: Obtain the hardware unique identifier and operating system kernel signature of the target mobile device, perform a hash operation to bind the hardware unique identifier and the operating system kernel signature, and generate a trusted baseline snapshot of the target mobile device. The trusted benchmark snapshot is transmitted to the server for integrity verification. Based on the verification result and the preset compliance group rules, an atomic control policy is generated. The atomic control policy is then distributed and configured to the hardware abstraction layer of the target mobile device to obtain the configured atomic control policy. The atomic control policy includes context constraints, hardware resource objects, and operation instruction dimensions. Based on the configured atomic control strategy, a two-layer monitoring mechanism is initiated to capture the operating data of the target mobile device and generate software and hardware interaction behavior data; the operating data includes application programming interface call requests at the application layer and hardware input / output requests at the driver layer. The software and hardware interaction behavior data is input into the risk arbitration module residing on the device. The software and hardware interaction behavior data is pre-executed for compliance verification in combination with the current device operating environment context, and a real-time risk assessment result is generated. In response to the real-time risk assessment result indicating a violation, an automated emergency response action matching the risk level is executed at the hardware abstraction layer according to a preset tiered handling logic. The automated emergency response action includes blocking hardware driver calls, cutting off network communication, or performing a security wipe, so that the target mobile device enters a defensive protection state. The interception logs and risk feature data generated by the target mobile device under the defense protection state are extracted, and the interception logs and risk feature data are fed back to the server to generate a policy update package. The atomic control policy is then iteratively updated according to the policy update package.

[0006] This invention also provides an integrated system for centralized permission management and emergency response of mobile devices, the system comprising: The snapshot generation module is used to obtain the hardware unique identifier and operating system kernel signature of the target mobile device, perform a hash operation on the hardware unique identifier and the operating system kernel signature, and generate a trusted baseline snapshot of the target mobile device. The strategy configuration module is used to transmit the trusted benchmark snapshot to the server for integrity verification, generate an atomic control policy based on the verification result and preset compliance group rules, and distribute and configure the atomic control policy to the hardware abstraction layer of the target mobile device to obtain the configured atomic control policy; the atomic control policy includes context constraints, hardware resource objects and operation instruction dimensions; The data generation module is used to initiate a two-layer monitoring mechanism based on the configured atomic control strategy to capture the running data of the target mobile device and generate software and hardware interaction behavior data; the running data includes application programming interface call requests at the application layer and hardware input / output requests at the driver layer. The risk assessment module is used to input the software and hardware interaction behavior data into the risk arbitration module residing on the device, and perform pre-execution compliance verification on the software and hardware interaction behavior data in combination with the current device operating environment context to generate real-time risk assessment results. The emergency response module is used to respond to the real-time risk assessment result indicating the existence of violations, and to execute automated emergency response actions at the hardware abstraction layer that match the risk level according to the preset graded handling logic; the automated emergency response actions include blocking hardware driver calls, cutting off network communication, or performing a security wipe, so that the target mobile device enters a defensive protection state; The policy update module is used to extract the interception logs and risk feature data generated by the target mobile device under the defense protection state, feed the interception logs and risk feature data back to the server to generate a policy update package, and iteratively update the atomic control policy according to the policy update package.

[0007] Furthermore, to achieve the above objectives, the present invention also proposes an electronic device, comprising: a memory for storing computer software programs; and a processor for reading and executing the computer software programs, thereby realizing the integrated method for centralized control of permissions and emergency response of a mobile device as described above.

[0008] Furthermore, to achieve the above objectives, the present invention also proposes a non-transitory computer-readable storage medium storing a computer software program, which, when executed by a processor, implements an integrated method for centralized permission management and emergency response of a mobile device as described above.

[0009] In summary, the present invention has the following advantages: (1) The present invention constructs a management middleware based on the Hardware Abstraction Layer (HAL). By sinking the control granularity from the software interface layer to the operating system kernel mode and hardware driver layer, the system can directly hook the I / O requests of physical devices, ensuring that even if malicious applications bypass the upper application sandbox by means of packing or obfuscation, they still cannot call the camera, NFC or storage module without authorization, thereby achieving deep protection of "software and hardware combination".

[0010] (2) This invention introduces an end-side risk arbitration and pre-execution blocking mechanism. By deploying a policy engine locally on the terminal and performing millisecond-level analysis before instruction execution, this method can directly trigger tiered emergency responses (such as network isolation, hardware circuit breaking, or data self-destruction) without relying on real-time network connections. This effectively solves the pain point of existing technologies being unable to contain sudden data leakage risks in offline or weak network environments, achieving a qualitative change from "passive post-event auditing" to "proactive real-time defense". Attached Figure Description

[0011] Figure 1 A flowchart illustrating an integrated method for centralized permission management and emergency response of mobile devices provided by this invention; Figure 2 A schematic diagram of the structure of an integrated system for centralized permission management and emergency response of a mobile device provided by the present invention; Figure 3 A schematic diagram of the hardware structure of a possible electronic device provided by the present invention; Figure 4 This is a schematic diagram of the hardware structure of a possible computer-readable storage medium provided by 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 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.

[0013] In the description of this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0014] In the description of this invention, the term "for example" is used to mean "used as an example, illustration, or description." Any embodiment described as "for example" in this invention is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use the invention. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that the invention can be made without using these specific details. In other instances, well-known structures and processes will not be described in detail to avoid obscuring the description of the invention with unnecessary detail. Therefore, the invention is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed herein.

[0015] Please see Figure 1 The present invention provides a flowchart of an integrated method for centralized permission management and emergency response of mobile devices, comprising the following steps: Step 201: Obtain the hardware unique identifier and operating system kernel signature of the target mobile device, perform a hash operation to bind the hardware unique identifier and the operating system kernel signature, and generate a trusted baseline snapshot of the target mobile device.

[0016] In some embodiments, the security component first reads the immutable hardware ID (such as the CPU serial number or the security chip ID in the TEE) from the mobile device as a unique hardware identifier, and simultaneously performs an integrity scan on the currently loaded operating system kernel code segment to extract the kernel signature. Subsequently, the system can use one-way hash algorithms such as SHA-256 to perform a salted hash operation on the aforementioned hardware identifier and the kernel signature, generating a trusted baseline snapshot that uniquely represents "specific hardware running a specific version of the system," providing a trusted foundation for subsequent secure access.

[0017] In some embodiments, step 201 may include: Read the immutable CPU serial number pre-stored in the trusted execution environment of the target mobile device as a unique hardware identifier; Scan the operating system kernel code segment of the target mobile device in its current operating environment and extract the memory image digest as the operating system kernel signature; The CPU serial number and memory image digest are concatenated using a preset timestamp factor, and the concatenated data is subjected to a SHA-256 hash operation to obtain a trusted baseline snapshot.

[0018] In some embodiments, to ensure the uniqueness and unforgeability of device identity, this embodiment does not rely on easily modified IMEI codes or MAC addresses, but instead delves into the underlying hardware. The security component can access the Trusted Execution Environment (TEE, such as ARM TrustZone) within the processor architecture by calling the underlying driver interface. Within the secure isolation zone of the TEE, a physically immutable CPU serial number, written by fuse at the factory, is stored. The system reads this serial number string from the protected memory space and uses it as a unique hardware identifier. Because this reading process is completed within the TEE, external malware or a rooted operating system cannot intercept or tamper with the read instruction, thus establishing a hardware-level root of trust.

[0019] While acquiring the hardware identifier, the system can initiate an integrity measurement process to verify the software environment. Specifically, the security component can obtain the load base address and end address of the current operating system kernel in physical memory, locating the kernel's code segment (.text segment) and read-only data segment (.rodata segment). The system can then perform a byte-by-byte scan of the binary data within this memory region and use lightweight verification algorithms (such as CRC32 or MD5) to calculate and generate a fixed-length checksum, i.e., a memory image digest. This digest accurately reflects whether the currently running kernel has been injected with malicious code, whether unauthorized modules have been mounted, or whether the system call table has been tampered with, thus constituting the operating system kernel signature.

[0020] In some embodiments, to prevent replay attacks and achieve strong hardware-software binding, the system first obtains the current network standard time or high-precision system clock as a timestamp factor (Nonce), which is used to identify the timeliness of the snapshot generation. Then, the system concatenates these three sets of data into a string according to a preset order: "CPU serial number + operating system kernel signature + timestamp factor". Next, SHA-256 (a 256-bit secure hash algorithm) is used to perform a one-way encryption operation on the concatenated data stream, and the generated 256-bit hash value is the trusted baseline snapshot of the target mobile device. This snapshot not only contains information on "object identification (hardware ID)" and "state (kernel signature)," but also includes the dimension of "when (timestamp)," ensuring that the authentication data uploaded to the server cannot be forged or intercepted and reused by attackers.

[0021] Step 202: Transmit the trusted baseline snapshot to the server for integrity verification. Based on the verification result and the preset compliance group rules, generate an atomic control policy and distribute and configure the atomic control policy to the hardware abstraction layer of the target mobile device to obtain the configured atomic control policy.

[0022] The atomic control strategy includes context constraints, hardware resource objects, and operation instruction dimensions.

[0023] In some embodiments, the server can receive and verify whether the snapshot is on a whitelist. Upon successful verification, it matches the corresponding compliance rules based on the user group (e.g., R&D group, management group) to which the device belongs. These rules are transformed into machine-readable atomic control policies, which are three-dimensional configuration matrices containing context constraints (e.g., time, geofencing), hardware resource objects (e.g., / dev / video0, NFC controller), and operation instructions (e.g., Read, Write, IOCTL). Finally, this policy can be injected into the hardware abstraction layer (HAL) of the terminal operating system via an encrypted channel, enabling pre-positioning and takeover of the underlying driver interfaces.

[0024] In some embodiments, step 202 may include: The server receives and verifies the trusted baseline snapshot. If the verification passes, it retrieves the corresponding user permission group based on the device identifier of the target mobile device and extracts the set of business rules that match the user permission group. The business rule set is parsed and converted into a machine-readable configuration file as an atomic control policy. The configuration file is used to define the hardware driver handles that are allowed to be accessed and the corresponding opcodes. The configuration file is transmitted to the target mobile device through an encrypted secure channel, and the address of the intercept function in the configuration file is written into the function pointer table of the hardware abstraction layer using dynamic hooking technology. This completes the takeover and configuration of the underlying hardware driver interface, resulting in a configured atomic control strategy.

[0025] First, after receiving the trusted baseline snapshot uploaded by the target mobile device, the server can use a pre-built signature verification algorithm to verify the integrity of the signature data in the snapshot, confirming that the device has not been subjected to a man-in-the-middle attack during transmission and that its kernel environment has not been tampered with. After successful verification and confirmation that the device is a trusted device, the server extracts the device ID from the snapshot and retrieves the user permission group (e.g., core confidential group, general office group, or visitor group) to which the device belongs from the background database. Next, the system extracts a set of business rules matching the user permission group from the policy library. These business rules are typically high-level policies described in natural language, such as "prohibit the use of cameras in the R&D area" or "allow access to internal storage only during working hours."

[0026] Next, to enable the terminal's underlying operating system to understand and execute the aforementioned high-level business rules, the server needs to perform "atomic" transformation of the policy. Specifically, the system can be configured with a policy parsing engine that maps abstract business rules to specific system-level instructions. The parsing engine translates "block camera" into control instructions targeting specific hardware driver handles (such as / dev / video0 or CameraService), and "read / write restriction" into opcodes (such as IOCTL_READ, IOCTL_WRITE) of the underlying file system. Finally, these instructions are encapsulated into a machine-readable configuration file (usually in JSON or Protobuf format), i.e., the atomic control policy. This configuration file precisely defines the controlled hardware resource objects, the types of actions allowed or prohibited, and the context conditions under which they take effect.

[0027] Finally, the system executes the policy distribution and activation configuration. The server establishes an encrypted secure channel based on TLS (Transport Layer Security) to distribute the configuration file to the target mobile device, ensuring that the policy data is not eavesdropped. After receiving the configuration, the device's security component initiates the underlying takeover process. Specifically, the system uses Dynamic Hooking to locate the dynamic link libraries (.so files) loaded in the operating system's Hardware Abstraction Layer (HAL). The system scans the function pointer table or virtual function table (vtable) in the HAL layer's memory space; these entries originally point to the actual hardware driver interface functions. The security component uses atomic write operations to overwrite the entry with the interceptor function address specified in the configuration file, thereby replacing the original driver function address. In this way, the system completes the takeover of the underlying hardware driver interface without modifying the operating system source code or restarting the device. Afterward, any application's call request to the hardware will first be redirected to the security component's interceptor function for compliance checks.

[0028] In some embodiments, step 202 may include: Locate the memory space of the target process that has loaded the Hardware Abstraction Layer (HAL) dynamic link library, and obtain the global offset table in the target process's memory space; Traverse the global offset table to retrieve the target entry that matches the original hardware operation function symbol, read the original memory address stored in the target entry, and copy and save the original memory address to the pre-allocated jumper memory area. An atomic write operation is performed to overwrite the address of the intercept function specified in the configuration file to the target entry in the global offset table. Subsequent call instructions for the underlying hardware driver interface are redirected to the address of the intercept function, thus completing the takeover and configuration of the underlying hardware driver interface and obtaining the configured atomic control strategy.

[0029] In some embodiments, after a security policy is issued, the security component first reads the operating system's process file system (e.g., the / proc / [pid] / maps file in Linux / Android) to parse the virtual memory mapping layout of the target process (usually a system service process or a specific HAL service daemon). The system locates the base address in memory of the hardware abstraction layer dynamic link library (.so file) based on its filename. Next, the system parses the ELF (Executable and Linkable Format) header information of the dynamic link library and searches for the segment named .got or .got.plt according to the section header table, thereby determining the exact starting address and size of the Global Offset Table (GOT) in the process's memory space. The GOT table is a key data structure in the dynamic linking mechanism used to store the absolute addresses of external functions.

[0030] After locating the GOT table, the system can perform a reverse lookup using the Dynamic Symbol Table. The system traverses the symbol table, searching for the function symbol name corresponding to the controlled hardware interface specified in the configuration file (e.g., open, ioctl, or the vendor-specific camera driver function `camera_device_open`). Once a match is found, the system calculates the offset of the corresponding entry in the GOT table based on the symbol's index in the symbol table; this is the "target entry." The system then reads the currently stored address value in the target entry, which is the entry address of the original hardware driver function. To ensure business continuity (i.e., ensuring the hardware functions correctly after compliance checks), the system copies and backs up this original address to a pre-allocated memory region with execution permissions, known as the "trampoline memory region." This trampoline region essentially acts as a relay bridge, allowing security components to subsequently call back the original driver function via the trampoline.

[0031] Because modern operating systems typically mark the memory page containing the GOT as "read-only" to prevent tampering, the system first calls a memory protection system call (such as mprotect) to temporarily change the permissions of the memory page to "read-write". Then, to prevent program crashes caused by multi-threaded concurrency, the system performs an atomic write operation, writing the memory address of the pre-defined "Interceptor Function" into the target entry of the GOT table, overwriting the original driver function address. After writing, the "read-only" attribute of the memory page is immediately restored. At this point, the Hook configuration is complete. When any upper-layer application attempts to call the hardware driver interface again, the program flow will jump to the modified GOT entry via the Procedure Linked List (PLT), thus being forcibly redirected to the interceptor function of the security component. Within the interceptor function, the system executes subsequent permission determination logic, thereby achieving complete control over the underlying hardware driver interface.

[0032] Step 203: Based on the configured atomic control strategy, start the two-layer monitoring mechanism to capture the running data of the target mobile device and generate software and hardware interaction behavior data.

[0033] The runtime data includes application programming interface (API) call requests from the application layer and hardware input / output requests from the driver layer.

[0034] In some embodiments, the system can simultaneously launch a user-mode monitoring engine located at the application layer and a kernel-mode monitoring engine located at the driver layer. The user-mode engine is responsible for hooking and recording application programming interface (API) call requests in the Java or Native layer to identify application intent; the kernel-mode engine directly listens for input / output requests on the hardware bus. The system performs timestamp alignment and correlation analysis on the data from these two layers to generate software and hardware interaction behavior data containing complete call chain information, thereby preventing malicious applications from bypassing upper-layer monitoring through the lower layer.

[0035] In some embodiments, step 203 may include: Start the user-mode monitoring engine, inject monitoring probes into the application process space, and intercept and record application interface-level call requests; Start the kernel-mode monitoring engine, register callback functions on the hardware driver bus, and listen to and capture the input / output control code of the underlying device; By using process identifiers as association keys, call requests and input / output control codes within the same time window are merged and deduplicated to generate software and hardware interaction behavior data containing complete call chain information.

[0036] In some embodiments, the user-space monitoring engine runs as a high-privilege system service. It can utilize operating system-provided debugging interfaces (such as ptrace in Linux) or dynamic link library preloading mechanisms (such as LD_PRELOAD) to inject monitoring probes into the process space of all newly launched applications. The probes hook key API interfaces (e.g., Camera.open(), AudioRecord.start(), LocationManager.getLastKnownLocation()) in the Android Framework or Native layer using Hook technology. When an application initiates a call, the probe intercepts the request before the system executes and records the caller's metadata, which may include the application package name, application signature, function stack information, and API parameters. This monitoring layer is primarily responsible for capturing the application's "semantic intent" (i.e., what the application claims to do).

[0037] To prevent malicious applications from bypassing standard APIs and directly manipulating hardware, this system deploys a kernel-mode monitoring engine at the operating system kernel level. This engine exists as a kernel module (LKM) or eBPF program, directly registering a notifier chain or callback function on the bus interfaces of critical hardware drivers (such as the V4L2 camera subsystem, ALSA audio subsystem, or USB bus). The engine monitors the input / output control (IOCTL) instruction stream passing through the kernel in real time, capturing the underlying hardware opcodes. These opcodes represent the actual physical actions performed by the hardware (such as "powering on the sensor" or "reading a flash sector"). Through this layer of monitoring, the system can grasp the "physical facts" of the hardware.

[0038] Since user-mode API calls are ultimately translated into kernel-mode system calls, there is a slight time delay between the two, but they logically belong to the same transaction. The data processing module maintains a "sliding time window" (e.g., 100 milliseconds) based on a circular buffer. The module extracts the process identifier (PID) from the user-mode log and the current process context PID from the kernel-mode log. Within the preset time window, the system uses the PID as an index to match and merge the application-layer "semantic intent" with the kernel-layer "physical facts." The system removes redundant intermediate state data and constructs a complete chain of "software-hardware interaction behavior data" (e.g., App A [PID:1024] -> calls Camera API -> triggers IOCTL_STREAMON on / dev / video0). This end-to-end data can not only identify regular violations but also effectively identify fraudulent behavior, such as an app requesting recording permissions but actually attempting to read NFC data.

[0039] Step 204: Input the software and hardware interaction behavior data into the risk arbitration module residing on the device, and perform pre-execution compliance verification on the software and hardware interaction behavior data in combination with the current device operating environment context to generate real-time risk assessment results.

[0040] In some embodiments, the risk arbitration module receives the aforementioned interactive data locally and collects the current operating environment context in real time (such as whether it is connected to an untrusted Wi-Fi network or is in a sensitive area). The module compares the actual operational intent with the injected atomic control policy (i.e., the configured atomic control policy), makes a prediction before the instruction actually reaches the physical hardware, and generates a real-time risk assessment result of "allow," "alarm," or "block," achieving millisecond-level risk identification.

[0041] In some embodiments, step 204 may include: Collect the target mobile device's current real-time environmental parameters, which include at least the geographic location coordinates, the identifier of the wireless network service set it is connected to, and the system time. Find the target rule tuple that matches the real-time environment parameters and the requested hardware resource object in the atomic control strategy; The operation instructions in the software and hardware interaction behavior data are compared with the allowed actions defined in the target rule tuple. If the operation instructions exceed the range of allowed actions, a decision signal indicating interception is generated as the real-time risk assessment result.

[0042] In some embodiments, when the monitoring engine detects sensitive behavior, it can trigger the risk arbitration module to initiate an environmental awareness process. This module calls the device's multi-source sensor interfaces in parallel: First, it can obtain high-precision geographic location coordinates (latitude and longitude) through GPS, BeiDou, or base station triangulation technology to determine whether the device is in a confidential area (such as a "R&D building" or "conference room"); second, it can scan the current network status and extract the accessed wireless network service set identifier (SSID) and the more difficult-to-forge physical address (BSSID) to determine whether the device is in a controlled and trusted network environment; finally, it can read the system time synchronized via the Secure Network Time Protocol (NTP) to determine whether the current operation occurs within the specified working time window. The above multi-dimensional data together constitute the "current device operating environment context".

[0043] In some embodiments, the arbitration module utilizes efficient memory retrieval algorithms (such as hash mapping or multi-branch decision trees) to search the locally cached atomic control policy library. The input key-value pair (Key) for retrieval consists of two parts: the "environmental context" collected above, and the "target hardware resource object" parsed from the hardware-software interaction data (e.g., Target_Device= / dev / camera). The system locks down the target rule tuple most suitable for the current scenario based on "longest prefix matching" or priority weight logic. For example, this tuple might be defined as: "{condition: [location=headquarters, network=office network, time=9:00-18:00], resource: camera, policy ID: Rule_1024}".

[0044] In some embodiments, after locking the rule tuple, the module can read the "Allowed Action Set" defined in the tuple. For example, the rule might specify that in this scenario, the camera is only allowed to perform "low-resolution preview (PREVIEW_LOW_RES)," while "high-definition recording (RECORD_HIGH_RES)" or "snapshot (SNAPSHOT)" is prohibited. The module compares the actual captured low-level operation commands (Opcode / Function Call) in the hardware and software interaction behavior data with the allowed action set using a whitelist. If the actual command is not in the allowed set (e.g., the APP attempts to call the high-definition recording command), it is considered "unauthorized access." At this time, the arbitration module immediately generates a decision signal containing the "BLOCK" command, risk type, and policy ID as the final real-time risk assessment result, and outputs the signal to the execution layer to trigger blocking.

[0045] Step 205: In response to the real-time risk assessment result indicating the existence of violations, and based on the preset graded handling logic, execute automated emergency response actions at the hardware abstraction layer that match the risk level.

[0046] Among them, automated emergency response actions include blocking hardware driver calls, cutting off network communication, or performing a security wipe to put the target mobile device into a defensive protection state.

[0047] In some embodiments, when the assessment result indicates a violation, the system does not need to wait for server instructions and can directly trigger a response based on the risk level defined in the policy: for minor violations, the system intercepts driver calls at the HAL layer and returns empty data, blocking hardware use; for moderate violations, the system automatically cuts off network communication interfaces; for severe violations (such as detecting root privilege escalation attempts), the system executes a security erase command to destroy critical keys. After the above actions are executed, the target mobile device enters a functionally restricted defense protection state.

[0048] In some embodiments, step 205 may include: Calculate the risk score for the violation; If the risk score is in the low-risk range, a virtual blank data stream is returned to the application that initiated the call to block the hardware driver call; If the risk score is in the medium risk range, immediately terminate the application process that initiated the call and disable the network adapter driver to cut off the network connection. If the risk score is in the high-risk range and the integrity of the operating system is detected to be compromised, a security erase command is sent to the underlying storage controller to destroy the key file in the encrypted partition, putting the target mobile device into an unrecoverable defense protection state.

[0049] In some embodiments, the system does not treat all violations equally, but instead introduces a quantitative assessment mechanism. The risk arbitration module calculates the current risk score (e.g., 0-100) based on multi-dimensional factors. These factors may include: violation frequency (number of consecutive attempts within a short period), resource sensitivity (camera access is weighted more heavily than accelerometer access), application reputation (system-level application violations vs. third-party application violations), and environmental urgency (violations in classified areas are weighted more heavily than those in unclassified areas). The system uses a weighted summation algorithm to derive the final real-time risk score.

[0050] In some embodiments, if the risk score is in the low-risk range (e.g., a maximum score of 100 points, the corresponding low-risk range can be 0-50 points), then a virtual blank data stream is returned to the initiating application to block the hardware driver call. For accidental misoperations or minor violations (such as an application attempting to refresh location in the background), the system can adopt a "soft blocking" strategy. In the interception function of the Hardware Abstraction Layer (HAL), the system does not perform actual hardware I / O operations, but instead constructs and returns a "fake data packet" conforming to a standard data format. For example, when intercepting a camera call, a completely black image frame is returned; when intercepting a microphone call, a silent PCM audio stream is returned. This processing method (Data Mocking / Spoofing) protects privacy data from being stolen and prevents the application from crashing due to not receiving data, ensuring system stability.

[0051] In some embodiments, if the risk score is in the medium-risk range (e.g., a maximum score of 100 points corresponds to a range of 51-80 points), the initiating application process is immediately terminated, and the network adapter driver is disabled to cut off the network connection. For obvious unauthorized behavior or data leakage attempts, the system can adopt a "strong blocking" strategy. First, the security component calls the operating system's process management interface to send a forced termination signal (such as SIGKILL) to the process identifier (PID) of the violating app, immediately killing the process. Simultaneously, to prevent data from being read into memory and waiting to be sent, the security component directly sends a "Down" command to the underlying network adapter driver or cuts off the power supply to the Wi-Fi / cellular baseband chip through the power management interface. This combination of "disconnecting the network + killing the process" physically cuts off the data transmission channel.

[0052] In some embodiments, if the risk score is in the high-risk range (e.g., a maximum score of 100), the corresponding high-risk range can be 81-100 points. If operating system integrity is detected as compromised, a secure erase command is sent to the underlying storage controller to destroy the key file within the encrypted partition, putting the target mobile device into an unrecoverable state of protection. For the highest-level threat scenarios (such as detecting a root privilege escalation attack, physical disassembly, or known unauthorized control of the device), the system triggers a "self-destruct" defense. The security component bypasses the file system and directly sends a low-level secure erase command to the Flash / UFS storage controller. This operation is not a simple file deletion, but rather involves multiple random overwrites of the KeyStore partition or direct destruction of the full-disk encryption master key. Once the master key is lost, all encrypted data within the storage medium will become garbled due to the inability to decrypt, thus achieving complete data destruction and making the device logically unrecoverable, ensuring that core secrets are not leaked under any extreme circumstances.

[0053] Step 206: Extract the interception logs and risk feature data generated by the target mobile device in the defense protection state, feed the interception logs and risk feature data back to the server to generate a policy update package, and iteratively update the atomic control policy according to the policy update package.

[0054] In some embodiments, the system can package and encrypt detailed logs intercepted locally (including the signature of the violating app, call stack, and trigger time) and environmental characteristic data and upload them to the server. The server uses big data analysis to identify new attack patterns or compliance vulnerabilities, generates incremental policy update packages, and sends them back to the mobile device via a heartbeat channel to dynamically correct and upgrade the local atomic control policies, thereby forming a security closed loop of "single point discovery, global immunity".

[0055] In some embodiments, step 206 may include: The stack trace information and attack signature vector in the interception log are packaged and encrypted, and then uploaded to the server after the network connection is restored; The server uses clustering algorithms to analyze attack feature vectors from multiple devices, identifies new attack patterns, and generates incremental defense rules for these new attack patterns. Incremental defense rules are encapsulated into policy update packages and pushed to the target mobile device through a heartbeat detection channel.

[0056] In some embodiments, when a mobile device triggers a defense mechanism (such as blocking or isolation), the edge security component can immediately initiate an evidence collection process. Specifically, the system can extract the stack trace (including function call chains, register states, and memory offsets) and attack vector (such as specific malicious API call sequences, illegal IOCTL parameter combinations, or abnormal process tree structures) at the time of interception. To prevent sensitive logs from being leaked during transmission, the system uses serialization technology (such as Protobuf) to package the above data and uses a hybrid encryption scheme (i.e., encrypting the data packet with a randomly generated AES key and then encrypting the AES key with the server's RSA public key) for high-strength encryption. Considering that the device may be in a "network disconnection" defense state, the system can adopt a "store-and-forward" mechanism: first, the encrypted packet is cached in a local secure storage area, and the system listens for network connection status broadcasts (ConnectivityManager); once the network connection is detected to be restored and the device is in a trusted network environment, a background service is immediately started to asynchronously upload the encrypted packet to the server.

[0057] In some embodiments, the server can receive encrypted logs from a massive number of terminal devices, decrypt them, and clean the data. The system introduces unsupervised clustering algorithms from machine learning (such as DBSCAN or K-Means) to perform multi-dimensional spatial clustering analysis on attack feature vectors from different devices. Specifically, if the system detects that a large number of devices have reported highly similar violation logs within a short period of time (e.g., all pointing to the same unknown third-party dynamic library file or the same set of abnormal NFC reading frequencies), the algorithm will determine that this phenomenon is a "new attack pattern" or a "zero-day vulnerability exploit." Based on the clustering results, the policy generation engine automatically extracts the common features of this attack pattern (such as specific file hash values ​​or specific memory access patterns) and transforms them into a new blocking rule, namely an "incremental defense rule," thereby realizing the transformation from single-point, occasional failures to global threat intelligence.

[0058] In some embodiments, to reduce network bandwidth consumption and improve response speed, the server does not redistribute the full policy file; instead, it encapsulates the newly generated defense rules into lightweight policy update packages (patches). The system can utilize a long-connection heartbeat channel (such as a keep-alive link based on MQTT or WebSocket protocols) as a signaling carrier. When the server generates a critical update, it sends a "configuration change notification" or directly pushes the policy update package to all online target mobile devices through this channel. Upon receiving the push, the device dynamically loads the incremental rule and merges it into its local atomic control policy without restarting the system, thereby enabling all managed devices to quickly gain immunity to new types of attacks.

[0059] In some embodiments, step 206 may include: Verify the digital signature of the policy update packet to ensure its source is trustworthy; Parse the policy update package to obtain new rule entries, and build a new policy data structure in memory; By using atomic swap operations, the old policy pointer in the hardware abstraction layer is pointed to the new policy data structure, enabling online iterative updates of atomic control policies without restarting the target mobile device.

[0060] In some embodiments, when a mobile device receives a policy update package pushed by the server, the security component may not execute immediately, but instead first initiate a signature verification process. The system invokes a pre-installed CA root certificate or public key in the local trusted keystore and uses an asymmetric encryption algorithm (such as RSA-2048 or ECDSA) to decrypt and verify the digital signature attached to the update package. Simultaneously, the system calculates the hash digest of the update package content and compares it with the digest in the signature. Only when the signature verification passes and the digest matches is it confirmed that the update package indeed originates from a legitimate server and has not been tampered with during transmission, thereby preventing attackers from attacking the defense system by forging policy packages.

[0061] In some embodiments, after passing security verification, the system initiates the parsing process in a separate memory space (Heap Memory). The system deserializes the serialized update package (such as a Protobuf or JSON binary stream) into an operable object and extracts the newly added or changed rule entries. To ensure the efficiency of policy retrieval, the system does not directly modify the original policy object. Instead, it adopts the "copy-on-write" or "double buffering" approach to construct a completely new optimized policy data structure in memory (e.g., generating a new hash map or a trie tree). At this time, the old policy data structure is still being read by the HAL layer to process current hardware requests. The old and new structures coexist temporarily in memory without interfering with each other.

[0062] In some embodiments, to prevent null pointer dereferences or logical errors in ongoing hardware calls during policy switching, the system utilizes atomic operations (such as Compare-and-Swap / CAS) provided by the CPU or the operating system's RCU (Read-Copy-Update) synchronization mechanism. The system locks a global policy pointer variable and, within an uninterruptible CPU instruction cycle, instantly modifies the pointer address pointing to the "old policy data structure" to the address pointing to the "new policy data structure." Because this operation is atomic, all hardware call requests initiated after the switching moment will immediately access the new policy, while requests initiated before the switching moment will still be processed by the old policy until completion. Once all reference counts of the old policy reach zero, the garbage collection mechanism (GC) releases the memory occupied by the old structure. In this way, the system can achieve millisecond-level dynamic policy activation without restarting the device or related service processes.

[0063] Please see Figure 2 , Figure 2This is a schematic diagram of the structure of an integrated system for centralized permission management and emergency response of mobile devices provided by the present invention.

[0064] like Figure 2 As shown in the figure, an integrated system for centralized permission management and emergency response of mobile devices proposed in this embodiment of the invention includes: The snapshot generation module 301 is used to obtain the hardware unique identifier and operating system kernel signature of the target mobile device, perform a hash operation to bind the hardware unique identifier and the operating system kernel signature, and generate a trusted baseline snapshot of the target mobile device. The policy configuration module 302 is used to transmit the trusted benchmark snapshot to the server for integrity verification, generate atomic control policies based on the verification results and preset compliance group rules, and distribute and configure the atomic control policies to the hardware abstraction layer of the target mobile device to obtain the configured atomic control policies; the atomic control policies include context constraints, hardware resource objects and operation instruction dimensions; The data generation module 303 is used to initiate a two-layer monitoring mechanism based on a configured atomic control strategy to capture the running data of the target mobile device and generate software and hardware interaction behavior data; the running data includes application interface call requests at the application layer and hardware input / output requests at the driver layer. The risk assessment module 304 is used to input software and hardware interaction behavior data into the risk arbitration module residing on the device, and perform pre-execution compliance verification on the software and hardware interaction behavior data in combination with the current device operating environment context to generate real-time risk assessment results. The emergency response module 305 is used to respond to the real-time risk assessment results indicating that there is a violation. Based on the preset hierarchical handling logic, it executes automated emergency response actions at the hardware abstraction layer that match the risk level. The automated emergency response actions include blocking hardware driver calls, cutting off network communication, or performing security wipe to put the target mobile device into a defensive protection state. The policy update module 306 is used to extract the interception logs and risk feature data generated by the target mobile device in the defense protection state, feed the interception logs and risk feature data back to the server to generate a policy update package, and iteratively update the atomic control policy according to the policy update package.

[0065] Please see Figure 3 , Figure 3 A schematic diagram illustrating an embodiment of the electronic device provided in this invention. For example... Figure 3 As shown, an embodiment of the present invention provides an electronic device 400, including a memory 410, a processor 420, and a computer program 411 stored in the memory 410 and executable on the processor 420. When the processor 420 executes the computer program 411, it performs the following steps: Obtain the hardware unique identifier and operating system kernel signature of the target mobile device, perform a hash operation to bind the hardware unique identifier and the operating system kernel signature, and generate a trusted baseline snapshot of the target mobile device. A trusted baseline snapshot is transmitted to the server for integrity verification. Based on the verification result and the preset compliance group rules, an atomic control policy is generated. The atomic control policy is then distributed and configured to the hardware abstraction layer of the target mobile device to obtain the configured atomic control policy. The atomic control policy includes context constraints, hardware resource objects, and operation instruction dimensions. Based on the configured atomic control strategy, a two-layer monitoring mechanism is initiated to capture the running data of the target mobile device and generate software and hardware interaction behavior data; the running data includes application programming interface call requests at the application layer and hardware input / output requests at the driver layer. The software and hardware interaction behavior data is input into the risk arbitration module residing on the device. Combined with the current device operating environment context, the software and hardware interaction behavior data is pre-executed for compliance verification, and real-time risk assessment results are generated. In response to real-time risk assessment results indicating violations, and based on preset tiered handling logic, automated emergency response actions matching the risk level are executed at the hardware abstraction layer. These automated emergency response actions include blocking hardware driver calls, cutting off network communication, or performing a security wipe, putting the target mobile device into a defensive protection state. Extract the interception logs and risk feature data generated by the target mobile device in the defense protection state, feed the interception logs and risk feature data back to the server to generate a policy update package, and iteratively update the atomic control policy according to the policy update package.

[0066] Please see Figure 4 , Figure 4 This is a schematic diagram illustrating an embodiment of a computer-readable storage medium provided by an embodiment of the present invention. For example... Figure 4 As shown, this embodiment provides a computer-readable storage medium 500 on which a computer program 411 is stored. When the computer program 411 is executed by a processor, it performs the following steps: Obtain the hardware unique identifier and operating system kernel signature of the target mobile device, perform a hash operation to bind the hardware unique identifier and the operating system kernel signature, and generate a trusted baseline snapshot of the target mobile device. A trusted baseline snapshot is transmitted to the server for integrity verification. Based on the verification result and the preset compliance group rules, an atomic control policy is generated. The atomic control policy is then distributed and configured to the hardware abstraction layer of the target mobile device to obtain the configured atomic control policy. The atomic control policy includes context constraints, hardware resource objects, and operation instruction dimensions. Based on the configured atomic control strategy, a two-layer monitoring mechanism is initiated to capture the running data of the target mobile device and generate software and hardware interaction behavior data; the running data includes application programming interface call requests at the application layer and hardware input / output requests at the driver layer. The software and hardware interaction behavior data is input into the risk arbitration module residing on the device. The software and hardware interaction behavior data is pre-executed for compliance verification in combination with the current device operating environment context, and real-time risk assessment results are generated. In response to real-time risk assessment results indicating violations, and based on preset tiered handling logic, automated emergency response actions matching the risk level are executed at the hardware abstraction layer. These automated emergency response actions include blocking hardware driver calls, cutting off network communication, or performing a security wipe, putting the target mobile device into a defensive protection state. Extract the interception logs and risk feature data generated by the target mobile device in the defense protection state, feed the interception logs and risk feature data back to the server to generate a policy update package, and iteratively update the atomic control policy according to the policy update package.

[0067] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0068] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0069] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A system that specifies functions in one or more boxes.

[0070] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including an instruction set implemented in a process. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0071] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0072] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0073] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A method for centralized permission management and emergency response of mobile devices, characterized in that, The method includes: Obtain the hardware unique identifier and operating system kernel signature of the target mobile device, perform a hash operation to bind the hardware unique identifier and the operating system kernel signature, and generate a trusted baseline snapshot of the target mobile device. The trusted benchmark snapshot is transmitted to the server for integrity verification. Based on the verification result and the preset compliance group rules, an atomic control policy is generated. The atomic control policy is then distributed and configured to the hardware abstraction layer of the target mobile device to obtain the configured atomic control policy. The atomic control policy includes context constraints, hardware resource objects, and operation instruction dimensions. Based on the configured atomic control strategy, a two-layer monitoring mechanism is initiated to capture the operating data of the target mobile device and generate software and hardware interaction behavior data; the operating data includes application programming interface call requests at the application layer and hardware input / output requests at the driver layer. The software and hardware interaction behavior data is input into the risk arbitration module residing on the device. The software and hardware interaction behavior data is pre-executed for compliance verification in combination with the current device operating environment context, and a real-time risk assessment result is generated. In response to the real-time risk assessment result indicating a violation, an automated emergency response action matching the risk level is executed at the hardware abstraction layer according to a preset tiered handling logic. The automated emergency response action includes blocking hardware driver calls, cutting off network communication, or performing a security wipe, so that the target mobile device enters a defensive protection state. The interception logs and risk feature data generated by the target mobile device under the defense protection state are extracted, and the interception logs and risk feature data are fed back to the server to generate a policy update package. The atomic control policy is then iteratively updated according to the policy update package.

2. The integrated method for centralized permission management and emergency response of mobile devices according to claim 1, characterized in that, The step of hashing and binding the hardware unique identifier with the operating system kernel signature to generate a trusted baseline snapshot of the target mobile device includes: Read the immutable CPU serial number pre-stored in the trusted execution environment of the target mobile device and use it as the unique identifier of the hardware; Scan the operating system kernel code segment of the target mobile device in its current operating environment and extract the memory image digest as the operating system kernel signature; The CPU serial number and the memory image digest are concatenated using a preset timestamp factor, and the concatenated data is subjected to a SHA-256 hash operation to obtain the trusted benchmark snapshot.

3. The integrated method for centralized permission management and emergency response of mobile devices according to claim 2, characterized in that, The process involves transmitting the trusted baseline snapshot to the server for integrity verification, generating an atomic control policy based on the verification result and preset compliance group rules, and then distributing and configuring the atomic control policy to the hardware abstraction layer of the target mobile device to obtain the configured atomic control policy, including: The server receives and verifies the trusted benchmark snapshot. If the verification passes, it retrieves the corresponding user permission group based on the device identifier of the target mobile device and extracts the set of business rules that match the user permission group. The set of business rules is parsed and converted into a machine-readable configuration file as the atomic control policy. The configuration file is used to define the hardware driver handles that are allowed to be accessed and the corresponding opcodes. The configuration file is transmitted to the target mobile device through an encrypted secure channel, and the address of the interception function in the configuration file is written into the function pointer table of the hardware abstraction layer using dynamic hooking technology. This completes the takeover and configuration of the underlying hardware driver interface, resulting in the configured atomic control strategy.

4. The integrated method for centralized permission management and emergency response of mobile devices according to claim 3, characterized in that, The process involves transmitting the configuration file to the target mobile device via an encrypted secure channel, and using dynamic hooking technology to write the interception function addresses in the configuration file into the function pointer table of the hardware abstraction layer. This completes the takeover and configuration of the underlying hardware driver interface, resulting in the configured atomic control strategy, including: Locate the memory space of the target process that has loaded the hardware abstraction layer dynamic link library, and obtain the global offset table in the memory space of the target process; The global offset table is traversed to retrieve the target entry that matches the original hardware operation function symbol, the original memory address stored in the target entry is read, and the original memory address is copied and saved to the pre-allocated jump board memory area. An atomic write operation is performed to overwrite the address of the interception function specified in the configuration file to the target entry in the global offset table. Subsequent call instructions for the underlying hardware driver interface are redirected to the address of the interception function, thereby completing the takeover and configuration of the underlying hardware driver interface and obtaining the configured atomic control strategy.

5. The integrated method for centralized permission management and emergency response of mobile devices according to claim 4, characterized in that, Based on the configured atomic control strategy, a two-layer monitoring mechanism is initiated to capture the operating data of the target mobile device and generate software and hardware interaction behavior data, including: Start the user-mode monitoring engine, inject monitoring probes into the application process space, and intercept and record the application interface-level call requests; Start the kernel-mode monitoring engine, register callback functions on the hardware driver bus, and listen to and capture the input / output control code of the underlying device; Using process identifiers as association keys, the call requests and input / output control codes within the same time window are merged and deduplicated to generate the software and hardware interaction behavior data containing complete call chain information.

6. The integrated method for centralized permission management and emergency response of mobile devices according to claim 5, characterized in that, The step of inputting the software and hardware interaction behavior data into the risk arbitration module residing on the device, and performing pre-execution compliance verification on the software and hardware interaction behavior data in conjunction with the current device operating environment context to generate real-time risk assessment results includes: Collect the current real-time environmental parameters of the target mobile device. The real-time environmental parameters include at least the geographic location coordinates, the identifier of the accessed wireless network service set, and the system time. The target rule tuple that matches the real-time environment parameters and the requested hardware resource object is searched in the atomic control strategy. The operation instructions in the software and hardware interaction behavior data are compared with the allowed actions defined in the target rule tuple. If the operation instructions exceed the range of allowed actions, a decision signal indicating interception is generated as the real-time risk assessment result.

7. The integrated method for centralized permission management and emergency response of mobile devices according to claim 6, characterized in that, In response to the real-time risk assessment result indicating a violation, the system executes automated emergency response actions at the hardware abstraction layer, matching the risk level, based on a preset tiered handling logic. These actions include: Calculate the risk score for the aforementioned violation; If the risk score is in the low-risk range, a virtual blank data stream is returned to the application that initiated the call to block the hardware driver call; If the risk score is in the medium risk range, the application process that initiated the call will be terminated immediately, and the network adapter driver will be disabled to cut off the network connection. If the risk score is in the high-risk range and the integrity of the operating system is detected to be compromised, a security erase command is sent to the underlying storage controller to destroy the key file in the encrypted partition, thus putting the target mobile device into an unrecoverable defense protection state.

8. The integrated method for centralized permission management and emergency response of mobile devices according to claim 7, characterized in that, The step of extracting the interception logs and risk characteristic data generated by the target mobile device under the defense protection state, and feeding back the interception logs and risk characteristic data to the server to generate a policy update package includes: The stack information and attack feature vector in the interception log are packaged and encrypted, and uploaded to the server after the network connection is restored; The server uses a clustering algorithm to analyze attack feature vectors from multiple devices, identifies new attack patterns, and generates incremental defense rules for these new attack patterns. The incremental defense rules are encapsulated into a policy update package and pushed to the target mobile device through a heartbeat detection channel.

9. The integrated method for centralized permission management and emergency response of mobile devices according to claim 8, characterized in that, The iterative update of the atomic control policy based on the policy update package includes: Verify the digital signature of the policy update package to ensure the source is trustworthy; The policy update package is parsed to obtain new rule entries, and a new policy data structure is constructed in memory; By using atomic swap operations, the old policy pointer in the hardware abstraction layer is pointed to the new policy data structure, enabling online iterative updates of the atomic control policy without restarting the target mobile device.

10. An integrated system for centralized access control and emergency response of mobile devices, characterized in that, The system includes: The snapshot generation module is used to obtain the hardware unique identifier and operating system kernel signature of the target mobile device, perform a hash operation on the hardware unique identifier and the operating system kernel signature, and generate a trusted baseline snapshot of the target mobile device. The strategy configuration module is used to transmit the trusted benchmark snapshot to the server for integrity verification, generate an atomic control policy based on the verification result and preset compliance group rules, and distribute and configure the atomic control policy to the hardware abstraction layer of the target mobile device to obtain the configured atomic control policy; the atomic control policy includes context constraints, hardware resource objects and operation instruction dimensions; The data generation module is used to initiate a two-layer monitoring mechanism based on the configured atomic control strategy to capture the running data of the target mobile device and generate software and hardware interaction behavior data; the running data includes application programming interface call requests at the application layer and hardware input / output requests at the driver layer. The risk assessment module is used to input the software and hardware interaction behavior data into the risk arbitration module residing on the device, and perform pre-execution compliance verification on the software and hardware interaction behavior data in combination with the current device operating environment context to generate real-time risk assessment results. The emergency response module is used to respond to the real-time risk assessment result indicating the existence of violations, and to execute automated emergency response actions at the hardware abstraction layer that match the risk level according to the preset graded handling logic; the automated emergency response actions include blocking hardware driver calls, cutting off network communication, or performing a security wipe, so that the target mobile device enters a defensive protection state; The policy update module is used to extract the interception logs and risk feature data generated by the target mobile device under the defense protection state, feed the interception logs and risk feature data back to the server to generate a policy update package, and iteratively update the atomic control policy according to the policy update package.

Images