Odd - I was able to read the full article before the paywall stuff showed up. Thanks for posting the archive link.
It would be nice that Samsung put some effort in combating these forensic tools…their Autoblocker doesn’t seem to be enough.
Full docs:
iPhone: Graykey-iPhone.xlsx - Google Sheets
Iphone (Backup): https://files.catbox.moe/pal7dn.xlsx
Android: Graykey-Android.xlsx - Google Sheets
Android (Backup): https://files.catbox.moe/fsinh5.xlsx
I guess this is without Graphene OS ?
The GrapheneOS team seems to have a pretty good idea of what vulnerabilities GrayKey was using and why their capabilities were significantly degraded in April 2024. They have a good thread on it here.
Thank you. Interesting they are still planning more feature against physical attacks.
It’s important they keep moving the bar while they are ahead, especially given they are such a small team. Truly impressive work!
https://nitter.poast.org/GrapheneOS/status/1858906957647630424#m
It seems GrapheneOS is affected, unless I misunderstood the tweet
Feels like a bit of a mixed bag…
The change in April 2024 indicates our reset attack mitigation proposal didn’t only block XRY but also Graykey too
GrapheneOS is much different from the stock Pixel OS due to the additional exploit protections such as the hardware-level USB-C port control and hardware memory tagging so it doesn’t really mean much without them having a specific section on GrapheneOS as Cellebrite docs do.
Does using the “charging-only” option mitigate these threats on GOS?
From this thread at the time of the vulnerabilities’ discovery by the GrapheneOS team, they wrote:
So at least when these vulnerabilities were being exploited and GrayKey had ‘full’ extraction capabilities, GrapheneOS is implied to have been unaffected.
In the best-case scenario (for GrayKey), their capabilities on GrapheneOS are the same as on stock. It’s likely GrapheneOS fares better, but such a claim would be pure speculation on my part.
I don’t think those protections really apply in this situation. As far as I understand, USB is always enabled when in fastboot mode. The solution to the original vulnerability here was to zero memory before enabling USB in fastboot mode. As for how they are currently achieving Partial AFU on stock Pixel devices, we really have no idea.
All that being said, it’s obviously well understood that GrapheneOS is far and away the best OS for mobile security and privacy, and they do extensive hardening and attack service reduction, which is documented here.