Root permission acquisition method and device, medium and electronic equipment

Abstract

The present disclosure relates to a root permission acquisition method, device, medium and electronic equipment, wherein the method comprises: sending a root permission request to a preset server and receiving a root permission flag; setting a terminal system partition as a read-write permission when determining that the root permission flag is a preset flag; renaming a root permission file under a terminal system system / xbin directory as SU and configuring the permission of the root permission file as an upgradable permission, the root permission file being compiled into the system system / xbin directory in advance when the system firmware of the terminal is compiled, and the permission being configured as an unupgradable permission in advance; and executing an SU program based on the root permission file with the renamed name SU to acquire the root permission. The scheme of the present disclosure is relatively simple for a user to operate and easy to implement when acquiring the root permission.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a root privilege acquisition method, a root privilege acquisition device, a computer-readable storage medium and an electronic device that implement the root privilege acquisition method. Background Technology

[0002] As is well known, root privileges are system administrator privileges in the Android operating system. Root privileges allow access to and modification of almost all files on a user's mobile device. Therefore, to improve security, current mobile terminal systems manage root privileges very strictly, and most applications or programs typically do not have root privileges.

[0003] In related technologies, some applications are allowed to obtain root privileges in order to provide a better user experience or for a certain function. However, the current methods for obtaining root privileges are relatively complex and inconvenient for users to implement. Summary of the Invention

[0004] To solve the above-mentioned technical problems, or at least partially solve them, this disclosure provides a root privilege acquisition method, a root privilege acquisition device, a computer-readable storage medium, and an electronic device that implements the root privilege acquisition method.

[0005] In a first aspect, embodiments of this disclosure provide a method for obtaining root privileges, including:

[0006] Send a root privilege request to a preset server and receive a root privilege flag; the root privilege flag is issued by the preset server in response to the root privilege request.

[0007] When the root permission flag is determined to be a preset flag, the terminal system partition is set to read and write permissions; the preset flag is used to indicate the root permission of an authorized user.

[0008] Rename the root privilege file in the system / xbin directory of the terminal system to SU, and configure the permissions of the root privilege file to elevate privileges; wherein, the root privilege file is pre-compiled into the system / xbin directory during the system firmware compilation of the terminal, and the permissions of the root privilege file are pre-configured to prevent privilege escalation;

[0009] Execute the SU program to obtain root privileges based on the root privilege file that has been renamed to SU.

[0010] In some embodiments of this disclosure, when the root privilege file is compiled into the system / xbin directory, it is named with a preset name, which is different from SU.

[0011] In some embodiments of this disclosure, before determining that the root permission flag is a preset flag, the method includes:

[0012] Write the root permission flag to the non-erasable partition of the terminal system to trigger a terminal system restart;

[0013] During the restart process of the terminal system, it is monitored and determined whether the root permission flag is a preset flag.

[0014] In some embodiments of this disclosure, the root permission flag is 0 or 1; the monitoring and determination of whether the root permission flag is a preset flag includes:

[0015] If the root permission flag is detected to be 1 during the terminal system restart process, it is determined to be a preset flag.

[0016] In some embodiments of this disclosure, it also includes:

[0017] During the terminal system restart process, a preset program monitors and determines whether the root permission flag is the preset flag;

[0018] The preset program has root privilege management functionality.

[0019] In some embodiments of this disclosure, the preset program is pre-configured in the system partition during the compilation of the terminal's system firmware.

[0020] In some embodiments of this disclosure, sending a root privilege request to a preset server includes:

[0021] Generate a root privilege request based on the user's input account, password, and user information;

[0022] The generated root privilege request is sent to the preset server.

[0023] Secondly, embodiments of this disclosure provide a root privilege acquisition device, comprising:

[0024] The information transceiver module is used to send a root permission request to a preset server and receive a root permission flag; the root permission flag is issued by the preset server in response to the root permission request.

[0025] The permission flag processing module is used to set the terminal system partition to read and write permissions when it determines that the root permission flag is a preset flag; the preset flag is used to indicate the root permission of an authorized user.

