Anti-theft verification method and system

Abstract

The invention discloses an anti-theft verification method and system, and relates to the technical field of information security, a linked protection system is formed through three-level cooperative verification of a driving layer, a system layer and an application layer, and in the driving layer, an identification interface with read-only attributes is strongly coupled with hardware peripherals, so that the security of the system is improved. A unique identification code is generated through hard coding of a hardware register address, mirror image transplantation is blocked from a bottom layer, a hidden self-starting service of a system layer is operated preferentially at the initial stage of equipment starting, an unauthorized device cannot load a system function by detecting existence of an interface and legality of the identification code, and an application layer performs secondary verification before a core function is called. The sensitive operation is forbidden, the multi-level verification mechanism enables an attacker to simultaneously break through three levels of hardware binding, system startup protection and application function limitation, full-link security protection for preventing extraction, startup and use is constructed, and the uniqueness of the system and the application is effectively guaranteed.

Description

Technical Field

[0001] The present invention relates to the field of information security technology, and in particular to an anti-theft verification method and system. Background Art

[0002] As an important carrier of enterprises, the software systems and core applications of terminal devices face severe theft risks with the large-scale marketization of various embedded devices and consumer electronic devices. Competitors can cause unauthorized devices to run by unpacking system images and extracting firmware, leading to a series of problems such as core code leakage and user data security. Traditional single-dimensional protection methods are no longer able to cope with complex attack scenarios, and there is an urgent need to build a more efficient anti-theft system from the system architecture level.

[0003] Currently, the existing mainstream anti-theft solutions have three main deficiencies:

[0004] Single protection layer, easily bypassed: Existing solutions only implement protection at the application layer through key verification and license mechanisms. Malicious users can modify the verification logic through reverse engineering or exploit system vulnerabilities to bypass application layer restrictions. This fails to form a coordinated verification mechanism among drivers, systems, and applications.

[0005] Driver-level protection lacks strong hardware binding: Existing driver-level protection often uses modifiable software identifiers, which are not deeply bound to the physical characteristics of hardware peripherals. This allows images to be illegally burned to other devices. In addition, insufficient permission control on driver interfaces creates the risk of tampering by userspace programs.

[0006] In summary, existing technologies lack a layered and coordinated protection architecture and a deep binding mechanism between hardware and software, making it difficult to cope with increasingly complex software theft attacks. How to build a multi-level protection system covering the driver layer, system layer, and application layer to achieve unique binding between software and hardware and ensure that the verification process cannot be bypassed has become a technical problem that needs to be solved urgently. Summary of the Invention

[0007] The purpose of the present invention is to make up for the shortcomings of the existing technology and provide an anti-theft verification method and system, which can form an interlocking protection system through three-level collaborative verification of the driver layer, system layer, and application layer. At the driver layer, the read-only identification interface is strongly coupled with the hardware peripherals, and a unique identification code is generated by hard-coding the hardware register address and encryption to block image transplantation from the bottom layer. The hidden self-starting service of the system layer is preferentially run at the initial stage of device startup. By detecting the existence of the interface and the legitimacy of the identification code, it ensures that unauthorized devices cannot load system functions. The application layer performs a second verification before calling the core function and disables sensitive operations. This multi-level verification mechanism requires attackers to break through the three levels of hardware binding, system startup protection, and application function restriction at the same time, and builds a full-link security protection against extraction, startup, and use, effectively ensuring the uniqueness of the system and application.

[0008] In order to solve the above technical problems, the present invention provides the following technical solutions: On the one hand, an anti-theft verification method, the specific steps of the method are:

[0009] S100, driver layer interface integration: Integrate a special identification interface driver with read-only attributes in the device kernel code, define a unique interface name and identification code content, and set the interface to read-only attributes;

[0010] S200, interface and device binding: responsible for compiling the identification interface driver into the system image and establishing a strong coupling relationship between the driver and the device peripherals;

[0011] S300, bottom-level verification during system startup: After the device is powered on, the driver registers a read-only identification interface with the system proc directory, enters the system initialization phase, starts the hidden system auto-start service through the systemd service architecture, and reads the identification code in the interface;

[0012] S400, system layer verification: comparing and matching the read identification code with the security identification code stored in the kernel;

[0013] S500, application layer verification: After the system is started, the driver layer interface is verified twice when the application calls the API. When the identification code does not match the hardware fingerprint, the execution of the functional module is restricted.

[0014] Furthermore, the identification code content generated by the special identification interface in S100 is generated in the following manner:

[0015] When the device is started for the first time, hardware fingerprint information is collected, including the CPU serial number, baseband chip ID and memory unique identifier. A dynamic identification code is generated through a hash chain and encrypted and stored in the read-only memory area of ​​the driver layer. The interface is set to read-only attribute. After the driver is compiled, it is included with the system image, forming a strong coupling relationship between the driver layer and the device peripherals, making it impossible to directly port the image to non-company devices.

[0016] Furthermore, the read-only attribute of the interface in S100 is implemented through kernel-level protection:

[0017] During the driver initialization phase, when calling sysfs_create_file(), the file permission mask is set to S_IRUSR|S_IRGRP|S_IROTH(0444), prohibiting any user space write operation. The sysfs_create_file() function is used to create an interface file in the / sys virtual file system. By setting the file permission mask to 0444, only all users are allowed to read the file content.

[0018] Rewrite the write() and mmap() methods in the file_operations structure to force the return of the permission denied error code -EPERM, blocking the path to modify the interface content through system calls;

[0019] During the kernel compilation phase, a custom macro is enabled through the Kconfig option. During compilation, a read-only attribute is added to the memory area where the interface file is located. This marks the interface file as read-only in the system image and prevents it from being modified.

[0020] Furthermore, the specific binding process of forming a strong coupling relationship between the driver and the device peripheral in S100 is as follows:

[0021] The driver code hard-codes the hardware communication parameters of the device peripherals: for I2C devices, the slave address is preset to 0x50, and the device model is matched through the compatible field in the device tree. For SPI devices, the clock frequency is preset to 40MHz and the data bit width is 8 bits. The clock configuration and hardware compatibility are verified during driver initialization.

[0022] Perform hardware verification when the driver is loaded: send the command response code 0xAA55 to the peripheral register address 0x1001, read the return value to see if it is the response code 0x55AA, and if it is not 0xAA55 for three consecutive times, it is determined that the device is not our company's device and the driver initialization is terminated;

[0023] During the driver image compilation phase, the device hardware ID is bound to the driver binary file through a SHA-256 hash. The generated image file can only be decrypted and run on devices with a matching hash value.

[0024] Furthermore, the implementation of the hidden system self-start service in S300 further includes:

[0025] Implant a disguised process name in the systemd service configuration file, disguise the service process name as the system kernel process kworker, and set its startup priority to the highest level;

[0026] Through the kernel module signature verification mechanism, if the signature verification fails, the service will be refused to load;

[0027] When the service starts, a composite checksum based on the device location and the startup timestamp is dynamically generated and written to the kernel security log area.

[0028] Furthermore, the hidden system self-starting service in S300 runs before other system processes and has a hidden attribute to prevent tampering by a third party. The service first detects whether the identification interface exists. When it does not exist or the interface is unreadable, it is determined to be an unauthorized device and the device restart is immediately triggered. When the interface exists, the identification code in the interface is read.

[0029] Furthermore, when the S400 performs security identification code comparison, it decrypts the pre-stored reference identification code in the kernel, and compares and matches the read identification code with the reference value. When there is a match, the system is allowed to load drivers, modules and functional components normally. When there is no match, it is determined to be an unauthorized device, and the device is forced to restart and an exception log is recorded.

[0030] Furthermore, the interactive process of the application calling the API to perform secondary verification in S500 is as follows:

[0031] When the application calls the core API, it calls the system to obtain the identification interface identification code;

[0032] Extract hardware fingerprints at the application layer, including BIOS serial number and baseband chip ID;

[0033] The interface identification code is decrypted and compared with the hardware fingerprint. If the verification fails, the application will only allow the core functional module to perform restricted operations.

[0034] On the other hand, an anti-theft verification system includes components such as an identification interface module, a device binding driver module, a hidden service verification module, a system loading control module, and an application function permission module;

[0035] The identification interface module is deployed in the kernel layer of the device, contains a special identification interface with read-only attributes, stores a unique identification code, and releases read permissions only to the system and applications;

[0036] The device binding driver module is responsible for compiling the identification interface driver into the system image, establishing a strong coupling relationship between the driver and the device peripherals, ensuring that the image cannot be run on non-company devices, and preventing firmware extraction and theft from the bottom layer;

[0037] The hidden service verification module is based on the hidden self-starting service of the systemd architecture, and the existence of the identification interface is preferentially detected when the device starts;

[0038] The system loading control module decides whether to load the system functional components according to the signal of the hidden service verification module. Only when the verification passes, the driver, module and system service are allowed to start normally; otherwise, the system initialization process is blocked and the device is forced to enter the restart state.

[0039] The application function permission module is deployed at the application layer, and obtains an identification code through an identification interface before calling a core function, and compares it with a preset reference identification code value.

[0040] Compared with the existing technology, this anti-theft verification method and system has the following beneficial effects:

[0041] 1. The present invention forms an interlocking protection system through three-level collaborative verification of the driver layer, system layer, and application layer. At the driver layer, the read-only identification interface is strongly coupled with the hardware peripherals. The unique identification code is generated by hard-coding the hardware register address and encryption to block image transplantation from the bottom layer. The hidden self-starting service of the system layer is given priority to run at the initial stage of device startup. By detecting the existence of the interface and the legitimacy of the identification code, it ensures that unauthorized devices cannot load system functions. The application layer performs a second verification before calling the core function and disables sensitive operations. This multi-level verification mechanism requires attackers to break through the three levels of hardware binding, system startup protection, and application function restriction at the same time, building a full-link security protection against extraction, startup, and use, effectively ensuring the uniqueness of the system and application.

[0042] 2. The present invention achieves strong portability for multiple systems and multiple hardware platforms through standardized driver interface design and hardware verification logic. The identification interface driver adopts device tree parsing and pre-compiled macro definition technology to adapt to different kernel versions and system architectures. At the same time, the read-only interface of the driver layer performs read operations, the system layer verification is implemented through the systemd service, and the application layer function restriction is quickly completed through API calls. The overall solution has a very low impact on device performance and is suitable for resource-constrained embedded devices. In addition, the deep binding of hardware and software ensures that the system image cannot run on non-company devices, which not only ensures security but also takes into account the practicality and scalability of engineering applications.

[0043] Other advantages, objects and features of the present invention will be described in part in the following description and, in part, will be apparent to those skilled in the art based on an examination of the following or may be learned from the practice of the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] To more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. Those skilled in the art can also derive other drawings based on these drawings without inventive effort.

[0045] Figure 1 This is an operational flow chart of an anti-theft verification method;

[0046] Figure 2 This is a module composition diagram of an anti-theft verification system. DETAILED DESCRIPTION

[0047] In order to further illustrate the technical means and effects adopted by the present invention to achieve the predetermined purpose of the invention, the specific implementation methods, structures, features and effects of the present invention are described in detail below in conjunction with the accompanying drawings and preferred embodiments.

[0048] Example 1

[0049] This embodiment focuses on an anti-theft verification system, which aims to solve the problem that terminal product systems and applications are easily stolen, such as Figure 2 As shown, the system integrates an identification interface module, a device binding driver module, a hidden service verification module, a system loading control module, and an application function permission module. Through the collaborative work of the driver layer, the system layer, and the application layer, all-round protection of the system and applications is achieved. At the driver layer, a read-only interface driver with a unique identification code is integrated, the system layer uses a hidden self-starting service to perform underlying verification, and the application layer controls functional permissions based on the verification results. This embodiment elaborates on the working principle and mutual cooperation mechanism of each module.

