Ios файловая система: Роль файловой системы Apple — Служба поддержки Apple (RU)

Как получить доступ к файлам iPhone с помощью монтирования диска

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

В этой статье мы рассмотрим следующие различные подходы:

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

PTP: доступ к фотографиям, видео и данным камеры как к креплению на диск

iOS автоматически представляет современные устройства как камеры, когда они подключены через USB. При этом используется протокол передачи изображений (PTP), который является довольно ограниченной системой, позволяющей копировать фотографии туда и обратно. Вы, вероятно, узнаете папки DCIM , в которых обычно появляются фотографии.

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

Доступ к фотографиям и данным приложения через AFC через iTunes

В базе знаний Apple есть статья, в которой описывается, как управлять общим обменом файлами с iTunes .

Доступ к данным приложения через USB с помощью FUSE

FUSE — это система, которая позволяет пользователям монтировать диски на своих компьютерах под управлением Windows или Mac без необходимости вносить изменения на уровне администратора в свои системы. FUSE расшифровывается как « файловая система в пользовательском пространстве » и доступна в различных формах на большинстве платформ. Сам FUSE является уровнем абстракции, поскольку он не является технологией, напрямую связывающейся с устройством или источником данных: для этого обычно используется другой подход. В случае установки iPhone в качестве накопителя FUSE будет связываться с iPhone по другому протоколу: SSH, AFC / AFC2, PTP или WebDAV. В Windows часто используется популярная файловая система Dokan в пользовательском режиме , а в macOS osxfuse популярна.

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

Использование FUSE для MacOS

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

Прежде всего, давайте найдем UDID вашего устройства. Вы можете сделать это с помощью бесплатной версии iPhone Backup Extractor , с помощью команды lsusb или с помощью ioreg -p IOUSB -l -w 0 . Запустите iPhone Backup Extractor, когда ваше устройство подключено, выберите свое устройство и выберите вкладку «Информация». Вы увидите UDID показанный в разделе «Идентификаторы оборудования»:

Данные устройства отображаются в iPhone Backup Extractor

Далее, давайте подготовим FUSE для macOS:

$ brew tap homebrew/cask
$ brew cask install osxfuse
==> Caveats
To install and/or use osxfuse you may need to enable their kernel extension in
  System Preferences → Security & Privacy → General
For more information refer to vendor documentation or the Apple Technical Note:
  https://developer.apple.com/library/content/technotes/tn2459/_index.html
You must reboot for the installation of osxfuse to take effect.

И давайте установим ifuse , который является кодом, который может взаимодействовать с устройствами iOS через FUSE:

$ brew install ifuse

С установленным ifuse можно смонтировать ваш iPhone или iPad, используя UDID мы получили ранее:

$ mkdir ~/iphone
$ ifuse ~/iphone --udid 000000000000000000000000

Это позволит смонтировать ваш iPhone как диск на вашем компьютере. Если вы хотите пойти дальше и вникнуть в дополнительные данные, этот пост суперпользователя довольно удобен, и аналогично этот пост описывает использование инструмента usbmuxd.

Устранение ошибок, с которыми вы можете столкнуться

ifuse might complain: Invalid device UDID specified, length needs to be 40 characters. Starting with the iPhone X, Apple changed UDIDs to use 24 bytes and a dash (-) instead of the old 40-byte format.

Если вам не Failed to connect to lockdownd service on the device. Try again. If it still fails try rebooting your device. убедитесь, что ваше устройство подключено и не отображает диалоговое окно «Доверяйте этому компьютеру». Вы должны будете одобрить это сначала. Если после этого вы получите ERROR: Device 000000000000000000000000 returned unhandled error code -13 вам необходимо отключить и повторно подключить устройство.

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

Если вы собираетесь монтировать только одно устройство iOS, вы можете просто запустить ifuse ~/iphone .

Нужно использовать предварительную версию

usbmuxd?

usbmuxd isn’t frequently updated, so occasionally when a new version of iOS is released, it lacks support. To fix that, you can install the latest development version of it as below:

brew unlink usbmuxd
brew install --HEAD usbmuxd
brew unlink libimobiledevice
brew install --HEAD libimobiledevice
brew cask uninstall osxfuse
brew cask install osxfuse idevicepair

Доступ к данным приложения через USB с помощью FUSE на взломанном устройстве

Инструкции точно такие же, как указано выше. С взломанным устройством вы сразу увидите больше данных. Аккуратно, а?

Использование сервера Filza WebDAV для доступа к корневому файлу iOS

На взломанном устройстве iOS можно установить приложение файлового менеджера с именем Filza через Cydia. В настройках Fileza вы можете включить режим сервера WebDAV . Это обеспечивает довольно простой интерфейс для доступа других устройств к вашему устройству iOS, хотя и крайне небезопасно. WebDAV — это очень общий механизм работы с веб-данными, и существует множество клиентов, которые могут получить к ним доступ, включая веб-интерфейс, встроенный в Filza. Подключитесь к своему устройству через веб-браузер, и вы увидите интерфейс. Легко.

Использование AFC2 для доступа к файлам iOS через USB

Что такое AFC2?

AFC означает « Apple File Conduit », собственный механизм Apple для передачи данных с устройства iOS на хост-компьютер. AFC работает на каждом устройстве iOS, но заблокирован только для предоставления доступа к ограниченному набору данных. «AFC2» — это прозвище, данное ряду инструментов, созданных сообществом джейлбрейков, эмулирующих AFC, но предоставляющих доступ ко всему устройству. Последняя реализация AFC2 была разработана Cannathea и доступна на GitHub .

AFC2 можно установить из Cydia, и после установки клиент AFC сможет полностью просматривать устройство.

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

До выпуска iOS 8 было несколько плагинов Cydia для взломанных устройств, которые при подключении заставляли iPhone представлять себя как USB-накопитель . Увы, в современных версиях iOS они больше не поддерживаются.

Восстановление удаленных файлов с подключенного устройства iOS

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

Руководство по безопасности Apple iOS кратко описывает это на стр. 17 в «обзоре архитектуры»:

Каждый раз, когда создается файл в разделе данных, Data Protection создает новый 256-битный ключ (ключ «на файл») и передает его аппаратному механизму AES, который использует ключ для шифрования файла при его записи на флэш-память в режиме AES-XTS. На устройствах с SoC A7, S2 или S3 используется AES-CBC. Вектор инициализации вычисляется со смещением блока в файл, зашифрованный с помощью хэша SHA-1 ключа для каждого файла.

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

Бонус: монтирование компьютера под управлением Windows с вашего iPhone или iPad

В iOS 13 появилась поддержка SMB для iOS. Это позволяет пользователям получать удаленный доступ к дискам на компьютерах Windows. Вот как это работает:

1. Найдите IP-адрес вашего компьютера с Windows. Команда ipconfig должна сказать вам это.

2. На компьютере Windows щелкните правой кнопкой мыши папку, которой вы хотите поделиться, и выберите « Properties → « Sharing → « Advanced sharing Sharing . Нажмите «Поделиться этой папкой».

3. На вкладке «Общий доступ» выберите « Share... , затем в раскрывающемся меню выберите свою учетную запись, добавьте ее и убедитесь, что у нее есть разрешения «Чтение / запись». Нажмите «Поделиться» и «Применить» и закройте окно.

4. На вашем устройстве iOS откройте приложение Apple «Файлы», нажмите «Подключиться к серверу». Введите smb:// а затем IP-адрес вашего ПК. Затем выберите «Зарегистрированный пользователь» и введите имя и пароль своей учетной записи Windows.

После этого ваш диск Windows должен появиться на устройстве iOS.

В чем замысел файловой системы APFS

Если новая файловая система успела чем-то огорчить вас, имена виновных в этом будут вам интересны. Это iPhone, iPod touch и iPad. Они слишком хорошо продавались, объёмы продаж стремительно росли, а у Apple появились свободные средства, в особо крупных размерах. Представьте себя на месте Apple: вдруг, без каких-либо последствий, вы можете позволить себе все.

Зачем на самом деле нужна APFS?

Они справились с соблазнами, и повели себя разумно. Может быть даже слишком. Жить было бы намного интереснее если бы они придумали не только лучшие в мире и самые успешные “умные часы”. Стив мог бы рискнуть и замахнуться на что-то нереальное, но осиротевшее руководство компании слишком хорошо помнило откуда пришли эти деньги, и сотни предложений “снизу”, после долгих обсуждений и экспериментов, не принимались. Рискованно. А вы на их месте вели бы себя как-то иначе? Тем не менее, некоторые из этих предложений, после длительных дискуссий и обсуждений, отвергнуть не удалось. Одно из этих предложений касалось разработки новой, современной, файловой системы для iOS. А не отвергли его по целому ряду причин.

Предлагаем подписаться на наш канал в «Яндекс.Дзен». Там вы сможете найти эксклюзивные материалы, которых нет на сайте.

Во-первых, файловая система в iOS живет и работает в уникальных (по сравнению с её сестрой в macOS) условиях. Пользователи напрямую с ней не соприкасаются. Она скрыта от них, её будто бы вообще нет (в СМИ сообщалось об её отсутствии). Во-вторых, в любом iOS-устройстве – одно-единственное хранилище данных, и оно несменяемое. А внешние хранилища данных к iOS-устройствам в те времена подключить было невозможно, и не из-за того что в Apple работали неумехи – это было принципиально: внешний накопитель, будь это флэшка, SSD или RAID – переносчик инфекции и заразы. Были еще и “в-третьих”, и “в-четвертых”, но не стану вас утомлять. С момента начала разработки до презентации новой файловой системы разработчикам (и предоставления им её бета-версии) должно было пройти два или два с половиной года. Файловую систему для iOS, за это время, можно и нужно было вылизать до ослепительного блеска.

Совместимость с macOS? Напрямую с файловой системой iOS macOS дела не имела, лишь через специальное программное обеспечение. Которое взаимодействовало с файловой системой iOS через API, которые решили сохранить нетронутыми. Кроме того, файловая система в iOS и без этого была существенно другой, отличной от HFS+ в macOS. Только API были один-в-один, но все остальное было, фактически, разработано заново. Когда Mac OS 10.5 “Леопард” втискивали в мобильное устройство, переделывать пришлось многое. Сначала операционную систему избавили от всего лишнего. Значительную часть функций файловой системы просто отрезали. Когда этого оказалось мало, высушивали блок за блоком, многие из них переписали заново, упрощая везде где это было возможно. Можно считать что один раз её уже переписали.

Все Mac с Catalina работают на APFS

О том что файловая система iOS радикально отличалась от той что использовалась в Mac’ах, мало кто знает. Разве что про чувствительность HFS+ в iOS к регистру в именах файлов и других объектов файловой системы. То есть, в HFS+/iOS строчные и заглавные варианты той же буквы считаются разными, и файлы “File.txt” и “file.txt” запросто могут находиться в одной директории. macOS нечувствительна к регистру в именах объектов файловой системы, для обычных пользователей это оптимальный вариант. В прошлом, в варианте файловой системы для Mac OS X Server, при установке операционной системы можно было включить или выключить чувствительность к регистру. Если бы это было необходимо, сделать файловую систему Mac’ов чувствительной к регистру было бы легче легкого. Извините за уклонение от темы, но в сети очень часто укоряют Apple за эту самую нечувствительность – и винят в этом низкую квалификацию её инженеров.

В марте 2017 года APFS дебютировала в iOS, и все прошло без сучка и задоринки. То для чего её задумывали и для чего разрабатывали, дотошно и тщательно, получилось на все сто. Высший балл. Но в процессе разработки вводные поменялись. Задание усложнили.