[0026] The permission file configuration module is used to rename the root permission file in the system / xbin directory of the terminal system to SU, and configure the permissions of the root permission file to elevate permissions; wherein, the root permission file is pre-compiled into the system / xbin directory during the system firmware compilation of the terminal, and the permissions of the root permission file are pre-configured to prohibit privilege escalation;

[0027] The root privilege acquisition module is used to execute the SU program to obtain root privileges based on the root privilege file that has been renamed to SU.

[0028] Thirdly, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the root privilege acquisition method described in any of the above embodiments.

[0029] Fourthly, embodiments of this disclosure provide an electronic device, including:

[0030] Processor; and

[0031] Memory for storing the executable instructions of the processor;

[0032] The processor is configured to execute the steps of the root privilege acquisition method described in any of the above embodiments by executing the executable instructions.

[0033] The technical solution provided in this disclosure has the following advantages compared with the prior art:

[0034] In the embodiments of this disclosure, a user can send a root permission request to a preset server via a terminal. The terminal receives a root permission flag issued by the server in response to the root permission request. When the root permission flag is determined to be a preset flag, the system partition is set to read and write permissions. Then, the root permission file in the system / xbin directory of the terminal system is renamed to SU, and the permissions of the root permission file are configured to allow escalation of privileges. This root permission file is pre-compiled into the system / xbin directory during the compilation of the terminal's system firmware, and the permissions of the root permission file are pre-configured to disallow escalation of privileges. Finally, the SU program is executed based on the renamed root permission file to obtain root privileges. In this way, since the root permission file is pre-compiled into the system / xbin directory during the compilation of the terminal's system firmware, when root privileges are needed, the user only needs to send a root permission request to the preset server. After the server issues the root permission flag, the terminal can automatically perform the subsequent steps to obtain root privileges. Therefore, this implementation scheme is relatively simple and easy for the user to operate. Attached Figure Description

[0035] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0036] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0037] Figure 1 This is a flowchart illustrating the root privilege acquisition method according to an embodiment of this disclosure;

[0038] Figure 2 This disclosure illustrates another method for obtaining root privileges.

[0039] Figure 3 This is a flowchart illustrating yet another method for obtaining root privileges according to an embodiment of this disclosure;

[0040] Figure 4 This is a flowchart illustrating another method for obtaining root privileges according to an embodiment of this disclosure;

[0041] Figure 5 This is a schematic diagram of a root privilege acquisition device shown in an embodiment of the present disclosure;

[0042] Figure 6This is a block diagram of an electronic device that implements the root privilege acquisition method according to an embodiment of this disclosure. Detailed Implementation

[0043] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0044] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0045] Figure 1 This is a flowchart illustrating a method for obtaining root privileges according to an example embodiment of this disclosure. This method can be applied to terminals such as smartphones, and may include the following steps:

[0046] Step S101: Send a root permission request to the preset server and receive a root permission flag; the root permission flag is issued by the preset server in response to the root permission request.

[0047] For example, the preset server can be a server with root privilege management, such as a remote server or cloud server set up by the mobile phone system firmware development company to manage system root privileges. Users can log in to, for example, a system firmware management application on their mobile terminals. This system firmware management application can interact with the preset server to manage root privileges on the phone. Based on this system firmware management application, a root privilege request can be sent to the preset server. This root privilege request can be a request for root privileges for at least one application installed on the system. In this case, the root privilege request can carry the corresponding application's attribute information, such as the application name and the application's digital signature. After receiving the root privilege request, the preset server responds to the root privilege request and determines whether to grant root privileges. For example, it can determine whether to grant root privileges to the corresponding application based on the application's attribute information, such as the application name and the application's digital signature. When granting root privileges, a root privilege flag, such as 1, can be issued; when not granting root privileges, a different root privilege flag, such as 0, can be issued.

[0048] Step S102: When it is determined that the root permission flag is a preset flag, set the terminal system partition to read and write permissions; the preset flag is used to indicate the root permission of the authorized user.

[0049] For example, the preset flag could be a root permission flag, such as 1, that grants root privileges to users authorized by the preset server. When the terminal determines that the root permission flag issued by the server is the preset flag, such as 1, it sets the terminal system partition to read and write permissions.

