В модуле BillingService необходимо изменить параметры для повышения безопасности?

Комментарий для класса BillingService рекомендует:

Вы должны изменить и обфускать этот код перед его использованием.

Хорошо, но что нужно изменить?

Имя класса? TAG используется для регистрации? Имена методов и члены данных? Сама логика и программный поток? Другие?

Другими словами, я могу понять необходимость обфускации, но как я могу избежать реализации рекомендации, не переписывая все с нуля (возможно, с ошибками, которые хуже, чем не изменением)?

Я сейчас работаю над этим, и мой подход до сих пор таков:

  1. Я использую BillingReceiver, Billing Service, PurchaseObserver и ResponseHandler.
  2. Я переместил все константы в свой собственный класс Constants, и все вышеперечисленные классы включены в мой собственный пакет.
  3. Я покончил с классом PurchaseDatabase и интегрировал его в свою собственную базу данных SQLite, DBAdapter и классы доступа к данным.
  4. Я изменил CatalogEntry на свой собственный объект модели, и мой пользовательский интерфейс будет совсем другим, например, например, группой RadioButton, а не Spinner для элементов продукта (у меня всего 4).
  5. Он говорит в классе безопасности «Для безопасной реализации весь этот код должен быть реализован на сервере, который взаимодействует с приложением». Мне повезло, что мое приложение все равно должно контактировать с моим сервером, поэтому я буду применять эти меры безопасности на сервере, и я сделаю свою собственную проверку информации о покупке, переданной на сервер. Я ищу, чтобы защитить эту часть коммуникаций, используя SSL, и мне уже требуется предварительное имя пользователя / пароль (хешированный и соленый), который хранится на моем сервере.
  6. Я вырезаю любой другой лишний код, который я не использую, например, редактирование полезной нагрузки.
  7. Некоторые из методов имеют 5 или 6 параметров в своей сигнатуре, например onPurchasestateChanged () – я думал о объединении их в один объект-оболочку (но еще не сделал этого).
  8. Я тестирую его медленно и тщательно, чтобы понять, что происходит, и следовать рекомендациям. Сначала я использовал полный образец, чтобы убедиться, что он сработал и протестировал статические ответы. Затем я начал делать свои собственные изменения, продолжая статическое тестирование. Я все еще тестирую статические ответы, и я буду следить за потоком сообщений, чтобы понять происходящие обмены. Как только я доволен этим, я буду тестировать свой собственный идентификатор продукта и попробовать и убедиться в данных и его безопасности.
  9. Я думал, что строка разработчикаPayload также может быть подписана и зашифрована, а при возврате на мой сервер, расшифрована и проверена на целостность.
  10. Наконец, я буду запутывать код с помощью ProGuard и следовать некоторым советам для этого, которые доступны в StackOverflow.

Надеюсь это поможет.

Здесь нет хороших новостей: вам нужно изменить все, что вы можете, помимо использования Proguard. Это включает в себя объединение классов, их разделение, перемещение определенных методов из одного модуля в другой и, в частности, шифрование информации о покупке, хранящейся в базе данных, поскольку описание класса PurchaseDatabase предполагает:

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

Причина в том, что с помощью таких инструментов, как AntiLVL, очень легко сравнить ваш декомпилированный (обфусканный!) Код с исходным образцом и вычесть из него все необходимое для его компрометации. Невозможно полностью предотвратить растрескивание, но вы должны попытаться сделать это как можно труднее.

Они объясняют это следующим образом:

Приложение примера биллинга в приложении является общедоступным и может быть загружено кем угодно, а это значит, что злоумышленник относительно легко обращает ваше приложение, если вы используете образец кода точно так, как он опубликован. Образец приложения предназначен для использования только в качестве примера. Если вы используете какую-либо часть образца приложения, вы должны изменить его, прежде чем публиковать его или опубликовать как часть производственного приложения.

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

Это означает, что вы не используете код, как предусмотрено, измените часть его, чтобы хакеры не смогли узнать, какой код вы используете.

В принципе, я не думаю, что они имели в виду сам сервис billingService, но как вы его используете в своем приложении.

Intereting Posts
Ошибка GridView в горизонтальном расстоянии Есть ли способ заставить EditText начать печатать в верхнем левом углу EditText? Инструменты автоматизации тестирования Android Передача ArrayList строковых массивов из одной активности в другую в android Покупки в приложениях для Android: вам нужно проверить разрешение com.android.vending.BILLING при настройке Android 6? Gradle buildType / productFlavor с использованием неожиданного buildConfigField Как воспроизводить видео с помощью видеовизу и входного потока Нет разрешения на запись в / mnt / extsd Android OpenGL ES GL10 или GL11 SecurityException – неизвестное имя вызывающего пакета -Android 6.0.1 Есть ли способ создать файл R.java в Android Studio? Обновление библиотеки Google Play Services и отсутствующий символ @ integer / google_play_services_version Ужасная производительность libPNG на iOS Как я могу обновить свой ListFragment, когда он вернется в макет из предыдущего стека? Видео + аудиозапись Android