What you need to know
- Security researcher John Wu has found undocumented APIs that let apps with Admin privileges install new system apps on the Mate 30.
- The permissions are used by the "LZPlay" app to install the Google framework and services, but Wu says they're also a security risk.
- Huawei says the Mate 30 does not ship with GMS, and that it has "no involvement" with LZPlay.
Shortly after this update was published, the LZPlay website was taken down, and the app no longer works. Mate 30 devices with Google apps installed from LZPlay no longer pass Google's CTS (compatibility testing suite) for things like DRM and Google Pay support.
The Mate 30 Pro is the first Huawei flagship to launch since the Chinese company was added to the U.S. government's Entity List, meaning it's unable to ship with Google apps and services. Shortly after launch, the "Google Service Assistant" app (aka LZPlay, from its website URL) became well known as a simple way to restore Google services to the Mate 30. Yet exactly how it worked wasn't known until developer and Android security expert John Wu got stuck into its inner workings.
In a piece published today on Medium, Wu says that the app uses undocumented Huawei MDM (mobile device management) permissions in order to install the key Google components and apps as system apps -- an unusual situation with implications for device security. What's more, Wu's research claims that in order to use these powerful undocumented permissions, the anonymous developer of LZPlay would need to have received certification from Huawei. In a statement to Android Central, Huawei has denied any involvement with LZPlay.
The main reason you can't simply install the Google Framework, GMS Core and the other underpinnings of Google's services like a normal APK file is because they're system apps, and use special permissions not available to regular apps. System apps can have way more control over your phone than an app you'd download from the Google Play Store. And although system apps can be updated with new versions -- for example, from the Play Store -- the originals must first be loaded on the /system partition by the phone's manufacturer. Updated versions of apps must then be signed with the same security key as the original version.
The /system partition normally can't be changed by users unless the phone is rooted. As such, Android users normally can't install new system apps -- which, for security reasons, is a very good thing.
Since Huawei can't legally do business with U.S. companies, it can't load these apps at the factory. Yet users also can't directly install Google services by themselves either, because they're system apps. (And since Huawei locks its bootloaders, rooting is also out of the question.)
The solution, for the creator(s) of LZPlay, is to use a powerful but undocumented subset of Huawei's Mobile Device Management APIs. MDM APIs give a huge amount of control over the device, and are often used by businesses to manage company-owned phones.
The two undocumented MDM permissions discovered by John Wu are:
At the risk of stating the obvious: The former is a permission to install system apps, and the latter is a permission to install an app which can't subsequently be uninstalled. Both are unusual even in the world of MDM, and according to Wu, neither currently features in Huawei's official documentation.
But wait a minute -- isn't it impossible to install new system apps?
Wu's research shows that apps like LZPlay don't install apps directly to the /system partition, which is read-only, but the same writeable storage as any other app. Thanks to the "install system app" MDM permission, Android then "flags" them as being system apps, granting them the correct permissions to work. And that's what's happening when LZPlay downloads Google's core components from... wherever it yanks them from.
Such an undocumented permission is very unusual and, if abused, potentially bad for security. Users do, however, have to choose to give an app Administrator permissions before they could be affected. And there are other security measures in place, which we'll get to soon, with Huawei acting as a gatekeeper for all its various MDM permissions. Yet, as Wu explains in his article, storing the original versions of system apps on the same writeable storage as other user apps opens up the possibility of easier tampering if some other security vulnerability is discovered. (Unlikely, but certainly not impossible.)
Wu combed through the Chinese documentation for Huawei's MDM SDK for more clues. He says that in order to use any of the MDM APIs, developers need to sign agreements with Huawei, justify their use of MDM permissions, and submit APK files for approval. Once approved, Wu says, Huawei provides a digital certificate necessary for the permissions to work.
And that only makes the situation with LZPlay all the more strange. Having undocumented MDM permissions that can install new system apps is certainly not normal, but at the same time it's the only way users could install Google services to an unlicensed phone, without completely torpedoing Android's built-in security. Yet the idea of the anonymous developer of LZPlay going through the lengthy MDM API approval process and gaining Huawei's blessing is even more bizarre.
Wu accuses Huawei of being "well aware" of LZPlay, and of allowing its continued existence:
However Huawei has denied any involvement with the app or the site. In a statement to Android Central, a Huawei spokesperson said:
And Wu says the APK file itself is similarly opaque:
(Ed. note: QiHoo Jiagu is a China-based firm specializing in mobile app security)
Someone paid money to create this app, was somehow able to get it certified, then forked out to design its professional-looking website and host its files and yet wants no credit. In fact, it seems they've gone out of their way to remain completely anonymous.
Wu's original research is well worth a read if you're considering using the LZPlay method to install Google apps on a Huawei phone. (Or if you just want to appreciate the software engineering mad science that's required to make all this work.) Between the anonymity of the app and the power of the permissions it uses, it's definitely worth looking at LZPlay with a critical eye.
Alex is global Executive Editor for Android Central, and is usually found in the UK. He has been blogging since before it was called that, and currently most of his time is spent leading video for AC, which involves pointing a camera at phones and speaking words at a microphone. He would just love to hear your thoughts at email@example.com, or on the social things at @alexdobie.
Until anyone can show any abuse from any of this, it's hard to get worked up about security "issues."
Just because a security hole has yet to be exploited is not a reason to dismiss said security hole. Particularly once the flaw has been disclosed publicly.
Is it a flaw? Isn't it working exactly as it's supposed to? I doubt anyone, least of all Huawei, is going to be keen on stopping this. And anyone resorting to it is already way beyond caring about security; they just made the best phone in the world better. As I understand it, it's been all the rage in China for some time now, and uninstalling it after it's served its purpose mitigates any security risk? Edit: Heh. Looks like hosting sites are being taken down, possibly pressured by Huawei themselves. Seems they might be concerned people are finding out about the backdoors to their devices. Go figure.
It would be wiser for Huawei to keep this phone in China as is. 'cause if they were being scrutinised before, this won't help them.
If Huawei needs to sign permissions and issue digital certificates, there's no way for them to not be involved or at least aware of these apps. And as such, under European Law, this might fall under promotion of piracy and could lead them into very nasty legal battles unnecessarily.
Huawei; It wasn't us nudge, nudge, wink, wink 😉
Get the best of Android Central in in your inbox, every day!
Thank you for signing up to Android Central. You will receive a verification email shortly.
There was a problem. Please refresh the page and try again.