Risks
As with almost all interventions in complex systems, there are also risks involved in flashing modified software and firmware that must be taken into account.
Root access
Rooting or enabling root access means access to the root directory of a system, i.e. unrestricted access to all files in a system. With Android systems this is not possible at first. Only by flashing a custom recovery this becomes possible. However, the root access only works in the recovery. In order to get access to the whole system in the Android system itself, extra packages like Magisk or SuperSU have to be flashed. Such packages can quickly pose additional security risks for inexperienced users. In addition, there are apps that check whether the device is rooted before each start and then deny use if necessary, for example banking apps.
Risks with flashing
A fundamental risk to be considered when flashing is the loss of warranty. If the device is operated with software not certified by the manufacturer, the warranty claim will expire in most cases. However, some manufacturers accept warranty claims if the stock ROM is restored and the bootloader is locked again. This is not possible with Samsung, where the bootloader has software built into it called Knox, which detects and stores whether the bootloader has ever been unlocked. In such a case any warranty claim will be void, even in case of pure hardware defects.
A further risk is the possibility of irrevocably destroying the device, of “bricking”. Especially less experienced users should be warned against this. However, almost every cell phone can be restored via the fast boot mode with the stick ROM flash and so. Last but not least there is an emergency download mode for devices with Qualcomm Chipsets, which allows “deep flashing” and “unbricking” of “bricked” devices.
It is virtually impossible to flash an image that does not correspond to the device. In general TWRP refuses to install unsuitable software unless the device check has been removed or modified in the flash script.
Since the generation of a custom ROM often requires reverse engineering, where trial and error is the only possibility for error correction, not every custom ROM works without problems at first go.
For example, custom ROMs are often in beta or alpha stage and do not yet work as well as they should. Especially the device specific source code, i.e. the device trees, do not always work directly with every Android update, but have to be made compatible in painstaking detail work. For the Xiaomi Redmi Note 4X, for example, there were problems with the fingerprint sensor of the manufacturer Goodix during the custom ROM update to Android 10. Especially with this manufacturer and Android updates by communities there are always problems.
It may well be that not every developer is sympathetic to the modding communities. For example, in the case of the Xiaomi Pocophone F1, the fake kernel of the developer Arter97 was published without his knowledge. As it later turned out, it was not his kernel, but malware that permanently blocks the device for the user and sends data from the device to the developer. So users should be very careful where and from whom they obtain software and firmware. The XDA forum is a good place to go for this, telegram groups are somewhat more problematic, since anyone can distribute software here, even if it has not been tested.
The further use of custom ROMs can lead to restrictions in functionality, especially in banking apps. These check the status of the bootloader in part very precisely or rely on Google services like Safetynet that collides with installations like Magisk SuperUser. As a result, some banking apps refuse to start. The developer of Magisk tries to hide the rooting from the system and to outwit Google’s Safetynet, on which many apps depend. However, this is like a cat and mouse game between him and Google, which keeps blocking his patches.
Unlocked Bootloader
The unlocked bootloader is often mentioned as a major security risk with custom ROMs. This enables a stranger to play software on the device without the user’s knowledge if the device is lost or in the case of so-called evil maid attacks in which the cell phone is unattended and physically available to the attacker.
Therefore, there are efforts in the custom ROM scene to make it possible to lock the bootloader after flashing the custom ROMs again, despite major hurdles. To do this, the Android Verified Boot and the Android Secure Boot Patch would have to be applied correctly when compiling and the generated images of the system would have to be signed with the correct keys and sums. So far only GrapheneOS could realize this for the Google Pixel devices as first custom ROM. Recently, /e/OS, a custom Android based deGoogled ROM also announced lockable bootloader with Fairphone owing an official partnership with them. It is not verified boot like GrapheneOS and Pixel combination as of yet but only secure boot, which you may please note.
