Коротка відповідь
На Google Pixel, який працює у звичайному режимі — із заблокованим завантажувачем, увімкненим перевіреним завантаженням і без root-доступу, — IMEI змінити неможливо. Це стосується і заводської Android, і GrapheneOS, і будь-якої іншої операційної системи: жодна ОС не має шляху запису до тих даних, з яких модем бере свій ідентифікатор.
Операційна система тут узагалі не є вирішальним чинником. IMEI належить не Android, а модему — окремому процесору з власною мікропрограмою, власною памʼяттю та власним контролем цілісності. Заміна ОС на пристрої не змінює ані вміст цієї памʼяті, ані правила, за якими модем її перевіряє.
Незмінність IMEI на Pixel забезпечує перевірка цілісності всередині підписаної мікропрограми модему у поєднанні з перевіреним завантаженням, а не одноразово програмована апаратна комірка.
Яке обладнання тут задіяне
Усі Pixel на платформі Google Tensor — від Pixel 6 до Pixel 10 включно — використовують стільниковий модем Samsung сімейства Shannon (Exynos). Серії Pixel 9 та Pixel 10 працюють з модемом Exynos 5400: попри перехід виробництва самого процесора Tensor G5 на TSMC, радіочастину Google залишив без змін.
Модем є окремим обчислювальним блоком. GrapheneOS описує його як ізольований компонент: доступ до памʼяті розмежовано через IOMMU і обмежено внутрішньою памʼяттю та тими ділянками, які драйвер явно надає у спільне користування. Wi-Fi, Bluetooth і супутникова навігація на різних поколіннях реалізовані або всередині цього ж модему в окремих пісочницях, або на окремих мікросхемах.
Усе, що стосується стільникового звʼязку — реєстрація в мережі, автентифікація, передавання IMEI під час процедур сигналізації — відбувається всередині модему. Android бачить лише результат.
Де саме зберігається IMEI у Pixel
Публічно задокументована структура зберігання на Tensor-пристроях виглядає так.
Розділ devinfo. Невеликий розділ обсягом 8192 байти без файлової системи. Він містить заголовок і дві області тегів. У теговій області PS зберігаються рядкові значення, які заводом записуються один раз: серійні номери, MAC-адреси, а також теги imei1 та imei2. Для Tensor-пристроїв саме devinfo є джерелом істини — на відміну від платформ Qualcomm, де первинним є EFS.
Енергонезалежна памʼять модему (EFS). Значення IMEI дублюються у NV-елементах модему — зокрема CAL.Common.Imei та CAL.Common.Imei_2nd. Це робоча копія, з якою працює радіочастина.
Контрольне значення cpsha. У розділі persist, за шляхом /mnt/vendor/persist/modem/cpsha, у текстовому вигляді зберігається контрольна сума SHA-256, обчислена мікропрограмою модему на підставі значень IMEI.
Логіка перевірки така: під час запуску модем звіряє IMEI із розділу devinfo з контрольною сумою cpsha. Якщо значення не збігаються, модем не намагається «виправити» ситуацію і не працює зі зміненим номером — він повідомляє 000000000000000 і на екран за кодом *#06#, і в мережу. Пристрій просто втрачає стільниковий звʼязок.
Три рівні, що утримують IMEI незмінним
Рівень перший: вимога галузевих стандартів
Специфікація 3GPP TS 22.016 у чинній редакції формулює вимогу без застережень: IMEI має бути унікальним і не може змінюватися після завершення виробничого циклу обладнання; він має протистояти втручанню — маніпуляціям і зміні — будь-якими засобами, зокрема фізичними, електричними та програмними.
Документ GSMA TS.06 повторює цю вимогу і додає до неї власні технічні принципи безпеки IMEI, окремо зазначаючи, що стандарти 3GPP вимагають непрограмованості IMEI, але не описують, як саме виробник має цього досягти.
Стандарт задає результат, а не механізм. Кожен виробник обирає власну реалізацію, і саме тому стійкість захисту різниться від платформи до платформи.
Рівень другий: контроль цілісності всередині мікропрограми модему
Це власне реалізація Google. Мікропрограма модему підписана і завантажується під контролем перевіреного завантаження. Вона обчислює контрольну суму SHA-256 за алгоритмом і з ключовим матеріалом, які залишаються всередині самої мікропрограми, і звіряє з нею вміст devinfo.
Спроби відтворити цей алгоритм ззовні успіху не мали. Навіть у разі успіху немає жодних гарантій, що Google використовуватиме той самий ключовий матеріал у наступних версіях мікропрограми.
Рівень третій: перевірене завантаження і заблокований завантажувач
Обидва розділи, задіяні у схемі, недосяжні для запису у штатному режимі роботи. Запис до devinfo потребує прямого доступу до блокового пристрою, запис до /mnt/vendor/persist — прав суперкористувача. Ані звичайний застосунок, ані системний застосунок без спеціальних привілеїв, ані сама операційна система у нормальному режимі такого доступу не мають.
На Pixel отримання root-доступу вимагає розблокування завантажувача. Розблокований завантажувач вимикає перевірене завантаження — той самий механізм, на якому тримається довіра до всього іншого: до апаратної атестації ключів, до StrongBox на базі Titan M2, до захисту від відкоту версій. GrapheneOS прямо кваліфікує пристрій із розблокованим завантажувачем як незавершену інсталяцію і не надає підтримки в такому стані.
Програмний захист, а не eFuse
Поширене уявлення про те, що IMEI у сучасних смартфонах «пропалено» в одноразово програмовану комірку (eFuse), для Pixel не підтверджується жодним публічним джерелом. Апаратні запобіжники в цих платформах справді використовуються — для лічильників захисту від відкоту версій, для фіксації стану завантажувача, для зберігання відбитків ключів кореня довіри. Але задокументований механізм захисту IMEI має іншу природу: це криптографічна привʼязка, обчислена й перевірена програмно.
Одноразово програмована комірка фізично не піддається перезапису — обійти її неможливо в принципі. Перевірку в мікропрограмі обійти складно, але принципово можливо, якщо змусити саму мікропрограму перерахувати контрольну суму для нових значень. Саме це й було зроблено.
Ми вважаємо за правильне викласти це прямо, а не повторювати зручне, але неточне твердження про фізичну неможливість. Клієнт, який ухвалює рішення щодо власної моделі загроз, має спиратися на точну картину.
Що відомо про обхід і скільки він коштує
У спільноті дослідників задокументовано процедуру, яка на частині поколінь Pixel дозволяла записати довільний IMEI так, щоб модем прийняв його і повідомляв у мережу. Схема полягала у зміні тегів imei1 та imei2 у розділі devinfo, переведенні пристрою у заводський режим завантаження та надсиланні модему службової AT-команди AT+GOOGGETIMEISHA, яка змушувала мікропрограму перерахувати контрольну суму вже для нових значень. Отриманий результат записувався у файл cpsha.
Стан цього напряму на сьогодні виглядає так.
Процедура ніколи не працювала без root-доступу. Усі відомі реалізації прямо вказують root як обовʼязкову умову. Це означає розблокований завантажувач і вимкнене перевірене завантаження.
Google послідовно закриває цей шлях. Команду AT+GOOGGETIMEISHA вилучено з актуальних образів прошивки модему, а автор lexipwn, найпоширенішого інструмента, призупинив його розробку. Публічні повідомлення в хронологічному порядку:
- 13 грудня 2025 року: учасник форуму повідомляє, що команди в актуальних образах прошивки модему вже немає, і застерігає від спроб на Pixel 10, бо телефон може перестати вмикатися.
- 11 травня 2026 року: інший учасник повідомляє, що процедура не спрацьовувала на Android 14, 15 і 16, доки він не створив із root-доступом відсутній файл хешу cpsha; після цього вона спрацювала.
- 22 вересня 2026 року: третій учасник публікує метод для Pixel 10 Pro. З root-доступом запущений модем змушують завантажити дані зі старого образу прошивки модему Pixel 9, після чого модем перезапускають. Автор перевірив метод лише на Pixel 10 Pro.
Кожен із описаних методів потребує root-доступу. На Pixel із GrapheneOS і заблокованим завантажувачем жоден із них не запуститься.
Алгоритм обчислення контрольної суми не відтворено. Без цього обхід залишається залежним від наявності службової команди у конкретній версії мікропрограми, а не від розуміння самої схеми.
Pixel із GrapheneOS купують заради конкретного набору властивостей: перевірене завантаження з кореня довіри на кожному запуску, апаратна атестація, обмеження кількості спроб підбору пароля на рівні захищеного елемента, стійкість до інструментів вилучення даних. Кожна з цих властивостей є похідною від заблокованого завантажувача. Розблокування заради зміни IMEI обмінює весь цей набір на один змінений ідентифікатор — при тому, що самої вигоди від такої заміни, як показано нижче, не існує.
Ми не рекомендуємо таку модифікацію.
Програмна підміна IMEI: що вона робить насправді
Окремо існує клас застосунків, які позиціонують себе як засоби «зміни IMEI»: модулі для Xposed та LSPosed на кшталт IMEI Masker, Android Faker, SpoofMyDevice.
Механізм їхньої роботи не має нічого спільного з модемом. LSPosed є фреймворком перехоплення викликів у середовищі виконання ART. Модуль підміняє значення, яке повертають методи класу TelephonyManager — і лише для тих застосунків, які користувач заздалегідь позначив у налаштуваннях модуля. Новий застосунок, встановлений після цього, отримає справжнє значення, доки його не додано до переліку вручну.
Що залишається незмінним:
- Код *#06# показує справжній IMEI, бо це значення надходить від модему, а не від Android.
- Мережа отримує справжній IMEI, бо його передає модем під час процедур сигналізації, не звертаючись до Android узагалі.
- Root-доступ залишається обовʼязковим — з усіма наслідками, описаними вище.
Тобто інструмент змінює відповідь операційної системи окремим застосункам і не змінює нічого з того, що бачить оператор або будь-хто з доступом до мережевої інфраструктури.
З Android 10 застосунки не мають доступу до IMEI
Ключове питання до будь-якого засобу підміни IMEI на рівні ОС: яку саме проблему він розвʼязує?
Починаючи з Android 10, стороннім застосункам доступ до незмінних апаратних ідентифікаторів закрито повністю. IMEI, MEID, серійний номер, серійний номер SIM-картки та ідентифікатор абонента захищено дозволом READ_PRIVILEGED_PHONE_STATE. Цей дозвіл видається лише застосункам, підписаним платформним ключем, і привілейованим системним компонентам. Застосунки з Google Play оголосити його не можуть.
Застосунок, який призначений для Android 10 або новішої версії і намагається прочитати IMEI, отримує SecurityException. Застарілі застосунки отримують порожнє значення або заповнювач. Виняток становить лише поточний застосунок для SMS та MMS.
GrapheneOS успадковує це обмеження повністю і додатково прибирає застарілий шлях доступу до серійного номера.
Отже, сценарій «застосунок стежить за мною через IMEI» на сучасному Pixel не реалізується незалежно від наявності будь-яких модулів підміни. Ми не змогли визначити жодного практичного завдання, яке програмна підміна IMEI розвʼязує на пристрої з Android 10 або новішою версією. Витрати ж цілком реальні: root, розблокований завантажувач і втрата перевіреного завантаження.
Навіть справжня зміна IMEI не приховує пристрій у мережі
Припустимо на мить, що IMEI усе-таки змінено на рівні модему. Анонімності в стільниковій мережі це не дає.
Проєкт GrapheneOS формулює це стисло: IMEI не є єдиним апаратним ідентифікатором пристрою, доступним стільниковій мережі, і зміна самого лише IMEI приховує один поширений ідентифікатор, а не робить пристрій неідентифікованим.
Що залишається доступним для мережі:
Профіль можливостей пристрою. Під час реєстрації пристрій передає мережі докладний перелік власних радіотехнічних можливостей — підтримувані діапазони, комбінації агрегації несучих, категорії пропускної здатності, алгоритми безпеки, набір підтримуваних служб. Дослідники з галузі безпеки стільникових мереж показали, що цей обмін відбувається до автентифікації, без захисту цілісності та без перевірки з боку мережі, і що його достатньо для визначення моделі пристрою.
Радіочастотний відбиток. Фізичні характеристики передавача — залишкове зміщення частоти, нелінійності підсилювача, перехідні процеси — є унікальними для кожного примірника обладнання і піддаються класифікації. У публікаціях, присвячених ідентифікації за радіочастотним відбитком на підставі преамбули PRACH, для 5G-смартфонів наводиться точність класифікації близько 92 % за відношення сигнал/шум 25 дБ. Жоден програмно записаний ідентифікатор на це не впливає.
Ідентифікатори абонента. IMSI або SUPI привʼязані до SIM-картки, а не до апарата. Постійний IMEI із різними SIM-картками і постійна SIM-картка зі зміненим IMEI однаково утворюють помітну кореляцію.
Додатковий чинник — рідкісність. Нетипова поведінка сама собою є ідентифікаційною ознакою. GrapheneOS окремо зауважує щодо конфігурацій із ротацією ідентифікаторів, що вони різко виділяють користувача на тлі решти абонентів саме через свою нечисленність, і це полегшує відстеження.
Позиція проєкту GrapheneOS
Офіційна документація GrapheneOS формулює позицію в одному реченні: змінити IMEI на серійному пристрої неможливо, і GrapheneOS не може додати таку можливість, оскільки її не підтримує апаратна платформа.
Ця відповідь стосується пристрою у тому стані, в якому GrapheneOS призначена працювати: із заблокованим завантажувачем і перевіреним завантаженням. Саме в такому стані ми передаємо пристрої клієнтам.
Висновок
IMEI на Google Pixel належить модему, а не операційній системі. Його утримують три речі: вимога стандартів 3GPP і GSMA, перевірка цілісності SHA-256 всередині підписаної мікропрограми модему та перевірене завантаження із заблокованим завантажувачем.
Це не апаратний запобіжник. Обхід існує, потребує root-доступу і крок за кроком закривається виробником; метод для Pixel 10 Pro опубліковано 22 вересня 2026 року. Ціною такого обходу є повна відмова від тих властивостей безпеки, заради яких Pixel із GrapheneOS і купують.
Програмні засоби «підміни IMEI» працюють на іншому рівні — вони змінюють відповідь Android окремим застосункам і не змінюють нічого з того, що передається в мережу. При цьому з часів Android 10 сторонні застосунки взагалі не мають доступу до IMEI, тож проблеми, яку ці засоби нібито розвʼязують, на сучасному пристрої не існує.
Якщо завдання полягає у тому, щоб не бути відстеженим через стільникову мережу, IMEI — не той напрям, на якому варто зосереджувати зусилля. Режим польоту повністю вимикає приймання і передавання стільникової радіочастини, залишаючи Wi-Fi доступним, — і це єдиний спосіб виключити відстеження пристрою мережею.
Pixel 9 та Pixel 10 із GrapheneOS. Ми підбираємо модель під вашу модель загроз, встановлюємо GrapheneOS, блокуємо завантажувач і передаємо пристрій із повним посібником з експлуатації. Деталі GrapheneOS →
Повʼязані: Pixel із GrapheneOS · обфускація IMEI на GL.iNet Mudi · Як перевірити захищений телефон.
Купити Pixel із GrapheneOS: моделі
Джерела
Стандарти
- 3GPP TS 22.016 «International Mobile station Equipment Identities (IMEI)», V19.0.0 (2025-10), розділ 2. — 3gpp.org
- GSMA TS.06 «IMEI Allocation and Approval Process», V27.0 (06.01.2025), розділ 7 «IMEI Security and Integrity Guidelines». — imeidb.gsma.com
Документація GrapheneOS
- GrapheneOS, Usage guide, розділ «Carrier functionality» — твердження про неможливість зміни IMEI на серійному пристрої. — 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, про розблокований завантажувач як незавершену інсталяцію. — grapheneos.org
- GrapheneOS, допис від 17.10.2024 про недостатність зміни самого лише IMEI. — grapheneos.social
Обмеження доступу до ідентифікаторів в Android
- Android Developers, «Privacy changes in Android 10», розділ про незмінні ідентифікатори. — developer.android.com
- Android Open Source Project, «Device identifiers». — source.android.com
Механізм зберігання IMEI у Tensor-пристроях
- lexipwn — інструмент і технічний опис структури розділу devinfo, механізму cpsha та команди AT+GOOGGETIMEISHA. — codeberg.org
- Privacy Guides Community, обговорення «Pixel (Tensor chip) IMEI modification guide», зокрема повідомлення від 13 грудня 2025 року (команду вилучено з образу прошивки модему), 11 травня 2026 року (відсутній файл cpsha) і 22 вересня 2026 року (метод для Pixel 10 Pro). — discuss.privacyguides.net
- rektstarsceosu, «pixel10-imei-repair», метод для Pixel 10 Pro від 22 вересня 2026 року, потребує root-доступу, перевірений лише на Pixel 10 Pro. — github.com
- Pixel-IMEI-Restore — незалежний опис тієї самої послідовності дій. — github.com
Апаратна платформа
- 9to5Google, про використання модему Exynos 5400 у Tensor G5 і серії Pixel 10. — 9to5google.com
Ідентифікація пристрою в мережі поза 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» — про передавання переліку можливостей пристрою до автентифікації без захисту.
- «Radio Frequency Fingerprint Identification for 5G Mobile Devices Using DCTF and Deep Learning», Sensors. — pmc.ncbi.nlm.nih.gov
Засоби програмної підміни ідентифікаторів
- LSPosed — фреймворк перехоплення викликів ART. — github.com
- Репозиторій модулів LSPosed: Android Faker, SpoofMyDevice, IMEI Masker. — modules.lsposed.org
