This post is needed to debunk misinformation from a charlatan (@hackerfantastic) masquerading as being a legitimate security researcher. They used to be quite successful at duping people into believing they were legitimate by taking credit for other people's work and fabricating vulnerabilities, which hasn't held up for them in the long term. They have historical follows from actual researchers from before their credibility disintegrated which is part of why people still fall for it. They are not a legitimate researcher and many of their past claims of exploits including phony systemd exploits have been debunked. Lennart Poettering is one of several people to debunk their made up vulnerabilities and had their replies hidden along with being blocked, which is the same approach they just took with us (see the hidden posts at x.com/hackerfantasti… for an example). The many unsubstantiated claims they make should not be believed. We can't reply at all within those threads anymore due to the new way blocking works so we're replying here instead.

Their main attempt at attacking us is making the ridiculous and downright desperate false claim that somehow the only purpose of GrapheneOS is using OpenBSD heap allocators, which it hasn't even used since before we made hardened_malloc in 2018:

x.com/hackerfantasti…
x.com/hackerfantasti…
x.com/hackerfantasti…

Our hardened_malloc project is an important sub-project protecting very well against the majority of remote code execution exploits in the userspace part of the OS. However, it's a tiny portion of our overall work and only one of many major privacy and security features we provide. Even if we did still use OpenBSD malloc for 32-bit apps on older devices still supporting them, that wouldn't be a significant part of the project at all.

They're promoting that people use a highly insecure device without the most basic hardware, firmware and software security features where data can be trivially extracted from the device without even using exploits and where far more vulnerabilities are exposed with negligible protection against them being exploited:

x.com/hackerfantasti…

GrapheneOS is a Linux distribution based on the Android Open Source Project (AOSP). Compared to a traditional desktop Linux distribution, AOSP is already very hardened and provides dramatically better privacy and security. It's a night and day difference. Traditional desktop Linux distributions struggle to deploy exploit protections from the early 2000s and lack proper app sandboxing. They lack systemic privacy and security work throughout the OS as a whole. They're really a bunch of largely anti-security projects glued together into a frankenstein OS with the development direction set by these individual projects, not the distributions. They ship what's provided to them, and the result is not a particularly secure OS. iOS and AOSP are far more secure than these operating systems. A bunch of companies having badly maintained forks of AOSP does not reflect on AOSP itself, but even those are far more secure than traditional desktop operating systems if they're doing the bare minimum of providing security patch backports.

Android Open Source Project without our improvements is far more secure than desktop Linux distributions. It already has a far more hardened kernel with a huge amount of attack surface reduction via the kernel configuration, very advanced use SELinux and to a lesser extent seccomp-bpf. The differences in userspace are far more dramatic. It has a well designed mandatory app sandbox and sandboxing heavily used throughout the OS. It has strict full system SELinux MAC/MLS policies which the OS is developed around rather than being added on afterwards. The majority of new code is being written in memory safe languages (Rust, Java, Kotlin). It was always focused on memory safety, sandboxing, etc. from the start. Privacy and security are a major focus throughout it and many design compromises are made for them rather than being an afterthought. Backwards incompatible privacy and security changes are made to the app sandbox on a yearly basis.

Our features compared to the latest release of the standard Android Open Source Project are documented at grapheneos.org/features. This page only covers our improvements and does not cover the standard AOSP privacy and security features. The subset of our features which have been landed upstream by us such as FORTIFY_SOURCE for the Linux kernel string library have been removed from our features page.

Our hardened_malloc project provides great protection against heap corruption vulnerabilities in userspace but that's just one small part of the overall GrapheneOS project. Prior to making our hardened_malloc project in 2018, we used our own fork of OpenBSD malloc ported to Linux and extended with significant additional security features. This had to be replaced as a whole to provide substantially better security against heap vulnerabilities.

