CN112163192A - root authority acquisition method, root authority acquisition device, root authority acquisition medium and electronic equipment - Google Patents

root authority acquisition method, root authority acquisition device, root authority acquisition medium and electronic equipment Download PDF

Info

Publication number
CN112163192A
CN112163192A CN202010989429.3A CN202010989429A CN112163192A CN 112163192 A CN112163192 A CN 112163192A CN 202010989429 A CN202010989429 A CN 202010989429A CN 112163192 A CN112163192 A CN 112163192A
Authority
CN
China
Prior art keywords
root
authority
mark
preset
root authority
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010989429.3A
Other languages
Chinese (zh)
Inventor
黄超华
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Meizu Technology Co Ltd
Original Assignee
Meizu Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Meizu Technology Co Ltd filed Critical Meizu Technology Co Ltd
Priority to CN202010989429.3A priority Critical patent/CN112163192A/en
Publication of CN112163192A publication Critical patent/CN112163192A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/105—Arrangements for software license management or administration, e.g. for managing licenses at corporate level
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44589—Program code verification, e.g. Java bytecode verification, proof-carrying code

Abstract

The disclosure relates to a root authority acquisition method, a root authority acquisition device, a root authority acquisition medium and electronic equipment, wherein the method comprises the following steps: sending a root permission request to a preset server and receiving a root permission mark; setting a terminal system partition as a readable and writable permission when the root permission mark is determined to be a preset mark; renaming a root authority file under a terminal system/xbin directory to be SU, and configuring the authority of the root authority file to be liftable, wherein the root authority file is compiled into the system/xbin directory when a system firmware of a terminal is compiled in advance, and the authority is configured to be forbidden to be lifted in advance; and executing the SU program based on the root authority file with the renamed name SU to acquire the root authority. For the user, the operation is simple and the implementation is easy when the root authority is obtained.

Description

