A method, system, device and medium for deleting USB device plug-in recording based on an operating system

Abstract

The application provides a USB device plug-in record deletion method, system, device and medium based on an operating system, belongs to the technical field of USB device plug-in records, and realizes complete deletion of the USB device plug-in record through registry permission privilege escalation, USB path data extraction, PID / VID rule establishment, full registry subentry matching deletion, export and replacement of a system file, loading of an old version system file after restart for secondary deletion, NK block identification based on a HIVE file format, screening of target blocks with a deleted state and a name containing DISK / USB or matching PID / VID, generation of an equal-length random string to cover name data, and final deletion of old files, associated logs and execution of disk remaining space safe erasure. Through replacement of a registry file, processing of old file residues, multi-dimensional data covering and disk erasure, complete deletion of the USB device plug-in record is realized, and anti-forensic recovery is effectively prevented.

Description

Technical Field

[0001] This invention belongs to the field of USB device plug-in / plug-out recording technology, specifically relating to a method, system, device, and medium for deleting USB device plug-in / plug-out records based on an operating system. Background Technology

[0002] Since its introduction, USB (Universal Serial Bus) technology has become one of the standard interfaces for modern computers and electronic devices. Its plug-and-play feature, high compatibility, and low cost have led to the widespread use of USB devices (such as USB flash drives, external hard drives, and peripherals) in personal, business, and industrial settings. However, with the increasing prevalence of USB devices, the security risks they pose have become increasingly prominent.

[0003] USB devices are a channel for sensitive data leakage. Unauthorized insertion of USB flash drives may result in the copying of confidential files or malware infiltrating the system through side-load attacks. Windows systems record the insertion and removal history of all USB devices through the registry. These records not only expose device usage traces but may also become clues for attackers to track user behavior. Although existing tools can partially erase these records, they suffer from problems such as cumbersome operation and incomplete removal of residual data.

[0004] For example, by modifying the deletion flag of a registry key, changing 0x01 to 0x00 marks the record as deleted, but the original data is still retained in the physical storage of the HIVE file. For instance, third-party registry cleaning tools only clean index information, not overwriting physical data; the data can be extracted using a hexadecimal editor or recovery software. Some USB device records may be stored in deep subkeys of the registry or subkeys created across different times; traditional traversal methods only process surface subkeys, leading to omissions. Summary of the Invention

[0005] This invention provides a method for deleting USB device plug-in / plug-out records based on an operating system. By replacing registry files, handling old file remnants, multi-dimensional data overwriting, and disk erasure, the method achieves complete erasure of USB device plug-in / plug-out records, effectively preventing counter-forensic recovery.

[0006] The methods include:

[0007] S101: Register the program used to delete USB device plug-in / plug-out records to a Windows service.

[0008] Grant it editing permissions on the Windows Registry;

[0009] S102: Access the system registry, enumerate the subkeys under the USB path in the registry, and obtain the USB device plug-in / plug-out record data stored therein;

[0010] S103: Parse the acquired record data, extract the device identifier PID and VID information, establish deletion condition filtering rules and save the target record information;

[0011] S104: Traverse and load all quantum entries in the system registry, perform matching operations on subkey names, delete the matched data through the Windows application programming interface, and only delete the flag bits in the system file;

[0012] S105. Call the Windows API function RegSaveKey to export the registry system key as a first file, and then use the Windows API function RegReplaceKey to replace the current registry system file with the newly generated first file;

[0013] S106: After completing the file replacement, uninstall and delete the temporary registry service, trigger a system restart, and completely replace the registry system file with the new first file;

[0014] S107: Load the old version of the system file in read-only mode, traverse its subkey names, perform secondary deletion on records that meet the deletion criteria, and uninstall the registry.

[0015] S108: Open the old system file in binary reading mode, identify all content blocks in the old system file that start with nk based on the characteristics of the HIVE file format; extract the first 4 bytes of data for each nk-marked content block, convert it into a deletion state with integer sign judgment, skipping content blocks with negative numbers and including content blocks with positive numbers in the scope to be processed;

[0016] S109: Parse the name field of the content block to be processed, extract the string from offset 0x50 in the name field, and determine whether it completely matches the DISK or USB substring. If the match is successful, execute S110.

[0017] S110: Extract the corresponding PID and VID information from the record saved in step S103, combine them into the target string PID_XXXX&VID_XXXX, and perform matching with the string in the content block name field;

[0018] S111: Based on the target block matched by the name field, generate a random string of equal length according to the length information stored in the block header, and overwrite the original name data from offset 0x50;

[0019] S112: After completing the name data overwrite, delete the old system file and associated log file through the Windows API, and perform a secure erase on the remaining disk space to eliminate residual information.

[0020] This application also provides a system for deleting USB device plug-in / unplug records based on an operating system, the system comprising:

[0021] The permissions settings module is used to register the program used to delete USB device plug-in / plug-out records to a Windows service and grant it editing permissions to the Windows Registry.

[0022] The record enumeration module is used to access the system registry, enumerate the subkeys under the USB path in the registry, and obtain the USB device plug-in / plug-out record data stored therein.

[0023] The parsing and filtering module is used to parse the acquired record data, extract device identifiers (PID and VID) information, establish deletion condition filtering rules, and save target record information.

[0024] The Modify and Delete module is used to traverse and load all entries in the system registry, perform matching operations on subkey names, and delete the matched data through the Windows application programming interface, only deleting the flag bits in the system file;

[0025] The backup and file replacement module is used to call the Windows API function RegSaveKey to export the registry system key as a first file, and then use the Windows API function RegReplaceKey to replace the current registry system file with the newly generated first file;

[0026] The file replacement and uninstallation module is used to replace files, uninstall and delete temporary registry services, trigger system restart, and completely replace the registry system file with the new first file.

[0027] The old file loading and deletion module is used to load the old version of the system file in read-only mode, traverse its subkey names, perform secondary deletion on records that meet the deletion criteria, and uninstall the registry.

