У сучасних мобільних застосунках саме in‑app покупки та підписки приносять левову частку доходу. Проте навіть коректна інтеграція Google Play Billing не гарантує, що користувач справді заплатить за преміум‑функції. У розмові на каналі Philipp Lackner демонструється, як зловмисник може обійти платіжний потік без модифікації APK, використовуючи інструмент динамічної інструментації Frida. Ця техніка показує, наскільки вразливими залишаються застосунки, які покладаються лише на клієнтську логіку.
Від статичного зламу до живого переписування коду
Класичний сценарій атаки на in‑app покупки починається зі статичного аналізу: зловмисник завантажує release‑APK з Google Play через сторонні сайти, де можна отримати «сирий» файл застосунку. Далі використовуються інструменти на кшталт Jadx для декомпіляції в читабельний Java‑подібний код та APKTool для розбирання APK на smali‑файли, їх модифікації й перепакування.
У демонстраційному застосунку преміум‑доступ контролюється простою змінною стану: isPremium — це state flow, який на старті має значення false і перемикається в true після успішної покупки через Google Play. У першому сценарії атаки (який розглядається окремо в іншій частині серії) зловмисник змінює smali‑код так, щоб цей прапорець ініціалізувався як true ще під час запуску. В результаті користувач отримує преміум без будь‑якого платіжного діалогу.
Однак існує більш витончений підхід, який не потребує перепакування APK. Саме тут у гру вступає Frida — інструмент динамічної інструментації, що дозволяє втручатися в роботу застосунку «на льоту», підмінюючи виклики функцій у вже запущеному процесі.
Що таке Frida і чому без root вона безсила
Frida позиціонується як кросплатформний інструмент для динамічної інструментації: вона дає змогу під’єднатися до процесу, перехопити виклики функцій, змінити їхню поведінку або повністю замінити реалізацію на власну. На Android це означає можливість втручатися в роботу будь‑якого застосунку, який виконується на пристрої, — за умови, що у зловмисника є достатні привілеї.
Саме тому використання Frida на Android вимагає root‑доступу — або на фізичному пристрої, або в емуляторі. Без root неможливо коректно інжектувати код у процеси інших застосунків, а отже, неможливо реалізувати повноцінну динамічну інструментацію.
Типовий сценарій виглядає так: на пристрій або емулятор за допомогою adb завантажується спеціальний серверний бінарій Frida для Android. Цей бінарій запускається з правами root, після чого Frida відкриває канал для віддаленого керування з хост‑машини (наприклад, ноутбука розробника або зловмисника). Далі вже з десктопа можна підключатися до процесу потрібного застосунку, писати скрипти на JavaScript і в реальному часі змінювати поведінку коду.
У демонстрації використовується Android‑емулятор, який попередньо «рутять». Для цього його запускають із прапорцем -writable-system, що дозволяє змінювати системний розділ, а потім виконують команди adb root та adb remount. Після цього система працює в режимі, де adb має root‑привілеї, а отже, можна завантажити й запустити Frida‑server з максимальними правами.
Цей технічний ланцюжок — root‑емулятор, Frida‑server, віддалене підключення — створює середовище, в якому будь‑який застосунок перетворюється на «відкриту книгу» для динамічного аналізу та маніпуляцій.
Як Frida переписує логіку покупки «на льоту»
Ключова відмінність другого сценарію атаки полягає в тому, що APK залишається оригінальним і непошкодженим. Немає перепакування, немає повторного підпису, немає змін у файлах застосунку. Усе відбувається в оперативній пам’яті під час виконання.
У демонстраційному застосунку преміум‑доступ надається через функцію на кшталт grantPremiumAccess, яка в підсумку встановлює isPremium у true і оновлює інтерфейс. У нормальному сценарії ця функція викликається лише після того, як Google Play Billing поверне успішний результат, а застосунок перевірить, що покупка справді здійснена й підтверджена.
Frida дозволяє зловмиснику обійти весь цей ланцюжок. Один із найпростіших варіантів — перехопити обробник натискання на кнопку покупки. У типовому Android‑застосунку це onClick‑обробник, який запускає платіжний потік Google Play. Замість того, щоб дозволити йому виконати стандартну логіку, Frida може «підчепитися» до цього обробника і замінити його тіло на власний код.
На практиці це виглядає так: зловмисник пише Frida‑скрипт, який знаходить у процесі клас, що відповідає за екран покупки, і метод, який викликається при натисканні кнопки. Далі цей метод «перехоплюється» — Frida підміняє його реалізацію. Замість запуску Google Play Billing, новий код просто викликає grantPremiumAccess без будь‑яких перевірок.
Результат для користувача виглядає майже так само, як легальна покупка: він натискає кнопку, інтерфейс оновлюється, з’являється напис «Premium active», функції розблоковано. Але жодного реального платежу не відбулося, Google Play не отримав транзакції, а розробник — грошей.
Важливо, що в цьому сценарії застосунок з точки зору файлової системи залишається незміненим. Це ускладнює виявлення атаки за допомогою простих перевірок цілісності APK або підпису. Усе шахрайство відбувається на рівні виконання, де Frida перехоплює й переписує виклики функцій у реальному часі.
Преміум без модифікації APK: чому це особливо небезпечно
Другий сценарій атаки, побудований на Frida, демонструє принципово інший клас загроз порівняно зі статичним зламом через APKTool. Якщо у випадку зі smali‑модифікаціями розробник ще може спробувати захищатися через перевірку підпису, виявлення модифікованих пакетів або контроль джерела встановлення, то при динамічній інструментації такі підходи втрачають ефективність.
Frida дозволяє вмикати преміум‑доступ на оригінальному, незміненому APK, встановленому з офіційного магазину. Застосунок підписаний справжнім ключем розробника, проходить усі стандартні перевірки, але логіка виконання вже не належить повністю самому застосунку. Частина рішень фактично делегується Frida‑скриптам, які зловмисник інжектує в процес.
У демонстрації це проявляється в тому, що другий тип атаки не вимагає жодних змін у файлах застосунку. Frida просто підключається до процесу, знаходить потрібні методи й викликає grantPremiumAccess напряму, минаючи Google Play Billing. Таким чином, навіть якщо розробник не допускає простих помилок на кшталт зберігання преміум‑статусу в явному вигляді в SharedPreferences, сама наявність клієнтської функції, яка вмикає преміум, стає точкою атаки.
Це підкреслює фундаментальну проблему: будь‑яка логіка, яка приймає остаточне рішення про надання доступу до платних функцій на клієнті, може бути змінена або обійдена. Frida лише робить цей процес зручним, скриптовим і відтворюваним.
Frida проти криптографії: коли шифрування не рятує
Ще один важливий аспект динамічної інструментації — можливість працювати не лише з бізнес‑логікою, а й з криптографічними API. Багато розробників, усвідомлюючи ризики простого прапорця isPremium, намагаються захистити преміум‑контент, шифруючи його локально. Наприклад, відео, статті або інші ресурси можуть зберігатися в зашифрованому вигляді й розшифровуватися лише для користувачів із чинною підпискою.
На перший погляд це виглядає як суттєве посилення безпеки. Однак Frida й тут відкриває можливості для обходу. Оскільки інструмент може перехоплювати виклики будь‑яких функцій, зловмисник здатен «підчепитися» до криптографічних API, які застосунок використовує для шифрування та розшифрування.
У найпростішому варіанті можна перехопити функцію, яка відповідає за розшифрування контенту, і змінити її поведінку. Наприклад, змусити її завжди повертати розшифровані дані незалежно від того, чи має користувач преміум‑доступ. Або ж, навпаки, перехопити момент, коли застосунок уже розшифрував контент для легального користувача, і зберегти ці дані в незашифрованому вигляді для подальшого використання.
Інший напрямок — маніпуляція параметрами шифрування. Якщо застосунок використовує прості клієнтські ключі або предиктивні схеми, Frida дозволяє перехопити ці ключі в момент виконання, змінити їх або зберегти для подальшого аналізу. У результаті навіть відносно складні схеми захисту, побудовані виключно на клієнтській криптографії, можуть бути зруйновані.
Це не означає, що шифрування марне. Воно ускладнює масовий злам і захищає від найпримітивніших атак. Але в поєднанні з інструментами на кшталт Frida стає очевидно: прості клієнтські механізми шифрування не можуть розглядатися як достатній бар’єр для захисту преміум‑контенту. Зловмисник, який контролює середовище виконання, здатен перехопити або змінити будь‑яку операцію, що відбувається на пристрої користувача.
Чому Google Play Billing не є захистом сам по собі
У демонстраційному застосунку платіжний потік побудований навколо Google Play Billing. Клас‑менеджер ініціалізує клієнта, підключається до сервісів Google, запускає платіжний діалог і отримує результат. Після успішної відповіді застосунок викликає функцію обробки покупки, перевіряє, що транзакція справді завершена й підтверджена, і лише тоді викликає grantPremiumAccess, перемикаючи isPremium у true.
На папері це виглядає коректно. Проте ключова проблема полягає в тому, що застосунок не має надійного способу переконатися, що сигнал про успішну покупку справді походить від Google Play, а не від підміненої логіки на клієнті. У демонстрації чітко видно: сам факт використання Google Play Billing Library не заважає зловмиснику перехопити критичні точки — обробник кнопки покупки, функцію обробки транзакції або сам виклик grantPremiumAccess.
Це підкреслює важливу тезу: бібліотека Google Play Billing — це інструмент для інтеграції платіжного потоку, але не повноцінний механізм захисту від клієнтських обходів. Вона не може запобігти тому, що відбувається в середовищі, яке повністю контролює користувач або зловмисник із root‑доступом.
Саме тому в індустрії давно сформувалася практика виносити остаточне рішення про надання преміум‑доступу на сервер. Клієнтський застосунок у такій моделі лише збирає дані про покупку (наприклад, токен транзакції) й передає їх на бекенд. Уже сервер звертається до Google Play або App Store для верифікації, а потім зберігає статус підписки в своїй базі даних. Клієнт лише відображає те, що вирішив сервер, а не самостійно визначає, чи є користувач преміум‑клієнтом.
Деталі такої архітектури виходять за межі цього матеріалу, але саме динамічні атаки з використанням Frida наочно показують, чому без серверної валідації будь‑який клієнтський захист залишається умовним.
Висновки: контроль над виконанням — головна загроза
Сценарій з Frida демонструє, що головна сила зловмисника — це контроль над середовищем виконання. Root‑емулятор або root‑пристрій, Frida‑server із правами суперкористувача, можливість перехоплювати й замінювати виклики функцій у реальному часі — усе це перетворює навіть добре структурований платіжний потік на набір гачків, за які можна потягнути.
Динамічна інструментація дозволяє:
перехоплювати обробники кнопок і напряму викликати функції надання преміум‑доступу;
вмикати преміум на оригінальному, незміненому APK, минаючи будь‑які перевірки цілісності пакета;
працювати з криптографічними API, обходячи прості схеми шифрування локального преміум‑контенту.
У сукупності це робить очевидним: покладатися лише на клієнтську логіку, навіть якщо вона побудована навколо офіційних бібліотек Google Play Billing, небезпечно. Поки остаточне рішення про надання доступу до платних функцій приймається на пристрої користувача, інструменти на кшталт Frida залишатимуться ефективним засобом обходу.
Справжня стійкість до таких атак вимагає зміни моделі довіри: клієнтський застосунок слід розглядати як потенційно скомпрометоване середовище, а критичні рішення — виносити на сервер, доповнюючи це більш просунутими клієнтськими захистами. Динамічні атаки, продемонстровані за допомогою Frida, лише підкреслюють актуальність цього підходу.
Джерело
How Attackers Can Hack Your In-App Purchases (+ How You Protect Them) — Philipp Lackner