System attribute simulation method and system based on a honkong NEXT simulator

Abstract

The application relates to the technical field of computer software, in particular to a system attribute simulation method and system based on a HongMeng NEXT simulator. The method comprises the following steps: loading a read-only copy of a HongMeng NEXT system image of a target test environment in a controlled host, analyzing an image file system to locate a user configuration file, a system attribute configuration file and a security configuration file; adding a superuser configuration item in the user configuration file, setting a user identifier and a group identifier as zero, and recording the creation state of the configuration item; declaring an enabled device connector debugging mode and a global debugging flag in the system attribute configuration file, declaring the running parameters of a lenient mode in the security configuration file, and recording the effective states of the debugging mode and the security mode respectively. Through controllable simulator Root technology, a HongMeng NEXT simulator analysis environment with high privilege and depth is successfully constructed.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and in particular to a system attribute simulation method and system based on the HarmonyOS NEXT simulator. Background Technology

[0002] HarmonyOS NEXT is Huawei's next-generation operating system. Unlike the traditional HarmonyOS based on the Linux kernel, HarmonyOS NEXT adopts a completely new self-developed kernel architecture, eliminating its dependence on the Android ecosystem. During the development and testing of HarmonyOS NEXT, developers and security researchers need to conduct in-depth testing, application compliance checks, and security vulnerability analysis. These tasks require obtaining high-level system privileges to access underlying system resources.

[0003] However, HarmonyOS NEXT employs strict security mechanisms in its design. First, the system does not provide superuser privileges similar to root in Linux by default; all users run with limited permissions and cannot access the system's core directories and critical configuration files. Second, the HarmonyOS NEXT emulator performs an integrity check on the system image upon startup. If any modification to the image file is detected, the emulator automatically restores the system to its initial state, meaning any customized modifications to the system are not persistent. While this design ensures system security and stability, it also presents significant challenges for development, testing, and security research. Summary of the Invention

[0004] Therefore, it is necessary for the present invention to provide a system attribute simulation method and system based on the HarmonyOS NEXT simulator to solve at least one of the above-mentioned technical problems.

[0005] To achieve the above objectives, a system attribute simulation method based on the HarmonyOS NEXT simulator includes the following steps:

[0006] Step S1: Load a read-only copy of the HarmonyOS NEXT system image of the target test environment into the controlled host, and parse the image file system to locate the user profile, system property profile, and security profile;

[0007] Step S2: Add a super user configuration item to the user configuration file, set both the user identifier and the group identifier to zero, and record the creation status of the configuration item;

[0008] Step S3: Declare the device connector debugging mode and global debugging flag enabled in the system property configuration file, declare the running parameters of the permissive mode in the security configuration file, and record the effective status of the debugging mode and the security mode respectively; when the creation status and the effective status of the debugging mode and the security mode are both true, generate the super privilege activation flag.

[0009] Step S4: When the super privilege activation flag is true, disassemble and analyze the emulator startup tool, locate the image integrity verification function, insert a sequence of instructions that force a return to success at its conditional jump point, and generate the modified startup tool file;

[0010] Step S5: Use the startup tool file to load the system image to start the emulator, and connect to the emulator as a super user to verify super user privileges.

[0011] This invention also provides a system attribute simulation system based on the HarmonyOS NEXT simulator, used to execute the above-described system attribute simulation method based on the HarmonyOS NEXT simulator. The system attribute simulation system based on the HarmonyOS NEXT simulator includes:

[0012] The image parsing module is used to load a read-only copy of the HarmonyNEXT system image of the target test environment into the controlled host, and parse the image file system to locate the user configuration file, system property configuration file and security configuration file.

[0013] The permission configuration module is used to add a super user configuration item to the user configuration file, set both the user identifier and the group identifier to zero, and record the creation status of the configuration item.

[0014] The debug activation module is used to declare the enabling of device connector debug mode and global debug flag in the system property configuration file, declare the running parameters of permissive mode in the security configuration file, and record the effective status of debug mode and security mode respectively; when the creation status and the effective status of debug mode and security mode are both true, a super privilege activation identifier is generated.

[0015] The verification and modification module is used to disassemble and analyze the emulator startup tool when the super privilege activation flag is true, locate the image integrity verification function, insert a sequence of instructions that force a return to success at its conditional jump, and generate the modified startup tool file.

[0016] The startup verification module is used to load the system image using the startup tool file, start the emulator, and connect to the emulator as a superuser to verify superuser privileges.

[0017] This invention constructs a complete chain from image parsing to superuser privilege acquisition by loading a read-only copy of the HarmonyOS NEXT system image into the target test environment, parsing user configuration files, system property configuration files, and security configuration files, and performing systematic operations on the mounted image to verify user identifiers, system properties, boot tool integrity, and the emulator boot process. At the user configuration level, a new superuser configuration item is added, embedding the superuser identity (UID=0 / GID=0) into the image, directly building a controllable highest-privilege account for the emulator environment. By enabling device connector debug mode and global debug flags in the system property configuration file and declaring permissive mode runtime parameters in the security configuration file, the effective status of debug and security modes is clearly defined, thus enabling the emulator environment to enter a controllable and open debug state. Furthermore, once the superuser privilege activation flag is established, the boot tool is disassembled, the image integrity verification function is located, a forced success instruction sequence is inserted into its jump instructions, and a modified boot tool is generated. Finally, the system image is loaded through this boot tool, connected in the emulator as a superuser, and UID=0 is verified, thereby completing the acquisition of superuser privileges for the image boot process.

