Method and system for backup and recovery of iOS device data

Abstract

The application relates to the technical field of data backup, and discloses a backup and recovery method and system for iOS device data, wherein the method comprises the following steps: performing SSL certificate verification and EscrowBag key authentication on an iOS device to obtain a data path list; performing parallel scanning of APFS file system B-Tree traversal, NAND flash page reading and SQLite WAL log analysis on an iOS device storage partition according to the data path list to obtain an original data set; performing integrity evaluation based on the original data set to obtain an effective data set and construct a virtual file index; confirming a user's data selection list based on the virtual file index and performing safe recovery to return a data recovery result; and the application combines SQLite page Cell reconstruction and fragment file signature matching technology, can intelligently repair and quality predict damaged data, improves user experience and operation efficiency, and ensures the safety and reliability in the data recovery process.

Description

Technical Field

[0001] This invention relates to the field of data backup technology, and in particular to a method and system for backing up and restoring data on iOS devices. Background Technology

[0002] Users store a large amount of personal data on their iOS devices, including important information such as photos, videos, chat logs, and contact details. However, due to accidental deletion, failed system upgrades, physical device damage, or factory resets, users frequently face data loss. Existing data recovery technologies mainly rely on iTunes or iCloud backups for recovery. This method requires users to create a complete backup beforehand and cannot selectively recover data for specific applications or data types. Furthermore, it often fails to function properly when the device is damaged or the system crashes. For the proprietary data formats of social applications such as WhatsApp and LINE, existing technologies often cannot accurately parse their complex database structures and encryption mechanisms, resulting in low recovery success rates. Summary of the Invention

[0003] This invention provides a method and system for backing up and restoring data on iOS devices. By combining SQLite (lightweight relational database) page cell reconstruction and fragmented file signature matching technology, this invention can intelligently repair and predict the quality of damaged data, improve user experience and operational efficiency, and ensure the security and reliability of the data recovery process.

[0004] In a first aspect, the present invention provides a method for backing up and restoring data on an iOS device, the method comprising:

[0005] SSL certificate verification and EscrowBag key authentication are performed on the iOS device to obtain device authentication information. Based on the device authentication information, Bundle path parsing and table structure identification are performed on the WhatsApp ChatStorage database, system SMS database and Photos database in the iOS device to obtain a data path list.

[0006] Based on the data path list, perform parallel scanning of the iOS device storage partition, including APFS file system B-Tree traversal, NAND flash memory page reading, and SQLite WAL log parsing, to obtain the original data set;

[0007] Integrity assessment is performed on the original data set, and cell reconstruction is performed on the damaged SQLite pages and signature matching is performed on the fragmented files to obtain a valid data set. A virtual file index is then constructed based on the valid data set.

[0008] Based on the virtual file index, the user's data selection list is confirmed and a secure recovery is performed, returning the data recovery result.

[0009] In conjunction with the first aspect, in the first implementation of the first aspect of the present invention, the step of performing SSL certificate verification and EscrowBag key authentication on the iOS device to obtain device authentication information, and then performing Bundle path parsing and table structure identification on the WhatsApp ChatStorage database, system SMS database, and Photos database in the iOS device based on the device authentication information to obtain a data path list, including:

[0010] Establish a USB communication connection between the Lightning interface and the iOS device and send a device query command to the lockdownd daemon to obtain the connection handle;

[0011] Based on the connection handle, the local computer performs an SSL handshake with the iOS device and exchanges a digital certificate and a pairing record stored on the iOS device for two-way authentication to obtain a secure communication channel;

[0012] Through the secure communication channel, a password verification bypass operation is performed based on the EscrowBag encryption key generated during the initial pairing of the iOS device, thereby obtaining the device's unlocked state.

[0013] Based on the device unlock status, read the device authentication information of the iOS device, which includes the UDID unique identifier, the iOS system version number, and the APFS file system configuration parameters;

[0014] The list of data paths in the iOS device is identified based on the device authentication information.

[0015] In conjunction with the first aspect, in a second implementation of the first aspect of the present invention, the step of identifying the data path list in the iOS device based on the device authentication information includes:

[0016] Input the APFS file system configuration parameters from the device authentication information into the com.apple.mobile.installation_proxy service to obtain a list of installed applications;

[0017] Based on the list of installed applications, the sandbox root directory path of each application is parsed and the set of application database file paths is located.

[0018] Read the data path list of the WhatsApp database, SMS database, and Photos database based on the application database file path set.

[0019] In conjunction with the first aspect, in a third implementation of the first aspect of the present invention, the step of reading the data path list of the WhatsApp, SMS, and Photos databases according to the application database file path set includes:

[0020] A list of valid database files is obtained by performing format header validation on the SQLite files in the application database file path set.

[0021] Based on the list of valid database files, query the table structure information of the WhatsApp database, SMS database, and Photos database;

[0022] Based on the table structure information, the field definition specifications are read, and based on the field definition specifications, the field access paths are marked according to the data source and storage characteristics to obtain a data path list.

[0023] In conjunction with the first aspect, in the fourth implementation of the first aspect of the present invention, the parallel scan of the iOS device storage partition based on the data path list, including APFS file system B-Tree traversal, NAND flash memory page reading, and SQLite WAL log parsing, to obtain the original data set, includes:

[0024] The WhatsApp ChatStorage.sqlite path and Photos.sqlite path recorded in the data path list are assigned to different scanning threads and APFS logical layer scan, NAND physical layer scan and WAL log scan are started to obtain a set of scanning tasks;

[0025] Based on the scan task set, read the data location information of the APFS file system;

[0026] Based on the data location information, the NAND flash memory chip is directly accessed and the raw data is read. At the same time, the ECC check code and bad block mark of each page's OOB area are checked to filter out the raw file data.

[0027] The transaction records of the SQLite database file in the original file data are analyzed by performing WAL (Write-Ahead Log) and Rollback Log, and the page cell data structure of the deleted records is reconstructed to restore the original data set that was overwritten.

[0028] In conjunction with the first aspect, in a fifth implementation of the first aspect of the present invention, the step of reading data location information from the APFS file system based on the scan task set includes:

[0029] Based on the scan task set, locate the storage partition of the iOS device and read the basic configuration information of the APFS file system;

[0030] Based on the basic configuration information, the physical address offset of the Object Map is extracted from the Volume Superblock, and the root node pointer and object count field of the Object Map header are read to obtain the Object Map index table.

[0031] The physical address of the root node in the Object Map index table is input into the B-Tree traversal algorithm to determine the node type and parse the key-value pairs and child node pointers in the node according to the different structures of internal nodes and leaf nodes to obtain the B-Tree node traversal path.

[0032] Based on the B-Tree node traversal path, locate the file system objects corresponding to the WhatsApp ChatStorage.sqlite and Photos.sqlite files, and extract the inode number and physical block address information from the extent record of each file to obtain the data location information.

[0033] In conjunction with the first aspect, in the sixth implementation of the first aspect of the present invention, the step of performing integrity assessment based on the original data set, performing cell reconstruction on corrupted SQLite pages, and performing signature matching repair on fragmented files to obtain a valid data set, and constructing a virtual file index based on the valid data set, includes:

[0034] Extract the file integrity, overwrite degree, time interval, and storage location of the original data set and calculate the probability of successful data recovery;

[0035] A database corruption location report is created based on the probability of successful data recovery, marking the location of the corrupted page.

[0036] Based on the damaged page address in the database damage location report, read the link pointers and cell contents of adjacent intact pages, and reconstruct the cell pointer array structure and data record content of the damaged page to obtain a complete SQLite database file;

[0037] Based on the complete SQLite database file, file reassembly is performed on the file data marked as fragmented in the original data set to obtain a valid data set;

[0038] A virtual file index is built based on the storage offset, data size, and file type identifier of each file in the valid data set.

[0039] In conjunction with the first aspect, in the seventh implementation of the first aspect of the present invention, the step of confirming the user's data selection list based on the virtual file index and performing secure recovery, and returning the data recovery result, includes:

[0040] Image files marked as JPEG and HEIC formats in the virtual file index are used by the libjpeg-turbo decoding library to generate thumbnails, while the FFmpeg library is used to extract the first frame key image from the MP4 video file to obtain media preview data;

[0041] Based on the WhatsApp chat history and system SMS files in the virtual file index, perform emoji decoding and timestamp formatting, and sort the contact data by name to display phone and email information to obtain text preview data;

[0042] Based on the media preview data and the text preview data, the preview content is displayed through the user interface and the user's checkbox selection operation is recorded, along with the path and recovery priority of the selected file, to obtain a data selection list.

[0043] Based on the data selection list, the selected data is safely recovered, and the data recovery result is returned.

[0044] In conjunction with the first aspect, in the eighth implementation of the first aspect of the present invention, the step of safely recovering the selected data according to the data selection list and returning the data recovery result includes:

[0045] Extract the path information of the selected file from the data selection list and generate a secure data channel between the iOS device and the local computer;

[0046] Based on the secure data channel, the selected data is divided into data blocks and each data block is encrypted to obtain securely transmitted data;

[0047] The securely transmitted data is transferred from the iOS device to the local computer, decrypted block by block, and written to the user-specified directory according to the SQLite database structure of the original file, and the data recovery result is returned.

[0048] Secondly, the present invention provides an iOS device data backup and recovery system, the iOS device data backup and recovery system comprising:

[0049] The acquisition module is used to perform SSL certificate verification and EscrowBag key authentication on the iOS device to obtain device authentication information. Based on the device authentication information, the module performs Bundle path parsing and table structure identification on the WhatsApp ChatStorage database, system SMS database, and Photos database in the iOS device to obtain a data path list.

[0050] The storage partition scanning module is used to perform parallel scanning of the iOS device storage partitions based on the data path list, including APFS file system B-Tree traversal, NAND flash memory page reading, and SQLite WAL log parsing, to obtain the original data set.

[0051] The integrity assessment module is used to perform integrity assessment based on the original data set, perform cell reconstruction on damaged SQLite pages and signature matching repair on fragmented files to obtain a valid data set, and construct a virtual file index based on the valid data set;

[0052] The secure recovery module is used to confirm the user's data selection list based on the virtual file index and perform secure recovery, returning the data recovery result.

[0053] The technical solution provided by this invention bypasses the lock screen password verification of iOS devices through SSL certificate verification and EscrowBag key authentication mechanisms, supporting data access to devices in locked, damaged, and recovery modes. Based on Bundle path parsing and table structure recognition technology, it can accurately locate and parse the complex internal structures of the WhatsApp ChatStorage database, system SMS database, and Photos database, overcoming the limitations of existing technologies in supporting private data formats of iOS applications. Through a parallel scanning architecture of APFS file system B-Tree traversal, NAND flash memory page reading, and SQLiteWAL log parsing, data extraction can be performed simultaneously at the logical, physical, and log layers, improving scanning efficiency and data coverage. Combined with SQLite page cell reconstruction and fragmented file signature matching technology, it enables intelligent repair and quality prediction of damaged data. Through virtual file index construction and lazy loading technology, it achieves rapid preview of large amounts of recovered data without consuming large amounts of memory resources, while also providing thumbnail generation and format parsing functions, improving user experience and operational efficiency. A secure transmission channel was established from iOS devices to the local computer, and with the help of chunked transmission and breakpoint resume mechanisms, the security and reliability of the data recovery process were ensured.

[0054] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0055] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0056] Figure 1 This is a schematic diagram of an embodiment of the method for backing up and restoring iOS device data in this invention;

[0057] Figure 2 This is a schematic diagram of an embodiment of the iOS device data backup and recovery system in this invention. Detailed Implementation

[0058] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0059] The terms "comprising" and "having," and any variations thereof, used in the embodiments of this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0060] To facilitate understanding of this embodiment, a method for backing up and restoring iOS device data disclosed in this embodiment of the invention will first be described in detail. For example... Figure 1 As shown, this method includes the following steps:

[0061] 101. Perform SSL certificate verification and EscrowBag key authentication on the iOS device to obtain device authentication information. Based on the device authentication information, perform Bundle path parsing and table structure identification on the WhatsApp ChatStorage database, system SMS database, and Photos database in the iOS device to obtain a data path list.

[0062] Specifically, a wired communication channel is established at the physical level between the iOS device and the external host system. This is achieved through the Lightning interface, building a low-level connection architecture based on the USB protocol (Universal Serial Bus). On top of this architecture, a device query command is sent to the iOS system-level daemon `lockdownd` to obtain a unique connection handle representing the current connection session. This connection handle serves as the context carrier for all command exchanges and data transmissions during communication. Based on the obtained connection handle, the host system initiates an SSL (Secure Sockets Layer) handshake with the iOS device. During the handshake, the host system provides a trusted digital certificate from its local computer and extracts the pairing record generated during the initial pairing with the iOS device. Through digital signature verification and key negotiation, two-way identity verification is completed, establishing a secure communication channel with a complete identity trust chain and encryption protection. The system accesses the iOS device's encryption policy parameters via a secure communication channel and triggers a verification operation that bypasses the lock screen password mechanism based on the EscrowBag key set pre-stored during initial pairing. It decrypts the relevant access password verification area using the EscrowBag, directly obtaining the device's unlock status and successfully mounting the user data partition without requiring user password input. After unlocking, it calls the device information reading interface to extract core authentication information, including the Unique Device Identifier (UDID), operating system version number, device model, serial number, region code, hardware encryption flag, and APFS file system structure configuration parameters. It also determines whether the device uses the APFS partition architecture reported by the device. The device authentication information is input into a preset path recognition module, which uses a pre-loaded path template matching engine to identify a set of data paths compatible with the current device system version, partition structure, and application version, generating a data path list. This list includes key paths such as system-level data paths, sandbox data directories, photo media library cache paths, various database file paths, and user behavior log files.

[0063] 102. Perform parallel scans of the iOS device storage partitions based on the data path list, including APFS file system B-Tree traversal, NAND flash memory page reading, and SQLite WAL log parsing, to obtain the original data set;

