Root permission obtaining method, burning method and electronic equipment

Abstract

The invention 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 mirror image with an identification mapping file in the electronic equipment; starting the electronic equipment, and enabling the electronic equipment to enter a factory test semi-boot mode based on the identification mapping file; and closing permission verification of the electronic equipment to complete root permission acquisition. According to the method, the factory test semi-boot mode is entered under the guidance of the identification mapping file under the user version system mirror image, more permissions can be opened under the factory test semi-boot mode, and acquisition of the highest permission root permission can be completed under the condition that permission verification is closed. Therefore, according to the method and the device, the root permission can be acquired by only programming the system mirror image of the final user version, and a test version system for acquiring the root permission does not need to be additionally programmed, so that the production process is simplified, and a more efficient equipment production process is realized.

Description

Technical Field

[0001] The present invention 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 Art

[0002] Android devices need to obtain root permissions to perform some operations before leaving the factory. However, in order to ensure the safety of Android devices after leaving the factory, root permissions of Android devices need to be restricted when leaving the factory.

[0003] In the related art, an open system with open root permissions needs to be burned first for developers to operate before leaving the factory, and then a user system with limited root permissions for users to use needs to be burned. Therefore, two burning operations are required, which is time-consuming, labor-intensive, and cumbersome. Summary of the invention

[0004] The technical problem to be solved by the present invention is to provide a root permission acquisition method, a burning method and an electronic device to achieve a more efficient Android device production process.

[0005] In order to solve the above technical problems, a technical solution adopted by the present invention is: A root permission acquisition method is applied to an electronic device, the method comprising: Burning a user version system image with an identification image file in an electronic device; Turning on the electronic device, and entering the electronic device into a factory test semi-boot mode based on the identification image file; The permission check of the electronic device is turned off to complete the acquisition of root permissions.

[0006] In order to solve the above technical problems, another technical solution adopted by the present invention is: A burning method, characterized in that it is applied to an electronic device and is implemented based on a root permission acquisition method according to any one of claims 1 to 5, comprising: After obtaining the root permission, performing permission operations on the electronic device in a factory test semi-boot mode of the electronic device; After completing the permission operation, delete the identification image file and restart the electronic device.

[0007] In order to solve the above technical problems, another technical solution adopted by the present invention is: An electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, each step of the above-mentioned method for obtaining permissions in the production of an Android device is implemented.

[0008] The beneficial effects of the present invention are as follows: the present application directly burns the user version system image that can eventually be shipped, and adds an identification image file in the user version system image; in the electronic device startup program, it can automatically enter the factory test semi-boot mode based on the identification image file, and the factory test semi-boot mode will open more permissions, and the highest authority root permission can be obtained when the permission check is turned off. Therefore, the present application can achieve the acquisition of root permissions by only burning the final user version of the system image, without the need to additionally burn the test version system for obtaining root permissions, simplifying the production process and achieving a more efficient equipment production process. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 A flowchart of a method for obtaining root permissions provided by an embodiment of the present invention; Figure 2 A flowchart of a method for burning data provided by an embodiment of the present invention; Figure 3 A flowchart of the steps of a root permission acquisition method and a burning method provided by an embodiment of the present invention in a specific scenario; Figure 4 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0010] In order to make the technical problems, technical solutions and beneficial effects to be solved by the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0011] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0012] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or combinations thereof.

[0013] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0014] In the related art, Android devices need to rely on root permissions to perform some operations in the production process in the production environment before leaving the factory, such as writing keys (googlekey), extracting configuration files (certificate configuration file csr.json), etc. In order to ensure the security of Android devices after leaving the factory, especially the security of financial terminals during use, to avoid irreversible modifications to the system of Android devices after leaving the factory that affect the normal use of Android devices, and also to ensure the security of Android devices during use, it is necessary to restrict root permissions or directly hide root permissions.

[0015] However, the current related technology usually adopts a method of burning a test (debug) version system with open root permissions in the Android system during the production process. After completing the operation requiring root permissions, the user (user) version system with limited root permissions provided to users is re-burned; this process requires two system burnings, which is cumbersome and reduces production efficiency.

[0016] In addition, two different versions of burning files need to be prepared during the production process, which increases the possibility of errors during the burning process.

[0017] In order to solve the above problems, the present application provides a method for obtaining root permissions. The following is a detailed introduction to the method for obtaining root permissions of the present application.

[0018] The root permission acquisition method in this application can be used in electronic devices. The electronic devices in this application can be electronic devices using the Android system, such as mobile phones, tablets, computers, etc., and also include various financial terminals such as POS machines, cash registers, etc.

[0019] The following is a detailed description of the root permission acquisition method in the present invention. Figure 1 , including steps 110 to 130.

[0020] Step 110: Burn the user version system image with the identification image file into the electronic device.

[0021] In one embodiment of the present application, step 110 includes step 111: burning a user version system image with a misc partition in the electronic device, wherein the misc partition includes an identification image file. In this way, when burning the system, a misc partition (used in the Android system to store device configuration information and temporary data) is set in the system, and the identification image file is set in the misc partition. Because the identification image file is used to guide the electronic device to enter the factory test semi-boot mode before the electronic device leaves the factory, it needs to be deleted after the electronic device completes the production process, and the electronic device cannot enter the factory test semi-boot mode, thereby ensuring the safety of the electronic device after it is put into formal use; because the identification image file needs to be deleted, it is set in the misc partition to facilitate the search of the identification image file, thereby further improving production efficiency.

[0022] For example, a user version system image containing misc.img is burned in an electronic device, and the identifier ffbm-01 is written in misc.img, then the partition formed after burning has the identifier ffbm-01. In this way, during the factory burning process, a misc partition is added to the user version system image and the identifier ffbm-01 is written in it, so that the electronic device can enter the ffbm mode (factory test semi-boot mode) during the boot process, thereby obtaining root permissions.

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

[0024] In one embodiment of the present application, step 120 includes step 121: turning on the electronic device, if it is determined in the startup program that the electronic device includes an identification image file, setting the mode identifier in the startup parameters of the electronic device to the factory test semi-boot identifier, 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 identifier in the startup parameters is correspondingly set to the factory test semi-boot identifier, and then if it is necessary to verify the current mode later, it can be verified by reading the mode identifier, so that other operations in the system can be indicated that the current system has entered the factory test semi-boot mode and obtain the corresponding system permissions that are opened.

[0025] For example, during the boot process of an electronic device with an Android system, the bootlinux (Linux boot program boot) of the electronic device will read the identifier in the misc partition through recovery.c to determine which mode to enter during the execution of the main function of the boot program BootLinux.c. If ffbm-01 is read, it will be passed to UpdateCmdLine.c used to update the boot command line. After UpdateCmdLine.c recognizes ffbm-01, it will determine that the ffbm mode needs to be entered during the boot phase, and write the read identifier ffbm-01 into the androidboot.mode attribute to identify the device boot mode. In this way, by utilizing the original judgment process of entering different modes during the boot process of the Android device, by burning the misc partition and writing the ffbm-01 identifier in it as a parameter and passing it to the boot process, the device can enter the ffbm mode after the boot process is completed, thereby allowing root permissions to be obtained.

[0026] In one embodiment of the present application, when the electronic device is turned on, the step a is also included: turning on the electronic device, if the electronic device does not include the identification image file, the electronic device enters the user mode. In this way, when the electronic device is turned on, different modes are entered according to whether the identification image file exists. If it exists, the factory test semi-startup mode is entered based on the identification image file. If it does not exist, the user mode is directly entered. There is no need to separately burn two versions of the system with root permissions and without root permissions to achieve the management of root permissions in the production process. Whether to open the root permission can be managed directly by storing and deleting the identification image file in the device. When burning, the final user version system can be directly burned, which reduces the number of times the system is burned, thereby improving the efficiency of equipment production.

[0027] For example, if the user version system image without misc.img is burned, the misc partition cannot be read during the boot process, and the identifier ffbm-01 cannot be obtained. The ffbm mode will not be entered, but the normal user mode will be entered. In this way, when the identifier ffbm-01 in the misc partition cannot be recognized, the ffbm mode will not be entered, and the root permission cannot be obtained, ensuring the normal use and safety of the device.

[0028] Step 130: close the permission check of the electronic device to complete the acquisition of root permissions.