[0028] The reading and block recognition module is used to open the old version of the system file in binary reading mode. Based on the characteristics of the HIVE file format, it identifies all content blocks in the old version of the system file that start with nk. It extracts the first 4 bytes of data for each nk-marked content block and converts it into a deletion state with integer sign judgment. Content blocks with negative numbers are skipped, and content blocks with positive numbers are included in the scope to be processed.

[0029] The field extraction and matching module is used to parse the name field of the content block to be processed, extract the string from the offset 0x50 in the name field, and determine whether it completely matches the DISK or USB substring.

[0030] The string combination matching module is used to extract the corresponding PID and VID information from the records saved by the parsing and filtering module, combine them into the target string PID_XXXX&VID_XXXX, and perform matching with the string in the content block name field;

[0031] The data overwrite module, based on the target block matched by the name field, generates a random string of equal length according to the length information stored in the block header, and overwrites the original name data from offset 0x50.

[0032] The deletion and erasure module is used to delete the old system file and associated log file via Windows API after overwriting the name data, and to perform a safe erasure process on the remaining disk space to eliminate residual information.

[0033] According to another embodiment of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method for deleting USB device plug-in / plug-out records based on an operating system.

[0034] According to another embodiment of this application, a storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the method for deleting USB device plug-in / plug-out records based on an operating system.

[0035] As can be seen from the above technical solutions, the present invention has the following advantages:

[0036] This invention provides a method for deleting USB device plug-in / plug-out records under an operating system. It obtains high privileges by registering a Windows service with elevated privileges. First, it uses RegSaveKey to export a clean registry file, then uses RegReplaceKey to atomically replace the original system file, ensuring the system uses the new file and the old file is no longer exclusively used by the system. Subsequent deletion and data overwriting of the old file completely removes residual data. For the NK block structure of HIVE files, after identifying deleted blocks, the name field is extracted and matched against the target PID / VID. A random string of equal length is used to overwrite the name area, disrupting the continuity and identifiability of the original data, making it impossible for recovery tools to extract valid information. Through hierarchical traversal of sub-items and multi-dimensional matching, all nested levels and historical records are covered. Simultaneously, combined with HIVE file structure parsing, the physical storage location within the NK block is directly located, avoiding omissions caused by changes in factor paths. Based on the length information stored in the NK block header in the HIVE file, a random string of equal length is generated to overwrite the original name area, ensuring that every byte of the original data is destroyed. Combined with secure erasure of remaining disk space, all possible residual traces are eliminated.

[0037] This invention employs multiple operations—flag modification, file replacement, data overwriting, and disk erasure—to ensure that USB plug-in / unplug records leave no residue in the registry, file system, or remaining disk space, making them unrecoverable using conventional tools. It adapts to system exclusivity restrictions, using atomic replacement and access control to prevent system crashes or data corruption, ensuring the controllability of the operation process. Combining multi-dimensional matching based on PID / VID, name fields, and timestamps, it processes only the target USB record, preventing accidental deletion of critical system data. Attached Figure Description

[0038] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0039] Figure 1 This is a flowchart of a method for deleting USB device plug-in / plug-out records based on an operating system.

[0040] Figure 2 This is a schematic diagram of a system for deleting USB device plug-in / plug-out records based on an operating system.

[0041] Figure 3 This is a schematic diagram of an electronic device. Detailed Implementation

[0042] The method for deleting USB device plug-in / unplug records under an operating system described in this application is implemented on a Windows system. The System file is stored in HIVE format, and each entry in the registry is a key, stored in NK format within the HIVE data format. This can be found by opening it with WinHex. Figure 1 The Key within the NK block is its binary data, which includes an NK signature and the Key name. The entire NK block contains 25 different data types, stored in fixed-size blocks. The most important information includes the following:

[0043] Size: Starting at offset 0x0, the system uses a 32-bit signed integer for storage, where negative numbers represent not deleted and positive numbers represent deleted areas that can be overwritten. In the screenshot above, its hexadecimal value is 0x90FFFFFF, stored in little-endian. Converted to decimal, it is -112, representing a length of 112, indicating an area that has not been deleted.

[0044] Signature: Starting at offset 0x04, the signature of this NK record is an ASCII string nk with a hexadecimal value of 0x6E6B.

[0045] Name: Starts at offset 0x50. The name is 2 bytes long, starting at offset 0x4C. In the example above, the length is 0x1c00, which is 28 in decimal.

[0046] Read the file, iterate through all blocks starting with "nk" and marked as deleted. Extract their names, contents, and lengths, ensuring they start with "DISK&" or contain "PID" and "VID". If these conditions are met, a second overwrite is required. Randomly generate a string of the same length and overwrite the original name with it to achieve complete deletion.

[0047] The following describes in detail the method for deleting USB device plug-in / unplug records based on an operating system, as per this application. Specific details, such as particular system architectures and techniques, are presented for illustrative purposes and not for limitation, to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will recognize that this application can be implemented in other embodiments without these specific details.

[0048] It should be understood that, when used in this specification, terms include indicating the presence of a described feature, integral, step, operation, element, and / or component, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. The terms include, encompass, have, and variations thereof mean including but not limited to, unless otherwise specifically emphasized.

[0049] The statements such as "one embodiment" or "some embodiments" described in this application mean that one or more embodiments of this application include the specific features, structures, or characteristics described in that embodiment. Therefore, the statements such as "in one embodiment," "in some embodiments," "in other embodiments," and "in still other embodiments" in this application do not necessarily refer to the same embodiment, but rather mean one or more, but not all, embodiments, unless otherwise specifically emphasized.

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

[0051] Please see Figure 1 The diagram shows a flowchart of a method for deleting USB device plug-in / plug-out records based on an operating system in a specific embodiment. The method includes:

[0052] S101: Register the program used to delete USB device plug-in / plug-out records to a Windows service and grant it editing permissions to the Windows Registry.