This charlatan (@hackerfantastic) is spreading misinformation about GrapheneOS because they had a business deal with Copperhead after the failed takeover attempt on GrapheneOS. They were trying to sell devices with their insecure, closed source fork of legacy GrapheneOS versions. They hold a grudge against us based on their business venture failing and are trying their best to spread misinformation about it. Unfortunately for them, they don't have the faintest clue about what we work on and what we provide in current generation GrapheneOS. They responded to us responding with polite, accurate information by hiding our posts, blocking us and doubling down on blatant misinformation which we already pointed out.

If you want to go down a deep rabbit hole, look into how the company they co-founded, Hacker House, got money through government corruption. If they keep going down the road of supporting harassment content targeting our team, we can make a post about this. Pinephone Pro is closed source hardware with closed source firmware. The components it uses have incredibly poor security. It lacks very basic privacy and security features from hardware through software. It's not open hardware, it's just false marketing.

https://x.com/hackerfantastic/status/1888241083882086890

Revolut is specifically banning GrapheneOS by checking for the build machine hostname and username being set to grapheneos. We've changed these to build-host and build-user. Combined with another change, this allow our users to log in to it again until they roll out Play Integrity API enforcement.

There's no legitimate excuse for banning using a much more private and secure operating system while permitting devices with no security patches for a decade. Meanwhile, Revolut's shoddily made app tells users they're banning GrapheneOS because they're "serious about keeping your data secure".

Revolut's app will stop working against once they start enforcing having a Play Integrity API result showing it's a Google certified device. This is not a security feature but rather anti-competitive behavior from Google deployed by apps like Revolut wanting to pretend they care about security.

Revolut uses a bunch of shady closed source third party libraries in their app and it's one of these libraries banning GrapheneOS. These libraries are a major security risk and put user data at risk of being compromised. Revolut is not taking user security seriously at all and is cutting corners. There's no legitimate reason for any app to ban GrapheneOS users. It has the full standard security model and massive security improvements. There's no logic in banning GrapheneOS. It makes no sense for them to ban anything when they permit a device with no patches for 10 years. It's performative.

GrapheneOS fully supports standard Android hardware attestation for verifying the hardware, firmware and operating system along with the app that's using it. See grapheneos.org/articles/attes…. If apps insist on checking device integrity, that's the only way they should do it.

Play Integrity API checks that Google's monopolies are supported through devices licensing Google Mobile Services and integrating their browser, search engine, advertising, etc. It's anti-competitive and clearly illegal. Multiple governments are taking regulatory action and are in contact with us.

@weare_unplugged @fndr76 Unplugged's hardware, firmware and software is highly insecure relative to an iPhone or Pixel and doesn't meet our basic security requirements:



Unplugged are making incredibly false claims about how what they provide compares to GrapheneOS on a Pixel.grapheneos.org/faq#future-dev… @weare_unplugged @fndr76 An iPhone is legitimately a far better option for privacy and security than an Unplugged device. Unplugged has been repeatedly attacking GrapheneOS unprovoked with false claims about it along with false claims about iPhones and Pixels. That's their approach to marketing.

Android 15 QPR2 is moving 6th/7th/8th generation Pixels to the Linux kernel's 6.1 LTS branch already used for 9th generation Pixels. This will reduce the kernel branches we need to support down to 6.1 and 6.6. There will likely need to be a yearly migration for all the devices. Linux kernel increased official support time for the Long Term Support (LTS) branches from 2 years to 6 years, mainly for Android devices using Generic Kernel Image (GKI) releases. However, it was recently reduced back to 2 years. Pixels will need to start migrating every year.

IMEI is not the only hardware identifier for the device available to the cellular network. Changing the IMEi alone isn't enough to hide the device identity from the network. It will only hide one commonly used ID rather than making the device not uniquely identifiable. Carriers often detect device model via IMEI and multiple other ways as part of their standard operating procedure. They change how things work based on the detected capabilities but also hard-wired quirks for device models, etc. Devices send a lot of info on capabilities.