[0050] During the device development phase of this embodiment, the identification interface module integrates a special identification interface driver into the device kernel code and defines a unique interface name to identify the special interface. When the device is started for the first time, the system collects hardware fingerprint information through a specific hardware interface function, uses the unique serial number acquisition function provided by the CPU to read the CPU serial number from the CPU internal register, and obtains the baseband chip ID through the driver interface function provided by the baseband chip. For the memory unique identifier, the unique identification code solidified inside the memory chip is read, and the collected CPU serial number, baseband chip ID and memory unique identifier are concatenated into a string as the input of the hash chain to generate a dynamic identification code. In order to further improve security, the dynamic identification code is encrypted and stored in the read-only memory area of ​​the driver layer to ensure that it will not be tampered with during the operation of the device. In order to set the interface to read-only attribute, Multiple protection measures are taken during the driver initialization phase. When the sysfs_create_file() function is called to create an interface file in the / sys virtual file system, the file permission mask is set to S_IRUSR|S_IRGRP|S_IROTH (i.e. 0444), which means that only all users are allowed to read the file content, and any write operation in user space is prohibited. The write() and mmap() methods in the file_operations structure are rewritten. When the user space program attempts to modify the interface content through a system call, the permission denial error code -EPERM is forced to be returned, thereby blocking the path to modify the interface content through a system call. During the kernel compilation phase, custom macros are enabled through the Kconfig option, and a read-only attribute is added to the memory area where the interface file is located during compilation, so that the interface file is marked as read-only in the system image and cannot be modified.

[0051] The driver code forms a strong coupling relationship with the device peripherals. For I2C devices, such as door lock control chips, the slave address is hard-coded as 0x50 in the driver code, and the device model is matched through the compatible field of the device tree to ensure that the driver is only loaded on the correct device. For SPI devices, the preset clock frequency is 40MHz and the data bit width is 8bit. When the driver is initialized, the clock configuration information in the hardware register is read to verify its compatibility with the preset value. When the driver is loaded, a hardware check is performed and the command response code 0xAA55 is sent to the peripheral register address 0x1001 of the door lock control chip, and then the return value is read. If the return value read for three consecutive times is not 0x55AA, then If it is determined to be a non-company device, the driver initialization process is terminated to prevent the device from loading the driver. During the driver image compilation stage, the device hardware ID (consisting of CPU serial number, motherboard model and other information) is hashed and bound to the driver binary file. The generated image file can only be decrypted and run on the device with a matching hash value, preventing the firmware from being extracted and used on other devices from the bottom layer. After the device is powered on, the identification interface driver registers a read-only identification interface with the system proc directory. This process is implemented through the proc_register() function in the kernel, which registers the interface related information (such as interface name, operation function pointer, etc.) in the proc file system, so that the system can access the interface during the startup process.

[0052] When the system enters the initial stage, the hidden service verification module starts the hidden system self-starting service through the systemd service architecture. In the systemd service configuration file, the developer implants a disguised process name and disguises the service process name as the system kernel process kworker. This can avoid being easily identified and attacked by malware. At the same time, its startup priority is set to the highest level to ensure that the service runs before other system processes. When the service starts, it first verifies itself through the kernel module signature verification mechanism. The kernel module signature is a security mechanism to prevent malicious modules from loading. When the developer compiles the service module, he uses the private key to sign the module. When the service is loaded, the system uses the corresponding public key for verification. If the signature verification fails, the service is refused to load to ensure the security of the system. During the startup process, the service , dynamically generates a composite checksum based on device location and startup timestamp, and the generated composite checksum is written to the kernel security log area, which is used to record key security information during the system startup process for subsequent auditing and tracking. The hidden system self-starting service has a hidden attribute to prevent third-party tampering. The service first detects whether the identification interface exists, and checks whether the corresponding interface file in the / proc directory exists by calling the access() function. If it does not exist or the interface is unreadable (for example, the file permission is modified and it cannot be read), it is determined to be a non-authorized device and the device restart is triggered immediately. This restart operation is achieved by calling the reboot() function, forcing the device to restart and preventing unauthorized devices from continuing to start the system. If the interface exists, the identification code in the interface is read to provide data for subsequent system-level verification.

