Root permission acquisition method, burning method and electronic device

Abstract

The application discloses a root permission acquisition method, a burning method and electronic equipment. The root permission acquisition method comprises the following steps: burning a user version system image with an identification image file in the electronic equipment; starting the electronic equipment, and entering the electronic equipment into a factory test semi-boot mode based on the identification image file; and closing the permission check of the electronic equipment, and completing the acquisition of the root permission. The identification image file is used for guiding the electronic equipment to enter the factory test semi-boot mode under the user version system image. More permissions are opened in the factory test semi-boot mode, and the acquisition of the highest permission root permission can be completed under the condition that the permission check is closed. Therefore, the application can realize the acquisition of the root permission by burning only one version of the final user version system image, and the test version system for acquiring the root permission is not needed to be additionally burned, so that the production process is simplified, and a more efficient device production process is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of Android device development, and in particular to a root permission acquisition method, a burning method and an electronic device. BACKGROUND

[0002] An Android device needs to acquire root permission before being shipped for some operations, but in order to ensure the use safety of the Android device after being shipped, the Android device needs to limit root permission when being shipped.

[0003] In the related art, an open system with open root permission needs to be burned first for developers to operate before being shipped, and then a user system with limited root permission for users needs to be burned, so that two burning operations are required, which is time-consuming and laborious, and the procedure is complicated. SUMMARY

[0004] The present application solves the technical problem of providing a root permission acquisition method, a burning method and an electronic device, and realizing a more efficient Android device production process.

[0005] In order to solve the above technical problem, one technical solution adopted by the present application is:

[0006] A root permission acquisition method applied to an electronic device, the method comprising:

[0007] burning a user version system image with an identification image file in the electronic device;

[0008] turning on the electronic device, and based on the identification image file, entering the electronic device into a factory test semi-boot mode;

[0009] turning off the permission check of the electronic device, and completing root permission acquisition.

[0010] In order to solve the above technical problem, another technical solution adopted by the present application is:

[0011] A burning method applied to an electronic device and realized based on the root permission acquisition method of any one of claims 1-5, comprising:

[0012] after acquiring root permission, performing permission operation on the electronic device in the factory test semi-boot mode of the electronic device;

[0013] after completing the permission operation, deleting the identification image file and turning on the electronic device again.

[0014] In order to solve the above technical problem, another technical solution adopted by the present application is:

[0015] An electronic device comprises a memory, a processor, and a computer program stored on the memory and running on the processor, wherein the processor implements each step of the above-mentioned method for obtaining root permission in production of an Android device when executing the computer program.

[0016] The application has the beneficial effect that the application can finally burn the user version system image to be shipped and add an identification image file in the user version system image; in the electronic device startup program, the identification image file can be used to automatically enter the factory test semi-boot mode, more permissions can be opened in the factory test semi-boot mode, and the acquisition of the highest permission root permission can be completed without permission verification. Therefore, the application can realize the acquisition of the root permission by only burning the final user version system image, without burning the test version system for acquiring the root permission, thereby simplifying the production process and realizing a more efficient device production process. BRIEF DESCRIPTION OF DRAWINGS

[0017] Figure 1 A step flowchart of a root permission acquisition method provided for an embodiment of the application;

[0018] Figure 2 A step flowchart of a burning method provided for an embodiment of the application;

[0019] Figure 3 A step flowchart of a root permission acquisition method and a burning method provided for an embodiment of the application in a specific scenario;

[0020] Figure 4 A structural schematic diagram of an electronic device provided for an embodiment of the application. DETAILED DESCRIPTION

[0021] In order to make the technical problems, technical solutions and beneficial effects of the application clearer, the application will be further described in detail below in combination with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the application and not to limit the application.

[0022] In the following description, specific details are set forth in order to provide a thorough understanding of embodiments of the application. However, persons skilled in the art will understand that embodiments of the application can be practiced without these specific details. In other instances, well-known structures, devices, circuits, and methods have not been described in detail in order to avoid obscuring the application.

[0023] It should be understood that the word “comprising” when used in the specification and claims of this application indicates the existence of the stated features, integers, steps, operations, elements, and / or components but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0024] Reference throughout this application to “one embodiment” or “some embodiments” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the application. Thus, the appearances of the phrases “in one embodiment”, “in some embodiments”, “in other embodiments”, “in additional embodiments”, and so on, in various places throughout this specification are not necessarily all referring to the same embodiment, unless otherwise specified. The terms “comprising”, “including”, “having” and their variants, as used in this application, mean “including but not limited to”, unless otherwise specified.