[0018] Compared to traditional methods that simply modify user configurations or enable debug mode on emulators or real devices, this method integrates image parsing, mounting, attribute recognition, startup tool modification, and permission verification into a coherent process. This makes obtaining maximum privilege control in the HarmonyOS NEXT emulator environment more feasible, systematic, and traceable. Its advantages include: First, read-only mounting ensures the original image is not corrupted and can be safely rolled back, improving operational security. Second, by identifying user configuration formats, user identifier field locations, system attribute configuration formats, and security policy formats, the solution has good version compatibility and does not rely on hard-coded paths specific to a particular version. Third, by disassembling and modifying the startup tool integrity verification function, it overcomes the limitations of traditional methods that only modify user files without changing the startup tool's verification logic, improving the reliability of obtaining super privileges in the emulator environment. Finally, by explicitly recording the configuration item creation status, debug mode activation status, security mode activation status, and activation identifiers, the entire process is traceable and auditable, facilitating testing, verification, and patent documentation. Overall, this method not only provides a complete, well-defined, and controllable implementation path for simulating system attributes in the HarmonyOS NEXT simulator environment, but also provides a reliable means for researching and testing key aspects such as system-level permissions, startup verification, and configuration modification in the simulation environment, thereby significantly improving test coverage, debugging efficiency, and the feasibility of permission control. Attached Figure Description

[0019] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0020] Figure 1 This is a flowchart illustrating the steps of a system attribute simulation method based on the HarmonyOS NEXT simulator according to the present invention.

[0021] Figure 2 This is a timing diagram of a system attribute simulation process according to an embodiment of the present invention;

[0022] Figure 3 This is a schematic diagram of a system attribute simulation system based on the HarmonyOS NEXT simulator according to the present invention. Detailed Implementation

[0023] The technical method of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0024] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0025] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0026] To achieve the above objectives, please refer to Figures 1 to 3 This invention provides a method for simulating system attributes based on the HarmonyOS NEXT simulator, the method comprising the following steps:

[0027] Step S1: Load a read-only copy of the HarmonyOS NEXT system image of the target test environment into the controlled host, and parse the image file system to locate the user profile, system property profile, and security profile;

[0028] Step S2: Add a super user configuration item to the user configuration file, set both the user identifier and the group identifier to zero, and record the creation status of the configuration item;

[0029] Step S3: Declare the device connector debugging mode and global debugging flag enabled in the system property configuration file, declare the running parameters of the permissive mode in the security configuration file, and record the effective status of the debugging mode and the security mode respectively; when the creation status and the effective status of the debugging mode and the security mode are both true, generate the super privilege activation flag.

[0030] Step S4: When the super privilege activation flag is true, disassemble and analyze the emulator startup tool, locate the image integrity verification function, insert a sequence of instructions that force a return to success at its conditional jump point, and generate the modified startup tool file;

[0031] Step S5: Use the startup tool file to load the system image to start the emulator, and connect to the emulator as a super user to verify super user privileges.

[0032] Furthermore, step S1 includes the following steps:

[0033] Step S11: Locate the pre-acquired HarmonyOS NEXT system image file in the emulator installation directory of the controlled host;

[0034] In one embodiment, the HarmonyOS NEXT emulator software is installed on the controlled host, in a directory such as / opt / harmony_next_emulator / images / . A pre-downloaded or copied image file, such as system-image-harmonyos-next-5.0.1-phone_x86.img, is located in this directory.

[0035] For example, the file harmony_next_5.0.1_phone_x86.img is found in the path / opt / harmony_next_emulator / images / .

[0036] It should be noted that the "emulator installation directory" here refers to the installation location of the emulator software on the controlled host, which is used to store the system image, not the storage partition where the actual device runs.

[0037] Step S12: Read the file header information of the HarmonyOS NEXT system image file, extract the file system type identifier from the file header information, and record the file system type identifier as the image format type;

[0038] In one embodiment, the test script opens the aforementioned image file in read-only mode, reads the first few bytes (e.g., the first 512 bytes), and analyzes whether the header contains identifiers such as "Linux rev 1.0 ext4 filesystem data" or "EROFS" (referencing the common file system formats ext4 or EROFS in the HarmonyOS NEXT image). For example, if the header contains the string "Linux rev 1.0 ext4 filesystem data,UUID=…", then "ext4" is recorded as the image format type.

[0039] It should be noted that the HarmonyOS NEXT image may use a read-only file system such as EROFS as the system partition, so this step of the program should support the recognition of multiple file system types.

[0040] Step S13: Select an image parsing tool according to the image format type, use the image parsing tool to create a read-only copy of the system image, mount the read-only copy to the temporary directory of the controlled host, and obtain the mount root path.

[0041] In one embodiment, if the identified image format type is "erofs", then a parsing tool suitable for erofs is selected. First, the original image is copied as a read-only copy on the controlled host, for example, copying harmony_next_5.0.1_phone_x86.img to harmony_next_copy.img, to prevent modification of the original image. Then, a temporary mount directory is created on the controlled host, for example, / mnt / harmony_next_temp / .

[0042] For example, execute the mount tool erofs-fuse harmony_next_copy.img / mnt / harmony_next_temp / (assuming the emulator environment supports similar mount tools). After successful mount, the controlled host obtains the mount root path / mnt / harmony_next_temp / .

[0043] Furthermore, step S1 also includes the following steps:

[0044] Step S14: Starting from the mount root path, traverse the directory tree structure to obtain the system configuration directory. Search for the configuration file containing user account information in the system configuration directory. When a file whose filename contains the keyword of the user password is found, the user configuration file is obtained.

[0045] In one embodiment, starting from the mount root path / mnt / harmony_next_temp / , a script or tool is used to recursively traverse the directory tree (including common system configuration paths such as etc / , data / system / , config / , etc.).

[0046] For example, the filename users_shadow.db is found in the path / mnt / harmony_next_temp / data / system / users / , where "shadow" matches the "user password keyword". Therefore, the path ... / users_shadow.db is recorded and identified as the "user profile".

[0047] It should be noted that the configuration file path in the HarmonyOS NEXT system may differ from that in general Linux, so keyword matching should be flexible and the traversal should cover all potential subdirectories.

[0048] Step S15: Locate the configuration file containing system property declarations in the system configuration directory. When a file whose filename contains the keyword "default value of property" is found, the system property configuration file is obtained.