[0053] The system loading control module reads the identification code in the identification interface based on the hidden system self-start service, and the system layer begins verification. In the kernel, the encrypted baseline identification code is stored in a hardware-protected memory area. During the comparison, the pre-stored baseline identification code is decrypted to obtain the baseline value. The read identification code is compared and matched with the baseline value. If the two match, the system is allowed to load drivers, modules, and functional components normally. The system will follow the preset startup process to load various drivers (such as network drivers and storage drivers), system modules (such as file system modules and process management modules), and functional components (such as door lock control services and user authentication services) in sequence, allowing the device to enter normal operation. If the comparison does not match, it is determined to be an unauthorized device, and the system will forcibly restart the device and record an exception log. The exception log is recorded in the device's non-volatile storage device (such as Flash). The log content includes the time when the identification code comparison failed and the device's current status information (such as network connection status and system running processes) to facilitate subsequent analysis of illegal access events.

[0054] After the system is started, the application function permission module is deployed at the application layer. In this embodiment, taking the mobile phone control application of the smart door lock device as an example, when the user calls the core API (such as the unlocking API) through the mobile phone application, the application calls the system to obtain the identification interface identification code. At the application layer, by calling the interface function provided by the system, the identification code is read from the identification interface file in the / proc directory. At the same time, the hardware fingerprint is extracted at the application layer, including the BIOS serial number (obtained by reading the system-specific BIOS information file) and the baseband chip ID (obtained with the help of the interface function provided by the system driver). The interface identification code is decrypted and compared with the hardware fingerprint. If the verification fails, the application will only allow the core function module to perform restricted operations. For example, for the unlocking API, when the verification fails, the application will refuse to execute the unlocking instruction and return an error prompt to the user interface, informing the user that there is a security risk on the device and the operation cannot be performed. At the same time, the application will record the verification failure event in the local log and upload it to the remote server via the network for administrator monitoring and management.

[0055] In summary, in the entire anti-theft verification process, the identification interface module, device binding driver module, hidden service verification module, system loading control module, and application function permission module work closely together. The identification interface module serves as the data source, stores the unique identification code and provides read permission, and provides basic data for the verification work of other modules. The device binding driver module tightly binds the identification interface driver to the device peripherals to ensure the uniqueness of the device from the bottom layer and prevent image transplantation. The hidden service verification module detects the identification interface at the initial stage of system startup and provides a decision basis for the system loading control module. The system loading control module decides whether to load the system function component according to the result of the hidden service verification module and controls the entire system. In the startup process, the application function permission module performs a secondary verification of the core functions at the application layer to ensure that only legitimate devices can use the complete application functions. When the device starts, the device binding driver module first compiles the identification interface driver into the system image and establishes a strong coupling relationship with the device peripherals. After the hidden service verification module is started, it detects the existence of the identification interface and the compliance of the identification code. If the verification passes, it sends a permission signal to the system loading control module. The system loading control module allows the system to load drivers, modules and functional components normally. When the application calls the core function, the application function permission module obtains the identification code through the identification interface, performs a secondary verification, and controls the execution permission of the application function according to the verification result.

[0056] Example 2

[0057] like Figure 1 As shown, this embodiment provides an anti-theft verification method for performing device reading and verification. The specific process is as follows:

[0058] When the device is powered on and starts up, the system registers a read-only identification interface: When the device is powered on and starts up, the read-only attribute special identification interface driver integrated into the device kernel code starts working. The driver registers the read-only identification interface with the system proc directory. This process is based on the systemd service architecture and uses the driver to complete the registration of the interface in the system directory, providing a data interaction channel for subsequent verification.

[0059] Detect whether there is an identification interface and read the content of the interface: The system enters the initial stage and starts the hidden system self-start service through the systemd service architecture. This service runs before other system processes and has hidden properties to prevent third-party tampering. After the service is started, first check whether the identification interface exists. If it does not exist or the interface is unreadable (such as insufficient permissions resulting in inability to read), it is determined to be an unauthorized device, and the device restart instruction is immediately triggered to restart the device to prevent illegal devices from continuing to start the system. If the interface exists, read the identification code in the interface and enter the next step of the verification process;

