Multi-mode one-key destruction method based on OpenHarmony system

Abstract

The present invention belongs to the field of data destruction technology, specifically a multi-mode one-key destruction method based on the OpenHarmony system, including: Step S0: the server registers the system destruction service to SAMgr through the Binder driver; the client remotely calls the server through the proxy object; Step S1: the user issues a call request through the client, the proxy object encapsulates the call request as a message, and passes it to the server through the Binder driver; Step S2: the server performs the corresponding system destruction operation through the system destruction service and obtains the processing result; Step S3: the server returns the processing result to the proxy object; Step S4: the proxy object returns the processing result to the client. Through the above scheme, users can dynamically match the destruction algorithm according to parameters to meet the destruction requirements of different scenarios. Compared with the fixed destruction mode, the destruction strategy of the present invention is more flexible and intelligent.

Description

Technical Field

[0001] The present invention belongs to the technical field of data destruction, and in particular is a multi-mode one-key destruction method based on the OpenHarmony system. Background Art

[0002] With the popularization of smart devices and the Internet of Things, device management and data security issues are becoming increasingly prominent. Especially in the event of device failure and privacy leakage, how to efficiently and securely handle device data has become an important issue that needs to be addressed. The one-click destruction function of the operating system can quickly and thoroughly erase all data on the hard drive (personal information, business secrets, and other sensitive content). This effectively prevents data from being recovered and used by criminals after the device is discarded or transferred, thereby protecting personal privacy and corporate interests. However, currently in the OpenHarmony system, there is no convenient and efficient one-click data destruction method. Existing data destruction solutions have technical problems such as complex operation, high time and resource consumption, and irreversibility. Therefore, how to implement a flexible, customized, fast, convenient, safe and reliable data destruction solution in the OpenHarmony system has become the key to improving system security and user experience. Summary of the Invention

[0003] To solve the above technical problems, the present invention discloses a multi-mode one-key destruction method based on the OpenHarmony system. It can not only quickly and thoroughly erase and destroy key data through the designed algorithm, but also customize appropriate destruction strategies according to the actual needs of users, ensuring the destruction effect while improving the reuse value of the equipment, protecting user privacy security and system stability.

[0004] The present invention is based on the multi-mode one-key destruction method of the OpenHarmony system, comprising the following steps:

[0005] Step S0: The server registers the system destruction service to the SAMgr of the OpenHarmony system through the Binder driver; the client remotely calls the server through the proxy object;

[0006] Step S1: The user sends a call request through the client, the proxy object encapsulates the call request into a message, and passes it to the server through the Binder driver;

[0007] Step S2: The server performs the corresponding system destruction operation through the system destruction service based on the call request and obtains the processing result;

[0008] Step S3: The server returns the processing result to the proxy object;

[0009] Step S4: The proxy object returns the processing result to the client.

[0010] A further improvement of the present invention is that the call request includes a destruction mode and a destruction parameter; the destruction mode is the destruction of the entire device or the destruction of some files;

[0011] The step S2 comprises the following steps:

[0012] Step S21: The server determines the destruction mode based on the call request. If the destruction mode is complete destruction, the server inputs the destruction parameters into the matcher to perform a quick destruction algorithm or a full destruction algorithm match to destroy the entire device's data and obtain the processing result. If the destruction mode is partial file destruction, the server proceeds to step S22 after the client selects the files to be destroyed.

[0013] Step S22: The server determines whether the file to be destroyed is an identification file. If so, the server marks the file to be destroyed as a first file to be destroyed. The server destroys the data of the first file to be destroyed using an identification destruction algorithm and obtains a processing result. If the file to be destroyed is not an identification file, the server marks the file to be destroyed as a second file to be destroyed and then proceeds to step S23.

[0014] Step S23: The server inputs the destruction parameter into the matcher to perform matching with the quick destruction algorithm or the full destruction algorithm to destroy the data of the second file to be destroyed, and obtains a processing result.

[0015] A further improvement of the present invention is that the destruction parameters include destruction sufficiency and destruction urgency; the server sets a sufficiency threshold;

[0016] In step S21, the server inputs the destruction parameters into the matcher to match the quick destruction algorithm or the full destruction algorithm to destroy the data of the entire device. The process is as follows:

[0017] Step A0: The matcher compares the destruction sufficiency with the sufficiency threshold. If the destruction sufficiency is equal to the sufficiency threshold, the matcher directly returns to the first destruction count and proceeds to step A2. If the destruction sufficiency is less than the sufficiency threshold, the matcher proceeds to step A1.

[0018] If the degree of destruction is greater than the degree of destruction threshold, the second destruction times are returned based on the second destruction formula of the matcher, and then step A2 is entered;