[0025] In the related art, some operations in the production environment before the Android device is shipped need to rely on root permission, such as writing a key (google key), extracting a configuration file (certificate configuration file csr.json), and the like. In order to ensure the security of the Android device after it is shipped, especially the security of the financial terminal in use, avoid the system of the Android device being modified irreversibly after it is shipped, affecting the normal use of the Android device, and in order to ensure the security of the Android device in use, the root permission needs to be limited or directly hidden.

[0026] However, in the related art, a test (debug) version system with open root permission is usually burned in the Android system in the production process, and after the operation requiring root permission is completed, a user (user) version system providing limited root permission for use is re-burned for the user to use. In this process, the system needs to be burned twice, which is complicated and reduces the production efficiency.

[0027] Moreover, two different versions of the burning file need to be prepared in the production process, which increases the possibility of errors in the burning process.

[0028] To solve the above problems, the application provides a root permission acquisition method. The following will introduce a root permission acquisition method of the application.

[0029] The root permission acquisition method in the application can be used in an electronic device. The electronic device in the application can be an electronic device using an Android system, such as a mobile phone, a tablet computer, a computer, and the like, and further includes various financial terminals, such as a POS machine and a cash register.

[0030] The root permission acquisition method in the application is specifically described below with reference to the accompanying drawings. Figure 1 and includes steps 110-130.

[0031] Step 110: Burn a user version system image with an identification image file in the electronic device.

[0032] In an embodiment of the application, step 110 includes step 111: burn a user version system image with a misc partition in the electronic device, and the misc partition includes the identification image file. In this way, the misc partition (used for storing configuration information and temporary data of a device in an Android system) is set in the system when the system is burned, and the identification image file is set in the misc partition. Since the identification image file is used to guide the electronic device to enter a factory test semi-boot mode before the electronic device is shipped, the identification image file needs to be deleted after the production process of the electronic device is completed, so that the electronic device cannot enter the factory test semi-boot mode, thereby ensuring the use safety of the electronic device after being put into formal use. Since the identification image file needs to be deleted, the identification image file is set in the misc partition to facilitate the search of the identification image file, thereby further improving the production efficiency.

[0033] For example, a user version system image containing misc.img is burned in the electronic device, and the identification ffbm-01 is written in misc.img. In this way, the partition formed after being burned contains the identification ffbm-01. In this way, the misc partition is added to the user version system image during the factory burning process, and the ffbm-01 identification is written in the misc partition, so that the electronic device can enter the ffbm mode (factory test semi-boot mode) during the booting process, thereby acquiring the root permission.

[0034] Step 120: Turn on the electronic device, and enter the electronic device into the factory test semi-boot mode based on the identification image file.

[0035] In an embodiment of the present application, step 120 comprises step 121: starting the electronic device, if it is determined in the starting program that the electronic device comprises the identification image file, setting the mode identification in the starting parameter of the electronic device to the factory test semi-boot identification, and instructing the electronic device to enter the factory test semi-boot mode. In this way, after entering the factory test semi-boot mode, the mode identification in the starting parameter is set to the factory test semi-boot identification, and the subsequent verification of the current mode can be verified by reading the mode identification, so as to instruct other operations in the system that the current system has entered the factory test semi-boot mode, and obtain the corresponding system permission.

[0036] For example, in the booting process of the electronic device of the Android system, the bootlinux (Linux boot program boot) of the electronic device reads the identification in the misc partition through recovery.c in the process of executing the main function of the starting program BootLinux.c to determine which mode to enter, if ffbm-01 is read, it will be passed to UpdateCmdLine.c for updating the starting command line, UpdateCmdLine.c identifies ffbm-01, and determines that the ffbm mode needs to be entered in the starting stage, and writes the read identification ffbm-01 to the androidboot.mode attribute for identifying the device starting mode. In this way, by using the judgment process of entering different modes in the original booting process of the Android device, the misc partition is burned and the ffbm-01 identification is written in it as a parameter to the booting process, so that the device can enter the ffbm mode after the booting process is completed, thereby allowing the root permission to be obtained.

[0037] In an embodiment of the present application, when starting the electronic device, it further comprises step a: starting the electronic device, if the electronic device does not comprise the identification image file, the electronic device enters the user mode. In this way, the electronic device enters different modes according to whether the identification image file exists when starting, if it exists, it enters the factory test semi-boot mode based on the identification image file, if it does not exist, it directly enters the user mode, so it is not necessary to respectively burn two versions of the system with root permission and without root permission to realize the management of root permission in the production process, the management of whether to open the root permission can be directly realized by storing and deleting the identification image file in the device, so the final user version system can be directly burned when burning, reducing the number of times of burning the system, thereby improving the efficiency of device production.

