Method for preventing cracking of smart device, smart device and system

Abstract

The application discloses a method, a smart device and a system for preventing cracking of the smart device. The method comprises the following steps: obtaining the current cutting frequency of the device firmware when the system program is enabled; obtaining an authorization instruction from a server when the current cutting frequency reaches a cutting frequency threshold; and normally running the smart device and the system program if the authorization instruction returned by the server is received. The method for preventing cracking of the smart device improves the cracking difficulty of the system program and the smart device, and guarantees the security of the system program and the smart device.

Description

Technical Field

[0001] This application belongs to the field of computer and intelligent device technology, and in particular relates to a method, intelligent device and system for preventing the cracking of intelligent devices. Background Technology

[0002] As hacking techniques continue to evolve, the problem of system program cracking is becoming increasingly serious. Common system program cracking methods, such as decompiling and cracking system programs and then modifying, repackaging, and flashing the device, or replacing system programs and background services, can compromise the security of system programs or the entire system, increasing the likelihood of losses for stakeholders. To protect the interests of stakeholders, developers urgently need to implement a series of effective anti-cracking measures to ensure the secure and reliable operation of system programs. Summary of the Invention

[0003] This application provides a method, a smart device, and a system for preventing the hacking of smart devices. The method for preventing the hacking of smart devices using this application can increase the difficulty of cracking the system program, thereby ensuring the security of the system program.

[0004] In a first aspect, embodiments of this application provide a method for preventing hacking of a smart device. The smart device includes device firmware and system programs. The method includes:

[0005] When the system program is started, obtain the current number of cuts in the device firmware;

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

[0007] If an authorization instruction is received from the server, 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, before obtaining the authorization instruction from the server based on the current number of cuts, the method may also include:

[0012] If the device firmware version is higher than the preset authorized firmware version, then determine whether the device firmware has been authorized.

[0013] If the device firmware has been authorized, and the current number of cuts has reached the cutting threshold of the device firmware, then execute the step of obtaining the authorization instruction from the server.

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

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

[0016] If no authorization instruction is received from the server within the preset time period, a prompt message will be provided indicating that the smart device needs to connect to the internet to obtain the authorization instruction.

[0017] Optionally, the method also includes:

[0018] When binding the system program with the device firmware for authorization, the system program obtains the digital type provided by the device firmware and generates a signing key based on the digital type and the software signature.

[0019] Obtain the dynamic key generated by the device firmware, and retrieve 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. Once the device firmware is successfully verified, the system program and the device firmware are bound together for authorization.

[0022] Optionally, the method also includes:

[0023] When binding system programs with system services of smart devices for authorization, the application signature of the system program is verified. Once the application signature verification is successful, a preset function library is loaded to support the operation of the system program.

[0024] When the system program obtains the device information of the smart device, it verifies the application signature again. After the application signature is verified again, the device information is encrypted with a public key, thus completing the authorization binding between the system program and the system service.

[0025] Optionally, the method also includes:

[0026] When binding system programs with the Android system of smart devices for authorization, the system signature of the Android system is obtained, and the APK file of the system program is re-signed based on the system signature to complete the authorization binding between the system program and the Android system.

[0027] Optionally, the method also includes:

[0028] Before burning the device firmware into a set of chips, the device firmware is encrypted to generate an encryption key for the device firmware.

[0029] The encryption key is stored on another set of chips;

[0030] When configuring smart devices, they need to read encryption keys from another set of chips for security verification during operation.

[0031] Secondly, embodiments of this application provide a smart device, including: a processor; and a memory storing a computer program, wherein when the computer program is executed by the processor, the processor performs the smart device anti-hacking method as described above.

[0032] Thirdly, embodiments of this application provide a system for preventing the cracking of smart devices. The smart device includes device firmware, system program, system service, and Android system. The device firmware is authorized and bound to the system program, the system program is authorized and bound to the system service, and the system program is authorized and bound to the Android system. The authorization binding is implemented based on the method for preventing the cracking of smart devices according to any of the above.

[0033] The method for preventing cracking of smart devices provided in this application limits the number of times the device firmware can be cut. When the current number of cuts reaches a threshold, the authorization command is retrieved again from the server, thus limiting the possibility of software cracking. Furthermore, when the authorization command is received from the server, the smart device and system program operate normally, achieving authorization binding between the system program and the device firmware, greatly reducing the risk of system program cracking and improving the security of both the system program and the smart device. Attached Figure Description

[0034] The technical solution and its beneficial effects will become apparent from the following detailed description of specific embodiments of this application, in conjunction with the accompanying drawings.

[0035] Figure 1 This is a schematic diagram illustrating the binding and verification of device firmware and server in the method for preventing cracking of smart devices provided in this application embodiment;

[0036] Figure 2 This is a schematic flowchart of the first method for preventing the hacking of smart devices provided in this application embodiment;

[0037] Figure 3 This is a flowchart illustrating the process of the system program obtaining authorization instructions from the server in the method for preventing the cracking of smart devices provided in this application embodiment;

[0038] Figure 4 This is a schematic diagram of the second method for preventing hacking of smart devices provided in this application embodiment;

[0039] Figure 5 This is a schematic diagram illustrating the binding and verification of device firmware and system program in the method for preventing cracking of smart devices provided in this application embodiment;

[0040] Figure 6This is a schematic diagram of a first structure of a smart device provided in an embodiment of this application;

[0041] Figure 7 This is a schematic diagram of a second structure of a smart device provided in an embodiment of this application;

[0042] Figure 8 This is a schematic diagram of the structure of the smart device anti-hacking system provided in the embodiments of this application. Detailed Implementation