[0049] In one embodiment, within the system-config scope under the mounted image path (e.g., / mnt / harmony_next_temp / etc / sysconfig / or / mnt / harmony_next_temp / vendor / config / ), the script searches for files whose filenames contain keywords such as "default", "system_properties", "prop_default", and "sys_attr".

[0050] For example, the path to system_properties_default.conf was found in / mnt / harmony_next_temp / etc / sysconfig / , so it was noted down and designated as "system properties configuration file".

[0051] It should be noted that the system property files of HarmonyOS NEXT may differ from those of traditional Android or Linux systems. Their naming conventions, directory structures, or key-value pair formats may have HarmonyOS characteristics, so the search rules should be adapted to the characteristics of this platform.

[0052] Step S16: Locate the configuration file containing security policy definitions in the system configuration directory. When a file with the keyword "security configuration" in its filename is found, the security configuration file is obtained.

[0053] In one embodiment, the configuration directory under the mount root path (such as / mnt / harmony_next_temp / etc / security / or / mnt / harmony_next_temp / vendor / config / security / ) is also searched for filenames containing keywords such as "security_policy", "sec_config", "policy_def", and "safemode_config".

[0054] For example, if security_policy.conf is found in the path / mnt / harmony_next_temp / etc / security / , then record the path and designate it as the "security configuration file".

[0055] It should be noted that the security policy definitions in the HarmonyOS NEXT system may differ from those in traditional systems (such as microkernel architecture, modular security policies, etc.). Therefore, the traversal should fully cover all possible directories, and keyword matching should be based on the security configuration naming conventions of HarmonyOS NEXT.

[0056] Furthermore, step S2 includes the following steps:

[0057] Step S21: Read the configuration lines in the user configuration file, parse the field separator and the number of fields in each configuration line, and record the field separator and the number of fields as the user configuration format;

[0058] In one embodiment, the system first opens the "user configuration file" located in the preceding steps (e.g., / data / system / users / users_shadow.db or / etc / accounts / user_passwd.conf within the HarmonyOS NEXT emulator image) in read-only mode and reads all configuration lines line by line. For each configuration line, such as "admin:x:1000:1000:Administrator: / home / admin: / bin / sh", the system identifies it by analyzing the field separator used in the line (a colon ":" in this example) and the number of fields (7 in this example): the field separator is ":" and the number of fields is 7. The system records these two pieces of information—"field separator = ':'" and "number of fields = 7"—in a data structure as the "user configuration format" of the user configuration file.

[0059] For example, the system records "User configuration format: delimiter ':', number of fields 7". It should be noted that the "number of fields" here should include the total number of fields separated by delimiters in each line. The "delimiter" may be ":", ",", "|", etc., depending on the image version or system configuration. Therefore, the reading program should be able to detect multiple possibilities.

[0060] Step S22: Identify fields containing user identifier values ​​and group identifier values ​​in the existing configuration lines, determine the positions of the user identifier field and group identifier field by the numerical characteristics of the field content, and record the positions of the two fields as identifier field position information;

[0061] In one embodiment, the system continues to traverse each configuration line of the user profile, splitting each line's fields using the user configuration format identified in S21 (e.g., "separator ':', number of fields 7"). Taking the example line "admin:x:1000:1000:Administrator: / home / admin: / bin / sh" as an example, after splitting, the system obtains a field array ["admin","x","1000","1000","Administrator"," / home / admin"," / bin / sh"]. The system analyzes the field content to determine which fields might be "User Identifier (UID)" and "Group Identifier (GID)"—for example, checking if the field content is a numeric value (e.g., "1000") and consistent with the system's standard user identifier value range. Assuming the third field ("1000") is identified as a UID and the fourth field ("1000") is identified as a GID, the system records "User Identifier field position = third field" and "Group Identifier field position = fourth field".

[0062] For example, the system records "UID in field 3, GID in field 4".

[0063] It should be noted that this judgment depends on the field value being numerical and falling within the range of common UID / GID. If the system uses atypical numerical values ​​or custom formats, the program needs to have an exception handling or manual confirmation mechanism.

[0064] Step S23: Read the configuration line of the default shell user in the user configuration format, and extract the user identifier value and group identifier value of the user from the identifier field position information.

[0065] In one embodiment, the system searches the user profile for the configuration line that identifies the default shell user (e.g., the username is "shell" or "root" or the default account name in the image, "default_user"). Assume the line "default_user: x:2000:2000:Default Shell: / home / default_user: / bin / sh" is found. The system uses the identifier field positions recorded in step S22 (UID in field 3, GID in field 4) to extract the third field value "2000" from the array as the user identifier value and the fourth field value "2000" as the group identifier value.

[0066] For example, the system determines that the default shell user's UID=2000 and GID=2000.

[0067] It should be noted that this step assumes that the configuration line for the default shell user can be explicitly identified (e.g., by the username keyword "shell"). If it cannot be automatically identified, manual confirmation or a default username logic should be provided.

[0068] Furthermore, step S2 also includes the following steps:

[0069] Step S24: Copy the existing configuration line as a template line. In the template line, change the username field to the super user name, change the user identifier field to the value zero, change the group identifier field to the value zero, keep the contents of other fields unchanged, and generate the super user configuration line.

[0070] In one embodiment, the system selects an existing configuration line (e.g., "default_user:x:2000:2000:DefaultShell: / home / default_user: / bin / sh") from the user configuration file as a template. The system copies the entire line to the "template line". Then, depending on the requirements, it replaces the username field (in this example, the first field "default_user") with "superuser" or "root" as the superuser name; at the same time, it modifies the user identifier field (i.e., the third field) to "0", modifies the group identifier field (i.e., the fourth field) to "0", and leaves the remaining fields (such as the password placeholder "x", the comment field "Default Shell", the home directory " / home / default_user", and the shell path " / bin / sh") unchanged. Finally, a new configuration line "superuser:x:0:0:Default Shell: / home / default_user: / bin / sh" is generated.

[0071] For example, generate the superuser configuration line and prepare it for writing.