[0060] System services and peripheral modules are loaded normally (when the identification interface exists and is read normally): After the hidden system self-starting service successfully reads the identification code in the identification interface, it compares the read identification code with the security identification code stored in the kernel. If the two match, the device is determined to be legal and the system is allowed to load drivers, modules and functional components normally. System services and peripheral modules are loaded normally in the preset order, including network drivers, storage drivers, file system modules, process management modules, etc., so that the device enters normal operation. If the comparison does not match, it is determined to be an unauthorized device, and the device is forced to restart and an exception log is recorded. The exception log is recorded in the non-volatile storage device of the device and contains information such as the time when the identification code comparison failed and the device status.

[0061] Detect whether there is an identification interface, start the software application and read the content of the interface: After the system starts normally, the software application starts to start. When the application calls the core API, it will call the system to obtain the identification interface identification code. At the same time, the hardware fingerprint (including BIOS serial number and baseband chip ID) is extracted at the application layer, and the hardware fingerprint information is obtained through the interface function provided by the system driver;

[0062] Application-specified functions cannot be used (when the identification interface does not exist or the reading is abnormal): If the application finds that the identification interface does not exist or the reading is abnormal (for example, the read identification code does not match the hardware fingerprint) when obtaining the identification code, the device is determined to have a security risk and the application will only allow the core function module to perform restricted operations;

[0063] The application is fully functional and operating normally (when the identification interface exists and is read normally): When the identification interface identification code obtained by the application is successfully compared with the hardware fingerprint, it indicates that the device has passed the application layer verification and the application is fully functional and operating normally. Users can use the various functions of the application normally, including executing core business logic and accessing sensitive data, ensuring the security and normal use of the device and application.

[0064] The above description is merely a preferred embodiment of the present invention and does not constitute any form of limitation to the present invention. Although the present invention has been disclosed as above in terms of a preferred embodiment, it is not intended to limit the present invention. Any person skilled in the art can, without departing from the scope of the technical solution of the present invention, make some changes or modifications to equivalent embodiments using the technical contents disclosed above. However, any brief modifications, equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention are still within the scope of the technical solution of the present invention.

Claims

1. A method for verifying against theft, characterized in that: The specific steps of this method are: S100, driver layer interface integration: Integrate a special identification interface driver with read-only attributes in the device kernel code, define a unique interface name and identification code content, and set the interface to read-only attributes; S200, interface and device binding: responsible for compiling the identification interface driver into the system image and establishing a strong coupling relationship between the driver and the device peripherals; S300, bottom-level verification during system startup: After the device is powered on, the driver registers a read-only identification interface with the system proc directory, enters the system initialization phase, starts the hidden system auto-start service through the systemd service architecture, and reads the identification code in the interface; S400, system layer verification: comparing and matching the read identification code with the security identification code stored in the kernel; S500, application layer verification: After the system is started, the driver layer interface is verified twice when the application calls the API. When the identification code does not match the hardware fingerprint, the execution of the functional module is restricted.

2. The anti-theft verification method according to claim 1, characterized in that: The method for generating the identification code content driven by the special identification interface in S100 is: When the device is started for the first time, hardware fingerprint information is collected, including the CPU serial number, baseband chip ID and memory unique identifier. A dynamic identification code is generated through a hash chain and encrypted and stored in the read-only memory area of ​​the driver layer. The interface is set to read-only attribute. After the driver is compiled, it is included with the system image, forming a strong coupling relationship between the driver layer and the device peripherals, making it impossible to directly port the image to non-company devices.