[0050] Step S103: Rename the root privilege file in the system / xbin directory of the terminal system to SU, and configure the permissions of the root privilege file to elevate privileges. The root privilege file is pre-compiled into the system / xbin directory during the terminal's system firmware compilation, and its permissions are pre-configured to prevent privilege escalation.

[0051] For example, the root privilege file can essentially be a file related to the SU (Switch User) program, which obtains root privileges, to allow certain applications to acquire root access. In this embodiment, the root privilege file is pre-compiled into the system / xbin directory during the system firmware compilation of the terminal. The permissions of the root privilege file are pre-configured to disable privilege escalation, for example, configured with "-rwxr-xr-x" permissions, meaning no privilege escalation permissions. This root privilege file can also be pre-named with a name different from SU, as described below.

[0052] When the terminal system partition is set to read and write permissions, you can read and write files with root privileges in the system / xbin directory of the terminal system. For example, you can rename the root file to SU and configure its permissions to elevate privileges, such as "-rwsr-sr-x" permissions, which means it has privilege escalation permissions.

[0053] Step S104: Execute the SU program to obtain root privileges based on the root privilege file renamed to SU.

[0054] Specifically, after renaming as described above, you can execute the SU program based on the root privilege file named SU to obtain root privileges.

[0055] In the root privilege acquisition method described in this embodiment, the user can send a root privilege request to a preset server via a terminal. The terminal receives a root privilege flag issued by the server in response to the root privilege request. When the root privilege flag is determined to be a preset flag, the system partition is set to read and write permissions. Then, the root privilege file in the system / xbin directory of the terminal system is renamed to SU, and the permissions of the root privilege file are configured to allow escalation. This root privilege file is pre-compiled into the system / xbin directory during the system firmware compilation of the terminal, and the permissions of the root privilege file are pre-configured to prohibit escalation. Finally, the SU program is executed based on the renamed root privilege file named SU to obtain root privileges. Thus, since the root privilege file is pre-compiled into the system / xbin directory during the system firmware compilation of the terminal, when root privileges are needed, the user only needs to send a root privilege request to the preset server. After the server issues the root privilege flag, the terminal can automatically execute subsequent steps to obtain root privileges. Therefore, this implementation scheme is relatively simple and easy for the user to operate.

[0056] Optionally, in some embodiments of this disclosure, in combination with Figure 2 The flowchart shown illustrates a method for obtaining root privileges, which may include the following steps:

[0057] Step S201: Generate a root privilege request based on the user's input account, password, and user information.

[0058] For example, a user can open a system firmware management application on their mobile device, enter their previously registered account and password to log in to the aforementioned preset server, and then access the system firmware management application. If the user has not registered before, i.e., this is their first login, they can complete the registration process before logging in. Afterwards, the user can enter user information in the system firmware management application, and a root permission request will be generated based on the account, password, and user information. The user information can be the user's biometric information such as fingerprints, or information such as the user's mobile phone number; this embodiment does not impose any restrictions on this.

[0059] Step S202: Send the generated root privilege request to the preset server.

[0060] Specifically, after generating a root privilege request, the system firmware management application can send the generated root privilege request to the preset server.

[0061] In a specific application scenario, users can log in to the Flyme system firmware to manage their application accounts and enter their username, password, etc. in the settings to confirm enabling root privileges. After that, a root privilege request will be sent to the Flyme system cloud server to request authorization for root privileges.

[0062] Step S203: Receive root permission flag, which is issued by the preset server in response to the root permission request.

[0063] Specifically, after receiving a root permission request, the default server, such as the Flyme system cloud server, can determine whether the requesting user is a legitimate user based on the account, password, and user information. If so, root permission is granted and a root permission flag, such as 1, can be issued. Otherwise, root permission is not granted and a root permission flag, such as 0, can be issued.

[0064] Step S204: When it is determined that the root permission flag is a preset flag, set the terminal system partition to read and write permissions; the preset flag is used to indicate the root permission of the authorized user.

[0065] Step S205: Rename the root privilege file in the system / xbin directory of the terminal system to SU, and configure the permissions of the root privilege file to elevate privileges. The root privilege file is pre-compiled into the system / xbin directory during the terminal's system firmware compilation, and its permissions are pre-configured to prevent privilege escalation.

