Anti-cracking method for intelligent device, intelligent device and system

Abstract

The invention discloses an intelligent device anti-cracking method, an intelligent device and a system, and the intelligent device anti-cracking method comprises the steps: obtaining the current cutting frequency of device firmware when a system program is started; when the current cutting frequency reaches a cutting frequency threshold value, acquiring an authorization instruction from the server; and if an authorization instruction returned by the server is received, the intelligent device and the system program operate normally. By means of the anti-cracking method for the intelligent device, the cracking difficulty of the system program and the intelligent device is improved, and the safety of the system program and the intelligent device is guaranteed.

Description

Technical Field

[0001] The present application belongs to the technical field of computers and intelligent devices, and in particular, relates to a method, intelligent device and system for preventing intelligent devices from being cracked. Background Art

[0002] With the continuous evolution of hacking technology, the problem of system program cracking is becoming increasingly serious. Common system program cracking methods, such as decompiling and cracking system programs and tampering with repackaging and flashing, replacing system programs and background services, etc., will destroy the security of system programs or systems and increase the possibility of losses to related parties. In order to protect the interests of related parties, developers urgently need to take a series of effective anti-cracking measures to ensure the safe and reliable operation of system programs. Summary of the invention

[0003] The embodiments of the present application provide a method, a smart device and a system for preventing a smart device from being cracked. By adopting the method for preventing a smart device from being cracked according to the embodiments of the present application, the difficulty of cracking a system program can be increased, thereby ensuring the security of the system program.

[0004] In a first aspect, an embodiment of the present application provides a method for preventing a smart device from being cracked, wherein the smart device includes device firmware and a system program, and the method includes:

[0005] When the system program is enabled, get the current cutting count of the device firmware;

[0006] When the current number of cuts reaches the cut number threshold, obtain the authorization instruction from the server;

[0007] If the authorization instruction returned by the server is received, the smart device and system program will operate normally.

[0008] Optionally, obtain authorization instructions from the server, including:

[0009] Encrypt the current number of cuts, the authorization number of the device firmware, and the device information of the smart device to generate an authorization request;

[0010] Send the authorization request to the server to obtain the authorization instruction from the server.

[0011] Optionally, according to the current number of cuts, before obtaining the authorization instruction from the server, the method further includes:

[0012] If the firmware version of the device firmware is higher than the preset authorized firmware version, determining whether the device firmware is authorized;

[0013] If the device firmware has been authorized and the current number of cuts reaches the threshold of the number of cuts of the device firmware, the step of obtaining the authorization instruction from the server is executed;

[0014] If the device firmware is not authorized, perform authorization configuration on the device firmware.

[0015] Optionally, when the current number of cuts reaches the number of cuts threshold, after obtaining an authorization instruction from the server, the method further includes:

[0016] If the authorization instruction returned by the server is not obtained within the preset time, a prompt message will be provided that the smart device needs to be connected to the Internet to obtain the authorization instruction.

[0017] Optionally, the method further includes:

[0018] When the system program and the device firmware are authorized and bundled, the digital type provided by the device firmware is obtained through the system program, and a signature key is generated according to the digital type and the software signature;

[0019] Obtain the dynamic key generated by the device firmware, and obtain the corresponding encrypted string based on the dynamic key;

[0020] Generate verification information based on the signature key and the encrypted string;

[0021] The verification information is sent to the device firmware for verification, so that after the device firmware verification succeeds, the authorization binding of the system program and the device firmware is completed.

[0022] Optionally, the method further includes:

[0023] When the system program is authorized and bundled with the system service of the smart device, the application signature of the system program is verified, and the preset function library is loaded after the application signature verification passes to support the operation of the system program;

[0024] When the system program obtains the device information of the smart device, the application signature is verified again. After the application signature is verified again, the device information is encrypted with the public key to complete the authorization bundling of the system program and the system service.

[0025] Optionally, the method further includes:

[0026] When the system program is authorized and bundled with the Android system of the smart device, the system signature of the Android system is obtained, and the apk file of the system program is re-signed according to the system signature to complete the authorization bundling of the system program and the Android system.

[0027] Optionally, the method further includes:

[0028] Before burning the device firmware into a set of chips, encrypt the device firmware and generate an encryption key for the device firmware;

[0029] storing encryption keys on another set of chips;

[0030] When the smart device is running, it needs to read the encryption key from another set of chips for security verification.

[0031] In a second aspect, an embodiment of the present application provides a smart device, comprising: a processor; and a memory storing a computer program, wherein when the computer program is executed by the processor, the processor executes any of the above-mentioned methods for preventing the smart device from being cracked.

[0032] On the third aspect, an embodiment of the present application provides a system for preventing a smart device from being cracked, wherein the smart device includes device firmware, system programs, system services, and an Android system, wherein the device firmware and the system program are authorized to be bundled, the system program and the system service are authorized to be bundled, and the system program and the Android system are authorized to be bundled, and the authorization bundling is implemented by a method for preventing a smart device from being cracked based on any of the above items.

[0033] The method for preventing smart devices from being cracked provided in the embodiment of the present application configures a limit on the number of times the device firmware is cut, so that when the current number of cuts of the device firmware reaches the threshold number of cuts, the authorization instruction is re-obtained from the server, thereby limiting the possibility of the software being cracked. In addition, when the authorization instruction returned by the server is received, the smart device and the system program run normally, and the authorization bundling of the system program and the device firmware is realized, which greatly reduces the risk of the system program being cracked and improves the security of the system program and the smart device. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The technical solution and beneficial effects of the present application will be made apparent by describing in detail the specific implementation methods of the present application in conjunction with the accompanying drawings.

[0035] Figure 1 It is a schematic diagram of the binding verification of the device firmware and the server in the method for preventing the smart device from cracking provided by the embodiment of the present application;

[0036] Figure 2 This is a first flow chart of the method for preventing a smart device from being cracked provided by an embodiment of the present application;

[0037] Figure 3 It is a flowchart of when a system program obtains an authorization instruction from a server in a method for preventing a smart device from cracking provided in an embodiment of the present application;

[0038] Figure 4 This is a second flow chart of the method for preventing a smart device from being cracked provided in an embodiment of the present application;

[0039] Figure 5 It is a schematic diagram of bundling verification of device firmware and system program in the method for preventing smart device cracking provided by an embodiment of the present application;

[0040] Figure 6A schematic diagram of the first structure of the smart device provided in the embodiment of the present application;

[0041] Figure 7 A second structural diagram of the smart device provided in the embodiment of the present application;

[0042] Figure 8 A schematic diagram of the structure of a system for preventing smart device cracking provided in an embodiment of the present application. DETAILED DESCRIPTION

[0043] Please refer to the drawings, where the same component symbols represent the same components. The principle of the present application is illustrated by implementing it in an appropriate computing environment. The following description is based on the illustrated specific embodiments of the present application, which should not be considered as limiting other specific embodiments of the present application that are not described in detail herein.

[0044] Here are three common software cracking methods:

[0045] The first software cracking method: obtaining the chip firmware program by reading the electronic hardware chip. Specifically, the cracker determines the electronic hardware chip containing key information in the target smart device. Use professional hardware reading technology and tools to try to establish a connection with the chip. Break through the chip's security protection mechanism (if any) and successfully read the data in the chip. Identify and extract the chip firmware program from the read data. The firmware program may contain the device's key operating logic, algorithms, and interface information for interacting with the software. The cracker can reverse engineer the firmware program, analyze the code and data therein, to find the software's security mechanism defects and crack it. The cracker can also analyze the obtained firmware program to find loopholes or exploitable parts in it for further attacks or illegal use. For example, if there are security vulnerabilities in the chip firmware, the cracker can gain control of the device by attacking these vulnerabilities, thereby affecting the normal operation and security mechanism of the software. For example, exploiting a buffer overflow vulnerability in the firmware to execute malicious code to bypass the software's security protection.

[0046] The second software cracking method: decompile and crack the App and tamper with it to repackage and flash the device. Taking feedback cracking as an example, the cracker can obtain the installation file of the App by extracting it from the installed device or downloading it from the Internet. Use the decompilation tool to decompile the installation file of the App and convert it from binary code to readable source code. By analyzing the decompiled source code, you can understand the functional structure, business logic, and interaction method of the App with the server. Tamper with the source code according to the purpose of the cracking, which may include removing restricted functions, adding malicious code, modifying the interface display, etc. Repackage the modified source code into a new App installation file. Install this repackaged App on the target device, or integrate it into the device's system by flashing the device to replace the original App. In this way, the cracked App can be run on the device to achieve the illegal purpose of the cracker.

[0047] The third software cracking method: directly replace the App and background services to completely separate them from the original system. Taking feedback cracking as an example, the cracker first conducts in-depth research on the App and its system to determine the functions, structure, and interaction methods of its App and background services with the device. Select appropriate App and background service solutions to replace the original App and background services in the target system. The selected App and background services can be software components with similar functions developed by themselves or obtained from other channels. By modifying the operating system of the device, replacing it with a software installation tool, or remotely replacing it through a network attack, the original App and background services in the target system are replaced and completely replaced by new software components. Since the new App and background services are not controlled by the original system, the cracker can freely operate and analyze them without worrying about being detected or restricted by the original system. For example, the cracker can modify the code of the new App, add malicious functions, or obtain sensitive information.

[0048] The fourth software cracking method: Analyze and intercept the submission request so that the App does not deduct the number of times or tamper with the number of times. Taking Edraw Feedback cracking as an example, the cracker observes the operation process of the target App while using it, especially focusing on the links involving the submission request of the number of times. Use network analysis tools or other technical means to intercept and monitor the communication between the App and the server. When the App submits a request for the number of times to the server, the cracker tries to intercept this request. Analyze the intercepted request to understand its format, parameters and communication protocol. According to the analysis results, the App does not deduct the number of times or tamper with the number of times by modifying the request data or forging the response. In this way, the cracker can use certain functions of the App without restrictions without complying with normal usage rules.

[0049] In view of the various software cracking methods provided above, the embodiments of the present application provide corresponding technical solutions, which prevent the smart device and its system program from being cracked by building relevant communication methods among smart devices, device firmware, APP, and server.

[0050] Device firmware refers to software programs stored in a specific storage chip inside a smart device. Device firmware is usually responsible for basic device function control, such as starting the device, initializing hardware, managing power, etc. APP (system program) is software installed on the device that provides users with various specific functions and services. App interacts with the device through the Android system and uses the hardware functions of the device to realize its own functions.

[0051] On the one hand, the technical solution provided in the embodiment of the present application configures the binding verification of the device firmware and the server. Figure 1 , Figure 1 It is a schematic diagram of the bundling verification of the device firmware and the server in the method for preventing the smart device from cracking provided in an embodiment of the present application.

[0052] First, the number of cuts is controlled for the device firmware. When the device firmware reaches a certain number of cuts, it must re-acquire authorization through the network server, that is, perform a flush authorization operation.

[0053] During the binding verification process between the device firmware and the server, when the system program is enabled, the current number of cuts of the device firmware is obtained, and when the current number of cuts reaches the cut number threshold, an authorization instruction is obtained from the server according to the current number of cuts.

[0054] The server receives the current cutting times, and determines the device status of the smart device according to the current cutting times and the historical cutting times of the device firmware, so as to generate an authorization instruction to return when the device status is normal.

[0055] The software receives the authorization instruction returned by the server, and completes the authorization binding between the device firmware and the server according to the authorization instruction.

[0056] In the embodiment of the present application, the device firmware and the server are authorized to be bundled, so that the system program can run normally only after the device firmware and the server have successfully performed authorization verification. This effectively prevents unauthorized devices from using the system program and reduces the possibility of illegal copying and use of the system program. In addition, a key security line is added to the system program, so that when crackers try to crack the system program, they not only need to break through the security mechanism of the system program itself, but also have to deal with the authorization association with the server, which greatly increases the difficulty of cracking, thereby improving the security of the system program.

[0057] The technical solution for the bundled verification of device firmware and server is described in detail below. Figure 2 , Figure 2 This is a first flow chart of a method for preventing a smart device from being cracked provided by an embodiment of the present application. The method for preventing a smart device from being cracked can be applied to a system program. The process of the method for preventing a smart device from being cracked may include:

[0058] 101. When the system program is enabled, obtain the current cutting times of the device firmware;

[0059] 102. When the current number of cuts reaches the cut number threshold, obtain an authorization instruction from the server;

[0060] 103. If the authorization instruction returned by the server is received, the smart device and the system program operate normally.

[0061] In this embodiment, the object supported by the device firmware may be a system program. The system program records the current number of cuts of the device firmware, and determines whether the current number of cuts reaches the number of cuts threshold of the device firmware. The number of cuts threshold may be determined based on the total authorized number of cuts of the device firmware. For example, 90% of the total authorized number of cuts is set as the number of cuts threshold. In other words, if the total authorized number of cuts of the device firmware is 100, if the current number of cuts indicates that 90 cuts have been made, and the remaining number of cuts is 10, it means that the current number of cuts of the device firmware has reached the number of cuts threshold. At this point, it is necessary to re-obtain the authorization instruction from the server for authorization. If the authorization instruction is not re-obtained from the server, the system program cannot be used normally.

[0062] When the system program receives the authorization instruction returned by the server, the smart device and the system program can operate normally.

[0063] In some embodiments, in step 102, obtaining an authorization instruction from the server according to the current number of cuts includes:

[0064] Encrypt the current number of cuts, the authorization number of the device firmware, and the device information of the smart device to generate an authorization request;

[0065] Send the authorization request to the server to obtain the authorization instruction from the server.

