Определение того, что iPhone взломан Jail Programmatically

Ответ 1

Здесь - один из способов определить, было ли ваше приложение взломанным.

Вкратце: трещины обычно требуют изменения Info.plist. Поскольку у него обычный файл, к которому у вас есть доступ, довольно легко определить такие изменения.

Ответ 2

Обнаружение джейлбрейка телефона так же просто, как проверка наличия папки /private/var/lib/apt/. Хотя это не определяет пользователей только для Installer, к настоящему времени большинство из них установили Cydia, Icy или RockYourPhone (все из которых используют apt)

Чтобы обнаружить пиратских пользователей, самый простой способ - проверить наличие ключа SignerIdentity в вашем приложении Info.plist. Поскольку продвинутые крекеры могут легко найти стандартные проверки [[[NSBundle mainBundle] infoDictionary] objectForKey: @"SignerIdentity"], лучше всего затмить эти вызовы с использованием среды выполнения Objective C, доступной через #import <objc/runtime.h>, или использовать альтернативные эквиваленты.

Ответ 3

Просто чтобы расширить на zakovyrya ответить, вы можете использовать следующий код:

if ([[[NSBundle mainBundle] infoDictionary] objectForKey: @"SignerIdentity"] != nil) {
  // Jailbroken
}

ОДНАКО, человек, взломанный в вашем приложении, может выполнить шестую версию вашей программы и как таковой, они могут отредактировать строку @ "SignerIdentity", чтобы прочитать @ "siNGeridentity" или что-то еще, что вернет нуль и, таким образом, пройдет.

Итак, если вы используете это (или любые другие предложения из http://thwart-ipa-cracks.blogspot.com/2008/11/detection.html):

• Не ожидайте, что он будет работать вечно
• Не используйте эту информацию, чтобы каким-либо образом нарушить/затруднить ваше приложение (в противном случае у них будет причина для его использования, поэтому ваше приложение не будет знать, что это jailbroken)
• Возможно, разумно обфускать этот бит кода. Например, вы можете поместить в свой код закодированную в исходном коде строку base64, а затем декодировать ее в приложении, изменив процесс.
• Подтвердите свою проверку позже в своем коде (например, когда я сказал SignerIdentity, действительно ли он сказал SignerIdentity или siNGeridentity?)
• Не сообщайте людям на общедоступном веб-сайте, таком как stackoverflow, как вы это делаете.
• Имейте в виду, что это всего лишь руководство и не является безупречным (и не имеет доказательств безопасности!) - с большой силой приходит большая ответственность.

Ответ 4

Чтобы расширить слова yonel и Benjie выше:

1) Метод Лэндона Фуллера, основанный на проверке шифрования, связанной выше yonel, по-видимому, единственный, который еще не побежден автоматическими инструментами крекинга, Я бы не стал слишком беспокоиться о том, что Apple изменит состояние заголовка LC_ENCRYPTION_INFO в ближайшее время. Кажется, что это имеет некоторые непредсказуемые последствия для jailbroken iphones (даже когда пользователь купил копию...)

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

2) В дополнение к комментарию Benjie re. obfuscation (абсолютная необходимость иметь дело с любыми строковыми значениями в вашем антипиратском коде): подобный, но, возможно, еще более простой способ - всегда проверять соленную хешированную версию значения, которое вы ищете. Например (хотя эта проверка уже не эффективна), вы должны проверить каждое ключевое имя MainBundle как md5 (keyName + "some secret salt" ) против соответствующей константы... Скорее всего, но обязательно победите любую попытку найти строка.

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