Определение, сломан ли iPhone джейлом Программно - PullRequest
78 голосов
/ 17 июля 2009

Как определить (программно), является ли iPhone / iPod:

  1. Джейл сломан
  2. Запуск взломанной копии вашего программного обеспечения

Pinch Media может определить, не сломан ли телефон или не работает ли программное обеспечение, кто-нибудь знает, как они это делают? Есть ли библиотеки?

Ответы [ 4 ]

39 голосов
/ 17 июля 2009

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

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

25 голосов
/ 21 июля 2009

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

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

10 голосов
/ 21 июля 2009

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

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

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

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

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

Чтобы расширить комментарии Йонела и Бенджи выше:

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

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

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

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

...