iOS backup password cracking and data recovery system
By employing a multi-layered progressive verification and dynamic threshold prediction model, combined with an online feature database and cracking algorithm matching, the problems of iOS backup file tampering and encryption algorithm updates were solved, enabling secure cracking and reliable recovery of iOS backup files.
Patent Information
- Application Number
- CN202511279468.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-09
- Publication Date
- 2025-11-18
- Estimated Expiration
- 2045-09-09
AI Technical Summary
Existing technologies, when cracking iOS backup files, fail to effectively confirm whether the backup files have been tampered with, resulting in restored data that does not reflect the true situation, may contain viruses or malware, and cannot adapt to Apple's updated system encryption algorithms.
It employs a multi-layered progressive verification module, an online feature database, a dynamic threshold estimation module, and a cracking matching module. It ensures the integrity of backup files through file ID, size, and hash verification, and combines dynamic thresholds and cracking algorithm matching models to achieve secure cracking and recovery of backup files.
Ensure the authenticity and recoverability of backup files, avoid false positives caused by over-verification, be compatible with the new iOS system encryption algorithm, and improve cracking efficiency and data recovery reliability.
Smart Images

Figure CN120803818B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data security and recovery technology, specifically to an iOS backup password cracking and data recovery system. Background Technology
[0002] Chinese patent CN102750495A discloses a system for cracking and restoring encrypted backup files on an iPhone, comprising: a GUI module, a password cracking module, a backup file restoration module, and a keychain viewing module. The GUI module is a graphical user interface for user interaction with the device; the password cracking module, associated with the GUI module, is used to crack the encrypted file and obtain the cracked password; the backup file restoration module receives the cracked password and restores the encrypted backup file; and the keychain viewing module receives the cracked password and views the data stored in the keychain.
[0003] With the increasing security of iOS systems, backup files typically employ high-strength encryption algorithms (such as AES-256 combined with PBKDF2 key derivation). If users forget their backup passwords, important data will be inaccessible. Current technologies, in obtaining critical information from encrypted backup files to provide a basis for subsequent cracking, often neglect to verify whether the backup file has been tampered with before directly performing the cracking operation. This means that if the backup has been tampered with (e.g., critical documents have been replaced, transaction records have been deleted), the restored data will not reflect the true situation, rendering the password cracking result invalid. Furthermore, maliciously tampered backups may contain viruses, malicious plugins, or backdoor programs. Restoring such backups could allow remote control of the device, further stealing current device data (such as banking information, biometric data), or causing device crashes, data loss, and other problems. Summary of the Invention
[0004] To address the aforementioned technical problems, the present invention aims to provide an iOS backup password cracking and data recovery system, including a cloud platform. The cloud platform has a file input module, a multi-layer progressive verification module, an online feature database, a dynamic threshold estimation module, a cracking matching module, and a cracking feedback module.
[0005] The file input module is used to receive backup file packages provided by users, extract the metadata baseline information of the backup file packages, and perform core file determination on each file in the backup file packages;
[0006] The multi-layer progressive verification module is used to perform FileID verification, Size verification, hash verification and final fault tolerance verification on the backup file package based on metadata baseline information, and obtain the multi-layer progressive verification results of the backup file package;
[0007] The online feature database is used to acquire and store the effective backup pass rate and abnormal backup interception rate corresponding to the labeled samples of different backup characteristics under different dynamic threshold sets, as well as the cracking results and efficiency coefficients corresponding to the labeled samples of different backup characteristics under different cracking algorithms.
[0008] The dynamic threshold prediction module is used to build a dynamic threshold prediction model based on an online feature database and output the dynamic threshold set in the final fault tolerance verification process.
[0009] The cracking and matching module is used to build a cracking algorithm matching model based on an online feature database. When the multi-level progressive verification of the backup file package passes, the cracking algorithm of the backup file package is output.
[0010] The cracking feedback module is used to crack and recover backup file packages based on cracking algorithms, and provides online feedback on the cracking results and file recovery results.
[0011] Furthermore, the metadata baseline information includes a backup global checksum (the top-level hash value of the entire backup file package, generated based on the hash calculation of all files in the file-level metadata list) and a file-level metadata list. The file-level metadata list includes entry information for all files in the backup file package. The entry information for each file includes: FileID: a unique identifier for the file (e.g., abc123...), Hash: the SHA-1 hash value of the file content (used to verify file integrity), Size: the original size of the file (unencrypted state), and ProtectionClass: the file encryption level (e.g., Complete indicates full encryption).
[0012] Furthermore, the process of determining core documents includes:
[0013] The function attributes of each file in the file-level metadata list are obtained. The ProtectionClass and function attributes of each file in the file-level metadata list are selected as evaluation indicators. The user sets file recovery constraints, and the indicator weights of the evaluation indicators are set according to the file recovery constraints. The membership matrix of each file to the preset importance level is obtained through fuzzy comprehensive evaluation.
[0014] The importance level of each file is obtained based on the membership matrix and indicator weights. An importance level threshold is preset, and files with an importance level greater than the importance level threshold are marked as core files.
[0015] Furthermore, the process of performing FileID and Size verification on the backup file package based on metadata baseline information includes:
[0016] Based on the file-level metadata list, the backup file package is traversed for each file's FileID. If the backup file package is missing a FileID included in the file-level metadata list, it is determined whether the file corresponding to the missing FileID is a core file. If so, the backup is determined to be corrupted, and the user is prompted to resubmit the backup file package. If not, the file corresponding to the missing FileID is marked as an abnormal file.
[0017] Subsequently, the size of each non-abnormal file in the backup file package is traversed based on the file-level metadata list. The size of each non-abnormal file in the backup file package is compared with the size of each non-abnormal file in the file-level metadata list to obtain the size deviation value of each non-abnormal file. A preset deviation threshold is set (based on the historical size deviation value pattern, such as ±1024 bytes). If the size deviation value of a non-abnormal file in the backup file package is greater than the deviation threshold, the non-abnormal file is marked as an abnormal file. It is then determined whether the abnormal file is a core file. If it is, the backup is determined to be corrupted, and the user is prompted to resubmit the backup file package. If not, a hash verification is performed.
[0018] Furthermore, the process of performing hash verification includes:
[0019] Read the encrypted content of each non-abnormal file (named by FileID) in the backup file package (at this time, the password has not been cracked, only the original encrypted data is verified), obtain the SHA-1 hash value of the encrypted content, retrieve the corresponding hash of each non-abnormal file in the file-level metadata list based on the FileID of each non-abnormal file, and compare the consistency of the SHA-1 hash value of each non-abnormal file with the corresponding hash in the file-level metadata list. If there is a non-abnormal file whose SHA-1 hash value is inconsistent with the corresponding hash in the file-level metadata list, determine whether the non-abnormal file is a core file. If it is, determine that the backup is corrupted. If not, mark the non-abnormal file as an abnormal file.
[0020] Furthermore, the final fault tolerance verification process includes:
[0021] The percentage of abnormal files in the backup file package is N%, and the percentage of the total size of abnormal files in the backup file package is S%. The encrypted content of each file (named by FileID) in the backup file package is read (the password has not yet been cracked, only the original encrypted data is verified). The encrypted content is hashed to obtain the SHA-1 hash value of all non-abnormal files in the backup file package. The SHA-1 hash values of all non-abnormal files are sorted according to the FileID of all non-abnormal files and concatenated into a string to obtain the hash of the string.
[0022] A dynamic threshold set is obtained, including the dynamic percentage threshold for abnormal files, the dynamic percentage threshold for abnormal file size, and the hash string difference threshold. If N% is less than the dynamic percentage threshold for abnormal files and S% is less than the dynamic percentage threshold for abnormal file size, the hash of the string is compared with the global backup check value to obtain the hash string difference. It is then determined whether the hash string difference is less than the hash string difference threshold. If it is less, it means that the entire backup file list and metadata have not been tampered with (ensuring that no files have been added / deleted or metadata has been modified). In this case, the multi-level progressive verification is considered to have passed, all files exist, sizes match, and hash chains are complete, indicating that the backup has not been tampered with, and the subsequent cracking process can proceed. If it is not less, it means that the entire backup has been tampered with (e.g., malicious programs have added files or modified metadata baseline information). In this case, the multi-level progressive verification is considered to have failed, and the user is prompted to provide a new backup.
[0023] If N% is greater than or equal to the dynamic percentage threshold for abnormal files or S% is greater than or equal to the dynamic percentage threshold for abnormal file size, the multi-level progressive verification is deemed to have failed, and the user is prompted to provide a new backup.
[0024] Furthermore, the process of obtaining the effective backup pass rate and abnormal backup interception rate corresponding to the labeled samples with different backup characteristics under different dynamic threshold sets, as well as the cracking results and efficiency coefficients corresponding to the labeled samples with different backup characteristics under different cracking algorithms, includes:
[0025] Construct a labeled sample set, extract features from the labeled sample set, and obtain the backup characteristics corresponding to different labeled samples in the labeled sample set. The backup characteristics include backup attribute features, anomaly features, and hash difference features.
[0026] Several different dynamic threshold sets are constructed. Based on the different dynamic threshold sets, multi-level progressive verification is performed on the labeled samples with different backup characteristics in the labeled sample set. The multi-level progressive verification results corresponding to the labeled samples with different backup characteristics under different dynamic threshold sets are obtained. Based on the multi-level progressive verification results, the effective backup pass rate (the probability that a normal backup sample is not misjudged as failing the hash check) and the abnormal backup interception rate (the probability that an abnormal backup sample is judged as failing the hash check) corresponding to the labeled samples with different backup characteristics under different dynamic threshold sets are obtained.
[0027] Different cracking algorithms are called from the preset algorithm library to crack labeled samples with different backup characteristics. The cracking results (successful cracking, failed cracking) and efficiency coefficients (obtained from cracking time and cracking resource consumption) corresponding to labeled samples with different backup characteristics under different cracking algorithm conditions are obtained.
[0028] Furthermore, the process of constructing a dynamic threshold prediction model based on an online feature database and outputting the dynamic threshold set in the final fault tolerance verification process includes:
[0029] The effective backup pass rate and abnormal backup interception rate corresponding to the labeled samples of different backup characteristics under different dynamic threshold sets in the online feature database are used as the training set and the validation set, with the training set (80%) and the validation set (20%). Five-fold cross-validation is used to avoid overfitting. The model parameters (such as learning rate, batch size, and regularization coefficient) are optimized with the objective function of maximizing the sum of the effective backup pass rate and the abnormal backup interception rate. The dynamic threshold prediction model is tested through the validation set until it meets the preset requirements, and the trained dynamic threshold prediction model is output.
[0030] The current backup file package is verified by feature extraction to obtain its backup characteristics. These characteristics are then input into the dynamic threshold prediction model, which outputs the dynamic threshold set corresponding to the current backup file package.
[0031] Furthermore, the process of constructing a cracking algorithm matching model based on an online feature database and outputting the cracking algorithm for the backup file package includes:
[0032] A cracking algorithm matching model is constructed based on an online feature database. The cracking results and efficiency coefficients corresponding to the labeled samples with different backup characteristics under different cracking algorithm conditions in the online feature database are used as training data. The objective function of the cracking algorithm matching model is set based on the cracking results and efficiency coefficients. The cracking algorithm matching model is trained using the training data to obtain the trained cracking algorithm matching model.
[0033] The backup characteristics of the backup file package are input into the cracking algorithm matching model, and the cracking algorithm of the backup file package is output according to the cracking algorithm matching model (e.g., for iOS16 backup with a high number of iterations, the PBKDF2 brute-force algorithm is given priority).
[0034] Furthermore, the process of cracking and recovering backup file packages based on cracking algorithms, and providing online feedback on the cracking and recovery results, includes:
[0035] The non-abnormal files in the backup file package are cracked using the cracking algorithm of the backup file package. The cracking result and efficiency coefficient are obtained (if the cracking result is a failure, the efficiency coefficient is zero by default). If the cracking result is a success, a decryption key is generated. The non-abnormal files in the backup file package are decrypted using the decryption key to generate an image recovery file of the non-abnormal files in the backup file package.
[0036] The image recovery file of the non-abnormal file in the backup file package is sent to the user. The user judges the image recovery file and generates a judgment result, which includes valid backup and abnormal backup.
[0037] The cracking results, efficiency coefficients, judgment results, backup characteristics, and dynamic threshold sets corresponding to the cracking algorithms of the backup file packages are uploaded to the online feature database. The online feature database updates the effective backup pass rate corresponding to the labeled samples of different backup characteristics under different dynamic threshold sets in real time according to the judgment results. The dynamic threshold prediction model and the cracking algorithm matching model periodically obtain the effective backup pass rate and abnormal backup interception rate corresponding to the labeled samples of different backup characteristics under different dynamic threshold sets in the online feature database, as well as the cracking results and efficiency coefficients corresponding to the labeled samples of different backup characteristics under different cracking algorithms, and update the model parameters accordingly.
[0038] Compared with the prior art, the beneficial effects of the present invention are:
[0039] 1. The multi-layered progressive verification module is essentially designed to ensure the authenticity and recoverability of critical user data, rather than pursuing zero file loss. The loss of non-core files (such as cache and redundant resources) typically does not affect password cracking (which relies on encrypted parameter files) or core data recovery (which relies on databases such as address books and SMS messages). Therefore, the logic of "core priority + fault tolerance verification" applies: the integrity of core files is the bottom line—if core files are missing or tampered with, backups lose their recovery value and must be terminated; the loss of non-core files is optional—through dynamic hash chain reconstruction and risk quantification, losses are tolerated within a controllable range, prioritizing the recovery process of core data.
[0040] This strategy avoids misjudging valid backups due to overly strict verification, while ensuring the reliability of recovery results through core data verification. It balances rigor and practicality, achieving the goal of maximizing the value of data recovery under controllable risks.
[0041] 2. Apple may update its encryption algorithm with each generation of iOS (e.g., from SHA-1 to SHA-256). Existing technologies require manual upgrades of the algorithm library, resulting in compatibility issues. This invention uses an online feature database to record the cracking results of the new algorithm on various backups in real time, and dynamically updates the preset algorithm library based on user feedback. This significantly shortens the system's adaptation cycle to new iOS versions, ensuring that cracking capabilities are synchronized with system upgrades. Attached Figure Description
[0042] Figure 1 This is a schematic diagram of the iOS backup password cracking and data recovery system according to an embodiment of this application. Detailed Implementation
[0043] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0044] like Figure 1 As shown, the iOS backup password cracking and data recovery system includes a cloud platform. The cloud communication connection includes a file input module, a multi-layer progressive verification module, an online feature database, a dynamic threshold estimation module, a cracking matching module, and a cracking feedback module.
[0045] The file input module is used to receive backup file packages provided by users, extract the metadata baseline information of the backup file packages, and perform core file determination on each file in the backup file packages;
[0046] The multi-layer progressive verification module is used to perform FileID verification, Size verification, hash verification and final fault tolerance verification on the backup file package based on metadata baseline information, and obtain the multi-layer progressive verification results of the backup file package;
[0047] The online feature database is used to acquire and store the effective backup pass rate and abnormal backup interception rate corresponding to the labeled samples of different backup characteristics under different dynamic threshold sets, as well as the cracking results and efficiency coefficients corresponding to the labeled samples of different backup characteristics under different cracking algorithms.
[0048] The dynamic threshold prediction module is used to build a dynamic threshold prediction model based on an online feature database and output the dynamic threshold set in the final fault tolerance verification process.
[0049] The cracking and matching module is used to build a cracking algorithm matching model based on an online feature database. When the multi-level progressive verification of the backup file package passes, the cracking algorithm of the backup file package is output.
[0050] The cracking feedback module is used to crack and recover backup file packages based on cracking algorithms, and provides online feedback on the cracking results and file recovery results.
[0051] It should be further explained that, in the specific implementation process, the file input module allows users to manually import the backup file package (including core files such as .mbdb.manifest), and then extracts the backup root directory file from the backup file package. This file contains the "digital fingerprint" of the entire backup, which is the basis for verification. The backup global verification value and file-level metadata list are extracted from the backup root directory file.
[0052] It should be further explained that, in the specific implementation process, the metadata baseline information includes the backup global checksum (the top-level hash value of the entire backup file package, generated based on the hash calculation of all files in the file-level metadata list) and the file-level metadata list. The file-level metadata list includes entry information for all files in the backup file package. The entry information for each file includes: FileID: unique file identifier (e.g., abc123...), Hash: SHA-1 hash value of the file content (used to verify file integrity), Size: original file size (unencrypted state), and ProtectionClass: file encryption level (e.g., Complete indicates full encryption).
[0053] It should be further explained that, in the specific implementation process, the process of determining the core documents includes:
[0054] The system retrieves the functional attributes of each file in the file-level metadata list, selects the ProtectionClass and functional attributes (including storing all contact information, recording SMS content, call logs and timestamps, storing browser cache, application temporary data, application built-in images, system default ringtones, etc.) of each file in the file-level metadata list as evaluation indicators, sets file recovery constraints by the user (e.g., the user sets "only recover photos and contacts" through the system interface, and the corresponding file type automatically increases the indicator weight), sets the indicator weights of the evaluation indicators according to the file recovery constraints, and obtains the membership matrix of each file to the preset importance level through fuzzy comprehensive evaluation using existing technology;
[0055] The importance level of each file is obtained based on the membership matrix and indicator weights. An importance level threshold is preset, and files with an importance level greater than the importance level threshold are marked as core files.
[0056] It should be further explained that, in the specific implementation process, the process of obtaining the importance level of each document based on the membership matrix and indicator weights includes:
[0057] The fuzzy comprehensive evaluation matrix of the evaluation indicators is obtained by fusing the indicator weights and membership degree matrix of the evaluation indicators through the formula. The membership degree of each document to different importance levels is obtained according to the fuzzy comprehensive evaluation matrix. The importance level with the highest membership degree for each document is selected and the importance level of each document is taken as the importance level of each document.
[0058] The formula is:
[0059] ;
[0060] in, The fuzzy comprehensive evaluation matrix for the evaluation indicators. To evaluate the indicator weights, For the membership matrix, "This indicates that the elements at corresponding positions in the weight matrix and membership matrix of the evaluation index are multiplied together." The weighting parameter is used to balance the weight matrix and membership matrix in the fuzzy comprehensive evaluation matrix used to control the evaluation index.
[0061] It should be further explained that, in the specific implementation process, the process of performing FileID and Size verification on the backup file package based on metadata baseline information includes:
[0062] Based on the file-level metadata list, the backup file package is traversed for each file's FileID. If the backup file package is missing a FileID included in the file-level metadata list, it is determined whether the file corresponding to the missing FileID is a core file. If so, the backup is determined to be corrupted, and the user is prompted to resubmit the backup file package. If not, the file corresponding to the missing FileID is marked as an abnormal file.
[0063] Then, based on the file-level metadata list, the size of each non-abnormal file in the backup file package is traversed. The size of each non-abnormal file in the backup file package is compared with the size of each non-abnormal file in the file-level metadata list to obtain the size deviation value of each non-abnormal file. A preset deviation threshold is set (based on the historical size deviation value pattern, such as ±1024 bytes). If the size deviation value of a non-abnormal file in the backup file package is greater than the deviation threshold, the non-abnormal file is marked as an abnormal file. It is then determined whether the abnormal file is a core file. If it is, the backup is considered corrupted, and the user is prompted to resubmit the backup file package. If not, a hash check is performed.
[0064] It should be further explained that, in the specific implementation process, the hash verification process includes:
[0065] Read the encrypted content of each non-abnormal file (named by FileID) in the backup file package (at this point, the password has not been cracked, only the original encrypted data is verified), obtain the SHA-1 hash value of the encrypted content, retrieve the corresponding hash of each non-abnormal file in the file-level metadata list based on the FileID of each non-abnormal file, and compare the consistency of the SHA-1 hash value of each non-abnormal file with the corresponding hash in the file-level metadata list. If there is a discrepancy between the SHA-1 hash value of a non-abnormal file and the corresponding hash in the file-level metadata list, determine whether the non-abnormal file is a core file. If it is, determine that the backup is corrupted and prompt the user to resubmit the backup file package. If not, mark the non-abnormal file as an abnormal file.
[0066] It should be further explained that, in the specific implementation process, the final fault tolerance verification process includes:
[0067] The percentage of abnormal files in the backup file package is N%, and the percentage of the total size of abnormal files in the backup file package is S%. The encrypted content of each file (named by FileID) in the backup file package is read (the password has not yet been cracked, only the original encrypted data is verified). The encrypted content is hashed to obtain the SHA-1 hash value of all non-abnormal files in the backup file package. The SHA-1 hash values of all non-abnormal files are sorted according to the FileID of all non-abnormal files and concatenated into a string to obtain the hash of the string.
[0068] A dynamic threshold set is obtained, which includes a dynamic percentage threshold for abnormal files, a dynamic percentage threshold for abnormal file sizes, and a hash string difference threshold (the thresholds in this invention are obtained by software simulation based on a large amount of data to get the closest to the real situation; the threshold size is set by those skilled in the art based on the actual situation or obtained by simulation based on a large amount of data). If N% is less than the dynamic percentage threshold for abnormal files and S% is less than the dynamic percentage threshold for abnormal file sizes, the hash of the string is compared with the global verification value of the backup to obtain the hash string difference. It is then determined whether the hash string difference is less than the hash string difference threshold. If it is less, it means that the entire backup file list and metadata have not been tampered with (ensuring that no files have been added / deleted or metadata has been modified), and the multi-level progressive verification is deemed to have passed. All files exist, their sizes match, and the hash chain is complete, indicating that the backup has not been tampered with, and the subsequent cracking process can proceed. If it is not less, it means that the entire backup has been tampered with (e.g., a malicious program has added files or modified the metadata baseline information), and the multi-level progressive verification is deemed to have failed, prompting the user to provide a new backup.
[0069] If N% is greater than or equal to the dynamic percentage threshold for abnormal files or S% is greater than or equal to the dynamic percentage threshold for abnormal file size, the multi-level progressive verification is deemed to have failed, and the user is prompted to provide a new backup.
[0070] The essence of multi-layered progressive verification is to ensure the authenticity and recoverability of critical user data, rather than pursuing "zero missing files." The absence of non-core files (such as cache and redundant resources) usually does not affect password cracking (which relies on encrypted parameter files) or core data recovery (which relies on databases such as address books and SMS messages). Therefore, the system uses a "core priority + fault-tolerant verification" logic:
[0071] The integrity of core files is the "bottom line"—if core files are missing or tampered with, the backup loses its value for recovery and must be terminated;
[0072] The absence of non-core files is "optional"—through dynamic hash chain reconstruction and risk quantification, the absence can be tolerated within a controllable range, while prioritizing the recovery process of core data.
[0073] This strategy avoids misjudging valid backups due to overly strict verification (such as "nothing can be missing"), while ensuring the reliability of recovery results through core data verification. It balances "rigor" and "practicality" and achieves the goal of "maximizing the value of data recovery under controllable risks".
[0074] It should be further explained that, in the specific implementation process, the process of obtaining the effective backup pass rate and abnormal backup interception rate corresponding to the labeled samples with different backup characteristics under different dynamic threshold sets, as well as the cracking results and efficiency coefficients corresponding to the labeled samples with different backup characteristics under different cracking algorithms, includes:
[0075] Construct a labeled sample set, which includes:
[0076] Normal backup sample: Collected 100,000+ real user backup data records (with user authorization), covering different iOS versions (iOS 9 to the latest version), device types (iPhone / iPad), storage capacity (16GB to 1TB), and backup content (including a large number of media files / mainly system data, etc.).
[0077] Abnormal backup sample:
[0078] Non-core file missing samples: generated by manually deleting non-core files such as cache, logs, and redundant media (missing percentages vary from 1% to 50%).
[0079] Core file missing sample: Generated by deleting core files such as Manifest.plist and address book database (simulating fatal missing files).
[0080] Tampering with backup samples: Modifying part of the file content (such as replacing photos or tampering with text messages) and then recalculating the local hash to simulate a malicious tampering scenario.
[0081] Each sample is labeled with two classes of tags (used by the model to learn the "threshold reasonableness"):
[0082] Validity labels: 1 (backup is valid, core data can be fully recovered), 0 (backup is invalid, core data has been tampered with or is missing);
[0083] Risk label: Probability of backup being tampered with (marked by manual audit, e.g., 0.1% is low risk, 20% is high risk);
[0084] Feature extraction is performed on the labeled sample set to obtain the backup characteristics corresponding to different labeled samples in the labeled sample set. The backup characteristics include backup attribute features (basic attributes: iOS version (e.g., 16.5), device model (e.g., iPhone 14), total number of backup files (total_files), total size (total_size), salt length, number of iterations, hash algorithm type; core file ratio: number of core files / total number of files, core file size / total size), anomaly features (the proportion of the number of anomaly files to the total number of files in the labeled sample and the proportion of the total size of the anomaly files to the total size of the labeled sample), and hash difference features (the string edit distance between the hash of the labeled sample string and the global verification value of the backup of the labeled sample).
[0085] Several different dynamic threshold sets are constructed. Based on the different dynamic threshold sets, multi-level progressive verification is performed on the labeled samples with different backup characteristics in the labeled sample set. The multi-level progressive verification results corresponding to the labeled samples with different backup characteristics under different dynamic threshold sets are obtained. Based on the multi-level progressive verification results, the effective backup pass rate (the probability that a normal backup sample is not misjudged as failing the hash check) and the abnormal backup interception rate (the probability that an abnormal backup sample is judged as failing the hash check) corresponding to the labeled samples with different backup characteristics under different dynamic threshold sets are obtained.
[0086] Different cracking algorithms are called from the preset algorithm library to crack labeled samples with different backup characteristics. The cracking results (successful cracking, failed cracking) and efficiency coefficients (obtained from cracking time and cracking resource consumption) corresponding to labeled samples with different backup characteristics under different cracking algorithm conditions are obtained.
[0087] It should be further explained that, in the specific implementation process, the process of building a dynamic threshold prediction model based on an online feature database and outputting the dynamic threshold set in the final fault tolerance verification process includes:
[0088] The effective backup pass rate and abnormal backup interception rate corresponding to the labeled samples of different backup characteristics under different dynamic threshold sets in the online feature database are used as the training set and the validation set, with the training set (80%) and the validation set (20%). Five-fold cross-validation is used to avoid overfitting. The model parameters (such as learning rate, batch size, and regularization coefficient) are optimized with the objective function of maximizing the sum of the effective backup pass rate and the abnormal backup interception rate. The dynamic threshold prediction model is tested through the validation set until it meets the preset requirements, and the trained dynamic threshold prediction model is output.
[0089] The objective function of the dynamic threshold prediction model is:
[0090] ;
[0091] in, The objective function value is used to train the dynamic threshold prediction model (with the objective function value as the maximum requirement). To ensure a high backup success rate, Abnormal backup interception rate;
[0092] Obtain the backup characteristics of the backup file package, input the backup characteristics into the dynamic threshold prediction model, and output the dynamic threshold set corresponding to the current backup file package based on the dynamic threshold prediction model.
[0093] It should be further explained that, in the specific implementation process, the process of constructing a cracking algorithm matching model based on the online feature database and outputting the cracking algorithm in the backup file package includes:
[0094] A cracking algorithm matching model is constructed based on an online feature database. The cracking results and efficiency coefficients corresponding to the labeled samples with different backup characteristics under different cracking algorithm conditions in the online feature database are used as training data. The objective function of the cracking algorithm matching model is set based on the cracking results and efficiency coefficients. The cracking algorithm matching model is trained using the training data to obtain the trained cracking algorithm matching model.
[0095] The objective function of the matching model in the cracking algorithm is:
[0096] ;
[0097] ;
[0098] in, The objective function value is used as the target value (the matching model of the cracking algorithm is trained with the objective function value as the requirement). To crack the result, Efficiency coefficient;
[0099] The backup characteristics of the backup file package are input into the cracking algorithm matching model, and the cracking algorithm of the backup file package is output according to the cracking algorithm matching model (e.g., for iOS16 backup with a high number of iterations, the PBKDF2 brute-force algorithm is given priority).
[0100] It should be further explained that, in the specific implementation process, the process of cracking and recovering the backup file package based on the cracking algorithm, and providing online feedback on the cracking results and file recovery results, includes:
[0101] The non-abnormal files in the backup file package are cracked using the cracking algorithm of the backup file package. The cracking result and efficiency coefficient are obtained (if the cracking result is a failure, the efficiency coefficient is zero by default). If the cracking result is a success, a decryption key is generated. The non-abnormal files in the backup file package are decrypted using the decryption key to generate an image recovery file of the non-abnormal files in the backup file package.
[0102] The image recovery file of the non-abnormal file in the backup file package is sent to the user. The user judges the image recovery file and generates a judgment result, which includes valid backup and abnormal backup.
[0103] The cracking results, efficiency coefficients, judgment results, backup characteristics, and dynamic threshold sets corresponding to the cracking algorithms of the backup file packages are uploaded to the online feature database. The online feature database updates the effective backup pass rate corresponding to the labeled samples of different backup characteristics under different dynamic threshold sets in real time according to the judgment results. The dynamic threshold prediction model and the cracking algorithm matching model periodically obtain the effective backup pass rate and abnormal backup interception rate corresponding to the labeled samples of different backup characteristics under different dynamic threshold sets in the online feature database, as well as the cracking results and efficiency coefficients corresponding to the labeled samples of different backup characteristics under different cracking algorithms, and update the model parameters accordingly.
[0104] The above embodiments are only used to illustrate the technical methods of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical methods of the present invention without departing from the spirit and scope of the technical methods of the present invention.
Claims
1. An iOS backup password cracking and data recovery system, characterized in that, Including the cloud, the cloud communication connection includes a file input module, a multi-layer progressive verification module, an online feature database, a dynamic threshold estimation module, a crack matching module, and a crack feedback module; The file input module receives backup file packages provided by users, extracts the metadata baseline information of the backup file packages, obtains the functional attributes of each file in the file-level metadata list, selects the ProtectionClass and functional attributes of each file in the file-level metadata list as evaluation indicators, sets file recovery constraints according to user settings, sets the indicator weights of the evaluation indicators according to the file recovery constraints, obtains the membership degree matrix of each file with respect to the preset importance level through fuzzy comprehensive evaluation, obtains the importance level of each file according to the membership degree matrix and indicator weights, presets the importance level threshold, and marks files with the corresponding importance level greater than the importance level threshold as core files. The multi-layer progressive verification module is used to perform FileID verification, Size verification, hash verification and final fault tolerance verification on the backup file package based on metadata baseline information, and obtain the multi-layer progressive verification results of the backup file package; An online feature database is used to construct a labeled sample set, extract features from the labeled sample set, and obtain backup characteristics corresponding to different labeled samples in the labeled sample set. The backup characteristics include backup attribute features, anomaly features, and hash difference features. Several different dynamic threshold sets are constructed. Based on the different dynamic threshold sets, multi-level progressive verification is performed on the labeled samples with different backup characteristics in the labeled sample set. The multi-level progressive verification results corresponding to the labeled samples with different backup characteristics under different dynamic threshold sets are obtained. Based on the multi-level progressive verification results, the effective backup pass rate and abnormal backup interception rate corresponding to the labeled samples with different backup characteristics under different dynamic threshold sets are obtained. Different cracking algorithms are called from the preset algorithm library to crack labeled samples with different backup characteristics, and the cracking results and efficiency coefficients of labeled samples with different backup characteristics under different cracking algorithm conditions are obtained. The dynamic threshold prediction module uses the effective backup pass rate and abnormal backup interception rate corresponding to the labeled samples of different backup characteristics under different dynamic threshold sets in the online feature database as the training set and validation set. It optimizes the model parameters with the objective function of maximizing the sum of the effective backup pass rate and the abnormal backup interception rate. The dynamic threshold prediction model is tested through the validation set until it meets the preset requirements, and the trained dynamic threshold prediction model is output. The current backup file package is verified by feature extraction to obtain its backup characteristics. These characteristics are then input into the dynamic threshold prediction model, which outputs the dynamic threshold set corresponding to the current backup file package. The crack matching module is used to build a crack algorithm matching model based on an online feature database. It uses the cracking results and efficiency coefficients of the labeled samples with different backup characteristics under different cracking algorithm conditions in the online feature database as training data. Based on the cracking results and efficiency coefficients, the objective function of the crack algorithm matching model is set. The crack algorithm matching model is trained using the training data to obtain the trained crack algorithm matching model. The backup characteristics of the backup file package are input into the cracking algorithm matching model, and the cracking algorithm of the backup file package is output according to the cracking algorithm matching model. The cracking feedback module is used to crack and recover backup file packages based on cracking algorithms, and provides online feedback on the cracking results and file recovery results.
2. The iOS backup password cracking and data recovery system according to claim 1, characterized in that, The metadata baseline information includes a backup global checksum and a file-level metadata list. The file-level metadata list includes entry information for all files in the backup file package. The entry information for each file includes: FileID, Hash, Size, and ProtectionClass.
3. The iOS backup password cracking and data recovery system according to claim 2, characterized in that, The process of performing FileID and Size verification on backup file packages based on metadata baseline information includes: Based on the file-level metadata list, traverse the FileID of each file in the backup file package. If the backup file package is missing a FileID included in the file-level metadata list, determine whether the file corresponding to the missing FileID is a core file. If it is, determine that the backup is corrupted. If not, mark the file corresponding to the missing FileID as an abnormal file. Then, based on the file-level metadata list, the size of each non-abnormal file in the backup file package is traversed to obtain the size deviation value of each non-abnormal file. A preset deviation threshold is set. If the size deviation value of a non-abnormal file in the backup file package is greater than the deviation threshold, the non-abnormal file is marked as an abnormal file. It is then determined whether the abnormal file is a core file. If it is, the backup is determined to be corrupted. If not, a hash check is performed.
4. The iOS backup password cracking and data recovery system according to claim 3, characterized in that, The process of performing hash verification includes: Read the encrypted content of each non-abnormal file in the backup file package, obtain the SHA-1 hash value of the encrypted content, retrieve the corresponding hash of each non-abnormal file in the file-level metadata list based on the FileID of each non-abnormal file, and compare the consistency of the SHA-1 hash value of each non-abnormal file with the corresponding hash in the file-level metadata list. If the SHA-1 hash value of a non-abnormal file is inconsistent with the corresponding hash in the file-level metadata list, determine whether the non-abnormal file is a core file. If it is, determine that the backup is corrupted; otherwise, mark the non-abnormal file as an abnormal file.
5. The iOS backup password cracking and data recovery system according to claim 4, characterized in that, The final fault tolerance verification process includes: Count the percentage N% of the number of abnormal files in the total number of files in the backup file package and the percentage S% of the total size of abnormal files in the total size of the backup file package. Obtain the SHA-1 hash value of all non-abnormal files in the backup file package. Sort the SHA-1 hash values of all non-abnormal files according to their FileIDs and concatenate them into a string. Obtain the hash of the string. Obtain a dynamic threshold set, which includes the dynamic percentage threshold of abnormal files, the dynamic percentage threshold of abnormal file size, and the hash string difference threshold. If N% is less than the dynamic percentage threshold of abnormal files and S% is less than the dynamic percentage threshold of abnormal file size, then compare the hash of the string with the backup global verification value to obtain the hash string difference. Determine whether the hash string difference is less than the hash string difference threshold. If it is less, then the multi-layer progressive verification is deemed to have passed. If it is not less, then the multi-layer progressive verification is deemed to have failed. If N% is greater than or equal to the dynamic percentage threshold of abnormal files or S% is greater than or equal to the dynamic percentage threshold of abnormal file size, then the multi-level progressive verification is deemed to have failed.
6. The iOS backup password cracking and data recovery system according to claim 5, characterized in that, The process of cracking and recovering backup file packages based on cracking algorithms, and providing online feedback on the cracking and recovery results, includes: The non-abnormal files in the backup file package are cracked using the cracking algorithm of the backup file package. The cracking result and efficiency coefficient are obtained. If the cracking result is successful, a decryption key is generated. The non-abnormal files in the backup file package are decrypted using the decryption key to generate an image recovery file of the non-abnormal files in the backup file package. The image recovery file of the non-abnormal file in the backup file package is sent to the user. The user judges the image recovery file and generates a judgment result, which includes valid backup and abnormal backup. Upload the cracking results, efficiency coefficients, judgment results, backup characteristics, and dynamic threshold sets corresponding to the cracking algorithm of the backup file package to the online feature database.
Citation Information
Patent Citations
System for cracking and restoring iPhone encrypted backup files
CN102750495A
A partial backup restoration method and device for iOS data
CN109669813A