Method and device for correcting abnormal time of heartbeat packet data, equipment and medium

Abstract

The invention provides a method and device for correcting abnormal time of heartbeat packet data, equipment and a medium. The method is applied to a PC terminal, and comprises the following steps: acquiring current time and historical heartbeat packet data of the PC terminal; wherein the historical heartbeat packet data represents a heartbeat packet sent to the device end by the PC end in a historical time period; determining an abnormal condition according to the historical heartbeat packet data and the current time; wherein the abnormal condition indicates whether the PC end has abnormal time or not; correcting the current time based on the abnormal condition and the historical heartbeat packet data to obtain the corrected current time; and sending the heartbeat packet data containing the corrected timestamp of the current time to the equipment end. According to the method, the heartbeat packet data time accuracy can be verified.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, device and medium for correcting abnormal time in heartbeat packet data. Background Technology

[0002] The PC typically needs to periodically send heartbeat packets containing time information to the device to maintain the connection and synchronize the state. The device relies on the timestamps in these heartbeat packets to perform critical operations, such as determining whether to authorize access or triggering other predefined events.

[0003] However, in the above methods, the PC's time settings are easily tampered with by users. Since the time data in the heartbeat packet comes directly from the PC's system clock, once the user modifies the system time, the time data in the heartbeat packet will be distorted. This will cause the device to make judgments based on incorrect time, potentially leading to a series of problems such as unauthorized access, false event triggering, or missing important operation opportunities.

[0004] Therefore, there is an urgent need for a solution that can verify or protect the time accuracy of heartbeat packet data. Summary of the Invention

[0005] Based on the defects and shortcomings of the prior art, this application proposes a method, apparatus, device and medium for correcting abnormal time of heartbeat packet data, which can verify the accuracy of heartbeat packet data time.

[0006] According to a first aspect of the embodiments of this application, a method for correcting abnormal time in heartbeat packet data is provided. The method is applied on a PC and includes: Obtain the current time and historical heartbeat data from the PC; the historical heartbeat data represents the heartbeats sent from the PC to the device during historical time periods. Based on historical heartbeat data and the current time, anomalies are identified; the anomaly indicator shows whether an abnormal time has occurred on the PC. Based on abnormal conditions and historical heartbeat data, the current time is corrected to obtain the corrected current time. Send the heartbeat packet data, which includes the corrected timestamp of the current time, to the device.

[0007] In one possible implementation, historical heartbeat data includes historical time; based on the historical heartbeat data and the current time, abnormal situations are determined, including: If the historical time in the historical heartbeat packet data is later than or equal to the current time, the abnormal situation is determined to be a time tampering situation on the PC. If the historical time in the historical heartbeat data is earlier than the current time, then the abnormal situation is determined to be that there is no time tampering on the PC.

[0008] In one possible implementation, the current time is corrected based on abnormal conditions and historical heartbeat data to obtain the corrected current time, including: If the abnormal situation is determined to be due to time tampering on the PC, the current time is corrected based on historical heartbeat data to obtain the corrected current time. If the abnormal situation is determined to be that there is no time tampering on the PC, then the current time is determined to be the corrected current time.

[0009] In one possible implementation, the historical heartbeat data includes historical time; the current time is corrected based on the historical heartbeat data to obtain the corrected current time, including: The current time is corrected based on historical time and preset interval time to obtain the corrected current time; where preset interval time represents the preset interval time at which the PC sends heartbeat data to the device.

[0010] In one possible implementation, the heartbeat packet data includes: a timestamp, cumulative usage duration, heartbeat count, and a checksum; wherein, the timestamp represents the corrected current time; the cumulative usage duration represents the cumulative usage duration of the device within the authorized validity period; the heartbeat count represents the number of times the PC sends heartbeat packet data to the device; and the checksum represents the encrypted digest generated by the communication between the PC and the device.

[0011] According to a second aspect of the embodiments of this application, a method for correcting abnormal time in heartbeat packet data is provided. The method is applied to a device and includes: Receive heartbeat data sent by the PC; the heartbeat data is generated by the PC after correcting the current time based on the current time and historical heartbeat data when an abnormal situation is determined. The heartbeat packet data is parsed to obtain the parsed heartbeat packet data. The operating status of the device is determined based on the parsed heartbeat packet data.

[0012] In one possible implementation, the parsed heartbeat data packet includes a timestamp; based on the parsed heartbeat data packet, the operating status of the device is determined, including: If the timestamp is within the preset authorized time period, the device's operating status is determined to be authorized. If the timestamp is not within the preset authorized time period, the device's operating status is determined to be unauthorized.

[0013] In one possible implementation, the parsed heartbeat data packet includes a checksum; based on the parsed heartbeat data packet, the operating status of the device is determined, including: Based on the checksum, the heartbeat packet data is verified to obtain the verification result; If the verification result indicates that the verification failed, then the operating status of the device is determined to be locked. If the verification result indicates that the verification was successful, then the operating status of the device is determined to be normal.

[0014] According to a third aspect of the embodiments of this application, an apparatus for correcting abnormal times in heartbeat packet data is provided. The apparatus is applied to a PC and includes: The acquisition module is used to acquire the current time and historical heartbeat data from the PC; the historical heartbeat data represents the heartbeat packets sent from the PC to the device during historical time periods. The determination module is used to determine abnormal situations based on historical heartbeat data and the current time; among which, the abnormal situation indicates whether an abnormal time has occurred on the PC. The correction module is used to correct the current time based on abnormal conditions and historical heartbeat data to obtain the corrected current time; The sending module is used to send heartbeat packet data containing a corrected timestamp of the current time to the device.

[0015] In one possible implementation, the historical heartbeat data includes historical time; the determination module includes: If the historical time in the historical heartbeat packet data is later than or equal to the current time, the abnormal situation is determined to be a time tampering situation on the PC. If the historical time in the historical heartbeat data is earlier than the current time, then the abnormal situation is determined to be that there is no time tampering on the PC.

[0016] In one possible implementation, the correction module includes: The first correction module is used to correct the current time based on historical heartbeat data if the abnormal situation is determined to be time tampering on the PC. The second correction module is used to determine the current time as the corrected current time if the abnormal situation is determined to be that there is no time tampering on the PC.