[0019] Step A1: The matcher compares the degree of destruction sufficiency with the degree of destruction urgency. If the degree of destruction sufficiency is greater than or equal to the degree of destruction urgency, the matcher directly returns the first destruction count and proceeds to step A2. If the degree of destruction sufficiency is less than the degree of destruction urgency, the matcher returns the destruction step size based on the first destruction formula of the matcher and proceeds to step A3.

[0020] Step A2: The matcher matches all destruction algorithms to destroy the data on the entire machine and determines the result. If the data destruction on the entire machine is successful, the result is "destruction success." If the data destruction on the entire machine fails, the result is "destruction failure," and a log corresponding to the destruction failure is obtained.

[0021] Step A3: The matcher matches the fast destruction algorithm to destroy the data of the entire machine and determines the processing result; if the data destruction of the entire machine is successful, the processing result is destruction success; if the data destruction of the entire machine fails, the processing result is destruction failure, and the corresponding log of destruction failure is obtained.

[0022] A further improvement of the present invention is that the rapid destruction algorithm refers to performing a write-0 operation on the data of the entire machine or the data of the second file to be destroyed with the destruction step length as an interval;

[0023] The complete destruction algorithm refers to performing a write-0 operation on all data of the entire machine or the data of the second file to be destroyed with a first destruction number of times or a second destruction number of times.

[0024] A further improvement of the present invention is that the first destruction formula is: ;

[0025] The second destruction formula is: ;

[0026] Among them, s represents the degree of destruction sufficiency, u represents the degree of destruction urgency, Indicates the destruction step length; Indicates the second destruction count.

[0027] A further improvement of the present invention is that in step S22, before the server destroys the first file to be destroyed through the identification destruction algorithm, it first performs user authentication. If the user authentication is successful, the identification algorithm database of the OpenHarmony system outputs the data of the first file to be destroyed, and the server destroys the data of the first file to be destroyed based on the identification destruction algorithm.

[0028] A further improvement of the present invention is that the identification destruction algorithm refers to repeatedly writing 0 operations on the data of the first file to be destroyed.

[0029] Beneficial effects of the present invention:

[0030] 1. The OpenHarmony system based on this destruction method has a higher level of security than systems that rely on traditional hard destruction mechanisms (such as Windows).

[0031] 2. The OpenHarmony system-based destruction method dynamically adapts the destruction algorithm based on user-entered destruction urgency u and destruction sufficiency s, meeting destruction requirements in different scenarios. Compared to the fixed destruction modes of other systems (such as Windows), this invention's destruction strategy is more flexible and intelligent, achieving an optimal balance between destruction speed and thoroughness. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 A schematic diagram of the flow of the system call interface of the present invention;

[0033] Figure 2 A schematic diagram of communication between the client and the server of the present invention;

[0034] Figure 3 A schematic diagram of the process of partial file destruction according to the present invention;

[0035] Figure 4 This is a schematic diagram of the process of destroying the entire device according to the present invention;

[0036] Figure 5 Schematic diagram of the matching device of the present invention. DETAILED DESCRIPTION

[0037] The following is a clear and complete description of the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings in the embodiments of the present invention. In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention can also be implemented in other ways different from those described herein, and those skilled in the art can make similar generalizations without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0038] The present invention discloses a multi-mode one-key destruction method based on the OpenHarmony system. It can not only quickly and thoroughly erase and destroy key data through a designed algorithm, but also customize a suitable destruction strategy according to the actual needs of the user, ensuring the destruction effect while improving the reuse value of the equipment, protecting user privacy and security and system stability.

[0039] To address the data destruction needs of the OpenHarmony system in various scenarios, this paper designs a multi-mode, one-click destruction method based on the OpenHarmony system. This method is implemented using the OpenHarmony system's system services and provides a corresponding system interface. When a user invokes the server-side system destruction service through the client UI or system commands, the server executes the corresponding destruction operation.

[0040] The multi-mode one-click destruction method of the present invention involves a client, a system call interface, a server, and a destruction service interface. The client communicates with the server through the system call interface, and the server performs the system destruction service by calling the destruction service interface. The system destruction service is registered in the SAMgr of the OpenHarmony system.

[0041] 1. System call interface

[0042] This invention first provides a system call interface for the upper-level UI (client), aiming to provide users with a convenient and intuitive operation method, supporting one-click destruction of data on the entire device or partial files. By encapsulating system commands, the system call interface allows users to invoke the destruction service through the client's graphical user interface (UI) or command line tool, ensuring simple and efficient operation.

[0043] 1.1 The system call interface supports the following functions:

[0044] (1) Destroy the entire system (whole device destruction): Users can choose to destroy all data in the device with one click, ensuring that no sensitive information is leaked when the device is transferred or discarded; the device refers to the device installed with the OpenHarmony system.

[0045] (2) Destroy some files (partial file destruction): Users can choose to destroy specified files or folders (files to be destroyed), which is suitable for scenarios where only part of the data needs to be destroyed.

[0046] (3) Destruction parameter configuration: Users can configure the degree of urgency and adequacy of destruction through the UI interface. The server of the OpenHarmony system automatically matches the corresponding destruction algorithm based on the destruction parameters.

[0047] 1.2 System call interface calling method

[0048] The system call interface supports two calling methods:

[0049] (1) Graphical User Interface: Users select the destruction mode, configure the destruction parameters, and perform the destruction operation through the client UI interface.

[0050] (2) Command line tool: Developers or advanced users can directly call the destruction function through the command line tool.

[0051] 1.3 System call interface call example

[0052] The following is a specific design example of the system call interface:

[0053] (1) Destroy designated files

[0054] Users can destroy the specified files by running the following command:

[0055] oh_destroy -f / --file <file path> -u <urgency> -s <destruction sufficiency>

[0056] Destruction parameter description:

[0057] -f or --file: means destroying the specified file or folder.

[0058] <File path>: The path of the file to be destroyed.

[0059] -u: Indicates the urgency of destruction. A larger value means the destruction operation needs to be completed faster.

[0060] -s: Indicates the degree of destruction. A larger value indicates a more thorough destruction operation.

[0061] (2) Destroy the entire system (the entire machine's data)

[0062] The user can destroy the entire system with the following command:

[0063] oh_destroy -a / --all -u <urgency> -s <destruction sufficiency>

[0064] Destruction parameter description:

[0065] -a or --all: means destroying the entire system (all data on the machine).

[0066] -u and -s: Same as above, indicating the urgency of destruction and the sufficiency of destruction respectively.

[0067] (3) Return value

[0068] After the system call interface is completed, the server will return the processing result:

[0069] succeeded: indicates that the destruction is successful.

[0070] failed: indicates that the destruction failed. Users can troubleshoot based on the returned error information (log).

[0071] 1.4 The system call interface implementation process is as follows: Figure 1 As shown,

[0072] (1) Destruction mode selection: Users can select the destruction mode through the drop-down menu of the client, including two destruction modes: whole machine destruction and partial file destruction.

[0073] (2) File selection: In partial file destruction mode, users can select files to be destroyed through the file browser.

[0074] (3) Destruction parameter configuration: Users can configure the degree of urgency and adequacy of destruction through the slider or input box.

[0075] (4) Execute button: After the user clicks the "Execute Destruction" button, the server will execute the destruction operation according to the configured destruction parameters.

[0076] (5) Operation feedback: After the destruction operation is completed, the client UI interface will display the processing result (destruction success or destruction failure), and provide detailed log information when the destruction fails.

[0077] 2. System Destruction Service

[0078] The system destroy service is one of the core components that implements the multi-mode, one-click destroy functionality in this invention. The system destroy service (Destroy_SA) communicates with the system call interface via IPC (inter-process communication). IPC communication uses a client-server model, where the client process acquires a proxy object (Proxy) from the server process to achieve inter-process data communication.

[0079] In IPC communication, the client process interacts with the server process through proxy objects to read and write data and execute destruction operations. The system destruction service (Destroy_SA) encapsulates the underlying destruction logic and provides a concise C / C++ interface that developers can directly call to implement destruction functions. In addition, the command-line tool (oh_destroy) further simplifies user operations, allowing users to trigger destruction operations with a simple command, improving the system's ease of use and flexibility.

[0080] 2.1 System destruction service implementation process:

[0081] 2.11 Initialize system destruction service (Destroy_SA)

[0082] The system destruction service (Destroy_SA) is started by importing the destroy_sa.json configuration file and executing the system / bin / sa_main program. The sa_main program initializes the configuration of the Destroy_SA service, including key information such as the service ID and process name, based on the destruction parameters in the json configuration file.

[0083] 2.12 Implementation of the Destroy Service Interface of the System Destroy Service (Destroy_SA)

[0084] The destruction service interface encapsulates the destruction operation through C / C++ functions for system call interfaces (such as the command line tool oh_destroy). The following is the specific design of the destruction service interface:

[0085] (1) Destroy designated files (files to be destroyed)

[0086] int DestroyFile(const char filePath,int urgency, int sufficient);

[0087] Destruction parameter description:

[0088] filePath: The path of the file to be destroyed.

[0089] urgency: The urgency of destruction. A larger value indicates that the destruction operation needs to be completed faster.

[0090] sufficient: The degree of destruction. A larger value indicates a more thorough destruction operation.

[0091] Return value:

[0092] Return 0 if the destroy operation is successful.

[0093] A non-zero return value indicates that the destroy operation failed. The error code can be used to troubleshoot the problem.

[0094] (2) Destroy the entire system (whole machine destruction)

[0095] int DestroySystem(int urgency, int sufficient);

[0096] Destruction parameter description:

[0097] The terms urgency and sufficient are the same as above, indicating the urgency and sufficiency of destruction respectively.

[0098] Return value:

[0099] Return 0 if the destroy operation is successful.

[0100] A non-zero return value indicates that the destroy operation failed. The error code can be used to troubleshoot the problem.

[0101] 2.13 Start the Destroy_SA service

[0102] The Destroy_SA service interface is encapsulated into the libdestoryservice.z.so dynamic library file. The sa_main program parses the process name and loads the libdestoryservice.z.so dynamic library file corresponding to the service. It then waits for the System Ability Manager (SAMgr) to start the service and stores the relevant information of Destroy_SA in the System Ability Manager, completing the registration of the system destruction service.

[0103] 2.14 Communication Process

[0104] In the OpenHarmony system, the server process registers services with SAMgr through the Binder driver. The client process, in turn, queries SAMgr through the Binder driver and obtains the server's proxy object. The client initiates a remote call through the proxy object. The Binder driver is responsible for passing the call request and parameters to the server and returning the processing results to the client. The following is a detailed communication process:

[0105] (1) Server registration service

[0106] The server-side process registers the service-related information (such as service ID, interface description, etc.) to SAMgr through the Binder driver; SAMgr is responsible for managing all registered system services and providing interfaces for clients. Figure 2 As shown, Figure 2 Proxy represents the service requester (client), and Stub represents the service provider (server).

[0107] (2) The client obtains the proxy object

[0108] When a client process needs to communicate with a server, it first queries the SAMgr through the Binder driver for a proxy object for the target service. The SAMgr returns the proxy object to the client. This proxy object has the same interface as the server, and the client can call the server through the proxy object.

[0109] (3) The client initiates a remote call

[0110] When a client calls a proxy object, the proxy object encapsulates the call request and parameters into a Binder message and sends it to the server through the Binder driver. The Binder driver then passes the call request and parameters to the server. After receiving the call request, the server executes the corresponding processing logic and returns the processing results to the proxy object through the Binder driver. Finally, the proxy object returns the server's processing results to the client.

[0111] 2.2 Destruction Mode

[0112] Considering that different users have different actual needs for data destruction and specific destruction scenarios, this paper has designed a set of destruction modes, including partial file destruction and complete device destruction. The specific design is as follows:

[0113] 2.21 Destruction of some documents

[0114] Partial file destruction securely destroys user-specified files. The core design of this destruction mode is to match the destruction algorithm with the user-entered destruction parameters, thereby achieving complete destruction of user-specified files.

[0115] like Figure 3 As shown, the process of partial file destruction can be divided into the following steps:

[0116] (1) User input: The user inputs the files to be destroyed through the client or command line tool; and specifies the degree of urgency and thoroughness of destruction. These two destruction parameters represent the urgency and thoroughness of the destruction operation, respectively.

[0117] (2) Destruction service interface call: The client or command line tool passes the path of the file to be destroyed, the degree of urgency of destruction, and the degree of completeness of destruction input by the user to the destruction service interface.

[0118] (3) Destruction algorithm matching: After receiving the user input, the destruction service interface on the server side starts processing the destruction request and matches the destruction algorithm through the matcher.

[0119] 2.22 The entire machine is destroyed

[0120] Complete device destruction is designed to completely destroy critical data blocks predefined by the OpenHarmony system, ensuring that all sensitive data on the device running the OpenHarmony system cannot be recovered. This mode's core design relies on matching a destruction algorithm with two key destruction parameters entered by the user: destruction urgency and destruction adequacy (full-text inspection), thereby achieving complete destruction of the entire device's data.

[0121] like Figure 4 As shown, the process of destroying the entire machine can be divided into the following steps:

[0122] (1) User input: The user inputs the degree of urgency and thoroughness of destruction through the upper-layer application (client) or command line tool. These two destruction parameters represent the urgency and thoroughness of the destruction operation, respectively.

[0123] (2) Destruction service interface call: The upper-layer application (client) or command-line tool passes the degree of urgency and adequacy of destruction (destruction parameters) to the destruction service interface.

[0124] (3) Destruction algorithm matching: After the destruction service interface receives user input, it starts processing the destruction request and matches the destruction algorithm through the matcher.

[0125] 2.3 Destruction Algorithm

[0126] The destruction algorithms mainly include quick destruction algorithm, identification destruction algorithm and total destruction algorithm.

[0127] 2.31 Fast Destruction Algorithm

[0128] The rapid destruction algorithm writes zeros to the binary data of the entire device or the file to be destroyed at specified intervals, rather than writing them entirely. This method destroys the integrity of the file rather than the entire file. Compared to the full destruction algorithm, the rapid destruction algorithm can quickly destroy a large number of files within a limited time, thus shortening the destruction process.

[0129] The specific process of the rapid destruction algorithm is as follows:

[0130] (1) Determine the destruction step length: Determine the destruction step length K based on the destruction parameters;

[0131] (2) Destroy the data of the file or the entire machine to be destroyed according to the destruction step length using a random array of Gaussian distribution with a center of destruction step length K and a divergence of N (N < K / 5); for a file of a specified length, use the quotient of the number of bytes in the file and K as the specified number, generate a random array according to a Gaussian distribution with a center of K and a divergence of N (N < K / 5), and then write zeros to the specified location of the data of the file or the entire machine to be destroyed according to this random array. The divergence N is noise.

[0132] 2.32 Identity Destruction Algorithm

[0133] The core of the identification destruction algorithm is to maintain a user-defined identification algorithm database. After using a specific identification command, the user can add the user-specified identification file to the identification algorithm database. When the identification destruction algorithm is triggered, the system first reads the identification file from the identification algorithm database and repeatedly writes zeros to the user-specified identification file. This ensures that the user's identification file is completely destroyed even if the destruction process is incomplete or forcibly interrupted. The identification destruction algorithm allows users to add important files to a separate security database and prioritize their destruction when necessary. This design effectively protects users' sensitive data and avoids the risk of privacy leaks caused by device loss or transfer.

[0134] The specific process is as follows:

[0135] (1) Creation and maintenance of the identification algorithm database: During daily use, users can call the destory --add-file [filename] command through shortcut commands or UI interface operations to add identification files to the identification algorithm database. At the same time, users can remove identification files by calling destory --remove-file [filename]. Each user maintains their own identification algorithm database separately to ensure information isolation between users.

[0136] (2) Destruction of some documents:

[0137] Authentication before destruction: When the user executes the identification destruction algorithm, authentication will be performed and the user-specified identification file will be output;

[0138] Identification destruction: For the identification file output by the identification algorithm database, the system will write all its contents to zero and repeat the operation a specified number of times to ensure that the data is completely overwritten.

[0139] 2.33 All Destruction Algorithm

[0140] The goal of the full destruction algorithm is to completely write 0 to the data of the entire machine (the entire disk partition) or the files to be destroyed, ensuring that all data cannot be recovered.

[0141] The data destruction process of the entire machine by the full destruction algorithm is as follows:

[0142] (1) Disk partition identification: The OpenHarmony system consists of multiple image partitions, such as boot_linux.img, system.img, vendor.img, and userdata.img. The algorithm first scans and obtains all image partitions in the system through the getRootfs() function.

[0143] (2) Destruction operation: For all mirror partitions, the algorithm will perform multiple write-0 operations. The number of write-0 operations is determined by the logic of the matcher. The more destruction operations are performed, the more thorough the destruction.

[0144] (3) Device Lock: After all destruction operations are completed, the system will automatically lock the device to ensure that the device cannot be used again. Users need to perform operations such as system partition burning to restore the device function.

[0145] 2.4 Matchers

[0146] The matcher takes a destroy parameter with two inputs:

[0147] (1) Destruction urgency (u): Indicates the speed at which the destruction operation needs to be completed. The larger the u value, the faster the destruction speed is required.

[0148] (2) Destruction sufficiency (s): This indicates the degree of thoroughness that the destruction operation must achieve. The larger the value of s, the more thorough the destruction operation. Both values range from [1, 10] and are positive integers.

[0149] like Figure 5 As shown, the matcher quickly calculates the corresponding destruction algorithm based on the two input destruction parameters and the set sufficiency threshold. In this embodiment, the sufficiency threshold is set to 3.

[0150] The core of the matcher is function f, which corresponds to two destruction formulas and is designed as follows:

[0151] The first destruction formula is: ;

[0152] The second destruction formula is: .

[0153] Function f is influenced by two destruction parameters: u (destruction urgency) and s (destruction sufficiency), with s being the first destruction parameter and u being the second. The primary factor in function f is the destruction sufficiency, s. The destruction formula is matched by comparing s with the sufficiency threshold. When s = 3, the function directly returns the first destruction count and uses all destruction algorithms to destroy the entire device's data or pending files. When s < 3 (the sufficiency threshold) and u > s, rapid destruction is the primary user requirement. The primary influencing parameter in f is the destruction urgency, s. Based on the first destruction formula, f returns the destruction step size and uses the rapid destruction algorithm to destroy the entire device's data or pending files. When s < 3 and u ≤ s, f returns the first destruction count and uses all destruction algorithms to destroy the entire device's data or pending files. When s > 3, f returns the second destruction count based on the second destruction formula and uses all destruction algorithms to destroy the entire device's data or pending files. In this embodiment, the first destruction count is 1.

[0154] Based on the above discussion, the present invention provides a multi-mode one-key destruction method based on the OpenHarmony system, comprising the following steps:

[0155] Step S0: The server registers the system destruction service to the SAMgr of the OpenHarmony system through the Binder driver; the client remotely calls the server through the proxy object.

[0156] Specifically, the server process registers the service-related information (such as service ID, interface description, etc.) into SAMgr through the Binder driver; SAMgr is responsible for managing all registered system services and providing a query interface for the client.

[0157] When a client process needs to communicate with a server process, it first queries the SAMgr for a proxy object for the system destroy service through the Binder driver. The SAMgr returns the proxy object to the client. This proxy object has the same interface as the server, and the client can use it to call the server's system destroy service.

[0158] Step S1: The client sends a call request, and the proxy object encapsulates the call request into a message and passes it to the server through the Binder driver. The call request includes a destruction mode and destruction parameters. The destruction parameters include a destruction path, a degree of urgency, and a degree of adequacy. In this embodiment, s represents the degree of adequacy and u represents the degree of urgency.

[0159] Specifically, the client calls the proxy object, the proxy object encapsulates the client's call request into a Binder message and sends it to the server through the Binder driver; the Binder driver passes the call request to the server.

[0160] Step S2: The server performs the corresponding system destruction operation through the system destruction service based on the call request and obtains the processing result;

[0161] The specific process is as follows:

[0162] Step S21: The server determines the destruction mode through the system destruction service based on the call request. If the destruction mode is determined to be complete destruction, the server inputs the destruction parameters (destruction sufficiency, destruction urgency u) into the matcher to perform a quick destruction algorithm or a full destruction algorithm match to destroy the entire device's data and obtain a processing result. If the destruction mode is partial file destruction, the server proceeds to step S22 after the client selects the files to be destroyed.

[0163] Step S22: The server determines whether the file to be destroyed is an identification file. If so, the server marks the file as the first file to be destroyed. It then destroys the data in the first file to be destroyed using the identification destruction algorithm and obtains a processing result. It should be noted that before the server destroys the first file to be destroyed using the identification destruction algorithm, it first performs authentication. If the authentication passes, the OpenHarmony system's identification algorithm database outputs the first file to be destroyed, and the server destroys the data in the first file to be destroyed by writing all zeros. To distinguish between files to be destroyed, if a file to be destroyed is an identification file, it is marked as the first file to be destroyed; if it is not an identification file, it is marked as the second file to be destroyed.

[0164] If the file to be destroyed is the second file to be destroyed, the server proceeds to step S23;

[0165] Step S23: Inputting the destruction parameters (destruction sufficiency, destruction urgency u) into the matcher to perform matching with a quick destruction algorithm or a full destruction algorithm to destroy the data of the second file to be destroyed and obtain a processing result.

[0166] Step S3: The server returns the processing result to the proxy object;

[0167] Step S4: The proxy object returns the processing result to the client, and the client's UI displays the processing result.

[0168] Among them, in step S21, the server inputs the destruction parameter into the matcher to match the fast destruction algorithm or the full destruction algorithm to destroy the data of the entire machine. The process is as follows: Figure 5 As shown,

[0169] Step A0: The matcher pre-sets a sufficiency threshold, and compares the destruction sufficiency with the sufficiency threshold;

[0170] If the degree of destruction is equal to the degree of destruction threshold, the matcher returns to the first destruction number and then proceeds to step A2; if the degree of destruction is less than the degree of destruction threshold, then proceeds to step A1;

[0171] If the degree of destruction is greater than the degree of destruction threshold, the second destruction times are returned based on the second destruction formula of the matcher, and then step A2 is entered;

[0172] Step A1: The matcher compares the degree of destruction sufficiency with the degree of destruction urgency;

[0173] If the degree of destruction sufficiency is greater than or equal to the degree of destruction urgency, the matcher returns to the first destruction count and then proceeds to step A2;

[0174] If the degree of destruction sufficiency is less than the degree of destruction urgency, the destruction step length is returned based on the first destruction formula of the matcher, and then step A3 is entered;

[0175] Step A2: The matcher matches all destruction algorithms to destroy the data of the entire machine and determines the processing result. If the data destruction of the entire machine is successful, the processing result is destruction success. If the data destruction of the entire machine fails, the processing result is destruction failure, and the corresponding log of destruction failure is obtained.

[0176] Step A3: The matcher matches the fast destruction algorithm to destroy the entire machine's data and determines the result. If the destruction of the entire machine's data is successful, the result is "destruction success." If the destruction of the entire machine's data fails, the result is "destruction failure," and a log corresponding to the destruction failure is generated.

[0177] In step S23, the server inputs the destruction parameters into the matcher to match the quick destruction algorithm or the full destruction algorithm. The process is consistent with the matcher matching process in step S21. The difference is that step S21 ultimately destroys the data of the entire machine, while step S23 destroys the data of the second file to be destroyed.

[0178] The server inputs the destruction parameters into the matcher to match the quick destruction algorithm or the full destruction algorithm to destroy the data of the second file to be destroyed. The process is as follows:

[0179] Step B0: The matcher pre-sets a sufficiency threshold and compares the destruction sufficiency with the sufficiency threshold. If the destruction sufficiency is equal to the sufficiency threshold, the matcher returns to the first destruction count and proceeds to step B2. If the destruction sufficiency is less than the sufficiency threshold, the matcher proceeds to step B1.

[0180] If the degree of destruction is greater than the degree of destruction threshold, the second destruction times are returned based on the second destruction formula of the matcher, and then step B2 is entered;

[0181] Step B1: The matcher compares the degree of destruction sufficiency with the degree of destruction urgency. If the degree of destruction sufficiency is greater than or equal to the degree of destruction urgency, the matcher returns the first destruction count and proceeds to step B2. If the degree of destruction sufficiency is less than the degree of destruction urgency, the matcher returns the destruction step size based on the first destruction formula of the matcher and proceeds to step B3.

[0182] Step B2: The matcher matches all destruction algorithms and destroys the data of the second file to be destroyed based on the destruction path, and returns the processing result. If the data of the second file to be destroyed is destroyed successfully, the processing result returned is "destruction success". If the data of the second file to be destroyed fails, the result returned is "destruction failure", and the log corresponding to the destruction failure is returned.

[0183] Step B3: The matcher matches the fast destruction algorithm and destroys the data of the second file to be destroyed based on the destruction path, returning the result. If the data destruction of the second file to be destroyed is successful, the result returned is "destruction success". If the data destruction of the second file to be destroyed fails, the result returned is "destruction failure", and the corresponding log of the destruction failure is returned.

[0184] Here is an example of a destruction algorithm:

[0185] The present invention is based on the OpenHarmony operating system and implements a multi-mode one-key destruction method applicable to the OpenHarmony standard system. In the specific example of the present invention, the Runhe HH-SCDAYU200 development kit is used, and its hardware configuration is as follows:

[0186] Processor: Rockchip RK3568, quad-core 64-bit Cortex-A55 architecture, main frequency up to 2.0GHz;

[0187] GPU: Integrated dual-core architecture GPU, supporting 3D graphics rendering and hardware synthesis functions;

[0188] Memory: The minimum memory is 128 MiB, and expansion is supported;

[0189] Storage: Supports storage media such as eMMC and NAND Flash, and the file system uses the ext4 format.

[0190] Software environment configuration:

[0191] Operating system version: OpenHarmony-5.0.0-Release;

[0192] System call interface development tool: DevEco Studio (version 5.0.5.315).

[0193] Example of a fast destruction algorithm:

[0194] This example demonstrates the practical application of selecting the important file destruction mode and matching it with the rapid destruction algorithm. The server receives the destruction parameters entered by the client through a system call interface: target file file1, destruction sufficiency level s=1, and destruction urgency level u=2. The server then calculates the destruction step size K=22. During the rapid destruction algorithm, the divergence N=2 is set, and a random number sequence is generated based on a Gaussian distribution. The rapid destruction algorithm then writes zeros to the specified storage location of target file file1 based on this random number sequence, achieving secure destruction of the data in the target file (target file1).

[0195] To verify the effectiveness of the destruction algorithm, we performed an integrity check on the target file, file1, after the rapid destruction algorithm completed. We confirmed that the contents of target file1 were completely garbled and the original data could not be restored, fully demonstrating the effectiveness of the rapid destruction algorithm.

[0196] Example of a logo destruction algorithm:

[0197] In this example, the server first calls the init_db("user1") function to create an empty identification algorithm database for user user1 and set their authentication password and fingerprint information. This database is stored in a key-value pair format, where the key is the user ID and the value is a list of file paths. This ensures that each user's data is stored independently and securely, effectively preventing data leakage.

[0198] The user adds files file1 and file2 to the identification algorithm database using the shortcut command destroy --add-file file1 file2. Subsequently, the identification destruction algorithm is triggered by calling destroy_files("user1") . Before executing the destruction operation, the server verifies the password or fingerprint of user user1 to ensure that only authorized users can trigger the destruction operation, further improving the security of the operating system.

[0199] After authentication, the system reads the file list stored in the identification algorithm database and performs multiple write-to-0 operations on file1 and file2 in the file list. This design ensures that even if the destruction process is interrupted or incomplete, the user's sensitive files can be completely destroyed, effectively protecting user privacy.

[0200] To verify the destruction effect, we performed an integrity check on the target file after the algorithm completed. The results showed that the file contents were completely garbled and the original data could not be restored. This result fully demonstrates the effectiveness and reliability of the identification destruction algorithm in secure data destruction.

[0201] Example of all destruction algorithms:

[0202] This example demonstrates the actual process of selecting a complete data destruction mode and matching all destruction algorithms. The system's server receives the destruction parameters s=6 and u=4 from the client via an interface. The matcher calculates the second destruction count as two. The algorithm then calls the getRootfs() function to retrieve the system-specified image partitions and performs two write-to-zero operations on all image partitions to ensure complete data destruction.

[0203] To verify the effectiveness of the destruction, the system was checked. After the destruction was complete, the device was locked and unusable. Reflashing the system partition restored the device to its original state. After reflashing, the device booted normally. Verification confirmed that the device contained no user data, confirming the effectiveness and reliability of the entire destruction algorithm.

[0204] Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

Claims

1. A multi-mode one-key destruction method based on the OpenHarmony system, characterized in that: The following steps are involved: Step S0: The server registers the system destruction service to the SAMgr of the OpenHarmony system through the Binder driver; the client remotely calls the server through the proxy object; Step S1: The user sends a call request through the client, the proxy object encapsulates the call request into a message, and passes it to the server through the Binder driver; Step S2: The server performs the corresponding system destruction operation through the system destruction service based on the call request and obtains the processing result; Step S3: The server returns the processing result to the proxy object; Step S4: The proxy object returns the processing result to the client; The call request includes a destruction mode and destruction parameters; the destruction mode is complete destruction or partial file destruction; the destruction parameters include destruction adequacy and destruction urgency; The step S2 comprises the following steps: Step S21: The server determines the destruction mode based on the call request. If the destruction mode is complete destruction, the server inputs the destruction parameters into the matcher to perform a quick destruction algorithm or a full destruction algorithm match to destroy the entire device's data and obtain the processing result. If the destruction mode is partial file destruction, the server proceeds to step S22 after the client selects the files to be destroyed. Step S22: The server determines whether the file to be destroyed is an identification file. If so, the server marks the file to be destroyed as a first file to be destroyed. The server destroys the data of the first file to be destroyed using an identification destruction algorithm and obtains a processing result. If the file to be destroyed is not an identification file, the server marks the file to be destroyed as a second file to be destroyed and then proceeds to step S23. Step S23: The server inputs the destruction parameter into the matcher to perform matching with the quick destruction algorithm or the full destruction algorithm to destroy the data of the second file to be destroyed, and obtains a processing result.

2. The multi-mode one-key destruction method based on the OpenHarmony system according to claim 1 is characterized in that: The server sets the sufficiency threshold; In step S21, the server inputs the destruction parameters into the matcher to match the quick destruction algorithm or the full destruction algorithm to destroy the data of the entire device. The process is as follows: Step A0: The matcher compares the destruction sufficiency with the sufficiency threshold; if the destruction sufficiency is equal to the sufficiency threshold, the matcher directly returns to the first destruction count and then proceeds to step A2; If the destruction sufficiency is less than the sufficiency threshold, proceed to step A1; If the degree of destruction is greater than the degree of destruction threshold, the second destruction times are returned based on the second destruction formula of the matcher, and then step A2 is entered; Step A1: The matcher compares the degree of destruction sufficiency with the degree of destruction urgency; If the degree of destruction sufficiency is greater than or equal to the degree of destruction urgency, the matcher directly returns to the first destruction count and then proceeds to step A2; If the degree of destruction sufficiency is less than the degree of destruction urgency, then the destruction step length is returned based on the first destruction formula of the matcher, and then step A3 is entered; Step A2: The matcher matches all destruction algorithms to destroy the data on the entire machine and determines the result. If the data destruction on the entire machine is successful, the result is "destruction success." If the data destruction on the entire machine fails, the result is "destruction failure," and a log corresponding to the destruction failure is obtained. Step A3: The matcher matches the fast destruction algorithm to destroy the data of the entire machine and determines the processing result. If the data destruction of the entire machine is successful, the processing result is destruction success. If the data destruction of the entire machine fails, the processing result is destruction failure, and the corresponding destruction failure log is obtained. The first destruction formula is: ; The second destruction formula is: ; Among them, s represents the degree of destruction sufficiency, u represents the degree of destruction urgency, Indicates the destruction step length; Indicates the second destruction count.

3. The multi-mode one-key destruction method based on the OpenHarmony system according to claim 2 is characterized in that: The fast destruction algorithm refers to writing 0 operations on the data of the entire machine or the data of the second file to be destroyed with the destruction step length as the interval; The complete destruction algorithm refers to performing a write-0 operation on all data of the entire machine or the data of the second file to be destroyed with a first destruction number of times or a second destruction number of times.

4. The multi-mode one-key destruction method based on the OpenHarmony system according to claim 2 is characterized in that: In step S22, before the server destroys the first file to be destroyed using the identification destruction algorithm, it first performs user authentication. If the user authentication is successful, the identification algorithm database of the OpenHarmony system outputs the data of the first file to be destroyed, and the server destroys the data of the first file to be destroyed based on the identification destruction algorithm.

5. The multi-mode one-key destruction method based on the OpenHarmony system according to claim 4 is characterized in that: The identification destruction algorithm refers to repeatedly writing 0 operations on the data of the first file to be destroyed.

Images