3. The anti-theft verification method according to claim 2, characterized in that: The read-only attribute of the interface in S100 is implemented through kernel-level protection: During the driver initialization phase, when calling sysfs_create_file(), the file permission mask is set to S_IRUSR|S_IRGRP|S_IROTH(0444), prohibiting any user space write operation. The sysfs_create_file() function is used to create an interface file in the / sys virtual file system. By setting the file permission mask to 0444, only all users are allowed to read the file content. Rewrite the write() and mmap() methods in the file_operations structure to force the return of the permission denied error code -EPERM, blocking the path to modify the interface content through system calls; During the kernel compilation phase, a custom macro is enabled through the Kconfig option. During compilation, a read-only attribute is added to the memory area where the interface file is located. This marks the interface file as read-only in the system image and prevents it from being modified.

4. The anti-theft verification method according to claim 2, characterized in that: The specific binding process of the driver and the device peripherals in S100 to form a strong coupling relationship is as follows: The driver code hard-codes the hardware communication parameters of the device peripherals: for I2C devices, the slave address is preset to 0x50, and the device model is matched through the compatible field in the device tree. For SPI devices, the clock frequency is preset to 40MHz and the data bit width is 8 bits. The clock configuration and hardware compatibility are verified during driver initialization. Perform hardware verification when the driver is loaded: send the command response code 0xAA55 to the peripheral register address 0x1001, read the return value to see if it is the response code 0x55AA, and if it is not 0xAA55 for three consecutive times, it is determined that the device is not our company's device and the driver initialization is terminated; During the driver image compilation phase, the device hardware ID is bound to the driver binary file through a SHA-256 hash. The generated image file can only be decrypted and run on devices with a matching hash value.

5. The anti-theft verification method according to claim 1, characterized in that: The implementation of the hidden system self-start service in S300 further includes: Implant a disguised process name in the systemd service configuration file, disguise the service process name as the system kernel process kworker, and set its startup priority to the highest level; Through the kernel module signature verification mechanism, if the signature verification fails, the service will be refused to load; When the service starts, a composite checksum based on the device location and the startup timestamp is dynamically generated and written to the kernel security log area.

6. The anti-theft verification method according to claim 5, characterized in that: The hidden system self-start service in S300 runs before other system processes and has a hidden attribute to prevent third-party tampering. The service first detects whether the identification interface exists. If it does not exist or the interface is unreadable, it is determined to be an unauthorized device and the device restart is immediately triggered. If the interface exists, the identification code in the interface is read.

7. The anti-theft verification method according to claim 1, characterized in that: When the S400 performs security identification code comparison, it decrypts the pre-stored reference identification code in the kernel and compares and matches the read identification code with the reference value. When there is a match, the system is allowed to load drivers, modules and functional components normally. When there is no match, it is determined to be an unauthorized device, and the device is forced to restart and an exception log is recorded.

8. The anti-theft verification method according to claim 1, characterized in that: The interactive process of the application calling the API to perform secondary verification in S500 is as follows: When the application calls the core API, it calls the system to obtain the identification interface identification code; Extract hardware fingerprints at the application layer, including BIOS serial number and baseband chip ID; The interface identification code is decrypted and compared with the hardware fingerprint. If the verification fails, the application will only allow the core functional module to perform restricted operations.

9. An anti-theft verification system, applicable to an anti-theft verification method according to any one of claims 1 to 8, characterized in that: The components of this system include: identification interface module, device binding driver module, hidden service verification module, system loading control module, and application function permission module; The identification interface module is deployed in the kernel layer of the device, contains a special identification interface with read-only attributes, stores a unique identification code, and releases read permissions only to the system and applications; The device binding driver module is responsible for compiling the identification interface driver into the system image, establishing a strong coupling relationship between the driver and the device peripherals, ensuring that the image cannot be run on non-company devices, and preventing firmware extraction and theft from the bottom layer; The hidden service verification module is based on the hidden self-starting service of the systemd architecture, and the existence of the identification interface is preferentially detected when the device starts; The system loading control module decides whether to load the system functional components according to the signal of the hidden service verification module. Only when the verification passes, the driver, module and system service are allowed to start normally; otherwise, the system initialization process is blocked and the device is forced to enter the restart state. The application function permission module is deployed at the application layer, and obtains an identification code through an identification interface before calling a core function, and compares it with a preset reference identification code value.

Images