[0029] In one embodiment of the present application, step 130 includes step 131: verifying whether the mode identifier is a factory test semi-boot identifier in the factory test semi-boot mode, and if so, turning off the permission check of the security kernel and executing the root permission opening step; otherwise, turning on the permission check of the security kernel. In this way, it is possible to verify whether the factory test semi-boot mode is turned on by checking whether the mode identifier is a factory test semi-boot identifier, so that the current system status can be quickly obtained through the mode identifier. If the mode identifier is not a factory test semi-boot identifier, the security kernel needs to be verified, and the root permission cannot be directly opened. By adding the identifier verification, it is further ensured that the system is in a safe state when the root identifier is turned on.

[0030] For example, in an Android device, a mandatory security check is performed through selinux.cpp, in which the IsEnforcing function is used to check whether the system properties or kernel parameters are set to enable the mandatory execution of selinux. In this case, the judgment of androidboot.mode can be added to the IsEnforcing function. From the previous example, it can be seen that during the boot process of an Android device, if the ffbm mode can be entered, the value of androidboot.mode will be written to ffbm-01. If the IsEnforcing function judges that the value of androidboot.mode is ffbm-01, the mandatory security check can be turned off, so that the root permission can be directly obtained. In this way, in the mandatory security check, the judgment of whether the ffbm mode has been entered is realized by adding the judgment of androidboot.mode. If the ffbm mode has been entered, the mandatory security check selinux is turned off so that the root permission can be directly obtained. If the ffbm mode has not been entered, the security check is kept turned on to protect the device. By adding the judgment of the value of the androidboot.code attribute, the flexible control of whether the root permission is open can be realized to meet the different requirements of the production process and user use.

[0031] In summary, by adding an identification image file to the official user version system image that can be used directly, after the electronic device is turned on, it can enter the factory test semi-boot mode according to the identification image file and modify the corresponding identification; in the factory test semi-boot mode, the permission check of the security kernel is turned off according to the corresponding identification, so that the root permission can be directly obtained, so that the root permission required for the production state can be obtained when the electronic device is burned with the final user version, without having to burn a special debug version with root permission first, and then burn the official user version after completing the permission operation, thereby improving the development efficiency. And by marking with the identification image file, when the identification image file is deleted, it is impossible to enter the factory test semi-boot mode during the boot process, thereby realizing the permission limitation of the user version and ensuring the safety of the device after leaving the factory.

[0032] The following specifically describes a burning method in the present invention, referring to the attached Figure 2 , including steps 210 to 220.

[0033] In one embodiment of the present application, a burning method in the present invention is used for an electronic device that has obtained root permission, for example, an electronic device that has obtained root permission based on the above-mentioned root permission obtaining method.

[0034] Step 210: After obtaining the root authority, perform authority operations on the electronic device in the factory test semi-boot mode of the electronic device.

[0035] In one embodiment of the present application, performing permission operations on the electronic device in the factory test semi-boot mode of the electronic device in step 210 includes step 211: importing a key into the electronic device in the factory test semi-boot mode of the electronic device. In this way, the key is imported in the factory test semi-boot mode, which can ensure that the root permission required for the key import operation is available, and the key import process is implemented in the secure environment of the factory, thereby ensuring the security of the key import process.

[0036] Among them, permission operations can also include permission operations that require root permissions to execute, such as writing googlekey and extracting configuration files (certificate configuration file csr.json).

[0037] Step 220: After completing the permission operation, delete the identification image file and restart the electronic device.

[0038] In one embodiment of the present application, step 220 includes step 221: after completing the permission operation, erase the misc partition and restart the electronic device. In this way, the identification image file is saved in the misc partition, which is a partition used to store device configuration information and temporary data. The identification image file can be directly deleted by erasing the misc partition, which will not affect the normal use of the system, and there is no need to specifically retrieve the identification image file from the file for deletion. It only needs to directly operate the misc partition, which further improves the execution efficiency.

[0039] In one embodiment of the present application, step 220 further includes 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 performed on the basis of retaining the root authority, 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 can no longer be read after the system is restarted, so that the factory test semi-boot mode will not be entered.