[0066] First, the embodiment of the present application sets a limit on the number of cuts for the device firmware. For newly upgraded firmware, when there is no authorization, the relevant information about the number of cuts authorized for the device firmware is obtained by reading specific instructions, such as "BD:110,1;". After reading the specific instructions, the relevant information about the number of cuts authorized is verified. If the verification result feedback that the authorized number of cuts is 0, it is determined that the device firmware is newly upgraded and the number of cuts of the device firmware needs to be authorized. In this way, it is ensured that the smart device can use the system program normally.

[0067] Among them, when the instruction "BD: 110, 1;" is sent, if "RCMD = 110, 1, 1;" is returned, it means that the authorized number of cuts is 0, and the device firmware has not set the authorization for the number of cuts. By sending monitoring instructions and returning verification results in this way, the authorization status of the device firmware for the number of cuts can be accurately detected.

[0068] Then, when the system program is enabled, the current number of cuts of the device firmware is obtained, that is, the current number of cuts of the device firmware that has been authorized for the number of cuts, and when the current number of cuts reaches the threshold of the number of cuts, an authorization request is generated according to the current number of cuts, device information and authorization number, and the authorization request is sent to the server, and the authorization request is used to apply for an authorization instruction from the server. By generating an authorization instruction, the security of data transmission such as the current number of cuts, device information and authorization number can be guaranteed.

[0069] Among them, when generating an authorization request according to the current number of cuts, device information and authorization number, it can be generated in an encrypted manner, and the encryption method includes but is not limited to the AES encryption algorithm (a block cipher algorithm that divides data into blocks of fixed size for encryption), the DES encryption algorithm (a symmetric encryption algorithm that uses a 56-bit key to encrypt a 64-bit data block), the RSA encryption algorithm (Rivest-Shamir-Adleman, using a pair of keys, i.e., a public key and a private key), etc. For example, first determine a key of a suitable length (such as 128 bits, 192 bits or 256 bits). Combine the number of cuts, device information and authorization number in a certain format, for example, connect them in a specific order into a string or a binary data block. Then use the AES encryption algorithm to encrypt the combined data to obtain an encrypted authorization request. For another example, organize the number of cuts, device information and authorization number into a data format suitable for encryption, and then encrypt them using the DES or 3DES algorithm. For example, first obtain the public key of the server, then convert the number of cuts, device information and authorization number into a format suitable for encryption (such as digital form or a specifically encoded string form), and finally use the RSA algorithm and the server public key to encrypt and generate an encrypted authorization request.

[0070] Exemplarily, the current number of cuts, device information and authorization number can also be encrypted using the MD5 algorithm, and then encrypted using the RSA algorithm to generate an authorization request and submit it to the server. The server is used to generate a TOKEN based on the received authorization request and return it to the system program. After the system program obtains the TOKEN, it can use the TOKEN to access other encrypted interfaces. Among them, the TOKEN can be used as a credential for the system program to subsequently access other encrypted interfaces, ensuring that only authorized system programs can access the resources of the server. The parameters and return data of these interfaces are encrypted using different RSAs, further enhancing the security of data transmission. Different interfaces may use different RSA keys to encrypt and decrypt data to ensure the confidentiality and integrity of data during transmission.

[0071] In some embodiments, see Figure 3 , Figure 3 It is a flowchart of the system program running in the method for preventing smart device cracking provided in an embodiment of the present application.

[0072] Step 102 includes:

[0073] 1021. Determine whether the firmware version of the device firmware is higher than the preset authorized firmware version;

[0074] If yes, then execute step 1022 to determine whether the device firmware is authorized;

[0075] If the device firmware is authorized, then execute step 1023 to determine whether the current number of cuts reaches the cutting number threshold;

[0076] If yes, execute step 1024, call the API interface to send an authorization request to the server to obtain an authorization instruction;

[0077] If not, step 1025 is executed, and the smart device and the system program run normally. The system program is installed on the smart device.

[0078] If the firmware version of the device firmware is not higher than the preset authorized firmware version, the process ends, or a prompt message for upgrading the firmware version is output.

[0079] If the device firmware is not authorized, authorization configuration is performed on the device firmware, that is, the step of authorizing the number of times of the device firmware is performed.

[0080] In some embodiments, before executing step 1024, the method further includes:

[0081] 1026. Determine whether the smart device is connected to the Internet;

[0082] If yes, execute step 1024, call the API interface to send an authorization request to the server to obtain an authorization instruction;

[0083] If not, execute step 1027 to provide a prompt message that the smart device needs to be connected to the Internet to obtain the authorization instruction.

[0084] In this embodiment, the method of providing prompt information that the smart device needs to be connected to the Internet to obtain the authorization instruction includes but is not limited to: pop-up prompt, voice prompt, text prompt, SMS prompt, telephone prompt, etc.

[0085] For example, when the current number of cuts is equal to the threshold number of cuts, the smart device may be forced to connect to the Internet to obtain the authorization instruction, thereby ensuring that the smart device can perform authorization interaction with the server in a timely manner.

[0086] In some embodiments, step 102 further includes:

[0087] 104. If the authorization instruction returned by the server is not obtained within the preset time, a prompt message is provided that the smart device needs to be connected to the Internet to obtain the authorization instruction.

[0088] The preset duration can be 5 minutes, 10 minutes, 15 minutes, etc., and can be configured according to actual needs.

[0089] In some embodiments, the above-mentioned cutting number threshold can be adjusted according to the total authorized cutting number.

[0090] For example, for device firmware with a large number of offline cutting times, a higher total authorized cutting number can be set, such as increasing from the original 1,000 times to 10,000 times. When the current cutting number reaches 90% of the total authorized cutting number, it is necessary to connect to the Internet to obtain new authorization instructions.

[0091] For another example, for device firmware that is frequently cut, the total authorized cut times can be dynamically adjusted based on the recent cut frequency. For example, based on 1,000 times, when the cut frequency is high, the total authorized cut times can be increased, and when the cut frequency is low, the total authorized cut times can be decreased. The adjustment range can be determined based on the difference between the cut frequency and the basic cut frequency. The larger the difference, the larger the adjustment range, and the smaller the difference, the smaller the adjustment range.

[0092] For example, the total authorized cutting times can be manually adjusted. For smart devices that have been authorized by the cutting times, the total authorized cutting times can be modified by the developer. For example, the total authorized cutting times of a smart device are set to 1,000 times in advance, and the background monitors that the smart device has used 10 cutting times. At this time, the total authorized cutting times are quite different from the actual cutting times. In order to avoid wasting resources, the developer can modify the total authorized cutting times to 100 times. Of course, the user can also apply to adjust the total authorized cutting times.