[0017] In one possible implementation, the historical heartbeat data includes historical time; the first correction module includes: The current time is corrected based on historical time and preset interval time to obtain the corrected current time; where preset interval time represents the preset interval time at which the PC sends heartbeat data to the device.

[0018] In one possible implementation, the heartbeat packet data includes: a timestamp, cumulative usage duration, heartbeat count, and a checksum; wherein, the timestamp represents the corrected current time; the cumulative usage duration represents the cumulative usage duration of the device within the authorized validity period; the heartbeat count represents the number of times the PC sends heartbeat packet data to the device; and the checksum represents the encrypted digest generated by the communication between the PC and the device.

[0019] According to a fourth aspect of the embodiments of this application, an apparatus for correcting abnormal times in heartbeat packet data is provided. The apparatus is applied to a device and includes: The receiving module is used to receive heartbeat data sent by the PC. The heartbeat data is generated by the PC after correcting the current time based on the current time and historical heartbeat data when an abnormal situation is determined. Parsing and processing are used to parse the heartbeat packet data to obtain the parsed heartbeat packet data; The determination module is used to determine the operating status of the device based on the parsed heartbeat packet data.

[0020] In one possible implementation, the parsed heartbeat data packet includes a timestamp; the determining module includes: If the timestamp is within the preset authorized time period, the device's operating status is determined to be authorized. If the timestamp is not within the preset authorized time period, the device's operating status is determined to be unauthorized.

[0021] In one possible implementation, the parsed heartbeat data packet includes a checksum; the determining module includes: Based on the checksum, the heartbeat packet data is verified to obtain the verification result; If the verification result indicates that the verification failed, then the operating status of the device is determined to be locked. If the verification result indicates that the verification was successful, then the operating status of the device is determined to be normal.

[0022] According to a fifth aspect of the present application, an electronic device is provided, including: a memory and a processor; the memory is connected to the processor and is used to store a program; the processor is used to implement the method of the first aspect of the present application by running the program in the memory.

[0023] According to a sixth aspect of the embodiments of this application, a storage medium is provided, on which a computer program is stored, and when the computer program is run by a processor, it implements the method of the first aspect of the embodiments of this application.

[0024] According to a seventh aspect of the present application, a computer program product is provided, including computer program instructions that, when executed by a processor, cause the processor to implement the method as described in the first aspect of the present application.

[0025] According to an eighth aspect of the embodiments of this application, a chip is provided, including a processor and a data interface, wherein the processor reads and runs a program stored in a memory through the data interface to perform a method as described in any of the first aspects of the embodiments of this application.

[0026] This application provides a method, apparatus, device, and medium for correcting abnormal times in heartbeat packet data. It acquires the current time and historical heartbeat packet data from a PC. The historical heartbeat packet data accurately characterizes the heartbeat packets sent from the PC to the device during historical time periods, providing fundamental data support for subsequent analysis. Next, a deep analysis is performed based on the historical heartbeat packet data and the current time to identify abnormal conditions. These abnormal conditions clearly indicate whether abnormal times have occurred on the PC, providing a key basis for subsequent correction. Then, based on the identified abnormal conditions and historical heartbeat packet data, the current time is scientifically corrected to obtain the accurate corrected current time. Finally, the heartbeat packet data containing the corrected current time timestamp is accurately sent to the device. This effectively solves the problem of inaccurate heartbeat packet data caused by abnormal PC time, which affects normal communication between the device and the PC. It ensures the stability and accuracy of data transmission between the device and the PC, guaranteeing the efficient and reliable operation of the entire system. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0028] Figure 1 A flowchart illustrating a method for correcting abnormal time in heartbeat packet data provided in this application embodiment. Figure 1 .

[0029] Figure 2 A flowchart illustrating a method for correcting abnormal time in heartbeat packet data provided in this application embodiment. Figure 2 .

[0030] Figure 3 A flowchart illustrating a method for correcting abnormal time in heartbeat packet data provided in this application embodiment. Figure 3 .

[0031] Figure 4 A schematic diagram of the structure of a heartbeat packet data abnormality correction device provided in this application embodiment. Figure 1 .

[0032] Figure 5 A schematic diagram of the structure of a heartbeat packet data abnormality correction device provided in this application embodiment. Figure 2 .

[0033] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0034] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0035] First, the technical terms involved in the embodiments of this application will be explained: The PC client is a software application running on the user's computer, such as a professional 3D design software or data acquisition tool. It acts as the system's "commander" and "coordinator," responsible for periodically generating "heartbeat" signals, collecting the local system time, and communicating with the device. Its core challenge lies in the fact that its environment is untrusted, with the user having full authority to modify the system time.

[0036] The device side is a physical peripheral without real-time clock (RTC) hardware, typically manifested as a USB dongle, industrial control module, or dedicated data acquisition card. Acting as the system's recorder and arbitrator, it internally contains a microcontroller and a non-volatile memory to store critical time anchor data. The device side's fundamental task is to maintain a reliable time reference that only increments, even if the time information from the PC is unreliable.

[0037] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only one component of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0038] Before introducing the solution proposed in this application, the relevant technologies will first be introduced: In current heartbeat-based state synchronization systems, the PC acts as the control center, periodically sending heartbeat data packets to devices without a real-time clock (RTC). The core function of these packets is to maintain communication connections, synchronize states, and carry crucial timestamp information. Devices rely entirely on these timestamps from the PC to perform a series of critical logical decisions, such as verifying authorization validity periods, real-time control of function access permissions, or triggering time-based events. While this architecture works effectively in an ideal state, a fundamental prerequisite for its security is the absolute reliability of the PC's system time.

[0039] However, because PCs run in a general-purpose operating system environment under complete user control, their system clocks lack any anti-tampering properties. Users can easily modify the system time through various means (such as manually adjusting the system date and time, resetting it in the BIOS, using virtual machine snapshots to roll back to a past state, or utilizing software time freeze services). This capability directly renders the timestamp information carried in heartbeat packets unreliable. When a maliciously modified or unintentionally misset time is encapsulated in a heartbeat packet and sent to the device, the device will make decisions based on this distorted and non-linear time data.