[0066] Step S206: Execute the SU program based on the root privilege file renamed to SU to obtain root privileges.

[0067] For specific implementation details of steps S204 to S206 above, please refer to the corresponding descriptions in the foregoing embodiments, which will not be repeated here.

[0068] In this embodiment, root privileges can be granted based on the user's input account, password, and user information to generate a root privilege request. After the server determines that the user is legitimate, root privileges can be granted. This can prevent unauthorized user operations and improve the security of obtaining root privileges.

[0069] Optionally, based on any of the above embodiments, in some embodiments of this disclosure, when the root privilege file is compiled into the system / xbin directory, it can be named with a preset name, which is different from SU. For example, when the root privilege file is compiled into the system / xbin directory, it can be named LU, but it is not limited to this. In this way, when executing step S103, the root privilege file named LU in the terminal system / xbin directory can be renamed to SU, and the permissions of the root privilege file can be configured to elevate privileges, for example, configured as "-rwsr-sr-x" permissions, that is, privilege escalation permissions. When executing step S104, the SU program can be executed based on the renamed root privilege file named SU to obtain root privileges.

[0070] In this embodiment, the root privilege file is pre-named with a different name than SU, such as LU, to prevent third-party applications from assuming that the terminal has root privileges enabled. Furthermore, the permissions of the root privilege file are pre-configured to prevent privilege escalation, for example, configured with "-rwxr-xr-x" permissions, meaning no privilege escalation permissions are allowed. This prevents malicious root privileges from being enabled and improves system security.

[0071] Optionally, based on the above embodiments, some embodiments of this disclosure refer to... Figure 3 As shown, before determining that the root permission flag is a preset flag, the method may include the following steps:

[0072] Step S301: Write the root permission flag to the non-erasable partition of the terminal system to trigger a terminal system restart.

[0073] Specifically, as an example, a root permission flag such as 1 issued by the server can be written to the non-erasable partition of the phone system to trigger a phone system restart.

[0074] Step S302: During the restart process of the terminal system, monitor and determine whether the root permission flag is a preset flag.

[0075] For example, during the phone system restart process, the system monitors and determines whether the root permission flag in the system's non-erasable partition is the preset flag 1.

[0076] Figure 3 Other steps can be referred to the description in the foregoing embodiments, and will not be repeated here.

[0077] Optionally, as an example, in some embodiments of this disclosure, the root permission flag can be 0 or 1. Correspondingly, the monitoring and determination of whether the root permission flag is a preset flag in step S302 can specifically be: if the root permission flag is detected to be 1 during the terminal system restart process, then it is determined to be a preset flag. For example, if the root permission flag is detected to be 1 during the mobile phone system restart process, then it is determined to be a preset flag.

[0078] Optionally, based on the above embodiments, some embodiments of this disclosure may further include the following step: during the terminal system restart process, a preset program monitors and determines whether the root permission flag is the preset flag.

[0079] In this embodiment, the preset program may have root privilege management functionality. The preset program can be, for example, an installd program, but is not limited to this. In a specific application scenario, when the phone system restarts, it enters the boot process. A judgment mechanism can be added during the startup of the installd program. If the system root privilege flag is found to be 1, it indicates that the user has successfully granted root privileges. The system partition can then be mounted with read / write (rw) permissions, and the root privilege file in the system / xbin directory, i.e., system / xbin / LU, can be renamed to SU, and its permissions can be modified to "-rwsr-sr-x". This allows third-party applications to detect the presence of the SU file in the system / xbin directory, assume that root privileges are enabled, and continue executing the SU program to achieve root privilege escalation.

[0080] Optionally, in some embodiments of this disclosure, the preset program, such as the installd program, is pre-configured in the system partition during the compilation of the system firmware of the terminal, such as a mobile phone. That is, the installd program is a built-in program of the system. This program can configure the system partition with read-write (rw) permissions and rename the root permission file in the system / xbin directory, i.e., system / xbin / LU, to SU. Before this, third-party applications cannot detect the SU file in the system / xbin directory because it is renamed LU, which is different from SU. Thus, when obtaining root privileges, third-party applications cannot detect the SU file in the system / xbin directory and cannot replace it, thereby preventing other applications from illegally obtaining root privileges and improving security.