root authority acquisition method, root authority acquisition device, root authority acquisition medium and electronic equipment
Technical Field
The embodiment of the disclosure relates to the technical field of computers, in particular to a root permission obtaining method, a root permission obtaining device, a computer readable storage medium and an electronic device for realizing the root permission obtaining method.
Background
As is well known, the root right is a system administrator right of the Android operating system, which can access and modify almost all files in the user's mobile device. Therefore, in order to improve security, the management of root rights by the mobile terminal system is very strict at present, and most applications or programs do not have the root rights under normal conditions.
In the related art, in order to provide a better user experience or some function, part of applications are allowed to acquire root rights. However, the method for acquiring the root authority is complex to implement and inconvenient to operate.
Disclosure of Invention
In order to solve the technical problem or at least partially solve the technical problem, the present disclosure provides a root right obtaining method, a root right obtaining apparatus, a computer readable storage medium and an electronic device implementing the root right obtaining method.
In a first aspect, an embodiment of the present disclosure provides a root right obtaining method, including:
sending a root permission request to a preset server and receiving a root permission mark; the root permission mark is issued by the preset server in response to the root permission request;
when the root authority mark is determined to be a preset mark, setting a terminal system partition as a readable and writable authority; the preset mark is used for indicating root authority of an authorized user;
renaming a root authority file under a terminal system/xbin directory to be SU, and configuring the authority of the root authority file to be liftable; the root authority file is compiled into a system/xbin directory in advance when system firmware of the terminal is compiled, and the authority of the root authority file is configured to be forbidden to be promoted in advance;
and executing an SU program based on the root authority file with the renamed name SU to acquire the root authority.
In some embodiments of the present disclosure, the root rights file is named a preset name when compiled under the system/xbin directory, the preset name being different from SU.
In some embodiments of the present disclosure, before the determining that the root permission flag is a preset flag, the method includes:
writing the root permission mark into an unerasable partition of the terminal system to trigger the restart of the terminal system;
and monitoring and judging whether the root authority mark is a preset mark or not in the restarting process of the terminal system.
In some embodiments of the present disclosure, the root permission flag is 0 or 1; the monitoring and judging whether the root permission sign is a preset sign or not comprises the following steps:
and in the restarting process of the terminal system, when the root authority mark is monitored to be 1, determining that the mark is a preset mark.
In some embodiments of the present disclosure, further comprising:
in the restarting process of the terminal system, monitoring and judging whether the root permission mark is the preset mark by a preset program;
the preset program has a root authority management function.
In some embodiments of the present disclosure, the predetermined program is configured in the system partition in advance when the system firmware of the terminal is compiled.
In some embodiments of the present disclosure, the sending a root permission request to a preset server includes:
generating a root permission request based on an account number, a password and user information input by a user;
and sending the generated root permission request to the preset server.
In a second aspect, an embodiment of the present disclosure provides a root authority acquiring apparatus, including:
the information transceiving module is used for sending a root permission request to a preset server and receiving a root permission mark; the root permission mark is issued by the preset server in response to the root permission request;
the permission mark processing module is used for setting the terminal system partition as the readable and writable permission when the root permission mark is determined to be a preset mark; the preset mark is used for indicating root authority of an authorized user;
the authority file configuration module is used for renaming the root authority file under the terminal system/xbin directory to be SU and configuring the authority of the root authority file to be liftable; the root authority file is compiled into a system/xbin directory in advance when system firmware of the terminal is compiled, and the authority of the root authority file is configured to be forbidden to be promoted in advance;
and the root authority acquisition module is used for executing an SU program based on the renamed root authority file with the name of SU to acquire the root authority.
In a third aspect, the present disclosure provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the steps of the root right obtaining method in any one of the foregoing embodiments.
In a fourth aspect, an embodiment of the present disclosure provides an electronic device, including:
a processor; and
a memory for storing executable instructions of the processor;
wherein the processor is configured to execute the steps of the root right obtaining method according to any one of the above embodiments through executing the executable instructions.
Compared with the prior art, the technical scheme provided by the embodiment of the disclosure has the following advantages:
in the embodiment of the disclosure, a user can send a root permission request to a preset server through a terminal, the terminal receives a root permission mark issued by the server in response to the root permission request, a system partition is set as a readable and writable permission when the root permission mark is determined to be the preset mark, then a root permission file under a system/xbin directory of the terminal is renamed to SU, and the permission of the root permission file is configured to be a liftable permission; the root authority file is compiled into a system/xbin directory in advance when system firmware of the terminal is compiled, and the authority of the root authority file is configured to be forbidden to be promoted in advance; and finally, executing the SU program based on the renamed root authority file with the name of SU to acquire the root authority. Therefore, the root authority file is compiled into the system/xbin directory in advance when the system firmware of the terminal is compiled, when the root authority needs to be obtained, a user only needs to send a root authority request to a preset server, and the terminal can automatically execute subsequent steps to obtain the root authority after the server issues the root authority mark, so that the implementation scheme is simple in operation and easy to implement for the user.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and together with the description, serve to explain the principles of the disclosure.
In order to more clearly illustrate the embodiments or technical solutions in the prior art of the present disclosure, the drawings used in the description of the embodiments or prior art will be briefly described below, and it is obvious for those skilled in the art that other drawings can be obtained according to the drawings without inventive exercise.
Fig. 1 is a flowchart of a root right obtaining method according to an embodiment of the present disclosure;
FIG. 2 is a flowchart illustrating another root right acquisition method in an embodiment of the present disclosure;
fig. 3 is a flowchart illustrating another root right obtaining method according to an embodiment of the present disclosure;
fig. 4 is a flowchart illustrating a still another root right obtaining method according to an embodiment of the present disclosure;
fig. 5 is a schematic diagram of a root authority acquiring device according to an embodiment of the present disclosure;
fig. 6 is a block diagram of an electronic device implementing a root right obtaining method according to an embodiment of the present disclosure.
Detailed Description
In order that the above objects, features and advantages of the present disclosure may be more clearly understood, aspects of the present disclosure will be further described below. It should be noted that the embodiments and features of the embodiments of the present disclosure may be combined with each other without conflict.
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure, but the present disclosure may be practiced in other ways than those described herein; it is to be understood that the embodiments disclosed in the specification are only a few embodiments of the present disclosure, and not all embodiments.
Fig. 1 is a flowchart of a root right obtaining method according to an exemplary embodiment of the present disclosure, where the root right obtaining method may be applied to a terminal such as a smart phone, and the root right obtaining method may include the following steps:
step S101: sending a root permission request to a preset server and receiving a root permission mark; and the root permission mark is issued by the preset server in response to the root permission request.
For example, the preset server may be a server with root authority management, for example, a remote server or a cloud server for managing the root authority of the system set by a firmware development enterprise of a mobile phone system. A user can log in a system firmware management application on a mobile phone terminal, and the system firmware management application can interact information with a preset server to realize root authority management on the mobile phone. The root permission request can be sent to the preset server based on the system firmware management application. The root permission request may be a request for authorizing a root permission of at least one application installed by the system, and at this time, the root permission request may carry attribute information of the corresponding application, such as an application name, a digital signature of the application, and the like. After receiving the root permission request, the preset server responds to the root permission request to judge whether to grant the root permission, for example, whether to grant the root permission of the corresponding application program can be judged based on the attribute information of the application program, such as the application name, the digital signature of the application, and the like. When the root right is granted, a root right mark such as 1 can be issued, and when the root right is not granted, another different root right mark such as 0 can be issued.
Step S102: when the root authority mark is determined to be a preset mark, setting a terminal system partition as a readable and writable authority; the preset mark is used for indicating root authority of an authorized user.
For example, the preset flag may be a root authority flag such as 1, where the preset server authorizes the root authority of the user. And when the terminal determines that the root authority mark issued by the server is a preset mark such as 1, setting the terminal system partition as the readable and writable authority.
Step S103: and renaming the root authority file under the terminal system/xbin directory to SU, and configuring the authority of the root authority file as the liftable authority. The root authority file is compiled into a system/xbin directory in advance when system firmware of the terminal is compiled, and the authority of the root authority file is configured to be forbidden to be promoted.
Illustratively, the root authority file may be essentially a file related to an SU program (Switch User) that acquires the root authority, so as to allow a part of applications to acquire the root authority. In the embodiment, the root authority file is compiled into a system/xbin directory in advance when the system firmware of the terminal is compiled, and the authority of the root authority file is configured to prohibit the lifting authority in advance, for example, configured to "-rwxr-xr-x" authority, that is, without the authority bit authority. The root rights file may also be pre-named a different name than SU, as described below.
When the terminal system partition is set to be readable and writable, read-write operation can be performed on the root authority file under the terminal system/xbin directory, for example, the root authority file is renamed to SU, and the authority of the root authority file is configured to be liftable, for example, configured to be "-rwsr-sr-x" authority, that is, authority bit authority is provided.
Step S104: and executing an SU program based on the root authority file with the renamed name SU to acquire the root authority.
Specifically, after the renaming, the SU program may be executed based on the root authority file named SU to obtain the root authority.
In the root authority acquisition method of the embodiment of the disclosure, a user can send a root authority request to a preset server through a terminal, the terminal receives a root authority mark issued by the server in response to the root authority request, a system partition is set as a readable and writable authority when the root authority mark is determined to be the preset mark, then a root authority file under a system/xbin directory of the terminal is renamed to SU, and the authority of the root authority file is configured to be a liftable authority; the root authority file is compiled into a system/xbin directory in advance when system firmware of the terminal is compiled, and the authority of the root authority file is configured to be forbidden to be promoted in advance; and finally, executing the SU program based on the renamed root authority file with the name of SU to acquire the root authority. Therefore, the root authority file is compiled into the system/xbin directory in advance when the system firmware of the terminal is compiled, when the root authority needs to be obtained, a user only needs to send a root authority request to a preset server, and the terminal can automatically execute subsequent steps to obtain the root authority after the server sends a root authority mark, so that the implementation scheme is simple in operation and easy to implement for the user.
Optionally, in some embodiments of the present disclosure, in combination with the flowchart of the root right obtaining method shown in fig. 2, the root right obtaining method may include the following steps:
step S201: and generating a root permission request based on the account number, the password and the user information input by the user.
For example, the user may start a system firmware management application on the mobile phone terminal, enter a previously registered account and password in the system firmware management application, log in the preset server, and enter the system firmware management application. If the user is not registered before, namely the first time of login, the user can complete the registration first and then log in. The user may then enter user information in the system firmware management application, generating a root permission request based on the account number, password, and user information. The user information may be biometric information of the user, such as fingerprint information, or information such as a mobile phone number used by the user, which is not limited in this embodiment.
Step S202: and sending the generated root permission request to the preset server.
Specifically, after generating the root permission request, the system firmware management application may send the generated root permission request to the preset server.
In a specific application scene, a user can log in a firmware management application account of the flash system, input the account, a password and the like in setting to confirm the starting of the root authority, and then send a root authority request to a cloud server of the flash system to request the authorization of the root authority.
Step S203: and receiving a root authority mark, wherein the root authority mark is issued by the preset server in response to the root authority request.
Specifically, after a preset server, such as a cloud server of a flash system, receives a root permission request, whether a requested user is a legal user or not can be judged based on an account number, a password and user information, if so, the root permission can be issued, a root permission mark can be issued as 1, and if not, the root permission mark can be issued as 0.
Step S204: when the root authority mark is determined to be a preset mark, setting a terminal system partition as a readable and writable authority; the preset mark is used for indicating root authority of an authorized user.
Step S205: and renaming the root authority file under the terminal system/xbin directory to SU, and configuring the authority of the root authority file as the liftable authority. The root authority file is compiled into a system/xbin directory in advance when system firmware of the terminal is compiled, and the authority of the root authority file is configured to be forbidden to be promoted.
Step S206: and executing the SU program based on the root authority file with the renamed name SU to acquire the root authority.
For the specific implementation of the above steps S204 to S206, reference may be made to the corresponding descriptions in the foregoing embodiments, and details are not repeated here.
In this embodiment, the root right can be requested to be authorized based on the account number, the password and the user information input by the user, and the server side can grant the root right after determining that the user is a legal user, so that the operation of an illegal user can be avoided, and the security when the root right is acquired is improved.
Optionally, on the basis of any of the above embodiments, in some embodiments of the present disclosure, the root rights file may be named as a preset name when being compiled under the system/xbin directory, where the preset name is different from SU, for example, the root rights file is named as LU when being compiled under the system/xbin directory, but is not limited thereto. Thus, when step S103 is executed, the root rights file named LU in the terminal system/xbin directory may be renamed to SU, and the rights of the root rights file may be configured as liftable rights, for example, as "-rwsr-sr-x" rights, that is, rights with a lifting bit. In executing step S104, the SU program may be executed to obtain the root right based on the root right file with the renamed name SU.
In this embodiment, the root authority file is named as LU in advance, which is different from SU, so as to avoid that the third party application considers that the root authority is already opened by the terminal when checking. And the authority of the root authority file is configured to forbid lifting of the authority, for example, configured to be "-rwxr-xr-x" authority, namely, the authority without a lifting bit authority, so that the root authority can be prevented from being opened maliciously, and the system security is improved.
Optionally, on the basis of the foregoing embodiments, in some embodiments of the present disclosure, referring to fig. 3, before determining that the root permission flag is the preset flag, the method may include the following steps:
step S301: and writing the root permission mark into an unerasable partition of the terminal system to trigger the restart of the terminal system.
Specifically, as an example, for example, a root permission flag issued by the server side, such as 1, is written into the non-erasable partition of the mobile phone system to trigger the restart of the mobile phone system.
Step S302: and monitoring and judging whether the root authority mark is a preset mark or not in the restarting process of the terminal system.
Illustratively, in the process of restarting the mobile phone system, whether a root permission flag in an unerasable partition of the system is a preset flag 1 is monitored and judged.
Other steps in fig. 3 may refer to the description in the foregoing embodiments, and are not described herein again.
Optionally, as an example, in some embodiments of the present disclosure, the root permission flag may be 0 or 1. Correspondingly, in step S302, whether the root permission flag is a preset flag is monitored and determined, which may specifically be: and in the restarting process of the terminal system, when the root authority mark is monitored to be 1, determining that the mark is a preset mark. For example, in the process of restarting a mobile phone system, when the root authority flag is monitored to be 1, the root authority flag is determined to be a preset flag.
Optionally, on the basis of the above embodiments, some embodiments of the present disclosure may further include the following steps: and in the restarting process of the terminal system, monitoring and judging whether the root permission mark is the preset mark by a preset program.
In this embodiment, the preset program may have a root authority management function. The preset program may be, for example, an installd program, but is not limited thereto. In a specific application prospect, a mobile phone system can be restarted to enter a boot process, a judgment mechanism can be added in the starting process of an installd program, if a root authority mark of the system is found to be 1, which indicates that a user is successfully authorized, a system partition can be hung to be a readable and writable (rw) authority, a root authority file under a system/xbin directory, namely, a system/xbin/LU, is renamed to be SU, and the authority is modified to be-rwsr-sr-x. Therefore, the third-party application can think that the system has opened the root authority by detecting that the system/xbin directory has the SU file, and can continue to execute the SU program to achieve the function of right-lifting to the root authority.
Optionally, in some embodiments of the present disclosure, the preset program, for example, the installd program, is configured in the system partition in advance when the system firmware of the terminal, such as a mobile phone, is compiled. That is, the installd program is a built-in program, and the program can configure a system partition as a read-write (rw) right and rename a root right file under a system/xbin directory, namely system/xbin/LU, to SU, before a third-party application cannot detect that an SU file is under the system/xbin directory because the name of the SU file is different from that of the SU file. Therefore, when the root authority is obtained, the third-party application cannot detect the SU file under the system/xbin directory and cannot replace the SU file, so that the root authority can be obtained by illegal operation of other application programs, and the safety is improved.
Fig. 4 is a flowchart illustrating a root right obtaining method according to a specific embodiment of the present disclosure, where the root right obtaining method may include the following steps:
step S401: and generating a root permission request based on the account number, the password and the user information input by the user.
Step S402: and sending the generated root permission request to a preset server.
Step S403: and receiving a root authority mark issued by a preset server in response to the root authority request.
Step S404: and writing the root permission mark into an unerasable partition of the terminal system to trigger the restart of the terminal system.
Step S405: and in the restarting process of the terminal system, monitoring and judging whether the root authority mark is a preset mark 1 or not by a program with a root authority management function configured in a terminal system partition.
Step S406: and if the root authority mark is a preset mark 1, setting the terminal system partition as a readable and writable authority.
Step S407: and renaming the root authority file under the terminal system/xbin directory to SU, and configuring the authority of the root authority file as the liftable authority. The root authority file is compiled into a system/xbin directory in advance when system firmware of the terminal is compiled and is named as LU, and the authority of the root authority file is configured to prohibit lifting authority in advance.
Step S408: and executing the SU program based on the root authority file with the renamed name SU to acquire the root authority.
In the root permission obtaining method of the embodiment of the disclosure, a user can input an account number, a password and user information through a terminal to generate a root permission request and send the root permission request to a preset server, the terminal receives a root permission mark issued by the server in response to the root permission request, sets a system partition as a readable and writable permission when the root permission mark is determined to be a preset mark 1, then renames a root permission file named LU under a system/xbin directory of the terminal system to SU, configures the permission of the root permission file to be a liftable permission, and finally executes an SU program based on the renamed root permission file named SU to obtain the root permission. Therefore, the root authority file is compiled into the system/xbin directory in advance when the system firmware of the terminal is compiled, when the root authority needs to be obtained, the user sends a root authority request to the preset server, and the terminal can automatically execute the subsequent steps to obtain the root authority after the server sends the root authority mark, so that the embodiment is simple in operation and easy to implement for the user.
In addition, in the restarting process of the terminal system, a preset program monitors and judges whether the root permission mark is the preset mark 1. The default program may have root rights management function and is pre-configured in the system partition when the system firmware is compiled. That is, the default program is a built-in program, and the program can configure the system partition as a readable and writable (rw) right and rename the root right file under the system/xbin directory, i.e., system/xbin/LU, to SU, before which a third party application cannot detect that there is an SU file under the system/xbin directory because the name is different from that of SU. Therefore, when the root authority is obtained, the third-party application cannot detect the SU file under the system/xbin directory and cannot replace the SU file, so that the root authority can be obtained by illegal operation of other application programs, and the safety is improved.
It should be noted that although the various steps of the methods of the present disclosure are depicted in the drawings in a particular order, this does not require or imply that these steps must be performed in this particular order, or that all of the depicted steps must be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions, etc. Additionally, it will also be readily appreciated that the steps may be performed synchronously or asynchronously, e.g., among multiple modules/processes/threads.
Based on the same concept, the embodiment of the present disclosure provides a root permission obtaining apparatus, as shown in fig. 5, the root permission obtaining apparatus 50 may include an information transceiver module 501, a permission flag processing module 502, a permission file configuration module 503, and a root permission obtaining module 504; wherein:
the information transceiver module 501 is configured to send a root permission request to a preset server, and receive a root permission flag; and the root permission mark is issued by the preset server in response to the root permission request.
The permission flag processing module 502 is configured to set the terminal system partition as the readable and writable permission when it is determined that the root permission flag is the preset flag. The preset mark is used for indicating root authority of an authorized user.
The authority file configuration module 503 is configured to rename the root authority file in the terminal system/xbin directory to SU, and configure the authority of the root authority file as an upgradable authority. The root authority file is compiled into a system/xbin directory in advance when system firmware of the terminal is compiled, and the authority of the root authority file is configured to be forbidden to be promoted.
The root authority obtaining module 504 is configured to execute an SU program based on the root authority file with the renamed name SU to obtain the root authority.
In the root authority acquisition device of the embodiment of the disclosure, a user can send a root authority request to a preset server through a terminal, the terminal receives a root authority mark issued by the server in response to the root authority request, a system partition is set as a readable and writable authority when the root authority mark is determined to be the preset mark, then a root authority file under a system/xbin directory of the terminal is renamed to be SU, and the authority of the root authority file is configured to be a liftable authority; the root authority file is compiled into a system/xbin directory in advance when system firmware of the terminal is compiled, and the authority of the root authority file is configured to be forbidden to be promoted in advance; and finally, executing the SU program based on the renamed root authority file with the name of SU to acquire the root authority. Therefore, the root authority file is compiled into the system/xbin directory in advance when the system firmware of the terminal is compiled, when the root authority needs to be obtained, a user only needs to send a root authority request to a preset server, and the terminal can automatically execute subsequent steps to obtain the root authority after the server sends a root authority mark, so that the implementation scheme is simple in operation and easy to implement for the user.
Optionally, in some embodiments of the present disclosure, the root rights file is named a preset name when compiled under the system/xbin directory, and the preset name is different from SU.
Optionally, in some embodiments of the present disclosure, before the permission flag processing module 502 determines that the root permission flag is a preset flag, the permission flag processing module is further configured to: writing the root permission mark into an unerasable partition of the terminal system to trigger the restart of the terminal system; and monitoring and judging whether the root authority mark is a preset mark or not in the restarting process of the terminal system.
Optionally, in some embodiments of the present disclosure, the root permission flag may be 0 or 1. Correspondingly, the permission flag processing module 502 monitors and judges whether the root permission flag is a preset flag, which may specifically include: and in the restarting process of the terminal system, when the root authority mark is monitored to be 1, determining that the mark is a preset mark.
Optionally, in some embodiments of the present disclosure, the permission flag processing module 502 is further configured to monitor and determine, by a preset program, whether the root permission flag is the preset flag during a restart process of the terminal system. The preset program has a root authority management function.
Optionally, in some embodiments of the present disclosure, the preset program is configured in the system partition in advance when the system firmware of the terminal is compiled.
Optionally, in some embodiments of the present disclosure, the sending and receiving module 501 sends the root permission request to a preset server, which specifically includes: generating a root permission request based on an account number, a password and user information input by a user; and sending the generated root permission request to the preset server.
The specific manner in which the above-mentioned embodiments of the apparatus, and the corresponding technical effects brought about by the operations performed by the respective modules, have been described in detail in the embodiments related to the method, and will not be described in detail herein.
It should be noted that although in the above detailed description several modules or units of the device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit, according to embodiments of the present disclosure. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units. The components shown as modules or units may or may not be physical units, i.e. may be located in one place or may also be distributed over a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the wood-disclosed scheme. One of ordinary skill in the art can understand and implement it without inventive effort.
The embodiments of the present disclosure also provide a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the steps of the root authority acquisition method in any one of the above embodiments.
By way of example, and not limitation, such readable storage media can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
The computer readable storage medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A readable storage medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a readable storage medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
The embodiment of the disclosure also provides an electronic device, which includes a processor and a memory, wherein the memory is used for storing the executable instruction of the processor. Wherein the processor is configured to execute the steps of the root right obtaining method in any one of the above embodiments via executing the executable instructions.
In particular, FIG. 6 is a block diagram illustrating an electronic device in accordance with an exemplary embodiment. For example, the electronic device 600 may be a mobile phone, a smartphone, a computer, a digital broadcast terminal, a messaging device, a gaming console, a tablet device, a medical device, a fitness device, a personal digital assistant, and so forth.
Referring to fig. 6, electronic device 600 may include one or more of the following components: processing component 602, memory 604, power component 606, multimedia component 608, audio component 610, input/output (I/O) interface 612, sensor component 614, and communication component 616.
The processing component 602 generally controls overall operation of the electronic device 600, such as operations associated with display, telephone calls, data communications, camera operations, and recording operations. The processing element 602 may include one or more processors 620 to execute instructions to perform all or a portion of the steps of the root rights acquisition method described above. Further, the processing component 602 can include one or more modules that facilitate interaction between the processing component 602 and other components. For example, the processing component 602 can include a multimedia module to facilitate interaction between the multimedia component 608 and the processing component 602.
The memory 604 is configured to store various types of data to support operations at the electronic device 600. Examples of such data include instructions for any application or method operating on the electronic device 600, contact data, phonebook data, messages, pictures, videos, and so forth. The memory 604 may be implemented by any type or combination of volatile or non-volatile memory devices 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 memory, flash memory, magnetic or optical disks.
Power component 606 provides power to the various components of electronic device 600. Power components 606 may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power for electronic device 600.
The multimedia component 608 includes a screen that provides an output interface between the electronic device 600 and a 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 touch screen to receive an input signal from a user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundary of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 608 includes a front facing camera and/or a rear facing camera. The front camera and/or the rear camera may receive external multimedia data when the electronic device 600 is in an operation mode, such as a shooting mode or a video mode. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.
The audio component 610 is configured to output and/or input audio signals. For example, the audio component 610 includes a Microphone (MIC) configured to receive external audio signals when the electronic device 600 is in an operational mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signal may further be stored in the memory 604 or transmitted via the communication component 616. In some embodiments, audio component 610 further includes a speaker for outputting audio signals.
The I/O interface 612 provides an interface between the processing component 602 and peripheral interface modules, which may be keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to: a home button, a volume button, a start button, and a lock button.
The sensor component 614 includes one or more sensors for providing status assessment of various aspects of the electronic device 600. For example, the sensor component 614 may detect an open/closed state of the electronic device 600, the relative positioning of components, such as a display and keypad of the electronic device 600, the sensor component 614 may also detect a change in the position of the electronic device 600 or a component of the electronic device 600, the presence or absence of user contact with the electronic device 600, orientation or acceleration/deceleration of the electronic device 600, and a change in the temperature of the electronic device 600. The sensor assembly 614 may include a proximity sensor configured to detect the presence of a nearby object without any physical contact. The 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, the sensor assembly 614 may also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.
The communication component 616 is configured to facilitate communications between the electronic device 600 and other devices in a wired or wireless manner. The electronic device 600 may access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G, or 5G, or a combination thereof. In an exemplary embodiment, the communication component 616 receives broadcast signals or broadcast related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 616 further includes a Near Field Communication (NFC) module to facilitate short-range communications. 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.
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, micro-controllers, microprocessors or other electronic components for performing the root right acquisition method described above.
It is noted that, in this document, relational terms such as "first" and "second," and the like, may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
The foregoing are merely exemplary embodiments of the present disclosure, which enable those skilled in the art to understand or practice the present disclosure. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the disclosure. Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (10)