[0040] Based on this, embodiments of this application provide a method, apparatus, device, and medium for correcting abnormal timestamps in heartbeat packet data. By acquiring the current time and historical heartbeat packet data from the PC, determining the abnormal situation based on the historical heartbeat packet data and the current time, and correcting the current time based on the abnormal situation and historical heartbeat packet data to obtain the corrected current time, the heartbeat packet data containing the corrected timestamp is finally sent to the device. This achieves real-time detection and adaptive correction of PC time anomalies, effectively solving the problem of incorrect heartbeat packet data or misjudgment of device connection status caused by inaccurate time, thereby improving the reliability of heartbeat packet communication and system stability.

[0041] The method provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0042] Exemplary methods Figure 1 A flowchart illustrating a method for correcting abnormal time in heartbeat packet data provided in this application embodiment. Figure 1 Please see. Figure 1 In one exemplary embodiment, the provided method may include the following steps: S101. The PC obtains the current time and historical heartbeat data of the PC. The historical heartbeat data represents the heartbeats sent by the PC to the device during historical time periods.

[0043] For example, the current time and historical heartbeat data of the PC are obtained; wherein, the historical heartbeat data represents the heartbeat packets sent from the PC to the device during historical time periods.

[0044] Optionally, before the PC needs to send heartbeat data to the device, the current time of the PC should be obtained first. The current UTC or local time of the PC should be obtained in real time and formatted into a standard timestamp (such as ISO 8601 format).

[0045] Before sending a heartbeat packet to the device, the PC calls the time acquisition module to generate the current timestamp and a heartbeat identifier (such as an incrementing sequence number or a random string). The two are then encapsulated into heartbeat packet data and sent. After sending, the data is immediately appended to the historical storage.

[0046] Retrieve historical heartbeat data from historical storage.

[0047] S102. The PC determines the abnormal situation based on historical heartbeat data and the current time; the abnormal situation indicates whether an abnormal time has occurred on the PC.

[0048] For example, the timestamps of the most recent N historical heartbeat packets are retrieved from the historical heartbeat packet data to form a list [T1, T2, ..., Tn].

[0049] Calculate the interval ΔT_k between adjacent timestamps of historical heartbeat packets = T_(k+1)-T_k. Theoretically, heartbeats are sent periodically, and the interval should be approximately the preset period P.

[0050] Optionally, the mean and standard deviation of the actual intervals ΔT_k can be calculated, and a dynamic threshold can be set (e.g., mean ± 3 times the standard deviation). If any ΔT_k exceeds the threshold, a time jump or program freeze is determined.

[0051] Optionally, the timestamp Tn of the most recent historical heartbeat packet is taken, and the difference between it and the current time T_now_ref is calculated to obtain the actual elapsed time ΔT_real = T_now_ref - Tn from the last heartbeat to the present. Meanwhile, after sending the last heartbeat packet, if the PC sends heartbeats normally according to the preset heartbeat period P, the expected number of heartbeat packets sent should be count_expected = round(ΔT_real / P). The actual number of heartbeat packets sent by the PC within the ΔT_real period is obtained as count_actual (which can be obtained by querying the heartbeat records within the time period (T_now_ref - ΔT_real, T_now_ref)). The drift rate is calculated as: drift_rate = |count_expected - count_actual| / count_expected. If drift_rate exceeds a threshold (e.g., 5%), it indicates that there is a significant deviation between the PC's clock elapsed rate (frequency) and the actual time, i.e., a clock skew exists.

[0052] Optionally, the historical heartbeat timestamp sequence [T1, T2, ..., Tn] is fitted to an ideal time-growth model (e.g., starting at T1 and increasing with period P). The actual timestamp Tk is calculated as a function of the theoretical value (T1 + (k-1)). The residuals of P). If multiple consecutive residuals are found to undergo a step-like abrupt change in the same direction, rather than random fluctuations, then a time jump has occurred.

[0053] S103 and PC terminals correct the current time based on abnormal conditions and historical heartbeat data to obtain the corrected current time.

[0054] For example, if the anomaly is clock skew, a linear regression model is used. The PC timestamp from historical heartbeat packet data is used as the independent variable X, and the relative real time inferred from the heartbeat interval is used as the dependent variable Y. A linear fit is performed to obtain the formula Y = α. X + β. Here, the slope α estimates the relative speed of the PC clock (α>1 indicates the PC clock is running faster), and the intercept β estimates a fixed initial offset. During correction, the current PC time T_pc_now, which needs to be corrected, is substituted into the formula to obtain the corrected time T_corrected = α. T_pc_now + β.

[0055] If the anomaly is a time jump, a piecewise constant offset correction is used. Two stable time periods before and after the jump are identified. Assuming the jump occurs in the k-th heartbeat in the historical record, the most recent historical data after the jump (e.g., the k-th to n-th heartbeats) is used to calculate the average offset between the PC timestamp and the reference time within that time period: offset = mean( T_reference_i - T_pc_i). During correction, T_corrected = T_pc_now + offset.

[0056] If the abnormal condition is time standstill, extrapolation is used. The start point of the standstill is determined (i.e., the time of the last valid heartbeat packet, T_last_valid, and its corresponding reference time, T_ref_last). Since the PC clock does not update during the standstill, its reported current time, T_pc_now, is meaningless. The corrected time is obtained by adding the elapsed time estimated based on the heartbeat cycle to the last known valid point: T_corrected = T_ref_last + (T_external_now - T_external_last).

[0057] S104. The PC will send the heartbeat packet data containing the corrected current time timestamp to the device.

[0058] For example, heartbeat packet data containing a corrected timestamp of the current time is sent to the device.

[0059] According to the technical solution of this embodiment, the current time and historical heartbeat data of the PC are obtained. The historical heartbeat data accurately characterizes the relevant situations of heartbeat packets sent from the PC to the device during historical time periods, providing basic data support for subsequent analysis. Next, a deep analysis is performed based on the historical heartbeat data and the current time to identify abnormal situations. These abnormal situations clearly indicate whether abnormal times have occurred on the PC, providing a key basis for subsequent corrections. Then, based on the identified abnormal situations and the historical heartbeat data, the current time is scientifically corrected to obtain the accurate corrected current time. Finally, the heartbeat data containing the timestamp of the corrected current time is accurately sent to the device. This effectively solves the technical problem of inaccurate heartbeat data caused by abnormal PC time, which affects normal communication between the device and the PC. It achieves the beneficial effect of ensuring the stability and accuracy of data transmission between the device and the PC, ensuring the efficient and reliable operation of the entire system.

