Как защитить Google In-App Billing v3 от взлома кода?

Google предоставляет удобный API для реализации функций «покупки в приложении» в приложении для Android.

Наряду с этими документами есть также отдельная глава, посвященная уровню безопасности этой системы и хорошим способам ее разработки. В Интернете полно статей об этом шаге, от защиты открытого ключа до проверки на удаленном сервере , но я действительно не могу понять, почему все эти методы должны работать, когда основной проблемой является просто взлом кода .

Может быть, есть лучший термин, чтобы объяснить это, но позвольте мне сделать быстрый пример. Основная идея моего приложения заключается в том, что в определенные моменты пользователь не может действовать, если только он не купил предмет.

Что-то вроде:

public void accessTheVeryCoolFeature() { boolean haveIt = checkIfPurchased("verycoolfeature"); if (haveIt) { // YEAH! let's open this very cool feature I paid 200 bucks for } else { // ok... where is my wallet? boolean purchased = startPurchaseFlow("verycoolfeature"); if (purchased) { // my wallet is now empty but happy } } } 

Следуя предыдущим рекомендациям, разработчик может защитить свое приложение во время процесса покупки, позволяя методу startPurchaseFlow запрашивать удаленный, надежный сервер, который проверяет получение. Таким образом следует избегать покупок, совершенных с использованием «поддельного рынка».

Другой способ – защитить разблокированный контент, запутывая код. Это очень просто с такими инструментами, как ProGuard, и сделать жизнь «хакера» немного сложнее.

Теперь я попытался сыграть роль хакера, который хочет прочитать мой код, особенно этап выставления счетов. Мне потребовалось 1 минута, чтобы определить код, который я написал в предыдущем примере. Теперь лучшая часть: что, если я отредактирую (обфусканный) исходный код, чтобы сделать это?

 public void atvf() { boolean hi = cip("verycoolfeature"); hi = true; // <------------------------ AHAH! if (hi) { // YEAH! let's open this very cool feature for free } // ... } 

Все хорошие слова о дистанционной проверке и обфускации кода полностью исчезли. Итак, зачем тратить часы на попытки реализовать их, когда первая проблема находится в логическом значении ?

Я что-то упускаю?

Если ваше приложение сильно зависит от его функциональности, находящейся на сервере, – так как каждая функциональность остается на сервере, а приложение – просто клиентский инструмент для вызова этих API-интерфейсов серверов, вы ничего не можете сделать. Если это приложение на сервере, вы можете проверить каждый входящий запрос (например, приложение может отправлять хэш-сообщение в одно время), если для него существует действительная транзакция и она выплачивается. Если нет, отклоните запрос.

Код приложения работает на телефоне клиента. Если хакер получает доступ к этому коду и может изменять его, чтобы переопределить любые проверки счетов, вы ничего не можете сделать. Вы должны убедиться, что он не получает доступ к этому исходному коду в первую очередь.