Data recovery method and device of IOS equipment and storage medium

By obtaining and comparing the snapshot data list of IOS devices, determining the data to be restored and recovering, the problem of deleted data on IOS devices cannot be restored, and efficient and flexible data recovery is achieved.

CN120029821APending Publication Date: 2025-05-23深圳市乐数科技有限责任公司
View PDF 0 Cites 2 Cited by

Patent Information

Application Number
CN202510047185.X
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-01-13
Publication Date
2025-05-23

AI Technical Summary

Technical Problem

The prior art cannot effectively recover deleted data on IOS devices, especially due to hardware-level encryption and iOS system limitations, traditional data recovery technology is difficult to apply to IOS devices.

Method used

By obtaining the snapshot data list of the target device, sorting according to the snapshot time, determining the base snapshot data list and the snapshot data list to be compared, comparing the difference between the two to determine the data to be recovered, and data recovery is performed.

Benefits of technology

It realizes effective recovery of deleted data from IOS devices, avoids the problem that the SQLite engine cannot recover data, and does not need to directly contact Apple devices, improving the flexibility and efficiency of data recovery.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120029821A_ABST
    Figure CN120029821A_ABST
Patent Text Reader

Abstract

The invention relates to a data recovery method for an IOS device, and the method comprises the steps: obtaining a snapshot data list of a target device in response to a designated target device operation of a user; sorting according to the snapshot time corresponding to each snapshot data list, taking the snapshot data list corresponding to the last snapshot time as a reference snapshot data list, and taking other snapshot data lists as snapshot data lists to be compared; in response to a data recovery operation of a user, comparing the difference between the reference snapshot data list and the to-be-compared snapshot data list, and determining to-be-recovered data; and performing data recovery according to the to-be-recovered data. According to the scheme, the deleted data of the IOS equipment can be effectively recovered through comparison among the plurality of snapshot data lists.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of data recovery technology, and in particular to a data recovery method, device and storage medium for an IOS device. Background Art

[0002] Recovering deleted data on IOS devices has always been a difficult problem in the field of data recovery. This is because the storage media in IOS devices uses hardware-level encryption, and the plaintext data stored in the device cannot be directly accessed from outside the IOS system. Therefore, recovery technology based on storage device raw data or file system structured analysis is no longer applicable to Apple devices.

[0003] There are two methods in the prior art. One is a recovery technology based on iTunes backup files, which uses the principle that the SQLite engine does not completely erase the recorded content when executing the data deletion instruction to retrieve the deleted data. However, the new version of the SQLite engine will execute a database shrink instruction to improve performance when executing the deletion operation. This instruction will clear the deleted data in the database, making the deleted data unrecoverable. Therefore, the new version of the SQLite engine can no longer effectively recover the deleted data.

[0004] The other is a recovery technology based on iCloud backup files. Apple only officially provides one data recovery service, which is when a user sets up a new device, they select the required backup files from the iCloud server and restore them to the new device. Apart from this, it is not possible to select backup files from the iCloud server at any time to restore deleted data. At the same time, the recovery technology based on iCloud backup files also has the problem that the new version of the SQLite engine clears the deleted data, making the deleted data unrecoverable.

[0005] Therefore, there are still many deficiencies in the prior art, and the deleted data on the IOS device cannot be effectively recovered. Summary of the invention

[0006] The present application provides a data recovery method, device and storage medium for an IOS device to solve the problem in the prior art that deleted data on an IOS device cannot be effectively recovered.

[0007] In a first aspect, the present application provides a data recovery method for an IOS device, comprising:

[0008] In response to a user's operation of specifying a target device, obtaining a snapshot data list of the target device;

[0009] Sort the snapshot data lists according to the snapshot times corresponding to them, use the snapshot data list corresponding to the last snapshot time as the benchmark snapshot data list, and the other snapshot data lists as snapshot data lists to be compared;

[0010] In response to the data recovery operation of the user, comparing the difference between the baseline snapshot data list and the to-be-compared snapshot data list to determine the data to be recovered;

[0011] Data recovery is performed according to the data to be recovered.

[0012] Optionally, the baseline snapshot data list includes a plurality of baseline backup file lists, the snapshot data list to be compared includes a plurality of backup file lists to be compared, the backup file list to be compared includes a plurality of backup files to be compared, and in response to the data recovery operation of the user, comparing the difference between the baseline snapshot data list and the snapshot data list to be compared to determine the data to be recovered, comprises:

[0013] Comparing the backup file list to be compared with the reference backup file list in sequence to determine whether the backup file to be compared exists in the reference backup file list;

[0014] If not, marking the backup file to be compared as the data to be restored;

[0015] If so, it is determined whether the backup file to be compared is a database file.

[0016] Optionally, after the step of determining whether the backup file to be compared is a database file, the step further includes:

[0017] If not, the backup file to be compared is not the data to be restored;

[0018] If so, it is queried whether the data record content in the database file is the same as the data record content in the reference backup file.

[0019] Optionally, after the step of querying whether the data record content in the database file is the same as the data record content in the reference backup file, the step further includes:

[0020] If not, marking the difference data record content between the data record content in the database file and the data record content in the reference backup file as the data to be restored;

[0021] If so, the backup file to be compared is not the data to be restored.

[0022] Optionally, in response to the user's operation on the designated target device, obtaining the snapshot data list of the target device involves data interaction with an iCloud server, including:

[0023] In response to the user's authorization instruction, obtaining the user's IOS account and the password of the IOS account;

[0024] Perform authentication based on the SRP-6a protocol and obtain a token returned from the iCloud server;

[0025] Send a request to the server based on the IOS account, the token and the client information, and obtain metadata returned from the server, wherein the metadata is a parameter used by the client and the server to make data requests, wherein the client is an operation terminal of the user, and the client information includes device information and session information;

[0026] Sending a request to the server based on the metadata and the client information to obtain an escrow key;

[0027] In response to the user's designated target device operation, a request is sent to the server based on the metadata, the client information, and the device list bound to the IOS account to obtain a snapshot data list of the target device and a snapshot time and snapshot identifier corresponding to the snapshot data list, wherein the snapshot identifier is used to identify each snapshot backup operation, and the snapshot time is the time when each snapshot backup operation is executed;

[0028] Sending a request to the server based on the metadata, the client information and the snapshot identifier to download an encrypted backup file in a snapshot data list corresponding to the snapshot identifier, wherein the snapshot data list includes multiple backup files and backup file identifiers corresponding to the backup files;

[0029] The encrypted backup file is decrypted based on the escrow key to obtain the backup file in the snapshot data list.

[0030] Optionally, in response to the user's operation of specifying a target device, sending a request to the server based on the metadata, the client information, and a list of devices bound to the IOS account to obtain a snapshot data list of the target device and a snapshot time and a snapshot identifier corresponding to the snapshot data list, including:

[0031] Send a request to the server based on the metadata and the client information, and obtain a device identifier returned from the server, where the device identifier is used to mark an iOS device that has been logged in by the iOS account;

[0032] According to all the device identifiers, obtain a list of devices bound to the IOS account;

[0033] In response to the user's operation of specifying a target device, a request is sent to the server based on the metadata and the client information to traverse the device list, and a snapshot data list of the target device and a snapshot time and snapshot identifier corresponding to the snapshot data list returned from the server are obtained.

[0034] Optionally, sending a request to the server based on the metadata, the client information and the snapshot identifier to download an encrypted backup file in a snapshot data list corresponding to the snapshot identifier includes:

[0035] Sending a request to the server based on the metadata, the client information and the snapshot identifier to traverse the corresponding snapshot data list, and obtaining the backup file list identifier returned from the server;

[0036] Sending a request to the server to traverse the corresponding backup file list based on the metadata, the client information and the backup file list identifier, and obtaining the backup file identifier returned from the server;

[0037] Sending a request to the server based on the backup file identifier to obtain the file attribute and download link corresponding to the backup file identifier returned from the server;

[0038] The encrypted backup file is downloaded accordingly according to the download link and file attributes.

[0039] In a second aspect, the present application provides a data recovery device for an IOS device, the device comprising:

[0040] A backup data acquisition module, used for acquiring a snapshot data list of a target device in response to a user's operation of specifying the target device;

[0041] A snapshot data traversal module, used for sorting the snapshot data lists according to the snapshot times corresponding to the snapshot data lists, taking the snapshot data list corresponding to the last snapshot time as the benchmark snapshot data list, and the other snapshot data lists as the snapshot data lists to be compared;

[0042] a to-be-restored data determination module, configured to, in response to the user's data recovery operation, compare the difference between the baseline snapshot data list and the to-be-compared snapshot data list to determine the to-be-restored data;

[0043] A data recovery module is used to recover the data according to the data to be recovered.

[0044] In a third aspect, the present application provides a data recovery system for an IOS device, including: a client and a server, wherein the client sends instructions to the server to execute the data recovery method described in the present application.

[0045] In a fourth aspect, the present application further provides a computer storage medium storing computer executable instructions, wherein the computer executable instructions are used to execute the data recovery method described in the present application.

[0046] The present application obtains multiple snapshot data lists of the target device, determines a baseline snapshot data list and a snapshot data list to be compared according to the snapshot time, wherein the baseline snapshot data list includes multiple baseline backup file lists, the snapshot data list to be compared includes multiple backup file lists to be compared, and the backup file list to be compared includes multiple backup files to be compared. Compared with the disadvantages of the SQLite engine in the prior art that it cannot effectively retrieve deleted data and the problem that the data recovery solution based on iTunes backup has only a single snapshot. This solution compares multiple snapshot data lists to determine whether the backup file to be compared exists in the baseline backup file list, thereby determining the data to be recovered, and can effectively realize the recovery of deleted data of IOS devices. Furthermore, this solution only downloads the backup file data of the device specified by the user, which is conducive to saving the storage space downloaded to the local area, improving the efficiency of traversing files, and thus improving the efficiency of recovering data. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0048] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0049] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0050] Figure 1 A schematic diagram of a data recovery method for an IOS device provided in an embodiment of the present application;

[0051] Figure 2 Provided in the embodiments of this application Figure 1 Schematic diagram of the specific process of S100;

[0052] Figure 3 Schematic diagram of the specific process of S105 provided by the embodiment of the present application Figure 2 in

[0053] Figure 4 Schematic diagram of the specific process of S106 provided by the embodiment of the present application Figure 2 in

[0054] Figure 5 Schematic diagram showing the mapping relationship between snapshot identifiers and backup data provided by the embodiment of the present application

[0055] Figure 6 Schematic diagram of the specific process of S300 provided by the embodiment of the present application Figure 1 in

[0056] Figure 7 Schematic diagram of the specific process of the comparison reference snapshot data list and the snapshot data list to be compared provided by the embodiment of the present application

[0057] Figure 8 Schematic diagram of the structure of a data recovery device for an IOS device provided by the embodiment of the present application

[0058] Fig. 9 Schematic diagram of the structure of a data recovery system for an IOS device provided by the embodiment of the present application Detailed implementation manners

[0059] To make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Apparently, the described embodiments are only a part rather than all of the embodiments of the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts shall fall within the scope of protection of the present application.

[0060] The following disclosure provides many different embodiments or examples for implementing different structures of the present invention. To simplify the disclosure of the present invention, components and settings of specific examples are described below. Of course, they are only examples and are not intended to limit the present invention. In addition, the present invention may repeat reference numerals and / or letters in different examples. Such repetition is for the purpose of simplification and clarity and does not in itself indicate the relationship between the various embodiments and / or settings discussed.

[0061] Deleted data recovery on iOS devices has always been a difficult problem in the field of data recovery. Traditional recovery technology based on raw data of storage devices or structural analysis of file systems is no longer applicable to iOS devices because their storage media uses hardware-level encryption and the plaintext data stored in the device cannot be directly accessed from outside the iOS system. Therefore, conventional data recovery technology is difficult to work on Apple devices. At present, there are two main technical approaches to recover deleted data in the industry, namely, recovery technology based on iTunes backup files and recovery technology based on iCloud backup files.

[0062] The principle of the recovery technology based on iTunes backup files is to connect the Apple device to iTunes, back up the device data, and after obtaining the backup file, use the principle that the SQLite engine does not completely erase the recorded content when executing the data deletion instruction to retrieve the deleted data. This solution has the following obvious disadvantages: (1) Device dependence: The recovery process requires direct contact with the Apple device and installation of the iTunes software environment, otherwise the backup file cannot be obtained, which makes the solution less flexible and more limited in actual application scenarios. (2) The new version of the SQLite engine will execute a database shrink command to improve performance when performing a deletion operation. This command will clear the deleted data in the database. Therefore, the new version of the SQLite engine can no longer effectively recover deleted data.

[0063] The principle of the recovery technology based on iCloud backup files is basically the same as the data recovery solution based on iTunes backup files. The main difference is that the data source of this solution comes from iCloud backup. The obvious disadvantages of this solution are: (1) Apple only provides one data recovery service, which is to select the required backup file from the iCloud server to restore to the new device when the user sets up a new device. Apart from this, it is not possible to select backup files from the iCloud server at any time to restore deleted data. (2) Apple does not directly provide any public interface to access and obtain iCloud backup data. How to authorize and download iCloud backup data through iCloud is an open technical problem in the industry. (3) Even after obtaining the iCloud backup, there is a general problem that the SQLite engine will delete the deleted data and cannot effectively restore the deleted data.