[0081] Figure 4 This diagram illustrates a root privilege acquisition method according to a specific embodiment of the present disclosure. The root privilege acquisition method may include the following steps:

[0082] Step S401: Generate a root privilege request based on the user's input account, password, and user information.

[0083] Step S402: Send the generated root privilege request to the preset server.

[0084] Step S403: Receive the root privilege flag issued by the default server in response to the root privilege request.

[0085] Step S404: Write the root permission flag to the non-erasable partition of the terminal system to trigger a terminal system restart.

[0086] Step S405: During the restart process of the terminal system, a program with root permission management function configured in the terminal system partition monitors and determines whether the root permission flag is the preset flag 1.

[0087] Step S406: If the root permission flag is the preset flag 1, then set the terminal system partition to read and write permissions.

[0088] Step S407: Rename the root privilege file in the system / xbin directory of the terminal system to SU, and configure the permissions of the root privilege file to elevate privileges. The root privilege file is pre-compiled into the system / xbin directory and named LU during the terminal's system firmware compilation, and its permissions are pre-configured to prevent privilege escalation.

[0089] Step S408: Execute the SU program to obtain root privileges based on the root privilege file renamed to SU.

[0090] In the root privilege acquisition method described in this embodiment, the user can generate a root privilege request by entering their account, password, and user information on the terminal and send it to a preset server. The terminal receives a root privilege flag issued by the server in response to the root privilege request. When the root privilege flag is determined to be a preset flag 1, the system partition is set to read and write permissions. Then, the root privilege file named LU in the system / xbin directory of the terminal system is renamed to SU, and the permissions of the root privilege file are configured to be elevated. Finally, the SU program is executed based on the renamed root privilege file named SU to obtain root privileges. In this way, since the root privilege file is pre-compiled into the system / xbin directory during the system firmware compilation of the terminal, when root privileges are needed, the user sends a root privilege request to the preset server, and after the server issues a root privilege flag, the terminal can automatically execute the subsequent steps to obtain root privileges. Therefore, this implementation scheme is relatively simple and easy for the user to operate.

[0091] Additionally, during the terminal system reboot process, a preset program monitors and determines whether the root privilege flag is the preset flag 1. This preset program has root privilege management functionality and is pre-configured in the system partition during system firmware compilation. That is, this preset program is a built-in system program that can configure the system partition with read / write (rw) permissions and rename the root privilege file in the system / xbin directory, i.e., system / xbin / LU, to SU. Previously, third-party applications could not detect the SU file in the system / xbin directory because it was renamed LU, which is different from SU. Thus, when obtaining root privileges, third-party applications cannot detect the SU file in the system / xbin directory and cannot replace it, thereby preventing unauthorized root privilege acquisition by other applications and improving security.

[0092] It should be noted that although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that these steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps. Furthermore, it is readily understood that these steps may be executed synchronously or asynchronously, for example, in multiple modules / processes / threads.

[0093] Based on the same concept, embodiments of this disclosure provide a root privilege acquisition device, such as... Figure 5As shown, the root privilege acquisition device 50 may include an information transceiver module 501, a permission flag processing module 502, a permission file configuration module 503, and a root privilege acquisition module 504; wherein:

[0094] The information transceiver module 501 is used to send a root permission request to a preset server and receive a root permission flag; the root permission flag is issued by the preset server in response to the root permission request.

[0095] The permission flag processing module 502 is used to set the terminal system partition to read and write permissions when it determines that the root permission flag is a preset flag. The preset flag is used to indicate the root permission of an authorized user.

[0096] The permission file configuration module 503 is used to rename the root permission file in the system / xbin directory of the terminal system to SU, and configure the permissions of the root permission file to be elevated. The root permission file is pre-compiled into the system / xbin directory during the terminal's system firmware compilation, and its permissions are pre-configured to prevent privilege escalation.

[0097] The root privilege acquisition module 504 is used to execute the SU program to obtain root privileges based on the root privilege file renamed to SU.

