Nand память что это iphone

Нас часто спрашивают, существует ли возможность заменить NAND-память Айфона или Айпада, увеличить ее объем? Отвечаем, да, это возможно. С помощью профессионального сервисного оборудования и при участии опытного инженера — такая процедура успешно реализуется. Давайте рассмотрим случаи, когда стоит воспользоваться услугой замены памяти.

Когда нужна замена flash-памяти iPhone и iPad?

Основных причин, по сути, всего две:

• Чипы памяти повредились. Это может произойти как от естественного износа, так и по причине попадания в устройство влаги, механических воздействий. В результате гаджет не загружается, уходит в режим восстановления DFU, выдает ошибки 9, 14, 4013 и 4014. Перепрошивка может временно устранить неисправность, но для надежного ремонта необходима замена микросхем.
• Не хватает объема встроенной памяти. Если вы приобрели девайс с небольшой емкостью накопителя, то со временем можете столкнуться с ее нехваткой. Конечно, можно купить устройство с большим объемом, либо же заказать увеличение памяти на iPhone, iPad в нашем сервисном центре Apple Pro Москва.

При установке нового модуля NAND-памяти, необходимо помнить, что ее можно увеличить только до емкости поддерживаемой устройством. Например, на iPhone 8, возможно увеличить объем с 64 ГБ до 256 ГБ, но не больше.

Как происходит замена модуля памяти на iPhone

В данном случае, мы кратко опишем процедуру замены NAND-чипа на смартфоне Apple, хотя она идентична и для планшетов. Процесс работы условно разделен на такие этапы:

1. Диагностика устройства. Инженер тщательно осматривает и тестирует телефон на предмет механических повреждений и последствий залития жидкостью. Если все в порядке, может быть принято решение о замене памяти.
2. Смартфон разбирается. Снимается дисплей, отключается батарея, демонтируется материнская плата.
3. Деталь подготавливается к работе. Очищается заводской компаунд.
4. На профессиональной паяльной станции чип NAND-памяти выпаивается. Процедура проводится очень осторожно, с соблюдением температурных режимов.
5. На программаторе новый чип перепрошивается, в него помещается информация со старого модуля. Это необходимо для того, чтобы устройство «приняло» новый модуль и корректно работало с ним.
6. После перепрограммирования, память тестируется, она должна без ошибок читать и записывать данные.
7. Новая память припаивается на место с помощью специального трафарета для BGA-пайки.
8. Устройство еще раз тестируется и собирается в обратной последовательности. Перед финальной сборкой устанавливается специальная водозащитная проклейка для обеспечения герметичности.
9. Готовый iPhone с увеличенным объемом хранилища вручается счастливому владельцу с гарантией.

Заказать замену памяти iPhone, увеличение объема в Москве

Обратитесь в наш сервисный центр Apple Pro для профессионального ремонта вашего смартфона. Мы быстро и качественно заменим флеш-память, увеличим ее емкость, проведем перепрошивку. На все услуги распространяется гарантия. Ждем вас!

Источник

Неофициальное расширение памяти iPhone или Китайская победа над Американским маркетингом

Давным-давно, когда iPhone в России стоил дорого, многие покупали залоченные на AT&T айфоны с ибей, используя прокси-сим (гевейку) для анлока. В это время начался переход на iPhone 4, где способ с повышением модема до iPad’овского (06.15.00) не работал, последним софтовым анлоком был 01.59.00 (iOS 4.0), а обновление BaseBand требовало покупки новой гевейки. Вплоть до iOS 5.0, где новый модем 04.11.08 превратил множество устройств в iPod. Именно с этого момента расцвел этот удивительный китайский бизнес.
Под катом небольшая история от 2011 до наших дней с картинками.

Впрочем, залоченные «огрызки» покупали во всем мире, ввиду того, что Apple не продавала официально-разлоченные устройства в первые дни продаж, вынуждая оформлять устройство в контракт. Да и география продаж первой волны покрывала не так уж много стран и новинка могла дойти гораздо дольше посылки из США.
Изначально это была услуга по замене микросхемы модема и флеш памяти модема на новую, после чего записывался новый IMEI, затем менялся серийный номер в микросхеме устройства. Услуга стоила 150$.

Техническая часть:
На заводе Foxconn, где собирают яблочную продукцию, используются специальные диагностические прошивки. Я уже говорил о них тут, а также готовлю продолжение.

На фото отладочный bootchain для iPhone 4

Вызывается она из recovery (iboot) при помощи команды diags. После ее исполнения экран устройства становится пурпурным. Но если ввести специальную команду, можно вывести данное меню.

Сам кабель для iPhone 5+
Общение с программой diags происходит только через serial порт, который присутствует в 30 и 8 пиновых разъемах.
Существует внушительный список ее команд

2014 год
Еще в 2013 году появилась функция Activation Lock, позволяющая превратить устройство в «кирпич», до тех пор, пока не введен AppleID и пароль хозяина устройства. Данный способ начался применяться для разблокировки оных (ведь смена IMEI+SN гарантировано снимало блокировку), однако, прибыль с продаж iPhone 4 упала ввиду морального устаревания аппарата. От отчаяния начали появляться способы аппаратного «анлока» ipad, позволяющая установить на модель cellular прошивку от wifi версии, таким образом избегая блокировки. В то время активно велись опыты по записи пустых «болванок» с новым серийным номером для разблокировки ipad wifi и ipod touch.

2015 год
Китайцы начали разрабатывать это еще в 2012 году, однако, завершить удалось только сейчас. Сотрудник Foxconn проносит материнскую плату iPhone 6 на завод и прошивает диагностическую прошивку. В разрыв между NAND и платой ставится «каретка», позволяющая осуществлять горячее переключение bga NAND микросхемы.
Происходит это так: устанавливается nand с прошивкой, затем через dev bootchain загружается программа diags в озу, после чего происходит горячая смена микросхемы и производится изменение серийного номера на заданный.
Само устройство выглядит так:

Купить их можно даже на алиэкспрессе, как и «болванки» NAND.
Таким хитрым образом удается увеличивать память до 128 и даже до 256 гб (правда один чип обойдется в 800 юаней и продается в ограниченных количествах)
На последок видео сего процесса:

Впрочем, история еще не закончилась. Она происходит прямо сейчас, но ввиду экономических проблем в РФ, этот бизнес пока не прижился. К слову, оборудование стоит

$800, что в пересчете по курсу «курильщика» — 64к рублей + болванки памяти.

Источник

Низкоуровневая программно-техническая экспертиза iOS

В данном посте мы опишем, как получить образ NAND и использовать FTL-метаданные для восстановления удаленных файлов на устройствах, использующих процессор A4.

Механизмы шифрования и защиты данных файловой системы iOS теперь хорошо документированы и поддерживаются многими утилитами ПТЭ (программно-технической экспертизы или forensics). В качестве основной области хранения данных iOS-устройства используют NAND flash-память, но создание физических образов обычно имеет отношение к «dd image» логических разделов. Уровень трансляции Flash в iOS для текущих устройств имеет программную основу (реализован в iBoot и ядре), что означает, что CPU имеет прямой доступ к сырой NAND-памяти. В данном посте мы опишем, как получить образ NAND и использовать FTL-метаданные для восстановления удаленных файлов на устройствах, использующих процессор A4. Информация, представленная здесь, основана на серьезной работе по реверс-инжинирингу, выполненной командой iDroid/openiBoot.

Чтение NAND-памяти

iOS-устройства используют один или несколько идентичных чипов, адресуемых номером CE («chip enable»). Фактические параметры геометрии (число CE, число блоков на CE, число страниц на блок, размер страниц и резервной области) зависят от модели устройства и общей емкости хранилища. Физический адрес составляется из CE-номера чипа и физического номера страницы (PPN) на этом чипе.

Из-за ограничений NAND в операционных системах распространены механизмы трансляции (FTL), которые позволяют использовать NAND-память как обычное блочное устройство, оптимизируя при этом ее производительность и срок службы. Главная цель FTL заключается в уменьшении операций стирания и распределения их по всем блокам. С точки зрения ПТЭ, интересным побочным эффектом здесь является то, что при перезаписи логического блока на уровне блочного устройства старые данные на физическом уровне обычно не стираются сразу. Поэтому при поиске удаленных данных работа с сырым образом NAND может быть очень полезна.

Можно прочитать сырые данные NAND с помощью openiBoot, но передача данных по USB на данный момент довольно медленна, что делает этот способ непрактичным для выгрузки содержимого всей Flash-памяти.

Начиная с iOS 3 на ram-дисках Apple iOS можно найти программу ioflashstoragetool. Данная утилита может производить множество низкоуровневых операций, касающихся flash-хранилища и может читать сырые NAND-страницы и резервные области (не производя никакого рода дешифрования). Данная функциональность предоставлялась сервисом ядра IOFlashControllerUserClient.

В iOS 5 большая часть функций, предоставлявшихся данным интерфейсом IOKit, была убрана. Чтобы создать дамп посредством этого интерфейса, мы можем загрузить ram-диск с помощью более старой, четвертой версии ядра iOS. Это отлично работает, однако в таком случае мы потеряем способность использовать имеющийся код ядра для атаки перебором более новых связок ключей iOS 5. Чтобы выгрузить NAND под пятой версией ядра iOS, мы заново реализовали часть функции IOFlashControllerUserClient::externalMethod, ответственной за функциональность чтения. Когда наш инструмент выгрузки запускается под пятой версией ядра iOS, он замещает данную функцию той, что обрабатывает селектор kIOFlashControllerReadPage.

Кроме того, мы можем установить флаг загрузки nand-disable-driver, чтобы предотвратить высокоуровневый доступ к NAND и гарантировать, что ее содержимое не изменится в ходе получения.

Уровень преобразования Flash в iOS

Virtual Flash Layer (VFL) ответственен за переназначение bad-блоков и представление NAND, не содержащее ошибок, для FTL-слоя. VFL-слой знает физическую геометрию и транслирует виртуальные номера страниц, используемые FTL, в физические адреса (номер CE + номер физической страницы).

Слой FTL оперирует над VFL и предоставляет операционной системе интерфейс блочного устройства. Он транслирует номера логических страниц блочного устройства (LPN) в виртуальные номера страниц, занимается wear leveling и сборкой мусора в для блоков, содержащих устаревшие данные. На устройствах, поддерживающих аппаратное шифрование, все страницы, содержащие структуры данных, связанные с VFL и FTL, зашифрованы статическим ключом метаданных.

В различных версиях iOS использовались следующие варианты подсистем FTL:

• iOS 1.x и 2.x : «legacy» FTL/VFL
• iOS >= 3 : YaFTL / VSVFL
• Начиная с iOS 4.1, некоторые из новых устройств оснащены PPN (Perfect Page New) NAND, которая использует особый PPNFTL.

PPN-устройства имеют свой собственный контроллер с прошивкой, которая может быть изменена через интерфейс IOFlashControllerUserClient, но большая часть работы FTL похоже все еще выполняется программно – с помощью YaFTL поверх нового PPNVFL.

На основании кода openiBoot мы написали минимальную read-only реализацию YaFTL/VSVFL на Питоне, чтобы получить возможность просматривать образы NAND как блочные устройства. В сочетании с реализацией HFS+ на Питоне она позволяет извлечение логических разделов для получения эквивалента dd-image. Далее нам нужно понять механизмы YaFTL, чтобы воспользоваться дополнительными данными, доступными в образе NAND.

YaFTL

Следующий рисунок обобщает процесс преобразования YaFTL:

В ходе нормальной работы в каждый момент лишь один суперблок каждого типа является «открытым»: страницы записываются последовательно в манере log-block. Когда текущий суперблок заполнен, YaFTL находит пустой суперблок для продолжения процесса. старевшие пользовательские данные стираются только в процессе работы сборщика мусора.

Последние страницы индексного и пользовательского суперблоков используются для хранения BTOC (таблица содержимого блока). Для пользовательских блоков BTOC перечисляет логические номера страниц, хранимые в этих блоках. В индексном блоке BTOC хранит первые логические номера страниц, на которые указывает каждая из индексных страниц.

Восстановление FTL производится при загрузке, если FTL не был должным образом отмонтирован (после kernel panic или жесткой перезагрузки, например) и контекстная информация не была зафиксирована на flash-носителе. Функции восстановления FTL приходится исследовать все блоки (используя BTOC для ускорения процесса), чтобы восстановить корректный контекст.

Метаданные резервной области

Поле lpn позволяет FTL-коду проверять корректность преобразования при чтении страницы. Оно также используется в ходе процесса восстановления FTL, чтобы обнаруживать страницы в «открытых» суперблоках, которые не имеют BTOC.

В поле usn записывается глобальный порядковый номер обновления во время записи страницы. Этот номер увеличивается каждый раз при фиксации новой версии контекста FTL или когда суперблок заполнен и происходит открытие нового суперблока. Данное поле позволяет легко сортировать суперблоки по возрасту.

«Отбеливание» метаданных

Признак того, что отбеливание метаданных включено, находится в поле флагов специальной страницы NANDDRIVERSIGN.

Восстановление удаленных файлов

Когда таблица поиска построена, мы можем легко обратиться ко всем доступным версиям заданной логической страницы. Чтобы восстановить удаленные данные на разделе мы реализовали простой алгоритм, похожий на метод вырезания данных из журнала HFS:

• Перечислить все идентификаторы файла на разделе данных в его текущем состоянии: мы используем обычную трансляцию FTL и EMF-ключ для расшифровки данных.
• Получить местоположение текущего файла каталога и файла аттрибутов (диапазоны LBA)
• Для каждого LBA, принадлежащего файлу каталога
  • Для каждой версии текущего LBA
    • Считать страницу для данной версии, расшифровать ее с помощью EMF-ключа
    • найти в странице записи файла каталога, файловые идентификаторы которых не присутствуют в текущем списке файловых идентификаторов (удаленные файлы)
• Повторить тот же процесс с файлом атрибутов для нахождения ключей шифрования для ранее обнаруженных удаленных файлов (расширенные атрибуты cprotect)
• для каждого найденного удаленного файла
  • Пробежать в цикле все возможные ключи шифрования и версии первого логического блока, пока расшифрованное содержимое не совпадет с магическим числом (обычная магия файловых заголовков). См. функцию isDecryptedCorrectly (которую можно улучшить).
  • если найдены ключ шифрования и USN первого блока, считать следующие блоки файлов, используя данный USN как ссылку. Другой метод – начать считывать страницы, начиная с первого найденного блока файлов, следуя «порядку записи» FTL: читать до конца суперблока, затем продолжить в следующем с более высоким значением USN, и так, пока не будут найдены все блоки файла.

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

Один из файлов, который было бы интересно восстановить – системное хранилище ключей. Если атакующий смог получить доступ к первой версии системного хранилища ключей (без установленного пароля, сразу после восстановления прошивки), он мог бы затем получить доступ ко всем ключам классов без необходимости в атаке пароля пользователя. Однако, эксплуатировать более старые версии хранилища ключей невозможно из-за второго слоя шифрования: полезная нагрузка systembag.kb шифруется ключом BAG1, который хранится в уничтожаемой области и принимает случайное значение каждый раз, когда на диск записывается новая версия файла (когда пользователь меняет свой пароль). Данный механизм, очевидно, был разработан для предотвращения подобных атак, как объяснено в выступлении «Securing application data» с Apple WWDC 2010 (Сессия 209).

Уязвимость стирания в iOS 3.x

Инструменты получения содержимого NAND и вырезания данных теперь доступны в репозитории iphone-dataprotection. Дополнительные подробности также доступны на вики. Наконец, большое спасибо Патрику Вилдту и команде openiBoot за их работу над iOS FTL, которая позволила нам создать эти инструменты.

Источник