APFS впервые была представлена на WWDC 2017

На каком этапе это произошло – неизвестно. Сначала было принято решение о внедрении новой файловой системы в производных от iOS операционных системах. Это было просто, и протестов у команды вызвать не могло. Потом, скорее всего на каком-то очень нервном и неприятном для большинства участников совещании высшего руководства, у кого-то из топ-менеджеров, возникла эта мысль: “одна компания – одна файловая система”. Так и решили: в macOS, к тому же сроку, тоже должна быть внедрена новая файловая система. Современная, 64-битная, оптимизированная для работы с флэш-памятью, совместимая со всеми другими используемыми её типами.

Администрация не пожалела средств на расширение проекта, которому было выделено щедрое дополнительное финансирование, для которого открыли новые вакансии, кроме того в работу вовлекли сотрудников из группы занимавшейся HFS+. Техническое задание требовало от APFS умения работать не только с флэш-памятью, но и с жесткими дисками, и с приводами Fusion, и много чего еще. Все это за очень короткое время, под давлением администрации, в спешке. Впрочем, даже в этих условиях у них почти получилось, и все не так плохо, как могло бы быть. Но ни тщательной проработки деталей, ни продуманных до тонкостей решений, увы, не видно. APFS исполнилось два года, можно считать её версией 2.0, до версии 3.1, когда она должна “состояться”, остался еще год.

О проблемах APFS расскажу в другой раз.

iOS 13macOS CatalinaОбновление iOS и устройств AppleОперационные системы Apple

Как получить локальную файловую систему в стиле Android на iPhone или iPad

НЕКЕШЕРОВАННЫЙ КОНТЕНТ

С iOS 8 у вашего iPhone или iPad теперь может быть локальная файловая система, как у пользователей Android. Храните файлы для использования в автономном режиме, получайте к ним доступ в любом обновленном приложении и сохраняйте файлы непосредственно в файловой системе из других приложений.

Более того, некоторые из этих решений позволяют легко получить доступ к файлам Mac или ПК на вашем устройстве. Вы также можете использовать этот трюк для доступа к файлам через FTP, SFTP, WebDAV и другие протоколы в любом приложении.

Как это устроено

СВЯЗАННЫЕ С:

Как использовать расширения приложений на iPhone или iPad с iOS 8

iOS 8 включает

точка расширения поставщика документов / хранилища

. Любое стороннее приложение может подключиться к нему. По умолчанию это позволяет вам получать доступ к файлам из iCloud Drive и сохранять файлы в iCloud Drive из любого приложения, поддерживающего новое средство выбора документов. Сторонние сервисы облачного хранения, такие как Dropbox, Google Drive и Microsoft OneDrive, также могут подключаться к этому месту, что позволяет вам использовать выбранную вами службу облачного хранения как первоклассный гражданин в любом приложении. Приложения не нужно обновлять для поддержки каждой отдельной службы — они просто должны поддерживать стандартную систему расширений iOS 8.

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

даже пользователям Android требуется стороннее приложение, чтобы по-настоящему раскрыть мощь файловой системы

.

Файлы, которые вы сохраняете в приложении, которые вы можете рассматривать как локальную файловую систему, сохраняются как часть

файлы данных приложения в iOS

.

Загрузите приложение Transmit или Document

СВЯЗАННЫЕ С:

Все, что вам нужно знать об использовании iCloud Drive и библиотеки фотографий iCloud

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

• Документы

  (Бесплатно)
  
  : Приложение Readdle’s Documents отточено и бесплатное. Он предоставляет файловую систему, к которой вы можете получить доступ в любом приложении, а также мощное приложение с поддержкой просмотра различных типов документов и медиафайлов. Он также может синхронизироваться с
  
  iCloud Drive
  
  , Dropbox или Google Диск, что позволяет получить доступ к тому же набору файлов на вашем компьютере и легко копировать файлы в хранилище приложения или из него. Конечно, вся синхронизация необязательна — вы можете просто использовать ее как полностью автономное хранилище файлов. Как и Transmit ниже, он предлагает доступ к серверам WebDAV, FTP и SFTP.
  
  Это бесплатное приложение, вероятно, станет лучшим выбором для большинства людей.

• Передать

  ($10)
  
  : Transmit очень популярен в Mac OS X и теперь предлагает приложение для iOS благодаря новым функциям iOS 8. Transmit предлагает локальную файловую систему, но включает поддержку доступа к серверам хранения FTP, SFTP, WebDAV и Amazon S3. Благодаря системе расширений iOS 8, Transmit, таким образом, может добавить поддержку открытия файлов и сохранения файлов на этих удаленных серверах в любом приложении, которое поддерживает новое средство выбора документов.
  
  Вы даже можете включить SSH / SFTP-сервер на своем Mac, а затем использовать Transmit (или Documents) для доступа к его файловой системе непосредственно из приложений на вашем устройстве iOS. На официальном сайте Transmit есть инструкции. Это приложение стоит 10 долларов, но оно того стоит, если вам действительно нужны эти функции.

Как использовать новую файловую систему

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

Такие приложения предлагают доступ к общему листу, что позволяет легко открывать файлы из приложения файловой системы в другом приложении. Например, в «Документах» вы можете просмотреть файл, нажать кнопку «Поделиться» и нажать «Открыть в». Затем вы можете открыть файл непосредственно в другом приложении на своем устройстве, если это приложение утверждает, что поддерживает этот тип файла.

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

Но основной клей, который заставляет все это работать, — это система расширений iOS 8. Во-первых, убедитесь, что вы используете приложение, которое было обновлено для его поддержки, например Apple Pages или другое приложение iWork. Использование приложения, которое было обновлено для его поддержки, например Apple Pages или другого приложения iWork. Откройте список мест хранения, из которых можно открывать или сохранять файлы, и коснитесь опции «Еще…».

Вы увидите список установленных приложений, предоставляющих хранилища. Включите одно или несколько установленных расширений поставщика хранилища и нажмите Готово.

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

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

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

Кредит изображения:

LWYang на Flickr

Извлечение данных из iPhone без джейлбрейка (iOS 11-12)

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

Для чего нужен джейлбрейк

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

С точки зрения мобильной криминалистики джейлбрейк необходим для того, чтобы получить доступ к защищённым областям хранилища телефона: приватным данным приложений, включая базы данных защищённых чатов, паролям пользователя и маркерам аутентификации для самых разнообразных ресурсов. И если без джейлбрейка эксперту доступна лишь часть данных – та, к которой официально разрешён доступ как разработчиком приложения, так и компанией Apple, — то после установки джейлбрейка становятся доступны абсолютно все данные на смартфоне.

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

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

Доступ к файловой системе и Связке ключей через программу-агента

Список поддерживаемых агентом устройств довольно широк, включая все модели iPhone начиная с iPhone 5s и заканчивая линейкой iPhone Xr, Xs и Xs Max. Поддерживается большинство планшетов iPads, основанных на процессорах соответствующих поколений. Список поддерживаемых версий iOS несколько уже: поддерживаются iOS 11 и 12 всех версий, за исключением iOS 12.3, 12.3.1 и 12.4.1. Оценить совместимость разных способов извлечения данных можно на следующей схеме:

В чём отличия между разными способами извлечения данных?

1. Логическое извлечение: доступ к данным из резервной копии, расшифровка многих записей Связки ключей, извлечение медиа-файлов, некоторых журналов и данных приложений. Работает на всех устройствах и любых версиях iOS, но количество извлекаемых данных ограничено.
2. Работа через джейлбрейк: извлечение файловой системы и расшифровка Связки ключей. Совместимость ограничена моделями устройств и версиями iOS, для которых существует джейлбрейк.
3. Работа с checkra1n/checkm8: извлечение файловой системы и расшифровка Связки ключей. Совместимость ограничена моделями устройств (вплоть до A11, т.е. до iPhone 8/8 Plus/iPhone X включительно) и (на данный момент) версиями iOS3-13.3.1. В то же время этот метод использует аппаратную уязвимость, которую Apple не сможет исправить. Кроме того, доступно частичное извлечение в режиме BFU (до первой разблокировки, если пароль устройства неизвестен).
4. Программа-агент: извлечение файловой системы и расшифровка Связки ключей. Совместимость ограничена моделями устройств (A7-A11) и версиями iOS (11-12, кроме 12.3, 12.3.1, 12.4).

Извлечение файловой системы из iPhone с программой-агентом

Перед тем, как начать работу, потребуется подготовка. Для установки программы-агента на iPhone вам потребуется учётная запись Apple ID, зарегистрированная в программе Apple для разработчиков. Обычный Apple ID использовать для установки программы-агента нельзя.

Для регистрации в программе Apple для разработчиков будет необходимо активировать двухфакторную аутентификацию (если вы не сделали этого ранее). Для установки программы-агента вам потребуется создать пароль приложения; это можно сделать через браузер на странице Apple ID.

Обратите внимание: в программе Apple для разработчиков может быть зарегистрировано до 100 устройств каждого типа (например, 100 телефонов iPhones и 100 планшетов iPads). Вы сможете удалить устройство из вашей учётной записи после того, как закончите с ним работать.

Для извлечения файловой системы и расшифровки Связки ключей проделайте следующие действия.

1. Подключите iPhone к компьютеру. Подтвердите запрос на установление связи (на телефоне может потребоваться ввести код блокировки).
2. Запустите Elcomsoft iOS Forensic Toolkit 5. 30 или более новую версию.
3. В качестве первого шага рекомендуем выполнить логическое извлечение (создание резервной копии, извлечение медиа-файлов и т.д.)
4. Для работы с программой-агентом используйте цифровые команды 1…4.
5. Установка агента на iPhone: команда ‘1’ (Install agent). Вам потребуется ввести логин от Apple ID (напомним, зарегистрированного в программе для разработчиков) и пароль приложения, который вы сгенерировали ранее. Далее введите ‘Team ID’ из учётной записи для разработчиков. После установки агента, запустите приложение-агент на телефоне и оставьте его работать в активном режиме.
6. Дальнейшие шаги похожи на извлечение с использованием джейлбрейка за исключением того, что командой ‘D’ (Disable lock) пользоваться не нужно.
7. Извлечение Связки ключей: команда ‘2’.
8. Создание образа файловой системы: команда ‘3’. Копия файловой системы iPhone будет сохранена на компьютере в архиве в формате TAR.
9. Для удаление программы-агента с iPhone используйте команду ‘4’.

Просмотреть содержимое файловой системы можно посредством Elcomsoft Phone Viewer или альтернативного приложения, поддерживающего формат TAR. Для анализа Связки ключей используйте Elcomsoft Phone Breaker. Для анализа в ручном режиме смонтируйте или распакуйте образ файловой системы (для этого желательно использовать систему на основе UNIX или macOS).

Заключение

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

REFERENCES:

Elcomsoft iOS Forensic Toolkit

Elcomsoft iOS Forensic Toolkit – специализированный инструмент для проведения криминалистического анализа устройств, работающих под управлением Apple iOS. Для анализа доступна вся пользовательская и системная информация, а также зашифрованные данные из системного хранилища (связка ключей).

Официальная страница Elcomsoft iOS Forensic Toolkit »

Файловая система и связка ключей: что, зачем и как

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

Что?

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