[0060] Figure 2 A flowchart illustrating a method for correcting abnormal time in heartbeat packet data provided in this application embodiment. Figure 2 Please see. Figure 2 In one exemplary embodiment, the provided method may include the following steps: S201. Obtain the current time and historical heartbeat data from the PC.

[0061] For example, this step can be referred to step S101, and will not be described again.

[0062] In one example, the heartbeat packet data includes: timestamp, cumulative usage time, heartbeat count, and verification code; where the timestamp represents the corrected current time; the cumulative usage time represents the cumulative usage time of the device within the authorized validity period; the heartbeat count represents the number of times the PC sends heartbeat packet data to the device; and the verification code represents the encrypted digest generated by the communication between the PC and the device.

[0063] For example, the timestamp is a more reliable system time estimate obtained by the PC through previous detection and correction algorithms, rather than the original operating system time. Its technical significance lies in providing a consistent and accurate time reference for the entire communication system.

[0064] Cumulative usage time is the total working time of the device within the validity period of this authorization. It is usually accumulated in seconds or minutes. This data may be reported by the device each time it works and recorded by the PC, or it may be accumulated by the PC according to the device status instructions. Its core function is to realize authorization control or usage statistics based on time.

[0065] The heartbeat count is the total number of times the PC has successfully sent heartbeat packets to the device since the start of the current connection or authorization cycle. It is mainly used to detect packet loss in network communication (by sequence number interval) and can help determine connection activity.

[0066] A checksum is a digest generated by performing a cryptographic hash operation on all other data fields (or fields containing a specific key) in a heartbeat packet. Its purpose is to verify whether the data has been tampered with during transmission, to authenticate the legitimacy of the message source, and to ensure secure communication.

[0067] S202. If the historical time in the historical heartbeat packet data on the PC is later than or equal to the current time, the abnormal situation is determined to be that the PC has experienced time tampering; if the historical time in the historical heartbeat packet data is earlier than the current time, the abnormal situation is determined to be that the PC has not experienced time tampering.

[0068] For example, historical time is the timestamp recorded in historical heartbeat packet data. These timestamps are the values ​​that the PC wrote and stored in the data packet each time it sent a heartbeat packet in the past (which may be before or after the correction). Together, they constitute an event record on the local timeline of the PC.

[0069] Read the historical heartbeat packet data corresponding to the device from the protected persistent storage, and extract all the timestamp fields therein to form a historical timestamp list H = [T1, T2, ..., Tn]. At the same time, for the upcoming new heartbeat packet, obtain the current system time of the PC side as the current time T_now to be checked.

[0070] To ensure the robustness of the judgment, sort the historical timestamp list H in ascending order according to time. Take the largest timestamp therein as the key benchmark, that is, T_last = max(H), which represents the time point of the last valid heartbeat record.

[0071] If the current time T_now == T_last (the heartbeat interval is usually not zero), it can be regarded as an extreme tampering where the clock has stalled or the time has been reset and then happened to return to the origin exactly; if T_now > T_last, it is a normal situation.

[0072] If the current time T_now < T_last: it clearly indicates that the new timestamp is earlier than the last recorded time, and the time has reversed, which is an absolute ironclad evidence of human tampering. Therefore, determine that the abnormal situation is that time tampering has occurred on the PC side.

[0073] Output the judgment result (time tampering or no tampering found) to the system's exception handling module. If it is determined to be tampering, usually a high-level security alarm will be triggered, the service will be suspended, a security log will be recorded, and the values of T_now and T_last of this exception may be stored as evidence in the log.

[0074] S203. If the PC side determines that the abnormal situation is that time tampering has occurred on the PC side, then correct the current time according to the historical heartbeat packet data to obtain the corrected current time; if it is determined that the abnormal situation is that time tampering has not occurred on the PC side, then determine the current time as the corrected current time.

[0075] Exemplarily, obtain the timestamp list [T_{k-N+1}, ..., T_{k-1}, T_k] of the most recent N valid historical heartbeat packets from the integrity-protected historical storage, where T_k is T_last.

[0076] Calculate the average value avg_interval = average(T_{i} - T_{i-1}) of the adjacent intervals of these historical timestamps, which represents the average occurrence period of heartbeats on the real time axis during the non-tampered period.

[0077] After the last reliable time point T_last, real time continues to flow at a rate of avg_interval. Therefore, the corrected current time T_corrected is calculated as follows: T_corrected = T_last + avg_interval.

[0078] In one possible implementation, for greater accuracy, the sequence number of the last valid heartbeat, Count_last, can be recorded, and a heartbeat attempt counter, Count_now, can be maintained since then. Then, T_corrected = T_last + (Count_now - Count_last). avg_interval.

[0079] If the abnormal situation is determined to be that there is no time tampering on the PC, directly call the system time function (or use the current time T_now that was previously obtained for detection) and assign it to T_corrected, that is, T_corrected = get_system_time().

[0080] The calculated or assigned value T_corrected is passed as the output of this step to the heartbeat packet building module as the value of its timestamp field.

[0081] S204. The PC terminal corrects the current time based on the historical time and the preset interval time to obtain the corrected current time; where the preset interval time represents the preset interval time at which the PC terminal sends heartbeat packet data to the device terminal.

[0082] For example, retrieve the timestamp of the most recently verified valid or trusted heartbeat packet from the protected historical storage, denoted as T_base. Read the preset heartbeat sending interval P (in seconds) from the configuration file or constant definition.

[0083] Read the current system time (or the time after preliminary processing) from the PC and record it as T_now_raw. This time may be inaccurate due to clock malfunctions.

[0084] Calculate the raw time elapsed since the base point: Delta_raw = T_now_raw - T_base. Then, calculate the floating-point multiple of Delta_raw relative to the interval P: n_float = Delta_raw / P.

[0085] Choose the alignment method based on business requirements. Common strategies include: a) Rounding up (Ceil): n = ceil(n_float), ensuring that the corrected time T_corrected = T_base + n. P is no earlier than T_now_raw, suitable for scenarios where timestamp reversal is not allowed. b) Rounding: n = round(n_float), making the corrected time as close as possible to the original time, with the technical effect of minimizing the average error. c) Flooring: n = floor(n_float), ensuring that the corrected time is no later than the original time. Generally, to ensure the timeliness of events and prevent time "travel", the flooring strategy is safer. Therefore, the formula for calculating the corrected current time is: T_corrected = T_base + ceil((T_now_raw - T_base) / P) P. Output T_corrected as the authoritative timestamp used in subsequent processes (such as building heartbeat packets).

[0086] According to the technical solution of this embodiment, the current time and historical heartbeat packet data of the PC are obtained as the basis for analysis. Next, a detailed comparison is made between the historical time and the current time in the historical heartbeat packet data: if the historical time is later than or equal to the current time, the abnormal situation is determined to be time tampering on the PC; if the historical time is earlier than the current time, the abnormal situation is determined to be no time tampering on the PC. If time tampering is determined, the current time is corrected based on the historical heartbeat packet data to obtain the corrected current time; if no time tampering is determined, the current time is directly determined to be the corrected current time. Furthermore, the current time is further corrected based on the historical time and a preset interval. This effectively solves the problem of inaccurate heartbeat packet data caused by abnormal PC time, especially time tampering, which affects normal communication between the device and the PC, thus ensuring stable and accurate data transmission between the device and the PC and ensuring reliable system operation.

[0087] Figure 3 A flowchart illustrating a method for correcting abnormal time in heartbeat packet data provided in this application embodiment. Figure 3 Please see. Figure 3 In one exemplary embodiment, the provided method may include the following steps: S301. The device receives heartbeat data sent by the PC. The heartbeat data is generated by the PC after correcting the current time based on the current time and historical heartbeat data when it determines an abnormal situation.

[0088] For example, when the device is powered on or the service is started, a network socket (such as a TCP Server Socket or UDP Socket) is created, bound to a preset IP address and port number, and begins listening (for TCP) or preparing to receive (for UDP).

[0089] Entering the main service loop, the `accept()` function is called to block and wait for connection requests from the PCs. Once a connection is established, a separate thread or asynchronous task is created for that connection to handle subsequent communication, ensuring concurrent service to multiple PCs.

[0090] In the connection context or datagram processing logic, the recv() function is called repeatedly to read data from the network buffer until all bytes of a complete application layer message are collected. Protocols typically use length fields or delimiters to define message boundaries.

[0091] The heartbeat data received by the device is generated by the PC after correcting the current time based on the current time and historical heartbeat data to determine an abnormal situation.

[0092] S302. The device parses and processes the heartbeat packet data to obtain the parsed heartbeat packet data.

[0093] For example, the raw byte stream read from the network socket is stored in a buffer. The boundaries of a complete data packet are identified according to the design of the application layer protocol. For instance, if the protocol uses a length prefix, a fixed number of bytes are read first to obtain the length N, and then the next N bytes are read from the buffer as a complete packet; if a delimiter (such as a newline character) is used, reading continues until a delimiter is encountered.

[0094] The extracted complete data packet byte stream is decoded according to the agreed data format. For example, if JSON is used, the json.loads() function is called; if Protobuf is used, the corresponding ParseFromString() method is called. This step converts the byte stream into a dictionary or a specific message object containing the fields.

[0095] From the deserialized object, the checksum (e.g., the checksum field) is extracted and temporarily removed, leaving the core data to be verified. Then, the core data is re-converted into a byte string using the same serialization rules as the PC (same field order and encoding), and its HMAC value is calculated using the shared key. This calculated value is then securely compared with the extracted checksum. If they do not match, the process terminates, a security log is recorded, and the data packet is discarded. If they match, the process proceeds to the next step.

[0096] After passing the verification, business fields are extracted one by one from the core data object. This usually includes: converting the value of the timestamp field to the time type of the device-side programming language; converting the cumulative usage duration to an integer or a floating point number; converting the number of heartbeats to an integer, etc.

[0097] Perform basic rationality verification on the extracted fields. For example, check whether the timestamp deviates too much from the device-side local time (e.g., more than 24 hours), and check whether the number of heartbeats is greater than the previously recorded number of heartbeats. These checks can quickly detect obvious anomalies.

[0098] Organize the verified and converted fields into a new, clean data structure (e.g., a Python data class instance or a C structure), and output it as the parsed heartbeat packet data to the subsequent business processing module.

[0099] S303. The device determines the running state of the device according to the parsed heartbeat packet data.

[0100] Exemplarily, the device determines the running state of the device according to the parsed heartbeat packet data.

[0101] Read the total authorized duration D_total of the device from the configuration. Calculate the remaining authorized duration D_remaining = D_total - D_cumulative. If D_remaining <= 0, the authorization status is expired; if 0 < D_remaining <= D_warning (warning threshold, such as 7 days), the authorization status is about to expire (warning); if D_remaining > D_warning, the authorization status is valid. Hysteresis logic can be used here to avoid jitter near the threshold.

[0102] In one example, the parsed heartbeat data packet includes a timestamp; if the timestamp is within the preset authorized period, the running state of the device is determined to be the authorized state; if the timestamp is not within the preset authorized period, the running state of the device is determined to be the unauthorized state.

[0103] Exemplarily, extract the timestamp field from the parsed heartbeat packet data object and denote it as the current time. At the same time, read the start time and end time of the preset authorized period from the device-side security configuration storage (such as an encrypted configuration file, a security chip, or encrypted data pulled from an authorization server).

[0104] To ensure a valid comparison, all times must be converted to the same representation and time zone. Typically, all times are converted to a Unix timestamp (seconds since 1970-01-01 UTC) or an ISO 8601 formatted UTC time string for comparison. If the default authorized time period is stored in local time or a specific format string, it must be explicitly converted to a UTC timestamp in this step.

[0105] Perform logical judgment; if the start time of the authorized period is less than or equal to the current time, and the end time of the authorized period is less than or equal to the end time of the authorized period, then determine that the device's operating status is authorized; if the current time is less than the start time of the authorized period or greater than the end time of the authorized period, then determine that the device's operating status is unauthorized.