[0053] In some embodiments, the program is encapsulated as a Windows service program, the service startup type is set to temporary startup during registration, and the service is granted full control permissions in the registry through the system permission configuration interface. Specifically, this includes permissions to add, delete, modify, and query the system key and the Enum\USB subkey in the registry, ensuring that the program running has high system operation privileges and can bypass the registry access restrictions of ordinary programs.

[0054] S102: Access the system registry, enumerate the subkeys under the USB path in the registry, and obtain the USB device plug-in / plug-out record data stored therein.

[0055] In some embodiments, the current control set\Enumeration\USB subkey is started via the Windows Registry Access Interface. Then, all first-level and third-level subkeys under this subkey are traversed one by one via the RegEnumKeyEx interface. Simultaneously, the USB device plug-in / plug-out record data stored in each subkey is read via the RegQueryValueEx interface. This data is temporarily stored in a temporary cache area of ​​system memory according to the structure of subkey path-key name-key value content. In this way, by enumerating the subkeys under this path and reading the key values, the plug-in / plug-out record data of all USB devices can be completely obtained.

[0056] S103: Parse the acquired record data, extract the device identifier PID and VID information, establish deletion condition filtering rules, and save the target record information.

[0057] In some embodiments, the Product Identifier (PID) and Manufacturer Identifier (VID) are unique identifiers for a USB device, and the combination of PID and VID for each USB device is unique. Based on this uniqueness, filtering rules can be established to accurately locate the plug-in / plug-out records of specific USB devices that need to be deleted, avoiding the accidental deletion of records for other devices.

[0058] S104: Traverse and load all entries in the system registry, perform matching operations on subkey names, and delete the matched data through the Windows application programming interface. This deletion only modifies the system file flags.

[0059] In some embodiments, the Windows system registry is stored in HIVE file format. Each registry key corresponds to an NK block. The 4-byte integer at the beginning of the NK block is used to identify the deletion status of the key. A negative number indicates that the key has not been deleted, and a positive number indicates that the key has been deleted. Since the system file is a system-exclusive file, data cannot be deleted directly. Instead, it can only be deleted by modifying the flag bits. These key entries marked as deleted will be cleared when the file is replaced later.

[0060] S105. Call the Windows API function RegSaveKey to export the registry system key as a first file, and then use the Windows API function RegReplaceKey to replace the current registry system file with the newly generated first file.

[0061] In some embodiments, the currently loaded registry system key is exported as a first file via the RegSaveKey interface. The export path is set to the system temporary directory, and the export only mode is enabled, i.e., NK blocks marked for deletion are not exported, ensuring that the first file is a clean registry file without any deletion information residue. After the export is completed, a system file replacement request is initiated via the RegReplaceKey interface. Before the replacement, the system process management interface is called to pause non-core system processes to prevent these processes from occupying the original system file and causing the replacement to fail. During the replacement, the original system file is replaced with the first file, and the start time, end time, and result of the replacement operation are recorded.

[0062] In some specific embodiments, step S105 further includes the following steps:

[0063] S1051: Before calling RegSaveKey to export, check whether the current system file is locked or occupied by other processes through Windows API. If occupation is detected, record the conflicting process information and terminate the export operation to avoid incomplete export files due to file locking.

[0064] S1052: When performing file replacement using the Windows API's replacement function, set the flag for the replacement operation to ensure the replacement process is successful;

[0065] S1053: After the replacement is completed, the metadata and key registry entries of the new system file are read through the Windows API to verify their consistency with the metadata and key data of the first file, and the replacement operation is confirmed to be successful.

[0066] S1054: Before deleting its own Windows service, clean up the service's residual entries in the registry through API and reset the system's access permissions to the old system file to avoid subsequent erasure operations failing due to service remnants or unreleased permissions.

[0067] Step S105 of this embodiment solves the system instability problem caused by file locking, incomplete export, or replacement failure during the registry file replacement process through multi-stage verification and atomication operations, ensuring that the generated first file can safely and reliably replace the old system file.

[0068] S106: After completing the file replacement, uninstall and delete the temporary registry service, trigger a system restart, and completely replace the registry system file with the new first file.

[0069] In some embodiments, the temporary registry service is only used for privilege escalation operations in S101-S105. After completion, deletion can prevent the service from occupying system resources for a long time or being detected by third-party tools. When the system restarts, the registry will be reinitialized, a new system file will be loaded, and the old file will be completely replaced to ensure that the clean registry state in the new file takes effect.

[0070] S107: Load the old version of the system file in read-only mode, traverse its subkey names, perform secondary deletion on records that meet the deletion criteria, and uninstall the registry.

[0071] In some embodiments, although the old system file is replaced by the new file, there are still residual USB records that need to be deleted; loading in read-only mode can avoid modifying the current system registry and only operate on the old file; secondary deletion further marks the target record in the old file, accurately locates the target block for subsequent binary overwrite, and ensures that the residual records in the old file are completely processed.

[0072] S108: Open the old system file in binary read mode, and identify all content blocks in the old system file that start with nk based on the characteristics of the HIVE file format; extract the first 4 bytes of data for each nk-marked content block, convert it into a deletion state with integer sign judgment, skipping content blocks with negative numbers and including content blocks with positive numbers in the scope to be processed.

[0073] In some embodiments, the NK block in a HIVE file is the core unit for storing registry entry information, and the start flag nk and the header 4-byte deletion status flag have a fixed format. All NK blocks can be located by identifying the start flag, and NK blocks marked for deletion can be filtered out by judging the flag sign. Locating NK blocks marked for deletion in the old file and excluding undeleted blocks reduces redundancy in subsequent operations.

[0074] In some specific embodiments, step S108 further includes the following steps:

[0075] Step S1081: When identifying content blocks that start with nk, verify whether the block length conforms to the HIVE file format specification, exclude non-NK blocks caused by file corruption or mismatch, and ensure that only valid NK blocks are processed.