Существующие методы отличаются как по уровню сложности, так и объёмом возвращаемых данных. Термин «образ файловой системы» следует воспринимать буквально: в него входят все файлы и папки из устройства, включая структуру каталогов. При извлечении файловой системы можно ограничиться лишь пользовательскими данными, но можно извлечь и полный образ устройства. В полный образ обычно включается и образ системного раздела, что помогает обнаружить следы шпионского или зловредного программного обеспечения, если таковое работало на устройстве. В образ файловой системы входят как данные приложений, так и системные — журналы, история местоположений, данные о близлежащих сотовых вышках, временные файлы и т.п.

Что можно сказать об этом методе в сравнении с альтернативами? Разница существенна; в образе файловой системы содержится заметно больше ценных улик, чем в данных, которые можно извлечь посредством логического анализа (хотя и с ним не всё так просто). В то же время логический анализ зачастую является буквально единственным способом, доступным для того или иного устройства — он работает независимо как от аппаратной платформы, так и от версии операционной системы. Более того, логический анализ доступен не только для iPhone и iPad, но и для таких устройств, как Apple TV или Apple Watch (для них, однако, доступен достаточно ограниченный анализ — собственной службы резервного копирования у этих устройств просто нет).

Зачем?

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

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

Как?

Итак, вы решили извлечь образ файловой системы. Как это сделать? Существует как минимум два способа: с использованием уязвимости загрузчика (эксплойтом checkm8) и посредством агента-экстрактора.

Извлечение через уязвимость загрузчика — идеально чистый, повторяемый и верифицируемый способ добраться до данных, но и самый сложный в использовании. Кроме того, применимость этого метода жёстко ограничена: он работает только для старых устройств, последними из которых стали представители поколения iPhone 8, 8 Plus и iPhone X.

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

Как эти два метода сравнимы между собой? Если отвлечься от вопроса совместимости, сравнение будет выглядеть так:

checkm8

+ работает на любой версии iOS
+ работает без оглядки на ограничения MDM и Экранного времени
+ криминалистически чистый метод
— не работает на современных устройствах
— на некоторых платформах нужно удалить код блокировки экрана, что приводит к утрате части данных

агент-экстрактор

+ работает на любых устройствах, включая современные iPhone 13 Pro Max и даже iPad Pro на процессорах M1
+ не требуется удаление кода блокировки
— криминалистическая чистота не идеальна; минимальные изменения в файловой системе
— совместимость ограничена версиями iOS
— этот метод может не сработать, если устройство управляется MDM
— для работы нужна платная учётная запись в Apple Developer Program

Заключение

Если у вас есть такая возможность — снимите образ файловой системы и расшифруйте связку ключей одним из способов низкоуровневого доступа. Помните: «однокнопочных» решений в криминалистике не существует! Низкоуровневый анализ требует чёткого понимания поставленной цели, инструментов и способов её достижения.

checkm8, EIFT, ios, агент-экстрактор, низкоуровневое извлечение, файловая система

REFERENCES:

Elcomsoft iOS Forensic Toolkit

Elcomsoft iOS Forensic Toolkit – специализированный инструмент для проведения криминалистического анализа устройств, работающих под управлением Apple iOS. Для анализа доступна вся пользовательская и системная информация, а также зашифрованные данные из системного хранилища (связка ключей).

Официальная страница Elcomsoft iOS Forensic Toolkit »

Что такое файловая система Apple (APFS), представленная в iOS 10.3

Перейти к содержанию

Файловые системы — это то, как жесткие диски организуют данные для чтения операционной системой. Каждая операционная система построена для работы с файловой системой. Windows FAT, FAT32 и NTFS. macOS использует HFS +. Apple использует иерархическую файловую систему (HFS) более 30 лет. На WWDC 2016 Apple объявила о намерении обновить эту систему. Они познакомили мир с идеей файловой системы Apple (APFS). Последняя версия iOS 10.3, которая была выпущена всего несколько дней назад, переносит эту новую файловую систему на устройства iOS. Вот все, что вам нужно знать об APFS.

Зачем переходить на APFS?

Вы можете спросить, зачем переходить на новую файловую систему, если уже существует совершенно работоспособная? Операционные системы могут обращаться только к ограниченному объему пространства, то есть к доступному диапазону дат, максимальной длине имени файла и т. Д. Проблема с HFS в том, что он появился в 1985 году. с было в лучшем случае несколько мегабайт. Таким образом, файловая система была оптимизирована для такого объема пространства. Он мог бы вместить диапазон дат от 1904 до 2040 и адрес 2 терабайта пространства. Это было астрономически в 1985 году, сегодня это едва ли нормально. Apple увидела неминуемую гибель HFS и немного улучшила ее, выпустив в 1998 году обновление под названием HFS + для своей ОС 8.1.

Сегодня, однако, развилась не только емкость хранения, но и скорость. С появлением твердотельных накопителей и их развитием (например, M2 SSD) даже обновленная файловая система не оправдала ожиданий. Если мы получаем доступ к молниеносным дискам с использованием методологий, разработанных для компьютеров 20-летней давности, неизбежно возникнут проблемы. Чтобы решить эти проблемы, Apple представляет APFS. Файловая система с закрытым исходным кодом для всех устройств, iPhone, iPad, iPod, Watch, Mac и т. Д. Она в первую очередь предназначена для более эффективного использования SSD и флэш-памяти (которые обычно используются сегодня), а также для повышения безопасности и блокировки взлома.

Как перейти на APFS?

Apple переключит пользователей на новую систему через обновление ОС. Вам действительно не придется ничего делать, кроме обновления ОС. Пользователи iPhone и iPad, обновившиеся до iOS 10.3, уже перешли на новую файловую систему. Пользователям macOS, использующим релизную версию ОС, придется подождать немного дольше. Те, кто использует бета-версию macOS, уже обновлены до APFS.

Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)

Что хорошего в APFS?

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

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

Что делает APFS быстрее?

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

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

APFS лучше подходит для SSD?

Несмотря на то, что люди думают о твердотельных накопителях как о недавнем явлении, это не так. В 70-х они назывались EAROM (электрически изменяемая постоянная память), а первый коммерчески продаваемый твердотельный накопитель в 1976 году назывался Bulk Core! Однако в то время, как и в случае со всеми процессорами и оперативной памятью, доступ ко всему в электронном виде был медленным. Так будет на протяжении более трех десятилетий. Таким образом, даже несмотря на то, что технология существовала, она не считалась приоритетной.

Сегодня большинство платформ Apple текущего поколения (за исключением некоторых Mac Pro) работают с вариантом твердотельного хранилища, микросхемами Flash Storage. Они встроены в платы. Это позволяет сохранить целостность экосистемы (это часть того, как они создали тонкий Macbook Air на несколько лет раньше любого конкурента), а APFS оптимизирует обращение с этим хранилищем.

Например, APFS поддерживает команду TRIM, появившуюся, когда твердотельные накопители стали массовыми. TRIM сообщает операционной системе хоста, какие части диска являются пустыми, т. е. на них больше нет данных. С SSD это происходит мгновенно. Таким образом, люди, которым нравится оставлять свободное место, смогут получить его так же быстро, как только нажмут «Удалить».

Что уникального в APFS?

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

В APFS моментальные снимки создают единую версию всей системы, доступную только для чтения. Это означает, что это всего лишь копия исходных данных, но она не занимает никакого физического пространства. Если вы внесете изменения в исходный файл, снимок займет место для его хранения. Это помогает получить любые исходные копии или отменить любые изменения, которые вы, возможно, захотите. Точно так же, когда вы создаете клон, вы сохраняете компактную копию всей вашей системы (реальные файлы, папки и все такое). Он также начнет занимать место по мере внесения изменений. Это делает хранение очень эффективным по времени.

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

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

Насколько безопасен APFS?

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

Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)

Прокрутить вверх

Основы файловой системы

СледующийПредыдущий

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

APFS — файловая система по умолчанию в macOS, iOS, watchOS и tvOS. APFS заменяет HFS+ в качестве файловой системы по умолчанию для iOS 10. 3 и более поздних версий, а также macOS High Sierra и более поздних версий. macOS дополнительно поддерживает множество других форматов, как описано в разделе «Поддерживаемые файловые системы».

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

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

О файловой системе iOS

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

Стандартные каталоги iOS: местонахождение файлов

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

Эти каталоги контейнеров составляют основное представление файловой системы приложения. На рис. 1-1 показано представление каталога песочницы для приложения.

Рисунок 1-1   Приложение iOS, работающее в собственном каталоге песочницы

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

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

Приложение iOS может создавать дополнительные каталоги в каталогах Documents , Library и tmp . Вы можете сделать это, чтобы лучше организовать файлы в этих местах.

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

Куда вы должны поместить файлы вашего приложения

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

• Поместить данные пользователя в Documents/ . Пользовательские данные обычно включают в себя любые файлы, которые вы, возможно, захотите предоставить пользователю — все, что вы, возможно, захотите, чтобы пользователь создал, импортировал, удалил или отредактировал. Для приложения для рисования пользовательские данные включают в себя любые графические файлы, которые может создать пользователь. Для текстового редактора он включает текстовые файлы. Видео- и аудиоприложения могут даже включать файлы, которые пользователь загрузил для просмотра или прослушивания позже.

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

• Помните, что файлы в Documents/ и Application Support/ резервируются по умолчанию. Вы можете исключить файлы из резервной копии, вызвав -[NSURL setResourceValue:forKey:error:] с помощью ключа NSURLIsExcludedFromBackupKey . Любой файл, который можно воссоздать или загрузить, должен быть исключен из резервной копии. Это особенно важно для больших медиафайлов. Если ваше приложение загружает видео- или аудиофайлы, убедитесь, что они не включены в резервную копию.

• Поместите временные данные в каталог tmp/. К временным данным относятся любые данные, которые вам не нужно сохранять в течение длительного периода времени. Не забудьте удалить эти файлы, когда вы закончите с ними, чтобы они не продолжали занимать место на устройстве пользователя. Система будет периодически удалять эти файлы, когда ваше приложение не запущено; поэтому вы не можете полагаться на то, что эти файлы сохранятся после завершения работы вашего приложения.

• Поместите файлы кэша данных в каталог Library/Caches/. Данные кэша можно использовать для любых данных, которые должны храниться дольше, чем временные данные, но не так долго, как файл поддержки. Вообще говоря, приложению не требуются данные кэша для правильной работы, но оно может использовать данные кэша для повышения производительности. Примеры данных кеша включают (но не ограничиваются) файлы кеша базы данных и временный загружаемый контент. Обратите внимание, что система может удалить Caches/, чтобы освободить место на диске, поэтому ваше приложение должно иметь возможность повторно создавать или загружать эти файлы по мере необходимости.

О файловой системе macOS

Файловая система macOS предназначена для компьютеров Mac, где и пользователи, и программное обеспечение имеют доступ к файловой системе. Пользователи получают доступ к файловой системе напрямую через Finder, который представляет ориентированное на пользователя представление файловой системы, скрывая или переименовывая некоторые файлы и каталоги. Приложения получают доступ к файловой системе с помощью системных интерфейсов, которые отображают всю файловую систему точно так, как она отображается на диске.

Домены определяют размещение файлов

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

• Пользовательский домен содержит ресурсы, специфичные для пользователей, которые входят в систему. Хотя технически он охватывает всех пользователей, этот домен отражает только домашний каталог текущего пользователя во время выполнения. Домашние каталоги пользователей могут находиться на загрузочном томе компьютера (в каталоге /Users ) или на сетевом томе. Каждый пользователь (независимо от привилегий) имеет доступ и контроль над файлами в своем домашнем каталоге.

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

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

• Системный домен содержит системное программное обеспечение, установленное Apple. Ресурсы в системном домене требуются системе для работы. Пользователи не могут добавлять, удалять или изменять элементы в этом домене.

