Intereting Posts
В чем разница между представлением и активностью в развитии Android? Android "java.lang.RuntimeException: Parcelable сталкиваетсяClassNotFoundException, читающий объект Serializable" Команды оболочки Adb для изменения настроек или выполнения задач на телефоне Игровой сервер для пошаговой игры android / iOS Мне нужно изменить цвет штриха на определенный пользователем цвет. Ничего общего с государством «Ловить» OutOfMemoryError полностью решает проблему нехватки памяти? Как центрировать текст в tabhost? AdMob ", вы должны иметь adactivity, объявленный в androidmanifest.xml с configchanges" Ресурсы служб Google Play не были настроены Как выделить два щелчка элемента меню в ActionBarSherlock? Завершение работы в библиотеке поддержки Android? Создание изображения с экрана просмотра в Android Пользовательский интерполятор Android с xml Android, эквивалентный applicationDidBecomeActive и applicationWillResignActive (от iOS) Обрезать видео с помощью FFMpeg очень медленно

Как защитить 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 } // ... } 

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

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

Solutions Collecting From Web of "Как защитить Google In-App Billing v3 от взлома кода?"

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

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