The content of the article
Today in the issue: the story of the sensational vulnerability in smartphones based on MediaTek processors, the pitfalls of porting Android to the iPhone, the story of why the function of hiding root with Magisk will soon become useless. And also: inline classes and the principle of composition in Kotlin, a new way to start activities and request permissions, several new pentest tools and libraries for programmers.
MediaTek Processor Vulnerability History
Critical MediaTek rootkit affecting millions of Android devices has been out in the open for months – The history of detection and attempts to patch a critical bug in devices based on Chinese MediaTek processors.
Brief background: in early March, news of a very dangerous vulnerability revealed in virtually all devices using MediaTek 64-bit processors swept through all sites related to security and mobile devices. Not only did the vulnerability allow root access and disable SELinux (one of the basic Android security systems), it was also very easy to operate (one simple exploit that does not require special conditions for a successful hack).
The general public learned about the vulnerability thanks to the March Android security patch, in which it received a critical mark. However, the history of vulnerability detection does not begin at all with the patch, but with fasting diplomatic user on the XDA Developers forum. The post was dedicated to the Amazon Fire tablet.
A year ago, diplomatic discovered that the CMDQ driver in the Linux kernel for MediaTek processors accepts ioctl commands from anyone. Using these commands, you can access the DMA buffer, modify kernel memory, and disable SELinux. Later, diplomatic and other forum users found that the exploit works on almost all devices with a 64-bit MediaTek processor, with the exception of Vivo, OPPO, Huawei and Samsung devices with Android 8 and higher, which have protection against gaining root rights through exploits.
MediaTek patched the driver back in May 2019, but this did not just solve the problem. The fact is that MediaTek produces low-cost processors, and they are installed in state employees, whose support often ends when the smartphone is released from the assembly line. These are the same Blackview, Elefone and other Chinese consumer goods. Now all this is a portable backdoor, defenseless against the simplest malware, installed from warez (and this already exists – detected by Trend Micro Trojan uses the MediaTek vulnerability along with the CVE-2019-2215 vulnerability to gain control over the device).
It is for this reason that the patch for MediaTek ended up in the official Android security patch. This gives a chance that at least large manufacturers will update their devices so as not to violate the agreement on two-year device support. On the other hand, the share of patched devices is unlikely to rise above 1%.
Android porting history on iPhone
An adventure 13 years in the making – The history of the Sandcastle project, in which developers from the company Corellium managed to port Android to the iPhone.
The very possibility of porting appeared thanks to the checkm8 exploit, which exploits the vulnerability in the iPhone bootloader and allows not only to perform Jailbreak, but also gain full control over the device, including the ability to install and load alternative operating systems.
But it’s not even interesting, but what difficulties the developers have encountered. First of all, this is a custom Apple processor, which seems to be compatible with standard ARM, but has a lot of small differences: “almost” Samsung compatible UART-controller, “almost” Samsung compatible SPI-controller, non-standard interrupt controller, own way to enable additional processor cores and so on.
An even more interesting story happened with porting the Android platform on top of the already ported Linux kernel. It turned out that Android, in principle, does not support working with memory pages with a size other than 4 KB (Apple uses 16 KB). Android also turned out to be not quite a 64-bit system: in many places it is still possible to find 32-bit code that simply will not work on a fully 64-bit Apple processor.
Paradoxically, the Android port for iPhone was the first fully 64-bit Android build in history.
Bootloader unlock fact no longer hide
Magisk may no longer be able to hide bootloader unlocking from apps – An article on how Google beat the Magisk developer and made hiding the fact of unlocking the bootloader impossible.
Today, Magisk is the only reliable way to get root on the Android stock firmware. Magisk became popular and survived the war against Google due to the use of the rooting method, which does not require modification of the system partition, and the ability to hide the presence of root rights from certain applications (for example, banking clients, payment systems and online games).
To hide the root, Magisk uses several tricks that deceive the application and the SafetyNet system, designed to check the smartphone for security. For a long time, SafetyNet used heuristic methods to determine the root and unlock the bootloader (which is required to install Magisk).
However, users began to notice that some smartphones no longer pass SafetyNet testing with Magisk installed. Magisk's developer replied that sometimes SafetyNet no longer relies on a simple bootloader status check (which Magisk can trick), but instead uses a private encryption key from Keystore's secure repository to validate the transmitted data.
You can get around this protection only by gaining access to the private key, which is stored in a dedicated cryptographic coprocessor (TEE), and making it very problematic (Google pays between $ 250,000 and $ 1 million for such a vulnerability).
All this means that very soon all certified Google devices based on Android 8 and above will simply stop passing SafetyNet checks and Magisk will be useless if banking clients and other applications using SafetyNet are installed.
To the developer
StartActivityForResult in 2020
A first look at AndroidX Activity Result APIs – A small note about solving one of the most annoying tasks that arise when developing applications for Android.
It's about function
startActivityForResult(), which allows you to start the activity of another application in order to shift the solution to a specific problem: taking a picture using the camera, selecting a file, and so on. This mechanism seriously facilitates the life of the developer, but is implemented in the most inconvenient of possible ways. The developer needs to start the activity by passing it a special code, and then wait for the result in the callback implemented by overriding the method
onActivityResult() in activity or fragment. And all would be fine, but the request for authority is implemented in exactly the same way, so that the application code eventually creeps into a multitude of apparently unrelated functions.
There are many ways to solve this problem using third-party libraries, but this article talks about the official solution from Google. The alpha version of the AndroidX Activity library finally has an easy-to-use API that allows you to work with the activities of other applications without spreading the code by the activity of your application.
Continuation is available only to participants
Materials from the latest issues become available separately only two months after publication. To continue reading, you must become a member of the Xakep.ru community.
Join the Xakep.ru Community!
Membership in the community during the specified period will open you access to ALL Hacker materials, increase your personal cumulative discount and allow you to accumulate a professional Xakep Score!
I am already a member of Xakep.ru