На рис. 1-2 показано, как локальный, системный и пользовательский домены сопоставляются с локальной файловой системой установки macOS. (Сетевой домен не показан, но во многом похож на локальный домен.) На этом рисунке показаны видимые каталоги, которые может видеть пользователь. В зависимости от системы пользователя другие каталоги могут быть видны или некоторые из показанных здесь могут быть скрыты.

Рисунок 1-2   Локальная файловая система macOS

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

Стандартные каталоги macOS: местонахождение файлов

Независимо от того, предоставлены ли они системой или созданы вашим приложением, каждый файл имеет свое место в macOS. В Табл. 1-2 перечислены некоторые каталоги верхнего уровня в установке macOS и типы содержимого, которое содержится в каждом из них.

Важно:  Файлы в каталогах пользователя Documents и Desktop должны отражать только те документы, которые пользователь создал и с которыми работает напрямую. Точно так же каталоги мультимедиа должны содержать только файлы мультимедиа пользователя. Эти каталоги никогда не должны использоваться для хранения файлов данных, которые ваше приложение создает и которыми управляет автоматически. Если вам нужно место для хранения автоматически сгенерированных файлов, используйте Библиотека Каталог, специально предназначенный для этой цели. Информацию о том, куда поместить файлы в каталог библиотеки, см. в разделе «Каталог библиотеки, в котором хранятся файлы, относящиеся к приложениям».

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

Контейнеры файлов приложений macOS в песочнице

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

Для получения дополнительной информации см. Руководство по проектированию песочницы приложения .

Скрытые файлы и каталоги: упрощение работы пользователя

Чтобы упростить работу пользователей, Finder и некоторые специальные пользовательские интерфейсы (например, панели «Открыть» и «Сохранить») скрывают многие файлы и каталоги, которые пользователь никогда не должен должны использовать. Многие из скрытых элементов являются специфическими для системы или приложения ресурсами, к которым пользователи не могут (или не должны) обращаться напрямую. Среди файлов и каталогов, которые скрыты, следующие:

• Точечные каталоги и файлы. Любой файл или каталог, имя которого начинается с символа точки ( . ), автоматически скрывается. Это соглашение взято из UNIX, которая использовала его для сокрытия системных сценариев и других специальных типов файлов и каталогов. Два специальных каталога в этой категории — . и .. каталоги, которые являются ссылками на текущий и родительский каталоги соответственно.

• Каталоги для UNIX. Каталоги этой категории унаследованы от традиционных установок UNIX. Они являются важной частью уровня BSD системы, но более полезны для разработчиков программного обеспечения, чем для конечных пользователей. Некоторые из наиболее важных скрытых каталогов включают:

  • /bin — Содержит необходимые двоичные файлы командной строки. Обычно эти двоичные файлы выполняются из сценариев командной строки.

  • /dev — Содержит основные файлы устройств, такие как точки подключения для подключенного оборудования.

  • /etc — Содержит файлы конфигурации для конкретного хоста.

  • /sbin — Содержит основные двоичные файлы системы.

  • /tmp — Содержит временные файлы, созданные приложениями и системой.

  • /usr — Содержит несущественные двоичные файлы командной строки, библиотеки, заголовочные файлы и другие данные.

  • /var — Содержит файлы журналов и другие файлы с переменным содержимым. (Файлы журнала обычно просматриваются с помощью консольного приложения.)

• Явно скрытые файлы и каталоги. Finder может скрывать определенные файлы или каталоги, к которым пользователь не должен обращаться напрямую. Наиболее ярким примером этого является каталог /Volumes , который содержит подкаталог для каждого подключенного диска в локальной файловой системе из командной строки. (Finder предоставляет другой пользовательский интерфейс для доступа к локальным дискам.) В macOS 10.7 и более поздних версиях Finder также скрывает ~/Library — то есть каталог Library , расположенный в домашнем каталоге пользователя.

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

Хотя Finder и другие системные интерфейсы скрывают файлы и каталоги от пользователя, интерфейсы Cocoa, такие как NSFileManager , не отфильтровывают файлы или каталоги, которые обычно невидимы для пользователей. Таким образом, код, использующий эти интерфейсы, теоретически имеет полное представление о файловой системе и ее содержимом. (Конечно, процесс действительно имеет доступ только к тем файлам и каталогам, для которых у него есть соответствующие разрешения.)

Файлы и каталоги могут иметь альтернативные имена

В некоторых случаях Finder предоставляет пользователям имена файлов или каталогов, которые не соответствуют фактическим именам, отображаемым в файловой системе. Эти имена известны как отображаемых имен и используются только Finder и определенными системными компонентами (например, панелями «Открыть» и «Сохранить») при представлении пользователю информации о файлах и каталогах. Отображаемые имена улучшают взаимодействие с пользователем, представляя пользователю контент в более удобной форме. Например, macOS использует отображаемые имена в следующих ситуациях:

• Локализованные имена. Система предоставляет локализованные имена для многих системных каталогов, таких как Приложения , Библиотека , Музыка , Фильмы . Аналогичным образом приложение может предоставлять локализованные имена для себя и для любых каталогов, которые оно создает.

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

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

Важно:  Ваш код не должен позволять пользователям напрямую изменять отображаемые имена. Если вы хотите, чтобы пользователь указал имя файла, используйте панель «Сохранить».

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

В каталоге библиотеки хранятся файлы приложений

В каталоге библиотеки приложения и другие модули кода хранят свои пользовательские файлы данных. Независимо от того, пишете ли вы код для iOS или macOS, важно понимать структуру каталога Library . Вы используете этот каталог для хранения файлов данных, кешей, ресурсов, настроек и даже пользовательских данных в некоторых конкретных ситуациях.

В системе имеется несколько каталогов Library , но лишь немногие из них могут понадобиться вашему коду:

• Библиотека в текущем домашнем каталоге — это версия каталога, который вы используете чаще всего, поскольку он содержит все пользовательские файлы. В iOS библиотека размещается внутри пакета данных приложений. В macOS это каталог песочницы приложения или домашний каталог текущего пользователя (если приложение не находится в песочнице).

• /Library (только macOS) — приложения, которые совместно используют ресурсы между пользователями, хранят эти ресурсы в этой версии Библиотека каталог. Приложениям в песочнице не разрешено использовать этот каталог.

• /System/Library (только macOS) — этот каталог зарезервирован для использования Apple.

После выбора используемой версии каталога библиотеки вам все равно нужно знать, где хранить файлы. Сам каталог библиотеки содержит несколько подкаталогов, которые подразделяют содержимое конкретного приложения на несколько хорошо известных категорий. В Таблице 1-3 перечислены наиболее распространенные подкаталоги, которые вы можете использовать. Хотя каталоги библиотеки в macOS содержат намного больше подкаталогов, чем перечисленные, большинство из них используются только системой. Однако, если вам нужен более полный список подкаталогов, см. раздел Сведения о каталоге библиотеки macOS.

Контейнер хранилища файлов iCloud

iCloud предоставляет структурированную систему для хранения файлов для приложений, использующих iCloud:

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

• Внутри каждого каталога контейнера файлы разделены на «документы» и данные. Каждый файл или пакет файлов, расположенный в подкаталоге Documents (или одном из его подкаталогов), представляется пользователю (через пользовательский интерфейс iCloud в macOS и iOS) как отдельный документ, который можно удалить по отдельности. Все, что не находится в Documents или в одном из его подкаталогов, обрабатывается как данные и отображается как одна запись в пользовательском интерфейсе iCloud.

Документы, которые пользователь создает и просматривает в пользовательском интерфейсе приложения, например браузеры документов в Pages, Numbers и Keynote, должны храниться в Документы каталог. Другим примером файлов, которые могут находиться в каталоге Documents , являются сохраненные игры, опять же потому, что они представляют собой то, что приложение потенциально может предоставить какой-то метод для выбора.

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

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

Контейнеры iCloud также позволяют хранить пары «ключ-значение», к которым можно легко получить доступ без необходимости создавать формат документа.

Как система определяет тип содержимого в файле

Существует два основных метода определения типа содержимого в файле:

Универсальный идентификатор типа — это строка, однозначно идентифицирующая класс объектов, которые считаются имеющими «тип». UTI предоставляют согласованные идентификаторы для данных, которые все приложения и службы могут распознавать и на которые могут полагаться. Кроме того, они более гибкие, чем большинство других методов, поскольку их можно использовать для представления любых типов данных, а не только файлов и каталогов. Примеры ИМП включают:

• public.text — Открытый тип, идентифицирующий текстовые данные.

• public.jpeg — Общедоступный тип, идентифицирующий данные изображения JPEG.

• com.apple.bundle — тип Apple, который идентифицирует каталог пакета.

• com.apple.application-bundle — тип Apple, который идентифицирует связанное приложение.

Если для указания типов файлов доступен интерфейс на основе UTI, вы должны предпочесть этот интерфейс всем другим. Многие интерфейсы macOS позволяют указывать идентификаторы UTI, соответствующие файлам или каталогам, с которыми вы хотите работать. Например, на панели «Открыть» вы можете использовать UTI в качестве файловых фильтров и ограничить типы файлов, которые выбирает пользователь, теми, которые может обрабатывать ваше приложение. Несколько классов AppKit, в том числе NSDocument , NSPasteboard и NSImage , поддерживают UTI. В iOS UTI используются только для указания типов картона.

Одним из способов, которым система определяет UTI для данного файла, является просмотр его расширения имени файла. Расширение имени файла — это строка символов, добавленная в конец файла и отделенная от основного имени файла точкой. Каждая уникальная строка символов идентифицирует файл определенного типа. Например, .strings 9Расширение 0051 идентифицирует файл ресурсов с локализуемыми строковыми данными, а расширение .png идентифицирует файл с данными изображения в формате переносимой сетевой графики.

Примечание:  Поскольку символы точки являются допустимыми символами в именах файлов macOS и iOS, только символы после последней точки в имени файла считаются частью расширения имени файла. Все, что находится слева от последней точки, считается частью самого имени файла.

Если ваше приложение определяет пользовательские форматы файлов, вы должны зарегистрировать эти форматы и любые связанные с ними расширения имен файлов в вашем приложении.0050 Файл Info.plist . Ключ CFBundleDocumentTypes указывает форматы файлов, которые ваше приложение распознает и может открывать. Записи для любых пользовательских форматов файлов должны включать как расширение имени файла, так и UTI, соответствующие содержимому файла. Система использует эту информацию для направления файлов соответствующего типа в ваше приложение.

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

Безопасность: защита создаваемых файлов

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

Общие сведения о методах безопасного кодирования при работе с файлами см. в разделе 9.0005 Руководство по безопасному кодированию .

Песочницы ограничивают распространение повреждений

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

Разработчикам, пишущим приложения для macOS 10.7 и более поздних версий, рекомендуется помещать свои приложения в изолированные программные среды для повышения безопасности. Разработчикам приложений для iOS не нужно явно помещать свое приложение в песочницу, поскольку система делает это за них автоматически во время установки.

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

Разрешения и списки контроля доступа управляют всем доступом к файлам

Доступ к файлам и каталогам регулируется сочетанием списков управления доступом (ACL) и разрешений BSD. Списки управления доступом — это набор элементов управления, которые точно определяют, что можно и что нельзя делать с файлом или каталогом и кем. С помощью списков управления доступом вы можете предоставлять отдельным пользователям разные уровни доступа к данному файлу или каталогу. Напротив, разрешения BSD позволяют вам предоставлять доступ только трем классам пользователей: владельцу файла, одной указанной вами группе пользователей и всем пользователям. См. Обзор безопасности для получения дополнительной информации.

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

Поскольку приложения iOS всегда работают в изолированной программной среде, система назначает определенные списки управления доступом и разрешения для файлов, созданных каждым приложением. Однако приложения macOS могут использовать Identity Services для управления списками контроля доступа к файлам, к которым у них есть доступ. Сведения о том, как использовать Identity Services (и платформу совместной работы), см. в разделе 9.0005 Руководство по программированию Identity Services .

Файлы могут быть зашифрованы на диске

И macOS, и iOS поддерживают шифрование файлов на диске:

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

• macOS. Пользователи могут зашифровать содержимое тома с помощью приложения «Дисковая утилита». (Они также могут зашифровать только загрузочный том из системных настроек «Безопасность и конфиденциальность».) Содержимое зашифрованного диска доступно приложениям только во время работы компьютера. Когда пользователь переводит компьютер в спящий режим или выключает его, ключи дешифрования уничтожаются, чтобы предотвратить несанкционированный доступ к содержимому диска.

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

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

Синхронизация обеспечивает надежность кода, связанного с файлами

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

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

• Координаторы файлов. В macOS 10.7 и более поздних версиях файловые координаторы — это способ включить поддержку тонкой синхронизации непосредственно в объекты вашего приложения; см. Роль координаторов файлов и докладчиков.

• FSEvents. В macOS 10.5 и более поздних версиях события файловой системы позволяют отслеживать изменения в каталоге или его содержимом; см. Руководство по программированию событий файловой системы .

Файлы, параллелизм и безопасность потоков

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

Даже если вы используете потокобезопасный интерфейс для манипулирования файлом, проблемы могут возникнуть, когда несколько потоков или несколько процессов пытаются воздействовать на один и тот же файл. Хотя существуют средства защиты, предотвращающие одновременное изменение файла несколькими клиентами, эти средства защиты не всегда гарантируют эксклюзивный доступ к файлу в любое время. (Вы также не должны пытаться предотвратить доступ других процессов к общим файлам.) Чтобы ваш код знал об изменениях, внесенных в общие файлы, используйте файловые координаторы для управления доступом к этим файлам. Дополнительные сведения о координаторах файлов см. в разделе Роль координаторов файлов и докладчиков 9.0003

СледующийПредыдущий

Авторские права © Apple Inc., 2018. Все права защищены. Условия использования | Политика конфиденциальности | Обновлено: 09.04.2018

Понимание файловой системы iOS | by Lucideus

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

Вы можете войти в файловую систему iOS тремя способами, описанными в предыдущей статье. Есть три способа:

• Использование приложения с графическим интерфейсом (например, Filza File Manager) на iPhone.

• Использование приложения, созданного из командной строки (например, MTerminal) на iPhone.

• Использование клиента SSH на компьютере в той же сети.

Из трех способов самый простой способ войти в файловую систему — через приложение, такое как Filza File Manager. С другой стороны, использование SSH для входа в файловую систему было бы наиболее подходящим способом познакомиться с файловой системой iOS.

Используя вышеупомянутые методы, вы можете войти в файловую систему и просмотреть файлы и каталоги в ней. Сначала мы рассмотрим начальную точку файловой системы, то есть «/», также называемую корневым каталогом. Содержимое «/» в iOS 11.0 показано на снимке экрана ниже.

Вот некоторые из основных моментов:

• На взломанном устройстве все файлы и каталоги в разделе «/» имеют доступ для чтения и записи.
• Каталоги, расположенные непосредственно под ‘/’, могут быть классифицированы в соответствии с их именем следующим образом:
• Каталоги, аналогичные файловой системе MacOS: Applications, Library, System, User.
• Каталоги, общие для файловой системы UNIX: bin, boot, dev и т. д., lib, mnt, sbin, tmp, usr, var.
• Каталоги, уникальные для файловой системы iOS: private, cores.
• Другие каталоги в зависимости от используемого инструмента взлома.
• Некоторые каталоги являются символическими ссылками на другие каталоги под знаком «/».
• Символические ссылки обычно указывают на какой-либо каталог, который прямо или косвенно находится в каталоге /private.
• Также может существовать файл с именем «.file». Похоже, это не имеет смысла, но его можно использовать для проверки целостности файлов, чтобы убедиться, что файловая система не повреждена.

Каталог по умолчанию, в который вы попадаете при доступе к файловой системе iOS через командную строку, — «/var/root». Этот каталог является символической ссылкой на путь /private/var/root. Он называется домашним каталогом пользователя root, так как запуск команды «cd ~» через командную строку позволяет пользователю root перейти в этот конкретный каталог.

Важные наблюдения, которые следует отметить для файлов и папок в этом каталоге:

• По умолчанию он содержит два каталога — Application Support и Library
• Каталог /var/root является корневым каталогом 'root ' пользователь.

По умолчанию переменная PATH содержит каталоги /bin, /sbin, /usr/bin, /usr/sbin. Все эти каталоги содержат различные важные двоичные файлы для файловой системы iOS.

Вы можете использовать команду which из каталога /usr/bin, чтобы узнать путь к различным важным двоичным файлам в вашей системе. Вот некоторые из примеров:

Приложение iOS имеет доступ к следующим каталогам/компонентам для обмена данными:

Каталог предустановленных приложений iOS и приложений для джейлбрейка

/Applications/$app_name. app

Каталог приложений App Store

/var/containers/Bundle/Application/$uuid

Каталог данных

/var/mobile/Containers/Data/Application/$uuid

Общий каталог данных

/var/mobile/containers/shared/appgroup/$ uuid

IOS Клавичная кошачка

/var/keychains/keychain-2.db

Uipasteboard

бухга предварительно установленные приложения для iOS и родные приложения для джейлбрейка.

Примечание: Не рекомендуется удалять каталоги приложений, поскольку после удаления их нельзя будет переустановить.

• В этом каталоге хранятся приложения iOS, которые вы устанавливаете из App Store, такие как игры, инструменты, редактор фото/видео и т. д.
• Путь к этому каталогу: /var/containers/Bundle/Application/{uuid}, где uuid — это UUID приложения. UUID уникален для каждого приложения и всегда меняется при новой установке этого приложения.
• Файлы внутри каталога определенного приложения вместе образуют то, что на самом деле является файлом IPA этого приложения.

• В этом каталоге хранятся локальные данные всех приложений.
• Путь к каталогу данных: /var/mobile/Containers/Data/Application/{uuid}, где uuid — это UUID приложения. UUID уникален для каждого приложения и всегда меняется при новой установке этого приложения.
• Файлы в каталоге приложения содержат локальное хранилище данных приложения и могут быть доступны только этому конкретному приложению на устройстве без взлома из-за песочницы, предоставляемой iOS.

• В этом каталоге хранятся данные, совместно используемые группой приложений или их собственными расширениями.
• Путь к каталогу данных: /var/mobile/Containers/Shared/AppGroup/{uuid}, где uuid — это UUID группы приложений.
• Все установленные приложения могут не иметь записи в общем каталоге данных.

• Это файл базы данных SQLite, который содержит элементы, хранящиеся в связке ключей iOS для любого приложения, включая пароли WiFi, Apple ID iTunes и т. д.
• Файл находится в каталоге /var/Keychains/
• Имя файла — keychain-2.db
• Файл состоит из всех записей цепочки для ключей в зашифрованном виде.

• Он содержит текст, включая специальные символы, такие как смайлики, которые скопированы из текстового источника, такого как веб-сайт или документ.
• Доступ к нему можно получить с помощью cycript.

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

Ссылки на изображения: - https://images.google.com/

Подробная информация о файловой системе iOS (и как стать лучшим, используя критическое мышление) – iOS Brain

Вы когда-нибудь задумывались, как все эти люди разобрались, как манипулировать файловой системой iOS в своих приложениях? По какой-то странной причине Apple никогда не предоставляла хорошо организованной документации по этому вопросу. Вот что я чувствую: «Задай простой вопрос и получи тупой и слишком сложный ответ». Существует множество статей и руководств, в том числе моя собственная, в которых показаны примеры кода Objective-C или Swift для управления файловой системой iOS, и большая часть кода выглядит в основном одинаково. Тем не менее, этот код обманчиво сложен, его часто недооценивают и редко хорошо объясняют или понимают.

Где все нашли этот шаблонный код? Из простого наблюдения я обнаружил, что во многих случаях разработчики используют методологию копирования и вставки, т. е. ищут несколько ключевых слов в веб-поисковике, находят нужный код на таких сайтах, как StackOverflow или каком-нибудь блоге, копируют его, вставляют. его в проект Xcode и бейте его, пока он не заработает. Я не хочу, чтобы вы чувствовали себя так после прочтения моих руководств.

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

ВВЕДЕНИЕ

Кто из вас работал с изолированной файловой системой, которая поставляется с вашими приложениями для iOS? Заметьте, я сказал «прилагается», потому что независимо от того, используете вы его или нет, он есть. Если вы не воспользовались файловой системой iOS, есть большая вероятность, что, если вы посвятили себя разработке приложений для iOS в долгосрочной перспективе, вы в конечном итоге начнете использовать ее раньше, чем позже. Я широко использовал локальную файловую систему iOS.

ИСТОРИЧЕСКАЯ СПРАВКА

Итак, как я понял, как использовать локальную файловую систему iOS? Документация Apple по ней не самая лучшая, но, прочитав ее несколько раз, поэкспериментировав с собственным кодом (в основном, с Objective-C при изучении его на раннем этапе) и пообщавшись с другими разработчиками, я пришел к пониманию файловой системы iOS и написал свой собственный стандартный код для его использования.

Как я понял, что вы должны хранить файлы, которые будут напрямую , представленный вашим пользователям и/или управляемый ими в каталоге Documents вашего приложения? Откуда я взял код, который я показал вам в моем руководстве по файловой системе iOS для определения пути к каталогу Documents приложения, как показано здесь?

Получить каталог документов

func documentDirectoryURL() -> URL
{
вернуть FileManager. default.urls(для: .documentDirectory, в: .userDomainMask).сначала!
//возврат FileManager.default.urls(для: .documentDirectory, в: .userDomainMask)[0]
}

Обратите внимание, что в моем методе две строки кода, но одна из них закомментирована. Обе линии обеспечивают одинаковую функциональность. Я показал вам две альтернативы, то есть

Получить каталог документов

вернуть FileManager.default.urls(для: .documentDirectory, в: .userDomainMask).сначала!

… и …

Получить каталог документов

return FileManager.default.urls(для: .documentDirectory, в: .userDomainMask)[0]

по историческим причинам. В те времена, когда был доступен только Objective-C, я получал самый первый элемент массива, обращаясь к его первому или 0-му (нулевому) элементу. Как правило, это наиболее часто используемый метод для получения каталога Documents приложения.

Теперь, когда у нас есть Swift, я могу получить самый первый элемент массива, используя свойство first instance типа коллекции Array .

КАК Я ПОНЯЛ

Когда мне впервые представили приложение, требующее использования файловой системы iOS, я вошел в свою учетную запись Apple Developer и направился к документации разработчика или «базе знаний», если хотите. Сначала я нашел и прочитал «Руководство по программированию файловой системы», особенно разделы «Стандартные каталоги iOS: где находятся файлы», «Где вы должны разместить файлы своего приложения» и «Поиск элементов в стандартных каталогах».

Определение «стандартного каталога»

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

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

Поиск «стандартных каталогов»

При «Поиске элементов в стандартных каталогах» Apple дает совет:

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