[0106] In one example, the parsed heartbeat data packet includes a checksum; based on the checksum, the heartbeat data packet is validated to obtain the validation result; if the validation result indicates validation failure, the device's operating status is determined to be locked; if the validation result indicates validation success, the device's operating status is determined to be normal.

[0107] For example, from the parsed structured heartbeat packet data, the checksum field and the core data to be verified are explicitly separated. The core data typically includes business fields such as timestamp, cumulative usage duration, and number of heartbeats, but does not include the checksum itself.

[0108] The core data is converted into a byte string strictly following the same serialization rules as the PC (same field order, encoding format, no extra spaces, etc.). This is a crucial step; any serialization differences will lead to different digests in subsequent calculations, resulting in misjudgments.

[0109] Using a key that is securely shared with the PC in advance, the HMAC value is calculated on the byte string obtained above using a hash algorithm agreed upon by both parties (such as SHA256), resulting in calculated_digest.

[0110] The checksum field and the calculated_digest are compared using a constant-time comparison function. If they match perfectly, the verification is successful; otherwise, it fails.

[0111] If the verification fails, the device's operating status is immediately determined to be locked; if the verification succeeds, the device's operating status is determined to be normal. This decision should have the highest priority, typically preceding timestamp-based authorization status checks.

[0112] If the status is locked, an emergency security protocol is triggered, such as disconnecting the network connection from the current PC, sending an alarm to the management platform, and setting the device to a minimum security mode. Furthermore, regardless of success or failure, this verification event should be recorded in detail for auditing purposes.

[0113] According to the technical solution of this embodiment, the device first receives heartbeat packet data sent by the PC. This heartbeat packet data is generated by the PC after determining an abnormal situation based on the current time and historical heartbeat packet data, correcting the current time, and then generating the data based on the corrected current time. The device parses the received data to obtain the parsed heartbeat packet data, which includes key information such as timestamps and checksums. For the timestamp, the device determines whether it is within a preset authorized time period. If it is, the device is determined to be in an authorized state and can perform various operations normally; if not, it is determined to be in an unauthorized state, and the use of some functions is restricted. For the checksum, the device verifies the heartbeat packet data accordingly. If the verification result indicates failure, it means that the data may have been tampered with or is abnormal. In this case, the device is determined to be in a locked state to prevent potential risks; if the verification is successful, the device is determined to be in a normal state. This effectively solves the technical problem of misjudging the device's operating state due to time abnormalities or data tampering, which affects the safe and stable operation of the device, and ensures that the device operates stably in a legal and secure environment.

[0114] Exemplary device Correspondingly, Figure 4 A schematic diagram of the structure of a heartbeat packet data abnormality correction device provided in this application embodiment. Figure 1 ,like Figure 4 As shown, the device 400 provided in this embodiment is applied to a PC. The device 400 may include: The acquisition module 401 is used to acquire the current time and historical heartbeat data of the PC; wherein, the historical heartbeat data represents the heartbeat packets sent from the PC to the device during historical time periods; The determination module 402 is used to determine abnormal situations based on historical heartbeat packet data and the current time; wherein, the abnormal situation indicates whether an abnormal time has occurred on the PC. The correction module 403 is used to correct the current time based on abnormal conditions and historical heartbeat packet data to obtain the corrected current time; The sending module 404 is used to send heartbeat packet data containing a corrected timestamp of the current time to the device.

[0115] In one possible implementation, the historical heartbeat data includes historical time; the determination module 402 includes: If the historical time in the historical heartbeat packet data is later than or equal to the current time, the abnormal situation is determined to be a time tampering situation on the PC. If the historical time in the historical heartbeat data is earlier than the current time, then the abnormal situation is determined to be that there is no time tampering on the PC.

[0116] In one possible implementation, the correction module 403 includes: The first correction module 4031 is used to correct the current time based on historical heartbeat data if the abnormal situation is determined to be time tampering on the PC. The second correction module 4032 is used to determine the current time as the corrected current time if the abnormal situation is determined to be that there is no time tampering on the PC.

[0117] In one possible implementation, the historical heartbeat data includes historical time; the first correction module 4031 includes: The current time is corrected based on historical time and preset interval time to obtain the corrected current time; where preset interval time represents the preset interval time at which the PC sends heartbeat data to the device.

[0118] In one possible implementation, the heartbeat packet data includes: a timestamp, cumulative usage duration, heartbeat count, and a checksum; wherein, the timestamp represents the corrected current time; the cumulative usage duration represents the cumulative usage duration of the device within the authorized validity period; the heartbeat count represents the number of times the PC sends heartbeat packet data to the device; and the checksum represents the encrypted digest generated by the communication between the PC and the device.

[0119] The apparatus provided in this embodiment belongs to the same concept as the method provided in the above embodiments of this application, and can execute the method provided in any of the above embodiments of this application, possessing the corresponding functional modules and beneficial effects for executing the method. Technical details not described in detail in this embodiment can be found in the specific processing content of the method provided in the above embodiments of this application, and will not be repeated here.

[0120] Correspondingly, Figure 5 A schematic diagram of the structure of a heartbeat packet data abnormality correction device provided in this application embodiment. Figure 2 ,like Figure 5 As shown, the device 500 provided in this embodiment is applied to the device side, and the device 500 may include: The receiving module 501 is used to receive heartbeat packet data sent by the PC. The heartbeat packet data is generated by the PC after correcting the current time based on the current time and historical heartbeat packet data when it determines an abnormal situation. Parsing Process 502 is used to parse and process the heartbeat packet data to obtain the parsed heartbeat packet data; The determination module 503 is used to determine the operating status of the device based on the parsed heartbeat packet data.

[0121] In one possible implementation, the parsed heartbeat data packet includes a timestamp; the determining module 503 includes: If the timestamp is within the preset authorized time period, the device's operating status is determined to be authorized. If the timestamp is not within the preset authorized time period, the device's operating status is determined to be unauthorized.

[0122] In one possible implementation, the parsed heartbeat data packet includes a checksum; the determining module 503 includes: Based on the checksum, the heartbeat packet data is verified to obtain the verification result; If the verification result indicates that the verification failed, then the operating status of the device is determined to be locked. If the verification result indicates that the verification was successful, then the operating status of the device is determined to be normal.

