# Someone Snuck Into a Cellebrite Microsoft Teams Call and Leaked Phone Unlocking Details **URL:** https://discuss.privacyguides.net/t/someone-snuck-into-a-cellebrite-microsoft-teams-call-and-leaked-phone-unlocking-details/32448 **Category:** News **Tags:** article **Created:** 2025-10-30T18:41:24Z **Posts:** 36 ## Post 1 by @KevPham — 2025-10-30T18:41:24Z > **[Someone Snuck Into a Cellebrite Microsoft Teams Call and Leaked Phone...](https://www.404media.co/someone-snuck-into-a-cellebrite-microsoft-teams-call-and-leaked-phone-unlocking-details/)** > > The leaked slide focuses on Google Pixel phones and mentions those running the security-focused GrapheneOS operating system. 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. ![IMG_3171](https://forum-uploads.privacyguidesusercontent.com/original/2X/6/653403931a48e6cfa00cd21125c4d3d8990ec82c.jpeg) --- ## Post 4 by @anon57862721 — 2025-10-30T18:47:55Z Is someone able to properly share what the highly blurry picture says? --- ## Post 5 by @phnx — 2025-10-30T19:07:48Z | Model / State | Standard Android OS BFU | Standard Android OS AFU | Standard Android OS | GrapheneOS BFU \* | GrapheneOS AFU \* | GrapheneOS Unlocked | | --- | --- | --- | --- | --- | --- | --- | | Pixel 6 / Pixel 6 Pro / Pixel 6a | BFU Yes, BF No | FFS Yes, BF No | FFS Yes | BFU Yes, up to late 2022 SPL, BF No | FFS Yes, up to late 2022 SPL, BF No | FFS Yes, up to late 2024 SPL | | Pixel 7 / Pixel 7 Pro / Pixel 7a / Pixel Tablet / Pixel Fold | BFU Yes, BF No | FFS Yes, BF No | FFS Yes | BFU Yes, up to late 2022 SPL, BF No | FFS Yes, up to late 2022 SPL, BF No | FFS Yes, up to late 2024 SPL | | Pixel 8 / Pixel 8a / Pixel 8 Pro | BFU Yes, BF No | FFS Yes, BF No | FFS Yes | BFU Yes, up to late 2022 SPL, BF No | FFS Yes, up to late 2022 SPL, BF No | FFS Yes, up to late 2024 SPL | | Pixel 9 / Pixel 9 Pro / Pixel 9 Pro XL / Pixel 9 Pro Fold / Pixel 9a | BFU Yes, BF No | FFS Yes, BF No | FFS Yes | BFU No, BF No | FFS No, BF No | FFS Yes, up to late 2024 SPL | | | | | | | | | | | | | | | | | --- ## Post 6 by @KevPham — 2025-10-30T19:08:40Z Ah if only the leaker knew how screenshots work :sweat_smile: Original (still blurry): [https://files.catbox.moe/80kwmt.jpg](https://files.catbox.moe/80kwmt.jpg) --- ## Post 7 by @anon57862721 — 2025-10-30T19:11:13Z Thank you! 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) --- ## Post 8 by @phnx — 2025-10-30T19:18:48Z 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. --- ## Post 9 by @anon57862721 — 2025-10-30T19:23:27Z Good to know. Thank you for the context and nuance. --- ## Post 10 by @kalium — 2025-10-30T23:25:27Z > **[Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking](https://arstechnica.com/gadgets/2025/10/leaker-reveals-which-pixels-are-vulnerable-to-cellebrite-phone-hacking/)** > > Cellebrite can apparently extract data from most Pixel phones, unless they’re running GrapheneOS. > 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. --- ## Post 11 by @Pfannkuchen — 2025-10-31T01:20:43Z Original leak thread: [https://discuss.grapheneos.org/d/27698-new-cellebrite-capability-obtained-in-teams-meeting](https://discuss.grapheneos.org/d/27698-new-cellebrite-capability-obtained-in-teams-meeting) --- ## Post 12 by @Encounter5729 — 2025-10-31T10:20:54Z Am I right? : FYI, FFS is just consent-based extraction of files. So extraction of files if you unlock your phone. --- ## Post 13 by @bitsondatadev — 2025-10-31T11:12:38Z 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. --- ## Post 14 by @lyricism — 2025-10-31T21:57:20Z FFS is full file system extraction, which is more extensive access than users normally have through the UI. --- ## Post 15 by @Drippy0370 — 2025-10-31T21:57:43Z Cellebrite is the market leader in digital forensics. If Cellebrite can’t do it, it’s highly unlikely that other companies will be able to. --- ## Post 16 by @Drippy0370 — 2025-10-31T22:00:54Z 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. --- ## Post 17 by @Drippy0370 — 2025-10-31T22:02:26Z 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. --- ## Post 18 by @TheRipper — 2025-10-31T22:12:06Z 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](https://veracrypt.io/en/Downloads.html) is the best I know, and the most secure. Unfortunately, it is not available for smartphones. However, for Android there is [EDS](https://edsng.sovworks.com/), which is also a good solution. Remember that before encrypting, you must make a backup in case something goes wrong. --- ## Post 19 by @lyricism — 2025-10-31T22:25:17Z > [@TheRipper](#): > > We have a powerful tool to protect our devices: encryption. If your device is encrypted, no exploit will work; it is practically physically impenetrable 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. > [@TheRipper](#): > > [VeraCrypt](https://veracrypt.io/en/Downloads.html) is the best I know, and the most secure. Unfortunately, it is not available for smartphones. > > However, for Android there is [EDS](https://edsng.sovworks.com/), which is also a good solution. 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. > [@TheRipper](#): > > Remember that before encrypting, you must make a backup in case something goes wrong. 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? --- ## Post 20 by @TheRipper — 2025-10-31T22:35:37Z 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. --- ## Post 21 by @lyricism — 2025-10-31T22:40:15Z > [@TheRipper](#): > > I have yet to hear of a single case in which a device was compromised despite being robustly encrypted. Any compromise of an Android or iOS device would be a compromise of a robustly encrypted device, and such compromises happen all the time. > [@TheRipper](#): > > The exploit would have to be against the encryption software, not the operating system, provided we are talking about full encryption. 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. > [@TheRipper](#): > > EDS is “additional” encryption software for Android. It can encrypt personal documents in boxes and even hide them from view, which is useful. Yeah, how does that protect the device itself against exploits? --- ## Post 22 by @phnx — 2025-10-31T22:43:43Z 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. --- ## Post 23 by @lyricism — 2025-10-31T22:48:17Z Ehhh I would disagree with even this conceptually. If I’ve truly compromised the OS even in BFU I can just set up a keylogger to wait for you to unlock your device and then come back and access your data later with the recorded credential. In practice that might be overly complex to pull off, but again in theory at least encryption isn’t protecting against the exploits itself and isn’t particularly useful when used on an otherwise highly vulnerable device. --- ## Post 24 by @TheRipper — 2025-10-31T22:49:19Z On Android, it works differently. EDS is an additional layer of protection, but only for data sets, not for the entire operating system. Now, when it comes to Windows or Linux, we can talk about full encryption or encryption only for data sets. Let’s assume that a Windows 11 system is fully encrypted with VeraCrypt, the chosen encryption is strong, and the password is also strong (numbers, letters, uppercase, lowercase, symbols) and is 32 characters long, for example. How could you possibly bypass this protection? You only have two options: 1. brute force 2. exploit against encryption software. Let’s be realistic, in most cases it all depends on the encryption and the password chosen. --- ## Post 25 by @JohnSmith — 2025-10-31T22:49:51Z How many times has cellebrites capabilities wrt gos been leaked now? Lol --- ## Post 26 by @lyricism — 2025-10-31T22:51:57Z > [@TheRipper](#): > > Let’s assume that a Windows 11 system is fully encrypted with VeraCrypt, the chosen encryption is strong, and the password is also strong (numbers, letters, uppercase, lowercase, symbols) and is 32 characters long, for example. How could you possibly bypass this protection? You only have two options: 1. brute force 2. exploit against encryption software. Easy: If you are entirely relying on the encryption because you are under the false belief it makes your device impenetrable, and you thus neglect the rest of the device’s security, I could simply remove the disk, overwrite the device’s bootloader with a bootkit, put the disk back, and wait for you to unlock your encrypted OS or data partition. --- ## Post 27 by @TheRipper — 2025-10-31T22:55:59Z It doesn’t work like that. Try VeraCrypt sometime to see how it works. You can do whatever you want with the boot manager, but you will never be able to access the operating system or its data. --- ## Post 28 by @lyricism — 2025-10-31T23:01:31Z I don’t know what else to tell you other than it absolutely does work like that if you don’t have further boot protections in place like Secure Boot, which has nothing to do with the disk encryption inherently. I think you feel you have an understanding of this subject but I recommend you do a bit more reading because you’ve only scratched the surface if that’s your understanding of things. It seems you have an interest in the topic and I think you are doing yourself a disservice to assume you have all the answers already, so I do hope you heed that advice. Encryption will protect the confidentiality and integrity of your data at rest. That’s all. It does not make your OS more secure against exploits, and it certainly doesn’t make your device impenetrable. --- ## Post 29 by @TheRipper — 2025-10-31T23:15:02Z Of course, I don’t know everything, I only know a little about the encryption tools I mentioned. Right now, I don’t know of a method to bypass VeraCrypt’s protection, but a local attacker with a lot of time on their hands could try things, of course. Perhaps I went too far in saying that the device would be impenetrable. --- ## Post 30 by @any1 — 2025-11-01T11:07:38Z At this point they might as well just publicly release it every time instead of it always being leaked. --- ## Post 31 by @Drippy0370 — 2025-11-01T17:43:40Z If your smartphone is in BFU and you have a strong passphrase, then they need to bruteforce which will take like forever with a strong password. --- ## Post 32 by @hefefi1887 — 2025-11-01T18:08:36Z Teams has a feature that blocks screenshots > **[Microsoft Teams will soon block screen capture during meetings](https://www.bleepingcomputer.com/news/microsoft/microsoft-teams-will-soon-block-screen-capture-during-meetings/)** > > Microsoft is working on adding a new Teams feature that will prevent users from capturing screenshots of sensitive information shared during meetings. --- ## Post 33 by @WhinyHamletPayer — 2025-11-01T20:17:53Z > [@KevPham](#): > > So, Cellebrite can unlock GOS devices but only up to 2022 updates. Stock pixels are still quite vulnerable. This was known for quite some time back when their charts were first leaked. [https://discuss.privacyguides.net/t/updated-cellebrite-iphone-support-matrix-leak/](https://discuss.privacyguides.net/t/updated-cellebrite-iphone-support-matrix-leak/) --- ## Post 34 by @anonymous465 — 2025-11-02T01:11:06Z Can someone confirm that this was legitimate? I do not know who rogueFed is. What are the epistemic standards for leaks like this, or in general? I am not familiar with the discourse. --- ## Post 35 by @Pedja — 2025-11-02T23:54:36Z Took a pic of his monitor instead of taking a screenshot. Definitely a fed. --- ## Post 36 by @Labfox — 2025-11-03T00:22:42Z Leaking on a work device would be a bad idea though