[0064] Specifically, based on the data path list, key path information related to frequently used user data is extracted, and core data items, including the ChatStorage.sqlite database file path of WhatsApp and the Photos.sqlite system-level photo management database path, are assigned to independent scanning threads. Each thread is responsible for the data extraction task of its corresponding path. ChatStorage is a chat storage database, and SQLite is a lightweight relational database. On this basis, a logical layer structure scan of the APFS file system, a raw page scan of the NAND physical layer of the storage chip, and an incremental transaction record scan of the WAL (Write-Ahead Logging) and Rollback logs of the database file are launched to build a multi-level scan task set with parallel execution characteristics. Based on the data types and path location information involved in the scan task set, the APFS logical layer structure analysis module reads location data such as the Object Map, inode nodes (index nodes), and Volume Superblocks in the file system. Volumes (representing logical storage units) and Superblocks (representing the core data structure storing file system metadata) determine the starting block address, page index number, and data distribution range of the file content in the physical storage layer. Based on the data location information, the low-level I / O access module performs raw block read operations on the NAND flash memory chip, reading a fixed size of page data for each physical page and simultaneously parsing the ECC checksum and bad block identifier fields in the OOB field of the page's outer bounds (OOB) area. Page-by-page verification eliminates data pages that failed to write or had verification errors, and the original file data under the target path is extracted from the valid pages that passed verification. The extracted SQLite database type file undergoes deep structural parsing, and transaction record backtracking analysis of the WAL log is performed to identify incremental writes that have been committed but not yet merged, and these contents are merged into the main database file. At the same time, the Rollback Journal analysis module is used to reverse-parse the rollback log contents formed when the database is abnormally closed or interrupted, reconstructing the state of incomplete data blocks when the transaction was interrupted. Using the Freelist page linked list structure, the historical pages that are marked as released but whose page cell structure has not been actually overwritten are located. By reconstructing the cell pointers, payload structure, B-Tree page header fields, etc. of these pages, the deleted or logically overwritten data records are recovered, forming an original data set containing existing data and recoverable deleted data.

[0065] 103. Based on the original data set, perform integrity assessment, rebuild the damaged SQLite pages and repair the fragmented files by signature matching to obtain a valid data set, and build a virtual file index based on the valid data set;

[0066] Specifically, multi-dimensional recovery feature parameters are extracted for each data item in the original dataset, including file structure integrity flags, whether page data has been overwritten, the time interval between data generation time and the current scan time, and the spatial distribution location in the NAND physical storage address. These features are combined and input into a machine learning model for inference calculations to obtain a recovery success probability score for the current data item, ranging from 0 to 100, quantifying the data's effectiveness and reconstruction potential. Based on the recovery success probability distribution of all SQLite database files, file fragments with scores below a preset threshold are automatically identified, and their corresponding corrupted page addresses are extracted, generating a database corruption location report. This report includes the logical page number of each corrupted page, the name of the table structure it belongs to, the corresponding Freelist flag status, and whether it contains index pages or main data pages. The structure reconstruction module, based on the damaged page addresses marked in the damage location report, reverse-parses the intact pages that are physically contiguous or logically adjacent to them. By analyzing the B-Tree link pointers, right sibling page pointers, page header structures, and Cell array information of these adjacent pages, it recovers the page type identifier, the missing Cell pointer array, and payload data from the original page, and reconstructs the Cell content distribution structure of the target page. This achieves logical repair and structural synthesis of the damaged parts of the database, generating a complete SQLite master database file. Based on the complete SQLite database file, files marked as fragmented in the original data set are reconstructed. By analyzing the file signature markers, timestamp information, data segmentation order markers, and media type identifiers in the fragmented data segments, their logical positions in the database records are matched. These positions are then used as merging anchors to reassemble multiple discontinuous file fragments into continuous file data, resulting in a valid data set. For each file data item in the valid data set, extract its physical storage offset, occupied byte length, data type identifier, and recovery score information, and construct a virtual file index table. Each record in the index table corresponds to a data file item, including attributes such as file preview thumbnail, access permission flag, whether it is a user-selected object, and recommended recovery priority.

[0067] 104. Confirm the user's data selection list based on the virtual file index and perform secure recovery, then return the data recovery results.

[0068] Specifically, the virtual file index undergoes data type identification and format filtering. Image file paths marked as JPEG and HEIC formats are processed by the integrated libjpeg-turbo image decoding library (a high-performance image decoding library) for rapid thumbnail generation. Simultaneously, video files marked as MP4 format utilize the FFmpeg multimedia parsing engine to automatically extract the first keyframe of each video file as a representative image for media preview display, forming a media preview data set. The SQLite database data marked as WhatsApp chat logs and system SMS files in the virtual file index undergoes content structure parsing. Emoji Unicode encoding is performed by identifying the field encoding method. The timestamp field is formatted for local timezone conversion. Contact information fields are sorted in ascending order by the first letter of the name's pinyin. Furthermore, detailed information such as phone numbers, email addresses, and profile picture paths associated with each record are merged, reorganized, and formatted into a table structure to generate text preview data. The system interactively displays media preview and text preview data through a graphical user interface, binding checkboxes and priority dropdown options to each data item. Users can graphically select the data items to be recovered and set their recovery order or importance level. During user operation, the system records the data path, file type, estimated size, and user-specified recovery priority for each selected file, and dynamically updates a data selection list in real time. This list maintains metadata about all data to be recovered based on priority and path information. Secure recovery is performed on the selected data according to the data selection list. An end-to-end data transmission channel encrypted with AES-256-GCM (Advanced Encryption Standard - Galois / Counter Mode) is established for the selected data. The system calls the corresponding data writing module based on the file type, employing a block transmission mechanism to independently encrypt and verify each file in 1MB units during transmission. An SHA-256 (Secure Hash Algorithm 256-bit) integrity checksum is embedded to ensure the accuracy of each data block reception. For interrupted transmission tasks, the system supports breakpoint resumption and state recovery. Before writing files to the target storage path, the file system's writability and user access permissions are verified to ensure the local storage security of sensitive data. Chat logs or contact data marked as sensitive are then encrypted again using a user-defined password. Once all selected data transfers and write operations are complete, a data recovery report is generated. The report includes the number of successfully recovered files, total data volume, average transfer rate, number of failed retransmissions, and overall time taken. It also indicates the integrity score for each data item during the recovery process and whether an encrypted channel was enabled. The recovery report, along with all recovered data, is output to the user-specified path, cached resources are released, and the connection to the iOS device is disconnected, completing the entire data recovery process.

[0069] In one specific embodiment, the process of performing step 101 may specifically include the following steps:

[0070] Establish a USB communication connection between the Lightning interface and the iOS device and send a device query command to the lockdownd daemon to obtain the connection handle;

[0071] Based on the connection handle, the SSL handshake protocol is executed with the iOS device, and the local computer's digital certificate and the pairing record stored in the iOS device are exchanged for two-way authentication to obtain a secure communication channel;

[0072] By using a secure communication channel, a password verification bypass operation is performed based on the EscrowBag encryption key generated when the iOS device is first paired, thus obtaining the device's unlocked status.

[0073] Based on the device's unlock status, read the iOS device's device authentication information, which includes the UDID unique identifier, iOS system version number, and APFS file system configuration parameters;

[0074] Identify the list of data paths in an iOS device based on device authentication information.

[0075] Specifically, the host computer establishes a low-level access path to the target iOS device. This low-level access path starts with the Lightning physical interface and initializes the communication link via the USB transmission protocol. Simultaneously with establishing the physical connection, the Apple Mobile Device USB driver service is started, and its interface calls initiate a connection initialization request to the iOS device. During this process, the host system automatically locates and activates the system daemon `lockdownd` running on the device. This daemon, as the only open system service on the unlocked iOS device, accepts external device management commands and responds to authentication requests. The host system sends a standard device query command to `lockdownd`. Upon the device's response, a one-time connection session is established, and a connection handle is extracted. This connection handle identifies the communication channel between the device and host layers and serves as the endpoint for all command packet exchange and data transmission. After obtaining the handle, the SSL handshake protocol initialization process is initiated. At this time, the master control system submits the digital certificate information contained in the local preset and requests the pairing record file from the iOS device. The iOS device will return the pairing record saved when it was first paired. The record contains key fields such as the master control device's device ID, session verification public key, and signature algorithm type. The master control system performs certificate signature verification on the returned content and reverse verifies whether the certificate returned by the iOS device matches the trust chain. Under the premise of completing two-way identity comparison and handshake key consistency, a secure communication channel based on the SSL protocol is established. Through a secure communication channel, the system loads the locally stored EscrowBag encryption key file. The EscrowBag encryption key file is a key structure generated and stored when the iOS device is first paired with the current host system. It contains a private factor used to derive the device's encrypted lock zone access password. The system directly simulates the device's key derivation mechanism through the key structure to generate an access token that can unlock the user partition and submits it to the device to execute the bypass verification process. The bypass verification process does not require the actual user lock screen password to obtain data access permissions to the device in a logically unlocked state. After successful unlocking, the system issues a device information retrieval command, and the iOS device responds by returning its current status information, which includes the device's unique identifier UDID, the currently running iOS system version number, the device model code, regional settings parameters, and the file system architecture parameters it uses. If the device is a modern version, its file system type is APFS. The returned information also includes the APFS volume label, the root node address of the object mapping tree, encryption enable flags, and other fields. All authentication information is stored in the local cache.Based on the device authentication information, the path recognition module is activated. The module loads a path template database constructed from the mapping relationships between multiple iOS versions and application versions. Using parameters such as the system version number, file system type, and device status flags returned by the current device as filtering conditions, it selects a suitable path mapping scheme from the template library. This list includes all key data paths, such as system database paths, application sandbox paths, photo media paths, iCloud cache paths, and device configuration item paths. It also marks the access method, file format, encryption status, estimated data size, and scan priority of each path item, forming a data path list.

[0076] In one specific embodiment, the process of identifying the data path list in the iOS device based on device authentication information may specifically include the following steps:

[0077] Input the APFS file system configuration parameters from the device authentication information into the com.apple.mobile.installation_proxy service (application installation proxy service) to obtain a list of installed applications;

[0078] Based on the list of installed applications, the sandbox root directory path of each application is parsed and the set of application database file paths is located.

[0079] Read the list of data paths for the WhatsApp database, SMS (Short Message Service) database, and Photos database based on the application database file path set.

[0080] Specifically, APFS file system configuration parameters are extracted from the device authentication information. These parameters include the volume label name, root container path, file system object mapping table location, encryption status flag, and mount point information for each volume. These parameters are obtained through the lockdownd interface or the volume attribute node under the AFCD channel. Using the APFS configuration parameters as the initialization basis, the com.apple.mobile.installation_proxy service interface is input. This service is the official protocol proxy of the iOS system used by external devices to query, control, monitor, and manage installed applications. It has access to metadata of third-party and system applications. After inputting the file system root path parameter, the service returns a complete list of applications containing all registered BundleIdentifiers. A Bundle is an application package, and each application includes basic metadata fields such as application name, version number, developer identifier, whether it is a system application, signature status, and a physical path reference to its sandbox directory. Parsing the container path of each application in the returned structure reveals the actual physical path of the sandbox root directory. The sandbox path contains several subdirectories such as Documents, Library, and tmp. After obtaining the sandbox root path, the path recognition module is loaded. This module searches a pre-defined file structure template in the local database based on the application type and version number, constructing a corresponding set of database file paths for each app. This set includes predefined database filenames, storage locations, encryption status, table structure characteristics, and access priorities. For example, for the WhatsApp application, its data is identified as being located in Documents / ChatStorage.sqli The system identifies the associated media as being located in the Library / Media / directory. For the system SMS service, its database path is fixed at / private / var / mobile / Library / SMS / sms.db. This path belongs to a system-level container and needs to be accessed via AFC or a mounting tool after obtaining the unlock status. For the photo library, its main database is identified as being located at / private / var / mobile / Media / PhotoData / Photos.sqlite. This database is used to store metadata information of photos and video files in the system library, including timestamps, geolocation, associated albums, resource pointers, hidden flags, etc. After collecting all path sets, a path list generation operation is performed, appending fields such as data structure summary, storage priority, encryption status, database type (e.g., SQLite), and whether WAL or Journal logs are supported to each path item, thus constructing a data path list structure.

[0081] In one specific embodiment, the process of reading the data path list of the WhatsApp, SMS, and Photos databases based on the application database file path set can specifically include the following steps:

[0082] A list of valid database files is obtained by performing format header validation on SQLite files in the database file path set.

[0083] Query the table structure information of the WhatsApp database, SMS database, and Photos database based on the list of valid database files;

[0084] Based on the table structure information, the field definition specifications are read, and the field access paths are marked according to the data source and storage characteristics based on the field definition specifications to obtain a data path list.

[0085] Specifically, the application takes the set of database file paths as input and performs format validity verification on each data file marked as SQLite. The verification process uses the 16-byte file header structure unique to SQLite database files as the standard, meaning that the first byte of the file must contain the ASCII string signature "SQLite format 3". At the same time, it parses the page size, database version number, schema version, page count, and write synchronization flag fields in the main database header to ensure that these meta fields conform to the SQLite specification and that the file has not been structurally corrupted or illegally written to. If the file header signature is missing, the version number is incorrect, the page size is abnormal, or the header CRC (Cyclic Redundancy Check) does not match, the database is considered to be in a corrupted state and is removed from the path set. The validated database paths are marked as valid data sources, and a list of valid database files is constructed. Each record in the list contains attributes such as database path, file size, page structure summary, and whether WAL or Rollback mechanism is enabled. For each valid database file, the SQLite structure parsing module is loaded, and the PRAGMA command is executed or the table creation statement in the sqlite_master table is directly parsed to obtain the internal table structure information of the ChatStorage.sqlite database of WhatsApp, the sms.db database of system SMS, and the Photos.sqlite database of the photo library. This includes table name, field name, data type, primary key marker, index structure, foreign key dependencies, and default value settings. For example, in the WhatsApp database, key data tables identified include ZWAMESSAGE (stores text content, sender, recipient, timestamp, media path, etc.), ZWAMEDIACHAT (links multimedia messages), and ZWACONTACT (contact mapping information); in the SMS database, the core tables are message, handle, and chat, which record SMS content, contact numbers, and conversation mappings, respectively; in the photo database, the ZGENERICASSET table is parsed, which contains fields such as the path index of photo resources, shooting time, album number, geolocation, media type, and hidden flags.Based on the table structure information described above, the definition specifications of each field are extracted, including field name, data type (such as TEXT, INTEGER, BLOB), field length, whether it can be nullable, whether it has an index, and other structural characteristics. Field access path mapping rules are established based on the field's storage location, logical function, and data dependencies in the original database. These rules specify the access path, the data table it belongs to, the foreign key binding logic, and the structural hierarchy for each field during data extraction. For example, in WhatsApp, the media field is mapped to the multimedia table through the media ID in the message table and accesses the storage path field. The resource path field in the photo database is formed by concatenating the ZDIRECTORY and ZFILENAME fields in the ZASSET table to create the complete image path. All field access paths are summarized and annotated, and a data path list is constructed by combining the field's database, data content type, source trust level, and field integrity status.

