Безопасность iOS (часть II)

Безопасность iOS (часть II)

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

Автор: Понуровский Иван

В прошлой статье шла речь о базовых механизмах безопасности операционной системы iOS. Базовые механизмы включают в себя цепочку доверенной загрузки, персонализацию системного ПО, подписание кода сообщений, выполнение приложений в песочнице и с правами непривилегированного пользователя, права доступа (entitlements), ASLR и ARM’s Execute Never. Но, допустим, что случилось страшное: нарушителю удалось каким-то образом обойти базовые механизмы безопасности, и конфиденциальная информация пользователя теперь находится под угрозой. Но и тогда нарушителю может помешать последний, практически нерушимый, оплот безопасности – механизмы шифрования и защиты данных.

Аппаратный уровень

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

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

Каждое устройство с iOS имеет встроенный чип, в котором реализован алгоритм AES-256. Расположение чипа на пути от флеш-памяти к оперативной памяти заметно снижает энергозатраты на шифрование/дешифрование. На аппаратном уровне также реализован алгоритм SHA-1.

При производстве в процессор зашиваются два 256-битных ключа AES: UID (уникальный идентификатор устройства) и GID (групповой идентификатор устройства). Никакое программно-аппаратное обеспечение не может напрямую прочитать ключи AES; можно только прочитать результаты шифрования/дешифрования на этих ключах. Ключ UID уникален для каждого устройства, и он неизвестен даже Apple. Не стоит путать UID и ECID; ECID – это тоже уникальный и тоже идентификатор, который имеет вид 00000XXXXXXXXXXX, где X – шестнадцатеричная цифра; а UID, как уже говорилось выше, 256-битный ключ. Ключ GID одинаков для всех процессоров одного семейства (например, у всех процессоров A5 GID одинаковый).

При загрузке ядра служба IOAESAccelerator вычисляет еще пять ключей на основе UID и GID:

Рисунок 1. Ключи, генерируемые на основе UID и GID

  • Ключ 0x835 генерируется путем шифрования величины 01010101010101010101010101010101 на ключе UID;
  • Ключ 0х899 генерируется путем шифрования величины D1E8FCB53937BF8DEFC74CD1D0F1D4B0 на ключе UID, назначение ключа 0x899 неизвестно;
  • Ключ 0x89A генерируется путем шифрования величины DB1F5B33606C5F1C1934AA66589C0661 на ключе UID и используется для шифрования SHSH-сертификата;
  • Ключ 0x89B генерируется путем шифрования величины 183E99676BB03C546FA468F51C0CBD49 на ключе UID и используется для шифрования ключа раздела данных (ключ EMF);
  • Ключ 0x837 генерируется путем шифрования величины 345A2D6C5050D058780DA431F0710E15 на ключе GID, ключ использовался в ранних версиях iOS и в современных версиях не используется.

В дальнейшем нас будут интересовать только ключи 0x835, 0x89A и 0x89B.

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

Быстрое и безопасное удаление ключей настолько же важно, как и их генерация. Для решения подобной проблемы на устройствах под управлением iOS существует специальная область под названием Effaceable Storage. Область занимает 1 блок (~ 1Мб) во flash-памяти и содержит три ключа: зашифрованный ключ EMF, зашифрованный ключ DKey и ключ BAG1 (подробнее об этих ключах чуть ниже). Технология Effaceable Storage позволяет при необходимости быстро стереть все ключи, сделав всю информацию на устройстве пользователя недоступной.

Механизм защиты данных

Наряду с технологиями аппаратного уровня, для защиты данных пользователя во flash-памяти также используется механизм Data Protection. Механизм ориентирован на мобильные устройства и позволяет пользователю, например, отвечать на входящие звонки без расшифровки конфиденциальных данных, или в фоновом режиме скачивать информацию даже когда устройство заблокировано. Контроль доступа к каждому фалу осуществляется на основе класса защиты, то есть каждому файлу присваивается определенный класс защиты, в зависимости от того, когда может потребоваться доступ к этому файлу (например, только после разблокировки устройства, или даже если устройство заблокировано). У каждого класса защиты есть отдельный ключ, на котором шифруется ключ файла, принадлежащего конкретному классу защиты.
Рассмотрим теперь подробнее, какие действия происходят при создании файла, и как организована его защита. Все очень просто.

  • Каждый раз при создании файла система генерирует новый 256-битный ключ FileKey (файловый ключ);
  • Следующим шагом вычисляется вектор инициализации (IV). Сначала вычисляется так называемый IV-key. IV-key получается путем хеширования файлового ключа, причем хеш берется не весь, а только 16 байтов. Затем, чтобы вычислить окончательное значение IV нужно взять выход регистра сдвига с линейной обратной связью (LFSR), на вход которого подается блок из файла с определенного смещения, и зашифровать выход на ключе IV-key. Другими словами, IV= AES_ENC(SHA1(FileKey), LFSR(offset)).
  • Файл зашифровывается алгоритмом AES на ключе FileKey и векторе инициализации IV в режиме CBC и записывается во flash-память.
  • Файловый ключ FileKey зашифровывается соответствующим ключом класса защиты и записывается в метаданные файла.
  • Метаданные файла зашифровываются ключом EMF. EMF - это специальный ключ, который генерируется при установке iOS или после того, как пользователь стер все данные с устройства. Ключ EMF шифруется ключом 0x89B и сохраняется в области Effaceable Storage, т.е. EMF! = AES_ENC(0x89B, EMF). Опция “Удалить все содержимое и настройки” (“Erase all content and settings”) позволяет в мгновение ока сделать все данные на устройстве недоступными. Действительно, если стереть ключ EMF в Effaceable Storage, никакой файл расшифровать не получится.

Чтобы расшифровать файл нужно проделать все в обратном порядке: сначала расшифровать ключ EMF, затем расшифровать метаданные необходимого файла и прочитать из них зашифрованный FileKey; расшифровать FileKey и, наконец, расшифровать весь файл.
Итак, на данный момент иерархия криптографических ключей iOS выглядит следующим образом:

Рисунок 2. Первоначальный вариант иерархии ключей

Как видно из рисунка, назначение некоторых компонентов иерархии ключей все еще остается неясным. Для полной картины необходимо описать еще несколько сущностей.

Пароль пользователя

На своем устройстве пользователь может установить пароль (Passcode). Всего возможно три вида паролей:

  • четырехзначный числовой пароль;
  • числовой пароль произвольной длины;
  • алфавитный пароль произвольной длины.

На основе UID устройства и пароля пользователя с помощью специальной функции (PBKDF2) вычисляется парольный ключ (Passkey):

Рисунок 3. Вычисление парольного ключа

Чтобы усложнить нарушителю атаку перебором, вычисление парольного ключа намеренно замедляется и в среднем занимает около 80 миллисекунд, причем после каждой неудачной попытке ввода пароля временная задержка до следующей попытки увеличивается. Кроме того, пользователь может включить опцию, благодаря которой после определенного числа неправильных попыток ввода пароля вся информация с устройства будет стерта. Заметим еще, что благодаря тому, что в вычислении парольного ключа участвует UID, парольный ключ для разных устройств с одинаковым паролем все равно будет различаться. Вообще, парольный ключ играет одну очень важную функцию, о которой будет рассказано чуть позже. Известно также, что, начиная с iOS 5, в процессе вычисления парольного ключа участвует еще один аппаратный ключ UID+, но, к сожалению, более подробной информации об этом ключе мне найти не удалось

Ключи классов защиты

Всего в iOS существует 11 классов защиты, причем 5 классов используются для защиты данных (ключи классов защиты данных), а 6 для защиты элементов связок ключей (ключи классов защиты элементов связки ключей). Сначала рассмотрим ключи классов защиты данных.