[0038] For example, if the user version system image without misc.img is burned, the misc partition cannot be read in the booting process, and the identification ffbm-01 in the misc partition cannot be acquired, so the ffbm mode cannot be entered, and the normal user mode is entered. In this way, the ffbm mode cannot be entered when the identification ffbm-01 in the misc partition cannot be identified, so the root permission cannot be acquired, and the normal use and use safety of the device are ensured.

[0039] Step 130, the permission check of the electronic device is closed, and the root permission acquisition is completed.

[0040] In an embodiment of the present application, step 130 includes step 131: verifying whether the mode identification is the factory test semi-boot mode identification in the factory test semi-boot mode, if yes, the permission check of the security kernel is closed, and the root permission opening step is executed; otherwise, the permission check of the security kernel is opened. In this way, whether the factory test semi-boot mode is opened can be verified through whether the mode identification is the factory test semi-boot mode identification, so that the state of the current system can be quickly acquired through the mode identification, if the mode identification is not the factory test semi-boot mode identification, the security kernel needs to be verified, and the root permission cannot be directly opened. The system is ensured to be in a safe state when the root identification is opened through the identification verification.

[0041] For example, in the Android device, the selinux.cpp is used for the mandatory security check, and the IsEnforcing function is used for checking whether the system attribute or the kernel parameter is set to open the mandatory enforcement of selinux, so the judgment of androidboot.mode can be added in the IsEnforcing function. As known from the foregoing example, if the ffbm mode can be entered in the booting process of the Android device, the value of androidboot.mode will be written into ffbm-01, so if the value of androidboot.mode is ffbm-01 in the IsEnforcing function, the mandatory security check can be closed, so that the root permission can be directly acquired. In this way, the judgment of whether the ffbm mode is entered is realized through the judgment of androidboot.mode in the mandatory security check, if the ffbm mode is entered, the mandatory security check selinux is closed, so that the root permission can be directly acquired, if the ffbm mode is not entered, the security check is kept to be opened, so that the device is protected. The flexible control of whether the root permission is opened is realized through the judgment of the value of androidboot.code, so that the different requirements of the production process and the user use are met.

[0042] In summary, by adding the identification image file in the official directly usable user version system image, the electronic device can enter the factory test semi-boot mode according to the identification image file after booting, and the corresponding identification is modified. In the factory test semi-boot mode, the permission verification of the security kernel is closed according to the corresponding identification, so that the root permission can be directly obtained, which realizes the acquisition of the root permission required in the production state when the electronic device is burned with the final user version, without burning the special debug version with the root permission first, and then burning the official user version after completing the permission operation, thereby improving the development efficiency. Moreover, the identification is realized through the identification image file, and when the identification image file is deleted, the factory test semi-boot mode cannot be entered in the booting process, thereby realizing the permission limitation of the user version and ensuring the safety of the device after leaving the factory.

[0043] The following specifically introduces a burning method in the application, referring to the attached Figure 2 , including steps 210-220.

[0044] In an embodiment of the present application, the burning method in the application is used for an electronic device that has acquired the root permission, for example, an electronic device that has acquired the root permission based on the above-mentioned root permission acquisition method.

[0045] Step 210, after acquiring the root permission, performing the permission operation on the electronic device in the factory test semi-boot mode of the electronic device.

[0046] In an embodiment of the present application, the permission operation on the electronic device in the factory test semi-boot mode of the electronic device in step 210 includes step 211: importing the key to the electronic device in the factory test semi-boot mode of the electronic device. In this way, the key import is realized in the factory test semi-boot mode, the root permission required for the key import operation can be ensured, and the key import process is realized in the safe environment of the factory, thereby ensuring the safety of the key import process.

[0047] Among them, the permission operation can also be writing the googlekey, extracting the configuration file (certificate configuration file csr.json) and other permission operations that require root permission.

[0048] Step 220, after completing the permission operation, deleting the identification image file and restarting the electronic device.

[0049] In an embodiment of the present application, step 220 comprises step 221: after completing the permission operation, erasing the misc partition and restarting the electronic device. In this way, the identification image file is stored in the misc partition, which is a partition for storing configuration information and temporary data of the device, and the identification image file can be deleted by erasing the misc partition directly, without affecting the normal use of the system, and without the need to search for the identification image file in the file for deletion, and only the misc partition needs to be operated directly, further improving the execution efficiency.