[0086] In one specific embodiment, the process of performing step 102 may specifically include the following steps:

[0087] Assign the WhatsApp ChatStorage.sqlite and Photos.sqlite paths recorded in the data path list to different scanning threads and start APFS (Apple File System) logical layer scan, NAND physical layer scan and WAL log scan to obtain a scan task set;

[0088] Data location information is read from the APFS file system based on the scan task set;

[0089] Based on the data location information, the NAND flash memory chip is directly accessed and the raw data is read. At the same time, the ECC check code (Error Correction Code) and bad block mark of each page's OOB area (Out-Of-Band area) are checked to filter out the raw file data.

[0090] Perform transaction record analysis on the SQLite database file in the original file data using the WAL (Write Ahead Log) and Rollback Log, and reconstruct the page cell data structure of deleted records to restore the original data set that was overwritten.

[0091] Specifically, target database paths with high user data value and structural complexity are extracted from the data path list, such as WhatsApp's ChatStorage.sqlite and the system gallery's Photos.sqlite. These two key paths are then assigned to different parallel scanning threads. Each thread independently maintains thread-level state information, path access permissions, scanning strategy flags, and a list of target recovery items. During the initialization of the scanning task, a task queue containing three scanning modes is synchronously built for each thread: APFS logical layer scanning tasks for structural directories, NAND chip physical layer scanning tasks for physical page data recovery, and WAL (Write-Ahead Log) and Rollback log analysis tasks specifically for recovering incremental or overwritten records. These three tasks together form the scanning task set under the current path and are submitted to the scheduler for execution in a thread-independent manner. During the execution of the APFS logical layer scan task, the file system's Object Map structure and Volume Header are loaded. By traversing container-level nodes and Volume substructures, the file directory tree structure is parsed, the inode (index node) node number of the database file and its corresponding file block mapping table are identified, and the data location index containing information such as file physical page number, page size, logical offset, and write timestamp is extracted. The data location index is then handed over to the physical layer scan module for low-level access, directly establishing a raw block-level read session with the NAND Flash chip. The chip data pages are accessed sequentially according to the physical page number returned by the file system. Each page has a fixed length of 4096 bytes. In addition to the main data area, the system synchronously reads the corresponding OOB (Out-Of-Band) additional area of ​​each page and parses the ECC (Error Detection Code) field to verify the integrity of the page data. At the same time, it identifies whether the page contains bad block markers or replacement block redirection records. Only data pages that pass the ECC check and are not marked as invalid pages are included in the raw file buffer to form an unfiltered raw file data set. Incremental recovery processing at the transaction log level is performed on the database files marked as SQLite in the original file data set. The WAL log file content is extracted and parsed. The log saves the page image and write operation records of the database before the write operation is performed. Data pages that have not yet been merged into the main database are reassembled according to the WAL segment order, and these pages are reassembled and inserted into the main database file in logical order to enhance the transaction consistency of the main file.Based on this, the Rollback Journal is loaded to identify structurally damaged areas caused by the previous abnormal shutdown or transaction rollback operation. The state before the write operation was completed is restored through the backup page data in the log. At the same time, the Freelist page list structure in the database is analyzed. The Freelist page list points to all pages that have been logically released but have not yet been overwritten. The Freelist list is traversed and page structure verification and cell content restoration operations are performed on each free page. Based on the SQLite page structure format, page type, page header mark, number of cells, cell offset table and payload content are extracted. By reconstructing the cell pointer array and cell data block arrangement order within the page, the deleted or logically overwritten historical records are restored, forming an original data set including main data area records, WAL area change records, rollback page recovery records and Freelist unoverwritten records.

[0092] In one specific embodiment, the process of performing the step of reading data location information from the APFS file system based on the scan task set can specifically include the following steps:

[0093] Locate the storage partition of the iOS device based on the scan task set and read the basic configuration information of the APFS file system;

[0094] Based on the basic configuration information, the physical address offset of the Object Map is extracted from the Volume Superblock, and the root node pointer and object count field of the Object Map header are read to obtain the Object Map index table.

[0095] Input the physical address of the root node in the Object Map index table into the B-Tree (balanced tree) traversal algorithm to determine the node type and parse the key-value pairs and child node pointers in the node according to the different structures of internal nodes and leaf nodes to obtain the B-Tree node traversal path.

[0096] Based on the B-Tree node traversal path, locate the file system objects corresponding to the WhatsApp ChatStorage.sqlite and Photos.sqlite files, and extract the inode number and physical block address information from the extent record of each file to obtain the data location information.

[0097] Specifically, based on the path targets marked in the scan task set—namely, the logical paths pointing to the WhatsApp database (ChatStorage.sqlite) and the photo database (Photos.sqlite)—the physical storage partitions where these two target files reside are deduced. The APFS file system scanning module is then invoked to establish a low-level logical access channel. A fixed offset segment of the volume start block is extracted from the primary partition mapped to the iOS device to locate the currently active APFS volume container. Within the Superblock region of this APFS volume container, basic configuration fields including block size, total number of blocks, start block number, and object mapping start offset are read, providing a structural boundary reference for the entire file system. Based on the Object Map location offset indicated in the volume configuration, the system jumps to the physical start position of the Object Map and parses its header structure information, extracting the root node block address and the current total number of objects. This is used to establish an initial Object Map index table, which records the logical identifiers and physical mapping relationships of all currently active objects (files, directories, nodes) in the system. The root node address in the Object Map index table is loaded into the B-Tree traversal algorithm module as input. Based on the B+Tree structure rules adopted by APFS, the type field value of the current node page is determined. The node is divided into internal nodes and leaf nodes according to the node type. Child node pointer extraction is performed on internal nodes, and key-value pair structure parsing is performed on leaf nodes. The key value is the object's unique ID or path hash value, and the value is a pointer to the object's metadata and physical location description information. The B-Tree node page chain is traversed from top to bottom recursively, expanding the child nodes level by level until the leaf node page containing the target file path is located. During this process, a B-Tree traversal path graph is constructed, and the offset, number of child items, object hash, and verification field of each level node in the path are recorded in the traversal log. After successfully locating the B-Tree leaf nodes containing the descriptions of the ChatStorage.sqlite and Photos.sqlite file objects, the inode block number of each object is read. The inode number is the unique identifier of the target database file in the file system. Simultaneously, the extent record linked list associated with the inode is read. The extent record contains information about the block address distribution of the file data in the physical storage layer, including fields such as the starting physical block number, the number of consecutive blocks, the checksum status, and the encryption flag. Based on the extent description, the physical location mapping table of the target database file on the NAND Flash storage medium is reconstructed, i.e., the actual address layout of the file data in the device's storage layer. The physical block address information is used as the data location information. Here, NAND refers to NAND gate flash memory.