ID ключа

Название

Назначение

1

NSFileProtectionComplete

Данные доступны только после разблокировки

2

NSFileProtectionCompleteUnlessOpen

Данные доступны после разблокировки или если дескриптор файла остался открытым до блокировки

3

NSFileProtectionCompleteUntilFirstUserAuthentication

Данные недоступны только до первой аутентификации пользователя

4

NSFileProtectionNone

Данные доступны, даже если устройство заблокировано

5

NSFileProtectionRecovery

Недокументировано

Таблица 1. Ключи классов защиты данных

Полная защита (NSFileProtectionComplete, Class A): Если для данных установлен такой класс защиты, то спустя некоторое время после блокировки устройства расшифрованный ключ класса полной защиты стирается из оперативной памяти, делая тем самым данные класса NSFilePotectionComplete недоступными до тех пор, пока пользователь снова не разблокирует устройство и не введет пароль.

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

  • Помимо файлового ключа для файла генерируется пара открытый (pkf) закрытый ключ (skf):

  • У класса защиты NSFileProtectionCompleteUnlessOpen также есть открытый (pkc) / закрытый ключи (skc):

  • На основе закрытого ключа файла и открытого ключа класса защиты вычисляется разделяемый секрет:

  • Файловый ключ зашифровывается на хеше разделяемого секрета и вместе с открытым ключом файла сохраняется в метаданных. Закрытый ключ файла стирается из памяти:

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

 

Данные недоступны только до первой аутентификации пользователя (NSFileProtectionCompleteUntilFirstUserAuthentication, Class C): В отличие от класса полной защиты ключ класса защиты NSFileProtectionCompleteUntilFirstUserAuthentication не удаляется из памяти после блокировки устройства, следовательно пользователь будет иметь доступ к данным класса С, начиная с момента первой разблокировки устройства и ввода пароля вплоть до перезагрузки устройства.

Защита отсутствует (NSFileProtectionNone, Class D): Этот класс по умолчанию присваивается данным, если им не присваивается какой-либо другой класс. На самом деле ключ NSFileProtectionNone хранится в Effaceable Storage: это и есть тот самый ключ Dkey, зашифрованный ключом 0x835, т.е. Dkey! = AES_ENC(0x835, DKey). Таким образом, даже если файлу не присвоен какой-либо класс защиты, файл все равно шифруется.

Связка ключей

Многие приложения должны хранить собственные данные (например, пароли приложения, Wi-Fi пароли, почтовые аккаунты, сертификаты и.т.п.) в безопасности. Безопасность конфиденциальных данных приложений достигается за счет так называемой “связки ключей” (Keychain). По своей сути связка ключей – это база данных SQLite, хранящаяся в файловой системе устройства и имеющая класс защиты NoProtection. Доступ к базе осуществляется при помощи демона securityd, именно этот демон решает какое приложение или процесс к какому элементу связки ключей (записи в базе данных) может обратиться.

Хотя сама база и имеет класс защиты NoProtection, элементы связки ключей имеют собственные классы защиты, а соответственно и ключи классов защиты, в дальнейшем такие ключи будут называться ключи классов защиты элементов связки ключей. В Таблице 2 представлены все 6 возможных ключей классов защиты элементов связки ключей:


ID ключа

Название

Назначение

6

kSecAttrAccessibleWhenUnlocked

Элемент связки ключей доступен только после разблокировки

7

kSecAttrAccessibleAfterFirstUnlock

Элемент связки ключей недоступен только до первой аутентификации

8

kSecAttrAccessibleAlways

Элемент связки ключей доступен, даже если устройство заблокировано

9

kSecAttrAccessibleWhenUnlockedThisDeviceOnly

Элемент связки ключей доступен только после разблокировки, и элемент нельзя перемещать между устройствами

10

kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly

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

11

kSecAttrAccessibleAlwaysThisDeviceOnly

Элемент связки ключей доступен, даже если устройство заблокировано, и элемент нельзя перемещать между устройствами

Таблица 2. Ключи классов защиты элементов связки ключей

Заметим, что половина ключей классов защиты связки ключей имеет постфикс “ThisDeviceOnly”. Дело в том, что в iOS 5 появилась возможность перемещать элементы связки ключей с одного устройства на другое. Элементы, которые имеют класс защиты с постфиксом “ThisDeviceOnly” дополнительно защищаются UID устройства, и поэтому на другом устройстве их просто не получится расшифровать.
Каждый элемент связки ключей имеет следующую структуру (начиная с iOS 5):

Рисунок 4. Структура элемента связки ключей

access group: группа доступа, т.е. приложения, процессы, которые могут получить доступ к элементу связки ключей;

  • metadata: служебная информация, такая как время создания, последнего обновления элемента;
  • SHA1(attributes): каждая запись в базе данных содержит хеш атрибутов безопасности (т.е. тех параметры приложений, которые нужно хранить в безопасности) для более быстрого поиска по базе и для того, чтобы лишний раз не расшифровывать атрибуты;
  • DATA: непосредственно защищаемые данные
  • version: номер версии элемента связки ключей;
  • class: класс защиты элемента связки ключей;
  • wrapped per-item key: для каждого элемента генерируется отдельный ключ, “ключ элемента”, данное поле содержит ключ элемента, зашифрованный на соответствующем ключе класса защиты элементов связки ключей;
  • encrypted attributes + GMAC: аттрибуты хранятся в виде словаря и шифруются алгоритмом AES-128 в режиме GCM. Также во время шифрования для обеспечения целостности атрибутов вычисляется тэг GMAC.

Сумки с ключами

(Слева от абзаца 5_dollars.png) Все ключи классов защиты объединяются в еще одну сущность под названием “сумка с ключами” (Keybag). Всего существует 4 разновидности сумок с ключами: Системная сумка с ключами (System Keybag), Резервная сумка с ключами (Backup Keybag), Депонированная сумка с ключами (Escrow Keybag), Резервная сумка с ключами iCloud (iCloud Backup Keybag). Все сумки имеют одинаковую структуру, которая представлена на Рисунке 5:

Рисунок 5. Структура сумки с ключами

  • Header: заголовок, имеет следующие поля:
    • Version: номер версии; для iOS 5 установлен в 3;
    • Type: тип сумки (системная, резервная, депонированная или резервная iCloud);
    • Keybag UUID: уникальный идентификатор сумки с ключами;
    • HMAC: тэг HMAC для проверки целостности сумки.
  • Class keys list: записи о ключах классов защиты. Каждая запись имеет следующие поля:
    • Key UUID: уникальный идентификатор ключа;
    • Class: идентификатор класса защиты;
    • Wrapping type: способ шифрования ключа класса защиты;
    • Wrapped class key: зашифрованный ключ класса защиты
    • Public key (if any): открытый ключ для ассиметричных классов защиты (например, для класса защиты NSFileProtectionCompleteUnlessOpen)

Теперь рассмотрим, какие функции выполняет каждая сумка в отдельности.

Системная сумка с ключами. Системная сумка хранится непосредственно на устройстве в файле /private/var/keybags/systembag.kb. Файл системной сумки зашифрован на ключе BAG1, который, как уже известно, находится в Effaceable Storage. Нужно отметить, что после каждой смены пароля меняется и ключ BAG1. После расшифровки файла мы получим системную сумку с ключами, но она будет находиться в заблокированном состоянии, то есть все ключи классов защиты в сумке по-прежнему будут зашифрованы. Каждый ключ зашифрован одним из трех способов: либо только на ключе UID, либо только на парольном ключе, либо одновременно на парольном ключи и на UID. За конкретный тип шифрования отвечает поле Wrapping type.

Рисунок 6. Разблокировка системной сумки с ключами

В шифровании ключей классов защиты элементов связки ключей “…ThisDeviceOnly” всегда участвует ключ UID, для того чтобы на другом устройстве эти ключи расшифровать бы не получилось.

Резервная сумка с ключами. Каждый раз, когда пользователь делает резервную копию устройства в iTunes, на компьютере пользователя создается резервная сумка с ключами. Ключи классов защиты в резервной сумке отличаются от ключей классов защиты в системной сумке, поэтому все файлы бэкапа перешифровываются на новых ключах. Файлы бэкапа шифруются, конечно же, алгоритмом AES 256 в режиме CBC на уникальном ключе и нулевом IV.

Всего возможно два вида бэкапов: обычный и зашифрованный. Различия между ними следующие:

  • в простых бэкапах ключи элементов связки ключей всех классов защиты зашифрованы на ключе 0x835, и, следовательно, восстановить их можно только на оригинальном устройстве;
  • в зашифрованных бэкапах пользователь при резервном копировании вводит специальный пароль. Этот пароль 10 000 раз прогоняется через функцию PBKDF2 (заметим, что в отличие от вычисления обычного пароля UID здесь не используется) в результате чего получается парольный ключ резервной копии. Все ключи классов защиты перемещаемых элементов связки ключей (с идентификаторами с 6 по 8) зашифровываются только на парольном ключе резервной копии, а ключи классов защиты элементов связки ключей “…ThisDeviceOnly” (идентификаторы с 9 по 11) зашифровываются одновременно на ключе 0x835 и на парольном ключе резервной копии.

Согласно такой схеме резервного копирования элементы связки ключей “…ThisDeviceOnly” перебросить с одного устройства на другое никак не получится, а перемещаемые элементы связки ключей можно, простите за тавтологию, переместить только в зашифрованном бэкапе.
Депонированная сумка с ключами. Депонированная сумка позволяет синхронизированному устройству (например, компьютеру, на котором установлен iTunes) разблокировать устройство с iOS, не требуя каждый раз пароля от пользователя. Когда устройство подключается к компьютеру, iTunes просит пользователя ввести пароль. После правильного ввода пароля создается депонированная сумка (ключи классов защиты в ней точно такие же, как и в системной сумке) и сохраняется на компьютере. Депонированная сумка зашифрована на 256-битном случайно сгенерированном ключе. Ключ, в свою очередь, хранится в файле на устройстве в папке /private/var/root/Library/Lockdown/escrow_records. Файл имеет класс защиты NSFileProtectionCompleteUntilFirstUserAuthentication.

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

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

Рисунок 7. Иерархия ключей

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

В заключение статьи опишем возможные атаки на механизм защиты данных

Атаки на механизм защиты данных

Допустим, нарушитель все-таки хочет извлечь конфиденциальную информацию из устройства пользователя. Нарушителю может потребоваться файл целиком (например, какой-нибудь сверхсекретный документ), или какие-либо атрибуты безопасности приложений (Wi-Fi пароль, сертификаты, закрытые ключи приложений и.т.п.). В первом случае необходимо знать ключ EMF, а также соответствующий ключ класса защиты данных. Ключ EMF зашифрован на ключе 0x89B, который, в свою очередь, вычислен на основе UID. Для шифрования ключей классов защиты данных используются ключи BAG1, UID и/или парольный ключ. Во втором случае элементы связки ключей зашифрованы на соответствующих ключах классов защиты элементов связки ключей, и для их (ключей классов защиты) расшифровки также необходимо знать ключи BAG1, UID и/или парольный ключ.

Следует сказать, что на данный момент известных способов извлечь аппаратные ключи UID и GID не существует. Но не все так плохо. Специально для программно-технической экспертизы устройств с iOS компания Sogeti Labs выпустила пакет утилит, позволяющих извлечь практически все ключи (кроме аппаратных) из устройства. Ключи можно прочитать, благодаря пропатчиванию службы ядра IOAESAccelerator. Именно эта служба при загрузке ядра вычисляет ключи 0x835, 0x89A и 0x89B (см. Рисунок 1), а зная их, можно получить ключи Dkey, EMF и BAG1 (BAG1 вообще хранится незашифрованным). Для пропатчивания на устройстве, безусловно, должен быть сделан jailbreak. Код утилит от Sogeti Labs открыт, и при желании их легко можно найти в Интернете.

Таким образом, обычно всё упирается в знание парольного ключа, т.е. пароля. Ниже описано несколько возможных способов извлечения конфиденциальной информации. Тривиальный случай, когда нарушитель завладел устройством без пароля, рассматривать не будем.
Случай 1: Нарушитель имеет физический доступ к устройству с паролем. В таком случае, если пароль состоит из 4 цифр, то можно за разумное время перебрать все возможные пароли, разблокировать устройство и получить полный доступ к информации пользователя.

Меры противодействия:

  • Установить более сложный пароль;
  • Использовать опцию ”Стереть содержимое и настройки устройства после N неудачных попыток ввода пароля” (стереть ключ EMF).

Случай 2: Эксплуатация Депонированной сумки с ключами. Как известно ключи классов защиты из депонированной сумки ничем не отличаются от ключей в системной сумке. Если нарушитель будет иметь доступ к устройству и компьютеру пользователя, то он сможет извлечь из устройства ключ, на котором зашифрована депонированная сумка (подбор 256-битного ключа займет достаточно много времени), расшифровать сумку и извлечь все ключи классов защиты. В результате нарушитель получит доступ некоторым данным и атрибутам безопасности.

Меры противодействия:

  • Ограничить доступ к компьютеру, на котором хранится Депонированная сумка с ключами.

Случай 3: Эксплуатация обычного бэкапа. В обычных бэкапах все ключи классов защиты элементов связки ключей зашифрованы на ключе 0x835. Следовательно, имея доступ к компьютеру с бэкапом и устройству пользователя, можно с помощью утилит Sogeti Labs извлечь ключ 0x835 и расшифровать все элементы связки ключей из бэкапа.

Меры противодействия:

  • Ограничить доступ к компьютеру c бэкапами устройства;
  • Использовать зашифрованные бэкапы.

Случай 4: Эксплуатация зашифрованного бэкапа. В отличие от предыдущего способа часть ключей сейчас (с 6 по 8) зашифровано на парольном ключе резервной копии, а другая часть (с 9 по 11) на парольном ключе резервной копии и ключе 0x835. Если пароль резервной копии достаточно слабый, то его можно подобрать, а дальнейшие действия ничем не отличаются от предыдущего способа.

Меры противодействия:

  • Ограничить доступ к компьютеру c бэкапами устройства;
  • Использовать более сложный пароль.

Но не стоит думать, что достаточно сложный пароль будет панацеей от всех атак. Даже самый стойкий пароль не устоит перед социальной инженерией или внедрением вируса в устройства (при условии, что на устройстве сделан jailbreak).

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

Основные источники

1. http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf
2. http://theiphonewiki.com/wiki/
3.http://ensiwiki.ensimag.fr/images/4/4d/4MMSR-2011-2012-student_seminar-iPhone_data_protection_in_depth_-_Jean-Baptiste_Bedrune,_Jean_Sigwald_-_HITB_Amsterdam_2011.pdf
4. http://www.slideshare.net/andrey.belenko/ios-forensics-overcoming-iphone-data-protection
5. http://code.google.com/p/iphone-dataprotection/wiki/EncryptionKeys
6. www.exploit-db.com/download_pdf/19767/
7. http://code.google.com/p/iphone-dataprotection/wiki/iTunesBackups

 

 

Устали от того, что Интернет знает о вас все?

Присоединяйтесь к нам и станьте невидимыми!