Метод URLsForDirectory:inDomains: класса NSFileManager возвращает местоположение каталога, упакованное в объект NSURL . Каталог для поиска — это константа NSSearchPathDirectory . Эти константы предоставляют URL-адреса домашнего каталога пользователя, а также большинства стандартных каталогов.
Функция NSSearchPathForDirectoriesInDomains ведет себя как метод URLsForDirectory:inDomains: , но возвращает расположение каталога в виде пути на основе строки. Используйте 9Вместо этого используется метод 0050 URLsForDirectory:inDomains: . …

В обсуждении Apple «Поиск элементов в стандартных каталогах» показан пример кода Objective-C для поиска каталога поддержки приложений вашего приложения, предназначенного «для любых файлов, которые не являются файлами пользовательских данных» (см. «Листинг 2-2 Создание URL-адреса элемента в каталоге поддержки приложений"):

Получить каталог поддержки приложений

Объектив-C

- (NSURL*)applicationDataDirectory {
NSFileManager* sharedFM = [NSFileManager defaultManager];
NSArray* возможныхURLs = [sharedFM URLsForDirectory:NSApplicationSupportDirectory
inDomains:NSUserDomainMask];
NSURL* appSupportDir = ноль;
NSURL* appDirectory = ноль;

если ([количество возможных URL] >= 1) {
// Использовать первый каталог (если возвращено несколько)
appSupportDir = [possibleURLs objectAtIndex:0];
}

// Если существует действующий каталог поддержки приложений, добавьте
// идентификатор пакета приложения, чтобы указать конечный каталог.
если (appSupportDir) {
NSString* appBundleID = [[NSBundle mainBundle] bundleIdentifier];
appDirectory = [appSupportDir URLByAppendingPathComponent:appBundleID];
}

вернуть appDirectory;
}

Подождите минутку… Мы просто искали каталог Application Support . Почему мы, возможно, получаем несколько версий?! Хм?

Пример кода говорит вам, что если какие-либо каталоги найдены, может быть несколько . Хотя это кажется тупым и запутанным, это результат обеспечения кросс-портабельности с macOS. Я расширю тему предоставления унифицированного API для macOS и iOS, о чем Apple уже некоторое время говорила, позже в этом руководстве.

Обратите внимание, что версия Objective-C общего NSFileManager имеет URLsForDirectory:inDomains: 9Метод 0051. Он полностью соответствует методу Swift FileManager для URL-адресов (for:in:) .

Случай перечисления Objective-C NSSearchPathDirectory для NSApplicationSupportDirectory соответствует случаю перечисления Swift FileManager.SearchPathDirectory для applicationSupportDirectory .

Теперь вам должно быть более чем очевидно, что вы запрашиваете NSURL или URL в интересующий «стандартный каталог» — Documents/, Library/, tmp/ — указав экземпляр NSSearchPathDirectory или FileManager.SearchPathDirectory , при использовании Objective-C или Swift соответственно .

Что это за «домен»?

Обсуждение и пример кода, показанные в документации Apple, мало говорят о параметре inDomains в URLsForDirectory:inDomains: и, конечно же, не упоминает Swift-эквивалент параметра в параметре в методе urls(for:in:) . Это пример ситуации, когда вы должны быть хорошим читателем и исследователем.

В то время как документация Apple очень подробно описывает macOS , поскольку она относится к «Домены определяют размещение файлов», обсуждение той же темы для iOS практически отсутствует. Возможно, это ключевая фраза, которую вы хотите рассмотреть:

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

Подумай об этом. Такое устройство, как iPhone или iPad, обычно считается предназначенным для одного человека (одного пользователя). На этих устройствах одновременно может быть зарегистрирован только один Apple ID. Таким образом, мы можем быть уверены, что на iOS мы всегда будем использовать Константа NSUserDomainMask для аргумента inDomains при вызове метода URLsForDirectory:inDomains: в Objective-C и использовании константы .userDomainMask для аргумента в при вызове URL-адресов (для: in:) Метод в Swift.

Зачем перебирать несколько объектов

URL , чтобы найти «стандартный каталог»?

Почему методы iOS, такие как URLsForDirectory:inDomains: , возвращают массив из объектов NSURL , когда большинство разработчиков просто ищут один NSURL ? (Большинство из нас сейчас используют Swift, поэтому мы ищем один URL-адрес .) Заявленная цель метода заключается в том, что он «возвращает массив URL-адресов для указанного общего каталога в запрошенных доменах» и подпись или объявление метода Objective-C:

Метод Objective-C URLsForDirectory

Объектив-C

- (NSArray *)URLsForDirectory:(NSSearchPathDirectory)каталог
inDomains:(NSSearchPathDomainMask)domainMask;

Эквивалент Swift:

Метод URL-адресов Swift

func urls (для каталога: FileManager. SearchPathDirectory,
в domainMask: FileManager.SearchPathDomainMask) -> [URL]

Документация для метода «Возвращаемое значение» продолжается, заявляя: «Каталоги упорядочены в соответствии с порядком констант маски домена, с элементами в пользовательском домене первыми и элементами в системном домене последними».

Сравните это с моим кодом Swift для получения «стандартного» Документы каталог. Я указываю на пример получения каталога Documents , потому что, по моему опыту, при первой установке и использовании приложения iOS, исключая вмешательство с вашей стороны, Documents , скорее всего, будет единственным каталогом , созданным для вас, когда вы установите свое приложение и, следовательно, единственное, доступное вам изначально.

Пример кода Apple Objective-C для «Поиска элементов в стандартных каталогах» вызывает URLsForDirectory:inDomains: и возвращает NSArray . Обратите внимание на комментарий в примере кода Apple «Использовать первый каталог (если возвращено несколько)», который выглядит следующим образом:

Возвращено более одного NSURL.

Объектив-C

...
если ([количество возможных URL] >= 1) {
// Использовать первый каталог (если возвращено несколько)
appSupportDir = [possibleURLs objectAtIndex:0];
}
...

Всякий раз, когда я вызываю эквивалент Swift, urls(for:in:) , я делаю то же самое и «Использую первый каталог (если возвращается несколько)», как в моей версии кода, ориентированной на протокол:

Вызов метода URL-адресов Swift для получения документов

func documentDirectoryURL() -> URL
{
вернуть FileManager. default.urls(для: .documentDirectory, в: .userDomainMask).сначала!
//возврат FileManager.default.urls(для: .documentDirectory, в: .userDomainMask)[0]
}

Вы можете спросить: «Зачем принудительно разворачивать вызов для получения первого элемента массива из объектов URL ?» Хороший вопрос и вот ответ.

Сначала я использую ! , потому что я никогда не сталкивался с приложением без каталога Documents . Но , я не знаю никаких гарантий, что все будет работать идеально во время разработки приложения. Что делать, если что-то пойдет не так во время установки приложения и нет Каталог документов создан для вашего приложения? Метод urls(for:in:) может вернуть то, что он обещал, экземпляр [URL] , инициализированный, но, возможно, пустой, поэтому первый элемент [URL] может быть нулевым, если массив пуст. , по определению:

Первый метод коллекции Swift

вар первый: элемент? {получить}

Итак, теперь я использую ярлык и принудительно разворачиваю необязательный первый , чтобы сократить объем кода, который вам нужно прочитать. Ниже вы увидите, что я проверяю на наличие ошибок значение nil в first .

Законные причины для перебора нескольких объектов

URL для поиска «стандартного каталога»

Помните, я упоминал кросс-портабельность между iOS и macOS? Если я создам проект Xcode, ориентированный на macOS и использующий Cocoa App , я могу скомпилировать и запустить следующий код Swift на моем MacBook Pro:

Найти все корневые каталоги пользователей в macOS

пусть allUserDirectories = FileManager. default.urls (для: .userDirectory, в: .allDomainsMask)
для каталога в allUserDirectories
{
печать("\(каталог.путь)")
}

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

Список всех домашних каталогов пользователей macOS

MS DOS

/Пользователи
/Сеть/Пользователи

Я напечатал путь компонентов возвращенных объектов URL , чтобы я мог скопировать вывод из моей консоли Xcode и вставить в терминал и доказать себе, что я могу cd (каталог изменения) в оба / Каталоги пользователей и /Network/Users .

В этом примере показано использование доменов . У вас может быть несколько доменов на многопользовательском устройстве, таком как MacBook Pro. На устройстве iOS вы, скорее всего, ограничены только .userDomainMask из-за песочницы, хотя это может измениться в будущих версиях iOS. ( ИСКЛЮЧЕНИЕ: В Mac App Store продаются приложения, использующие песочницу.)

Я провел еще один эксперимент на базе macOS. Я хотел посмотреть, смогу ли я написать какой-нибудь код Swift для вывода списка всех домашних каталогов пользователей на моем MacBook Pro. Вот код:

Список всех пользовательских каталогов в macOS

let userDirectory = FileManager.default.urls (для: .userDirectory, в: .localDomainMask)
пусть pathToUserDirectory = userDirectory.first?.path
делать
{
пусть листинг = попробуйте FileManager.default.contentsOfDirectory(atPath: pathToUserDirectory!)
для подкаталога в списке
{
print("\(подкаталог)")
}
}
поймать пусть ошибка
{
печать (ошибка. локализованное описание)
}

Код работал отлично, и вот вывод консоли Xcode:

Список всех домашних каталогов пользователей в macOS

MS DOS

Все пользователи root: /Users

. localized
Эндрю Джаффи
Общий
Гость
тестирование программного обеспечения

КАК МНЕ НАПИСАТЬ СВОЙ КОД

Учитывая обсуждение до сих пор, как вы думаете, мой текущий код Swift для получения каталога Documents приложения надежен? Позвольте мне напомнить вам код, который я обсуждаю:

Метод URL-адресов Swift для получения документов

func documentDirectoryURL() -> URL
{
вернуть FileManager.default.urls(для: .documentDirectory, в: .userDomainMask).сначала!
}

Хотя это, вероятно, будет работать в 99% случаев, оно не учитывает сценарий, в котором по какой-то непредвиденной причине каталог Documents не создается при установке приложения из App Store — скажем, сценарий, в котором происходит сбой iPhone во время установки приложения. Что, если каким-то образом Каталог Documents удален из-за каких-то странных обстоятельств, когда пользователь фактически запускает приложение, или, возможно, из-за обновления операционной системы.

За 30 лет разработки программного обеспечения я повидал почти всего .

Чтобы быть действительно надежным, я бы добавил в свой код некоторую проверку ошибок. Во время любой операции приложения, для которой требуется доступ к каталогу Documents или любому другому подобному изолированному каталогу, я мог бы проверить, возвращает ли мой код управления файлами iOS добросовестный URL или nil :

Надежный метод Swift для получения документов

func documentDirectoryURL() -> URL?
{

пусть возможныеURLs = FileManager. default.urls (для: .documentDirectory, в: .userDomainMask)

если возможноURLs.count >= 1
{
// Использовать первый каталог (если возвращено несколько)
вернуть возможныеURLs.first
}
еще
{
вернуть ноль
}

}

Если я столкнусь с nil в приложении, ориентированном на файлы, я сообщу пользователю через UIAlertController .

О, КАКАЯ БОЛЬ ЭТО ВСЕ!

Примерно через год после выхода Swift я наткнулся на метод url(for:in:СоответствующийFor:create:) , который я считаю гораздо более чистым методом API файловой системы iOS/macOS для получения URL-адрес для «стандартного каталога», такого как Documents . Не знаю, почему я так долго не замечал этого метода. Не знаю, почему я так долго не замечал, что кто-то еще заметил этот метод. Я только что сделал поиск в Интернете и нашел почти нет ссылок от до URL-адрес (для:в:соответствуетДля:создать:) . Одно из единственных упоминаний, которые я смог найти, было в технической информации/примечаниях к выпуску для iOS 8. url(for:in:СоответствующийДля:create:) намного проще понять и использовать, потому что он возвращает один необязательный URL и не содержит чепухи про «Использовать первый каталог (если возвращается несколько)».

Позвольте мне сначала показать вам, как я теперь получаю каждый URL для «стандартных каталогов» iOS:

ЛУЧШИЙ быстрый метод для получения документов

func documentDirectoryURL() -> URL?
{

делать
{
пусть возможноURL = попробуйте FileManager. default.url (для: .documentDirectory, в: .userDomainMask, соответствующий для: nil, создать: true)

вернуть возможныйURL
}
поймать пусть ошибка
{
print("ОШИБКА: \(error.localizedDescription)")
вернуть ноль
}

}

}

}

}

}