[0093] For some smart devices that are offline, it is impossible to obtain authorization instructions from the server. The backend system has the ability to monitor the online status of smart devices in real time or regularly. When the backend system finds that a device is offline and unauthorized, the backend system dynamically generates authorization instructions based on preset authorization rules and algorithms. Then send the authorization instructions to the smart device through appropriate channels. For example, the channel for sending authorization instructions is to send the authorization instructions to the customer's registered email address via email, and explain in the email how to perform authorization operations on the recharge page. For example, the next time the customer logs in to the system program or website associated with the backend, a prompt window will pop up to inform the customer that there is an unauthorized device, and the authorization instructions and a link to guide the customer to the recharge page for authorization will be displayed in the window.

[0094] In some embodiments, in step 103, when the system program receives the authorization instruction returned by the server through the API interface, it also detects whether an auxiliary instruction returned by the server is received. If an auxiliary instruction returned by the server is received, the auxiliary instruction is passed to the device firmware. After successfully sending the auxiliary instruction to the device firmware, the system program immediately calls back the interface to inform the server that the auxiliary instruction has been sent. A specific notification message is sent to the server, including information such as the device identification and instruction sending status. After the server receives this notification message, it can understand that the system program has completed the sending operation of the auxiliary instruction, so that subsequent processing can be performed.

[0095] In some embodiments, the system program interface can also display information related to the authorized number of cuts. For example, when it is necessary to display system information, the corresponding function or module is called to obtain the integrated string. If the remaining number is 0, it is displayed in the format of "v24.05(9)(0)"; if the number of authorizations is not set (it may be a new device or the authorization setting has not been performed yet), it is displayed as "v24.05(9)(00)"; if it is authorized and there are 580 times left, it is displayed as "v24.05(9)(580)".

[0096] In some embodiments, when the system program detects the firmware version of the device firmware, it is also necessary to determine whether a firmware version rollback has occurred. Among them, a firmware version recording mechanism is pre-established on the smart device, and the firmware version number and related PG header information after each successful upgrade can be stored in the device's non-volatile memory (such as a specific area in the flash memory). When the device is started or any firmware-related operation is performed, first verify whether the current firmware version is consistent with the version in the record. If it is found that the version is lower than the version in the record, that is, a firmware rollback may have occurred, and corresponding measures should be taken at this time, such as preventing the device from starting, prompting the user to re-upgrade the correct firmware, or sending an alarm notification to the administrator. In this way, the authorization request is smoothly sent to the server.

[0097] A technical solution for bundled verification of device firmware and server. Another method for preventing smart devices from being cracked is also provided here. Figure 4 , Figure 4 1 is a second flow diagram of the method for preventing a smart device from cracking provided in an embodiment of the present application. The method for preventing a smart device from cracking can be applied to a server. The process of the method for preventing a smart device from cracking may include:

[0098] 201. When receiving the current cutting number of the device firmware, determine the device state of the smart device according to the historical cutting number and the current cutting number of the device firmware, where the device state includes a normal state and an abnormal state;

[0099] 202. If the device status is abnormal, the normal operation of the smart device and system programs is restricted;

[0100] 203. If the device status is normal, generate an authorization instruction and return it to the system program.

[0101] After receiving the authorization request submitted by the system program, the server obtains the current number of cuts of the device firmware and other data by parsing the authorization request and saves it in the data table. Then, the server adds the current number of cuts and the number of historical cuts recorded in the last upload to obtain a total number of cuts. Then, the server compares this total number of cuts with the total number of cuts set in the background.

[0102] If the sum of the number of cuts is greater than the total number of cuts, the server will determine that the device status of the smart device is abnormal, and will not generate an authorization instruction, nor will it send the authorization instruction to the system program, and the system program and the smart device cannot operate normally. If the sum of the number of cuts is not greater than the total number of cuts, the server will determine that the device status of the smart device is normal, and will generate an authorization instruction, and send the authorization instruction to the system program, and the system program will pass the authorization instruction to the device firmware, and the device firmware can support the normal operation of the system program.

[0103] Exemplarily, the current number of cuts is the number of cuts for the first upload. At this time, the server only needs to save the current number of cuts in the data table.

[0104] In some embodiments, generating the authorization instruction in step 203 and returning it to the system program includes:

[0105] Get the digital type corresponding to the authorization number of the device firmware;

[0106] Generate authorization instructions based on the current cutting times, device information of the device firmware, and digital type;

[0107] Returns authorization instructions to the device firmware.

[0108] In this embodiment, the server can obtain the authorization request sent by the system program through the API interface. The authorization request is obtained by encrypting the current number of cuts, device information and authorization number. The server reads the authorization number and converts it into a digital type. Then, add 1 to this number and perform a format conversion to obtain a new number. At the same time, determine the current number of cuts authorized by the device firmware (such as 1000 times) and obtain the device information (such as PID code). Next, call the authorization tool to obtain the authorization instruction based on this information. This authorization instruction is returned to the system program in an encrypted manner. The system program obtains the authorization instruction and decrypts it and sends it to the device firmware.

[0109] Furthermore, the server sends the authorization instruction to the system program, which sends it to the device firmware. The system program determines whether the authorization is successful based on the string corresponding to the returned authorization instruction. If so, the result of successful authorization is submitted to the server. When the server receives the result of successful authorization sent by the system program, it records the successful sending status of the authorization instruction. If the server does not receive the result of successful authorization sent by the system program, it also records the failed sending status of the authorization instruction.

[0110] The data table on the server backend records relevant data, which can be queried based on device information SN (serial number) and status to obtain corresponding reports, making it convenient for administrators and technicians to quickly understand the usage of smart devices, authorization status and other related information.

[0111] Exemplarily, the authorization instruction may be generated by an authorization tool, which may be integrated in the server or may communicate with the server.

[0112] First, the authorization tool is responsible for obtaining the system environment hardware information and performing encryption processing with the MD5 algorithm. Then, the authorization tool sends the processed encrypted hardware information to the authorization tool. MD5 (Message-Digest Algorithm 5) is a widely used cryptographic hash function that can generate a 128-bit (16-byte) hash value.

[0113] When the authorization tool generates the authorization instruction based on the encrypted hardware information, it also passes the device information (which may be some parameters or identifiers), the authorization number, the current number of cuts, etc. through the authorization tool to generate a new authorization instruction. In this way, the authorization instruction is associated with the specific device hardware, improving the security and uniqueness of the authorization.

[0114] Finally, the authorization tool reads the authorization instruction and runs it to complete the entire authorization process.

[0115] For example, if the authorization tool fails to generate an authorization instruction, the authorization tool may also send a warning text message to notify a technician so that the technician can handle the problem in a timely manner.

[0116] In some embodiments, step 202 further includes:

[0117] Provide prompt information that requires the developer to unlock the device;

[0118] Receive the unlocking instruction sent by the development end, and unlock the device firmware according to the unlocking instruction, wherein the unlocking instruction is obtained by a single dynamic encryption based on the device information.