[0043] Please refer to the illustrations, where the same component symbols represent the same components. The principles of this application are illustrated by example in a suitable computing environment. The following description is based on the specific embodiments of this application illustrated, and should not be construed as limiting other specific embodiments not detailed herein.

[0044] Here are four common methods for cracking software:

[0045] The first software cracking method involves obtaining the chip firmware program through electronic hardware chip reading. Specifically, the cracker identifies the electronic hardware chip containing critical information in the target smart device. Using specialized hardware reading techniques and tools, they attempt to establish a connection with the chip. They bypass the chip's security protection mechanisms (if any) and successfully read the data from the chip. From the read data, they identify and extract the chip firmware program, which may contain the device's critical operating logic, algorithms, and interface information for software interaction. The cracker can then reverse engineer the firmware program, analyzing its code and data to find and crack the software's security mechanisms. The cracker can also analyze the obtained firmware program to find vulnerabilities or exploitable parts for further attacks or illegal use. For example, if the chip firmware contains security vulnerabilities, the cracker can exploit these vulnerabilities to gain control of the device, thereby affecting the normal operation and security mechanisms of the software. For instance, by exploiting buffer overflow vulnerabilities in the firmware, malicious code can be executed to bypass the software's security protections.

[0046] The second method of software cracking involves decompiling and cracking the app, then modifying and repackaging it before flashing the device. Taking the Russian feedback cracking method as an example, the cracker obtains the app's installation file by extracting it from an already installed device or downloading it from the internet. They then use decompilation tools to decompile the app's installation file, converting it from binary code into readable source code. By analyzing the decompiled source code, they understand the app's functional structure, business logic, and interaction methods with the server. Depending on the cracking objective, they modify the source code, which may include removing restricted functions, adding malicious code, or modifying the interface display. The modified source code is then repackaged as a new app installation file. This repackaged app is installed on the target device or integrated into the device's system through flashing the device, replacing the original app. In this way, the cracked app can run on the device, achieving the cracker's illegal purpose.

[0047] The third method of software cracking involves directly replacing the app and its background services, completely detaching them from the original system. Taking the Ukrainian feedback crack as an example, the cracker first conducts in-depth research on the app and its system, determining the app's and background services' functions, structure, and interaction methods with the device. A suitable app and background service solution is selected to replace the original app and background services in the target system. The selected app and background services can be self-developed or software components with similar functions obtained from other sources. Through methods such as modifying the device's operating system, using software installation tools for replacement, or remote replacement via network attacks, the original app and background services in the target system are completely replaced by the new software components. Because 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 new app's code to add malicious functions or obtain sensitive information.

[0048] The fourth method of software cracking involves analyzing and intercepting submission requests to prevent the app from deducting or tampering with the number of attempts. Taking Edraw Feedback as an example, the cracker observes the target app's workflow, paying particular attention to the parts involving submission requests. Using network analysis tools or other techniques, they intercept and monitor the communication between the app and the server. When the app submits a request to the server, the cracker intercepts it. They analyze the intercepted request to understand its format, parameters, and communication protocol. Based on the analysis, they modify the request data or forge responses to prevent the app from deducting or tampering with the number of attempts. In this way, the cracker can use certain functions of the app without restriction, without adhering to normal usage rules.

[0049] In response to the various software cracking methods described above, this application provides corresponding technical solutions. By establishing communication mechanisms between the smart device, device firmware, APP, and server, the cracking of the smart device and its system programs can be prevented.

[0050] Device firmware refers to the software program stored in a specific memory chip inside a smart device. Device firmware is typically responsible for the device's basic functional control, such as starting the device, initializing hardware, and managing power. An app (system program) is software installed on the device, providing users with various specific functions and services. Apps interact with the device through the Android system, utilizing the device's hardware capabilities to perform their functions.

[0051] On the one hand, the technical solution provided in this application includes a binding verification between the device firmware and the server. Please refer to... Figure 1 , Figure 1 This is a schematic diagram illustrating the binding and verification of device firmware and server in the method for preventing cracking of smart devices provided in this application embodiment.

[0052] First, a cutting count control is configured in the device firmware. When the device firmware reaches a certain number of cutting counts, it must re-obtain authorization through the network server, i.e., perform a flushing authorization operation.

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

[0054] The server receives the current cutting count and determines the device status of the smart device based on the current and historical cutting counts in the device firmware. If the device status is normal, an authorization command is generated and returned.

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

[0056] In this embodiment, by binding the device firmware and the server with authorization, the system program can only run normally after successful authorization verification between the device firmware and the server. This effectively prevents unauthorized devices from using the system program and reduces the possibility of illegal copying and use of the system program. Furthermore, it adds a crucial security defense to the system program, requiring attackers to not only overcome the system program's own security mechanisms but also to overcome the authorization association with the server, significantly increasing the difficulty of cracking and thus enhancing the system program's security.

[0057] The technical solution for binding and verifying device firmware and server-side components is detailed below. Please refer to [link / reference needed]. Figure 2 , Figure 2 This is a schematic flowchart of a first embodiment of a method for preventing hacking of smart devices provided in this application. This method can be applied to system programs. The process of this method may include:

[0058] 101. When the system program is started, obtain the current number of cuts in the device firmware;

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

[0060] 103. If an authorization instruction is received from the server, the smart device and system program will run normally.

[0061] In this embodiment, the supported object of the device firmware can be a system program. The system program records the current number of cuts in the device firmware and determines whether the current number of cuts has reached the device firmware's cut count threshold. The cut count threshold can be determined based on the total authorized cut count of the device firmware; for example, setting 90% of the total authorized cut count as the cut count threshold. In other words, if the total authorized cut count of the device firmware is 100, and the current cut count indicates that 90 cuts have been performed, leaving 10 cuts remaining, then the current cut count of the device firmware has reached the cut count threshold. In this case, it is necessary to re-obtain the authorization command from the server. If the authorization command is not re-obtained from the server, the system program cannot be used normally.