[0098] In the root privilege acquisition device described in this embodiment, the user can send a root privilege request to a preset server via a terminal. The terminal receives a root privilege flag issued by the server in response to the root privilege request. When the root privilege flag is determined to be a preset flag, the system partition is set to read and write permissions. Then, the root privilege file in the system / xbin directory of the terminal system is renamed to SU, and the permissions of the root privilege file are configured to allow escalation. This root privilege file is pre-compiled into the system / xbin directory during the compilation of the terminal's system firmware, and the permissions of the root privilege file are pre-configured to prohibit escalation. Finally, the SU program is executed based on the renamed root privilege file named SU to obtain root privileges. In this way, since the root privilege file is pre-compiled into the system / xbin directory during the compilation of the terminal's system firmware, when root privileges are needed, the user only needs to send a root privilege request to the preset server. After the server issues the root privilege flag, the terminal can automatically execute the subsequent steps to obtain root privileges. Therefore, this implementation scheme is relatively simple and easy for the user to operate.

[0099] Optionally, in some embodiments of this disclosure, when the root privilege file is compiled into the system / xbin directory, it is named with a preset name, which is different from SU.

[0100] Optionally, in some embodiments of this disclosure, before the permission flag processing module 502 determines that the root permission flag is a preset flag, it is further configured to: write the root permission flag to the non-erasable partition of the terminal system to trigger a terminal system restart; and during the terminal system restart process, monitor and determine whether the root permission flag is a preset flag.

[0101] Optionally, in some embodiments of this disclosure, the root permission flag can be 0 or 1. Accordingly, the permission flag processing module 502 monitors and determines whether the root permission flag is a preset flag, which specifically includes: if the root permission flag is detected to be 1 during the terminal system restart process, then it is determined to be a preset flag.

[0102] Optionally, in some embodiments of this disclosure, the permission flag processing module 502 is further configured to monitor and determine whether the root permission flag is the preset flag during the terminal system restart process through a preset program. The preset program has root permission management functionality.

[0103] Optionally, in some embodiments of this disclosure, the preset program is pre-configured in the system partition during the compilation of the terminal's system firmware.

[0104] Optionally, in some embodiments of this disclosure, the information transceiver module 501 sends a root permission request to a preset server, which may specifically include: generating a root permission request based on the user's input account, password, and user information; and sending the generated root permission request to the preset server.

[0105] Regarding the apparatus in the above embodiments, the specific methods by which each module performs operations and the corresponding technical effects have been described in detail in the embodiments related to the method, and will not be elaborated here.

[0106] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units. Components shown as modules or units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the disclosed solution according to actual needs. Those skilled in the art can understand and implement this without any inventive effort.

[0107] This disclosure also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the root privilege acquisition method of any of the above embodiments.

[0108] For example, the readable storage medium may be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) 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.

[0109] The computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The readable storage medium may also be any readable medium other than a readable storage medium, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0110] This disclosure also provides an electronic device, including a processor and a memory, the memory being used to store executable instructions of the processor. The processor is configured to execute the steps of the root privilege acquisition method described in any of the preceding embodiments by executing the executable instructions.

[0111] Specifically, Figure 6This is a block diagram illustrating an electronic device according to an exemplary embodiment. For example, the electronic device 600 may be a mobile phone, smartphone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness equipment, personal digital assistant, etc.

[0112] Reference Figure 6 The electronic device 600 may include one or more of the following components: a processing component 602, a memory 604, a power supply component 606, a multimedia component 608, an audio component 610, an input / output (I / O) interface 612, a sensor component 614, and a communication component 616.

[0113] Processing component 602 typically controls the overall operation of electronic device 600, such as operations associated with display, telephone calls, data communication, camera operation, and recording. Processing component 602 may include one or more processors 620 to execute instructions to complete all or part of the steps of the root access acquisition method described above. Furthermore, processing component 602 may include one or more modules to facilitate interaction between processing component 602 and other components. For example, processing component 602 may include a multimedia module to facilitate interaction between multimedia component 608 and processing component 602.

[0114] Memory 604 is configured to store various types of data to support the operation of electronic device 600. Examples of this data include instructions for any application or method operating on electronic device 600, contact data, phonebook data, messages, pictures, videos, etc. Memory 604 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0115] Power component 606 provides power to various components of electronic device 600. Power component 606 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 600.