[0119] In this embodiment, if the device status is determined to be abnormal, the server sends a prompt message to the system program that the developer needs to unlock the device. On the other hand, the server sends an asynchronous email to notify the developer using the developer, so that the developer can promptly check the abnormal status and analyze the cause.

[0120] Among them, the causes of abnormal status include data transmission errors, equipment failure, malicious tampering, etc.

[0121] In addition, when the device status is determined to be abnormal, the system program can be locked first to prevent the potential risks that may be caused by the continued operation of the system program. When the system program is locked, the user needs to contact the developer to solve the problem through various channels, such as customer service hotline, email, online support platform, etc.

[0122] After receiving the user's request, the developer will remotely send the unlock command. The unlock command is dynamically encrypted and bundled with the device firmware. In this way, each unlock command is generated for a specific device and is encrypted to ensure security.

[0123] Secondly, to prevent the unlock command from being reused, the unlock command is set to expire after use. This can prevent the unlock command from being maliciously saved and abused, improving the security of the device. At the same time, the expired unlock command can also prompt the user to contact the developer in time when the device becomes abnormal again, rather than trying to use the expired unlock command for illegal unlocking.

[0124] In some embodiments, in order to better manage and control the use of system programs, each released system program needs to be registered in the cloud. Cloud registration can record the version information, release time, developer information, etc. of the system program, and can also verify the legitimacy of the system program. If an unregistered system program is found to attempt to access the server, the server can reject its request to improve the security of the system.

[0125] In some embodiments, the server also monitors and screens the active status of the smart devices associated with it. The active status of the smart device can be determined by determining whether the smart device has communicated with the server within a certain period of time, whether there is data upload or operation record, etc. If the smart device has communicated with the server within a certain period of time or has data upload or operation record, it is determined that the smart device is in an active state.

[0126] For the selected active devices, further statistics are collected on the smart devices that have not cut data recently. For example, statistics can be collected on the smart devices that have not cut data in the past week or month to quickly locate the devices that may have problems.

[0127] Then, by analyzing the status information, the last active time, historical operation records, etc. of the smart device that may have problems, it is determined whether the smart device has a fault, whether it is being used illegally, or whether there are other abnormal conditions.

[0128] When a problematic smart device is found, the backend returns a success status to the request to access the device data, but the data list is empty, in order to inform the system program that there is a problem with the device and no data is available.

[0129] After the system program receives a successful response from the server but the data list is empty, it automatically clears the relevant page data. This can prevent users from seeing erroneous or invalid data on the system program and improve the user experience. At the same time, the system program can take further measures, such as disabling the relevant functions of the device, making it impossible to use the device. This can be achieved by setting the device status flag in the system program or directly blocking the device's operation interface. For example, in the device list page of the system program, the problematic device is marked as unavailable and the user is prohibited from operating it.

[0130] As mentioned above, the embodiment of the present application performs binding verification between the device firmware and the server to prevent the device from being separated from the server, implements strict management and control of the number of device firmware cuts, ensures that the use of the device firmware is within the legal authorization scope, and at the same time improves the security of the system program to prevent unauthorized use and cracking of the system program.

[0131] On the other hand, the technical solution provided in the embodiment of the present application configures the authorization bundling of device firmware and system program. Figure 5 , Figure 5 It is a schematic diagram of the bundling verification of device firmware and system program in the method for preventing smart device cracking provided in an embodiment of the present application.

[0132] Among them, the system program is used to obtain the digital type and dynamic key provided by the device firmware to generate a signature key according to the digital type and software signature, and generate verification information according to the encrypted string corresponding to the signature key and the dynamic key, and send the verification information to the device firmware for verification.

[0133] The device firmware is used to perform reverse verification and comparison on the verification information, and to authorize and bundle the system program after the verification is successful.

[0134] The technical solution for bundled verification of device firmware and system programs is described in detail below. The method for preventing smart devices from being cracked provided by the embodiment of the present application also includes:

[0135] 301. Obtain the digital type provided by the device firmware, and generate a signature key according to the digital type and the software signature;

[0136] 302. Obtain a dynamic key generated by the device firmware, and obtain a corresponding encrypted string according to the dynamic key;

[0137] 303. Generate verification information according to the signature key and the encrypted string;

[0138] 304. Send the verification information to the device firmware for verification, so that after the device firmware verification succeeds, the authorization binding of the system program and the device firmware is completed.

[0139] This method is applied to system programs. The digital type provided by the device firmware is used as a unique identifier, also known as SSN, which consists of 9 digits. The software signature can be a SHA signature, which is a digital signature technology based on the SHA algorithm and is efficient and secure. The signature key generated according to the digital type and software signature is 10 digits. If it is less than 10 digits, a 10-digit signature key can be formed by adding 0 to the front of the string. For example, the signature key is "0456477993".

[0140] After obtaining the dynamic key generated by the device firmware, the dynamic key is split into a number, for example, the dynamic key "0464523395" is split into a number and "464523395" is used as the subscript. Then, specific characters or strings are extracted from the split dynamic key as the encrypted string, such as "474767" as the encrypted string.

[0141] When generating verification information based on the signature key and the encrypted string, an encryption algorithm can be used for processing. For example, the signature key, the encrypted string and a randomly generated number are used for encryption operations to generate verification information. By introducing random numbers to encrypt and generate verification information, the encryption strength of the verification information can be increased, preventing crackers from cracking the verification information by analyzing fixed encryption patterns.

[0142] Exemplarily, the encrypted signature key and encrypted string can also be converted as verification information. For example, the encrypted signature key and encrypted string are called initial verification information, which is a digital string type. Finally, the remainder obtained is converted into a string and then formatted to obtain the final verification information. Then, the final verification information is sent to the device firmware. Through the format conversion operation, the complexity and randomness of the verification information can be further increased, making it difficult for crackers to directly deduce the original data from the verification information.

[0143] Technical solution for bundled verification of device firmware and system programs. The method for preventing smart devices from being cracked provided by the embodiment of the present application also includes:

[0144] 401. Receive verification information sent by the system program;

[0145] 402. Reversely decrypt the verification information to determine the software signature of the system program;

[0146] 403. Obtain a decryption string based on the encryption key and software signature;

[0147] 404. Perform character verification based on the decrypted character string, and complete the authorization binding with the system program after the verification is successful.

[0148] This method is applied to device firmware. After the device firmware receives the verification information sent by the system program, it decrypts the verification information, extracts key information, and then compares it with the digital type stored in the device firmware. If the comparison result is consistent, it means that the verification is successful. By saving the relevant information sent by the system program, the legitimacy and authorization status of the system program are confirmed.

[0149] Specifically, after receiving the verification information, the device firmware reversely decrypts the verification information to obtain the software signature, and then performs specific verification and authorization management based on the software signature to improve the security and flexibility of authorization.