[0076] Step S1082: For each NK block, in addition to extracting the first 4 bytes to determine the deletion status, extract the timestamp field in the block header to record the block creation / modification time. This is used in subsequent steps to perform correlation verification with the USB device plug-in / unplug time and to exclude NK blocks that are not related to the target USB record.

[0077] Step S1083: For NK blocks whose first 4 bytes are positive, further check the upper block offset field in the block header. If the upper block offset points to an invalid address, mark the NK block as a single block and process it first to avoid residual invalid data.

[0078] Step S1084: During the processing, an NK block processing log is generated, which records the starting offset, block size, deletion status, timestamp, and upper block offset information of each NK block. The log is stored using a system-unique identifier for encryption.

[0079] Step S1085: For NK blocks whose timestamps overlap with the target USB record time range, a unique processing identifier is generated and linked with the name field matching process in steps S109-S111 to improve the targeting of the processing.

[0080] As can be seen, step S108 improves the accuracy and thoroughness of identifying and processing USB-related NK blocks in the old system file by verifying the integrity of the NK block, filtering the target block by combining the timestamp and the upper-level block information, and recording the processing log. This avoids misprocessing or omissions caused by relying solely on the NK flag and deletion status in the prior art. The implementation method is as follows: open the old system file in binary mode, traverse the file content, identify the block starting with NK; verify whether the block length conforms to the HIVE format, extract the timestamp and the upper-level block offset; mark a single block and record the log; generate a unique identifier to link with subsequent processing, ensuring that only deleted NK blocks related to the target USB record are processed.

[0081] S109: Parse the name field of the content block to be processed, extract the string from offset 0x50 in the name field, and determine whether it completely matches the DISK or USB substring. If the match is successful, execute S110.

[0082] In some embodiments, the NK block name field corresponding to the USB device plug-in / plug-out record contains a substring that identifies the USB device type or the DISK device. This feature can be used to further filter out deleted NK blocks related to USB, exclude deleted NK blocks of other types of devices, narrow down the range to be overwritten, and improve the fault tolerance of the filtering.

[0083] S110: Extract the corresponding PID and VID information from the record saved in step S103, combine them into the target string PID_XXXX&VID_XXXX, and perform matching with the string in the content block name field.

[0084] In some embodiments, PID and VID are unique identifiers of a USB device, and the format string PID_XXXX&VID_XXXX can precisely correspond to a specific USB device. By matching this string with the NK block name, the target device record to be deleted can be further locked from the USB-related NK block, ensuring that the overwrite operation is performed only on the target block.

[0085] S111: For the target block matched based on the name field, generate a random string of equal length according to the length information stored in the block header, and overwrite the original name data at offset 0x50.

[0086] In some embodiments, the name field of the target NK block contains the PID / VID associated name of the USB device. Overwriting it with a random string of equal length can completely destroy the original information, so that even if the old file is recovered, the USB device record cannot be identified by the name field. Post-overwrite verification can ensure that the operation is effective and avoid overwrite failure due to disk I / O errors.

[0087] S112: After completing the name data overwrite, delete the old system file and associated log file through the Windows API, and perform a secure erase on the remaining disk space to eliminate residual information.

[0088] In some embodiments, when a Windows system deletes a file, it only marks the sectors occupied by the file as free, without erasing the original data in the sectors. This data can be extracted using recovery tools. Secure erasure completely destroys residual data by writing random data multiple times to overwrite free sectors. Deleting associated logs and temporary records can eliminate operation traces and prevent them from being traced by anti-forensic tools.

[0089] This process thoroughly deletes old files and associated traces, clears residual data from disk sectors, and ensures that there are no remnants of USB device plugging and unplugging records. Multiple overwriting and trace detection further enhance the thoroughness of erasure, eliminate the risk of counter-evidence, and achieve the final traceless deletion effect.

[0090] In one embodiment of the present invention, based on step S104, the following will provide a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S104 further includes:

[0091] S1041: Classify the loaded system registry full quantum key according to the hierarchical structure of root key-first-level subkey-second-level subkey-third-level subkey, filter out the subkey set that is associated with the current control set\enumeration\universal serial bus subkey, exclude registry subkeys that are not related to USB device plug-in / plug-out records, and reduce invalid traversal operations.

[0092] S1042: Detect the current operating system's occupation status of the system file associated with the registry. If the system file is detected to be exclusively occupied by a system process, a temporary waiting mechanism is triggered. The occupation status is re-detected every preset time until it is confirmed that the system file is in a non-completely exclusive state with the executable flag bit modified.

[0093] S1043: Perform name matching operation on each of the classified related sub-items, compare the sub-item name with the deletion condition filtering rules established in step S103, record the storage path and current flag status of all target sub-items that match the name, and back up the flag status to the temporary storage area.

[0094] S1044: For a target sub-item whose name matches, send a flag modification request to the registry through the Windows application programming interface. The request is limited to updating the deletion status flag of the target sub-item from never deleted to deleted, without touching the original data storage area associated with the sub-item. If an interface call conflict occurs during the request process, pause the current operation and release the temporarily occupied registry resources first. Resend the flag modification request after the conflict is resolved.

[0095] S1045: After modifying the flags of all target sub-items, reread the flag status of each target sub-item and compare it with the original flag status backed up in the temporary storage area to confirm that all target sub-items have been successfully modified to the deleted flag. If there are any sub-items that have not been successfully modified, repeat step S1044 until the modification is successful, and record the operation log of the modification failure and retry process.

[0096] As can be seen, under the premise that the Windows system has exclusive restrictions on the system file and cannot directly and completely delete registry subkeys, step S104 achieves safe pre-deletion marking of registry subkeys associated with USB device plug-in / plug-out records by first filtering associated subkeys, then confirming the file's operable status, then accurately modifying the flag bit, and finally verifying the modification results. This avoids operation failures or registry corruption caused by exclusive system files, and ensures the stability of registry operations through backup and verification mechanisms.

[0097] In one embodiment of the present invention, based on step S107, the following will provide a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S107 further includes the following steps:

[0098] S1071: Call the system file detection tool to perform an integrity check on the old version of the system file, check whether the file has missing bytes, corrupted data or abnormal format. If an abnormality is detected, call the system backup and recovery interface to extract the complete old version of the system file from the old system file backup copy generated in step S1054, replace the abnormal file and then enter the loading process; if there is no backup copy, terminate the loading and record the abnormal information.

[0099] S1072: When loading an old version of the system file in read-only mode, an independent temporary memory isolation area is created through the system memory management interface. The loaded data of the old version of the system file is restricted to this isolation area, and the loaded data is prohibited from interacting with the current operating system's running memory, so as to avoid abnormal data in the old file from interfering with the current system operation.

[0100] S1073: When traversing all subkeys of the registry corresponding to the old version of the system file, the deletion condition filtering rules saved in S103 are called synchronously. Full character matching is performed on each subkey name, that is, the subkey name must completely contain the identification information in the filtering rules. The physical storage location of the matched subkey in the old version of the system file is recorded, such as the offset address in the file and the start and end bytes of the data block, forming a list of deletion locations.

[0101] S1074: After performing a secure deletion operation using the Windows application interface on a matched sub-item, reread the deletion status flag of the sub-item, corresponding to the first 4 bytes of the NK block. If the flag does not become positive, check if there is a temporary memory lock, release the lock, and re-execute the secure deletion. If the deletion fails 3 times in a row, add the sub-item information and the reason for the failure to the abnormal deletion list.

[0102] S1075: After completing the deletion of all matching sub-items, first clean up the old version of the system file loading data in the temporary memory isolation area, including sub-item name cache, deletion status record, etc., and then uninstall the registry loading instance corresponding to the old version of the system file through the system registry uninstallation interface. At the same time, delete the temporary operation data other than the deletion location list and the abnormal deletion list.

[0103] Step S107 of this embodiment addresses the technical problem that although the old system file has been replaced by the new file, residual USB plug-in records still remain and need to be deleted. Furthermore, directly loading the old file can easily lead to anti-forensic risks due to file corruption, memory interference, or incomplete deletion. The system's built-in file integrity detection tool compares the old system file's preset verification information to check for file corruption. If corrupted, it restores from a backup copy, ensuring the loaded file can be parsed correctly. An independent temporary memory isolation area is created to restrict the loaded data of the old system file to this area, preventing operational risks caused by interaction with the current system memory. When traversing the old file registry subkeys, a full character match is performed according to the filtering rules in step S103, recording the physical storage location of the matched subkeys to provide a location basis for subsequent secure erasure. After deletion, the deletion result is verified by rereading the flag bit. Failed entries are checked for memory locking issues and retried to avoid deletion omissions. Before unloading the old file registry, the loaded data and intermediate operation records in the isolated memory are cleaned up to prevent temporary data residue from being extracted by anti-forensic tools.

[0104] In one embodiment of the present invention, based on step S110, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner: Step S110 further includes the following steps:

[0105] Step S1101: Before extracting the PID and VID information and combining them into a target string, verify whether the usage time of the device corresponding to the target string overlaps with the timestamp of the NK block in the old system file. Only when the device usage time partially overlaps with the time range of the NK block will the subsequent matching operation be performed to avoid mismatches caused by the device being unplugged but the NK block not being updated in time.

[0106] Step S1102: For the target string PID_XXXX&VID_XXXX, synchronously check whether its associated device path contains USBSTOR or USB substring. If the path does not contain the relevant substring, mark it as a non-USB device record and skip the matching, thereby improving the targeting of the matching.

[0107] Step S1103: For dynamic PID / VID scenarios, generate extended matching rules, including the format PID_XXXX&VID_YYYY, and link them with the historical PID / VID information saved in step S103 to ensure that the device records for changing ports are still overwritten.

[0108] Step S1104: During the matching process, record the matching result of each target string, the associated NK block offset, timestamp and device path information, and generate a matching log. The log is encrypted and stored using a system-unique identifier to facilitate subsequent auditing or error backtracking.

[0109] Step S1105: For a successfully matched target block, generate a unique processing identifier and link it with the data overwrite process in subsequent steps to ensure that only NK blocks that completely match the target USB record are processed.

[0110] As can be seen, after extracting the PID / VID combined target string in step S110, the overlap between its usage time and the NK block timestamp is verified; the device path is checked for USB-related substrings; extended matching for dynamic PID / VID scenarios is supported; encrypted logs are recorded and unique identifiers are generated to ensure that only NK blocks that completely match the target USB record are processed. By using time overlap, path association, dynamic PID / VID support, and recording the matching process, the accuracy and thoroughness of matching the target string with the NK block name field are improved.

[0111] In one embodiment of the present invention, based on step S112, the following will provide a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S112 specifically includes:

[0112] Step S1121: Before deleting the old system file and associated log file through the Windows API, first verify whether the file is still locked by a system process. If a locking process exists, send a temporary termination request to the locking process. If the request times out, release the file handle through the system interface to ensure that the file can be completely deleted.

[0113] Step S1122: When performing a secure erase on the remaining disk space, the first time a random string is used to overwrite the data, the second time a string of all zeros is used to overwrite the data, and the third time a string of all ones is used to overwrite the data. The overwrite area includes the sectors originally occupied by the old system file and the storage area of ​​the associated log file, ensuring that the data cannot be restored by disk recovery tools.

[0114] Step S1123: During the erasure process, record detailed information about the erasure operation, including erasure time, starting sector, ending sector, number of overwrites and contents, and success / failure.

[0115] Step S1124: After erasure is complete, use a disk scanning tool to check if there is any residual data in the erased area. If any data blocks that have not been erased are detected, repeat the erasure operation until all target areas are completely covered.

[0116] Step S1125: Generate a file residue verification report for the deleted old system file and log file, recording the file deletion time, size before deletion, changes in disk space remaining after deletion, and erase operation log to ensure the thoroughness and verifiability of the deletion operation.

[0117] Step S112 of this embodiment ensures that the old system file, associated logs, and residual data in the remaining disk space are completely cleared by forcibly releasing the file lock, performing multiple rounds of overwrite erasure, recording encrypted logs, and verifying the erasure effect, thereby avoiding the risk of anti-forensic investigation caused by simple deletion in the prior art.

[0118] Furthermore, as a refinement of the specific implementation of the above-described method for deleting USB device plug-in / plug-out records based on an operating system, the method for deleting USB device plug-in / plug-out records based on an operating system also involves the following specific steps:

[0119] Step 301: Due to Windows' strict control over the current registry, normal deletion is not possible; privilege escalation is required. The program is then packaged as a Windows service, implementing a Windows service event loop. The program is registered as a Windows service and configured to start automatically.

[0120] Step 302: Enumerate the USB plug-in / plug-out records under the Current ControlSet\Enum\USB sub-item in the system.

[0121] Step 303: Parse the PID and VID from the enumerated data to support the selection of whether a record needs to be deleted, and save the records that need to be deleted.

[0122] Step 304: Traverse and load all subkeys in the registry, match the subkey names, and delete the matched data. Since the system has exclusive access to the system file, it cannot be completely deleted from the underlying level. It can only be deleted safely using the Windows API. This deletion simply modifies the flag bit, but the data is still retained in the file.

[0123] Step 305: Clean up and export the Windows Registry's system key. Use the Windows API RegSaveKey to export the system table structure from the registry into a first file. This first file is a clean registry file without any deletion information. Then, use RegReplaceKey to instruct the system to replace the existing system registry file with the new first file.

[0124] After completing the deletion operation, remove the Windows service itself to prevent it from running again after a restart. Restarting the current system will replace the old system file in the registry with the new one. However, the old system file and its operation records still exist on the disk and need to be safely erased.

[0125] Step 306: Deleting the SYSTEM file will leave file information in the remaining disk space. A safe erasure process is performed. The old SYSTEM file from the registry of the system to be cleaned is loaded via the Windows API.

[0126] Step 307: Traverse all subkeys in the registry, match the subkey names, and use the Windows API to safely delete those that match the record rules exported in Step 3. After deletion, uninstall the registry.

[0127] Step 308: The old system file has been replaced by the new file. Windows no longer exclusively owns the old system file, so a second deletion can be performed on both the old system file and the system log file. Open the system file in binary mode. According to HIVE file attributes, an NK block begins with the identifier 0x6E6B. Use the KMP matching algorithm to find the content block starting with 0x6E6B in the file. Once found, take the first four bytes, convert them to an integer type, and determine whether they are positive or negative. A negative number indicates that the block has not been deleted and is skipped without processing. A positive number indicates that the block has been deleted and is added to the deletion list.

[0128] Step 309: Parse the position of the block content to be deleted. Extract the size of the NK block from the block header, parse the name at offset 0x50, and convert the name into a string. Match the string with the target strings DISK and USB: starting from the beginning of the string, compare each character with the target substring until the comparison is complete or a perfect match is found.

[0129] Step 310: For USB records that meet the rules, extract the specific values ​​of PID and VID parsed in step 303, combine the values ​​to form the target string PID_XXXX&VID_XXXX, and match the string with the target string again.

[0130] Step 311: For the matched content blocks to be cleaned, randomly select a string str of the same length and overwrite it with the string str starting from 0x50.

[0131] Step 312: After the data overwrite is complete, delete the old system file and log file directly via Windows API. Although some file information remains in the remaining space, the critical data has been erased, achieving the goal of complete deletion.

[0132] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0133] The following are embodiments of a system for deleting USB device plug-in / plug-out records based on an operating system, provided in this disclosure. This system and the methods for deleting USB device plug-in / plug-out records based on an operating system described above belong to the same inventive concept. For details not described in detail in the embodiments of the system for deleting USB device plug-in / plug-out records based on an operating system, please refer to the embodiments of the methods for deleting USB device plug-in / plug-out records based on an operating system described above.

[0134] like Figure 2 As shown, the system includes:

[0135] The permission setting module 201 is used to register the program used to delete USB device plug-in / plug-out records to a Windows service and grant it editing permissions to the Windows Registry.

[0136] The record enumeration module 202 is used to access the system registry, enumerate the subkeys under the USB path in the registry, and obtain the USB device plug-in / plug-out record data stored therein.

[0137] The parsing and filtering module 203 is used to parse the acquired record data, extract the device identifier PID and VID information, establish deletion condition filtering rules, and save the target record information.

[0138] The modification and deletion module 204 is used to traverse and load all the entries in the system registry, perform matching operations on the subkey names, and delete the matched data through the Windows application interface. Deletion only modifies the system flag bit.

[0139] The backup and file replacement module 205 is used to call the Windows API function RegSaveKey to export the registry system key as a first file, and then use the Windows API function RegReplaceKey to replace the current registry system file with the newly generated first file;

[0140] The file replacement and uninstallation module 206 is used to uninstall and delete the temporary registry service after the file replacement is completed, triggering the system restart so that the registry system file is completely replaced by the new first file.

[0141] The old file loading and deletion module 207 is used to load the old version of the system file in read-only mode, traverse its subkey names, perform secondary deletion on records that meet the deletion criteria and filter rules, and uninstall the registry.

[0142] The reading and block recognition module 208 is used to open the old version of the system file in binary reading mode, and based on the characteristics of the HIVE file format, identify all content blocks in the old version of the system file that start with nk; extract the first 4 bytes of data for each nk-marked content block, convert it into a deletion state with integer sign judgment, skipping content blocks with negative numbers and including content blocks with positive numbers in the scope to be processed;

[0143] The field extraction and matching module 209 is used to parse the name field of the content block to be processed, extract the string from the offset 0x50 in the name field, and determine whether it completely matches the DISK or USB substring.