[0072] It should be noted that the template row field order, separators and format are consistent with the user configuration format, and the settings of the super user name, UID and GID meet the system specifications and the requirements that the simulator can recognize; if the position of the username field is different, it should be adjusted according to the position information in step S22.

[0073] Step S25: Verify that the number of fields and the delimiter of the super user configuration line conform to the user configuration format. When the format verification passes, append the super user configuration line to the user configuration file.

[0074] In one embodiment, the system first checks whether the generated superuser configuration line conforms to the previous user configuration format (e.g., "separator ':'", number of fields 7). The system splits the new line ["superuser","x","0","0","Default Shell"," / home / default_user"," / bin / sh"], verifying that the number of fields is indeed 7 and the separator used is ":". If the verification passes, the system appends the new line to the end of the user configuration file.

[0075] For example, after opening the configuration file, add a new line at the end: superuser:x:0:0:Default Shell: / home / default_user: / bin / sh.

[0076] It should be noted that file backups or version control should be performed before appending to prevent accidental writes from causing abnormal image configurations. In addition, write operations should maintain the original file permissions, format, and encoding to avoid format corruption.

[0077] Step S26: Record the timestamp of the file modification completion, record the timestamp as the time of user configuration modification, generate a super user configuration item creation success identifier, and record the identifier as the creation status of the configuration item.

[0078] In one embodiment, after confirming that the superuser configuration line has been successfully appended, the system obtains the current timestamp, with an example value of "2025-08-29 14:35:22". The system records this timestamp in a log or status structure as the last modification time of the user configuration file. Subsequently, the system generates a "superuser configuration item creation success identifier" (e.g., status code "SU_CONFIG_CREATED") and records it together with the aforementioned timestamp as the creation status of the configuration item.

[0079] For example, record "Modification time = 2025-08-29 14:35:22; Creation status = Success".

[0080] It should be noted that this record should be included in the overall system log management or auditing mechanism for future reference; if the append fails or the format verification fails, the failure status should be recorded, and a rollback or alarm process may be triggered.

[0081] Furthermore, step S3 includes the following steps:

[0082] Step S31: Read the property declaration lines in the system property configuration file, parse the key-value separator of each property declaration line, and record the key-value separator as the property separator;

[0083] In one embodiment, the system first opens the "system properties configuration file" located in the preceding steps (e.g., path / system / etc / sys_properties.conf or / mnt / harmony_next_temp / etc / sysconfig / system_properties_default.conf under the image mount path). The system reads each property declaration line in the file line by line, such as debug.connector.enabled=false or global.debug.flag:false. For each declaration line, the system identifies the separator used between the key and value (such as "=", ":", or "=" with a space) and saves the separator as the "property separator".

[0084] For example, if debug.connector.enabled=false is read, then the key-value pairs are identified using "=" (including spaces) as the separator, and the record attribute separator is "=".

[0085] It should be noted that the attribute separator may vary depending on the system version or image customization (such as ":" or "=" without spaces), so the identification logic should include a variety of possible separator characters and their variations.

[0086] Step S32: Parse the attribute declaration line using the attribute separator, extract the device connector debug mode attribute and the global debug flag attribute, and record the effective status of the debug mode;

[0087] In one embodiment, the system splits the key and value of each attribute declaration line according to the attribute separator (e.g., "=") recorded in step S31. For example, debug.connector.enabled=false is split into the key "debug.connector.enabled" and the value "false". The system continues to traverse all declaration lines, identifying items whose key names contain keywords such as "connector" or "debug.flag", such as "debug.connector.enabled" and "global.debug.flag". When both items are identified, the system reads their corresponding values: if "debug.connector.enabled=true" and "global.debug.flag=true", the system records "debug mode enabled" as true; otherwise, it records it as false.

[0088] For example, if debug.connector.enabled=true and global.debug.flag=true exist in the file, the system determines that debug mode is enabled.

[0089] It should be noted that keyword matching should be based on the attribute naming conventions that may be used in the HarmonyOS NEXT system, and prefix / suffix spaces should be removed during splitting to prevent parsing errors.

[0090] Step S33: Declare the operating parameters of the tolerant mode in the security configuration file, and record the effective status of the security mode;

[0091] In one embodiment, the system opens the "security configuration file" located in the previous steps (e.g., path / system / etc / security / security_policy.conf or mount path / mnt / harmony_next_temp / etc / security / security_policy.conf). The system writes or modifies a declaration configuration in this file, such as security.mode=permissive (where "permissive" indicates permissive mode). The system then reads this configuration line and determines whether it has taken effect: if the security.mode value is indeed "permissive", the "security mode effective status" is recorded as true; if it is still "enforcing" or another value, it is recorded as false.

[0092] For example, after modifying and confirming `security.mode=permissive` in the file, the system confirms that the security mode is enabled. It should be noted that "permissive mode" in the HarmonyOS NEXT environment may be represented by a specific name or value (such as "permissive", "allow_all", "disabled_enforcement", etc.). When implementing this mode, the correct parameters and values ​​should be confirmed based on the specific version.

[0093] Step S34: When the creation status and the effective status of debug mode and safe mode are both true, generate a super privilege activation identifier.

[0094] In one embodiment, the system first checks three states recorded in the preceding steps: whether the user configuration item "creation status" is true, whether the debug mode is enabled status is true, and whether the security mode is enabled status is true. If all three are true, the system generates a "super privilege activation flag" (e.g., a boolean value true or an internal status code "SUPER_PERMISSION_ACTIVATED") and records it in the permission configuration module.

[0095] For example, if creation status = true, debug mode enabled = true, and safe mode enabled = true, then record "super privilege activation flag = true".

[0096] It should be noted that once the activation identifier is generated, it should be used as a control condition to trigger the modification of the startup tool behavior in subsequent steps (such as steps S41 to S45); if any state is false, the identifier should not be generated and the reason for failure should be recorded.

[0097] Furthermore, step S32 includes the following steps:

[0098] Step S321: Parse the attribute declaration line according to the attribute separator, extract the attribute name and attribute value, search for the device connector mode attribute in the attribute name, and when the device connector mode attribute is found, recombine the device connector mode attribute name and full mode enable value using the attribute separator to generate a new attribute declaration line and replace the original declaration line.

[0099] In one embodiment, the system first opens the previously located "system property configuration file" (e.g., / mnt / harmony_next_temp / etc / sysconfig / system_properties_default.conf in the image mount path). The system reads each property declaration line line by line, splitting each line into a property name and a property value using a "property separator" (e.g., "="). The system then iterates through these property names, searching for entries whose names contain keywords such as "connector" or "device.connector" (e.g., debug.connector.enabled). Once the device connector mode property is found, the system generates a new declaration line: based on the original property name, but modifying its value to an enabled state (e.g., "true").

[0100] For example, the original line `debug.connector.enabled=false` is replaced with `debug.connector.enabled=true`. The system then replaces the original line with the new declaration and saves it back to the configuration file.

[0101] It should be noted that the so-called "full-mode enable value" should be consistent with the legal enable status corresponding to the system attribute (such as "true" / "1" / "enabled"). The program should predefine or read the set of legal enable values ​​to prevent accidental replacement.

[0102] Step S322: Parse the attribute declaration line according to the attribute separator, extract the attribute name and attribute value, search for the global debug flag attribute in the attribute name, and when the global debug flag attribute is found, recombine the global debug flag attribute using the attribute separator to generate a new attribute declaration line and replace the original declaration line.

[0103] In one embodiment, the system continues to read line by line in the same system property configuration file, with each line split into property name and value based on property delimiters. The system searches for property items whose names contain keywords such as "global.debug.flag" or "debug.global.enabled". Once the global debug flag property is identified, for example, if the original line is global.debug.flag=false, the system modifies its value to enabled (e.g., "true") and generates a new declaration line global.debug.flag=true, then replaces the original line and saves it to the configuration file.

[0104] For example, the original global.debug.flag=false is replaced with global.debug.flag=true.

[0105] It should be noted that before performing the replacement, you should verify whether the attribute is indeed in the category of "global debugging flags" to avoid mistakenly replacing other attributes; in addition, the overall format of the file (such as delimiters, indentation, and comments) should be kept consistent with the original file to prevent the file from being identified by the system as having an abnormal format.

[0106] Step S323: Reopen the system property configuration file to verify whether the values ​​of the device connector mode property and the global debug flag property have been modified to the enabled state. When both properties are enabled, generate a debug mode activation flag and record the flag as the activation state of debug mode.

[0107] In one embodiment, after completing the above replacement operation, the system closes and reopens the "System Property Configuration File" to read the new configuration content. The system finds the two items debug.connector.enabled and global.debug.flag, and confirms that their values ​​are both "true" (or the program-defined enabled value). If the verification is successful, i.e., "Device Connector Mode Property = Enabled" and "Global Debug Flag Property = Enabled", the system generates a boolean flag "Debug Mode Enabled Flag = True", and records this flag along with the current timestamp, configuration file path, and other information to the status log or permission configuration module.

[0108] For example, the system records "Debug mode enabled = true".

[0109] It should be noted that this verification process should take into account the possibility of cached or duplicate entries in the configuration file (e.g., two global.debug.flag lines). The program should prioritize reading the latest valid line or ignore comments / duplicates. In addition, if any attribute value is not modified to be enabled, "debug mode enabled = false" should be logged and the corresponding error or recovery mechanism should be triggered.

[0110] Furthermore, step S33 includes the following steps:

[0111] Step S331: Read the security policy declaration lines in the security configuration file, parse the parameter names and parameter value separation methods of each policy declaration line, and record the separation methods as parameter separators;

[0112] In one embodiment, the system first accesses a pre-defined security configuration file (e.g., / mnt / harmony_next_temp / etc / security / security_policy.conf under the mounted root path). The system opens the file in read-only mode and reads each security policy declaration line by line, such as security.mode:enforcing or sec.enhance.module=enabled. For each declaration, the system identifies the separator used between the parameter name and the parameter value, such as ":" or "=". The system records the detected separator in an internal variable as a "parameter separator" for subsequent parsing.

[0113] For example, if security.mode:enforcing is read, the separator is identified as ":".

[0114] It should be noted that the "parameter separator" may vary depending on the version or manufacturer (e.g., it may be "=", ":", with or without spaces), so the parsing logic should recognize multiple possible forms.

[0115] Step S332: Parse the policy declaration line according to the parameter separator, extract the parameter name and parameter value, search for the running mode parameter of the security enhancement module in the parameter name, and when the running mode parameter is found, recombine the running mode parameter name and tolerance mode value using the parameter separator to generate a new policy declaration line and replace the original security policy declaration line;

[0116] In one embodiment, the system splits each security policy declaration line into a parameter name and a parameter value based on a recorded parameter separator (e.g., ":"). For example, for security.mode:enforcing, it splits the name into "security.mode" and the value "enforcing". The system searches the name for keywords containing the security enhancement module's operating mode, such as "security.mode" or "sec.enhance.module.mode". Once the operating mode parameter is identified, the system generates a new declaration line: using the original parameter name and modifying the parameter value to the corresponding value for "permissive mode" (e.g., "permissive").

[0117] For example, replace `security.mode:enforcing` with `security.mode:permissive`. The system will replace the corresponding line in the original file with this new declaration line.

[0118] It should be noted that the "permissive mode value" should be based on the legal values ​​defined in the HarmonyOS NEXT system (such as "permissive", "allow_all", "disabled_enforcement", etc.). The correct value should be confirmed before implementation. At the same time, the replacement operation should retain any comments or formatting that may exist in the original file to avoid damaging the overall file structure.

[0119] Step S333: Reopen the security configuration file to verify whether the value of the running mode parameter has been modified to the tolerance mode. When the parameter value is the tolerance mode, generate a security mode effective flag and record the flag as the effective status of the security mode.