[0150] Use the current encryption key to obtain the corresponding decrypted string. If the verification information is obtained through format conversion. After obtaining the decrypted string, you can also reverse the operation of adding 2 and taking the remainder of 10. Perform character verification on the remainder to obtain the verification result.

[0151] If the decrypted string is consistent with the digital type stored in the device firmware, or the remainder is consistent with the digital type stored in the device firmware, the verification result is successful, otherwise the verification result is failed and the smart device is locked.

[0152] The mechanism of binding device firmware and system program authorization in the embodiment of the present application effectively prevents the system program from being cracked through software signatures, dynamic keys, and encryption. Among them, the software signature can ensure the legitimacy of the source of the system program, the use of dynamic keys increases the complexity and security of encryption, and the encryption operation makes it difficult for crackers to obtain original data and tamper with verification information. At the same time, through the two-way verification and comparison of the device firmware and the system program, the communication security between the device firmware and the system program can be ensured, preventing unauthorized system programs from accessing the device firmware, and protecting the security of the device firmware and user privacy.

[0153] On the other hand, the technical solution provided in the embodiment of the present application configures the bundling verification of system services and system programs. The system program is used to verify the application signature according to the application signature of the system program when loading the preset function library of the smart device, until the preset function library is loaded after the application signature verification is passed to support the operation of the system program. And when the system program obtains the device information of the smart device, it continues to verify the application signature until the device information is encrypted with the public key after the application signature is verified again, completing the authorized bundling of the system program and the system service.

[0154] First, use Android's JNI (Java Native Interface) to develop the libnewcutjni.so library, which is called the preset function library. During the loading process of the preset function library, the application signature of the system program is first obtained through the JNI reflection mechanism. JNI reflection allows the methods of native code (usually C or C++ code) to be dynamically called in Java code and its data structure to be accessed. By obtaining the application signature in this way, the legitimacy of the system program can be verified at a lower level.

[0155] Then compare and verify the obtained application signature with the correct signature information. If they are the same, it means that the system program is legal, the preset function library has been loaded, and subsequent operations can continue; if they are different, in order to ensure system security, exit the system program directly to prevent illegal system programs from accessing system services.

[0156] When the system program calls the device information of the smart device, the encrypted device information is obtained by calling the JniUtils.encryptSign() method. In this process, the application signature of the system program is verified again, and the next step is performed after the verification is passed to ensure that only legitimate applications can perform the next step. If the verification fails, an error message (err) is returned to prevent illegal applications from obtaining device information.

[0157] Furthermore, you can use JNI reflection to obtain the device information stored in sharedPreferences. sharedPreferences is a lightweight data storage method in Android, usually used to store application configuration information and user preferences.

[0158] After two verifications, the device information is also encrypted with the RSA public key without the last digit, completing the authorization binding with the system service. Among them, RSA is an asymmetric encryption algorithm with high security. By encrypting device information with RSA public key, the security of device information during transmission and storage can be ensured to prevent illegal acquisition and tampering.

[0159] The embodiment of the present application realizes the authorized bundling of system programs and system services, effectively preventing the illegal access to system services after the system programs are cracked, ensuring that only legal and untampered system programs can interact with system services, improving the security and stability of system services, and ensuring the confidentiality of system service data.

[0160] On the other hand, the technical solution provided in the embodiment of the present application configures the bundling verification of the Android system and the system program. By configuring the Android system to only allow the installation of specified system programs, it is possible to effectively prevent users or crackers from installing other unauthorized applications, delete the installed specified system programs, increase the difficulty of cracking, and reduce potential security risks. For example, in the Android system settings, only applications from specific sources are allowed to be installed, or only specific application package names are allowed to be installed through a whitelist mechanism.

[0161] For system programs, obtain the system signature of the customized Android system from the embedded Android manufacturer, and use the system signature of the Android system to re-sign the apk file of the system program to ensure that the system program is closely integrated with the Android system and increase security. If the cracker tries to install his own application, the installation process will be blocked due to the lack of the correct system signature.

[0162] In addition, the development and debugging mode can be disabled in the Android system to prevent hackers from using the debugging interface to perform malicious operations. For example, the development and debugging options can be hidden in the Android system settings, or access to the debugging port can be restricted through security policies.

[0163] The embodiment of the present application ensures the security of the device and the controllability of the application by imposing a series of restrictions and security measures on the Android system, preventing hackers from installing malicious applications, protecting the authority of the system program issued by the factory as an Android system application, and increasing the difficulty of cracking, thereby ensuring the security of the device and user data.

[0164] On the other hand, the present application also encrypts the chip of the smart device. Specifically, before the device firmware is burned into the chip, the device firmware is encrypted using a specific encryption algorithm. The encryption algorithm can be symmetric encryption (such as AES) or asymmetric encryption (such as RSA). During the encryption process, the device firmware is encrypted using a dynamically generated key to ensure that each device firmware has a unique encryption state.

[0165] The method of this embodiment includes: before burning the device firmware into a group of chips, encrypting the device firmware to generate an encryption key for the device firmware; storing the encryption key on another group of chips; and configuring the smart device to read the encryption key from another group of chips for security verification during operation.

[0166] Furthermore, a globally unique number storage area is set on the electronic circuit board to store a number that uniquely identifies the electronic circuit board. This number can be assigned by the manufacturer during the production process or generated by a specific algorithm. The existence of the globally unique number helps to distinguish and manage different electronic circuit boards, and can also serve as an important reference factor in the subsequent encryption and authorization process.

[0167] When encrypting the device firmware, a specific algorithm can be used to generate an encryption key based on the chip hardware information used by the current motherboard. The chip hardware information can include the chip model, serial number, manufacturer information, etc. By using this hardware information as input, the algorithm can generate a unique encryption key, which will be used to encrypt and decrypt the device firmware.

[0168] The encryption key is then stored on another set of chips, which can be a dedicated security chip or a chip with secure storage function. When the device is running, the key needs to be read from this set of chips to decrypt the device firmware. By storing the encryption key separately from the globally unique number, security is increased.

[0169] When the device is running, the device firmware reads the key stored in another set of chips and verifies whether the key is applicable to the current chip motherboard. This is achieved by comparing the chip hardware information and the input information of the key generation algorithm. If the key does not match the current chip motherboard, the device firmware will refuse to run or take other security measures to prevent illegal use or tampering. In addition, the key for each new program of the motherboard is different, so the cracker needs to crack the key for each motherboard separately, which further increases the difficulty of cracking.

[0170] During the operation of the device firmware, it can accept dynamic authorization instructions. According to the accepted dynamic authorization instructions, the device firmware can generate relevant dynamic signature keys. The dynamic signature key can be used to sign operations such as device firmware updates and configuration file verification.

[0171] The embodiment of the present application encrypts the chip of the smart device to protect the security of the device firmware, prevent the device firmware from being attacked and tampered with, and improve the security and reliability of the smart device.

