My GrapheneOS was cracked by Belgian police

hemingway

mmobder The downside of the thread deletion is a opportunity to claim "GoS are afraid of the truth and wipes all accusations, so it's a proof of vulnerability!"

Thread deletion would raise an eyebrow as people would ask why it was necessary if GOS is confident in its security.

Locking the post with an explanation as to why the post is without merit would work if done correctly. But if it isn't a "nail in the coffin" level of explanation addressing absolutely every question a reader might want to pose, a locked thread could backfire. Much easier to leave it as is and let the post live or die on its own merit.

thmf

b8r2 Did you setup or check Auditor app at least once? I suspect you weren't using original GrapheneOS. As @Hathaway_Noa said, you either used Wasted app or some other security theatre, or you weren't using original GrapheneOS. Some kind of lazy fork maybe, with added "security features others don't have". Things you said confirm this multiple times.

b8r2

thmf I was using original GrapheneOS. The Auditor app was not relevant to the duress wipe issue I reported; the problem occurred at the system level, not because of Auditor or any third party app. I did not use Wasted or any forked/modified version of GrapheneOS everything was standard, official GrapheneOS as provided by the project. The issue was specifically that the native duress PIN was entered but the secure wipe did not execute.

b8r2

Hathaway_Noa The “USB duress” feature you’re describing is from that app not from GrapheneOS and I never used it. My mention of any USB‑related setting was in response to someone else’s assumption, not because I relied on Wasted or any of its features.

The only thing that was actually used was the native GrapheneOS duress PIN

Hathaway_Noa

b8r2

I have deleted graphene OS phones with native duress probably more than 100 times in different settings, this feature has been througly tested by the community as a whole and I even personally know people in the Netherlands who have used the feature successfully when their phones got confiscated.

These scenarios are valible in your case:

you didn't setup the native duress feature
you did setup the native feature but you didn't have the right password, or you wrongly installed a password but you didn't remember it right
your data (according to yourself) got cracked, they could've easily guessed your password since your opsec is shit, just look at your telegram channel. I think I could've doxxed you within a few hours.
cops can check for cameras and see what password or pincode you have used to get in the phone. Maybe you go the same gym, they go to the gym and check camera footage of you putting in the password or pincode.

A lot of scenarios are possible. Since you are a low IQ scammer with phising panels and spamming I don't have your opsec hopes high.

Byteang3l

b8r2 did the device still power off and just come back on after as if it was rebooted ? Or did it just stay on and act as if you didn't type duress? Is it possible you just accidentally typed your legitimate password in the heat of the moment due to panic? I'm just trying to work out a chain of probability here. Because let's say you typed the duress pin wrong but didn't type in the real password, phone stays locked in AFU mode, which is still reasonably secure, GrapheneOS is great about nuking data at rest, and if it rebooted due to a failure to wipe somehow, it'd be in BFU mode which is even more secure than AFU of course, it's the intricate details that really matter here, because it tells us exactly what could've happened here. I do know that even if duress fails to wipe weaver keys, it still forces a reboot that would put it in BFU mode, which mitigates cold boot and baseband exploits, and USB exploits if you configured those properly, which only leaves more extreme methods like laser fault injection which the titan m2 is very very secure against, and even if it failed to wipe due to that, it would take a very long time to extract secrets from the M2 using that method.

b8r2

Byteang3l the duress PIN was entered correctly, but the system failed to execute the wipe. It did not power off and reboot; it remained on. There was no accidental entry of the legitimate password.. the duress PIN was intentionally used. The issue was not caused by AFU vs BFU states, mis-entry, or user error; it was specifically that the native GrapheneOS duress wipe function failed to trigger as designed, which is why the data was later accessible.

thmf

b8r2 or any forked/modified version of GrapheneOS everything was standard, official GrapheneOS as provided by the project.

Well you don't know that, because only the built-in Auditor app can tell you you're using official GrapheneOS. Auditor is not a third party app.

thmf

b8r2 the only logical explanation on my side

Now we finally have it. You're guessing.

b8r2

thmf This is not a guess. I am describing exactly what happened as observed: the duress PIN was entered, the device remained powered on, and the secure wipe did not execute. That’s the factual sequence

Byteang3l

b8r2 Even if the duress PIN didn’t trigger, this doesn’t automatically mean the device was easily accessible. AFU mode still keeps encryption keys in memory, the bootloader was locked, and accessing raw data would require very sophisticated hardware attacks that are not standard for police, and not something the Belgian government has access to, and certainly not in the time span mentioned here. Without detailed logs or evidence, it’s hard to accept this as proof of a GrapheneOS compromise, it could be an unusual one in a million bug, or a one in a billion flaw with your specific titan chip, but it’s not a widespread vulnerability as it stands now. If you can provide evidence down the line, we absolutely implore you to share it here when it becomes available, if the admins wanted this thread gone it already would be, so it should be here in the future when that information becomes available.

b8r2

thmf the duress PIN failing to trigger a wipe is independent of the Auditor’s verification. The device was a standard, official GrapheneOS installation, and nothing about the Auditor or third-party apps caused the failure.