[0120] In one embodiment, after completing the replacement operation, the system closes the security configuration file and reopens it to read the current content. The system locates the operating mode parameter (such as security.mode) and reads its value; if its value corresponds to "permissive mode" (e.g., "permissive"), the system confirms that the security mode has taken effect and generates a "security mode effective flag = true". The system records this flag in the status logging module, including the verification time, configuration file path, and modified version.

[0121] For example, if security.mode:permissive is read, the system records "security mode enabled = true".

[0122] It should be noted that this verification step should take into account that the configuration file may contain multiple version lines, comments, or file caching. The program should prioritize reading the latest valid line. If the value is not the expected forgiving mode, "Safe mode enabled = false" should be recorded and a rollback or error handling process may be triggered.

[0123] Furthermore, step S4 includes the following steps:

[0124] Step S41: When the super privilege activation flag is true, disassemble and analyze the emulator launch tool to obtain the tool code structure;

[0125] In one embodiment, the emulator's launcher file (e.g., "emulator_launcher_harmony_next.bin") is located in the emulator's installation directory on the controlled host. Then, a disassembler (e.g., IDAPro, Ghidra) is used to load this binary file and perform static disassembly analysis, function boundary identification, string reference searching, and other operations to generate the code structure model of the launcher. This model should include a function list, a string constant table, a control flow graph, jump relationships, and other information.

[0126] For example, a Ghidra scan revealed that the function check_image_integrity() was identified as an integrity verification function in the startup process.

[0127] Step S42: Search for strings containing integrity verification keywords in the tool code structure, locate the function address that references the string, and record the function address as the entry address of the verification function;

[0128] In one embodiment, within the aforementioned code structure, a string table is searched for keywords indicating integrity verification failure, such as "Integrity checkfailed" or "verify image hash," to determine the function that references that string. For example, if the string "Image integrity failure" is found to appear at function entry address 0x0050F200, this address is recorded as the "verification function entry address."

[0129] Step S43: Starting from the entry address of the verification function, traverse the instruction sequence in the tool code structure to identify the location of the comparison instruction that performs the numerical comparison, and use it as the comparison instruction address; after identifying the comparison instruction address, execute the conditional jump instruction location according to the comparison result.

[0130] In one embodiment, starting from the entry address of the verification function (0x0050F200), the disassembled instruction sequence is traversed backward to find the location where a numerical comparison (e.g., CMP instruction, TEST instruction) is executed, and this location is recorded as the "comparison instruction address" (e.g., 0x0050F238). Subsequently, the process of finding conditional jump instructions (e.g., BNE, BEQ, JNE, etc.) to determine whether the verification has failed or succeeded based on the comparison result is continued, and this address is recorded as the "jump instruction address" (e.g., 0x0050F244).

[0131] For example, disassembly reveals: 0x0050F238: CMP R0,

[0132] 0x0050F23C:BEQ 0x0050F260

[0133] Therefore, the address of the location comparison instruction is 0x0050F238, and the address of the jump instruction is 0x0050F23C.

[0134] It should be noted that the actual architecture may be ARM64 or other architectures, with different instruction sets and registers; the implementation should be adapted to the architecture of the actual emulator startup tool.

[0135] Step S44: Insert an instruction sequence that forces the return value to be successful at the jump instruction location, and generate the modified instruction content, wherein the instruction sequence includes an instruction to set the return register to the success flag value and an instruction to return immediately;

[0136] In one embodiment, a new instruction sequence is inserted at the jump instruction location (0x0050F23C) to force the integrity check function to return "success". For example, in the ARM64 architecture, this jump instruction can be replaced with:

[0137] MOV X0,#0 ; A return value of 0 indicates success.

[0138] RET ; Return immediately

[0139] Then, fill the remaining bytes with NOP (No Operation) to maintain code alignment. Generate the modified instruction content and record the modified version.

[0140] For example, the original BEQ 0x0050F260 is replaced.

[0141] It should be noted that the insertion instructions must be compatible with the target architecture's calling convention, return register, and alignment rules; incorrect modifications may cause the startup tool to malfunction or the simulator to fail to start.

[0142] Step S45: Write the modified instruction content into the jump instruction position of the simulator startup tool file, save the modified startup tool file, and generate the modified startup tool file.

[0143] In one embodiment, the emulator launcher file (“emulator_launcher_harmony_next.bin”) is opened in binary write mode, the file offset corresponding to the jump instruction address (0x0050F23C) is located, and the new instruction bytes are written to this location. The modified file is then saved as “emulator_launcher_harmony_next_patched.bin”. The modified launcher is then used to load the target image and launch the emulator, connecting as a superuser and verifying that the user UID is 0.

[0144] For example: After starting the emulator, execute the id command in the console. It will display uid=0 (root), confirming that you have obtained super user privileges.

[0145] It should be noted that this operation involves modifying the integrity verification mechanism. In the actual HarmonyOS NEXT system, it may be protected by firmware, signature, or hardware root of trust (such as HUK, eFuse mechanism). Therefore, the emulator version, signature verification mechanism, and compliance and legality should be considered when implementing it.

[0146] Of particular importance is that step S41 is as follows:

[0147] When the superuser privilege activation flag is true, locate the emulator startup tool file in the emulator installation directory of the controlled host;

[0148] An acute disassembly analysis of the emulator startup tool file is performed to generate disassembled code text containing machine instructions, which is recorded as the tool code structure.

[0149] In one embodiment, when the "superuser activation flag" is true in the current step, it means that the superuser configuration item has been successfully created, the system property debug mode is in effect, and the system security mode (forgiving mode) is in effect. Therefore, the emulator launcher file (e.g., named harmony_next_launcher.bin) is located in the emulator installation directory of the controlled host (assuming the path is / opt / harmonynext_emulator / bin / ). Subsequently, a disassembler (such as Ghidra or IDAPro) is used to perform static disassembly analysis on the launcher file, expanding the disassembled machine instruction code text and generating a "tool code structure"—including function entry addresses, string references, control flow graphs, and jump relationships.