[0040] For example, after completing the permission operation, you can enter fastboot mode (fast boot mode) through the adb reboot bootloader command, and then erase the misc partition data by executing the fastboot erase misc command. After the deletion is complete, restart the electronic device through the fastboot reboot command. After the restart, because the misc partition is erased, the electronic device cannot read the misc partition and cannot obtain the identifier ffbm-01, and will not enter the ffbm mode, so it cannot directly obtain root permissions. After the production process is completed, the misc partition can be erased and provided to users for use without the need to burn a debug version image with root permissions in the production process.

[0041] To sum up, after obtaining the root permission through the above-mentioned root permission acquisition method, the device can be operated on permission in the factory test semi-power-on mode through steps 210-220. After completing the permission operation, the identification image file is deleted and the electronic device is restarted. Then, after the restart, the electronic device cannot recognize the identification image file during the startup process, and will no longer enter the factory test semi-power-on mode, and thus cannot obtain the root permission. By controlling whether the factory test semi-power-on mode can be entered through the identification image file, there is no need to burn the system twice, only the final user version system with the identification image file needs to be burned once, and after completing the permission operation, the identification image file is deleted and restarted to complete the opening and closing of the root permission.

[0042] The following is a detailed introduction to the application embodiments of the present application. In the related art, it is necessary to separately burn a test (debug) version system with open root permissions during the production process to support operations that require root permissions during the production process. After completing the permission operation, in order to ensure the safety of the electronic equipment after leaving the factory, it is also necessary to re-burn the user (user) version system with limited root permissions provided to users. That is, the production line process steps in the related art include: Step 1: Burn the debug version; Step 2: Write googlekey; Step 3: Burn the user version. The updated process steps of this application are: Step 1: Burn the user version; Step 2: Write googlekey; Step 3: Erase the misc partition. This application does not need to burn the system twice, but only needs to burn the final user version system with an identification image file once, and after completing the permission operation, the identification image file is deleted and restarted to complete the opening and closing of root permissions.

[0043] This application can apply the above solution to the factory configuration process of electronic devices using the Android system. Figure 3 , comprising steps (1) to (6).

[0044] Step (1) burns the officially shipped user version image in the electronic device, the user version image contains misc.img (identification image file, forming misc partition after burning), and writes the identifier ffbm-01 in misc.img, so that the partition misc formed after burning has the identifier ffbm-01. This is equivalent to the above step 110.

[0045] Step (2) turns on the electronic device. During the bootlinux (Linux boot program boot) startup process of the electronic device (the process of executing the main function of BootLinux.c), recovery.c (reading parameters to determine which mode to boot into) reads the value ffbm-01 of the misc partition and passes it to UpdateCmdLine.c (including the UpdateCmdLine function, which is used to update the startup command line cmdline parameters. These parameters are passed to the kernel when the system starts). This is equivalent to the above step 121.

[0046] 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 is entered, and the ffbm mode (factory test semi-boot mode) cannot be entered. This is equivalent to step a above.

[0047] Step (3) After UpdateCmdLine.c recognizes ffbm-01, it determines that it is necessary to enter ffbm mode during the startup phase and writes the read value ffbm-01 into the androidboot.mode attribute (a system attribute used to identify the device startup mode). This is equivalent to the above step 121.

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

[0049] Step (4) In selinux.cpp (a mandatory security check mechanism in the Android system), the IsEnforcing function (used to check whether the system properties or kernel parameters are set to enable the mandatory execution of selinux) adds the judgment of androidboot.mode. If it is ffbm-01, the selinux policy is not started, that is, the selinux check is directly turned off, so that the root permission can be obtained when the user version is burned. This is equivalent to the above step 131. That is, after turning off the selinux check, the root permission is directly obtained through the adb root command.

[0050] Step (5) performs permission operations, such as writing a key (googlekey), extracting a configuration file (certificate configuration file csr.json), etc. This is equivalent to the above step 210.

[0051] After the required permission operation process is completed in step (6), enter the adb reboot bootloader to enter the fastboot mode, and then execute the fastboot erase misc command to erase the misc partition data. After restarting the terminal, execute step (2). In this way, the partition erase operation is supported in the fastboot mode, so that after the permission operation is completed, the identification image file can be deleted, so that the identification image file cannot be read after restarting to enter the normal boot mode. This is equivalent to the above step 220.