[0116] Multimedia component 608 includes a screen that provides an output interface between the electronic device 600 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 608 includes a front-facing camera and / or a rear-facing camera. When the electronic device 600 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0117] Audio component 610 is configured to output and / or input audio signals. For example, audio component 610 includes a microphone (MIC) configured to receive external audio signals when electronic device 600 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 604 or transmitted via communication component 616. In some embodiments, audio component 610 also includes a speaker for outputting audio signals.

[0118] I / O interface 612 provides an interface between processing component 602 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0119] Sensor assembly 614 includes one or more sensors for providing state assessments of various aspects of electronic device 600. For example, sensor assembly 614 can detect the on / off state of electronic device 600, the relative positioning of components such as the display and keypad of electronic device 600, changes in position of electronic device 600 or a component of electronic device 600, the presence or absence of user contact with electronic device 600, orientation or acceleration / deceleration of electronic device 600, and temperature changes of electronic device 600. Sensor assembly 614 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 614 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 614 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0120] Communication component 616 is configured to facilitate wired or wireless communication between electronic device 600 and other devices. Electronic device 600 can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G, or 5G, or combinations thereof. In one exemplary embodiment, communication component 616 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 616 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0121] In an exemplary embodiment, the electronic device 600 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above-described root privilege acquisition method.

[0122] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0123] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. 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 this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for obtaining root privileges, characterized in that, include: Send a root privilege request to the preset server and receive the root privilege flag; The root permission flag is issued by the preset server in response to the root permission request; When the root permission flag is determined to be a preset flag, the terminal system partition is set to read and write permissions; the preset flag is used to indicate the root permission of an authorized user. Rename the root privilege file in the system / xbin directory of the terminal system to SU, and configure the permissions of the root privilege file to elevate privileges; wherein, the root privilege file is pre-compiled into the system / xbin directory during the system firmware compilation of the terminal, and the permissions of the root privilege file are pre-configured to prevent privilege escalation; Execute the SU program to obtain root privileges based on the root privilege file that has been renamed to SU.

2. The acquisition method according to claim 1, characterized in that, When the root privilege file is compiled into the system / xbin directory, it is named with a default name, which is different from SU.

3. The acquisition method according to claim 1 or 2, characterized in that, Before determining that the root permission flag is a preset flag, the method includes: Write the root permission flag to the non-erasable partition of the terminal system to trigger a terminal system restart; During the restart process of the terminal system, it is monitored and determined whether the root permission flag is a preset flag.

4. The acquisition method according to claim 3, characterized in that, The root permission flag is 0 or 1; the monitoring and determination of whether the root permission flag is a preset flag includes: If the root permission flag is detected to be 1 during the terminal system restart process, it is determined to be a preset flag.

5. The acquisition method according to claim 4, characterized in that, Also includes: During the terminal system restart process, a preset program monitors and determines whether the root permission flag is the preset flag; The preset program has root privilege management functionality.

6. The acquisition method according to claim 5, characterized in that, The preset program is pre-configured in the system partition during the compilation of the terminal's system firmware.

7. The method for obtaining according to claim 1 or 2, characterized in that, Sending a root privilege request to the preset server includes: Generate a root privilege request based on the user's input account, password, and user information; The generated root privilege request is sent to the preset server.

8. A root privilege acquisition device, characterized in that, include: The message sending and receiving module is used to send root permission requests to a preset server and receive root permission flags. The root permission flag is issued by the preset server in response to the root permission request; The permission flag processing module is used to set the terminal system partition to read and write permissions when it determines that the root permission flag is a preset flag; the preset flag is used to indicate the root permission of an authorized user. The permission file configuration module is used to rename the root permission file in the system / xbin directory of the terminal system to SU, and configure the permissions of the root permission file to elevate permissions; wherein, the root permission file is pre-compiled into the system / xbin directory during the system firmware compilation of the terminal, and the permissions of the root permission file are pre-configured to prohibit privilege escalation; The root privilege acquisition module is used to execute the SU program to obtain root privileges based on the root privilege file that has been renamed to SU.

9. A computer-readable 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 root privilege acquisition method according to any one of claims 1 to 7.

10. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the steps of the root privilege acquisition method according to any one of claims 1 to 7 by executing the executable instructions.

Images