A
Можно попробовать запросы из натива делать (asio или boost) но и то перехватывается
Size: a a a
2020 August 07
m
Понятно, по всей вероятности проблема фундаментальная, гуглу в очередной раз не до нее
m
Можно попробовать запросы из натива делать (asio или boost) но и то перехватывается
Есть масса вариантов
m
Можно попробовать запросы из натива делать (asio или boost) но и то перехватывается
И я так полагаю, всевозможные детекторы Фриды, xposed, проверка на рут тоже идут мимо?
A
main
И я так полагаю, всевозможные детекторы Фриды, xposed, проверка на рут тоже идут мимо?
Да. Обходятся той же фридой и хпосетом)
m
Да. Обходятся той же фридой и хпосетом)
А по какому тогда пути следует идти чтобы усложнить задачу взлома? Понятно что рано или поздно взлом будет
A
Выноси все на сервер
A
И мультиплатформенность и защита)
R
main
А по какому тогда пути следует идти чтобы усложнить задачу взлома? Понятно что рано или поздно взлом будет
Если хочется на девайсе, то можно загнаться по whitebox реализации aes в нативной либе.
m
Если хочется на девайсе, то можно загнаться по whitebox реализации aes в нативной либе.
Я наверное не уточнил, у нас так и реализовано:
Шифрованный контент отправляется в нативную либу, далее нативный aes делает расшифку и возвращает обратно в java
Выходит, sqlite базу шифровать бесполезно, ключ нигде не спрячешь. Единственное, это шифровать данные базы и производить расшифровку внутри либы
Шифрованный контент отправляется в нативную либу, далее нативный aes делает расшифку и возвращает обратно в java
Выходит, sqlite базу шифровать бесполезно, ключ нигде не спрячешь. Единственное, это шифровать данные базы и производить расшифровку внутри либы
R
main
Я наверное не уточнил, у нас так и реализовано:
Шифрованный контент отправляется в нативную либу, далее нативный aes делает расшифку и возвращает обратно в java
Выходит, sqlite базу шифровать бесполезно, ключ нигде не спрячешь. Единственное, это шифровать данные базы и производить расшифровку внутри либы
Шифрованный контент отправляется в нативную либу, далее нативный aes делает расшифку и возвращает обратно в java
Выходит, sqlite базу шифровать бесполезно, ключ нигде не спрячешь. Единственное, это шифровать данные базы и производить расшифровку внутри либы
нативный aes c ключем в том же нативе != whitebox aes
R
ну это для справки
R
Ребята выше верно писали - если ключ в натива, даже если он размешен там, его можно достать фридой или дебагером нативного кода
m
Ребята выше верно писали - если ключ в натива, даже если он размешен там, его можно достать фридой или дебагером нативного кода
Даже если этот ключ не светится наружу?
R
Яркий пример этой истории - API key инстаграмма. Который лежал в нативе и тоже был “хитро” размешен )
R
main
Даже если этот ключ не светится наружу?
Конечно. Он же у тебя статический. Я запущу приложение под фридой и хукну функцию которая твой ключ собирает
R
почитай как ломали инстаграм и доставали api key. Вот так и твое приложение разломают =)
m
Конечно. Он же у тебя статический. Я запущу приложение под фридой и хукну функцию которая твой ключ собирает
Ключ вроде собирается динамически, но посыл понятен, что это тоже не защищает
R
Угу. Его сборка ничего не дает в случае с хуком
R
Гораздо адекватнее тут будет не баловаться с нативом, а просто хранить ключ в кейсторе. И сделать его уникальным для каждого пользователя. Т.е. генерить при первом запуске приложения например