9


Вот объявление для метода экземпляра url(for:in:СоответствующийFor:create:) класса FileManager :

Подпись для метода URL-адреса Swift — ЛУЧШИЙ

func url (для каталога: FileManager. SearchPathDirectory,
в домене: FileManager.SearchPathDomainMask,
подходитДля URL: URL?,
создать shouldCreate: Bool) throws -> URL

Обратите внимание, что у нас есть аргумент shouldCreate , который, если установлено значение true, определяет «Создавать ли каталог, если он еще не существует». Довольно мило.

Не беспокойтесь о метке аргумента и аргументе , соответствующем URL-адресу . Большинство разработчиков всегда оставляют этот аргумент как nil , потому что его вариант использования будет относительно редким. Я рекомендую вам прочитать об этом методе и начать использовать его как можно скорее в своих приложениях.

Аллилуйя!

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

Разрешения и пути к файловой системе в iOS

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

Манипулирование путями файловой системы в iOS и iPadOS (далее мы будем называть обе iOS) на самом деле довольно просто и похоже на то, как это делается, скажем, на Mac — с некоторыми особенностями. Как правило, вы можете предположить, что применяются все обычные правила с двумя ключевыми отличиями:

• Права доступа . iOS более строга в отношении того, что стороннее приложение, такое как Juno, может делать в файловой системе вашего устройства и к каким местам оно может получить доступ.
• Абсолютные пути . Не слишком полагайтесь на абсолютные пути — например, когда вы программируете в Juno и хотите указать местоположение файла для чтения, вместо этого используйте относительный путь.

Разрешения на доступ

По умолчанию приложения могут получать доступ только к своему собственному виртуальному пространству в файловой системе устройства, обычно называемому каталогом песочницы приложения, или песочница ; вы можете найти его в файлах в виде папки с названием и значком приложения в памяти вашего устройства (технически это только доступная пользователю часть песочницы приложения, но давайте пока проигнорируем это). Это часть файловой системы устройства, которой приложение «владеет» и имеет полный доступ для чтения и записи; здесь же Juno размещает свой вступительный блокнот и создает каталог /site-packages для ваших собственных модулей и пакетов Python. Основная причина, по которой эти файлы находятся там, где они есть, заключается в том, что Juno может быть уверена, что сможет получить доступ к этому местоположению, несмотря ни на что.

Однако iOS также позволяет сторонним приложениям получать доступ к файлам и каталогам в других местах (например, в iCloud или даже в песочницах других приложений), если вы, как пользователь, явным образом предоставляете доступ к ним в приложении. Например, когда вы открываете блокнот Jupyter в Files with Juno, система автоматически предоставляет Juno доступ к этому файлу, и любые внесенные вами изменения будут сохранены в исходном местоположении блокнота — точно так же, как на рабочем столе. То же самое происходит, когда вы открываете записную книжку с помощью файлового браузера Juno, который фактически представляет собой системный диалог выбора файлов, предоставляемый интеграцией Juno с приложением «Файлы».

Все хорошо, если вас интересует только содержимое документа, но что, если вы также хотите получить доступ к папке , в которой находится документ? Это очень распространенный сценарий в Juno: когда вы запускаете код в записной книжке, вы обычно также хотите иметь доступ к каталогу записной книжки — например, чтобы прочитать файл . csv или сохранить изображение графика. Но если ваш ноутбук не находится в песочнице Juno, система не предоставит Juno доступ к каталогу файла автоматически.

Когда Juno обнаружит, что у нее нет доступа к каталогу ноутбука, на котором она работает, она отобразит кнопку в верхней панели рядом с именем ядра:

Если вы нажмете эту кнопку, появится диалоговое окно выбора системной папки. появится, что позволит вам явно предоставить Juno доступ к каталогу ноутбука. Выберите папку, в которой находится записная книжка (она должна быть выбрана по умолчанию) и нажмите Готово:

Вот и все — теперь система предоставит Juno доступ к выбранной папке, и Juno автоматически установит ее в качестве текущей рабочей папки записной книжки (CWD ).

Обратите внимание, что это может не сработать, если ваш ноутбук находится в облачном хранилище — например, предоставление доступа к каталогам будет работать с iCloud, но не с Dropbox или OneDrive. Это связано с тем, что некоторые приложения облачных хранилищ не полностью интегрируются с Files на iOS, а функциональные возможности файловой системы, которые будут работать в Juno, работают только в той мере, в какой их разработчики решили интегрироваться с API Apple. Будем надеяться, что эти службы облачного хранения в конечном итоге завершат интеграцию файлов; но мы ищем обходные пути, где мы потенциально могли бы интегрироваться с некоторыми из них в обход приложения «Файлы».

Абсолютные пути

Хотя вы обнаружите, что абсолютные пути в iOS похожи на пути в настольных ОС, таких как macOS, вам не следует слишком полагаться на них — потому что они не являются постоянными и время от времени обновляются система под капотом, даже если вы не перемещали файл. Вот пример абсолютного пути к файлу в iOS:

 /private/var/mobile/Containers/Data/Application/76FB0F63-CCC1-4754-8047-B79F5E45FA97/Documents/MNIST/data.csv
 

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

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

 df = pd.read_csv('welcome-data/iris.csv')
 

Блокнот расположен рядом с каталогом /welcome-data , т. е. они оба расположены в одной папке — поэтому вместо использования абсолютного пути к каталогу вы можете просто обратиться к файлу .csv внутри него с 'welcome-data/ ирис.csv' .

CWD

Концепция текущего рабочего каталога (или CWD) важна в контексте использования относительных и абсолютных путей в Juno. Вы можете думать о CWD как о каталоге, в котором работает интерпретатор Python, связанный с ядром вашего ноутбука. Таким образом, когда вы хотите указать конкретное расположение файловой системы в своем коде Python — скажем, файл для чтения или записи — вы можете сделать это в отношении вашего рабочего каталога, и интерпретатор Python сможет найти его без дополнительных подсказок. Если CWD вашего ноутбука настроен на каталог вашего ноутбука, вы можете просто ссылаться на файлы, расположенные рядом с вашим ноутбуком, по их имени, например. «data.csv» — аналогично read_csv(...) пример выше.

При первом открытии записной книжки Juno попытается установить CWD в каталог записной книжки. Если Juno не может получить к нему доступ, он установит рабочий каталог ноутбука во временную папку и предложит вам предоставить доступ, показывая кнопку на верхней панели. Когда доступ будет предоставлен, Juno автоматически установит CWD в выбранный каталог.

Вы также можете в любое время вручную изменить рабочий каталог вашего ноутбука — возможно, вы захотите получить доступ к файлу в совершенно другом месте, а не там, где находится ваш ноутбук. Коснитесь имени ноутбука на верхней панели и выберите «Изменить каталог…», вы увидите тот же системный диалог, позволяющий предоставить Juno доступ к любому каталогу на вашем устройстве. Предоставление доступа также изменит рабочий каталог записной книжки, поэтому всего за несколько нажатий вы можете переключить CWD записной книжки в любое место на вашем устройстве и читать (или записывать) файл в нем, используя короткий относительный путь.

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

Вы всегда можете проверить свой текущий рабочий каталог, либо нажав имя ноутбука на верхней панели (CWD отображается в нижней части всплывающего меню), либо выполнив это:

 import os
ОС.getcwd()
 

Juno напечатает абсолютный путь к текущему рабочему каталогу этого ноутбука в выводе ячейки ниже.

Заполнение пробелов: извлечена полная файловая система iOS 14

iOS Forensic Toolkit 7.40 обеспечивает бесперебойную поддержку низкоуровневого извлечения для нескольких версий iOS до iOS 15. 1 включительно (15.1.1 на некоторых устройствах), добавляя совместимость с ранее неподдерживаемыми версиями iOS 14.

Что это такое

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

До этого обновления iOS Forensic Toolkit мог выполнять низкоуровневое извлечение данных большинства моделей iPhone под управлением iOS от 9 до 14.8, iOS 15-15.1 и iOS 15.1.1 на некоторых платформах. В частности, для платформы A14 агент извлечения поддерживал iOS 14.0–14. 3 и 15.0–15.1, из-за чего отсутствовал весь диапазон сборок iOS 14. Это привело к довольно фрагментированной матрице поддержки. В этом выпуске мы закрыли два оставшихся пробела, снова предложив действительно полное извлечение файловой системы для всех поддерживаемых платформ. С этим обновлением мы сделали возможным полное извлечение файловой системы iOS 9.от .0 до 15.1 для всех моделей iPhone и iPad, которые могут работать с этими версиями iOS, и iOS 15.1.1 для некоторых моделей.

Преимущества экстракции на основе агентов

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

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

Что делает определенную версию iOS «совместимой» с агентом? Агент извлечения получает необходимый уровень привилегий, эксплуатируя одну из известных уязвимостей в ядре iOS. Для этого приложение упаковывает ряд эксплойтов на уровне ядра и использует тот или иной, чтобы выйти из своей песочницы и получить доступ к файловой системе. Такие эксплойты требуют времени и усилий для поиска и реализации, а Apple активно исправляет известные уязвимости в обновлениях iOS. Вот почему последние версии iOS, как правило, невосприимчивы к эксплойтам, разработанным для более ранних сборок (хотя мы знаем о нескольких исключениях).

iOS 14.8.1

В более ранних версиях iOS Forensic Toolkit мы поддерживали версии iOS до iOS 14.8 включительно. Мы также поддерживали iOS 15.0–15.1 на всех совместимых устройствах и iOS 15.1.1 на некоторых платформах. iOS 14.8.1 заметно отсутствовала в списке из-за отсутствия надлежащего эксплойта.

Для других версий iOS, включая iOS 15, агент извлечения полагался на общедоступные эксплойты ядра. Иная ситуация с iOS 14.8.1, в которой нет публичного эксплойта. В эту сборку iOS мы включили новый неопубликованный эксплойт, благодаря чему наш агент извлечения стал первым в своем роде инструментом, поддерживающим эту версию iOS.

iOS 14.4–14.8.1 (Apple A14)

До этого выпуска мы поддерживали iOS 15.0–15.1 на всех платформах и iOS 15.1.1 на некоторых устройствах. Примечательно, что на устройствах Apple A14 Bionic не поддерживался весь диапазон iOS 14.4–14.8.1. iOS Forensic Toolkit 7.40 обеспечивает поддержку iOS 14.4-14.8.1 для устройств A14, теперь обеспечивая полную поддержку всех совместимых устройств и всех версий iOS от iOS 9. 0 до 15.1.1.

Использование экстрагента