[0098] In one specific embodiment, the process of performing step 103 may specifically include the following steps:

[0099] Extract file integrity, overwrite extent, time interval, and storage location of the original dataset and calculate the probability of successful data recovery;

[0100] A database corruption location report is created based on the probability of successful data recovery, marking the location of corrupted pages.

[0101] Based on the damaged page address in the database corruption location report, read the link pointers and cell contents of adjacent intact pages, and reconstruct the cell pointer array structure and data record content of the damaged page to obtain a complete SQLite database file;

[0102] Based on the complete SQLite database file, file reassembly is performed on the file data marked as fragmented in the original data set to obtain a valid data set;

[0103] A virtual file index is built based on the storage offset, data size, and file type identifier of each file in the valid data set.

[0104] Specifically, the original dataset contains various file data pages and logical database segments extracted from the storage media of iOS devices. Each data unit is used as an evaluation object, and file integrity flags, data page overwrite probability, time interval between data generation and extraction, and data storage location distribution characteristics in the NAND physical address mapping table are extracted item by item. File integrity is jointly judged by CRC check, SQLite header signature detection, and structure page consistency check; overwrite probability is calculated by comparing the byte entropy distribution within the page with historical checksums; time interval is calculated by the difference between the timestamp field in the metadata and the current system time; and storage location is evaluated by comprehensively assessing access risk through parameters such as the logical block number to which the page belongs and the bad block rate and erase / write count of the NAND chip it resides in. The above indicators are input into a pre-trained recovery prediction model. The model uses logistic regression or deep neural network to score the recovery success probability of each data item, with an output value ranging from 0 to 1. Based on the set probability threshold, pages with a recovery probability below the standard are regarded as damaged pages, and a database damage location report is generated. The report uses the page address as an index and marks the database name, page type, logical offset number, historical write count, and possible damage cause of each damaged page. For each damaged page, its physically adjacent preceding and following pages are loaded. Structural decoding and link pointer extraction are performed on these two pages. By identifying the right sibling page pointer, previous page pointer, and cell offset table in the B-Tree page, the context position of the damaged page in the B-Tree structure is reconstructed. Simultaneously, cell template data and content arrangement patterns with similar structures are extracted from adjacent pages. Cell pointer table interpolation and payload segment structure prediction are performed on the damaged page, and the original page structure is reconstructed accordingly, including the page header, free space offset, number of cells, and relative offset address of each cell, resulting in an SQLite database page. All repaired pages are then integrated in logical order to reconstruct a complete SQLite database file. Based on a complete SQLite database file, a reorganization operation is performed on unstructured data files marked as "fragmented" in the original data set. The fragmented data is classified and aggregated according to the file index information, timestamp sequence, original file size, signature mark and media attributes stored in the database records. A merge algorithm based on signature matching and time consistency is applied to sort and splice multiple file fragments by offset, while filling in some missing segments. Error tolerance methods such as zero filling, interpolation or redundant frame insertion are used to ensure the parsability of the file at the syntax level, generate a complete and usable data file and merge it into the effective data set.For each valid data item, its physical page offset position in the storage medium, actual file size, and type identifier (such as JPEG, MP4, SQLite, PDF, etc.) are extracted. Combined with the recovery success probability score and integrity score, a structured record is created for the current valid data item and written to the virtual file index table. The index table is stored in a flat data structure and includes path identifier, file type, recovery score, access permissions, preview feasibility flag, and target storage recommended path.

[0105] In one specific embodiment, the process of performing step 104 may specifically include the following steps:

[0106] Image files marked as JPEG and HEIC formats in the virtual file index are used by the libjpeg-turbo decoding library to generate thumbnails, while the FFmpeg library is used to extract the first frame key frame from the MP4 video file to obtain media preview data;

[0107] Based on the WhatsApp chat history and system SMS files in the virtual file index, perform emoji decoding and timestamp formatting, and sort the contact data by name to display phone and email information, thus obtaining text preview data;

[0108] Based on media preview data and text preview data, the preview content is displayed through the user interface and the user's checkbox selection operation is recorded, along with the path and recovery priority of the selected file, to obtain a data selection list.

[0109] The system performs secure data recovery based on the data selection list and returns the data recovery results.

[0110] Specifically, the virtual file index undergoes data type filtering. The format of each file is determined by identifying the file extension marker field and the file header signature bytes. Image files marked as JPEG (starting with FFD8) and HEIC are uniformly assigned to the image processing module. The image processing module uses the libjpeg-turbo high-performance decoding library to perform fast decoding on JPEG image files. Based on a preset thumbnail size (e.g., 256×256 pixels), it calls the library's compression sampling function to extract image brightness and color channel data, reducing the image scale while maintaining the clarity of the main visual elements. For HEIC format images, the system image frame or hardware-accelerated decoder is used to extract the main image frame and convert it into intermediate color space. The system formats images (such as YUV420) and generates visual thumbnails. All generated image preview files are cached in the L1 preview area of ​​memory, and a path mapping table is established. At the same time, for video files marked as MP4 format, the integrated FFmpeg multimedia processing library is called. The libavformat module is used to parse the MP4 container structure and the av_read_frame() function is called to read video frames in a loop until the first keyframe is captured. The first keyframe is decoded by the libavcodec decoder and converted into RGB image data. Then, it is compressed to generate static thumbnails for video preview display. The image preview and video preview data are unified into a media preview data structure and bound to file path, file type, and thumbnail cache reference identifier. In the parallel process, the data paths marked as WhatsApp chat history database and system SMS database in the virtual file index are loaded, and a dedicated text content parser is called to load the SQLite database file. The message body field, sender, receiver, and timestamp field are extracted by executing SELECT statements. The Unicode de-parsing of the emoji field is performed on the message body field to convert it into emoji icons or standard symbols, and the timestamp field is formatted according to the system's local time settings, such as converting the UNIX timestamp to the "YYYY-MM-DD HH:mm:ss" format. The name, phone number, and email fields in the contact database are read, and the name field is sorted by pinyin conversion to generate a sorted contact preview table. The contact preview table is embedded into the chat history interface as an auxiliary display module. Media preview data and text preview data are displayed to users in a waterfall layout through a graphical user interface. Each preview item is accompanied by a checkbox control and a priority rating selection box. When users make multiple selections, the system records their selection status, corresponding file path, recovery rating value, and recommended storage path in real time. All file items selected by users are summarized into a data selection list, which is cached in the recovery scheduling module in JSON format, and the selection time and user identifier are recorded.The recovery execution engine recovers each marked data item in the data selection list item by item, establishing an independent data transmission channel for each file. Each data block is end-to-end encrypted using the AES-256-GCM algorithm, and integrity verification based on SHA-256 is performed. Large files are divided into 1MB fixed blocks and transmitted in parallel, with the number of threads dynamically adjusted under USB 2.0 or USB 3.0 bandwidth conditions. Access permissions to the user-defined target directory are verified and a write transaction is established before writing to the target path. The transaction is automatically committed upon completion, ensuring the file is completely written to disk. For sensitive data items such as contacts or chat logs, secondary encryption is enabled according to settings, and a key digest is generated and embedded in the recovery report for user verification. After recovery, a recovery result file is generated, recording the path, type, size, time taken, integrity score, and whether retransmission was triggered for each successfully recovered file.