[0150] For example, during the disassembly process, the function entry address 0x004A1B00 was identified as the entry point for image integrity verification; the entire tool code structure was recorded as a data structure for subsequent modification.

[0151] It should be noted that the path, file name, function entry address, and tool name are assumed values ​​in this embodiment. The actual HarmonyOS NEXT Emulator startup tool may be different, and the public information does not disclose all the details of the startup tool's disassembly structure.

[0152] Of particular importance is that step S5 specifically involves:

[0153] The system image is loaded using the startup tool file to start the emulator. The emulator is connected as a superuser through the device connector. The user identity query command is executed to obtain the actual user identifier. When the actual user identifier is zero, it is confirmed that full superuser privileges have been obtained.

[0154] In one embodiment, the target system image is loaded and the emulator is launched using a boot tool file that has been modified in S4 (or confirmed to have no verification obstacles). For example, the emulator can be launched using the command `. / harmony_next_launcher.bin-image system.img`. After the emulator starts, a device connector tool (such as hdc, which replaces ADB in HarmonyOS NEXT) is used to connect to the emulator as a superuser. After a successful connection, a user identity query command (such as `id` or `whoami -u`, depending on the system environment) is executed in the emulator command line to obtain the current user's user identifier (UID). When the returned result shows that UID=0 (i.e., root / superuser), it is confirmed that full superuser privileges have been obtained.

[0155] For example, after executing `id`, the output shows `uid=0(root) gid=0(root)`, thus confirming success.

[0156] It should be noted that the names and commands of the device connector tools may change with the HarmonyOS NEXT version; the commands in this embodiment are only examples and should not be construed as the only applicable commands.

[0157] See Figure 2 The controlled host interacts with the system image through file read / write operations, enabling image parsing and configuration file modification; the controlled host interacts with the boot tool through binary file operations, enabling disassembly analysis and instruction modification of the boot tool; the boot tool interacts with the system image through image loading operations, enabling the reading of the modified image; the boot tool interacts with the emulator through boot commands, enabling the creation and execution of emulator instances; and the controlled host interacts with the emulator through a device connector, enabling verification of superuser privileges. Throughout the entire process, each object executes its corresponding operation sequentially according to a time sequence, ensuring the orderly execution of the system attribute simulation method.

[0158] See Figure 3 The present invention also provides a system attribute simulation system 100 based on the HarmonyOS NEXT simulator, used to execute the above-described system attribute simulation method based on the HarmonyOS NEXT simulator. The system attribute simulation system 100 based on the HarmonyOS NEXT simulator includes:

[0159] The image parsing module 101 is used to load a read-only copy of the HarmonyNEXT system image of the target test environment into the controlled host, and parse the image file system to locate the user configuration file, system property configuration file and security configuration file.

[0160] The permission configuration module 102 is used to add a super user configuration item in the user configuration file, set both the user identifier and the group identifier to zero, and record the creation status of the configuration item.

[0161] The debugging activation module 103 is used to declare the enabled device connector debugging mode and global debugging flag in the system property configuration file, declare the running parameters of the permissive mode in the security configuration file, and record the effective status of the debugging mode and the security mode respectively; when the creation status and the effective status of the debugging mode and the security mode are both true, a super privilege activation identifier is generated.

[0162] The verification and modification module 104 is used to disassemble and analyze the emulator startup tool when the super privilege activation flag is true, locate the image integrity verification function, insert a sequence of instructions that force a return to success at its conditional jump point, and generate the modified startup tool file.

[0163] The startup verification module 105 is used to load the system image using the startup tool file to start the emulator, and connect to the emulator as a superuser to verify superuser privileges.

[0164] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0165] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement 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 present 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 of the invention herein.

Claims

1. A method for simulating system attributes based on the HarmonyOS NEXT simulator, characterized in that, Includes the following steps: Step S1: Load a read-only copy of the HarmonyOS NEXT system image of the target test environment into the controlled host, and parse the image file system to locate the user profile, system property profile, and security profile; Step S2: Add a super user configuration item to the user configuration file, set both the user identifier and the group identifier to zero, and record the creation status of the configuration item; Step S3: Declare the device connector debugging mode and global debugging flag enabled in the system property configuration file, declare the running parameters of the tolerance mode in the security configuration file, and record the effective status of the debugging mode and the security mode respectively. When the creation status and the effective status of debug mode and safe mode are both true, a super privilege activation identifier is generated; Step S4: When the super privilege activation flag is true, disassemble and analyze the emulator startup tool, locate the image integrity verification function, insert a sequence of instructions that force a return to success at its conditional jump point, and generate the modified startup tool file; Step S5: Use the startup tool file to load the system image to start the emulator, and connect to the emulator as a super user to verify super user privileges.

2. The system attribute simulation method based on the HarmonyOS NEXT simulator according to claim 1, characterized in that, Step S1 includes the following steps: Step S11: Locate the pre-acquired HarmonyOS NEXT system image file in the emulator installation directory of the controlled host; Step S12: Read the file header information of the HarmonyOS NEXT system image file, extract the file system type identifier from the file header information, and record the file system type identifier as the image format type; Step S13: Select an image parsing tool according to the image format type, use the image parsing tool to create a read-only copy of the system image, mount the read-only copy to the temporary directory of the controlled host, and obtain the mount root path.

3. The system attribute simulation method based on the HarmonyOS NEXT simulator according to claim 2, characterized in that, Step S1 also includes the following steps: Step S14: Starting from the mount root path, traverse the directory tree structure to obtain the system configuration directory. Search for the configuration file containing user account information in the system configuration directory. When a file whose filename contains the keyword of the user password is found, the user configuration file is obtained. Step S15: Locate the configuration file containing system property declarations in the system configuration directory. When a file whose filename contains the keyword "default value of property" is found, the system property configuration file is obtained. Step S16: Locate the configuration file containing security policy definitions in the system configuration directory. When a file with the keyword "security configuration" in its filename is found, the security configuration file is obtained.