[0144] The string combination matching module 210 is used to extract the corresponding PID and VID information from the records saved by the parsing and filtering module, combine them into the target string PID_XXXX&VID_XXXX, and perform matching with the string in the content block name field.

[0145] Data overwrite module 211, based on the target block matched by the name field, generates a random string of equal length according to the length information stored in the block header, and overwrites the original name data from offset 0x50;

[0146] The deletion and erasure module 212 is used to delete the old system file and associated log file through the Windows API after the name data has been overwritten, and to perform a safe erasure process on the remaining disk space to eliminate residual information.

[0147] like Figure 3 As shown, this application also provides an electronic device, including a display module 103, a memory 102, a processor 101, and a computer program stored in the memory and executable on the processor 101. When the processor 101 executes the program, it implements the steps of a method for deleting USB device plug-in / plug-out records based on an operating system.

[0148] In embodiments of the present invention, electronic devices include, but are not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments described and / or claimed herein.

[0149] In this embodiment, processor 101 may be implemented using at least one of an application-specific integrated circuit, a programmable logic device, a field-programmable gate array, a processor, a controller, a microcontroller, a microprocessor, or an electronic unit designed to perform the functions described herein. In some cases, such an implementation may be implemented within a controller. For software implementation, implementations such as processes or functions may be implemented with separate software modules that allow the performance of at least one function or operation. Software code may be implemented by a software application (or program) written in any suitable programming language, and the software code may be stored in memory and executed by the controller.

[0150] The display module 103 is used to display information input by the user or information provided to the user. The display module 103 may include a display panel, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like.

[0151] The memory 102 can be used to store software programs and various data. The memory 102 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0152] This application also provides a storage medium storing a computer program thereon, characterized in that, when the computer program is executed by a processor, it implements the steps of the method for deleting USB device plug-in / plug-out records based on an operating system.

[0153] The storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example,, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

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

Claims

1. A method for deleting USB device plug-in / plug-out records based on an operating system, characterized in that, The methods include: S101: Register the program used to delete USB device plug-in / plug-out records to a Windows service and grant it editing permissions to the Windows Registry; S102: Access the system registry, enumerate the subkeys under the USB path in the registry, and obtain the USB device plug-in / plug-out record data stored therein; S103: Parse the acquired record data, extract the device identifier PID and VID information, establish deletion condition filtering rules and save the target record information; S104: Traverse and load all registry entries in the system registry, perform matching operations on subkey names, delete the matched data through the Windows application interface, and only modify the deletion status flag of the corresponding registry entry in the system file to mark the never deleted state as deleted. S105: Call the Windows API function RegSaveKey to export the registry system key as a first file in the mode of exporting only valid items. The first file is a clean registry file that does not contain NK blocks that have been marked for deletion. Then, use the Windows API function RegReplaceKey to replace the current registry system file with the newly generated first file. S106: After completing the file replacement, uninstall and delete the temporary registry service, trigger a system restart, and completely replace the registry system file with the new first file; S107: Load the old version of the system file in read-only mode, traverse its sub-item names, and perform secondary deletion on records that meet the deletion criteria. S108: Open the old system file in binary reading mode, identify all content blocks in the old system file that start with nk based on the characteristics of the HIVE file format; extract the first 4 bytes of data for each nk-marked content block, convert it into a deletion state with integer sign judgment, skipping content blocks with negative numbers and including content blocks with positive numbers in the scope to be processed; S109: Parse the name field of the content block to be processed, extract the string from offset 0x50 in the name field, and determine whether it completely matches the DISK or USB substring. If the match is successful, execute S110. S110: Extract the corresponding PID and VID information from the record saved in step S103, combine them into the target string PID_XXXX&VID_XXXX, and perform matching with the string in the content block name field; S111: Based on the target block matched by the name field, generate a random string of equal length according to the length information stored in the block header, and overwrite the original name data from offset 0x50; S112: After completing the name data overwrite, delete the old system file and associated log file through the Windows API, and perform a secure erase on the remaining disk space to eliminate residual information.

2. The method for deleting USB device plug-in / unplug records based on an operating system according to claim 1, characterized in that, Step S104 also includes: The loaded system registry full quantum entries are classified according to the hierarchical structure of root entry - first-level sub-second-level sub-third-level sub-entry, and the set of sub-entries that are associated with the current control set\enumeration\universal serial bus sub-entry is filtered out; The system checks the current operating system's usage status of the system file associated with the registry. If the system file is found to be exclusively occupied by a system process, a temporary waiting mechanism is triggered. The usage status is rechecked every preset time until it is confirmed that the system file is in a non-completely exclusive state where the executable flag bit can be modified. Perform name matching operation on each of the classified related sub-items, compare the sub-item name with the deletion condition filtering rules established in step S103, record the storage path and current flag status of all target sub-items that match the name, and back up the flag status to the temporary storage area. For a target subkey whose name matches, a flag modification request is sent to the registry via the Windows application programming interface. The request is limited to updating the deletion status flag of the target subkey from never deleted to deleted, without affecting the original data storage area associated with the subkey. After modifying the flags of all target sub-items, reread the flag status of each target sub-item and compare it with the original flag status backed up in the temporary storage area to confirm that all target sub-items have been successfully modified to have the deleted flag.

3. The method for deleting USB device plug-in / unplug records based on an operating system according to claim 1, characterized in that, Step S105 also includes the following steps: Before calling RegSaveKey to export, the Windows API is used to check whether the current system file is locked by other processes. If it is detected, the conflicting process information is recorded and the export operation is terminated. When performing file replacement using the Windows API's replace function, set the flags for the replacement operation; After the replacement is completed, the metadata and key registry entries of the new system file are read through the Windows API to verify their consistency with the metadata and key data of the first file; Before deleting its own Windows service, the system cleans up any residual entries of the service in the registry via API and resets the system's access permissions to the old system file.