1. A root authority acquisition method is characterized by comprising the following steps:
sending a root permission request to a preset server and receiving a root permission mark; the root permission mark is issued by the preset server in response to the root permission request;
when the root authority mark is determined to be a preset mark, setting a terminal system partition as a readable and writable authority; the preset mark is used for indicating root authority of an authorized user;
renaming a root authority file under a terminal system/xbin directory to be SU, and configuring the authority of the root authority file to be liftable; the root authority file is compiled into a system/xbin directory in advance when system firmware of the terminal is compiled, and the authority of the root authority file is configured to be forbidden to be promoted in advance;
and executing an SU program based on the root authority file with the renamed name SU to acquire the root authority.
2. The acquisition method according to claim 1, wherein the root rights file is named as a preset name when compiled under a system/xbin directory, and the preset name is different from SU.
3. The method according to claim 1 or 2, wherein before determining that the root permission flag is a preset flag, the method comprises:
writing the root permission mark into an unerasable partition of the terminal system to trigger the restart of the terminal system;
and monitoring and judging whether the root authority mark is a preset mark or not in the restarting process of the terminal system.
4. The acquisition method according to claim 3, wherein the root permission flag is 0 or 1; the monitoring and judging whether the root permission sign is a preset sign or not comprises the following steps:
and in the restarting process of the terminal system, when the root authority mark is monitored to be 1, determining that the mark is a preset mark.
5. The acquisition method according to claim 4, further comprising:
in the restarting process of the terminal system, monitoring and judging whether the root permission mark is the preset mark by a preset program;
the preset program has a root authority management function.
6. The method according to claim 5, wherein the predetermined program is pre-configured in the system partition when the system firmware of the terminal is compiled.
7. The obtaining method according to claim 1 or 2, wherein the sending the root permission request to the preset server includes:
generating a root permission request based on an account number, a password and user information input by a user;
and sending the generated root permission request to the preset server.
8. A root right acquiring apparatus, comprising:
the information transceiving module is used for sending a root permission request to a preset server and receiving a root permission mark; the root permission mark is issued by the preset server in response to the root permission request;
the permission mark processing module is used for setting the terminal system partition as the readable and writable permission when the root permission mark is determined to be a preset mark; the preset mark is used for indicating root authority of an authorized user;
the authority file configuration module is used for renaming the root authority file under the terminal system/xbin directory to be SU and configuring the authority of the root authority file to be liftable; the root authority file is compiled into a system/xbin directory in advance when system firmware of the terminal is compiled, and the authority of the root authority file is configured to be forbidden to be promoted in advance;
and the root authority acquisition module is used for executing an SU program based on the renamed root authority file with the name of SU to acquire the root authority.
9. A computer-readable storage medium, on which a computer program is stored, the computer program, when being executed by a processor, implementing the steps of the root right acquisition method according to any one of claims 1 to 7.
10. An electronic device, comprising:
a processor; and
a memory for storing executable instructions of the processor;
wherein the processor is configured to execute the steps of the root rights acquisition method of any of claims 1-7 via execution of the executable instructions.
CN202010989429.3A 2020-09-18 2020-09-18 root authority acquisition method, root authority acquisition device, root authority acquisition medium and electronic equipment Pending CN112163192A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010989429.3A CN112163192A (en) 2020-09-18 2020-09-18 root authority acquisition method, root authority acquisition device, root authority acquisition medium and electronic equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010989429.3A CN112163192A (en) 2020-09-18 2020-09-18 root authority acquisition method, root authority acquisition device, root authority acquisition medium and electronic equipment