[0050] In an embodiment of the present application, step 220 further comprises step 222: after completing the permission operation, instructing the electronic device to enter the fast boot mode, deleting the identification image file in the fast boot mode and restarting the electronic device. In this way, by entering the fast boot mode, basic operations on the system can be realized on the basis of retaining the root permission, such as deleting the identification image file and restarting the system, so that after deleting the identification image file, the system is restarted, and the identification image file cannot be read after the system is restarted, so that the factory test semi-boot mode cannot be entered.

[0051] For example, after completing the permission operation, the fastboot mode (fast boot mode) can be entered by the adb reboot bootloader instruction, and the misc partition data can be erased by executing the fastboot erase misc instruction, and after the deletion is completed, the electronic device is restarted by the fastboot reboot instruction, and after the restart, the electronic device cannot read the misc partition because the misc partition is erased, so the identification ffbm-01 cannot be obtained, and the ffbm mode cannot be entered, so the root permission cannot be directly obtained, so that after the production process is completed, the misc partition can be erased to provide the electronic device to the user for use, without the need to additionally burn the debug version image with root permission in the production link.

[0052] In summary, after the root permission is obtained through the above root permission obtaining method, the device can be operated in the factory test semi-boot mode through steps 210-220, and after the permission operation is completed, the identification image file is deleted and the electronic device is restarted. After restarting, the electronic device cannot identify the identification image file in the startup process, and will not enter the factory test semi-boot mode, so as to obtain the root permission again. The application controls whether to enter the factory test semi-boot mode through the identification image file, so that it is not necessary to burn twice the system, but only to burn once the final user version system with the identification image file, and after the permission operation is completed, the identification image file is deleted and restarted, so as to complete the opening and closing of the root permission.

[0053] The application embodiment of the present application will be described in detail below. In related technologies, a test (debug) version system with open root permission needs to be separately burned in the production process to support the operation requiring root permission in the production process. After the permission operation is completed, in order to ensure the safety of the electronic device after leaving the factory, the user (user) version system limiting the use of root permission needs to be re-burned for the user. That is, the production line process steps in related technologies include: step one: burn the debug version; step two: write the googlekey; step three: burn the user version. The updated process steps of the present application are: step one: burn the user version; step two: write the googlekey; step three: erase the misc partition. The present application does not need to burn twice the system, but only needs to burn once the final user version system with the identification image file, and after the permission operation is completed, the identification image file is deleted and restarted, so as to complete the opening and closing of the root permission.

[0054] The present application can apply the above scheme to the factory configuration process of an electronic device using an Android system. Referring to the accompanying drawings, Figure 3 , including steps (1)-(6).

[0055] Step (1) burns a formal shipment user version image in the electronic device, the user version image containing a misc.img (identification image file, forming a misc partition after burning), and writing the identification ffbm-01 in the misc.img. The partition misc formed after burning contains the identification ffbm-01. It is equivalent to step 110 described above.

[0056] Step (2) opens the electronic device, and in the booting process of the electronic device (the process of executing the main function of BootLinux.c), recovery.c (reads parameters to determine which mode to start) reads the value ffbm-01 of the misc partition and passes it to UpdateCmdLine.c (includes the UpdateCmdLine function, which is used to update the command line parameters, which are passed to the kernel when the system starts). It is equivalent to step 121 described above.

[0057] If there is no misc partition, the value of ffbm-01 cannot be read, indicating that there is no identification image file, and the normal system startup process cannot be entered. It is equivalent to step a described above.

[0058] Step (3) UpdateCmdLine.c identifies ffbm-01, determines that the ffbm mode needs to be entered during startup, and writes the read value ffbm-01 to the androidboot.mode attribute (a system attribute used to identify the device startup mode). It is equivalent to step 121 described above.

[0059] After successfully entering the ffbm mode, the Android system desktop is not displayed, but the boot animation interface is displayed, which can be used to determine whether the ffbm mode has been successfully entered.

[0060] Step (4) In selinux.cpp (a kind of mandatory security check mechanism in the Android system), the IsEnforcing function (used to check whether the system attribute or kernel parameter is set to enable the enforcement of selinux) is added to the judgment of androidboot.mode. If it is ffbm-01, the selinux policy is not started, that is, the selinux verification is directly turned off, so that the root permission can be obtained in the case of burning the user version. It is equivalent to step 131 described above. That is, after turning off the selinux verification, the root permission is obtained directly through the adb root instruction.

[0061] Step (5) Perform permission operations, such as writing a key (google key), extracting a configuration file (certificate configuration file csr.json), and the like. It is equivalent to step 210 described above.

[0062] After step (6) is executed, the terminal enters fastboot mode through adb reboot bootloader, and then the misc partition data is erased by executing fastboot erase misc instruction, and step (2) is executed after the terminal is restarted. In this way, the erasing operation of the partition is supported in the fastboot mode, so that the identification image file can be deleted after the permission operation is completed, and the identification image file cannot be read after the terminal is restarted to enter the normal starting mode. It is equivalent to the above step 220.

[0063] Wherein, the reboot operation can be performed by fastboot reboot instruction.

[0064] In summary, the ro.boot.mode attribute value is controlled by the msic.img image to enter the ffbm mode, the root operation is supported in this mode, and the selinux permission is opened according to the androidboot.mode value, so that the root permission can be obtained in the ffbm mode, and the root permission is closed in the normal starting mode of Android, and the security effect is achieved. After the write googlekey permission operation is executed in the ffbm, the bootloader mode is entered, and the misc image is erased (fastboot erase misc), so that the electronic device cannot enter the ffbm mode when the electronic device is started next time because the misc.img cannot be read, and the electronic device will enter the Android system normally. Thus, the permission difference control requirement in the production process and after the formal online is met by one-time image burning, and the production efficiency is improved.

[0065] Please refer to Figure 4 The application further provides an electronic device 300, which comprises a memory 301, a processor 302, and a computer program stored in the memory 301 and running on the processor 302, and the processor 302 implements each step of the root permission obtaining method or the burning method when executing the computer program.

[0066] The electronic device of the application has the advantages of the above method, which will not be repeated here.

[0067] The above is only an embodiment of the application, and does not limit the patent range of the application, and any equivalent transformation or direct or indirect application in the related technical field by using the content of the application specification and drawings is also included in the patent protection range of the application.

Claims

1. A root authority acquisition method, characterized by, The method is applied to an electronic device of an Android system, and comprises the following steps: burning a user version system image with an identification image file in the electronic device, wherein the user version system image is stored in a configuration information storage area of the Android system; starting the electronic device, and entering the electronic device into a factory test semi-boot mode based on the identification image file; turning off permission verification of the electronic device to complete root permission acquisition; the step of starting the electronic device and entering the electronic device into the factory test semi-boot mode based on the identification image file comprises the following steps: starting the electronic device, and if it is determined in a starting program that the electronic device comprises the identification image file, setting a mode identification in starting parameters of the electronic device to a factory test semi-boot identification, and instructing the electronic device to enter the factory test semi-boot mode; the step of turning off permission verification of the electronic device to complete root permission acquisition comprises the following steps: verifying whether the mode identification is the factory test semi-boot identification in the factory test semi-boot mode, and if yes, turning off permission verification of a security kernel and executing a root permission starting step.

2. The root privilege acquisition method of claim 1, wherein, the method further comprises the following steps: starting the electronic device, and if the electronic device does not comprise the identification image file, entering the electronic device into a user mode.

3. The root privilege acquisition method of claim 1, wherein, the step of verifying whether the mode identification is the factory test semi-boot identification in the factory test semi-boot mode further comprises the following steps: if the mode identification is not the factory test semi-boot identification, turning on permission verification of the security kernel.

4. The root privilege acquisition method of claim 1, wherein, the step of burning the user version system image with the identification image file in the electronic device comprises the following steps: burning the user version system image with a misc partition in the electronic device, wherein the misc partition comprises the identification image file.

5. A method of burning, characterized by, The electronic device is applied to, and a root permission acquisition method according to any one of claims 1-4 is implemented, and the electronic device comprises the following steps: after acquiring the root permission, performing permission operation on the electronic device in the factory test semi-boot mode of the electronic device; after completing the permission operation, deleting the identification image file and restarting the electronic device.

6. The method of claim 5, wherein the step of writing the data comprises the step of: the step of performing permission operation on the electronic device in the factory test semi-boot mode of the electronic device comprises the following steps: ​ in the factory test semi-boot mode of the electronic device, importing a key to the electronic device.

7. The method of claim 5, wherein the step of writing the data comprises the step of: the step of deleting the identification image file and restarting the electronic device after completing the permission operation comprises the following steps: ​ after completing the permission operation, erasing the misc partition and restarting the electronic device.

8. The method of claim 5, wherein the step of recording the data comprises the step of: the step of deleting the identification image file and restarting the electronic device after completing the permission operation comprises the following steps: ​ after completing the permission operation, instructing the electronic device to enter a fast boot mode, deleting the identification image file in the fast boot mode, and restarting the electronic device.

9. An electronic device, comprising: The electronic device comprises a memory, a processor, and a computer program stored on the memory and running on the processor, and the processor implements each step of the root permission acquisition method according to any one of claims 1-4 when executing the computer program.

Images