4. The method for deleting USB device plug-in / unplug records based on an operating system according to claim 1, characterized in that, Step S107 also includes the following steps: The system file detection tool is invoked to perform an integrity check on the old version of the system file, checking for missing bytes, corrupted data, or abnormal format. If an abnormality is detected, the system backup and recovery interface is invoked to extract the complete old version of the system file from the preset old system file backup copy, replace the abnormal file, and then proceed to the loading process. When loading an older version of the system file in read-only mode, a separate temporary memory isolation area is created through the system memory management interface to confine the loaded data of the older version of the system file within the isolation area; When traversing all subkeys of the registry corresponding to the old system file, the deletion condition filtering rules saved in S103 are called synchronously to perform full character matching on each subkey name, record the physical storage location of the matched subkeys in the old system file, and form a list of deletion locations. After performing a secure deletion operation using the Windows application interface on the matched sub-item, the deletion status flag of the sub-item is reread. If the flag does not become positive, the system checks for temporary memory locks, releases the locks, and then re-executes the secure deletion.

5. The method for deleting USB device plug-in / unplug records based on an operating system according to claim 1, characterized in that, Step S108 also includes the following steps: When identifying content blocks that start with nk, verify that the block length conforms to the HIVE file format specification; For each NK block, the timestamp field in the block header is also extracted to record the block creation / modification time; For NK blocks whose first 4 bytes are positive, check the upper block offset field in the block header. If the upper block offset points to an invalid address, mark the NK block as a single block and process it first. During the processing, an NK block processing log is generated, which records the starting offset, block size, deletion status, timestamp, and upper block offset information of each NK block. The log is stored in encrypted form using a system-unique identifier.

6. The method for deleting USB device plug-in / unplug records based on an operating system according to claim 1, characterized in that, Step S110 also includes the following steps: Before extracting and combining PID and VID information into a target string, verify whether the usage time of the device corresponding to the target string overlaps with the timestamp of the NK block in the old system file. If the device usage time partially overlaps with the time range of the NK block, perform subsequent matching operations. For the target string PID_XXXX&VID_XXXX, synchronously check whether its associated device path contains USBSTOR or USB substring. If the path does not contain the relevant substring, mark it as a non-USB device record and skip the match. For dynamic PID / VID scenarios, an extended matching rule is generated, which includes the format PID_XXXX&VID_YYYY, and is linked with the historical PID / VID information saved in step S103. During the matching process, the matching result, associated NK block offset, timestamp, and device path information for each target string are recorded to generate a matching log. For a successfully matched target block, a unique processing identifier is generated and linked with the data overwrite process in subsequent steps.

7. The method for deleting USB device plug-in / unplug records based on an operating system according to claim 1, characterized in that, Step S112 also includes the following steps: Before deleting the old system file and associated log file via Windows API, first verify whether the file is still locked by a system process. If a locking process exists, send a temporary termination request to the locking process. If the request times out, release the file handle through the system interface. When performing a secure erase on the remaining disk space, the first time a random string is overwritten, the second time a string of all zeros is overwritten, and the third time a string of all ones is overwritten. The overwriting scope includes the sectors originally occupied by the old system file and the storage area of ​​the associated log files. During the erasure process, record detailed information about the erasure operation; After erasing is complete, use a disk scanning tool to check if there is any residual data in the erased area. If any data blocks that have not been erased are detected, repeat the erasing operation until all target areas are completely covered. Generate a file residue verification report for the deleted old system files and log files.

8. A system for deleting USB device plug-in / plug-out records based on an operating system, characterized in that, The system is used to implement the method for deleting USB device plug-in / plug-out records based on an operating system as described in any one of claims 1 to 7; The system includes: The permissions settings module is used to register the program used to delete USB device plug-in / plug-out records to a Windows service and grant it editing permissions to the Windows Registry. The record enumeration module is used to access the system registry, enumerate the subkeys under the USB path in the registry, and obtain the USB device plug-in / plug-out record data stored therein. The parsing and filtering module is used to parse the acquired record data, extract device identifiers (PID and VID) information, establish deletion condition filtering rules, and save target record information. The modification and deletion module is used to traverse and load all the entries in the system registry, perform matching operations on the subkey names, delete the matched data through the Windows application interface, and only modify the deletion status flag of the corresponding registry entry in the system file, marking the never deleted state as deleted. The backup and file replacement module calls the Windows API function RegSaveKey to export the registry system key as a first file in the mode of exporting only valid items. The first file is a clean registry file that does not contain NK blocks that have been marked for deletion. Then, the Windows API function RegReplaceKey replaces the current registry system file with the newly generated first file. The file replacement and uninstallation module is used to replace files, uninstall and delete temporary registry services, trigger system restart, and completely replace the registry system file with the new first file. The old file loading and deletion module is used to load the old version of the system file in read-only mode, traverse its sub-item names, and perform secondary deletion on records that meet the deletion criteria. The reading and block recognition module is used to open the old version of the system file in binary reading mode. Based on the characteristics of the HIVE file format, it identifies all content blocks in the old version of the system file that start with nk. It extracts the first 4 bytes of data for each nk-marked content block and converts it into a deletion state with integer sign judgment. Content blocks with negative numbers are skipped, and content blocks with positive numbers are included in the scope to be processed. The field extraction and matching module is used to parse the name field of the content block to be processed, extract the string from the offset 0x50 in the name field, and determine whether it completely matches the DISK or USB substring. The string combination matching module is used to extract the corresponding PID and VID information from the records saved by the parsing and filtering module, combine them into the target string PID_XXXX&VID_XXXX, and perform matching with the string in the content block name field; The data overwrite module, based on the target block matched by the name field, generates a random string of equal length according to the length information stored in the block header, and overwrites the original name data from offset 0x50. The deletion and erasure module is used to delete the old system file and associated log file via Windows API after overwriting the name data, and to perform a safe erasure process on the remaining disk space to eliminate residual information.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method for deleting USB device plug-in / plug-out records based on an operating system as described in any one of claims 1 to 7.

10. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the method for deleting USB device plug-in / plug-out records based on an operating system as described in any one of claims 1 to 7.

Images