[0123] The apparatus provided in this embodiment belongs to the same concept as the method provided in the above embodiments of this application, and can execute the method provided in any of the above embodiments of this application, possessing the corresponding functional modules and beneficial effects for executing the method. Technical details not described in detail in this embodiment can be found in the specific processing content of the method provided in the above embodiments of this application, and will not be repeated here.

[0124] It should be understood that the modules in the above device can be implemented by a processor calling software. For example, the device includes a processor connected to a memory containing instructions. The processor calls the instructions stored in the memory to implement any of the above methods or to implement the functions of each unit of the device. The processor can be a general-purpose processor, such as a CPU or microprocessor, and the memory can be internal or external to the device. Alternatively, the units in the device can be implemented as hardware circuits. By designing the hardware circuits, some or all of the unit functions can be implemented. The hardware circuits can be understood as one or more processors. For example, in one implementation, the hardware circuit is an ASIC, and the functions of some or all of the above units are implemented by designing the logical relationships between the components within the circuit. In another implementation, the hardware circuit can be implemented by a PLD, such as an FPGA, which can include a large number of logic gates. The connection relationships between the logic gates are configured through configuration files to implement the functions of some or all of the above units. All units of the above device can be implemented entirely by a processor calling software, entirely by hardware circuits, or partially by a processor calling software with the remaining parts implemented by hardware circuits.

[0125] In this application embodiment, a processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction reading and execution capabilities, such as a CPU, microprocessor, GPU, or DSP. In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. These logical relationships are fixed or reconfigurable. For example, the processor may be a hardware circuit implemented as an ASIC or PLD, such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the processor loading instructions to implement the functions of some or all of the above units. Furthermore, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as an NPU, TPU, or DPU.

[0126] As can be seen, each unit in the above device can be one or more processors (or processing circuits) configured to implement the above methods, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms.

[0127] Furthermore, the units in the above devices can be integrated in whole or in part, or they can be implemented independently. In one implementation, these units are integrated together and implemented in the form of a System-on-Chip (SoC). The SoC may include at least one processor for implementing any of the above methods or implementing the functions of the units in the device. The at least one processor may be of different types, such as CPU and FPGA, CPU and artificial intelligence processor, CPU and GPU, etc.

[0128] Exemplary electronic devices This application provides an electronic device, see [link to relevant documentation] Figure 6 As shown, the electronic device includes a memory 600 and a processor 610 connected to the memory 600.

[0129] The memory 600 is used to store programs.

[0130] The processor 610 is configured to execute any method of the above embodiments to acquire the current time and historical heartbeat data of the PC, wherein the historical heartbeat data accurately characterizes the relevant situations of the PC sending heartbeat packets to the device during historical periods, providing basic data support for subsequent analysis. Next, a deep analysis is performed based on the historical heartbeat data and the current time to identify abnormal situations. These abnormal situations clearly indicate whether abnormal times have occurred on the PC, providing a key basis for subsequent correction. Then, based on the identified abnormal situations and the historical heartbeat data, the current time is scientifically corrected to obtain the corrected accurate current time. Finally, the heartbeat data containing the timestamp of the corrected current time is accurately sent to the device. This effectively solves the technical problem of inaccurate heartbeat data caused by abnormal PC time, which affects normal communication between the device and the PC, achieving the beneficial effect of ensuring the stability and accuracy of data transmission between the device and the PC, and ensuring that the entire system can operate efficiently and reliably.

[0131] For details on the specific processing procedure of the processor 610 described above, please refer to the description of the above method embodiments. For details on the specific implementation of the processor 610, please refer to the description of the above embodiments.

[0132] Specifically, the aforementioned electronic device may also include: a bus, a communication interface 620, an input device 630, and an output device 640.

[0133] The processor 610, memory 600, communication interface 620, input device 630, and output device 640 are interconnected via a bus. Among them: A bus can include a pathway for transmitting information between various components of a computer system.

[0134] The processor 610 can be a general-purpose processor, such as a general-purpose central processing unit (CPU), a microprocessor, etc., or an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program of the present invention. It can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0135] The processor 610 may include a main processor, as well as a baseband chip, modem, etc.

[0136] The memory 600 stores a program that executes the technical solution of this invention, and may also store an operating system and other key business functions. Specifically, the program may include program code, which includes computer operation instructions. More specifically, the memory 600 may include read-only memory (ROM), other types of static storage devices capable of storing static information and instructions, random access memory (RAM), other types of dynamic storage devices capable of storing information and instructions, disk storage, flash memory, etc.

[0137] Input device 630 may include a device for receiving user input data and information, such as an error microphone, keyboard, mouse, camera, scanner, light pen, voice input device, touch screen, pedometer, or gravity sensor.

[0138] Output device 640 may include devices that allow information to be output to a user, such as a speaker, display screen, printer, etc.

[0139] The communication interface 620 may include a device that uses any transceiver to communicate with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Network (WLAN), etc.

[0140] The processor 610 executes the program stored in the memory 600 and calls other devices, and can be used to implement the various steps of any of the methods provided in the above embodiments of this application.

[0141] This application also proposes a chip that includes a processor and a data interface. The processor reads and runs a program stored in a memory through the data interface to execute the method described in any of the above embodiments. For details of the processing and its beneficial effects, please refer to the embodiments of the above methods.

[0142] Exemplary computer program products and storage media In addition to the methods and apparatus described above, embodiments of this application may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps of the methods according to various embodiments of this application as described in any of the foregoing embodiments of this specification.

[0143] Computer program products can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0144] Furthermore, embodiments of this application may also be storage media storing a computer program, which is executed by a processor through steps in the methods described in any of the above embodiments according to various embodiments of this application, specifically implementing the following steps: Step 110: The PC obtains the current time and historical heartbeat data from the PC. The historical heartbeat data represents the heartbeats sent by the PC to the device during historical time periods. The PC determines the abnormal situation based on the historical heartbeat data and the current time. The abnormal situation indicates whether an abnormal time has occurred on the PC. The PC corrects the current time based on the abnormal situation and the historical heartbeat data to obtain the corrected current time. The PC sends the heartbeat data containing the timestamp of the corrected current time to the device.