[0111] In one specific embodiment, the process of performing secure recovery of selected data based on the data selection list and returning the data recovery result may specifically include the following steps:

[0112] Extract the path information of the selected files from the data selection list and create a secure data channel between the iOS device and the local computer;

[0113] Based on a secure data channel, the selected data is divided into data blocks and each data block is encrypted to obtain securely transmitted data;

[0114] The system securely transfers data from the iOS device to the local computer, decrypts it block by block, writes it to the user-specified directory according to the original file's SQLite database structure, and returns the data recovery results.

[0115] Specifically, all user-selected target data items are extracted from the data selection list. The path information, file type, recovery priority, source database type, and recommended target path for each item are loaded into the recovery scheduling module. The recovery scheduling module binds the data items to the device's file system handle based on the path identifier and performs pre-checks on path validity, source data integrity, and access permissions to ensure all files are within authorized data ranges and the device is unlocked or accessible. A key negotiation process is initiated using a USB port or WiFi channel through a preset device connection context. An elliptic curve key exchange algorithm (such as ECDH) is used to generate a symmetric encryption key between the iOS device and the local computer. Based on this key, an end-to-end secure communication tunnel based on the AES-256-GCM algorithm is established. This secure communication tunnel possesses data encryption, integrity verification, and transmission authentication capabilities, ensuring that data cannot be tampered with or leaked by intermediate devices during transmission. After a secure communication channel is established, the logical content of each target file is divided into multiple fixed-size data blocks according to its actual size. Each data block is independently encrypted using the AES-256-GCM encryption module. At the same time, a unique initialization vector (IV) and an encrypted tag (authentication tag) are generated for each data block for integrity authentication, forming a structurally complete secure transmission data unit. The structure includes the ciphertext body, IV field, Tag field, and data sequence number. All data blocks are sent from the iOS device to the local computer using a multi-threaded approach. The receiving end listens on the port and caches the data blocks in real time according to their numbering order. The decryption module uses the locally stored symmetric key and the received IV and Tag to perform integrity verification on each encrypted block and decrypt the ciphertext data. Blocks that fail verification are immediately discarded, triggering a retransmission mechanism. After successful decryption, the original plaintext data block is restored to its corresponding plaintext data page and written to the target file buffer. If the target file type is an SQLite database file, the database structure reconstruction module is automatically invoked. Based on the original schema structure recorded in the data selection list for each database file, page-level reconstruction and B-Tree structure restoration are performed on the decrypted data content. The SQLite file header, page directory, and transaction log association fields are reconstructed. Simultaneously, for databases with WAL (Write-Ahead Logging) enabled, corresponding WAL segments and checkpoint segments are established to ensure structural integrity and data consistency after file recovery. Data is written to the user-specified local directory according to the recovery path corresponding to each file. Transaction control strategies are enabled during the writing process to prevent database structure corruption due to write interruption. The write status and timestamp of each file are recorded.Once all data blocks have been decrypted and recovered, the communication channel is automatically closed and a recovery result report is generated. The report includes: the original path, target path, file size, total number of blocks, encryption and decryption status, whether retransmission was triggered, integrity score, and whether the write was successful for each recovered file. All failed recovery items are marked for subsequent review. Finally, the encryption key cache and recovery log temporary files are cleared, channel resources are released, and the overall recovery result is output to the user-specified directory.

[0116] The above describes the method for backing up and restoring iOS device data in embodiments of the present invention. The following describes the system for backing up and restoring iOS device data in embodiments of the present invention. Please refer to [link / reference]. Figure 2 One embodiment of the iOS device data backup and restore system of this invention includes:

[0117] The acquisition module 201 is used to perform SSL certificate verification and EscrowBag key authentication on the iOS device to obtain device authentication information, and based on the device authentication information, to perform Bundle path parsing and table structure identification on the WhatsApp ChatStorage database, system SMS database and Photos database in the iOS device to obtain a data path list.

[0118] The storage partition scanning module 202 is used to perform parallel scanning of the iOS device storage partition based on the data path list, including APFS file system B-Tree traversal, NAND flash memory page reading, and SQLite WAL log parsing, to obtain the original data set.

[0119] The integrity assessment module 203 is used to perform integrity assessment based on the original data set, perform cell reconstruction on damaged SQLite pages and signature matching repair on fragmented files to obtain a valid data set, and build a virtual file index based on the valid data set;

[0120] The secure recovery module 204 is used to confirm the user's data selection list based on the virtual file index and perform secure recovery, returning the data recovery result.

[0121] Through the collaborative efforts of the aforementioned components, and utilizing SSL certificate verification and EscrowBag key authentication mechanisms, it is possible to bypass the lock screen password verification of iOS devices, supporting data access to devices in locked, damaged, and recovery modes. Based on Bundle path parsing and table structure recognition technology, it can accurately locate and parse the complex internal structures of the WhatsAppChatStorage database, system SMS database, and Photos database, overcoming the limitations of existing technologies in supporting iOS application private data formats. Through a parallel scanning architecture of APFS file system B-Tree traversal, NAND flash memory page reading, and SQLite WAL log parsing, data extraction can be performed simultaneously at the logical, physical, and log layers, improving scanning efficiency and data coverage. Combined with SQLite page cell reconstruction and fragmented file signature matching technology, it enables intelligent repair and quality prediction of damaged data. Through virtual file index construction and lazy loading technology, it achieves rapid previewing of large amounts of recovered data without consuming significant memory resources, while also providing thumbnail generation and format parsing functions, improving user experience and operational efficiency. A secure transmission channel was established from iOS devices to the local computer, and with the help of chunked transmission and breakpoint resume mechanisms, the security and reliability of the data recovery process were ensured.

[0122] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0123] If the integrated unit is implemented as 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 technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0124] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for backing up and restoring data on an iOS device, characterized in that, include: The process involves: verifying the iOS device with an SSL certificate and EscrowBag key to obtain device authentication information; and using this authentication information, performing bundle path parsing and table structure identification on the WhatsApp ChatStorage database, system SMS database, and Photos database within the iOS device to obtain a data path list. Specifically, this includes: establishing a USB communication connection via the Lightning interface on the iOS device and sending a device query command to the lockdownd daemon to obtain a connection handle; performing an SSL handshake protocol with the iOS device based on the connection handle and exchanging a digital certificate from the local computer and a pairing record stored on the iOS device for two-way authentication to obtain a secure communication channel; using this secure communication channel, performing a password bypass operation based on the EscrowBag encryption key generated during the initial pairing of the iOS device to obtain the device unlock status; reading the device authentication information of the iOS device based on the unlock status, which includes a UDID unique identifier, the iOS system version number, and APFS file system configuration parameters; and identifying the data path list within the iOS device based on the device authentication information. Based on the data path list, perform parallel scanning of the iOS device storage partition, including APFS file system B-Tree traversal, NAND flash memory page reading, and SQLite WAL log parsing, to obtain the original data set; Integrity assessment is performed on the original data set, and cell reconstruction is performed on the damaged SQLite pages and signature matching is performed on the fragmented files to obtain a valid data set. A virtual file index is then constructed based on the valid data set. Based on the virtual file index, the user's data selection list is confirmed and a secure recovery is performed, returning the data recovery result.

2. The method for backing up and restoring iOS device data according to claim 1, characterized in that, The step of identifying the list of data paths in the iOS device based on the device authentication information includes: Input the APFS file system configuration parameters from the device authentication information into the com.apple.mobile.installation_proxy service to obtain a list of installed applications; Based on the list of installed applications, the sandbox root directory path of each application is parsed and the set of application database file paths is located. Read the data path list of the WhatsApp database, SMS database, and Photos database based on the application database file path set.

3. The method for backing up and restoring iOS device data according to claim 2, characterized in that, The step of reading the data path list of WhatsApp, SMS, and Photos databases based on the application database file path set includes: A list of valid database files is obtained by performing format header validation on the SQLite files in the application database file path set. Based on the list of valid database files, query the table structure information of the WhatsApp database, SMS database, and Photos database; Based on the table structure information, the field definition specifications are read, and based on the field definition specifications, the field access paths are marked according to the data source and storage characteristics to obtain a data path list.

4. The method for backing up and restoring iOS device data according to claim 1, characterized in that, The parallel scan of the iOS device's storage partition based on the data path list, involving APFS file system B-Tree traversal, NAND flash page reading, and SQLite WAL log parsing, yields the original data set, including: The WhatsApp ChatStorage.sqlite path and Photos.sqlite path recorded in the data path list are assigned to different scanning threads and APFS logical layer scan, NAND physical layer scan and WAL log scan are started to obtain a set of scanning tasks; Based on the scan task set, read the data location information of the APFS file system; Based on the data location information, the NAND flash memory chip is directly accessed and the raw data is read. At the same time, the ECC check code and bad block mark of each page's OOB area are checked to filter out the raw file data. The transaction records of the SQLite database file in the original file data are analyzed by performing WAL (Write-Ahead Log) and Rollback Log, and the page cell data structure of the deleted records is reconstructed to restore the original data set that was overwritten.

5. The method for backing up and restoring iOS device data according to claim 4, characterized in that, The step of reading data location information from the APFS file system based on the scan task set includes: Based on the scan task set, locate the storage partition of the iOS device and read the basic configuration information of the APFS file system; Based on the basic configuration information, the physical address offset of the Object Map is extracted from the Volume Superblock, and the root node pointer and object count field of the Object Map header are read to obtain the Object Map index table. The physical address of the root node in the Object Map index table is input into the B-Tree traversal algorithm to determine the node type and parse the key-value pairs and child node pointers in the node according to the different structures of internal nodes and leaf nodes to obtain the B-Tree node traversal path. Based on the B-Tree node traversal path, locate the file system objects corresponding to the WhatsApp ChatStorage.sqlite and Photos.sqlite files, and extract the inode number and physical block address information from the extent record of each file to obtain the data location information.

6. The method for backing up and restoring iOS device data according to claim 1, characterized in that, The process of performing integrity assessment based on the original data set, reconstructing damaged SQLite pages using Cells, and repairing fragmented files by signature matching to obtain a valid data set, and constructing a virtual file index based on the valid data set, includes: Extract the file integrity, overwrite degree, time interval, and storage location of the original data set and calculate the probability of successful data recovery; A database corruption location report is created based on the probability of successful data recovery, marking the location of the corrupted page. Based on the damaged page address in the database damage location report, read the link pointers and cell contents of adjacent intact pages, and reconstruct the cell pointer array structure and data record content of the damaged page to obtain a complete SQLite database file; Based on the complete SQLite database file, file reassembly is performed on the file data marked as fragmented in the original data set to obtain a valid data set; A virtual file index is built based on the storage offset, data size, and file type identifier of each file in the valid data set.

7. The method for backing up and restoring iOS device data according to claim 1, characterized in that, The process of confirming the user's data selection list based on the virtual file index and performing secure recovery, returning the data recovery result, includes: Image files marked as JPEG and HEIC formats in the virtual file index are used by the libjpeg-turbo decoding library to generate thumbnails, while the FFmpeg library is used to extract the first frame key image from the MP4 video file to obtain media preview data; Based on the WhatsApp chat history and system SMS files in the virtual file index, perform emoji decoding and timestamp formatting, and sort the contact data by name to display phone and email information to obtain text preview data; Based on the media preview data and the text preview data, the preview content is displayed through the user interface and the user's checkbox selection operation is recorded, along with the path and recovery priority of the selected file, to obtain a data selection list. Based on the data selection list, the selected data is safely recovered, and the data recovery result is returned.

8. The method for backing up and restoring iOS device data according to claim 7, characterized in that, The step of safely recovering the selected data according to the data selection list and returning the data recovery result includes: Extract the path information of the selected file from the data selection list and generate a secure data channel between the iOS device and the local computer; Based on the secure data channel, the selected data is divided into data blocks and each data block is encrypted to obtain securely transmitted data; The securely transmitted data is transferred from the iOS device to the local computer, decrypted block by block, and written to the user-specified directory according to the SQLite database structure of the original file, and the data recovery result is returned.

9. A backup and restore system for iOS device data, characterized in that, A method for backing up and restoring iOS device data as described in any one of claims 1-8, comprising: The acquisition module is used to perform SSL certificate verification and EscrowBag key authentication on the iOS device to obtain device authentication information. Based on the device authentication information, the module performs Bundle path parsing and table structure identification on the WhatsApp ChatStorage database, system SMS database, and Photos database in the iOS device to obtain a data path list. The storage partition scanning module is used to perform parallel scanning of the iOS device storage partitions based on the data path list, including APFS file system B-Tree traversal, NAND flash memory page reading, and SQLite WAL log parsing, to obtain the original data set. The integrity assessment module is used to perform integrity assessment based on the original data set, perform cell reconstruction on damaged SQLite pages and signature matching repair on fragmented files to obtain a valid data set, and construct a virtual file index based on the valid data set; The secure recovery module is used to confirm the user's data selection list based on the virtual file index and perform secure recovery, returning the data recovery result.

Images