@LysolPionex @Authy Sandboxed Google Play compatibility layer does not require using a work profile, user profile or Private Space for the apps to be sandboxed. They're sandboxed if you use them in your main Owner profile too. Putting it in a separate profile just keeps it a bit more separate. @LysolPionex @Authy SafetyNet Attestation API was deprecated a while ago and is nearly entirely phased out. It was replaced by the Play Integrity API. Both of these things work fine with sandboxed Google Play. The issue is they largely exist to support services banning any non-Google-ceritifed OS.

There's a highly inaccurate article about Pixels from Cybernews making the rounds everywhere in privacy communities. It gets the details nearly completely wrong and thoroughly misrepresents things like the optional network-based location used nearly everywhere as Pixel specific. Any non-Pixel device with the standard Google Play integration has similar Google service integration doing the same things. You don't avoid it at all by using a non-Pixel, but you do end up with a device that's far less secure and adds OEM services with their own privacy issues.

September 2024 Android Security Bulletin includes a patch for the wipe bypass we reported: CVE-2024-32896. It's actively exploited by forensic companies across devices. Pixels patched it in June 2024...

September ASB:
June PUB: source.android.com/docs/security/…
source.android.com/docs/security/… We reported several vulnerabilities exploited by forensic companies in January 2024. We proposed implementing firmware reset attack mitigation and wipe-without-reboot. Pixels shipped reset attack mitigation in April 2024 and also a firmware mitigation making wipe bypasses harder.

This is a fake story. Turns out that getting security information from the CISO of a mass surveillance company trying to build a dystopian police state providing police with "predictive policing" software largely based on racial stereotypes is a bad move.

https://x.com/cryps1s/status/1824077327577591827

Trail of Bits iVerify EDR product runs in the standard app sandbox on iOS and Android. It can hardly do anything beyond static scanning of APKs. It's a crippled antivirus app marketed as detecting sophisticated attackers. It's a scam and Trail of Bits has lost all credibility.

Wired was manipulated into spreading misinformation to market Palantir and iVerify by misrepresenting a vulnerability in a disabled demo app as being a serious problem which could be exploited in the real world. They should retract the article but won't.

wired.com/story/google-a… iVerify are scammers and anyone paying them money should rapidly stop doing it and remove their malware from their devices. The real security risk is giving remote code execution on your devices to one of these sketchy EDR companies lying about their capabilities and discoveries.

Here's the Cellebrite Premium 7.69.5 iOS Support Matrix from July 2024.

404media recently published an article based on the same April 2024 docs we received in April and published in May. Many tech news sites including 9to5Mac made incorrect assumptions treating that as current.



Here's the Cellebrite Premium 7.69.5 Android Support Matrix from July 2024 for Pixels. They're still unable to exploit locked GrapheneOS devices unless they're missing patches from 2022. A locked GrapheneOS device also automatically gets back to BFU from AFU after 18h by default.

@Parallel_Comms @utdream CalyxOS rolls back security a fair bit and doesn't provide comparable privacy or security features to GrapheneOS. It is not a hardened OS but rather somewhat anti-hardened. Their focus is marketing and bundling party apps and services, often with problematic privileged access. @Parallel_Comms @utdream CalyxOS lags a bit behind on updates and misleads users about the security patches and privacy/security they offer. All their release notes have inaccurate claims about it, and they copied setting an inaccurate security patch level from LineageOS among other problems from there.

Unplugged are a recent entry in the crowded space of selling insecure hardware with significantly worse privacy and security than an iPhone as highly private and secure. Bottom of the barrel MediaTek device with outdated AOSP is worse than status quo. All marketing, no substance. As part of marketing their products, Unplugged are spreading unsubstantiated spin and misinformation about GrapheneOS and the much more secure hardware we target. We've been aware of it for a while but chose not to respond to it until they began doing it in direct response to us.

