In fact, in my understanding, it should be two: 1, right 2, and root. For 1, permission cancellation is to take advantage of the loopholes in the system to obtain permissions that could not be obtained originally and enhance the permissions of this application. Known vulnerability: 1.a: The previously mentioned vulnerability using adbd is valid in 2. X era. This utilization process is still very complicated and takes a long time; 1.b: Samsung CPU vulnerability, for example, this vulnerability can be used to ROOT on the Galaxy system, and this vulnerability is easy to use and can be used in APK code. I used it on Galaxy Note. Power-up is not necessarily for the main system (Android system), but also for the auxiliary systems (BOOTLOADER and RECOVERY). 1.c: Samsung mobile phones can take advantage of a loophole in BOOTLOADER (I'm not sure if it is a loophole, but Samsung itself has no official unlocking tool. Is it officially provided? ), you can brush the package at will, so that we can modify the system partition in this way, and everyone has the right to modify the system partition. It takes more than a few minutes to upload a file. What is officially unlocked is the provision method, which allows users to brush in custom files. The old versions of 1.OPhone system (2.0, 2.5) have loopholes in path handling (I wonder if anyone else uses this system). It has a customized upk upgrade package, which can only handle files under /system/carrier, but the path processing is estimated to be text comparison. You can modify the files under/system /app through/system/operator/bypassing its management system ../app. Generally speaking, the vulnerability of the main system is the most harmful to users, because it enables an application with ordinary rights to access resources that it has no right to access. For the Samsung CPU vulnerability, if the application uses it to improve the permissions and directly access the database file of SMS instead of the provider provided by Android, then the system will not have the opportunity to use sandbox checking, and users will not know what they have done. It can't be seen from its permission application list that it can read short messages. There is no way for an ordinary application to solve the vulnerability of the auxiliary system, because the auxiliary system is not started at ordinary times. But it's not useless. For 2, the ROOT in my understanding is to install the ROOT management tool. For Linux distributions, it provides root management tools su and sudo. But for Android, there is no ROOT management tool, so we need to use the process of power lifting to insert the ROOT management tool into the system, which is convenient for us to use higher permissions. Because after all, the process of power promotion is generally not easy to achieve. For example, the vulnerability of BOOTLOADER or RECOVERY we mentioned cannot be used in the main system, and ROOT management tools need to be installed before it can be used in the main system. Because the system can be modified after ROOT, there is also a chance to fix known vulnerabilities, such as the vulnerability of Samsung CPU mentioned above. Due to the water level of half a bucket, the following may not be correct. Please be gentle: system security will not be reduced because of ROOT itself, unless the ROOT administrator has a loophole. Therefore, the use of security recovery and security root manager through official unlocking is consistent with official security. However, the two black "security" reminds us that not all the ROOT tools on the market are safe, so we must choose a recognized safe way when using them. For example, the SuperU.apk and its corresponding su application that we usually use will prompt the user for permission when applying for ROOT permission at the application layer.