[0062] The smart device and system program can only function normally when the system program receives the authorization instruction returned by the server.

[0063] In some embodiments, step 102, obtaining an authorization instruction from the server based on 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, this application embodiment sets a limit on the number of firmware cuts. For newly upgraded firmware, without authorization, information regarding the authorized number of firmware cuts is obtained by reading a specific instruction, such as "BD:110, 1;". After reading the specific instruction, the information regarding the authorized number of cuts is verified. If the verification result indicates that the authorized number of cuts is 0, it is determined that the device firmware has been newly upgraded and authorization for the number of firmware cuts is required. This ensures that the smart device can use the system program normally.

[0067] Specifically, if the command "BD: 110, 1;" is sent and "RCMD = 110,1,1;" is returned, it indicates that the authorized number of cuts is 0, and the device firmware has not yet set the authorization for the number of cuts. This method of sending monitoring commands and returning verification results can accurately detect the authorization status of the device firmware regarding the number of cuts.

[0068] Then, when the system program is started, 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 cuts. When the current number of cuts reaches the cut threshold, an authorization request is generated based on the current number of cuts, device information, and authorization number. This authorization request is then sent to the server, where it is used to request authorization instructions from the server. By generating authorization instructions, the security of data transmission of information such as the current number of cuts, device information, and authorization number can be ensured.

[0069] When generating an authorization request based on the current number of cuts, device information, and authorization number, encryption can be used. This encryption can include, but is not limited to, AES encryption (a block cipher algorithm that encrypts data in fixed-size blocks), DES encryption (a symmetric encryption algorithm that uses a 56-bit key to encrypt 64-bit data blocks), and RSA encryption (Rivest-Shamir-Adleman, using a pair of keys, a public key and a private key). For example, first determine a suitable key length (e.g., 128 bits, 192 bits, or 256 bits). Combine the number of cuts, device information, and authorization number in a specific format, such as concatenating them into a string or binary data block in a specific order. Then, encrypt this combined data using the AES encryption algorithm to obtain the encrypted authorization request. Alternatively, organize the number of cuts, device information, and authorization number into a suitable encryption format and then encrypt them using DES or 3DES algorithms. For example, you can first obtain the server's public key, then convert the number of cuts, device information, and authorization number into a format suitable for encryption (such as a number or a string with a specific encoding), and finally encrypt them using the RSA algorithm and the server's public key to generate an encrypted authorization request.

[0070] For example, the current number of cuts, device information, and authorization number can be encrypted first using the MD5 algorithm, and then encrypted again using the RSA algorithm to generate an authorization request submitted to the server. The server generates a token based on the received authorization request and returns it to the system program. After obtaining the token, the system program can use it to access other encrypted interfaces. The token serves as the credential for the system program to subsequently access other encrypted interfaces, ensuring that only authorized system programs can access server resources. The parameters and returned data of these interfaces are encrypted using different RSA encryption methods, further enhancing the security of data transmission. Different interfaces may use different RSA keys to encrypt and decrypt data, ensuring the confidentiality and integrity of data during transmission.

[0071] In some embodiments, please refer to Figure 3 , Figure 3 This is a flowchart illustrating the operation of the system program in the method for preventing the cracking of smart devices provided in this application embodiment.

[0072] Step 102 includes:

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

[0074] If so, proceed to step 1022: determine whether the device firmware has been authorized;

[0075] If the device firmware has been authorized, proceed to step 1023: determine whether the current number of cuts has reached the cutting number threshold.

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

[0077] If not, proceed to step 1025, and the smart device and system program will operate normally. The smart device has the system program installed.

[0078] If the device firmware version is not higher than the preset authorized firmware version, the process will end, or a prompt to upgrade the firmware version will be displayed.

[0079] If the device firmware is not authorized, then authorization configuration will be performed on the device firmware. That is, the steps of authorizing the device firmware a certain number of times will be executed.

[0080] In some embodiments, the method further includes the following steps prior to performing step 1024:

[0081] 1026. Determine if the smart device is connected to the internet;

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

[0083] If not, proceed to step 1027 and provide a prompt message indicating that the smart device needs to connect to the internet to obtain an authorization command.

[0084] In this embodiment, the methods for providing prompts that require smart devices to connect to the internet to obtain authorization instructions include, but are not limited to: pop-up prompts, voice prompts, text prompts, SMS prompts, telephone prompts, etc.

[0085] For example, when the current number of cuts equals the cut count threshold, it is also possible to force the smart device to connect to the network in order to obtain the authorization command, so as to ensure that the smart device can interact with the server for authorization in a timely manner.

[0086] In some embodiments, step 102 is followed by:

[0087] 104. If no authorization instruction is received from the server within the preset time period, a prompt message will be provided indicating that the smart device needs to connect 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 aforementioned threshold for the number of cuts can be adjusted based on the total authorized number of cuts.

[0090] For example, for device firmware with a high number of offline cutting operations, a higher total authorized cutting operation count can be set, such as increasing it from 1,000 to 10,000. When the current cutting operation count reaches 90% of the total authorized cutting operation count, a new authorization command needs to be obtained from the Internet.

[0091] For example, for device firmware that is cut frequently, the total authorized number of cuts can be dynamically adjusted based on the recent cutting frequency. For instance, starting with 1000 cuts, the total authorized number of cuts can be increased when the cutting frequency is high and decreased when the cutting frequency is low. The adjustment range can be determined by the difference between the cutting frequency and the base cutting frequency; the larger the difference, the larger the adjustment range, and vice versa.

[0092] For example, the total authorized number of cuts can also be manually adjusted. For smart devices that have already been authorized a certain number of cuts, the development team can modify the total authorized number of cuts. If a smart device is initially set to have a total authorized number of cuts of 1000, but the backend detects that the device has used 10 cuts, there is a significant discrepancy between the total authorized number of cuts and the actual number used. To avoid wasting resources, the development team can modify the total authorized number of cuts to 100. Of course, the user can also request an adjustment to the total authorized number of cuts.

[0093] For some smart devices that are offline and unable to obtain authorization commands from the server, the backend system has the capability to monitor the online status of smart devices in real time or periodically. When the backend system detects an offline, unauthorized device, it dynamically generates an authorization command based on preset authorization rules and algorithms. This command is then sent to the smart device through an appropriate channel. One possible channel is to send the authorization command via email to the customer's registered email address, explaining how to authorize the device on the recharge page. Another option is to display a pop-up notification when the customer next logs into the system program or website associated with the backend, informing them of the unauthorized device and showing the authorization command along with a link to the recharge page for authorization.

[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 checks whether it has received any supplementary instructions returned by the server. If it receives supplementary instructions returned by the server, it transmits these supplementary instructions to the device firmware. After successfully sending the supplementary instructions to the device firmware, the system program immediately calls back the interface to notify the server that the supplementary instructions have been sent. By sending a specific notification message to the server, including information such as the device identifier and instruction sending status, the server can understand that the system program has completed the supplementary instruction sending operation and can then proceed with subsequent processing.

[0095] In some embodiments, the system program interface can also display information related to the number of authorized cuts. For example, when system information needs to be displayed, the corresponding function or module is called to obtain the already integrated string. If the remaining number of cuts is 0, it is displayed as "v24.05 (9)(0)" in the format; if no authorized number of cuts has been set (which may be due to a new device or no authorization settings have been made), it is displayed as "v24.05 (9)(00)"; if there is authorization and 580 cuts remain, it is displayed as "v24.05 (9)(580)".

[0096] In some embodiments, when detecting the device firmware version, the system program also needs to determine whether a firmware version rollback has occurred. This is achieved by pre-establishing a firmware version recording mechanism on the smart device, storing the firmware version number and related PG header information after each successful upgrade in a specific area of ​​the device's non-volatile memory (such as a specific area in flash memory). When the device boots up or performs any firmware-related operations, it first verifies whether the current firmware version matches the recorded version. If a version lower than the recorded version is found, a firmware rollback may have occurred. In this case, appropriate measures should be taken, such as preventing the device from booting, prompting the user to perform a correct firmware upgrade again, or sending an alert notification to the administrator. This ensures that the authorization request is successfully sent to the server.

[0097] This section outlines a technical solution for binding and verifying device firmware and server-side components. Another method for preventing smart device hacking is also provided here; please refer to [link / reference]. Figure 4 , Figure 4 This is a schematic diagram of a second method for preventing hacking of smart devices provided in this application embodiment. This method for preventing hacking of smart devices can be applied to the server side. The process of this method for preventing hacking of smart devices may include:

[0098] 201. Upon receiving the current number of cuts from the device firmware, determine the device status of the smart device based on the historical number of cuts and the current number of cuts from the device firmware. The device status includes normal status and abnormal status.

[0099] 202. If the device is in an abnormal state, the normal operation of the smart device and system program will be restricted;

[0100] 203. If the device status is normal, an authorization command is generated and returned to the system program.

[0101] Upon receiving the authorization request from the system program, the server parses the request to obtain data such as the current number of cuts in the device firmware and saves it to a data table. Then, the server adds the current number of cuts to the historical number of cuts recorded in the last upload, obtaining a total number of cuts. Finally, the server compares this total number of cuts with the total number of cuts set in the backend.

[0102] If the total number of cuts exceeds the total number of cuts, the server will determine the smart device's status as abnormal. In this case, no authorization command will be generated or sent to the system program, and neither the system program nor the smart device will function properly. However, if the total number of cuts is not greater than the total number of cuts, the server will determine the smart device's status as normal. In this case, an authorization command will be generated and sent to the system program. The system program will then pass the authorization command to the device firmware, allowing the device firmware to support the normal operation of the system program.

[0103] For example, if the current number of cuts is the same as the number of cuts during the first upload, then the server only needs to save the current number of cuts to the data table.

[0104] In some embodiments, step 203, which generates an authorization instruction and returns it to the system program, includes:

[0105] Obtain the numeric type corresponding to the device firmware authorization number;

[0106] Generate an authorization instruction based on the current number of cuts, the device information in the device firmware, and the number type;

[0107] Return the authorization command to the device firmware.

[0108] In this embodiment, the server can obtain the authorization request sent by the system program through the API interface. This 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 number. Then, it increments this number by 1 and performs a format conversion to obtain a new number. Simultaneously, it determines the current number of cuts authorized by the device firmware (e.g., 1000 times) and obtains the device information (e.g., PID code). Next, it calls the authorization tool to obtain the authorization instruction based on this information. This authorization instruction is returned to the system program in encrypted form. The system program obtains the authorization instruction, decrypts it, and then sends it to the device firmware.

[0109] Furthermore, the server sends the authorization command to the system program, which then distributes it to the device firmware. The system program determines whether the authorization was successful based on the string corresponding to the returned authorization command. If successful, it submits the authorization success result to the server. When the server receives the authorization success result from the system program, it records the successful transmission status of the authorization command. If the server does not receive the authorization success result from the system program, it records the failure transmission status of the authorization command.

[0110] The server-side backend data tables record relevant data, which can be queried based on device information (SN, serial number) and status to obtain corresponding reports. This allows administrators and technicians to quickly understand the usage status, authorization status, and other related information of smart devices.

[0111] For example, authorization instructions can be generated by an authorization tool that can be integrated into the server or communicate with the server.

[0112] First, the authorization tool obtains the system environment hardware information and encrypts it using the MD5 algorithm. Then, the authorization tool sends this processed encrypted hardware information to the authorization tool. MD5 (Message-Digest Algorithm 5) is a widely used cryptographic hash function that produces a 128-bit (16-byte) hash value.

[0113] When generating authorization instructions based on encrypted hardware information, the authorization tool also receives device information (which may be a parameter or identifier), authorization number, and the current number of cuts, etc., to generate new authorization instructions. This ensures that the authorization instructions are associated with specific device hardware, improving the security and uniqueness of the authorization.

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

[0115] For example, if the authorization tool fails to generate authorization instructions, it can also send a warning SMS to notify the technicians so that they can address the problem promptly.

[0116] In some embodiments, step 202 is followed by:

[0117] Provides a prompt message indicating that unlocking is required on the development side;

[0118] Receive the unlock command sent by the development side, and unlock the device firmware according to the unlock command. The unlock command is obtained by dynamic encryption based on the device information once.

[0119] In this embodiment, if the device status is determined to be abnormal, the server sends a prompt message to the system program requiring the developer to unlock the device. Simultaneously, the server asynchronously sends an email notification to the developer using the device, enabling them to promptly investigate and analyze the cause of the abnormal status.

[0120] The causes of abnormal states include data transmission errors, equipment failures, and malicious tampering.

[0121] Additionally, when a device is determined to be in an abnormal state, the system program can be locked to prevent potential risks from its continued operation. Once the system program is locked, the user needs to contact the developers to resolve the issue. This can be done through various channels, such as customer service hotlines, email, and online support platforms.

[0122] Upon receiving a user's request, the developers will remotely issue an unlock command. This unlock command is dynamically encrypted and bound to the device firmware. Thus, each unlock command is generated specifically for the device and is encrypted to ensure security.

[0123] Secondly, to prevent the reuse of unlock commands, they are set to expire after use. This prevents unlock commands from being maliciously saved and abused, improving device security. At the same time, expired unlock commands also encourage users to contact the developers promptly if the device malfunctions again, rather than attempting to unlock it illegally using expired commands.

[0124] In some embodiments, 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 system program version information, release time, developer information, etc., and can also verify the legitimacy of the system program. If an unregistered system program attempts to access the server, the server can reject its request, thereby improving system security.

[0125] In some embodiments, the server also monitors and filters the activity status of its associated smart devices. The activity status of a smart device can be determined by whether it has communicated with the server within a certain period of time, or whether it has uploaded data or recorded operations. If a smart device has communicated with the server or uploaded data or recorded operations within a certain period of time, it is determined that the smart device is in an active state.

[0126] For the selected active devices, further analyze the smart devices that have not recently had their data cut. For example, you can analyze smart devices that have not had their data cut in the past week or month to quickly identify devices that may have problems.

[0127] Then, by analyzing the status information, most recent active time, and historical operation records of potentially problematic smart devices, it can be determined whether the smart device is malfunctioning, being used illegally, or has other abnormalities.

[0128] When a problematic smart device is detected, the background system returns a success status for any request to access the device's data, but the data list is empty. This is to notify the system program that the device has a problem and no data is available.

[0129] After receiving a successful response from the server that indicates an empty data list, the system program automatically clears the relevant page data. This prevents users from seeing erroneous or invalid data on the system program, improving user experience. Simultaneously, the system program can take further measures, such as disabling the device's functions, rendering it unusable. This can be achieved by setting a device status flag in the system program or by directly blocking the device's operation interface. For example, on the system program's device list page, problematic devices can be marked as unavailable, and users can be prevented from operating them.

[0130] As described above, this application embodiment uses a binding verification between the device firmware and the server. This prevents the device from disconnecting from the server, achieves strict management and control over the number of times the device firmware is split, ensures that the use of the device firmware is within the legal and authorized scope, and improves the security of the system program, preventing the use and cracking of unauthorized system programs.

[0131] On the other hand, the technical solution provided in this application embodiment configures the authorization binding of device firmware and system programs. Please refer to... Figure 5 , Figure 5 This is a schematic diagram illustrating the binding and verification of device firmware and system program in the method for preventing cracking of smart devices provided in this application embodiment.

[0132] The system program is used to obtain the digital type and dynamic key provided by the device firmware, generate a signing key based on the digital type and software signature, generate verification information based on the encrypted string corresponding to the signing key and 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 of the verification information, and to authorize and bind the system program after successful verification.

[0134] A technical solution for binding and verifying device firmware and system programs is described in detail below. The method for preventing hacking of smart devices provided in this application also includes:

[0135] 301. Obtain the numeric type provided by the device firmware, and generate a signing key based on the numeric type and the software signature;

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

[0137] 303. Generate verification information based on the signature key and the encrypted string;

[0138] 304. Send the verification information to the device firmware for verification, so that the system program and the device firmware are authorized and bound together after the device firmware is successfully verified.

[0139] This method is applied to system programs. The device firmware provides a unique identifier, also known as the SSN, consisting of 9 digits. The software signature can be an SHA signature, a digital signature technology based on the SHA algorithm, which is efficient and secure. The signature key generated based on the numeric type and software signature is a 10-digit number. If it is less than 10 digits, it can be padded with leading zeros to form a 10-digit signature key. For example, the signature key could be "0456477993".

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

[0141] When generating verification information based on the signature key and the encrypted string, encryption algorithms can be used. For example, the signature key, the encrypted string, and a randomly generated number can be used to perform encryption to generate verification information. Introducing random numbers into the encryption of verification information increases its encryption strength, preventing attackers from cracking it by analyzing fixed encryption patterns.

[0142] For example, the encrypted signing key and encrypted string can also be converted and used as verification information. For instance, the encrypted signing key and encrypted string can be called initial verification information, which is a numeric string. The remainder is then converted to a string and formatted to obtain the final verification information. This final verification information is then sent to the device firmware. This format conversion operation further increases the complexity and randomness of the verification information, making it difficult for attackers to directly deduce the original data from the verification information.

[0143] A technical solution for binding and verifying device firmware and system programs. The method for preventing hacking of smart devices provided in this application also includes:

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

[0145] 402. Decrypt the verification information in reverse to determine the software signature of the system program;

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

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

[0148] This method is applied to device firmware. After receiving the verification information sent by the system program, the device firmware decrypts the verification information, extracts key information, and compares it with the numeric type stored in the device firmware. If the comparison result matches, 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 decrypts it to obtain the software signature. Then, it performs specific verification and authorization management based on the software signature, improving the security and flexibility of the authorization process.

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

[0151] If the decrypted string matches the numeric type stored in the device firmware, or if the remainder matches the numeric type stored in the device firmware, the verification result is successful; otherwise, the verification result is unsuccessful, and the smart device is locked.

[0152] In this embodiment, the mechanism of binding device firmware and system program authorization effectively prevents the system program from being cracked through software signing, dynamic keys, and encryption. Software signing ensures the legitimacy of the system program's origin, while the use of dynamic keys increases the complexity and security of encryption, making it difficult for attackers to obtain the original data and tamper with verification information. Simultaneously, through bidirectional verification and comparison between the device firmware and the system program, secure communication between them is ensured, preventing unauthorized system programs from accessing the device firmware and protecting the security of the device firmware and user privacy.

[0153] On another front, the technical solution provided in this application embodiment includes a binding verification between system services and system programs. When loading a preset function library for a smart device, the system program verifies the application signature based on the application signature of the system program until the application signature verification is successful, at which point the preset function library is loaded to support the operation of the system program. Furthermore, when the system program obtains device information from the smart device, it continues to verify the application signature until the application signature is verified again, at which point the device information is encrypted with a public key, completing the authorized binding of the system program and system services.

[0154] First, the libnewcutjni.so library is developed using Android's JNI (Java Native Interface), and is referred to as the default function library. During the loading process, the default function library first obtains the application signature of the system program through the JNI reflection mechanism. JNI reflection allows Java code to dynamically call methods of native code (usually C or C++ code) and access its data structures. Obtaining the application signature in this way allows for lower-level verification of the legitimacy of the system program.

[0155] The obtained application signature is then compared with the correct signature information. If they match, the system program is legitimate, the preset function library is loaded, and subsequent operations can continue. If they do not match, to ensure system security, the system program is exited directly to prevent unauthorized system programs from accessing system services.

[0156] When a system program requests device information from a smart device, it retrieves the encrypted device information by calling the `JniUtils.encryptSign()` method. During this process, the application signature of the system program is first verified again. Only after successful verification can the next step be performed, ensuring that only legitimate applications can proceed. If verification fails, an error message (err) is returned, preventing unauthorized applications from obtaining device information.

[0157] Furthermore, device information stored in sharedPreferences can be obtained through JNI reflection. sharedPreferences is a lightweight data storage method in Android, typically used to store application configuration information and user preference settings.

[0158] After two successful verifications, the device information is further encrypted using RSA public key encryption after removing the last bit, completing the authorization binding with the system service. RSA is an asymmetric encryption algorithm with high security. Encrypting device information with an RSA public key ensures the security of device information during transmission and storage, preventing unauthorized access and tampering.

[0159] This application embodiment implements authorized binding of system programs and system services, effectively preventing unauthorized access to system services after the system programs are cracked, ensuring that only legitimate and untampered system programs can interact with system services, improving the security and stability of system services, and protecting the confidentiality of system service data.

[0160] Furthermore, the technical solution provided in this application includes a binding verification mechanism between the Android system and system programs. By configuring the Android system to only allow the installation of specified system programs, it effectively prevents users or crackers from installing unauthorized applications, deleting already installed specified system programs, increasing the difficulty of cracking, and reducing potential security risks. For example, the Android system settings can only allow the installation of applications from specific sources, or a whitelist mechanism can be used to allow only specific application package names to be installed.

[0161] For system applications, a system signature for the customized Android system is obtained from the embedded Android manufacturer. This signature is then used to re-sign the system application's APK file, ensuring a tight integration between the system application and the Android system and increasing security. If a cracker attempts to install their own application, the installation process will be blocked due to the lack of a proper system signature.

[0162] Additionally, configure the Android system to disable developer debugging mode to prevent attackers from using debugging interfaces for malicious operations. For example, you can hide the developer debugging option in Android system settings, or restrict access to debugging ports through security policies.

[0163] This application implements a series of restrictions and security measures on the Android system to ensure device security and application controllability. This prevents hackers from installing malicious applications, protects the authority of the system programs released by the manufacturer as Android system applications, increases the difficulty of cracking, and safeguards the security of device and user data.

[0164] Furthermore, this application also encrypts the chip of the smart device. Specifically, before burning the device firmware 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, a dynamically generated key is used to encrypt the device firmware, ensuring that each device firmware has a unique encrypted state.

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

[0166] Furthermore, a globally unique identifier storage area is set up on the electronic circuit board to store a unique number that 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 a globally unique number helps to distinguish and manage different electronic circuit boards, and can also serve as an important reference factor in subsequent encryption and authorization processes.

[0167] When encrypting device firmware, a specific algorithm can be used to generate an encryption key based on the chip hardware information used by the current motherboard. Chip hardware information may include the chip's 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 a separate set of chips, which can be dedicated security chips or chips with secure storage capabilities. During device operation, the key is retrieved from this set of chips to decrypt the device firmware. Security is enhanced by storing the encryption key separately from its globally unique identifier.

[0169] During device operation, the device firmware reads keys stored in another set of chips and verifies whether these keys are compatible with the current chip motherboard. This is achieved by comparing the chip hardware information with 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 unauthorized use or tampering. Furthermore, each motherboard has a different key for its new program, requiring attackers to crack the key individually for each motherboard, further increasing the difficulty of cracking.

[0170] During operation, the device firmware can accept dynamic authorization commands. Based on the received commands, the firmware can generate a dynamic signature key. This key can be used to sign operations such as firmware updates and configuration file verification.

[0171] This application embodiment protects the firmware security of smart devices by encrypting the chip, preventing the firmware from being attacked and tampered with, thereby improving the security and reliability of smart devices.

[0172] Please see Figure 6 , Figure 6 This is a first structural schematic diagram of a smart device provided in an embodiment of this 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 processors, cellular phones, smartphones, wearable devices, and other similar computing devices.

[0173] The smart device 400 provided in this application embodiment includes a memory 401 and a processor 402. The processor 402 executes the process in the smart device anti-hacking method provided in this 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 does not constitute a limitation on the smart device 400, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

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

[0176] The processor 402 is the control center of the electronic device. It connects various parts of the electronic device through various interfaces and lines. By running or executing computer programs stored in the memory 401 and calling data stored in the memory 401, it performs various functions of the electronic device and processes data, thereby monitoring the electronic device as a whole.

[0177] In this embodiment, the processor 402 in the electronic device loads the executable code corresponding to one or more system program processes into the memory 401 according to the following instructions, and the processor 402 runs the system program stored in the memory 401 to execute:

[0178] When the system program is started, obtain the current number of cuts in the device firmware;

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

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

[0181] Please see Figure 7 , Figure 7 This is a schematic diagram of a second structure of a smart device provided in an embodiment of this application.

[0182] The intelligent device 400 also includes: device firmware 403, system program 404, and system service 405. The processor 402 is electrically connected to the device firmware 403, system program 404, and system service 405. As the basic hardware carrier, the intelligent device 400 provides a physical platform for the device firmware 403, software, and system service 405 to run. The device firmware 403 acts as a bridge connecting hardware and software, responsible for hardware control and initialization, and providing a low-level interface for higher layers. The software is the core for implementing user functions, relying on firmware and device hardware resources, and meeting diverse user needs through the operating system and system program. The system service 405, as the support and extension part of the software, not only provides assurance for software operation but also collaborates to extend software functionality through services such as network, security, and data storage.

[0183] As one embodiment, the system program 404 is used to obtain the current number of cuts in the device firmware 403; when the current number of cuts reaches the cut count 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 one embodiment, the system program 404 is also used to obtain the current number of cuts, the device information of the smart device 400, and the authorization number of the device firmware 403; encrypt the current number of cuts, the device information, and the authorization number, generate an authorization request and send it to the server to obtain the authorization instruction from the server.

[0185] As one embodiment, the system program 404 is further configured to determine whether the device firmware 403 has been authorized if the firmware version of the device firmware 403 is higher than the preset authorized firmware version; if the device firmware 403 has been authorized and the current number of cuts reaches the cut count threshold of the device firmware 403, execute the step of obtaining an authorization instruction from the server based on the current number of cuts; if the device firmware 403 has not been authorized, then perform authorization configuration on the device firmware 403.

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

[0187] As one embodiment, the system program 404 is also used to obtain the numeric type provided by the device firmware 403, generate a signature key based on the numeric type and software signature; obtain the dynamic key generated by the device firmware 403, obtain the corresponding encrypted string based on the dynamic key; generate verification information based on 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 binding with the device firmware 403 after the device firmware 403 successfully verifies the information.

[0188] As one embodiment, the system program 404 is also used to obtain the application signature of the system program 404 when loading the preset function library where the device firmware 403 is located, verify the application signature, and complete the loading of the preset function library after the application signature verification is passed, so as 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 encrypts the device information with a public key to complete the authorization binding with the system service 405 where the device firmware 403 is located.

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

[0190] As one embodiment, before burning the device firmware 403 into a set of chips, the device firmware 403 is encrypted to generate an encryption key for the device firmware 403; the encryption key is stored on another set of chips.

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

[0192] In other words, in one optional embodiment of this application, the smart device 400 may mount some of its components, such as the processor 401, memory 402, and device firmware 403, on a carrier, which may be a circuit board. In this application embodiment, the carrier and the components mounted on it, such as the processor 401, memory 402, and device firmware 403, are referred to as the motherboard chip of the smart device 400, or simply the motherboard. This application embodiment encrypts the chip program of the motherboard chip to prevent hackers from stealing the chip program from the smart device 400, thereby maintaining the security performance of the smart device 400.

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

[0194] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a smart device anti-hacking system provided in an embodiment of this application. The smart device anti-hacking system includes a smart device and a server. The smart device can 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 for binding and verifying device firmware 403 and server 500, system program 404 is used to obtain the current number of cuts of device firmware 403, and when the current number of cuts reaches the cut count threshold, obtains an authorization instruction from server 500 based on the current number of cuts, and receives the authorization instruction returned by server 500, and completes the authorization binding between device firmware 403 and server 500 based on the authorization instruction.

[0196] The server 500 is used to receive the current cutting count, and determine the device status of the target device where the device firmware 403 is located based on the current cutting count and the historical cutting count. When the device status is normal, an authorization instruction is generated and returned.

[0197] As one 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 count and the current cutting count of the device firmware 403 when receiving the current cutting count of the device firmware 403. The device status includes normal status and abnormal status. If the device status is abnormal, the normal operation of the objects supported by the device firmware 403 is restricted. If the device status is normal, an authorization instruction is generated and returned to the system program 403.

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

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

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

[0201] Device firmware 403 is used to perform reverse verification and comparison of the verification information, and to authorize and bind the system program 404 after successful verification.

[0202] In the scheme for binding and verifying system service 405 and system program 404, the system program is used to obtain the application signature of the system program when loading the preset function library where device firmware 403 is located, verify the application signature, and complete the loading of the preset function library after the application signature verification is successful, so as to support the operation of the system program. Furthermore, when the system program obtains the device information corresponding to device firmware 403, it continues to verify the application signature until the application signature is verified again, and then encrypts the device information with a public key to complete the authorized binding with system service 405 where device firmware 403 is located.

[0203] In the scheme of binding system program 404 with the Android system of a smart device, system program 404 is used to obtain the system signature of the Android system, and re-sign the APK file of system program 404 based on the system signature to complete the binding of system program 404 with the Android system.

[0204] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the detailed description of the method for preventing smart devices from being hacked above, which will not be repeated here.

[0205] The smart device provided in this application embodiment and the smart device anti-hacking method in the above embodiment belong to the same concept. Any of the methods provided in the smart device anti-hacking method embodiment can be run on the smart device. For details of the specific implementation process, please refer to the smart device anti-hacking method embodiment, which will not be repeated here.

[0206] It should be noted that, regarding the method for preventing the hacking of smart devices in the embodiments of this application, those skilled in the art will understand that all or part of the process of implementing the method for preventing the hacking of smart devices in the embodiments of this application can be accomplished by controlling related hardware through a computer program. The computer program can be stored in a computer-readable storage medium, such as a memory, and executed by at least one processor. During execution, it can include the process of the embodiments of the method for preventing the hacking of smart devices. The storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), a random access memory (RAM), etc.

[0207] For the smart device in this application embodiment, its functional modules can be integrated into a single processing chip, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as 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 provides a detailed description of the method, smart device, and system for preventing hacking of smart devices provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for preventing hacking of smart devices, characterized in that, The smart device includes device firmware and system programs, and the method includes: When the system program is enabled, the current number of cuts in the device firmware is obtained; When the current number of cuts reaches the cut count threshold, an authorization instruction is obtained from the server. The cut count threshold is configured to be positively correlated with the total authorized cut count, which can be adjusted based on the offline cut count of the device firmware or the recent cut frequency. If an authorization instruction is received from the server, the smart device and the system program will operate normally. The system program will also pass the authorization instruction to the device firmware so that the device firmware can support the normal operation of the system program. If no authorization instruction is received from the server, the normal operation of the smart device and the system program will be restricted. When the system program is authorized and bound to the device firmware, the system program obtains the digital type provided by the device firmware and generates a signature key based on the digital type and the software signature. Obtain the dynamic key generated by the device firmware, and obtain the corresponding encrypted string based on the dynamic key; Verification information is generated based on the signature key and the encrypted string; The verification information is sent to the device firmware for verification, so that after the device firmware is successfully verified, the authorization binding between the system program and the device firmware is completed. The step of retrieving the authorization instruction from the server includes: The current number of cuts, the authorization number of the device firmware, and the device information of the smart device are encrypted to generate an authorization request; The authorization request is sent to the server to obtain the authorization instruction from the server.

2. The method for preventing hacking of smart devices 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, then it is determined whether the device firmware has been authorized. If the device firmware has been authorized, and the current number of cuts reaches the cutting number threshold, then the step of obtaining an authorization instruction from the server is executed; If the device firmware is not authorized, then an authorization configuration is performed on the device firmware.

3. The method for preventing hacking of smart devices according to claim 1, characterized in that, After obtaining the authorization instruction from the server when the current number of cuts reaches the cut count threshold, the method further includes: If no authorization instruction is received from the server within the preset time period, a prompt message will be provided indicating that the smart device needs to connect to the internet to obtain the authorization instruction.

4. The method for preventing hacking of smart devices according to any one of claims 1 to 3, characterized in that, The method further includes: When the system program is authorized and bound to the system services of the smart device, the application signature of the system program is verified. After the application signature verification is successful, a preset function library is loaded to support the operation of the system program. When the system program obtains the device information of the smart device, it verifies the application signature again. After the application signature is verified again, the device information is encrypted with a public key to complete the authorization binding between the system program and the system service.

5. The method for preventing hacking of smart devices according to any one of claims 1 to 3, characterized in that, The method also includes: When the system program is authorized and bound to 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 binding between the system program and the Android system.

6. The method for preventing hacking of smart devices according to any one of claims 1 to 3, characterized in that, The method also includes: Before burning the device firmware into a set of chips, the device firmware is encrypted to generate an encryption key for the device firmware. The encryption key is stored on another set of chips; The smart device is configured to read the encryption key from the other set of chips for security verification during operation.

7. A smart device, characterized in that, include: processor; as well as A memory storing a computer program, which, when executed by the processor, causes the processor to perform the method for preventing the hacking of a smart device as described in any one of claims 1 to 6.

8. A system for preventing hacking of smart devices, characterized in that, The smart device includes device firmware, system program, system service, and Android system. The device firmware is authorized and bound to the system program, the system program is authorized and bound to the system service, and the system program is authorized and bound to the Android system. The authorization binding is implemented based on the smart device anti-hacking method as described in any one of claims 1 to 6.

Images