4. The system attribute simulation method based on the HarmonyOS NEXT simulator according to claim 3, characterized in that, Step S2 includes the following steps: Step S21: Read the configuration lines in the user configuration file, parse the field separator and the number of fields in each configuration line, and record the field separator and the number of fields in the user configuration format; Step S22: Identify fields containing user identifier values ​​and group identifier values ​​in the existing configuration lines, determine the positions of the user identifier field and group identifier field by the numerical characteristics of the field content, and record the positions of the two fields as identifier field position information; Step S23: Read the configuration line of the default shell user in the user configuration format, and extract the user identifier value and group identifier value of the user from the identifier field position information.

5. The system attribute simulation method based on the HarmonyOS NEXT simulator according to claim 4, characterized in that, Step S2 also includes the following steps: Step S24: Copy the existing configuration line as a template line. In the template line, change the username field to the super user name, change the user identifier field to the value zero, change the group identifier field to the value zero, keep the contents of other fields unchanged, and generate the super user configuration line. Step S25: Verify that the number of fields and the delimiter of the super user configuration line conform to the user configuration format. When the format verification passes, append the super user configuration line to the user configuration file. Step S26: Record the timestamp of the file modification completion, record the timestamp as the time of user configuration modification, generate a super user configuration item creation success identifier, and record the identifier as the creation status of the configuration item.

6. The system attribute simulation method based on the HarmonyOS NEXT simulator according to claim 5, characterized in that, Step S3 includes the following steps: Step S31: Read the property declaration lines in the system property configuration file, parse the key-value separator of each property declaration line, and record the key-value separator as the property separator; Step S32: Parse the attribute declaration line using the attribute separator, extract the device connector debug mode attribute and the global debug flag attribute, and record the effective status of the debug mode; Step S33: Declare the operating parameters of the tolerant mode in the security configuration file, and record the effective status of the security mode; Step S34: When the creation status and the effective status of debug mode and safe mode are both true, generate a super privilege activation identifier.

7. The system attribute simulation method based on the HarmonyOS NEXT simulator according to claim 6, characterized in that, Step S32 includes the following steps: Step S321: Parse the attribute declaration line according to the attribute separator, extract the attribute name and attribute value, search for the device connector mode attribute in the attribute name, and when the device connector mode attribute is found, recombine the device connector mode attribute name and full mode enable value using the attribute separator to generate a new attribute declaration line and replace the original declaration line. Step S322: Parse the attribute declaration line according to the attribute separator, extract the attribute name and attribute value, search for the global debug flag attribute in the attribute name, and when the global debug flag attribute is found, recombine the global debug flag attribute using the attribute separator to generate a new attribute declaration line and replace the original declaration line. Step S323: Reopen the system property configuration file to verify whether the values ​​of the device connector mode property and the global debug flag property have been modified to the enabled state. When both properties are enabled, generate a debug mode activation flag and record the flag as the activation state of debug mode.

8. The system attribute simulation method based on the HarmonyOS NEXT simulator according to claim 7, characterized in that, Step S33 includes the following steps: Step S331: Read the security policy declaration lines in the security configuration file, parse the parameter names and parameter value separation methods of each policy declaration line, and record the separation methods as parameter separators; Step S332: Parse the policy declaration line according to the parameter separator, extract the parameter name and parameter value, search for the running mode parameter of the security enhancement module in the parameter name, and when the running mode parameter is found, recombine the running mode parameter name and tolerance mode value using the parameter separator to generate a new policy declaration line and replace the original security policy declaration line; Step S333: Reopen the security configuration file to verify whether the value of the running mode parameter has been modified to the tolerance mode. When the parameter value is the tolerance mode, generate a security mode effective flag and record the flag as the effective status of the security mode.

9. The system attribute simulation method based on the HarmonyOS NEXT simulator according to claim 8, characterized in that, Step S4 includes the following steps: Step S41: When the super privilege activation flag is true, disassemble and analyze the emulator launch tool to obtain the tool code structure; Step S42: Search for strings containing integrity verification keywords in the tool code structure, locate the function address that references the string, and record the function address as the entry address of the verification function; Step S43: Starting from the entry address of the verification function, traverse the instruction sequence in the tool code structure to identify the location of the comparison instruction that performs the numerical comparison, and use it as the comparison instruction address; after identifying the comparison instruction address, execute the conditional jump instruction location according to the comparison result. Step S44: Insert an instruction sequence that forces the return value to be successful at the jump instruction location, and generate the modified instruction content, wherein the instruction sequence includes an instruction to set the return register to the success flag value and an instruction to return immediately; Step S45: Write the modified instruction content into the jump instruction position of the simulator startup tool file, save the modified startup tool file, and generate the modified startup tool file.

10. A system attribute simulation system based on the HarmonyOS NEXT simulator, characterized in that, For executing the system attribute simulation method based on the HarmonyOS NEXT simulator as described in claim 1, the system attribute simulation system based on the HarmonyOS NEXT simulator includes: The image parsing module is used to load a read-only copy of the HarmonyNEXT system image of the target test environment into the controlled host, and parse the image file system to locate the user configuration file, system property configuration file and security configuration file. The permission configuration module is used to add a super user configuration item to the user configuration file, set both the user identifier and the group identifier to zero, and record the creation status of the configuration item. The debug activation module is used to declare the enabling of device connector debug mode and global debug flag in the system property configuration file, declare the running parameters of permissive mode in the security configuration file, and record the effective status of debug mode and security mode respectively; when the creation status and the effective status of debug mode and security mode are both true, a super privilege activation identifier is generated. The verification and modification module is used to disassemble and analyze the emulator startup tool when the super privilege activation flag is true, locate the image integrity verification function, insert a sequence of instructions that force a return to success at its conditional jump, and generate the modified startup tool file. The startup verification module is used to load the system image using the startup tool file, start the emulator, and connect to the emulator as a superuser to verify superuser privileges.

Images