Возможности декомпиляции в iOS и как их предотвратить

Question

Я недавно читал о декомпиляции приложений для iOS, и теперь я действительно обеспокоен этим. Как указано в следующих постах ( # 1 и # 2), можно декомпилировать iOS, которая распространяется в App Store. Это можно сделать с помощью джейлбрейка, и я думаю, скопировав приложение из памяти на жесткий диск. С некоторыми инструментами можно

• считывать строки (инструменты для работы со строками)
• сбросить файлы заголовков
• обратный инжиниринг для сборки кода

Похоже, что невозможно сделать реинжиниринг кода Какао.

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

1. Может кто-нибудь восстановить мои методы сохранения и шифрования или входа в систему с помощью сборки? Я имею в виду, может ли он понять, что именно происходит (что сохраняется, по какому пути, в какое время, какой ключ используется и т. Д., С какими учетными данными это логин, с которого выполнен веб-сайт)? У меня нет понимания сборки, это выглядит как матрица для меня...
2. Как я могу безопасно использовать NSStrings который не может быть прочитан со строками или прочитан в сборке? Я знаю, что можно сделать запутывание строк - но это все еще не безопасно, не так ли?

Answer 1

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

Без джейлбрейка можно разбирать приложения, используя купленный или загруженный бинарный файл. Это статический контроль, который облегчается с помощью стандартных инструментов для разборки. Хотя вам нужен инструмент, который достаточно хорош, чтобы добавлять символы из компоновщика и понимать вызовы методов в достаточной степени, чтобы можно было понять, что происходит. Если вы хотите почувствовать, как это работает, проверьте бункер, это действительно хороший инструмент для разборки / обратного проектирования.

Что касается вашего безопасного входа в систему, у вас есть более серьезная проблема, если у вас есть мотивированный злоумышленник: системные атаки типа "человек посередине". В этом случае злоумышленник может отключить сетевой код, используемый вашей системой, и увидеть все, что отправлено через стандартную сеть. Таким образом, вы не можете зависеть от того, сможете ли вы отправлять любые незашифрованные данные в "защищенный" канал на уровне ОС или библиотеки и ожидать, что их не увидят. Как минимум, вам необходимо зашифровать данные, прежде чем отправлять данные в канал (т.е. вы не можете зависеть от отправки простого текста в стандартные библиотеки SSL). Вы можете скомпилировать свой собственный набор библиотек SSL и связать их непосредственно с вашим приложением, что означает, что вы не получите никаких улучшений производительности и безопасности системы с течением времени, но вы можете вручную обновить свои библиотеки SSL по мере необходимости. Вы также можете создать свое собственное шифрование, но это чревато потенциальными проблемами, поскольку мотивированные хакеры могут в этот момент легче атаковать ваш проводной протокол (публично протестированные протоколы, такие как SSL, обычно более безопасны, чем те, которые вы можете собрать самостоятельно, если только Вы - особенно одаренный разработчик с многолетним опытом в области безопасности / шифрования).

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

• хранение ключей шифрования простого текста для любой стороны шифрования
• хранение ключей в специально названных ресурсах (файл с именем serverkey.text или ключ хранится в списке с именем, которое содержит key оба классика)
• по возможности избегайте простых паролей

Но наиболее важным является создание систем, в которых ключи (если они есть), хранящиеся в приложении, сами по себе бесполезны без информации, которую пользователь должен вводить сам (прямо или косвенно через такие системы, как OAUTH). Сервер не должен доверять клиенту для какой-либо важной операции, не имея некоторого взаимодействия с пользователем, которому можно доверять.

Брелок Apple предоставляет хорошее место для хранения токенов аутентификации, таких как те, которые получены во время последовательности OAUTH. С API немного сложно работать, но система надежная.

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