[0052] Among them, the reboot operation can be performed through the fastboot reboot command.

[0053] In summary, the msic.img image controls the ro.boot.mode attribute value to enter the ffbm mode, which supports root operations, and opens the selinux permission according to the androidboot.mode value, so that the root permission can be obtained in the ffbm mode, and the root permission can be closed in the normal Android startup mode to achieve a security effect. After ffbm executes the permission operations such as writing googlekey, it enters the bootloader mode and erases the misc image (fastboot erase misc), so that the next time the electronic device is started, it will not enter the ffbm mode because it cannot read misc.img, but will enter the Android system normally. In this way, the permission difference control requirements during the production process and after the official launch can be met through a single image burning, which improves production efficiency.

[0054] Please refer to Figure 4 The present invention also provides an electronic device 300, including a memory 301 and a processor 302, and a computer program stored in the memory 301 and running on the processor 302. When the processor 302 executes the computer program, it implements the various steps in a root permission acquisition method or a burning method as described above.

[0055] The beneficial effects of the electronic device of the present invention are the same as those of the above method and will not be described in detail here.

[0056] The above are only embodiments of the present invention, and are not intended to limit the patent scope of the present invention. Any equivalent transformations made using the contents of the specification and drawings of the present invention, or directly or indirectly applied in related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A method for obtaining root permissions, characterized in that: Applied to electronic equipment, the method comprises: Burning a user version system image with an identification image file in an electronic device; Turning on the electronic device, and entering the electronic device into a factory test semi-boot mode based on the identification image file; The permission check of the electronic device is turned off to complete the acquisition of root permissions.

2. A method for obtaining root permissions according to claim 1, characterized in that: Also includes: The electronic device is turned on, and if the electronic device does not include an identification image file, the electronic device enters a user mode.

3. A method for obtaining root permissions according to claim 1, characterized in that: The step of starting the electronic device and entering the factory test semi-boot mode based on the identification image file includes: Turning on the electronic device, if it is determined in the startup program that the electronic device includes an identification image file, setting the mode identifier in the startup parameters of the electronic device to a factory test semi-boot identifier, and instructing the electronic device to enter a factory test semi-boot mode; The step of closing the permission check of the electronic device and completing the acquisition of the root permission includes: In the factory test semi-boot mode, verify whether the mode identifier is the factory test semi-boot identifier. If so, turn off the permission check of the security kernel and execute the root permission opening step.

4. A method for obtaining root permissions according to claim 3, characterized in that: The verifying whether the mode identifier is the factory test semi-boot identifier in the factory test semi-boot mode further includes: If the mode identifier is not the factory test half-boot identifier, the permission check of the security kernel is enabled.

5. A method for obtaining root authority according to claim 1, characterized in that: The method of burning a user version system image with an identification image file in an electronic device comprises: A user version system image with a misc partition is burned in an electronic device, wherein the misc partition includes an identification image file.

6. A burning method, characterized in that: The method is applied to an electronic device and implemented based on a root permission acquisition method according to any one of claims 1 to 5, comprising: After obtaining the root permission, performing permission operations on the electronic device in a factory test semi-boot mode of the electronic device; After completing the permission operation, delete the identification image file and restart the electronic device.

7. A burning method according to claim 6, characterized in that: The performing permission operation on the electronic device in the factory test semi-power-on mode of the electronic device includes: The key is imported into the electronic device in a factory test semi-boot mode of the electronic device.

8. A burning method according to claim 6, characterized in that: After completing the permission operation, deleting the identification image file and restarting the electronic device includes: After completing the permission operation, erase the misc partition and restart the electronic device.

9. A burning method according to claim 6, characterized in that: After completing the permission operation, deleting the identification image file and restarting the electronic device includes: After completing the permission operation, the electronic device is instructed to enter a fast boot mode, in which the identification image file is deleted and the electronic device is restarted.

10. An electronic device, characterized in that: It comprises a memory, a processor and a computer program stored in the memory and running on the processor, and when the processor executes the computer program, each step in a method for obtaining root authority as described in any one of claims 1 to 5 is implemented.

Images