[0064] To sum up, the market needs a new technology or method that can overcome the pain points and difficulties of the above solutions, be closer to and more applicable to mainstream user scenarios, and achieve better data recovery results for Apple devices.

[0065] In order to solve the problems in the prior art, the present application provides a data recovery method for an IOS device. The present application downloads a snapshot data list of a specified target device in response to a user operation, determines a baseline snapshot data list according to the snapshot time, and then compares the baseline snapshot data list with the snapshot data list to be compared to determine the backup file data to be restored, thereby realizing the recovery of deleted data of the IOS device.

[0066] Figure 1 A data recovery method for an IOS device provided in an embodiment of the present application includes:

[0067] S100, in response to a user's operation of specifying a target device, obtaining a snapshot data list of the target device.

[0068] In the embodiment of the present application, the client is the user's operating terminal. The client only needs to be loaded with a data recovery program, which can execute the data recovery method of this scheme. The user clicks or touches a button on the client, and the client sends an instruction to the iCloud server to restore the deleted data to the user's operating terminal, that is, on which operating terminal (client) to operate to send a request to the iCloud server to restore the data, and finally the deleted data is restored locally on the operating terminal (client). The client can be an IOS device such as iPhone, iPad, Mac, etc., or a non-IOS device such as a Windows computer or other non-IOS system terminal device. The client information includes device information and session information. The device information refers to the hardware device information that must be specified when the client initiates a request to the iCloud server. The hardware device information can be the terminal device where the client is located. The session information refers to the field specified by the IOS system that is used whenever the client initiates a request to the iCloud server.

[0069] In the embodiment of the present application, the target device is for the IOS device. When the user uses the IOS device, the data in the IOS device is bound according to the user's IOS account, and the IOS account of the same user is logged in on different IOS devices. In the prior art, when selecting data recovery, all backups under the IOS account will be downloaded and restored. However, in the embodiment of the present application, the user can specify the target device to be restored. For example, when the user's IOS account has logged in to the iPhone and iPad, the server cloud will back up all the file data under the IOS account, that is, all the file data existing in the iPhone and iPad will be backed up. When the user issues a data recovery instruction on the client, if only the deleted data of any mobile terminal in the iPhone or iPad is to be restored, and not all the deleted data on the iPhone and iPad, the target device can be specified as the iPhone or iPad by specifying the operation of the target device. There is no need to download all the files backed up under the IOS account, which is conducive to saving local storage space and providing users with more flexible choices. This solution only downloads the backup file data of the device specified by the user, which is conducive to saving the storage space downloaded to the local, improving the efficiency of traversing files, and thus improving the efficiency of recovering data.

[0070] It should be noted that in the embodiment of the present application, the client can be the target device or not. When the client is the target device, the client of the user's terminal and the target device to be restored are the same device. For example, the user's IOS account has logged in to iPhone and iPad. When the user operates and issues a data recovery instruction on the iPhone, the iPhone is loaded with the client program for data recovery of this solution. The user specifies to restore the data on the iPhone, that is, the target device is selected as iPhone. At this time, the client device and the target device are the same device, and the deleted data is finally downloaded and restored to the local iPhone. When the client is not the target device, for example, the user operates and issues a data recovery instruction on iPad (or non-IOS device such as Windows), the iPad (or non-IOS device such as Windows) is loaded with the client program for data recovery of this solution, the user specifies to restore the data on the iPhone, that is, the target device is selected as iPhone. At this time, the client operated by the user and the target client are two different devices, and the deleted data is finally downloaded and restored to the client iPad (or non-IOS device such as Windows) locally, not the target device iPhone. In this application, the final data recovery is only downloaded on the client that carries the data recovery program implemented by this solution.

[0071] This solution avoids the drawback that the current SQLite engine cannot effectively retrieve deleted data by comparing the snapshot data list. And based on iCloud snapshot backup, there is no device dependency, and the recovery process does not require direct access to Apple devices and installation of the iTunes software environment. And as long as the client program is loaded on the client, the above method can be implemented, and the deleted data can be restored at any time, solving the problem that Apple only provides a data recovery service when the user uses a new device and cannot be restored at any time.

[0072] In the embodiment of the present application, each snapshot is equivalent to a backup of the data under the IOS account. The backed-up data is called snapshot data. Snapshot data refers to the backup data obtained by static copying the data in the IOS account at a specific time point, wherein the specific time point is called the snapshot time. The snapshot data records the data status at the snapshot time point to ensure the consistency of the data at the snapshot time point. Once generated, the snapshot data cannot be modified, ensuring the accuracy and reliability of historical data, which is conducive to data analysis, historical data tracing, and recovery of deleted data.

[0073] Specifically, Figure 2 As shown, Figure 2 Provided for the embodiments of this application Figure 1 In the specific process diagram of S100, in response to the user's operation on the designated target device, the snapshot data list of the target device is obtained, and the process involves data interaction with the iCloud server, including:

[0074] S101, in response to an authorization instruction from a user, obtaining the IOS account of the user and the password of the IOS account.

[0075] In an embodiment of the present application, the data in the IOS device is bound according to the user's IOS account, and the same user's IOS account is logged in on different IOS devices. Therefore, to recover deleted data, it is first necessary to obtain the user's IOS account and its password. In the IOS system, the IOS account used by the user is an Apple account, and the name corresponding to the Apple account is Apple ID.

[0076] S102, performing identity authentication based on the SRP-6a protocol and obtaining a token returned from the iCloud server.

[0077] In the embodiment of the present application, the client and the server must first perform identity authentication based on the SRP-6a protocol when interacting. The identity authentication process includes:

[0078] (1) Client srp initialization: Generate a random large number x = SHA256 (salt_c + SHA256 (AppleID + ": " + P)), where salt_c is a randomly generated salt value. Generate a public key A = g^a%N, where g is a public generator, which is always 2 in the iCloud cloud backup protocol, N is a large prime number, and a is a random number. Initiate a request through the https: / / gsa.apple.com / grandslam / GsServi ce2 interface. The client sends A, Apple ID, device information, and session-related information to the server, and the server returns B and salt_s.

[0079] The above process can be simplified as follows: the client initiates an SRP initialization request to the server through the https: / / gsa.apple.com / grandslam / GsService2 interface. The client sends the IOS account, device information, and session-related information to the server. The server returns SRP parameters according to the SRP protocol specification.

