Как защитить CSV или JSON базу данных в мобильном приложении?

Question

[an_del]

Пишу мобильное приложение, для его работы необходима база данных (собираю вручную, очень долго, поэтому не хочется чтобы какой нибудь Вася Пупкин однажды заглянул в apk и все мои труды забрал например к себе в проект).
У меня было 2 варианта:
1. Шифрование (Но как я понял бесплатные варианты так себе шифруют и могут быть в лёгкую расшифрованы)
2. Хранить на сервере (Но в этом случае нужен мощный сервер который выдержит нагрузку)

Comments

[mayton2019]

1) Каким образом CSV/JSON защитит тебя от реверс-инжинеринга. По моему - вообще никак не защитит.

2) Почти все современные алгоритмы шифрования - бесплатные. Их слабость может быть только в том
где лежит ключ. И этот вопрос трудно решаемый в парадигме дистрибуции apk файлов.

[Drno]

А чего ты жадничаешь то?

[an_del]

mayton2019, моя задача в этом и состоит, чтобы не дать любому Васе Пупкину распаковать приложение и узнать как оно работает

[an_del]

Drno, долгий труд :)
да и конкурент есть, у него база данных маленькая, информации пользователю очень мало даёт, а меня обширная и подробная, не хочется чтобы конкуренты заюзали мой труд

[mayton2019]

an_del, это сложная задача. Ревер-инжинеринг способен поднять любые факты из исходного кода.
Цена вопроса - время и специалисты. Но я не знаю насколько ценным должен быть твой код
чтобы за него кто-то взялся по серъезному. Что там у тебя? Лекарство от рака? Или формула
вечного двигателя?

Обычно для защиты от реверса - искусственно создают трудности для этого реверса. Например
делают обсфускацию кода. Обычно обфускация заключается в искусственном искажении смыслов
переменных. Переменные и названия классов могут быть из знаков подчеркивания долларов и цифр.
Для пущего ужаса в код могуд добавлятся ложные инструкции которые ничего не делают но просто
создают эффект дополнительной логики которая усложняет анализ.
Или например усложняют стек. Вот ты пишешь на Kotlin? Отлично
откажись и перейди на С++ под мобильную платформу. Пускай источником к анализу будет
не ART-код а машинный код по ARM процессоры. Это сильно испортит настроение реверс-инжинеру.
Правда я е уверен насчет практики. Пишут ли на С++ приложухи под мобилы или нет?

Answer 1

[rPman]

100% защиты не будет, в конечном счете все упрется в стоимость защиты и атаки, и соответственно смысла это делать.

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

Comments

[an_del]

с идентификаторами интересная мысль, спасибо, гляну подробнее как это работает

Answer 2

[d'Ivan]

Данные принято хранить в СУБД, а не файликах. Может работать on-prem или на облачном хостинге. СУБД может быть реляционной (язык запросов SQL), ключ-значение, колоночная и т.д
Как правило, мощный сервер не нужен. Даже если данных сотни ГБ. Но это зависит от того правильно ли спроектирована БД и типа самых популярных запросов к ней.
Как правило, мобильные приложения не работают напрямую с СУБД и используется многоуровневая архитектура. Безопасность данных обеспечивается комплексом мер безопасности для мобильного приложения и северной части (читай про OWASP). Само по себе шифрование данных возможно, но этим заморачиваются обычно лишь особо параноидальные организации. Это требует знаний в разработке бэкэнда. Обычно используется веб-фреймворк и стек технологий типа LEMP или альтернативы.

Есть вариант куда проще - можно рассматривать как промежуточный - миграция файлов в SQLITE (работать с ним из приложения при помощи SQL). Но я не знаю можно ли скачивать файл БД при установке на мобильное устройство. Иначе придётся запаковывать его в приложение. По идее можно, раз игры скачивают свой контент.

Ещё есть вариант с Firebase. Кто знает, пусть напишет.

Comments

[an_del]

глянул, Firebase выглядит привлекательным вариантом, спасибо

Answer 3

[Олег]

Никак. Технические решения не работают.
Ваша база из открытых источников ?
Думаю даже юридическая защита тут не поможет.

Только постоянная актуализация.
Занятие лидирущих позиций по ASO в своей нише.
Продвижение.
Цены на грани рентабельности.

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