[0145] For the foregoing method embodiments, in order to simplify the description, they are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to this application, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0146] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For apparatus embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0147] The steps in the methods of the various embodiments of this application can be adjusted, merged, or deleted in order according to actual needs, and the technical features described in each embodiment can be replaced or combined.

[0148] The modules and sub-modules in the various embodiments of the present application's devices and terminals can be merged, divided, and deleted according to actual needs.

[0149] It should be understood that the disclosed terminals, devices, and methods can be implemented in other ways, given the several embodiments provided in this application. For example, the terminal embodiments described above are merely illustrative. For instance, the division of modules or sub-modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple sub-modules or modules may be combined or integrated into another module, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0150] The modules or submodules described as separate components may or may not be physically separate. The components that constitute a module or submodule may or may not be physical modules or submodules; that is, they may be located in one place or distributed across multiple network modules or submodules. Some or all of the modules or submodules can be selected to achieve the purpose of this embodiment's solution, depending on actual needs.

[0151] Furthermore, the functional modules or sub-modules in the various embodiments of this application can be integrated into one processing module, or each module or sub-module can exist physically separately, or two or more modules or sub-modules can be integrated into one module. The integrated modules or sub-modules described above can be implemented in hardware or in the form of software functional modules or sub-modules.

[0152] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0153] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software unit executed by a processor, or a combination of both. The software unit can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0154] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0155] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for correcting abnormal time in heartbeat packet data, characterized in that, The method is applied to a PC, and the method includes: Obtain the current time and historical heartbeat data of the PC; wherein, the historical heartbeat data represents the heartbeat packets sent from the PC to the device during historical time periods; Based on the historical heartbeat data and the current time, an abnormal situation is determined; wherein, the abnormal situation indicates whether an abnormal time has occurred on the PC. Based on the abnormal situation and the historical heartbeat data, the current time is corrected to obtain the corrected current time; Send the heartbeat packet data, which includes the corrected timestamp of the current time, to the device.

2. The method according to claim 1, characterized in that, The historical heartbeat data includes historical time; based on the historical heartbeat data and the current time, abnormal situations are determined, including: If the historical time in the historical heartbeat packet data is later than or equal to the current time, then the abnormal situation is determined to be a time tampering situation on the PC. If the historical time in the historical heartbeat packet data is earlier than the current time, then the abnormal situation is determined to be that there is no time tampering on the PC.

3. The method according to claim 1, characterized in that, Based on the aforementioned abnormal situation and the historical heartbeat data, the current time is corrected to obtain the corrected current time, including: If it is determined that the abnormal situation is due to time tampering on the PC, then the current time is corrected based on the historical heartbeat data to obtain the corrected current time; If it is determined that the abnormal situation is that there is no time tampering on the PC, then the current time is determined to be the corrected current time.

4. The method according to claim 3, characterized in that, The historical heartbeat data includes historical time; based on the historical heartbeat data, the current time is corrected to obtain the corrected current time, including: The current time is corrected based on the historical time and the preset interval to obtain the corrected current time; wherein, the preset interval represents the preset interval between the PC and the device sending heartbeat data.

5. The method according to any one of claims 1-4, characterized in that, The heartbeat packet data includes: a timestamp, cumulative usage time, heartbeat count, and a verification code; wherein, the timestamp represents the corrected current time; the cumulative usage time represents the cumulative usage time of the device within the authorized validity period; the heartbeat count represents the number of times the PC sends heartbeat packet data to the device; and the verification code represents the encrypted digest generated by the communication between the PC and the device.

6. A method for correcting abnormal time in heartbeat packet data, characterized in that, The method is applied to the device side, and the method includes: Receive heartbeat data sent by the PC; the heartbeat data is generated by the PC after correcting the current time based on the current time and historical heartbeat data when an abnormal situation is determined. The heartbeat packet data is parsed to obtain parsed heartbeat packet data; The operating status of the device is determined based on the parsed heartbeat packet data.

7. The method according to claim 6, characterized in that, The parsed heartbeat data packet includes a timestamp; based on the parsed heartbeat data packet, the operating status of the device is determined, including: If the timestamp is within the preset authorized time period, then the operating status of the device is determined to be authorized. If the timestamp is not within the preset authorized time period, the device's operating status is determined to be unauthorized.

8. The method according to claim 6 or 7, characterized in that, The parsed heartbeat data packet includes a checksum; based on the parsed heartbeat data packet, the operating status of the device is determined, including: The heartbeat packet data is verified based on the verification code to obtain the verification result; If the verification result indicates that the verification failed, then the operating state of the device is determined to be locked. If the verification result indicates that the verification was successful, then the operating status of the device is determined to be normal.

9. A device for correcting abnormal time in heartbeat packet data, characterized in that, The device is used on a PC, and the device includes: The acquisition module is used to acquire the current time and historical heartbeat data of the PC; wherein, the historical heartbeat data represents the heartbeat packets sent from the PC to the device during historical time periods; The determination module is used to determine abnormal situations based on the historical heartbeat packet data and the current time; wherein, the abnormal situation indicates whether an abnormal time has occurred on the PC. The correction module is used to correct the current time based on the abnormal situation and the historical heartbeat packet data to obtain the corrected current time; The sending module is used to send heartbeat packet data containing a corrected timestamp of the current time to the device.

10. A device for correcting abnormal time in heartbeat packet data, characterized in that, The device is applied to the equipment end, and the device includes: The receiving module is used to receive heartbeat packet data sent by the PC. The heartbeat packet data is generated by the PC after correcting the current time based on the current time and historical heartbeat packet data when it determines an abnormal situation. Parsing processing is used to parse the heartbeat packet data to obtain parsed heartbeat packet data; The determination module is used to determine the operating status of the device based on the parsed heartbeat packet data.

11. An electronic device, characterized in that, include: Memory and processor; The memory is connected to the processor and is used to store programs; The processor is configured to implement the method as described in any one of claims 1-8 by running a program in the memory.

12. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the method as described in any one of claims 1-8.

13. A computer program product, characterized in that, It includes computer program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1-8.

Images