[0080] (2) Client identity authentication: Calculate parameter u = SHA256 (A + B); Calculate parameter x = SHA256 (salt_s + SHA256 (AppleID + ": " + P)); Calculate shared key S_c = (Bg^x)^(a+u*x)%N; Generate session key K_c = SHA256 (S_c); Calculate verification message M_c = H (H(N) XOR H(g) + H(AppleID) + salt_s + A + B + K_c), and send it to the server through the https: / / gsa.apple.com / grandslam / GsService2 interface. Extract srp parameters M2, np, spd, etc. from the response packet returned by the server. Among them, M2 is the verification value provided by the server. If the client verification matches, the identity authentication is successful. After the verification is successful, extract the value of "com.apple.gs.idms.pet" from the spd data and record it as the token petToken. This token can replace the password and be used for subsequent further requests.

[0081] The above process can be simplified as follows: the client calculates the parameters for further SRP authentication according to the SRP protocol specifications and sends them to the server through the https: / / gsa.apple.com / grandslam / GsServ ice2 interface to complete the authentication. After the authentication is passed, the server returns com.apple.gs.idms.pet. This value is the token related to data encryption in the iCloud data management service mechanism, recorded as token petToken.

[0082] S103, sending a request to the server based on the IOS account, the token and the client information, and obtaining metadata returned from the server, wherein the metadata is a parameter used by the client and the server to make data requests, wherein the client is the user's operating terminal, and the client information includes device information and session information.

[0083] In an embodiment of the present application, based on AppleID, petToken, device information and session information, a POST request is initiated to the https: / / setup.icloud.com / setup / authenticate / $APPLE_ID$ interface, and dsPrsID and mmeAuthToken are extracted from the server's response data packet. These two metadata are important parameters required when the client and the server interact and send requests later.

[0084] S104: Send a request to the server based on the metadata and the client information to obtain a escrow key.

[0085] In the embodiment of the present application, since the files backed up on the iCloud server are all in encrypted form, if you want to obtain the backup data of the target device, you also need to obtain the escrow key for decrypting the encrypted backup files. Before obtaining the escrow key, you also need to perform the pre-step (1) and pre-step (2) to enable the client to obtain the data decryption capability of the IOS encryption and decryption system, specifically including:

[0086] (1) Based on dsPrsID, mmeAuthToken, device information and session information, a POST request is initiated to the http: / / setup.icloud.com / setup / ck / v1 / ckAppInit?container=com.apple.backup.ios interface, and the user identifier cloudKitUserId is extracted from the response package returned by the server. Among them, cloudKitUserId is the unique identifier of each user account in the iCloud system, which will be used to specify a specific user account when the iCloud protocol requests user data in the future.

[0087] (2) Based on dsPrsID, mmeAuthToken, device information and session information, a POST request is initiated to the https: / / setup.icloud.com / setup / get_account_settings interface, and escrowProxyUrl, icloud_gateway_url and cloud KitToken are extracted from the server response package. escrowProxyUrl is the address of the escrow proxy service. The escrow proxy is used to manage the numerous keys in the iCloud service and provide these keys to authenticated clients, which can then obtain the ability to decrypt iCloud data. icloud_gateway_url is the address of the data service provided by icloud. cloudKitToken is used to authorize access to user data with the identity of cloudKitUserId.

[0088] After the client obtains the decryption capability of iCloud data through the above-mentioned pre-steps (1) and (2), the acquisition of the escrow key in the embodiment of the present application includes three steps. The first step is to obtain the encrypted escrow key, the second step is to obtain the decryption key used to decrypt the encrypted escrow key, and the third step is to decrypt the encrypted escrow key using the decryption key to obtain the escrow key.

[0089] The specific steps of the first step to obtain the encrypted escrow key include: based on dsPrsID, mmeAu thToken, device information and session information, initiate a POST request to the {escrowProxyUrl} / escrowproxy / api / get_records interface, and extract the value of the encrypted escrow key kPCSMetadataEscrowedKeys from the server's response package. In Apple's security system, the escrow key (key escorwed) is a mechanism for managing encryption keys. And kPCSMetadataEscrowedKeys is the private key metadata for encryption operations stored in iCloud, which is used to decrypt the encryption key of other files and data.

[0090] After the first step and before the second step, the embodiment of the present application also includes identity authentication. The specific process includes: based on dsPrsID, mmeAuthToken, device information and session information, a POST request is initiated to the {escrowProxyUrl} / escrowproxy / api / srp_init interface to initialize the srp identity verification with the managed key service.

[0091] The second step is to obtain the decryption key used to decrypt the encrypted escrow key. The specific steps include: based on dsPrsID, mmeAuthToken, device information and session information, initiate a POST request to the {escr owProxyUrl} / escrowproxy / api / recover interface, and extract the value of the decryption key BackupBagPassword from the server's return package. BackupBagPassword stores the key used to decrypt kPCSMetadataEscrowedKeys.

[0092] The third step is to decrypt the encrypted escrow key through the decryption key to obtain the escrow key. The specific steps include: decrypting the keys stored in the encrypted escrow key kPCSMetadataEscrowedKeys according to the decryption key BackupBagPassword, and recording the final decryption result as decryptedEscrowedKeys, that is, the decrypted escrow key. These keys are needed in the subsequent decryption of file data.

[0093] S105, in response to the user's designated target device operation, sends a request to the server based on the metadata, the client information and the device list bound to the IOS account, obtains the snapshot data list of the target device and the snapshot time and snapshot identifier corresponding to the snapshot data list, the snapshot identifier is used to identify each snapshot backup operation, and the snapshot time is the time when each snapshot backup operation is executed.

[0094] In the embodiment of the present application, before obtaining the snapshot data of the target device, it is necessary to obtain an account list for the user to select the corresponding target device. Specifically, Figure 3 As shown, Figure 3 Provided for the embodiments of this application Figure 2 The specific process diagram of S105 in the embodiment of the present invention is as follows: in response to the user's operation of specifying a target device, based on the metadata, the client information and the device list bound to the iOS account, a request is sent to the server to obtain a snapshot data list of the target device and a snapshot time and snapshot identifier corresponding to the snapshot data list, including:

[0095] S1051, sending a request to the server based on the metadata and the client information, and obtaining a device identifier returned from the server, where the device identifier is used to mark the iOS device that has been logged in by the iOS account.

[0096] In an embodiment of the present application, based on dsPrsID, mmeAuthToken, device information and session information, recordID and zoneID are specified as the first fixed value "BackupAccount" and the second fixed value "mbksync", wherein recordID refers to a unique identifier used to represent a record, and zoneID is a unique identifier representing a certain area, that is, recordID = "BackupAcco unt", zoneID = "mbksync", and a request is initiated to the interface {icloud_gateway_url} / ckdatabase / api / client / record / retrieve to obtain the device information of the backup package, and save the device identifier deviceID to an array or list.

[0097] Among them, the device identifier is used to mark the IOS device that has been logged in by the IOS account. For example, for an iPhone and iPad that have been logged in by the same IOS account of a user, the iPhone has a corresponding iPhone device identifier, and the iPad has a corresponding iPad device identifier. The function of the device identifier is to characterize different IOS devices.

[0098] Code example: deviceList = ["D:a5bbe7712fc95fe5417d5caa77eb9bc5481dc973","D:e3e502fb6e75925194cd7f2391ab686300d60c11"]

[0099] S1052: Obtain a list of devices bound to the IOS account based on all the device identifiers.

[0100] In the embodiment of the present application, according to the device identification obtained in step S1051, the device identifications corresponding to the same IOS account of all users are saved in a list to obtain a list of devices bound to the IOS account.

[0101] S1053, in response to the user's operation of specifying a target device, sending a request to the server to traverse the device list based on the metadata and the client information, and obtaining a snapshot data list of the target device and a snapshot time and snapshot identifier corresponding to the snapshot data list returned from the server.

[0102] In an embodiment of the present application, based on dsPrsID, mmeAuthToken, device information and session information, in response to the user selecting a target device for which data needs to be restored, the client specifies recordedID as the device identifier and zoneID as the second fixed value, i.e., recordID=deviceID, zoneID="mbksync", and initiates a request to the interface {icloud_gateway_url} / ckdatabase / api / clie nt / record / retrieve to obtain the snapshot time and snapshot identifier of the key bag keybag in the snapshot data list of the target device specified by the user and the snapshot data list, and saves information such as the snapshot data list snapshotIDList composed of the snapshot identifier, the snapshot time, and the snapshot size.

[0103] Among them, the decryption key keys stored in the keybag is used to decrypt key data such as the file attributes of the backup file. DecryptedEscrowedKeys is needed to decrypt the keybag data to obtain the file attributes of the decrypted backup file. Among them, the snapshot time and snapshot identifier are both in plain text. The snapshot identifier is used to identify each snapshot backup operation. The snapshot time is the time when each snapshot backup operation is executed. For example, the iCloud server performs a snapshot backup of the data of the IOS account at 12:00 on December 10, 2024. The snapshot time is 2024.12.10.12:00, and the snapshot identifier is the snapshot ID of the snapshot, such as snapshot 1, snapshot 2, etc. The snapshot identifier can be customized according to actual needs and is not specifically limited here.

[0104] Code example: snapshotIDList = ["S:7F924FF7-F2BC-436B-8867-57D312A1FB39","S:4A9BA009-7BDE-4BF5-B0CB-75ECE0A527FD"]

[0105] S106, sending a request to the server based on the metadata, the client information and the snapshot identifier to download the encrypted backup file in the snapshot data list corresponding to the snapshot identifier, wherein the snapshot data list includes multiple backup files and backup file identifiers corresponding to the backup files.

[0106] Specifically, Figure 4 Provided in the embodiments of this application Figure 2 The specific process diagram of S106 in FIG. 104 , wherein the step of sending a request to the server based on the metadata, the client information and the snapshot identifier to download the encrypted backup file in the snapshot data list corresponding to the snapshot identifier includes:

[0107] S1061: Send a request to the server to traverse the corresponding snapshot data list based on the metadata, the client information and the snapshot identifier, and obtain a backup file list identifier returned from the server.

[0108] In an embodiment of the present application, based on dsPrsID, mmeAuthToken, device information and session information, recordID is specified as the snapshot identifier, zoneID is specified as the second fixed value, that is, recordedID=snapshotID, zoneID="mbksync", and a request is initiated to the interface {icloud_gateway_url} / ckd atabase / api / client / record / retrieve to obtain the backup file list identifier manifestIDs of the snapshot.

[0109] S1062: Send a request to the server to traverse the corresponding backup file list based on the metadata, the client information and the backup file list identifier, and obtain the backup file identifier returned from the server.

[0110] In an embodiment of the present application, based on dsPrsID, mmeAuthToken, device information and session information, recordID is specified as the backup file list identifier, zoneID is the second fixed value, and a request is initiated to the interface {icloud_gateway_url} / ckdatabase / api / client / record / retrieve to obtain the corresponding backup file identifier fileID in the backup file list.

[0111] S1063: Send a request to the server based on the backup file identifier, and obtain the file attributes and download link corresponding to the backup file identifier returned from the server.

[0112] In an embodiment of the present application, based on dsPrsID, mmeAuthToken, device information and session information, recordID is specified as the backup file identifier, zoneID is specified as the second fixed value, and a request is initiated to the interface {icloud_gateway_url} / ckdatabase / api / client / record / retrieve to obtain the backup file attribute data and the backup file download link.

[0113] S1061-S1063 can be simplified to understand as follows: each snapshot data list includes multiple backup file lists and backup file list identifiers corresponding to the backup file lists, and each backup file list includes multiple backup files and backup file identifiers corresponding to the backup files. First, the client specifies the snapshot identifier to the server to request to traverse the snapshot data list, and the server returns the backup file list identifier in the snapshot data list to the client. Secondly, the client specifies the backup file list identifier to the server to request to traverse the backup file list, and the server returns the backup file identifier in the backup file list to the client. Finally, the client specifies the backup file identifier to the server to request to traverse the backup files, and the server returns the download link of the backup file and the attribute data of the backup file to the client.

[0114] S1064: Download the encrypted backup file accordingly according to the download link and the file attribute.

[0115] In the embodiment of the present application, the backup file identifier and the attribute data of the backup file obtained through the above S1061-1063 are used to obtain the download link of the backup file, that is, the path where the backup file is located is obtained for downloading to obtain the encrypted backup file.

[0116] This solution overcomes the technical difficulty of authorizing and downloading backup file data through iCloud when Apple does not directly provide any public interface access. At the same time, it only downloads the backup file data of the user-specified device, which is conducive to saving local storage space for downloading and improving the efficiency of traversing files, thereby improving the efficiency of recovering data.

[0117] S107: decrypt the encrypted backup file based on the escrow key to obtain the backup file in the snapshot data list.

[0118] In an embodiment of the present application, the client uses decryptedEscrowedKeys to decrypt the encrypted backup file and restore the encrypted backup file to a plaintext backup file.

[0119] It should be noted that the backup file list includes but is not limited to system applications (text messages, photo albums, etc.) and third-party application data (WeChat, WhatsApp, Facebook, messenger, etc.), and the backup file is equivalent to the specific data content in the application. In one possible implementation, the backup file list can be the photo album of the target device, and the backup file is each picture in the photo album. In another possible implementation, the backup file list can be WeChat, and WeChat is a third-party software provided to users for social interaction, and the data therein includes WeChat chat records, cache files, pictures and videos, etc. Therefore, the backup file list in the embodiment of the present application can also include a backup file sublist. When the backup file list is WeChat, the backup file sublist is WeChat chat records, cache files, pictures and videos, and each backup file sublist includes multiple backup files. For example, after the WeChat chat record backup file sublist is opened, it includes the chat records of the user with other different users or the chat records of the user in various groups.