[0172] See also Figure 6 , Figure 6 The first structural diagram of the smart device provided in the embodiment of the present application. The smart device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The smart device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices and other similar computing devices.

[0173] The smart device 400 provided in the embodiment of the present application includes a memory 401 and a processor 402. The processor 402 is used to execute the process in the method for preventing smart device cracking provided in the embodiment by calling the computer program stored in the memory 401.

[0174] Those skilled in the art will understand that Figure 6 The structure shown in the figure does not constitute a limitation on the smart device 400, and may include more or less components than those shown in the figure, or combine certain components, or arrange the components differently.

[0175] The system program stored in the memory 401 includes a computer program. The processor 402 executes various functional applications and data processing by running the computer program stored in the memory 401 .

[0176] The processor 402 is the control center of the electronic device. It uses various interfaces and lines to connect various parts of the entire electronic device. It executes various functions of the electronic device and processes data by running or executing computer programs stored in the memory 401 and calling data stored in the memory 401, thereby monitoring the electronic device as a whole.

[0177] In this embodiment, the processor 402 in the electronic device will load the executable code corresponding to the process of one or more system programs into the memory 401 according to the following instructions, and the processor 402 will run the system program stored in the memory 401 to execute:

[0178] When the system program is enabled, get the current cutting count of the device firmware;

[0179] When the current number of cuts reaches the cut number threshold, obtain the authorization instruction from the server;

[0180] If the authorization instruction returned by the server is received, the smart device and system program will operate normally.

[0181] See also Figure 7 , Figure 7 A second structural diagram of the smart device provided in an embodiment of the present application.

[0182] The smart device 400 also includes: device firmware 403, system program 404, and system service 405. Among them, the processor 402 is electrically connected to the device firmware 403, system program 404, and system service 405 respectively. As a basic hardware carrier, the smart device 400 provides a physical platform for the operation of the device firmware 403, software, and system service 405. The device firmware 403 is like a bridge connecting hardware and software, responsible for the control and initialization of the hardware, and providing the underlying interface for the upper layer. The software is the core of realizing user functions, relying on firmware and device hardware resources, and meeting the diverse needs of users through the operating system and system programs. As the support and extension part of the software, the system service 405 not only provides guarantee for the operation of the software, but also expands the software functions through the collaboration of network, security, data storage and other services.

[0183] As an embodiment, the system program 404 is used to obtain the current number of cuts of the device firmware 403; when the current number of cuts reaches a cutting number threshold, an authorization instruction is obtained from the server based on the current number of cuts; if the authorization instruction returned by the server is received, the smart device 400 and the system program 404 operate normally.

[0184] As an embodiment, the system program 404 is also used to obtain the current number of cutting times, device information of the smart device 400 and the authorization number of the device firmware 403; encrypt the current number of cutting times, device information and authorization number, generate an authorization request and send it to the server to obtain authorization instructions from the server.

[0185] As an embodiment, the system program 404 is also used to determine whether the device firmware 403 is authorized if the firmware version of the device firmware 403 is higher than the preset authorized firmware version; if the device firmware 403 is authorized and the current number of cuts reaches the cutting number threshold of the device firmware 403, execute the step of obtaining the authorization instruction from the server according to the current number of cuts; if the device firmware 403 is not authorized, perform authorization configuration on the device firmware 403.

[0186] As an embodiment, the system program 404 is also used to provide a prompt message that the smart device needs to connect to the Internet to obtain the authorization instruction if the authorization instruction returned by the server is not obtained within a preset time period.

[0187] As an embodiment, the system program 404 is also used to obtain the digital type provided by the device firmware 403, generate a signature key according to the digital type and the software signature; obtain the dynamic key generated by the device firmware 403, and obtain the corresponding encrypted string according to the dynamic key; generate verification information according to the signature key and the encrypted string; and send the verification information to the device firmware 403 for verification, so as to complete the authorization bundling with the device firmware 403 after the device firmware 403 is successfully verified.

[0188] As an embodiment, the system program 404 is also used to obtain the application signature of the system program 404 and verify the application signature when the system program 404 loads the preset function library where the device firmware 403 is located, and complete the loading of the preset function library after the application signature verification is passed to support the operation of the system program 404; when the system program 404 obtains the device information corresponding to the device firmware 403, it continues to verify the application signature until the application signature is verified again, and then performs public key encryption on the device information to complete the authorization bundling with the system service 405 where the device firmware 403 is located.

[0189] As an embodiment, the system program 404 is also used to obtain the system signature of the Android system, and re-sign the apk file of the system program 404 according to the system signature to complete the authorization bundling of the system program 404 and the Android system.

[0190] As an embodiment, before burning the device firmware 403 into a set of chips, encrypt the device firmware 403 to generate an encryption key for the device firmware 403; store the encryption key on another set of chips;

[0191] The smart device 400 is configured to read encryption keys from another set of chips for security verification during operation.

[0192] That is, in an optional implementation of the embodiment of the present application, the smart device 400 may set some of its components such as the processor 401, the memory 402 and the device firmware 403 on a carrier, which may be a circuit board. In the embodiment of the present application, the carrier and the components such as the processor 401, the memory 402 and the device firmware 403 set on the carrier may be referred to as the mainboard chip of the smart device 400, or simply referred to as the mainboard. The embodiment of the present application encrypts the chip program of the mainboard chip, which can prevent hackers from stealing the chip program in the smart device 400, so as to maintain the security performance of the smart device 400.

[0193] It should be noted that the embodiments of the smart device 400 of the present application and the embodiments of the method for preventing the smart device from cracking all involve software + firmware + hardware, or can be understood as facilitating the collaboration of software + firmware + hardware to prevent the chip program that has been encrypted in the smart device 400 from being cracked.

[0194] See also Figure 8 , Figure 8 A schematic diagram of the structure of a system for preventing smart device cracking provided in an embodiment of the present application. The system for preventing smart device cracking includes a smart device and a server. The smart device may be the smart device 400 in the above embodiment. The device firmware 403, system program 404 and system service 405 in the smart device 400 communicate with the server 500 through the device.

[0195] In the scheme of binding verification between the device firmware 403 and the server 500, the system program 404 is used to obtain the current cutting times of the device firmware 403, and when the current cutting times reaches the cutting times threshold, obtain the authorization instruction from the server 500 according to the current cutting times, and receive the authorization instruction returned by the server 500, and complete the authorization binding between the device firmware 403 and the server 500 according to the authorization instruction.

[0196] The server 500 is used to receive the current cutting times, and determine the device status of the target device where the device firmware 403 is located according to the current cutting times and the historical cutting times of the device firmware 403, so as to generate an authorization instruction to return when the device status is normal.

[0197] As an embodiment, the server 500 is also used to determine the device status of the target device where the device firmware 403 is located based on the historical cutting times and the current cutting times of the device firmware 403 when receiving the current cutting times of the device firmware 403, and the device status includes a normal state and an abnormal state; if the device status is an abnormal state, the normal operation of the object supported by the device firmware 403 is restricted; if the device status is a normal state, an authorization instruction is generated and returned to the system program 403.

