The short answer
On a Google Pixel operating as intended — bootloader locked, verified boot enabled, no root access — the IMEI cannot be changed. That holds for the stock Android build, for GrapheneOS, and for any other operating system: none of them has a write path to the data the modem draws its identifier from.
The operating system is not the deciding factor here at all. The IMEI belongs to the modem, not to Android. The modem is a separate processor with its own firmware, its own memory, and its own integrity checking. Replacing the operating system changes neither the contents of that memory nor the rules by which the modem validates it.
Precision matters here, so we state it plainly: what makes the IMEI immutable on a Pixel is not a one-time-programmable hardware cell, but an integrity check inside signed modem firmware, backed by verified boot. The difference between those two mechanisms is substantial, and we explain below why it matters.
The hardware involved
Every Pixel built on the Google Tensor platform — Pixel 6 through Pixel 10 inclusive — uses a Samsung Shannon-family cellular modem. The Pixel 9 and Pixel 10 series both run the Exynos 5400: although Google moved fabrication of the Tensor G5 itself to TSMC, the radio was carried over unchanged.
The modem is a distinct compute block. GrapheneOS describes it as an isolated component: memory access is partitioned by the IOMMU and confined to internal memory plus the regions the driver explicitly shares with it. Depending on the generation, Wi-Fi, Bluetooth and satellite navigation are implemented either inside that same modem in separate sandboxes or on dedicated chips.
The practical consequence is straightforward. Everything cellular — network registration, authentication, the signalling exchanges in which the IMEI is transmitted — happens inside the modem. Android only ever sees the result.
Where the IMEI actually lives on a Pixel
The publicly documented storage layout on Tensor devices works as follows.
The devinfo partition. A small partition of 8192 bytes with no filesystem on it. It holds a header and two tag regions. The PS tag region carries string values written once at the factory: serial numbers, MAC addresses, and the imei1 and imei2 tags. On Tensor devices devinfo is the source of truth — unlike Qualcomm platforms, where EFS holds that role.
Modem non-volatile memory (EFS). The IMEI values are mirrored into the modem NV items, specifically CAL.Common.Imei and CAL.Common.Imei_2nd. This is the working copy the radio operates against.
The cpsha check value. In the persist partition, at /mnt/vendor/persist/modem/cpsha, a SHA-256 checksum is stored in text form. The modem firmware computes it from the IMEI values. This is the load-bearing element of the whole protection scheme.
The validation logic runs like this. At startup, the modem compares the IMEI held in devinfo against the cpsha checksum. On a mismatch, the modem makes no attempt to repair the situation and will not operate with the substituted number: it reports 000000000000000 both on screen under *#06# and to the network. The device simply loses cellular service.
Three layers hold the IMEI in place
Layer one: the industry standards requirement
The current edition of 3GPP TS 22.016 states the requirement without qualification. The IMEI shall be unique and shall not be changed after the final production process of the mobile equipment, and it shall resist tampering — that is, manipulation and change — by any means, including physical, electrical and software.
GSMA TS.06 restates that requirement and layers its own IMEI Security Technical Design Principles on top, noting specifically that the 3GPP standards require IMEIs to be non-reprogrammable but say nothing about how a manufacturer is supposed to achieve that.
This point is worth dwelling on. The standard specifies an outcome, not a mechanism. Every manufacturer picks its own implementation, which is precisely why the strength of the protection varies from platform to platform.
Layer two: the integrity check inside the modem firmware
This is Google’s own implementation. The modem firmware is signed and loads under verified boot. It computes a SHA-256 checksum using an algorithm and key material that never leave the firmware itself, and validates the contents of devinfo against it.
Attempts to reproduce that algorithm externally have not succeeded. Even if one did, there is no guarantee Google would keep using the same key material in subsequent firmware releases.
Layer three: verified boot and a locked bootloader
Neither partition in the scheme is reachable for writing during normal operation. Writing to devinfo requires direct block device access; writing to /mnt/vendor/persist requires superuser privileges. No ordinary app, no system app short of special privileges, and no part of the operating system in its normal state has either.
On a Pixel, obtaining root access requires unlocking the bootloader. An unlocked bootloader disables verified boot — the very mechanism everything else rests on: hardware key attestation, StrongBox backed by Titan M2, rollback protection. GrapheneOS classifies a device with an unlocked bootloader as an incomplete installation and provides no support for one in that state.
This is not a hardware fuse, and the distinction matters
There is a widespread belief that the IMEI in modern smartphones is burned into a one-time-programmable cell, an eFuse. For Pixel devices, no public source supports this. These platforms genuinely do use hardware fuses — for rollback protection counters, for recording bootloader state, for storing root-of-trust key fingerprints. But the documented IMEI protection mechanism is of a different kind: a cryptographic binding, computed and verified in software.
The distinction is not academic. A one-time-programmable cell physically cannot be rewritten, so there is nothing to circumvent. A firmware check is hard to circumvent but not impossible in principle, provided one can persuade the firmware itself to recompute the checksum over new values. That is exactly what was done.
We prefer to state this openly rather than repeat the convenient but inaccurate claim of physical impossibility. Anyone making decisions about their own threat model deserves an accurate picture.
What is known about circumvention, and what it costs
Researchers in the community documented a procedure that, on some Pixel generations, allowed an arbitrary IMEI to be written such that the modem accepted it and reported it to the network. The approach was to modify the imei1 and imei2 tags in devinfo, boot the device into factory mode, and issue the service AT command AT+GOOGGETIMEISHA to the modem, forcing the firmware to recompute the checksum over the new values. The result was then written into the cpsha file.
Where that avenue stands today:
It never worked without root access. Every known implementation lists root as a hard prerequisite. That means an unlocked bootloader and verified boot disabled.
Google has been closing the path steadily. The AT+GOOGGETIMEISHA command has been removed from the radio image. The author of the most widely circulated script dropped maintenance, noting that it stopped working with the release of Android 16 QPR1. Community members reported failed attempts on Android 14, 15 and 16 throughout the first half of 2026.
The procedure does not apply to the Pixel 10 series. Researchers warn against attempting it outright: the outcome is an unusable device.
The checksum algorithm has never been reproduced. Without that, any circumvention depends on the service command still being present in a given firmware build, rather than on any understanding of the scheme itself.
Now the cost. People buy a Pixel with GrapheneOS for a specific set of properties: verified boot from a root of trust on every startup, hardware attestation, secure-element-enforced throttling of passphrase guessing, resistance to forensic extraction tooling. Every one of those properties is downstream of a locked bootloader. Unlocking it in order to change the IMEI trades the entire set for one altered identifier — and, as shown below, the benefit of that alteration does not exist in the first place.
We do not recommend this modification.
Software IMEI spoofing: what it actually does
Separately, there is a category of apps marketed as IMEI changers: Xposed and LSPosed modules such as IMEI Masker, Android Faker and SpoofMyDevice.
How they work has nothing to do with the modem. LSPosed is a hooking framework operating inside the ART runtime. The module substitutes the value returned by TelephonyManager methods, and it does so only for apps the user has ticked in the module configuration beforehand. A new app installed afterwards receives the real value until it is added to that list by hand.
What remains untouched:
- The *#06# code displays the real IMEI, because that value comes from the modem rather than from Android.
- The network receives the real IMEI, because the modem transmits it during signalling procedures without consulting Android at all.
- Root access remains mandatory, with every consequence described above.
In other words, the tool changes the answer the operating system gives to selected apps, and changes nothing whatsoever that the carrier — or anyone with access to network infrastructure — observes.
A problem that has not existed since Android 10
The decisive question to put to any operating-system-level IMEI spoofing tool is which problem it actually solves.
As of Android 10, third-party apps are cut off from non-resettable hardware identifiers entirely. The IMEI, MEID, serial number, SIM serial number and subscriber ID are all gated behind READ_PRIVILEGED_PHONE_STATE. That permission is granted only to apps signed with the platform key and to privileged system components. Apps distributed through Google Play cannot declare it.
An app targeting Android 10 or later that attempts to read the IMEI receives a SecurityException. Legacy apps receive an empty value or placeholder data. The only exception is the currently active SMS and MMS app.
GrapheneOS inherits that restriction in full and additionally removes the legacy access path to the serial number.
The scenario of an app tracking you via your IMEI therefore does not occur on a current Pixel, regardless of whether any spoofing module is installed. We have not been able to identify a single practical task that software IMEI spoofing accomplishes on a device running Android 10 or later. The costs, by contrast, are entirely real: root, an unlocked bootloader, and the loss of verified boot.
Even a genuine IMEI change does not hide the device from the network
Suppose for a moment that the IMEI really were changed at the modem level. That still buys no anonymity on a cellular network.
GrapheneOS puts it concisely: the IMEI is not the only hardware identifier available to the cellular network, and changing the IMEI alone conceals one commonly used identifier rather than making the device unidentifiable.
What the network still has:
The device capability profile. During registration, the device hands the network a detailed inventory of its own radio capabilities — supported bands, carrier aggregation combinations, throughput categories, security algorithms, the set of supported services. Cellular security researchers have shown that this exchange takes place before authentication, without integrity protection and without verification by the network, and that it is sufficient to determine the device model.
The radio frequency fingerprint. Physical characteristics of the transmitter — residual frequency offset, amplifier non-linearities, transient behaviour — are unique to each individual unit of hardware and lend themselves to classification. Published work on RF fingerprint identification from the PRACH preamble reports classification accuracy of roughly 92 percent for 5G handsets at a signal-to-noise ratio of 25 dB. No software-written identifier has any bearing on this.
Subscriber identifiers. The IMSI, or SUPI, is tied to the SIM rather than to the handset. A constant IMEI paired with rotating SIMs, and a constant SIM paired with a changing IMEI, both produce an equally conspicuous correlation.
There is a further factor: rarity. Unusual behaviour is itself an identifying trait. GrapheneOS has noted specifically of identifier-rotating configurations that they make a user stand out sharply against the wider subscriber population precisely because so few people run them, which makes tracking easier rather than harder.
The GrapheneOS position
The official GrapheneOS documentation puts it in a single sentence: it is not possible to change the IMEI on a production device, and GrapheneOS cannot add support for doing so because the hardware does not support it.
That answer describes a device in the state GrapheneOS is designed to run in: bootloader locked, verified boot active. That is exactly the state in which we hand devices to customers.
Conclusion
The IMEI on a Google Pixel belongs to the modem, not to the operating system. Three things hold it in place: the requirements set out by 3GPP and the GSMA, a SHA-256 integrity check inside signed modem firmware, and verified boot with a locked bootloader.
It is not a hardware fuse. Circumvention did technically exist on some generations, required root access, has been closed off progressively by the manufacturer, and does not apply to the Pixel 10. The price of that circumvention is the wholesale forfeit of the security properties that make a Pixel with GrapheneOS worth buying in the first place.
Software IMEI spoofing tools operate at an entirely different layer. They change what Android reports to selected apps and change nothing that reaches the network. Meanwhile, third-party apps have had no access to the IMEI at all since Android 10, so the problem these tools purport to solve does not exist on a current device.
If the objective is to avoid being tracked through the cellular network, the IMEI is the wrong place to apply effort. Airplane mode fully disables cellular transmit and receive while leaving Wi-Fi available, and it is the only way to take the device out of the network’s reach.
Pixel 8, Pixel 9 and Pixel 10 with GrapheneOS. We match the model to your threat model, install GrapheneOS, lock the bootloader, and hand over the device with a complete operating handbook. GrapheneOS details →
Related: Pixel with GrapheneOS · IMEI obfuscation on the GL.iNet Mudi.
Sources
Standards
- 3GPP TS 22.016, “International Mobile station Equipment Identities (IMEI)”, V19.0.0 (2025-10), clause 2. — 3gpp.org
- GSMA TS.06, “IMEI Allocation and Approval Process”, V27.0 (6 January 2025), section 7, “IMEI Security and Integrity Guidelines”. — imeidb.gsma.com
GrapheneOS documentation
- GrapheneOS, Usage guide, “Carrier functionality” — the statement that the IMEI cannot be changed on a production device. — grapheneos.org
- GrapheneOS, FAQ, “Can apps access hardware identifiers?” — grapheneos.org
- GrapheneOS, FAQ, “Is the baseband isolated?” — grapheneos.org
- GrapheneOS, FAQ, “What does GrapheneOS do about cellular tracking, interception and silent SMS?” — grapheneos.org
- GrapheneOS, FAQ, on an unlocked bootloader constituting an incomplete installation. — grapheneos.org
- GrapheneOS, post of 17 October 2024 on why changing the IMEI alone is insufficient. — grapheneos.social
Android identifier access restrictions
- Android Developers, “Privacy changes in Android 10”, section on non-resettable identifiers. — developer.android.com
- Android Open Source Project, “Device identifiers”. — source.android.com
IMEI storage mechanism on Tensor devices
- lexipwn — tooling and technical description of the devinfo partition layout, the cpsha mechanism and the AT+GOOGGETIMEISHA command. — codeberg.org
- Privacy Guides Community, “Pixel (Tensor chip) IMEI modification guide” thread, including reports of the removal of AT+GOOGGETIMEISHA from the radio image and of the procedure failing on the Pixel 10. — discuss.privacyguides.net
- Pixel IMEI restore scripts — an independent description of the same sequence of operations. — github.com
Hardware platform
- 9to5Google, on the use of the Exynos 5400 modem in the Tensor G5 and the Pixel 10 series. — 9to5google.com
Device identification beyond the IMEI
- Shaik et al., “Show Me Your Attach Request and I’ll Tell You Who You Are: Practical Fingerprinting Attacks in 4G and 5G Mobile Networks” — on device capability information being exchanged before authentication and without protection.
- “Radio Frequency Fingerprint Identification for 5G Mobile Devices Using DCTF and Deep Learning”, Sensors. — pmc.ncbi.nlm.nih.gov
Software identifier spoofing tooling
- LSPosed — an ART runtime hooking framework. — github.com
- LSPosed module repository: Android Faker, SpoofMyDevice, IMEI Masker. — modules.lsposed.org