[0120] In view of this, the backup file list in the embodiment of the present application is only a high-level concept, and the backup file list may include multiple backup file sub-lists. The specific backup file sub-lists are divided according to the backed up applications and are not specifically limited here.

[0121] like Figure 5 As shown, Figure 5 The mapping relationship between the snapshot identifier and the backup data provided in the embodiment of the present application is intended to be expressed. Based on the above relationship, there is a mapping relationship between the snapshot identifier and the snapshot data list, and the snapshot data list includes a backup file list, and the backup file list includes backup files. Therefore, for each snapshot, its snapshot identifier has a mapping relationship with the snapshot data list, the backup file list and the backup file, so a snapshot identifier and backup data mapping table can be constructed.

[0122] For example, the data of the target device is backed up twice, that is, there are two snapshot data lists of the target device, and the snapshot identifiers of the two snapshot data lists are snapshot 1 and snapshot 2, respectively. Snapshot 1 includes two backup file lists, and the names of the two backup file lists are backup file list chat and backup file list picture, respectively. The backup file list chat includes two backup files, namely backup file A and backup file B, and the backup file list picture includes two backup files, namely backup file C and backup file D.

[0123] Among them, snapshot 2 includes two backup file lists, the names of the two backup file lists are backup file list chat and backup file list picture, wherein the backup file list chat includes two backup files, namely backup file A and backup file E, and the backup file list picture includes two backup files, namely backup file C and backup file F.

[0124] Normally, the backup file list is a backup file list obtained after the application software or the system's built-in software is backed up. It can be understood that when the files in the same application software are backed up at different times, the backup files in the backup file list at each time are also different. For example, if WeChat is backed up at 2024.12.10.12:00, the backup file list named WeChat may include x backup files. If WeChat is backed up at 2024.12.10.15:00, the backup file list named WeChat may include y backup files, among which the contents of the backup files in x backup files and y backup files may or may not overlap. No specific restrictions are made here. Any snapshot in this application does not involve any scope restrictions with other snapshots, and all files of the target device are backed up at the current moment.

[0125] S200 , sorting the snapshot data lists according to the snapshot times corresponding to them, taking the snapshot data list corresponding to the last snapshot time as the reference snapshot data list, and the other snapshot data lists as snapshot data lists to be compared.

[0126] In an embodiment of the present application, based on the snapshot lists of the target device that have been acquired and the snapshot times corresponding to the snapshot lists, all snapshots are sorted in descending order of time. The last snapshot time is also the last backup, that is, the latest backup. The snapshot list corresponding to the last snapshot time is arranged in descending order and is used as the baseline snapshot data list, and the other snapshot data lists are used as snapshot data lists to be compared.

[0127] like Figure 6 As shown, Figure 6 A schematic diagram of a specific process of comparing a benchmark snapshot data list and a snapshot data list to be compared provided in an embodiment of the present application.

[0128] In the embodiments of the present application, Figure 6There are three snapshot data lists, and the corresponding times of the three snapshot data lists are 2024.12.10.9:00, 2024.12.10.8:00, and 2024.12.10.7:00 respectively. The snapshot times are arranged in descending order, and the snapshot data list corresponding to the last snapshot time 2024.12.10.9:00 is used as the baseline snapshot data list. The other snapshot data lists are all snapshot data lists to be compared. They are arranged in descending order. The snapshot data list corresponding to 2024.12.10.8:00 is used as snapshot data list 1 to be compared, and the snapshot data list corresponding to 2024.12.10.7:00 is used as snapshot data list 2 to be compared.

[0129] It should be noted that the time interval for snapshot backup is not limited in the embodiment of the present application. The embodiment only takes one hour as an example. In actual application, any time interval can be used as the time interval unit for snapshot backup.

[0130] This solution avoids the drawback that the current SQLite engine cannot effectively retrieve deleted data by comparing snapshot data lists. It determines the baseline snapshot data list and the snapshot data list to be compared through multiple snapshot data lists, thereby determining the deleted data that needs to be recovered, solving the problem that the existing data recovery solution based on iTunes backup has only a single snapshot.

[0131] S300 , in response to the data recovery operation of the user, comparing the difference between the baseline snapshot data list and the to-be-compared snapshot data list to determine the data to be recovered.

[0132] like Figure 6 As shown, Figure 6 Provided for the embodiments of this application Figure 1 The specific process diagram of S300 is as follows: specifically, the baseline snapshot data list includes multiple baseline backup file lists, the snapshot data list to be compared includes multiple backup file lists to be compared, the backup file list to be compared includes multiple backup files to be compared, and in response to the data recovery operation of the user, comparing the difference between the baseline snapshot data list and the snapshot data list to be compared to determine the data to be recovered, including:

[0133] The backup file list to be compared is compared with the reference backup file list in sequence to determine whether the backup file to be compared exists in the reference backup file list.

[0134] The core of the comparison in this scheme is to judge whether the backup files in the backup file list to be compared exist in the baseline backup file list by comparing the baseline backup file list and the backup file list to be compared. Since the backup file identifier is unique for each backup file, the basis for judgment is whether the backup file identifier in the backup file list to be compared exists in the baseline backup file list.

[0135] In an embodiment of the present application, if one wants to determine whether the backup file identifier of the backup file to be compared exists in the baseline backup file list, the steps specifically include: first, traversing each backup file list to be compared respectively and identifying the backup file identifier corresponding to the backup file to be compared in the backup file list to be compared; secondly, traversing the baseline backup file list and identifying the backup file identifier corresponding to the baseline backup file in the baseline backup file list, and determining whether the backup file identifier in the backup file list to be compared is consistent with the corresponding backup file identifier in the baseline backup file list.

[0136] If not, the backup file to be compared is marked as the data to be restored.

[0137] If otherwise, it indicates that the backup file identifier of the backup file to be compared does not exist in the reference backup file list, and the backup file to be compared is marked as the data to be restored.

[0138] If so, it is determined whether the backup file to be compared is a database file.

[0139] If so, it means that the backup file identifier of the backup file to be compared exists in the benchmark backup file list. However, if the backup file to be compared is a database file, it is possible that some data in the database has been deleted, while the database file itself has not been deleted. Therefore, it cannot be determined based on the backup file identifier alone, and it is necessary to continue to determine whether the backup file to be compared is a database file.

[0140] If not, it is determined that the backup file to be compared is not the data to be restored.

[0141] If otherwise, it indicates that the backup file identifier of the backup file to be compared exists in the reference backup file list, and it is determined that the backup file to be compared is not the data to be restored.

[0142] If so, it is queried whether the data record in the database file is the same as the data record in the reference backup file.

[0143] If the backup file to be compared is a database file, then the backup file to be compared is also a database file, and it is queried whether the data record content in the database file is the same as the data record content in the reference backup file.

[0144] If not, the difference data between the data record in the database file and the data record in the reference backup file is marked as the data to be restored.

[0145] If so, it is determined that the backup file to be compared is not the data to be restored.

[0146] In the embodiment of the present application, S300 will cooperate with Figure 7 Example of the embodiment Figure 1 Describe the comparison process. Figure 7 This is a schematic diagram of the specific process of comparing the benchmark snapshot data list and the snapshot data list to be compared provided in the embodiment of the present application. Figure 7 As shown, the baseline snapshot data list includes a baseline backup file list chat and a baseline backup file list picture, wherein the baseline backup file list chat includes backup file A and backup file B, and the baseline backup file list picture includes two backup files, whose backup file identifiers are backup file C and backup file D respectively. The previous snapshot data list 1 to be compared is traversed. The backup file list chat to be compared in the snapshot data list 1 to be compared includes backup file A, backup file E and backup file F. By comparison, backup file E and backup file F are not in the baseline backup file list, which means that backup file E and backup file F are deleted files. The backup file list picture to be compared in the snapshot data list 1 to be compared includes backup file D. By comparison, backup file D already exists in the baseline backup file list, which means that backup file D has not been deleted. Backup file C exists in the baseline backup file list but is not in the snapshot data list 1 to be compared, which means that backup file C is backup file data newly added after the backup at the snapshot time of 2024.12.10.8:00. Similarly, the backup file identifier in the snapshot data list 2 to be compared is compared to see whether it exists in the baseline backup file list. Finally, after comparing all snapshot data lists, the data to be restored is obtained, and the target device is restored, as shown in FIG. Figure 7 The arrows shown indicate the recovery results. This embodiment only lists three snapshot data lists, which are not limited to three in actual application scenarios and are not specifically limited here.

[0147] Through this solution, the baseline backup file list is used as a reference point to traverse all other backup file lists to be compared until all backup file lists to be compared are compared. Since the device starts the first snapshot backup when it is enabled, backup is performed at regular intervals, and the snapshot backup time interval is set to be sufficiently small, such as a certain preset threshold. The preset threshold is less than the time when the user executes the file deletion operation, which is equivalent to always having a snapshot to back up the file when the file exists. Therefore, no matter at what time, the deleted file data can always traverse the previous snapshot data list to find its backup to determine the file difference with the baseline backup file list, thereby restoring the deleted data, which is conducive to realizing effective recovery of the deleted data.

[0148] In an embodiment of the present application, the database file can be a SQL Server file. Each My SQL database is stored in a folder with the same name as the database. The four My SQL database files include a database file created by My SQL (server) and a database file created by the storage engine used by My SQL (server). In an embodiment of the present application, each photo is an independent backup file. For example, the chat data records in WeChat will be stored in the database file in the form of a file. At this time, it is necessary to further determine whether the specific content in the database file is deleted. Therefore, it is determined whether the data record content of the backup file to be compared is the same as the data record content of the benchmark backup file. Here, the backup file to be compared and the benchmark backup file are both database files.

[0149] In the embodiment of the present application, a common existence mode of a database file is, for example, chat records. There are twenty chat records between the target user corresponding to the target device and user A. The target user operates the target device to delete ten of the chat records with user A. Since all chat records between the target user and user A are stored and backed up in the form of a database file, although part of the data content in the database file is deleted, the entire database file still exists. Therefore, it is impossible to accurately determine whether the backup file to be compared is deleted by only identifying the backup file identifier of the backup file to be compared and whether it exists in the reference backup file list. If there are twenty chat records of user A in the database to be compared and ten chat records of user A in the reference database, it means that ten chat records with user A in the target device have been deleted. The contents of the backup file to be compared and the reference backup file are traversed respectively. At this time, the backup file to be compared and the reference backup file are both databases. Further determine which data record contents are deleted, and determine the difference data to restore the deleted data.

[0150] By further determining whether the backup file to be compared is a database file, it is avoided that deleted file data is judged as still existing file data, which reduces misjudgment, is conducive to more effective recovery of deleted data, and improves the accuracy of data recovery.

[0151] In short, in the embodiment of the present application, all snapshot data lists are analyzed in sequence by the above method. If the snapshot data record exists in the sqlite of the old snapshot but not in the sqlite of the benchmark snapshot, the data is marked as deleted data. After completing the traversal of all snapshots of the above-mentioned device in sequence, a complete set of existing data and a set of deleted data are obtained, and data recovery is performed on the target device based on the deleted data set.

[0152] S400: Perform data recovery according to the data to be recovered.

[0153] In an embodiment of the present application, the data to be recovered is determined by step S300, and in response to the user's data recovery operation, the deleted data on the target device is restored to the client device, wherein the client device may be the same device as the target device, or the client device may be a different device from the target device, and the reasons have been explained above and will not be repeated here.

[0154] This application downloads the snapshot data list of the specified target device in response to user operations, determines the baseline snapshot data list according to the snapshot time, and then compares the baseline snapshot data list with the snapshot data list to be compared to determine the backup file data to be restored, thereby restoring the deleted data of the IOS device. On the one hand, this solution avoids the disadvantage that the current sqlite engine cannot effectively retrieve deleted data by comparing the snapshot data list. On the other hand, this solution is based on iCloud snapshot backup without device dependence, and does not require direct contact with Apple devices and installation of the iTunes software environment during the recovery process. On the third hand, this solution determines the baseline snapshot data list and the snapshot data list to be compared through multiple snapshot data lists, thereby determining the deleted data that needs to be restored, solving the problem that the data recovery solution based on iTunes backup in the prior art has only a single snapshot. On the fourth hand, in this solution, as long as the client program is loaded on the client, the above method can be implemented, and the deleted data can be restored at any time, solving the problem that Apple only provides a data recovery service when the user uses a new device and cannot be restored at any time. Fifthly, this solution overcomes the technical difficulty of authorizing and downloading backup file data through iCloud when Apple does not directly provide any public interface access, and solves the problem that Apple's official black box process based on iCloud data recovery cannot be intervened. Sixthly, this solution only downloads the backup file data of the user-specified device, which is conducive to saving the storage space downloaded to the local area, improving the efficiency of traversing files, and thus improving the efficiency of recovering data.

[0155] like Figure 8 As shown, Figure 8 A schematic diagram of a data recovery device for an IOS device provided in an embodiment of the present application, wherein the data recovery device comprises:

[0156] The backup data acquisition module 510 is used to acquire a snapshot data list of a target device in response to a user's operation of specifying the target device;

[0157] The snapshot data traversal module 520 is used to sort the snapshot data lists according to the snapshot time corresponding to each of the snapshot data lists, and use the snapshot data list corresponding to the last snapshot time as the reference snapshot data list, and the other snapshot data lists as the snapshot data lists to be compared;

[0158] The to-be-restored data determining module 530 is configured to, in response to the user's data recovery operation, compare the difference between the baseline snapshot data list and the to-be-compared snapshot data list to determine the to-be-restored data;

[0159] The data recovery module 540 is used to recover the data according to the data to be recovered.

[0160] Fig. 9 Schematic diagram of the structure of the data recovery system of the IOS device provided in the embodiment of the present application. Fig. 9 As shown, the data recovery system 700 of this embodiment includes: a server 710 ( Fig. 9 Only one is shown), a client 720 and a data recovery program 721 stored in the client 720 and executable on at least one of the clients 720, the client 720 executes the data recovery program 721 to send a request to the server 710, and the server 710 feeds back a result to implement the steps in the above method embodiment.

[0161] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0162] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0163] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0164] In the embodiments provided in the present application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0165] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0166] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0167] The present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed through a computer program product. When the computer program product runs on a terminal device, the terminal device can implement the steps in the above-mentioned method embodiments when executing.

[0168] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application is described in detail with reference to the above-mentioned embodiments, a person skilled in the art should understand that the technical solutions described in the above-mentioned embodiments can still be modified, or some of the technical features can be replaced by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A data recovery method for an IOS device, characterized in that: include: In response to a user's operation of specifying a target device, obtaining a snapshot data list of the target device; Sort the snapshot data lists according to the snapshot times corresponding to them, use the snapshot data list corresponding to the last snapshot time as the benchmark snapshot data list, and the other snapshot data lists as snapshot data lists to be compared; In response to the data recovery operation of the user, comparing the difference between the baseline snapshot data list and the to-be-compared snapshot data list to determine the data to be recovered; Data recovery is performed according to the data to be recovered.

2. The method according to claim 1, characterized in that: The baseline snapshot data list includes a baseline backup file list, the baseline backup file list includes a baseline backup file, the snapshot data list to be compared includes a backup file list to be compared, the backup file list to be compared includes backup files to be compared, and in response to the data recovery operation of the user, comparing the difference between the baseline snapshot data list and the snapshot data list to be compared to determine the data to be recovered, including: Comparing the backup file list to be compared with the reference backup file list in sequence to determine whether the backup file to be compared exists in the reference backup file list; If not, marking the backup file to be compared as the data to be restored; If so, it is determined whether the backup file to be compared is a database file.

3. The method according to claim 2, characterized in that: After the step of determining whether the backup file to be compared is a database file, the method further includes: If not, determining that the backup file to be compared is not the data to be restored; If so, it is queried whether the data record in the database file is the same as the data record in the reference backup file.

4. The method according to claim 3, characterized in that: After the step of querying whether the data record in the database file is the same as the data record in the reference backup file, the method further includes: If not, marking the difference data between the data record in the database file and the data record in the reference backup file as the data to be restored; If so, it is determined that the backup file to be compared is not the data to be restored.

5. The method according to claim 1, characterized in that: The process of obtaining a snapshot data list of the target device in response to the user's operation on the designated target device involves data interaction with the iCloud server, including: In response to the user's authorization instruction, obtaining the user's IOS account and the password of the IOS account; Perform authentication based on the SRP-6a protocol and obtain a token returned from the iCloud server; Send a request to the server based on the IOS account, the token and the client information, and obtain metadata returned from the server, where the metadata is a parameter used by the client and the server to make data requests, wherein the client information includes device information and session information; Sending a request to the server based on the metadata and the client information to obtain an escrow key; In response to the user's designated target device operation, a request is sent to the server based on the metadata, the client information, and the device list bound to the IOS account to obtain a snapshot data list of the target device and a snapshot time and snapshot identifier corresponding to the snapshot data list, wherein the snapshot identifier is used to identify each snapshot backup operation, and the snapshot time is the time when each snapshot backup operation is executed; Sending a request to the server based on the metadata, the client information and the snapshot identifier to download an encrypted backup file in a snapshot data list corresponding to the snapshot identifier, wherein the snapshot data list includes multiple backup files and backup file identifiers corresponding to the backup files; The encrypted backup file is decrypted based on the escrow key to obtain the backup file in the snapshot data list.

6. The method according to claim 5, characterized in that: The step of responding to the user's operation of specifying a target device, sending a request to the server based on the metadata, the client information, and the device list bound to the IOS account, obtaining a snapshot data list of the target device and a snapshot time and snapshot identifier corresponding to the snapshot data list, includes: Send a request to the server based on the metadata and the client information, and obtain a device identifier returned from the server, where the device identifier is used to mark an iOS device that has been logged in by the iOS account; According to all the device identifiers, obtain a list of devices bound to the IOS account; In response to the user's operation of specifying a target device, a request is sent to the server based on the metadata and the client information to traverse the device list, and a snapshot data list of the target device and a snapshot time and snapshot identifier corresponding to the snapshot data list returned from the server are obtained.

7. The method according to claim 5, characterized in that: The sending a request to the server based on the metadata, the client information and the snapshot identifier to download the encrypted backup file in the snapshot data list corresponding to the snapshot identifier includes: Sending a request to the server based on the metadata, the client information and the snapshot identifier to traverse the corresponding snapshot data list, and obtaining the backup file list identifier returned from the server; Sending a request to the server to traverse the corresponding backup file list based on the metadata, the client information and the backup file list identifier, and obtaining the backup file identifier returned from the server; Sending a request to the server based on the backup file identifier to obtain the file attribute and download link corresponding to the backup file identifier returned from the server; The encrypted backup file is downloaded accordingly according to the download link and the file attribute.

8. A data recovery device for an IOS device, characterized in that: The system comprises: A backup data acquisition module, configured to acquire a snapshot data list of a target device in response to a user's operation of specifying the target device; A snapshot data traversal module, used for sorting the snapshot data lists according to the snapshot times corresponding to the snapshot data lists, taking the snapshot data list corresponding to the last snapshot time as the benchmark snapshot data list, and the other snapshot data lists as the snapshot data lists to be compared; a to-be-restored data determination module, configured to, in response to the user's data recovery operation, compare the difference between the baseline snapshot data list and the to-be-compared snapshot data list to determine the to-be-restored data; A data recovery module is used to recover the data according to the data to be recovered.

9. A data recovery system for an IOS device, comprising: A client and a server, wherein the client sends instructions to the server so that the system executes the method described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, which, when executed on a computer, enable the computer to execute the method according to any one of claims 1 to 7.

Citation Information

Cited By

  • ICloud data decryption and extraction system and method

    CN120856352A

  • An iCloud data decryption and extraction system and method

    CN120856352B