Вам потребуется поддерживаемое устройство iPhone или iPad с совместимой версией iOS. На следующем рисунке представлена ​​таблица поддерживаемых моделей устройств и версий iOS:

Для установки агента настоятельно рекомендуется использовать идентификатор Apple ID, зарегистрированный в программе разработчиков Apple, поскольку это устраняет необходимость открывать доступ в Интернет на устройстве. Обходной путь доступен для пользователей Mac. Подробные инструкции о том, как загрузить неопубликованное приложение Extraction Agen, доступны в нашем блоге.

Действия по извлечению файловой системы и расшифровке связки ключей

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

1. Подключите iPhone к компьютеру. Соедините устройство (установите доверительные отношения), подтвердив запрос на iPhone и введя пароль блокировки экрана.
2. Запустите iOS Forensic Toolkit 7.40 или новее.
3. На компьютере загрузите неопубликованный агент извлечения с помощью соответствующей команды в iOS Forensic Toolkit.
4. На iPhone запустите агент извлечения, коснувшись его значка.
Windows : требуется учетная запись разработчика. Используйте пароль для конкретного приложения.
macOS : учетная запись разработчика не требуется, но настоятельно рекомендуется.
5. Если поддерживается, извлеките связку ключей. Извлечь образ файловой системы (полная файловая система или раздел данных). Мы рекомендуем извлечь только раздел данных; полное изображение может быть использовано, например. для проверки системного раздела на наличие постоянных вредоносных программ.
6. На iPhone удалите агент извлечения обычным способом.
7. Теперь вы можете отключить iPhone и начать анализ данных.

агент, Apple, checkm8, EIFT, Elcomsoft iOS Forensic Toolkit, агент извлечения, iOS, логическое получение, низкоуровневое извлечение

ССЫЛКИ:

Elcomsoft iOS Forensic Toolkit

Извлекайте важные улики из устройств Apple iOS в режиме реального времени. Получите доступ к секретам телефона, включая пароли и ключи шифрования, и расшифруйте образ файловой системы с исходным кодом доступа или без него. Физические и логические параметры сбора данных для всех 64-разрядных устройств под управлением всех версий iOS.

Официальная веб-страница Elcomsoft iOS Forensic Toolkit и файлы для загрузки »

НОВЕЙШИЕ СТАТЬИ

Вход в DFU: iPhone 8, 8 Plus и iPhone X
Низкоуровневое извлечение iOS 15.2-15.3.1
Проверка шифрования диска Linux: LUKS2, Argon 2 и ускорение графического процессора
НОВОСТИ ЭЛКОМСОФТ

• Elcomsoft iOS Forensic Toolkit 7.60 расширяет возможности полного извлечения файловой системы на основе агентов25 августа, 2022
• Elcomsoft Distributed Password Recovery 4.45 поддерживает PIN-коды Windows Hello и шифрование LUKS216 августа, 2022
• Elcomsoft System Recovery 8.30 восстанавливает учетные записи Windows, защищенные PIN-кодом, поддерживает шифрование LUKS24 августа 2022 г.
• Elcomsoft iOS Forensic Toolkit 8.0 beta 12 улучшает извлечение информации из iPhone 728 июля, 2022
• Elcomsoft iOS Forensic Toolkit 8.0 beta 11 добавляет поддержку iOS 15.6 RC20 июля, 2022

ПРЕСС-РЕЛИЗЫ

• «Элкомсофт» взламывает PIN-коды Windows Hello и атакует шифрование LUKS216 августа, 2022
• ElcomSoft извлекает криминалистически обоснованное извлечение checkm8 на iPad, iPod Touch и Apple TV21 июня, 2022
• ElcomSoft представляет поддержку извлечения файловой системы iPhone 1329 апреля, 2022
• Elcomsoft System Recovery 8.20: Bootable Forensic Tools и поддержка Windows 1123 марта, 2022
• ElcomSoft обеспечивает повторяемое, криминалистически обоснованное извлечение checkm8 для iPhone 8, iPhone X и Apple Watch Series 310 Февраль, 2022

Как получить доступ к файлам iPhone с помощью монтирования диска

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

В этой статье мы рассмотрим следующие различные подходы:

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

PTP: доступ к фотографиям, видео и данным камеры в виде дискового монтирования

iOS автоматически представляет современные устройства как камеры, когда они подключены через USB. При этом используется протокол передачи изображений (PTP), который представляет собой довольно ограниченную систему, позволяющую копировать фотографии туда и обратно. Вы, вероятно, узнаете папки DCIM , в которых обычно появляются фотографии.

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

Доступ к фотографиям и данным приложений через AFC с помощью iTunes

В базе знаний Apple есть статья, описывающая, как управлять простейшим обменом файлами с помощью iTunes.

Доступ к данным приложения через USB с помощью FUSE

FUSE — это система, которая позволяет пользователям монтировать диски на своих компьютерах с Windows или Mac без необходимости внесения изменений в свои системы на уровне администратора. FUSE означает «файловая система в пользовательском пространстве» и доступен в различных формах на большинстве платформ. FUSE сам по себе является уровнем абстракции, поскольку это не технология, которая напрямую взаимодействует с устройством или источником данных: обычно для этого используется другой подход. В случае подключения iPhone в качестве диска FUSE будет связываться с iPhone по другому протоколу: SSH, AFC/AFC2, PTP или WebDAV. В Windows часто используется популярная файловая система пользовательского режима Dokan, а в macOS популярна osxfuse.

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

Использование монтирования FUSE в macOS

Давайте продемонстрируем этот подход в macOS и как монтировать устройство. Чтобы это работало, вам необходимо установить бесплатный менеджер пакетов Homebrew и ознакомиться с использованием терминала в macOS.

Прежде всего, давайте найдем UDID вашего устройства . Вы можете сделать это с помощью бесплатной версии iPhone Backup Extractor, с помощью команды lsusb или с помощью ioreg -p IOUSB -l -w 0 . Запустите iPhone Backup Extractor, пока ваше устройство подключено, выберите свое устройство и перейдите на вкладку «Информация». Вы увидите UDID , показанный в разделе «Идентификаторы оборудования»:

.
Данные устройства, показанные в iPhone Backup Extractor

Далее, давайте подготовим FUSE для macOS:

 $ brew tap homebrew/cask
$ варить бочку установить osxfuse
==> Предостережения
Чтобы установить и/или использовать osxfuse, вам может потребоваться включить их расширение ядра в
  Системные настройки → Безопасность и конфиденциальность → Общие
Дополнительные сведения см. в документации поставщика или в Технических примечаниях Apple:
  https://developer.apple.com/library/content/technotes/tn2459/_index.html
Вы должны перезагрузиться, чтобы установка osxfuse вступила в силу. 
 

И давайте установим ifuse , который представляет собой код, который может взаимодействовать с устройствами iOS через FUSE:

 $ brew install ifuse
 

С установленным ifuse можно смонтировать ваш iPhone или iPad, используя UDID , который мы получили ранее:

 $ mkdir ~/iphone
$ ifuse ~/iphone --udid 0000000000000000000000000
 

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

Устранение ошибок, с которыми вы можете столкнуться

ifuse может пожаловаться: Указан недопустимый UDID устройства, длина должна быть 40 символов . Начиная с iPhone X, Apple изменила UDID , чтобы использовать 24 байта и тире ( - ) вместо старого 40-байтового формата.

Если вы получаете Не удалось подключиться к службе блокировки на устройстве. Попробуйте еще раз. Если это все еще не удается, попробуйте перезагрузить устройство. убедитесь, что ваше устройство подключено и не отображает диалоговое окно «Доверять этому компьютеру». Сначала вам нужно одобрить это. Если вы затем получите ОШИБКА: устройство 000000000000000000000000 вернуло необработанный код ошибки -13 , вам необходимо отключить и снова подключить устройство.

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

Если вы собираетесь монтировать только одно устройство iOS, вы можете просто запустить ifuse ~/iphone .

Необходимо использовать предварительную версию

usbmuxd?

usbmuxd не часто обновляется, поэтому иногда, когда выпускается новая версия iOS, ему не хватает поддержки. Чтобы это исправить, вы можете установить последнюю версию разработки, как показано ниже:

 brew unlink usbmuxd
варить установить --HEAD usbmuxd
варить отвязать libimobiledevice
варить установить --HEAD libimobiledevice
варить бочку удалить osxfuse
варить бочку установить osxfuse idevicepair
 

Доступ к данным приложения через USB с помощью FUSE на взломанном устройстве

Инструкции точно такие же, как и выше. После взлома устройства вы сразу увидите больше данных. Аккуратно, а?

Использование WebDAV-сервера Filza для доступа к корневым файлам iOS

На взломанном устройстве iOS можно установить приложение файлового менеджера Filza через Cydia. В настройках Fileza вы можете включить режим сервера WebDAV. Это обеспечивает довольно простой интерфейс для доступа других устройств к вашему устройству iOS, хотя и крайне небезопасный. WebDAV — это очень общий механизм для работы с веб-данными, и есть много клиентов, которые могут получить к нему доступ: включая веб-интерфейс, встроенный в Filza. Подключитесь к своему устройству через веб-браузер, и вы увидите интерфейс. Легкий.

Использование AFC2 для доступа к файлам iOS через USB

Что такое AFC2?

AFC означает «Apple File Conduit», собственный механизм Apple для передачи данных с устройства iOS на главный компьютер. AFC работает на каждом устройстве iOS, но заблокирован для предоставления доступа только к ограниченному набору данных. «AFC2» — это прозвище, данное серии инструментов, созданных сообществом джейлбрейкеров, эмулирующих AFC, но обеспечивающих доступ ко всему устройству. Последняя реализация AFC2 была создана Cannathea и доступна на GitHub.

AFC2 можно установить из Cydia, и после установки клиент AFC сможет просматривать устройство целиком.

Другие методы доступа ко всем данным на взломанных устройствах

До выпуска iOS 8 существовало несколько плагинов Cydia для взломанных устройств, которые заставляли iPhone представлять себя как USB-накопитель при подключении. Увы, они больше не поддерживаются в современных версиях iOS.

Восстановление удаленных файлов с подключенного iOS-устройства

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

Руководство Apple по безопасности iOS кратко описывает это на странице 17 в «обзоре архитектуры»:

Каждый раз, когда создается файл в разделе данных, Data Protection создает новый 256-битный ключ («файловый ключ») и передает его аппаратному механизму AES, который использует ключ для шифрования файла в том виде, в котором он есть. записывается во флэш-память в режиме AES-XTS. На устройствах с SoC A7, S2 или S3 используется AES-CBC. Вектор инициализации вычисляется со смещением блока в файле, зашифрованном с помощью хэша SHA-1 ключа для каждого файла.

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

Бонус: подключение компьютера Windows с iPhone или iPad

В iOS 13 появилась поддержка SMB для iOS. Это позволяет пользователям получать удаленный доступ к дискам на компьютерах с Windows. Вот как это работает:

1. Найдите IP-адрес вашего компьютера с Windows. Об этом вам должна сообщить команда ipconfig .

2. На компьютере с Windows щелкните правой кнопкой мыши папку, к которой вы хотите предоставить общий доступ, и выберите Свойства → Общий доступ → Расширенный обмен . Нажмите «Поделиться этой папкой».

3. На вкладке «Общий доступ» выберите «Поделиться... », затем в раскрывающемся меню выберите свою учетную запись пользователя, добавьте ее и убедитесь, что у нее есть разрешения «Чтение/запись». Нажмите «Поделиться» и «Применить» и закройте окно.

4. На устройстве iOS откройте приложение Apple «Файлы», коснитесь «Подключиться к серверу».