Interesting information here. So, Cellebrite can unlock GOS devices but only up to 2022 updates. Stock pixels are still quite vulnerable
rogueFed then posted two screenshots of the Microsoft Teams call. The first was a Cellebrite Support Matrix, which lays out whether the company’s tech can, or can’t, unlock certain phones and under what conditions. The second screenshot was of a Cellebrite employee.
According to another of rogueFed’s posts, the meeting took place in October. The meeting appears to have been a sales call. The employee is a “pre sales expert,” according to a profile available online.
The Support Matrix is focused on modern Google Pixel devices, including the Pixel 9 series. The screenshot does not include details on the Pixel 10, which is Google’s latest device. It discusses Cellebrite’s capabilities regarding ‘before first unlock’, or BFU, when a piece of phone unlocking tech tries to open a device before someone has typed in the phone’s passcode for the first time since being turned on. It also shows Cellebrite’s capabilities against after first unlock, or AFU, devices.
As I understand this then, GOS users who have updated their software have nothing to worry about then, right? (atleast when the phone is locked in BFU or AFU modes)
I’d avoid making definitive statements like that. Cellebrite is just one of many companies developing these kinds of exploits. That being said, it’s clear that the approach GrapheneOS is taking with generic exploit protections and minimising attack surface (like by default disabling USB when locked) is effective.
We’ve reached out to Google to inquire about why a custom ROM created by volunteers is more resistant to industrial phone hacking than the official Pixel OS. We’ll update this article if Google has anything to say.
In their defense, they may have been more concerned with accidentally having a screen capture event register with their software and ruining their reputation and trust with the vendor.
Yes. However, please note that an attacker with ample resources and time can simply wait until an exploit becomes available. A device in the hands of an attacker will no longer be updated and is therefore vulnerable to new exploits that are discovered. For this reason, we also recommend setting a secure Diceware passphrase as the unlock method so that even if brute force is supported, for example, it is still very difficult for an attacker to decrypt the data.
In the After-First-Unlock state, a smartphone is generally more vulnerable to exploits. That’s why GrapheneOS also has an auto-reboot feature to put the device into BFU state after 18 hours by default.
We have a powerful tool to protect our devices: encryption. If your device is encrypted, no exploit will work; it is practically physically impenetrable, except for failures in the encryption software.
VeraCrypt is the best I know, and the most secure. Unfortunately, it is not available for smartphones.
However, for Android there is EDS, which is also a good solution.
Remember that before encrypting, you must make a backup in case something goes wrong.
This is not accurate. The device itself could easily still be exploitable even if encrypted and the keys are not loaded into RAM, and exploits in that state could allow brute forcing any potentially weak encryption keys. Even without directly decrypting the data, since you appear to be speaking to encryption generally here, attacks against a device with encrypted storage could take many forms and a device could hardly be described as impenetrable just because it has encrypted storage.
Modern Android devices already have their storage encrypted by default, and even if they didn’t I am confused as to what protection against exploits to the OS an app like the one you linked would provide.
Backed up where? To an unencrypted medium? Does the backup have any additional compensating controls for it being an unencrypted copy of apparently sensitive data?
I have yet to hear of a single case in which a device was compromised despite being robustly encrypted. The exploit would have to be against the encryption software, not the operating system, provided we are talking about full encryption.
EDS is “additional” encryption software for Android. It can encrypt personal documents in boxes and even hide them from view, which is useful.
Any compromise of an Android or iOS device would be a compromise of a robustly encrypted device, and such compromises happen all the time.
Why? The OS is running whether the keys are in RAM or not, in fact the encryption software is usually a part of the OS and compromising any part of the privileged OS components could give privileged access over the entire device.
Yeah, how does that protect the device itself against exploits?
You can absolutely still compromise a device using FBE. For example, there was a lock screen bypass affecting Pixels a while back, which also worked with BFU. But the fact remains that compromising the OS when all the user’s data is encrypted with keys that are not stored anywhere on the device is not particularly useful.