Novalissoide

b8r2 Have you enabled Adb and/or Shizuku?

b8r2

Hathaway_Noa I have deleted graphene OS phones with native duress probably more than 100 times in different settings, this feature has been througly tested by the community as a whole and I even personally know people in the Netherlands who have used the feature successfully when their phones got confiscated.

These scenarios are valible in your case:

you didn't setup the native duress feature
you did setup the native feature but you didn't have the right password, or you wrongly installed a password but you didn't remember it right
your data (according to yourself) got cracked, they could've easily guessed your password since your opsec is shit, just look at your telegram channel. I think I could've doxxed you within a few hours.
cops can check for cameras and see what password or pincode you have used to get in the phone. Maybe you go the same gym, they go to the gym and check camera footage of you putting in the password or pincode.

A lot of scenarios are possible. Since you are a low IQ scammer with phising panels and spamming I don't have your opsec hopes high.

You’re making a lot of claims based on assumptions, not on what actually happened. None of the scenarios you’re listing apply here, and throwing around insults doesn’t make your conclusions any more accurate. The duress PIN was set up, it was entered correctly, and the wipe did not run. That’s the entire point.

Speculating about “bad opsec,” guessing passwords, or imagining gym camera footage doesn’t change the factual sequence of events. You can disagree with my interpretation, but dismissing everything as user error while ignoring the details I’ve already given isn’t analysis it’s just projecting.

blissartt

b8r2
You truly don't get it.
Auditor has not caused the error, that's for sure. But Auditor would have been useful to check if your GrapheneOS was clear. You cannot just say "it's official GrapheneOS", only Auditor can prove that.

b8r2

Novalissoide Have you enabled Adb and/or Shizuku?

No ADB and Shizuku were not enabled on the device. The duress-wipe issue occurred on a standard, official GrapheneOS installation with default system settings. Nothing external like ADB or Shizuku contributed to the failure.

b8r2

Byteang3l Even if the duress PIN didn’t trigger, this doesn’t automatically mean the device was easily accessible. AFU mode still keeps encryption keys in memory, the bootloader was locked, and accessing raw data would require very sophisticated hardware attacks that are not standard for police, and not something the Belgian government has access to, and certainly not in the time span mentioned here. Without detailed logs or evidence, it’s hard to accept this as proof of a GrapheneOS compromise, it could be an unusual one in a million bug, or a one in a billion flaw with your specific titan chip, but it’s not a widespread vulnerability as it stands now. If you can provide evidence down the line, we absolutely implore you to share it here when it becomes available, if the admins wanted this thread gone it already would be, so it should be here in the future when that information becomes available.

I understand your point AFU mode, a locked bootloader, and standard encryption do make unauthorized access difficult under normal circumstances. The issue I’m reporting is specific to the native GrapheneOS duress PIN failing to trigger the wipe. I’m not claiming a widespread vulnerability, only that in this case, the duress action did not execute as designed, and the data became accessible afterward.

I have shared all the factual details I can at this time. If additional evidence becomes available later, it will be provided. Until then, this post reflects exactly what happened on this device, without speculation about broader hardware capabilities or general security of GrapheneOS.

hemingway

b8r2

FYI I was responding to someone else saying there was a contradiction there.

What was the reaction from the employee(?) after they entered the duress pin?

b8r2

hemingway FYI I was responding to someone else saying there was a contradiction there.

What was the reaction from the employee(?) after they entered the duress pin?

After the duress PIN was entered, the device remained powered on and no wipe occurred. From a technical standpoint, nothing happened on the device itself to indicate success it didn’t power off, reboot, or otherwise respond. Any reactions from those feds or others present are irrelevant to the sequence of events; the key point is that the native duress wipe failed to execute.

Novalissoide

b8r2 whether or not they contributed, were they ever used on the device?

Novalissoide

b8r2 standard, official GrapheneOS installation with default system settings

Then explain the mentioned Usb-wipe?

b8r2

Novalissoide neither ADB nor Shizuku were ever used on the device. The issue occurred entirely on a standard, official GrapheneOS installation with default system settings.

n3t_admin

b8r2 okay, I call the bluff here: so after the "feds" entered the (maybe incorrect) duress PIN, they were like: oh, it's wrong, have a nice day Sir! They didn't ask for a different PIN, they didn't retry it, they didn't ask why it was wrong? So many questions...

hemingway

b8r2 After the duress PIN was entered, the device remained powered on and no wipe occurred

Did it say "incorrect pin entered" or did it unlock the device? That's why I'm wondering about the fed's reaction since you mentioned you could not see what happened after the pin was entered.

Byteang3l

b8r2 what surprises me is you allegedly have had a warrant for pre-meditated murder since the creation of this post according to your attorney, yet here you are readily talking to us on this forum. How do you manage that especially with an ankle monitor on?

b8r2

Novalissoide The USB-wipe mention was in response to an earlier comment, not something I used on the device. The device itself was running standard GrapheneOS, and the issue occurred solely with the native duress PIN, which failed to trigger the secure wipe.

« Previous Page Next Page »