Как создавать патчи, основанные на доверчивой политике безопасности Android

[@FanAs]

Но зачем? Суть любой игры в том, чтобы пройти её, а не выиграть.

[@Asen]

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

[@Dimmerg]

Я думаю, тут также виноваты и разработчики приложений, которые не проверяют целостность данных, не шифруют их и используют их в своем приложении с полной доверенностью источнику…

На одного игрока, который хакнет игру, найдется 1000-10000 тех, кто просто поиграет в нее и скажет спасибо (или даже $). Какой смысл тратить тонну времени на защиту от взлома таких игр, если за это время лучше сделать уровней или запилить еще один режим игры? Любую защиту все равно сломают, ломать — не строить.

[@Asen]

Ломать — не стоить, это уж точно…

[@Fury]

На самом деле, подобная брешь не является виною только Android.

Эээ, где же брешь-то?
Приложение, подписанное новым сертификатом — это новое приложение. Поэтому ваш пропатченный 2048 — это уже не оригинальное приложение, его нужно ставить отдельно, и никаких апдейтов из маркета оно уже не получит.
Точно так же можно было разобраться в коде и сделать так, чтобы пропатченный 2048 сам писал нужные данные в файлы.
А то, что два приложения подписанные одним ключом (то есть принадлежащие одному разработчику), могут тесно взаимодействовать — это заложено в Андроид изначально (например, см. android:process в манифесте).

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

[@toxicdream]

Может я чего-то недопонимаю, но разве в статье как раз не об этом написано?

[@Tishka17]

Итак, имеем APK пакет приложения, подписанный нашим дефолтным ключом.

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

[@dordzhiev]

Ребят, ну это вовсе не патч. Мало апк переписать, так еще и XML сохранялки меняют.

[@amarao]

эм… ну отредактировали сейв. И? При xml-формате это просто. вот у diablo1 сложный формат save'a был, я не. осилил на первом курсе.

[@maxru]

Был редактор сейвов и для 1 и для 2.

[@amarao]

В мою скудную юность интернетов ещё толком не было, так что сейвы ломались вручную, при помощи hexeditor'а, diff'а и прочих handy stuff.

[@Tishka17]

А ведь plist бывает и бинарный

[@Asen]

Да-да, полностью с вами согласен. Приложениям, действительно, следует хранить свои более-менее важные данные не в чистом виде, а хотя бы в бинарном, как это делают разработчики Subway Surfers. Вот их уже будет гораздо сложнее «проломить» и сфальсифицировать данные. Собственно, эта статья, отчасти, как раз к подобному подходу хранения данных и призывает.

[@amarao]

В чём смысл прятать сейвы от пользователя?

[@Newbilius]

Так пропатчить данные приложения, установленного из магазина мы не можем, верно, только «своего» приложения (переподписанного)?

[@Asen]

Тут все дело в сертификате( цифровом ключе ) приложения. Собственно, достать сам APK пакет можно откуда угодно — хоть с GooglePlay — структура пакетов везде одинаковая. Но только после «взятия» целевого пакета уже встает вопрос о его переподписке.

[@Newbilius]

Я к тому, что как вариант атаки («заразить чужой телефон, которого нет у вас в руках») не сработает. Уже неплохо.

[@Bo0oM]

И играть стало неинтересно :)

[@coder1cv8]

Я, одно время, использовал в своих играх решение с шифрованием SharedPreferences, типа такого, что впрочем, не особо усложняет. Сейчас не использую никакой защиты. Смысл? Захотят взломать — взломают. Игрок, делающий патч с «бесконечными патронами» (или качающий этот патч с какого-нибудь варезника) — в любом случае, не моя ЦА. Лучше я потрачу это время/усилия на улучшение самой игры.

[@Tishka17]

Неожиданно увидеть plist на Android. С другой стороны, там же cocos2d.

[@stan_jeremy]

Изобретение

[@Newbilius]

И второй вопрос: игра отправляет данные на сервер для топа игроков? Т.е., реально фейковый рекорд себе сделать?
Если нет, то никаких проблем в безопасности нет.

[@Qbit]

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

Только не оригинальную игру, а переподписанную нашим ключом — правильно?

[@Asen]

Да, разумеется. «Уникальность и неповторимость» приложений на уровне системы определяется для Android как минимум двумя основными аспектами: название JAVA пакета( Java Package) и сертификатом( ключом ). Получается, что если хотя бы одно из двух не будет соответствовать оригиналу, то приложение уже будет совершенно другим для системы Android.

[@Qbit]

На самом деле, подобная брешь не является виною только Android.

Я не вижу тут бреши или неожиданного поведения системы.

1) Сперва установим [переподписанную нами] игру 2048.
2) Устанавливаем патч
3) Переустанавливаем нашу [исходную переподписанную] игру

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

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

Почему это называется «патчем»? Оно не меняет функционал исходной программы, меняет лишь её данные.

[@Asen]

Боюсь, вы слишком многословны.