[0198] As an embodiment, the server 500 is also used to obtain the digital type corresponding to the authorization number of the device firmware 403; generate an authorization instruction according to the current number of cuts, device information of the device firmware 403 and the digital type; and return the authorization instruction to the device firmware 403.

[0199] As an embodiment, the server 500 is also used to provide prompt information that the developer needs to unlock; receive the unlock instruction sent by the developer, and unlock the device firmware 403 according to the unlock instruction, wherein the unlock instruction is obtained by a single dynamic encryption based on the device information.

[0200] In the bundled verification scheme of the device firmware 403 and the system program 404, the system program 404 is used to obtain the digital type and dynamic key provided by the device firmware 403, to generate a signature key according to the digital type and the software signature, and to generate verification information according to the encrypted string corresponding to the signature key and the dynamic key, and send the verification information to the device firmware 403 for verification.

[0201] The device firmware 403 is used to perform reverse verification and comparison on the verification information, and to perform authorization bundling on the system program 404 after the verification is successful.

[0202] In the scheme of bundling verification of system service 405 and system program 404. The system program is used to obtain the application signature of the system program when the system program loads the preset function library where the device firmware 403 is located, and verify the application signature until the application signature is verified and the loading of the preset function library is completed to support the operation of the system program. And when the system program obtains the device information corresponding to the device firmware 403, the application signature is continuously verified until the application signature is verified again and the device information is encrypted with the public key to complete the authorization bundling with the system service 405 where the device firmware 403 is located.

[0203] In the scheme of authorizing and bundling the system program 404 with the Android system of the smart device, the system program 404 is used to obtain the system signature of the Android system, and re-sign the apk file of the system program 404 according to the system signature to complete the authorization bundling of the system program 404 with the Android system.

[0204] In the above embodiments, the description of each embodiment has its own focus. For the part that is not described in detail in a certain embodiment, please refer to the detailed description of the method for preventing smart device cracking above, which will not be repeated here.

[0205] The smart device provided in the embodiment of the present application and the method for preventing smart device cracking in the above embodiment belong to the same concept. Any method provided in the embodiment of the method for preventing smart device cracking can be run on the smart device. The specific implementation process is detailed in the embodiment of the method for preventing smart device cracking, which will not be repeated here.

[0206] It should be noted that, for the method for preventing smart devices from cracking in the embodiment of the present application, ordinary technicians in the field can understand that all or part of the process of implementing the method for preventing smart devices from cracking in the embodiment of the present application can be completed by controlling the relevant hardware through a computer program, and the computer program can be stored in a computer-readable storage medium, such as a memory, and executed by at least one processor, and the execution process may include the process of the embodiment of the method for preventing smart devices from cracking. Among them, the storage medium can be a disk, an optical disk, a read-only memory (ROM), a random access memory (RAM), etc.

[0207] For the intelligent device of the embodiment of the present application, each functional module can be integrated into a processing chip, or each module can exist physically separately, or two or more modules can be integrated into one module. The above-mentioned integrated module can be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium, such as a read-only memory, a disk or an optical disk.

[0208] The above is a detailed introduction to the method, smart device and system for preventing smart device cracking provided in the embodiments of the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A method for preventing a smart device from being cracked, characterized in that: The smart device includes device firmware and system program, and the method includes: When the system program is enabled, obtaining the current cutting number of the device firmware; When the current number of cuts reaches a threshold number of cuts, obtaining an authorization instruction from the server; If the authorization instruction returned by the server is received, the smart device and the system program will operate normally.

2. The method for preventing smart devices from being cracked according to claim 1, characterized in that: The obtaining of the authorization instruction from the server includes: Encrypting the current number of cutting times, the authorization number of the device firmware, and the device information of the smart device to generate an authorization request; The authorization request is sent to the server to obtain an authorization instruction from the server.

3. The method for preventing smart devices from being cracked according to claim 1, characterized in that: Before obtaining the authorization instruction from the server, the method further includes: If the firmware version of the device firmware is higher than the preset authorized firmware version, determining whether the device firmware is authorized; If the device firmware has been authorized and the current number of cuts reaches the number of cuts threshold, executing the step of obtaining an authorization instruction from the server; If the device firmware is not authorized, performing authorization configuration on the device firmware.

4. The method for preventing smart devices from being cracked according to claim 1, characterized in that: When the current number of cuts reaches the number of cuts threshold, after obtaining the authorization instruction from the server, the method further includes: If the authorization instruction returned by the server is not obtained within the preset time, a prompt message is provided that the smart device needs to be connected to the Internet to obtain the authorization instruction.

5. The method for preventing smart devices from being cracked according to any one of claims 1 to 4, characterized in that: The method further comprises: When the system program and the device firmware are authorized and bundled, the digital type provided by the device firmware is obtained through the system program, and a signature key is generated according to the digital type and the software signature; Obtaining a dynamic key generated by the device firmware, and obtaining a corresponding encrypted string according to the dynamic key; Generate verification information according to the signature key and the encrypted string; The verification information is sent to the device firmware for verification, so that after the device firmware verification succeeds, the authorization binding of the system program and the device firmware is completed.

6. The method for preventing a smart device from being cracked according to any one of claims 1 to 4, characterized in that: The method further comprises: When the system program is authorized and bundled with the system service of the smart device, the application signature of the system program is verified, and a preset function library is loaded after the application signature verification passes, so as to support the operation of the system program; When the system program obtains the device information of the smart device, the application signature is verified again, and the device information is encrypted with a public key after the application signature is verified again, thereby completing the authorization binding of the system program and the system service.

7. The method for preventing smart devices from being cracked according to any one of claims 1 to 4, characterized in that: The method also includes: When the system program is authorized to be bundled with the Android system of the smart device, the system signature of the Android system is obtained, and the apk file of the system program is re-signed according to the system signature to complete the authorized bundling of the system program and the Android system.

8. The method for preventing a smart device from being cracked according to any one of claims 1 to 4, characterized in that: The method also includes: Before burning the device firmware into a set of chips, encrypting the device firmware and generating an encryption key for the device firmware; storing the encryption key on another set of chips; The smart device is configured to read the encryption key from the other group of chips for security verification during operation.

9. A smart device, characterized in that: the processor; and A memory storing a computer program, which, when executed by the processor, enables the processor to execute the method for preventing a smart device from cracking as claimed in any one of claims 1 to 8.

10. A system for preventing smart devices from being cracked, characterized in that: The smart device includes device firmware, system program, system service and Android system, the device firmware is authorized to be bundled with the system program, the system program is authorized to be bundled with the system service, the system program is authorized to be bundled with the Android system, and the authorization bundling is implemented based on the method for preventing smart device cracking as described in any one of claims 1 to 8.

Images