@davidbombal This video has major inaccuracies. CalyxOS always uses multiple Google services and gives them extensive privileged access within the OS. CalyxOS has far more limited app compatibility than GrapheneOS, and their approach to compatibility comes a high security and privacy cost. @davidbombal GrapheneOS provides far broader app compatibility via our sandboxed Google Play compatibility layer. It also has a much easier installation process. It's completely backwards to say that GrapheneOS is harder to adopt. What's the basis for making those statements about GrapheneOS?

XRY and Cellebrite say they can do consent-based full filesystem extraction with iOS, Android and GrapheneOS. It means they can extract data from the device once the user provides the lock method, which should always be expected. They unlock, enable developer options and use ADB. Cellebrite's list of capabilities provided to customers in April 2024 shows they can successfully exploit every non-GrapheneOS Android device brand both BFU and AFU, but not GrapheneOS if patch level is past late 2022. It shows only Pixels stop brute force via the secure element.

April release of the Pixel boot chain firmware includes fixes for 2 vulnerabilities reported by GrapheneOS which are being actively exploited in the wild by forensic companies:




These are assigned CVE-2024-29745 and CVE-2024-29748.source.android.com/docs/security/…
source.android.com/docs/security/… CVE-2024-29745 refers to a vulnerability in the fastboot firmware used to support unlocking/flashing/locking. Forensic companies are rebooting devices in After First Unlock state into fastboot mode on Pixels and other devices to exploit vulnerabilities there and then dump memory.

We've added documentation for the hardware memory tagging implementation in hardened_malloc:



GrapheneOS on Pixel 8 / Pixel 8 Pro is the first platform using ARM MTE in production. Stock Pixel OS has it as a hidden development option requiring using ADB.github.com/GrapheneOS/har… GrapheneOS uses hardened_malloc as the system allocator and enables memory tagging by default. MTE is enabled for all base OS apps and nearly all executables. It's only temporarily disabled for surfaceflinger (due to upstream bug in Android 14 QPR1) and a few vendor executables.

Earlier this month, unknown attackers targeted our website servers by spamming requests in an attempt to overload the servers and prevent users from accessing out website. We provided detailed information on what was happening and how we responded to it.

https://twitter.com/GrapheneOS/status/1623604628993589248

We made it clear we don't know the specific group behind that specific DDoS attack. In response to , we explained it's not a sophisticated attack and very likely originates from groups who openly engage in other forms of underhanded attacks on GrapheneOS.

https://twitter.com/kitfunfel/status/1623632234971545600

Our website was targeted with a Distributed Denial of Service attack using HTTP/2 multiplexing within the 2 minute window from 2023-02-09T00:58:00Z to 2023-02-09T01:00:00Z. OVH detected it and enabled mitigation but enough went through to cause downtime due to memory limits. In September, a similar attack caused nginx's master process to be killed by the out-of-memory killer causing much longer downtime. Default systemd service lacked auto-restart since master process supervises workers. We fixed that:

github.com/GrapheneOS/inf…
github.com/GrapheneOS/inf…

Uptime monitoring dashboard for the production GrapheneOS services is available at nodeping.com/reports/status…. Alerts are also posted publicly in our #infra:grapheneos.org Matrix room when a check is added, starts failing or stops failing. It's often not really an outage. For example, today, the TLS checks for attestation.app detected the certificate would expire in less than 15 days. This ended up being because the removal of a legacy subdomain several weeks ago broke automatic certbot removal. It can do much more advanced checks though.

Google publishes the source code for their TalkBack screen reader. GrapheneOS maintains a fork of it and includes it in GrapheneOS with the help of a blind GrapheneOS user who works on their own more elaborate fork. Eventually, we'd like to include more or all of their changes. TalkBack depends on a text-to-speech (TTS) implementation installed/configured/activated. It needs to have Direct Boot support to function before the first unlock of a profile. Google's TTS implementation supports this and can be used on GrapheneOS, but it's not open source.