Publications (1)

Publication Number Publication Date
CN112163192A true CN112163192A (en) 2021-01-01

Family

ID=73862507

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010989429.3A Pending CN112163192A (en) 2020-09-18 2020-09-18 root authority acquisition method, root authority acquisition device, root authority acquisition medium and electronic equipment

Country Status (1)

Country Link
CN (1) CN112163192A (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113254916A (en) * 2021-05-25 2021-08-13 深圳市瑞驰信息技术有限公司 Implementation method of root switch of android system
TWI821052B (en) * 2021-12-05 2023-11-01 熵碼科技股份有限公司 Electronic device and method for performing permission management of storage device

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113254916A (en) * 2021-05-25 2021-08-13 深圳市瑞驰信息技术有限公司 Implementation method of root switch of android system
TWI821052B (en) * 2021-12-05 2023-11-01 熵碼科技股份有限公司 Electronic device and method for performing permission management of storage device

Similar Documents

Publication Publication Date Title
US10498723B2 (en) Method, and apparatus for authenticating access
EP3242195B1 (en) Control implementation method and apparatus for intelligent hardware device
WO2017080076A1 (en) Method and apparatus for monitoring files in system partition
CN104376273A (en) Data access control method and device
US10114735B2 (en) Method, device and medium for managing application program
US10558328B2 (en) Display screen unlocking method and apparatus
CN106775903B (en) Security policy file updating method and device
EP3407278A1 (en) Method and apparatus for reporting loss of card or device associated with account number or stolen of account number
CN107612888B (en) Enterprise user space creation method and device
CN112784262A (en) Data access method, device, terminal and storage medium
CN112163192A (en) root authority acquisition method, root authority acquisition device, root authority acquisition medium and electronic equipment
CN108319419B (en) Method and device for starting application
WO2018049609A1 (en) Permission control method and device
CN107071008B (en) Terminal equipment positioning method, device and equipment
CN107733674B (en) Component upgrading method and terminal
WO2017166461A1 (en) Method and apparatus for managing application program call
US9674768B2 (en) Method and device for accessing wireless network
CN107894909B (en) Method, device and storage medium for limiting Activity starting
US20210390026A1 (en) Method and device for processing information, and storage medium
CN106201634B (en) Software installation method and device
CN112733092B (en) Information processing method and device
CN112351131B (en) Control method and device of electronic equipment, electronic equipment and storage medium
US10812465B2 (en) Method for logging into account on mobile device, mobile device, and non-transitory computer readable storage medium
CN108011882B (en) Method, device and system for data synchronization
CN113805978A (en) Authority display method, device and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination