CN109657448B - Method and device for acquiring Root authority, electronic equipment and storage medium - Google Patents
Method and device for acquiring Root authority, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN109657448B CN109657448B CN201811574547.7A CN201811574547A CN109657448B CN 109657448 B CN109657448 B CN 109657448B CN 201811574547 A CN201811574547 A CN 201811574547A CN 109657448 B CN109657448 B CN 109657448B
- Authority
- CN
- China
- Prior art keywords
- authorization
- encrypted file
- partition
- electronic equipment
- file
- 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.)
- Active
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/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
-
- 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/45—Structures or tools for the administration of authentication
- G06F21/46—Structures or tools for the administration of authentication by designing passwords or checking the strength of passwords
-
- 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
Abstract
The embodiment of the application discloses a method and a device for acquiring Root authority, electronic equipment and a storage medium. The method comprises the following steps: sending identification information of the electronic equipment to a server, wherein the identification information comprises a machine code of the electronic equipment; receiving and storing an encrypted file generated by the server according to the machine code, wherein the encrypted file comprises authorization information; restarting the electronic equipment to enter a bootstrap program; verifying the validity of the authorization information in the bootstrap program; if the authorization information is verified to be legal, the protection mechanism of the electronic equipment is closed, and the authorization file is sent to the system partition so as to obtain the Root authority of the electronic equipment. The server generates an encrypted file according to the identification information generated by the electronic equipment, receives and stores the encrypted file, verifies the encrypted file in the electronic equipment, and can close the protection mechanism of the electronic equipment to acquire Root authority only when the encrypted file passes the verification. The security of obtaining the Root authority is improved.
Description
Technical Field
The present application relates to the field of IT (Information Technology ) technologies, and in particular, to a method, an apparatus, an electronic device, and a storage medium for obtaining a Root right.
Background
Operating systems born by Uinux, from Linux series to Android operating systems of intelligent terminals, have strict user management mechanisms. Taking an Android system as an example, a system highest authority account is called Root, and the account has a highest-level authority management mechanism, and can add or delete users, start or stop a process, even add or disable hardware, and the like. In order to guarantee the equipment safety of common users, google and terminal manufacturers do not open the Root authority when the intelligent terminal leaves a factory, but some extremely-guest users want to perform differentiated customization on the system of the intelligent terminal and need to acquire the Root authority.
At present, a lot of methods exist for obtaining roots, and a third party Root tool becomes a choice of extremely-guest users, but the Root method is unsafe, Root operation involves the bottom core of an operating system, which may cause system instability and even rushing, and the Root tool of the third party may have viruses, steal personal information of the user, and is poor in safety.
Content of application
The embodiment of the application provides a method and a device for obtaining Root authority, electronic equipment and a storage medium. The security in the process of obtaining the Root authority is improved.
In order to solve the above technical problems, the present application proposes the following technical solutions:
in a first aspect, an embodiment of the present application provides a method for acquiring a Root right, where the method includes:
sending identification information of the electronic equipment to a server, wherein the identification information comprises a machine code of the electronic equipment;
receiving and storing an encrypted file generated by the server according to the machine code, wherein the encrypted file comprises authorization information;
restarting the electronic device to enter a bootstrap program;
verifying the validity of the authorization information in the bootstrap;
if the authorization information is verified to be legal, the protection mechanism of the electronic equipment is closed, and an authorization file is sent to a system partition so as to obtain the Root authority of the electronic equipment.
In a second aspect, an embodiment of the present application provides an apparatus for acquiring Root rights, where the apparatus includes:
the device comprises a sending module, an obtaining module, a restarting module, a verification module and an authorization module.
The sending module is used for sending identification information of the electronic equipment to a server, wherein the identification information comprises a machine code of the electronic equipment;
the acquisition module is used for receiving and storing an encrypted file generated by the server according to the machine code, wherein the encrypted file comprises authorization information;
the restarting module is used for restarting the electronic equipment to enter a bootstrap program;
the verification module is used for verifying the validity of the authorization information in the bootstrap;
the authorization module is configured to close a protection mechanism of the electronic device, and send an authorization file to a system partition, so as to obtain a Root right of the electronic device.
In a third aspect, an embodiment of the present application provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor implements the steps of the Root authority obtaining method when executing the program.
In a fourth aspect, an embodiment of the present application provides a storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the steps of the method for acquiring Root rights.
In this embodiment, the identification information of the electronic device is sent to the server, the server generates an encrypted file according to the identification information of the electronic device, then copies the encrypted file to the first preset partition, restarts the electronic device to enter the boot program, verifies the authorization information in the encrypted file in the boot program, closes the protection mechanism of the electronic device when the authorization information is verified to be legal, and writes the authorization file into the system partition, thereby completing the process of obtaining the Root authority. The security in the process of obtaining the Root authority is ensured, and the difficulty in obtaining the Root authority is reduced.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
Fig. 1 is a schematic first flow chart of a method for acquiring Root rights provided in an embodiment of the present application.
Fig. 2 is a second process diagram of a method for acquiring Root rights provided in the embodiment of the present application.
Fig. 3 is a schematic flowchart of verifying the validity of authorization information according to an embodiment of the present application.
Fig. 4 is a schematic flowchart of configuring DM-preference according to an embodiment of the present application.
Fig. 5 is a schematic flowchart of configuring a Selinux mode according to an embodiment of the present application.
Fig. 6 is a schematic structural diagram of a Root authority acquiring device provided in an embodiment of the present application.
Fig. 7 is a schematic structural diagram of an electronic device provided in an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application are clearly and completely described with reference to the drawings, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
In the description that follows, specific embodiments of the present application will be described with reference to steps and symbols executed by one or more computers, unless otherwise indicated. Accordingly, these steps and operations will be referred to, several times, as being performed by a computer, the computer performing operations involving a processing unit of the computer in electronic signals representing data in a structured form. This operation transforms the data or maintains it at locations in the computer's memory system, which may be reconfigured or otherwise altered in a manner well known to those skilled in the art. The data maintains a data structure that is a physical location of the memory that has particular characteristics defined by the data format. However, while the principles of the application have been described in language specific to above, it is not intended to be limited to the specific form set forth herein, and it will be recognized by those of ordinary skill in the art that various of the steps and operations described below may be implemented in hardware.
The terms "first", "second", and "third", etc. in this application are used to distinguish between different objects and not to describe a particular order. Furthermore, the terms "include" and "have," as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or modules is not limited to only those steps or modules listed, but rather, some embodiments may include other steps or modules not listed or inherent to such process, method, article, or apparatus.
The embodiment of the application provides a Root authorization method, a Root authorization device, electronic equipment and a storage medium. The following are detailed below.
Referring to fig. 1, fig. 1 is a schematic view of a first process of a Root authorization method according to an embodiment of the present application, where the method is applied to an electronic device such as a smart phone, a tablet computer, and a smart television. Wherein the method comprises the following steps:
in step S101, identification information of the electronic device is transmitted to the server.
It can be understood that, in the Root process of the electronic device, first, according to information such as a system version, a model Number, an SN (Serial Number, a machine code), an IMEI (International Mobile Equipment Identity), and the like of the electronic device, the information is generated into identification information and sent to the server.
In an embodiment, the server may obtain the authorization file according to a system version of the electronic device, for example, an authorization manner and an authorization file required by a mobile phone system based on android4.1 version or android6.0 version when obtaining the Root authority may be different, and the server may obtain the authorization file according to system version information currently carried by the electronic device after obtaining the system version of the electronic device.
In step S102, an encrypted file generated by the server according to the machine code is received and saved.
When receiving the identification information sent by the electronic Equipment, the server analyzes and identifies the identification information to obtain information such as a system version, a model Number, an SN (Serial Number, a machine code), an IMEI (International Mobile Equipment Identity) and the like of the electronic Equipment, and then generates an encrypted file according to the information, wherein the encrypted file contains an authorization file and authorization information.
In an embodiment, after the server side obtains the SN code according to the identification information, an encryption value of the SN code is obtained through calculation, and then an encryption signature is performed by using a private key, for example, a signature is performed in an RSA manner, where an RSA encryption algorithm is an asymmetric encryption algorithm, and the obtained private key is only stored in the server, so as to prevent the private key from being leaked due to storage in the electronic device, and under the condition that the private key cannot be obtained, the signed encrypted file cannot be copied, thereby ensuring the security of the electronic device in the process of obtaining the Root authority.
It should be noted that the private key stored by the server and the public key preset in the electronic device are matched, and in the process of verification, verification is performed through matching of the private key and the public key.
After the server generates the encrypted file according to the acquired identification information, the electronic device downloads the encrypted file to a local storage through a network, or the server can actively send the encrypted file to the electronic device, and the electronic device performs the next step after acquiring the encrypted file.
In step S103, the electronic device is restarted to enter a boot program.
It can be understood that after the electronic device acquires the encrypted file, an attribute value is set, and a change in the attribute value is detected by a system process, so as to copy the acquired encrypted file to the first preset partition.
After copying is completed, the electronic equipment is restarted to enter a bootstrap program by calling power management service in the system, and the next step is carried out.
In step S104, the validity of the authorization information is verified within the boot program.
It can be understood that after the boot program is entered, the authorization information in the encrypted file in the first preset partition is verified in various ways, for example, decryption is performed by using decryption information preset in the electronic device and matched with the authorization information in the encrypted file, or the authorization information in the encrypted file is calculated by the electronic device, and the like, and finally whether the authorization information in the encrypted file is legal or not is determined, and the determination way may be that the authorization information is compared with the preset information, or the authorization information is paired with the preset information, and the like, to determine the validity of the authorization information.
In one embodiment, the calculation is performed by obtaining the machine code in the central processor to the first secret in case of a reboot of the handset. Calling the encrypted file in the first preset partition, decrypting the encrypted file by using a public key preset in the second preset partition to obtain a second encrypted value, if the first encrypted value is equal to the second encrypted value, indicating that the authorization information of the encrypted file is legal, and if the first encrypted value is not equal to the second encrypted value, indicating that the authorization information in the encrypted file is illegal.
In step S105, if the authorization information is verified to be valid, the protection mechanism of the electronic device is closed, and the authorization file is sent to the system partition.
It is understood that in the case of verifying that the authorization information of the encrypted file is legal, the electronic device needs to be shut down due to the existence of a protection mechanism, for example, write protection exists in a register of the electronic device, and in the case of not obtaining write authority, any application cannot modify the contents of the system partition, and any file cannot be written into the system partition. The electronic equipment has an independent verification mechanism, and the verification mechanism can protect the electronic equipment or the electronic equipment partition and ensure the integrity of the electronic equipment and the electronic equipment partition. For another example, a SELinux security subsystem is provided in the Linux system, which can reduce the resources accessible to the service process in the system to the maximum extent, and prevent hackers from controlling the electronic device with Root identities by using network service vulnerabilities.
To obtain the highest user right, the protection mechanism of the electronic device needs to be closed, and the authorization file can be normally written into the system partition, so that the Root right is obtained.
It should be noted that there are other partitions besides the system partition in the partition of the electronic device, the preset partition described in this embodiment is a partition independent from the system, and the system of the electronic device includes an operating system and other systems.
In summary, in this embodiment, identification information of an electronic device is sent to a server, the server generates an encrypted file according to the identification information of the electronic device, and then the encrypted file is copied to a first preset partition, the electronic device is restarted to enter a bootstrap program, authorization information in the encrypted file is verified in the bootstrap program, and when the authorization information is verified to be legal, a protection mechanism of the electronic device is closed, and the authorization file is written into a system partition, so that a Root authority acquisition process is completed.
Referring to fig. 2, fig. 2 is a second flow diagram of a Root authorization method according to an embodiment of the present invention, in this embodiment, a method for obtaining a Root right is described in detail by taking a smart phone commonly used by a current user as an example, and the method described in this embodiment is not limited to the smart phone, and is also applicable to electronic devices such as a smart television, a tablet computer, and the like. The method specifically comprises the following steps:
in step S201, the identification information of the mobile phone is sent to the server.
It can be understood that the identification information of the Mobile phone includes information such as a system version, a model Number, an SN (Serial Number, a machine code), an IMEI (International Mobile Equipment Identity), and the like, the Mobile phone sends the identification information to the server, the server generates a corresponding encrypted file according to the identification information, and the encrypted file includes authorization information and an authorization file.
For example, the mobile phone downloads an application program required for obtaining the Root authority, and then clicks a button for obtaining the Root authority function in an application program interface, so that the application program obtains the identification information of the mobile phone, and then sends the identification information to the server through the network.
In step S202, the server generates an encrypted file based on the identification information, and acquires the encrypted file.
After receiving the identification information, the server generates an encrypted file according to the identification information according to a Root authority acquisition request sent by the mobile phone, and then sends the encrypted file to the mobile phone through the network, and the mobile phone stores the encrypted file.
For example, after receiving the identification information sent by the Mobile phone application program, the server obtains information such as a system version, a model Number, an SN (Serial Number, a machine code), an IMEI (International Mobile Equipment Identity) and the like through analysis of the identification information, where information data such as the International Mobile Equipment Identity uploaded to the server may be used for after-sales statistical data. Then, a Root acquisition solution to be executed is determined according to the model and the system version of the mobile phone, and an encrypted file is generated according to a corresponding scheme, specifically, if the model of the mobile phone is a and the system version is a system based on Android6.0, an encrypted file of the model a mobile phone and the system version corresponding to the mobile phone is correspondingly generated. Then the mobile phone downloads the encrypted file to a local storage through a network.
The server generates an encrypted file according to the identification information, wherein the encrypted file can be generated according to the machine code, and the machine code is a unique value read by a central processing unit chip of the mobile phone, so that the uniqueness can be ensured.
For example, the server obtains the machine code from the received identification information, and then calculates the value of the machine code model MD5, where MD5 is a Message Digest Algorithm (MD5 Message-Digest Algorithm), and then performs RSA signature by using a private key, where the RSA encryption Algorithm is an asymmetric encryption Algorithm, the obtained private key is only stored in the server, so as to prevent the private key from being leaked out from the electronic device, and in the case that the private key cannot be obtained, the signed encrypted file cannot be copied, so that the security of the electronic device in the process of obtaining the Root authority is ensured, and correspondingly, a public key matched with the private key is preset in the mobile phone, and then in the subsequent verification step, the information in the encrypted file can be obtained by decrypting the encrypted file by using the public key.
It should be noted that the manner in which the server generates the encrypted file according to the identification information is not only generated according to the machine code, but also generated according to a verification file built in the mobile phone when the mobile phone leaves the factory, where the identification information includes the verification file, or generated according to communication between the server and the mobile phone before the mobile phone sends the identification information, and then the identification information including the verification file is sent to the server, and then the server generates the encrypted file required for obtaining the Root authority according to the verification file.
In step S203, the encrypted file is transmitted to a specified location within the preset partition.
After the encrypted file is downloaded and stored locally by the mobile phone, the mobile phone needs to be restarted in the process of obtaining the Root authority, but the content of the file system cannot be read in the early stage of restarting, so that the encrypted file needs to be sent to a readable preset partition.
For example, after the mobile phone application finishes downloading the encrypted file, the application sets an attribute value sys.root.config.true, then an init process in the system can detect the change of the attribute value, and starts a native process to directly copy the downloaded ciphertext to the offset position specified by the proanfo partition, where the application cannot directly write the encrypted file into the proanfo partition, and can write the encrypted file into the proanfo partition through the native process, and it needs to be noted that the proanfo partition data can be read at the early stage of restarting the mobile phone.
In step S204, the mobile phone is restarted to enter the boot program.
It can be understood that in the process of obtaining the Root authority of the mobile phone, a boot program needs to be entered to verify the authorization information of the encrypted file in the preset partition, so that the mobile phone needs to be restarted after the encrypted file is sent to the preset partition.
In step S205, it is determined whether the authorization information is legitimate.
It can be understood that the subsequent steps can be performed only when the authorization information in the encrypted file is legal, and finally the authorization file is sent to the system partition to obtain the Root authority. In this embodiment, the authorization information in the encrypted file is matched with the information built in the mobile phone, and the authorization information can be shown to be legal only if the matching is successful.
For example, the authorization information in the encrypted file may contain machine code information, and due to the uniqueness of the machine code, the validity of the authorization information verification may be guaranteed. Referring to fig. 3, fig. 3 is a schematic flow chart illustrating the process of verifying the validity of the authorization information according to the embodiment of the present application, which includes the following steps:
in step S301, a little kernel is entered.
The littlekernel can be understood as a Bootloader (bootstrap program) in an Android system, in an embedded operating system, the Bootloader is operated before an operating system kernel operates, the littlekernel stage is firstly entered before the operating system kernel enters the system kernel, and then the legitimacy of the authorization information in the encrypted file is verified.
In step S302, the SN code is obtained from the chip, and the md5 value is calculated to obtain M1.
When the mobile phone is restarted and enters a little kernel stage, an SN code (Serial Number, product Serial Number and machine code) in a CPU is obtained from an application programming interface of a system, the machine code is directly obtained from a chip and cannot be imitated, and then a first encryption value of the machine code is calculated according to the machine code, namely the calculated md5 value M1.
In step S303, the authorization information of the encrypted file is read by using the public key preset in the little kernel partition, and M2 is obtained.
The Little kernel partition is provided with a public key for decrypting the encrypted file, the public key corresponds to a private key in the server, so that the Little kernel partition can be used for decrypting the encrypted file, the encrypted file in the proinfo partition is obtained, the public key in the Little kernel partition is used for decryption, and the machine code information in the encrypted file is obtained to obtain a second encrypted value M2.
In step S304, it is determined whether M1 is equal to M2.
After the first encrypted value M1 and the second encrypted value M2 are calculated, whether the authorization information in the encrypted file is legal or not is verified by judging whether the first encrypted value M1 and the second encrypted value M2 are equal or not, the first encrypted value M1 and the second encrypted value M2 are theoretically equal to each other because the first encrypted value M and the second encrypted value M are both obtained through the machine code of the mobile phone, and the authorization information is legal under the condition that M1 is equal to M2.
In step S305, the authorization information is valid, and the write protection of the system partition is closed.
Under the condition that the authorization information is judged to be legal, the write protection function of the system partition is configured at the little kernel stage, and at the moment, the write protection function of the system partition can be directly closed.
In step S306, the authorization status is sent to the kernel.
Since the configuration of SElinux and DM-verify is configured in kernel, the verification status of the authorization information can be transferred to kernel, i.e. the system kernel, through a command line or in other ways.
In step S307, if the first cryptographic value M1 and the second cryptographic value M2 are determined to be unequal, the authorization information is illegal, and the write-protect function of the system partition of the mobile phone is turned on to protect the security of the mobile phone.
After the validity of the authorization information is verified, if the authorization information is legal, the next step S206 is executed to close the protection mechanism of the mobile phone.
In the process of obtaining the Root authority, the most important step is to send the authorization file to the system partition, but due to the protection mechanism in the mobile phone, the authorization file can be written into the system partition only by closing the protection mechanism of the mobile phone under the condition that the authorization information is verified.
The protection mechanism of the mobile phone mainly comprises a write protection function of a system partition, and also comprises a SElinux (security subsystem) and a DM-verity protection module, wherein the SElinux is a security subsystem in a Linux system and mainly has the functions of reducing resources accessible to a service process in the system to the maximum extent and preventing a hacker from controlling electronic equipment by using a network service vulnerability in a Root identity, the DM-verity is a sub-module in a Device Mapper of a kernel subsystem, and the DM-verity can generate a hash tree of the whole system image in a compiling stage. If the mobile phone uses a certain block of data in the system image when running, if the system detects that the hash value of the data block is not matched with the data recorded in the hash tree, the data block is not allowed to be used.
The configuration of the write protection function directly closes the write protection function of the system partition under the condition that the verification authorization information is legal in the littlekernel stage, but the configuration of the SElinux and the DM-preference needs to be configured in the kernel stage.
The configuration of the DM-threshold is shown in fig. 4.
In step S401, the Little kernel passes the status of the authorization information.
At this time, the Little kernel passes the validity status of the authorization information to the kernel by way of a command line.
In step S402, the DM-nature control command is set according to the validity of the authorization information.
And when the kernel mounts the system, acquiring the legal state of the authorization information through android boot.
In step S403, the DM-verify control instruction is passed through the command line.
Rootstatus pass is passed to the kernel through the command line if the authorization information is legitimate.
In the case of illegal authorization information, android is passed to the kernel through the command line.
In step S404, entering kernel, and setting a DM-preference mode according to the DM-preference control instruction.
And under the condition that the authorization information is legal, closing the DM-preference according to the corresponding control instruction so as to acquire the Root authority.
And under the condition that the authorization information is illegal, starting the DM-preference according to the corresponding control instruction to protect the safety of the mobile phone.
Wherein the configuration of SElinux is shown in FIG. 5.
In step S501, the Little kernel passes the status of the authorization information.
At this time, the Little kernel passes the validity status of the authorization information to the kernel by way of a command line.
In step S502, a SELinux control instruction is set according to the validity of the authorization information.
The Selinux has two modes, namely an executing Mode and a permission Mode, in a normal state, an intercepting system has no configured access, directly enters the executing Mode, and modifies and compiles ALLOW _ PERMISSIVE _ SELINUX to be 1 in the process of acquiring the Root authority, so that when a kernel phase starts Selinux, the kernel phase acquires from android. And setting a SELinux control instruction according to the legality of the authorization information, so that the SELinux is configured into a corresponding mode.
In step S503, the SELinux control instruction is passed through the command line.
In case the authorization information is legal, android, selinux, legal is passed to the kernel through the command line.
In the case of illegal authorization information, android boot, selinux, enfocing is passed to the kernel through the command line.
In step S504, enter kernel, and set the SELinux mode according to the SELinux control instruction.
And under the condition that the authorization information is legal, setting SELinux as a permission mode according to the corresponding control instruction so as to acquire Root authority.
And under the condition that the authorization information is illegal, setting SELinux as an enfocing mode according to a corresponding control instruction, and protecting the safety of the mobile phone.
After the protection mechanism of the mobile phone is closed, in step S207, an authorization file is sent to the system partition.
It can be understood that after the protection mechanism of the mobile phone is closed, the read-write operation can be performed on the system partition, then the authorization file is sent to the "system/xbin/" directory, and then the authority of the authorization file is modified to 4755 by the chmod function, that is, all users can read, write, and execute the authorization file.
In step S208, the mobile phone is restarted, and the mobile phone successfully acquires the Root right.
If the authorization information is not legal in the process of verifying the authorization information in step S205, in step S209, a protection mechanism of the mobile phone is started, where starting the protection mechanism of the mobile phone specifically includes starting a write protection function of a system partition, starting DM-preference, and configuring SELinux as an enfong mode, so as to protect the security of the mobile phone.
In step S210, if the authorization information is illegal, the mobile phone is restarted, and the Root right is not obtained.
In summary, in this embodiment, the identification information of the mobile phone is sent to the server, the server generates an encrypted file according to the machine code in the identification information, then the mobile phone downloads the encrypted file to the local storage, and sends the encrypted file to the first preset partition, then the mobile phone is restarted to enter the bootstrap program, the authorization information of the encrypted file in the first preset partition is verified in the bootstrap program, when the authorization information is verified, the protection mechanism of the mobile phone is closed, the authorization file in the encrypted file is sent to the system partition, and after the mobile phone is restarted, the Root authority is successfully obtained. In the whole process of obtaining the Root authority, the security of obtaining the Root authority is improved, and the difficulty of obtaining the Root authority is reduced.
Referring to fig. 6, fig. 6 is a schematic structural diagram of a Root authority acquiring device according to an embodiment of the present application.
The Root authority acquiring device 600 includes a sending module 610, an acquiring module 620, a restarting module 630, a verifying module 640 and an authorizing module 650.
The sending module 610 is configured to send identification information of the electronic device to the server, where the identification information includes a machine code of the electronic device.
It can be understood that the identification information of the electronic device includes information such as a system version, a model Number, an SN (Serial Number, a machine code), an IMEI (International Mobile Equipment Identity), and the like, and the electronic device sends the identification information to the server through the sending module 610, and the server generates a corresponding encrypted file according to the identification information, where the encrypted file includes the authorization information and the authorization file.
And an obtaining module 620, configured to receive and store an encrypted file generated by the server according to the machine code, where the encrypted file includes the authorization information.
After receiving the identification information, the server generates an encrypted file according to the identification information according to a Root authority acquisition request sent by the electronic device, and then sends the encrypted file to the electronic device through the network, and the electronic device acquires the encrypted file through the acquisition module 620.
The obtaining module 620 specifically includes a detecting sub-module 621 and a first sending sub-module 622.
The detection submodule 621 is configured to set an attribute value, and the system process detects a change in the attribute value.
And the first sending sub-module 622 is configured to send the saved encrypted file to the first preset partition.
After the electronic device downloads the encrypted file and stores the encrypted file to the local, the electronic device needs to be restarted in the process of obtaining the Root authority, but the content of the file system cannot be read in the early stage of restarting the electronic device, so that the encrypted file needs to be sent to a readable preset partition. The detection module 621 may set an attribute value, and then start a system process to send the encrypted file to a preset partition according to the change of the attribute value.
For example, after the mobile phone application finishes downloading the encrypted file, the application sets an attribute value sys.root.config.true, then an init process in the system can detect the change of the attribute value, and starts a native process to directly copy the downloaded ciphertext to the offset position specified by the proanfo partition, where the application cannot directly write the encrypted file into the proanfo partition, and can write the encrypted file into the proanfo partition through the native process, and it needs to be noted that the proanfo partition data can be read at the early stage of restarting the mobile phone.
And a restart module 630, configured to restart the electronic device to enter the boot program.
In the process of obtaining the Root authority, the electronic device needs to be restarted by the restart module 630 to enter the boot program, so that the next steps can be performed.
And the verifying module 640 is used for verifying the validity of the authorization information in the bootstrap.
It can be understood that the subsequent steps can be performed only when the authorization information in the encrypted file is legal, and finally the authorization file is sent to the system partition to obtain the Root authority. In this embodiment, the verification module 640 performs validity verification on the authorization information, and the Root authority obtaining step can be continuously performed only when the verification is successful.
The verification module 640 specifically includes: a first calculation submodule 641, a second calculation submodule 642 and a judgment submodule 643.
The first calculating submodule 641 is configured to obtain a machine code in the central processing unit, and calculate a first encrypted value according to the machine code.
When the electronic device is restarted and enters a little kernel stage, the SN code (Serial Number, machine code) in the CPU is obtained from the application programming interface of the system, the machine code is directly obtained from the chip and cannot be imitated, and then the first encryption value, that is, the calculated md5 value M1, is calculated according to the first calculating submodule 641.
The second calculating submodule 642 is configured to read the encrypted file in the first preset partition, and decrypt the encrypted file by using a public key preset in the second preset partition to obtain a second encrypted value.
The Little kernel partition is provided with a public key for decrypting the encrypted file, the public key corresponds to a private key in the server, so that the Little kernel partition can be used for decrypting the encrypted file, the encrypted file in the proinfo partition is obtained, the public key in the Little kernel partition is used for decryption, and the machine code information in the encrypted file is obtained to obtain a second encrypted value M2.
A determining submodule 643, configured to determine whether the first encrypted value and the second encrypted value are equal, and if yes, determine that the authorization information is legal.
After the first and second encrypted values M1 and M2 are calculated, it is verified whether the authorization information in the encrypted file is legitimate by determining whether the two are equal.
The authorization module 650 is configured to close a protection mechanism of the electronic device, and send an authorization file to the system partition, so as to obtain a Root right of the electronic device.
The authorization module 650 specifically includes a close sub-module 651 and a second send sub-module 652.
The close sub-module 651 is configured to close the write protect function of the system partition, close the DM-verify, and modify SELinux into the permission mode.
In the process of obtaining the Root authority, the most necessary step is to send the authorization file to the system partition, but due to the protection mechanism in the mobile phone, the authorization file can be written into the system partition only by closing the protection mechanism of the mobile phone through the closing sub-module 651 when the authorization information is verified to be passed.
And the second sending submodule 652 is configured to send the authorization file to the system partition preset location.
It can be understood that after the protection mechanism of the mobile phone is turned off, the read-write operation can be performed on the system partition, then the authorization file is sent to the "system/xbin/" directory through the second sending sub-module 652, and then the authority of the authorization file is modified to 4755 through the chmod function, that is, all users can read, write, and execute the authorization file.
In summary, in this embodiment, identification information of an electronic device is sent to a server, the server generates an encrypted file according to the identification information of the electronic device, and then the encrypted file is copied to a first preset partition, the electronic device is restarted to enter a bootstrap program, authorization information in the encrypted file is verified in the bootstrap program, and when the authorization information is verified to be legal, a protection mechanism of the electronic device is closed, and the authorization file is written into a system partition, so that a Root authority acquisition process is completed.
Referring to fig. 7, fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present disclosure.
The electronic device 700 may include an input unit 701, a display unit 702, a memory 703, a processor 704 including one or more processing cores, a power supply 705, and a Wireless Fidelity (WiFi) module 706. Those skilled in the art will appreciate that the terminal structure shown in fig. 7 is not intended to be limiting and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components. Wherein:
the input unit 701 may be used to receive input numeric or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control. Specifically, in a particular embodiment, the input unit 701 may include a touch-sensitive surface as well as other input devices. The touch-sensitive surface, also referred to as a touch display screen or a touch pad, may collect touch operations by a user (e.g., operations by a user on or near the touch-sensitive surface using a finger, a stylus, or any other suitable object or attachment) thereon or nearby, and drive the corresponding connection device according to a predetermined program. Alternatively, the touch sensitive surface may comprise two parts, a touch detection means and a touch controller. The touch detection device detects the touch direction of a user, detects a signal brought by touch operation and transmits the signal to the touch controller; the touch controller receives touch information from the touch sensing device, converts the touch information into touch point coordinates, sends the touch point coordinates to the processor 704, and can receive and execute commands sent by the processor 704. In addition, touch sensitive surfaces may be implemented using various types of resistive, capacitive, infrared, and surface acoustic waves. The input unit 701 may include other input devices in addition to the touch-sensitive surface. In particular, other input devices may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, and the like.
The memory 703 may be used for storing software programs and modules, and the processor 704 executes various functional applications and data processing by operating the software programs and modules stored in the memory 703. The memory 703 may mainly include a program storage area and a data storage area, where the program storage area may store an operating system, an application program (such as a sound playing function, an image playing function, etc.) required by at least one function, and the like; the storage data area may store data (such as audio data, a phonebook, etc.) created according to the use of the terminal, etc. Further, the memory 703 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device.
The display unit 702 may be used to display information input by or provided to a user and various graphical user interfaces of the terminal, which may be made up of graphics, text, icons, video, and any combination thereof. The Display unit 702 may include a Display panel, and optionally, the Display panel may be configured in the form of a Liquid Crystal Display (LCD), an Organic Light-Emitting Diode (OLED), or the like. Further, the touch-sensitive surface may overlay the display panel, and when a touch operation is detected on or near the touch-sensitive surface, the touch operation is transmitted to the processor 704 to determine the type of touch event, and the processor 704 then provides a corresponding visual output on the display panel according to the type of touch event. Although in FIG. 7 the touch-sensitive surface and the display panel are two separate components to implement input and output functions, in some embodiments the touch-sensitive surface may be integrated with the display panel to implement input and output functions.
WiFi belongs to short-distance wireless transmission technology, and the terminal can help a user to send and receive e-mails, browse webpages, access streaming media and the like through the WiFi module 706, and provides wireless broadband internet access for the user. Although fig. 7 shows the WiFi module 706, it is understood that it does not belong to the essential constitution of the terminal, and may be omitted entirely as needed within the scope not changing the essence of the invention.
The processor 704 is a control center of the terminal, connects various parts of the entire mobile phone by using various interfaces and lines, and performs various functions of the terminal and processes data by operating or executing software programs and/or modules stored in the memory 703 and calling data stored in the memory 703, thereby performing overall monitoring of the mobile phone. Optionally, processor 704 may include one or more processing cores; preferably, the processor 704 may integrate an application processor, which primarily handles operating systems, user interfaces, applications, etc., and a modem processor, which primarily handles wireless communications. It will be appreciated that the modem processor described above may not be integrated into processor 704.
The terminal also includes a power supply 705 (e.g., a battery) for powering the various components, which may preferably be logically coupled to the processor 704 via a power management system that may be used to manage charging, discharging, and power consumption. The power supply 705 may also include any component of one or more dc or ac power sources, recharging systems, power failure detection circuitry, power converters or inverters, power status indicators, and the like.
Although not shown, the terminal may further include a camera, a bluetooth module, and the like, which will not be described herein. Specifically, in this embodiment, the processor 704 in the terminal loads the executable file corresponding to the process of one or more application programs into the memory 703 according to the following instructions, and the processor 704 runs the application programs stored in the memory 703, thereby implementing various functions:
sending identification information of the electronic equipment to a server, wherein the identification information comprises a machine code of the electronic equipment;
receiving and storing an encrypted file generated by the server according to the machine code, wherein the encrypted file comprises authorization information;
restarting the electronic device to enter a bootstrap program;
verifying the validity of the authorization information in the bootstrap;
if the authorization information is verified to be legal, the protection mechanism of the electronic equipment is closed, and an authorization file is sent to a system partition so as to obtain the Root authority of the electronic equipment.
It will be understood by those skilled in the art that all or part of the steps of the methods of the above embodiments may be performed by instructions or by associated hardware controlled by the instructions, which may be stored in a computer readable storage medium and loaded and executed by a processor.
To this end, the present application provides a storage medium, in which a plurality of instructions are stored, where the instructions can be loaded by a processor to execute the steps in any one of the methods for transferring a virtual resource provided in the present application. For example, the instructions may perform the steps of:
sending identification information of the electronic equipment to a server, wherein the identification information comprises a machine code of the electronic equipment;
receiving and storing an encrypted file generated by the server according to the machine code, wherein the encrypted file comprises authorization information;
restarting the electronic device to enter a bootstrap program;
verifying the validity of the authorization information in the bootstrap;
if the authorization information is verified to be legal, the protection mechanism of the electronic equipment is closed, and an authorization file is sent to a system partition so as to obtain the Root authority of the electronic equipment.
The above operations can be implemented in the foregoing embodiments, and are not described in detail herein.
Wherein the storage medium may include: read Only Memory (ROM), Random Access Memory (RAM), magnetic or optical disks, and the like.
Since the instructions stored in the storage medium may execute the steps in any virtual resource transfer method provided in the embodiments of the present application, beneficial effects that can be achieved by any virtual resource transfer method provided in the embodiments of the present application may be achieved, which are detailed in the foregoing embodiments and will not be described herein again.
The method, the device and the system for filtering browser page data provided by the embodiment of the application are described in detail above, a specific example is applied in the description to explain the principle and the implementation of the application, and the description of the embodiment is only used to help understand the method and the core idea of the application; meanwhile, for those skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.
Claims (10)
1. A method for acquiring Root authority, applied to an electronic device, is characterized in that the method comprises:
sending identification information of the electronic equipment to a server, wherein the identification information comprises a machine code of the electronic equipment;
setting an attribute value, and detecting the change of the attribute value by a system process;
sending the stored encrypted file to a first preset partition, wherein the encrypted file comprises authorization information;
restarting the electronic device to enter a bootstrap program;
verifying the validity of the authorization information in the bootstrap program according to a public key preset in a second preset partition;
if the authorization information is verified to be legal, the protection mechanism of the electronic equipment is closed, and an authorization file is sent to a system partition so as to obtain the Root authority of the electronic equipment.
2. The method for obtaining Root rights according to claim 1, wherein the verifying the validity of the authorization information according to a preset public key in the bootstrap includes:
acquiring a machine code in a central processing unit, and calculating a first encryption value according to the machine code;
and reading the encrypted file in the first preset partition, and decrypting the encrypted file by using a public key preset in the second preset partition to obtain a second encrypted value.
3. The method for obtaining Root rights according to claim 2, wherein the verifying the validity of the authorization information according to a preset public key in the bootstrap program further comprises:
determining whether the first cryptographic value and the second cryptographic value are equal;
and if so, determining that the authorization information is legal.
4. The method for obtaining Root rights according to any one of claims 1 to 3, wherein if the authorization information is verified to be legal, closing a protection mechanism of the electronic device, and pushing an authorization file to a system partition includes:
closing the write protection function of the system partition;
closing DM-preference and modifying SELinux into a permission mode;
and sending the authorization file to a preset position of the system partition.
5. An apparatus for acquiring Root rights, applied to an electronic device, includes: the device comprises a sending module, an obtaining module, a restarting module, a verification module and an authorization module;
the sending module is used for sending identification information of the electronic equipment to a server, wherein the identification information comprises a machine code of the electronic equipment;
the acquisition module includes: the detection submodule is used for setting an attribute value and detecting the change of the attribute value by a system process;
the first sending submodule is used for sending the stored encrypted file to a first preset partition, and the encrypted file comprises authorization information;
the restarting module is used for restarting the electronic equipment to enter a bootstrap program;
the verification module is used for verifying the validity of the authorization information in the bootstrap program according to a public key preset in a second preset partition;
the authorization module is configured to close a protection mechanism of the electronic device, and send an authorization file to a system partition, so as to obtain a Root right of the electronic device.
6. The apparatus for obtaining Root rights according to claim 5, wherein the verification module comprises:
the first calculation submodule is used for acquiring a machine code in the central processing unit and calculating a first encryption value according to the machine code;
and the second calculation submodule is used for reading the encrypted file in the first preset partition and decrypting the encrypted file by using a public key preset in the second preset partition to obtain a second encrypted value.
7. The apparatus for obtaining Root rights according to claim 6, wherein the verification module further comprises:
and the judging submodule is used for judging whether the first encryption value and the second encryption value are equal or not, and if so, determining that the authorization information is legal.
8. The apparatus for obtaining Root rights according to any of claims 5 to 7, wherein the authorization module comprises:
the closing submodule is used for closing the write protection function of the system partition, closing the DM-preference and modifying the SELinux into a permission mode;
and the second sending submodule is used for sending the authorization file to a preset position of the system partition.
9. An electronic device, comprising:
a memory storing executable program code, a processor coupled with the memory;
the processor calls the executable program code stored in the memory to perform the method of any of claims 1-4.
10. A storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, performs the steps of the method according to any one of claims 1-4.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811574547.7A CN109657448B (en) | 2018-12-21 | 2018-12-21 | Method and device for acquiring Root authority, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811574547.7A CN109657448B (en) | 2018-12-21 | 2018-12-21 | Method and device for acquiring Root authority, electronic equipment and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109657448A CN109657448A (en) | 2019-04-19 |
| CN109657448B true CN109657448B (en) | 2021-05-07 |
Family
ID=66115960
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811574547.7A Active CN109657448B (en) | 2018-12-21 | 2018-12-21 | Method and device for acquiring Root authority, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109657448B (en) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110457894B (en) * | 2019-08-06 | 2021-08-03 | 惠州Tcl移动通信有限公司 | root authority distribution method and device, storage medium and terminal equipment |
| CN112528267A (en) * | 2019-09-19 | 2021-03-19 | 青岛海信移动通信技术股份有限公司 | Root operation executing method and mobile terminal |
| CN110972141B (en) * | 2019-12-04 | 2022-02-22 | 迈普通信技术股份有限公司 | Information verification method and device, electronic equipment and readable storage medium |
| CN111490880B (en) * | 2020-05-12 | 2023-10-20 | 上海明略人工智能(集团)有限公司 | File receiving method and device |
| CN111625295A (en) * | 2020-05-22 | 2020-09-04 | 苏州浪潮智能科技有限公司 | Embedded system starting method, device, equipment and storage medium |
| CN113553629A (en) * | 2021-09-18 | 2021-10-26 | 新大陆数字技术股份有限公司 | Hardware authorization method and system |
| CN114780152B (en) * | 2022-03-22 | 2024-03-15 | 西安广和通无线软件有限公司 | Computing device starting method and device |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103152366A (en) * | 2013-04-10 | 2013-06-12 | 珠海市魅族科技有限公司 | Method, terminal and server for obtaining terminal authorization |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR101238846B1 (en) * | 2011-06-10 | 2013-03-04 | 한국전자통신연구원 | System and method for verifying certificate |
| CN106162612B (en) * | 2016-06-27 | 2019-11-08 | 北京小米移动软件有限公司 | Control the method and device of Root authority |
| CN107223328A (en) * | 2017-04-12 | 2017-09-29 | 福建联迪商用设备有限公司 | A kind of method and system of Root authority management and control |
| CN108846281A (en) * | 2018-05-02 | 2018-11-20 | 广州视源电子科技股份有限公司 | Root authority acquisition methods, device, terminal device and storage medium |
-
2018
- 2018-12-21 CN CN201811574547.7A patent/CN109657448B/en active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103152366A (en) * | 2013-04-10 | 2013-06-12 | 珠海市魅族科技有限公司 | Method, terminal and server for obtaining terminal authorization |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109657448A (en) | 2019-04-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109657448B (en) | Method and device for acquiring Root authority, electronic equipment and storage medium | |
| TWI648651B (en) | Equipment for processing safety information, single-chip system and method for realizing safety operating system switching | |
| CN101578609B (en) | Secure booting a computing device | |
| CN110457894B (en) | root authority distribution method and device, storage medium and terminal equipment | |
| CN107431924B (en) | Device theft protection associating device identifiers with user identifiers | |
| KR101281678B1 (en) | Method and Apparatus for authorizing host in portable storage device and providing information for authorizing host, and computer readable medium thereof | |
| JP5346608B2 (en) | Information processing apparatus and file verification system | |
| CN109964227B (en) | Method and terminal for updating SELinux security policy | |
| KR20140016280A (en) | Protecting operating system configuration values | |
| WO2008085367A1 (en) | Trusting an unverified code image in a computing device | |
| CN109614798B (en) | Safe starting method and device and terminal equipment | |
| US11625480B2 (en) | Mobile device with secure private memory | |
| US11727115B2 (en) | Secured computer system | |
| EP3701411A1 (en) | Software packages policies management in a securela booted enclave | |
| US10764038B2 (en) | Method and apparatus for generating terminal key | |
| CN109891425B (en) | Sequence verification | |
| CN115544586B (en) | Secure storage method for user data, electronic device and storage medium | |
| KR20190033930A (en) | Electronic device for encrypting security information and method for controlling thereof | |
| US11520771B2 (en) | Measurement update method, apparatus, system, storage media, and computing device | |
| US20200244461A1 (en) | Data Processing Method and Apparatus | |
| US20090187898A1 (en) | Method for securely updating an autorun program and portable electronic entity executing it | |
| CN108990041B (en) | Method and equipment for setting main card and auxiliary card | |
| CN111353150B (en) | Trusted boot method, trusted boot device, electronic equipment and readable storage medium | |
| KR20180073041A (en) | Electronic device, method for controlling thereof and computer-readable recording medium | |
| CN116776317A (en) | System validity verification method and device and electronic equipment |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |