Папка dyld mac os что это такое
Обновлено: 21.11.2024
Формат dyld_shared_cache в iOS 15 и macOS 12 изменился и теперь разделен на 2 или более частей. Гидра больше не может его открыть.
Было бы полезно обновить Ghidra, чтобы открыть эти кластеры общего кэша.
Ниже приведены примеры каталога макета общего кэша в iOS и macOS
Текст был успешно обновлен, но возникли следующие ошибки:
Ryanmkurtz прокомментировал 18 августа 2021 г.
Есть ли у вас ссылки, описывающие новый формат? В данный момент у меня нет к ним доступа.
zcutlip прокомментировал 18 августа 2021 г.
К сожалению, их немного. Ожидается, что Apple выпустит обновленный исходный код dyld осенью, но это часто немного отстает от финальных выпусков.
Hopper имеет (очень) предварительную поддержку, но я не думаю, что она делает что-то еще.
Надеюсь, это поможет. Я посмотрю, что еще я могу найти.
mumbel прокомментировал 18 августа 2021 г. •
zcutlip прокомментировал 19 августа 2021 г.
Если прошлое является каким-либо указанием, то да, именно туда пойдет новый исходный код dyld, который будет включать заголовочные файлы, описывающие новый формат, а также код C++, который его анализирует. Я ожидаю увидеть источник для этого, вероятно, в октябре/ноябре. Apple не очень последовательна в этом.
Что касается версий, существуют поля заголовков, которые сообщают о версиях различными способами, но это не очень удобно: "посмотрите на поле версии, чтобы увидеть, с какой версией формата мы имеем дело".
Вероятно, лучшим примером определения версии является DyldExtractor, упомянутый выше. Они неплохо справляются с различными вариантами форматов. Это комбинация просмотра нескольких явных полей версии в разных структурах и эвристики (например, если это поле имеет значение NULL, ищите дополнительные поля в конце).
Ryanmkurtz прокомментировал 19 августа 2021 г.
У меня есть несколько образцов, и я должен сделать первые предположения о том, как все устроено. Самая большая проблема, которую я вижу заранее, заключается в том, что наша структура загрузчика не предназначена для загрузки более 1 файла. Загрузчик может поддерживать функцию «Добавить в программу», но я вижу, что эти файлы перекрестно ссылаются друг на друга с точки зрения определений макета памяти и местоположений DYLIB, поэтому нам придется немного подумать о том, как лучше всего справиться с этим. р>
astrelsky прокомментировал 20 августа 2021 г.
К сожалению, их немного. Ожидается, что Apple выпустит обновленный исходный код dyld осенью, но это часто сильно отстает от финальных выпусков.
У меня есть несколько образцов, и я должен сделать первые предположения о том, как все устроено.
MacOS, разработанная и распространяемая Apple, безусловно, является одной из самых надежных операционных систем. Он используется в основном профессионалами, которые намерены использовать свои компьютеры в деловых целях. Однако в последнее время поступает много сообщений об ошибке «Dyld: Library Not Loaded» в MacOS. В этой статье мы обсудим причину, из-за которой возникает эта ошибка, а также предложим эффективные решения для их исправления.
Сообщение об ошибке «dyld: библиотека не загружена» в MacOS
Что вызывает ошибку «Dyld: библиотека не загружена» в MacOS?
После получения многочисленных отчетов мы решили изучить проблему и определить причину, из-за которой возникает эта ошибка.
- Недопустимое расположение: эта ошибка возникает, когда компьютер пытается найти файл «libmysqlclient.18.dylib» или файл, аналогичный этому, в расположении «usr/lib». Совершенно очевидно, что файл отсутствует в этом месте, из-за чего возникает ошибка.
Теперь, когда у вас есть общее представление о характере проблемы, мы перейдем к ее решению. Обязательно реализуйте их в определенном порядке, в котором они предоставлены, чтобы избежать конфликтов.
Решение 1. Создание символической ссылки
Проблему можно решить, создав символическую ссылку в каталоге, где компьютер проверяет наличие файла «.dylib». Для этого:
Пример приведенной выше команды выглядит следующим образом:
Решение 2. Обновление Brew
В некоторых случаях этот файл отсутствует в каталоге из-за устаревшей установки «Brew». Поэтому на этом этапе мы будем обновлять Brew. Для этого:
Решение 3. Запуск сценария «Copy_dylibs.py»
В некоторых случаях ссылки на файлы «.dylib» неверны, из-за чего возникает эта ошибка. Поэтому на этом этапе мы запустим скрипт, который автоматически обнаружит и устранит эти проблемы. Для этого:
Если на вашем Mac мало места, у вас может возникнуть соблазн удалить эти папки, но трогать их опасно.
macOS имеет глубокую и вложенную структуру папок, а установка macOS по умолчанию содержит множество незнакомо звучащих каталогов. Большинству пользователей даже не нужно прикасаться к этим файлам.
Apple не просто так скрывает определенные папки. Работа с этими каталогами может привести к нестабильной работе системы, потере данных или, что еще хуже, к невозможности загрузки вашего Mac. Мы покажем вам места в файловой системе macOS, которые большинству пользователей не следует трогать.
1. Языковые файлы и папки
Приложения для Mac поставляются с языковыми файлами для каждого поддерживаемого языка. Когда вы переключаете системный язык вашего Mac, приложение сразу переключается на этот язык.
Чтобы просмотреть языковые файлы приложения, щелкните его, удерживая клавишу Control, и выберите в контекстном меню пункт «Показать содержимое пакета». Путь будет выглядеть так: AppName.app/Contents/Resources/Lang.lproj
Удаление языковых файлов для сторонних приложений легко выполняется через Терминал. Но для приложений macOS по умолчанию вам необходимо отключить защиту целостности системы, что мы вообще не рекомендуем.
Несмотря на то, что в Интернете можно найти много советов по удалению языковых файлов, чтобы освободить место на диске, количество заработанного вами места недостаточно для связанных с этим рисков.
Быстрое сканирование с помощью CleanMyMac показывает, что мой Mac освободит около 520 МБ дискового пространства, удалив эти файлы. В вашем случае результат может быть другим, но маловероятно, что вы выиграете больше нескольких гигабайт. Кроме того, эти шаги необходимо повторять после каждого серьезного обновления macOS.
Когда вы удаляете языковые файлы, вы не можете предсказать, какие приложения будут аварийно завершать работу или зависать. В худшем случае вам придется переустановить приложение. Кроме того, старые версии программ, таких как приложения Microsoft Office и Adobe, могут не работать или обновляться должным образом. Поэтому лучше игнорировать языковые файлы и папки.
Ознакомьтесь с нашими советами по освобождению места на вашем Mac, чтобы узнать, как это сделать лучше.
2. Скрытая папка /private/var
macOS создает несколько пользовательских и связанных с системой файлов кэша для ускорения работы системы. Кэш и временные данные, расположенные в /Library/Caches, находятся под вашим контролем. Вы можете вручную удалить этот кеш без каких-либо сторонних инструментов.
Но файлы в системной папке полностью управляются macOS. Они даже не видны вам. Иногда элементы в этих каталогах могут занимать огромное количество места на диске. Таким образом, вы можете задаться вопросом, безопасно ли удалять содержимое /private/var/folders или нет.
Расположение /private/var/folders
Самый простой способ найти папку /private/var — через меню Finder Go to Folder. Нажмите Cmd + Shift + G, чтобы открыть окно «Перейти к папке», и введите /private/var/folders. Сразу же откроется новая вкладка Finder.
Чтобы открыть расположение системных кэшированных и временных файлов, запустите окно терминала и введите следующее: open $TMPDIR. Вы увидите двухсимвольное имя папки с длинными, казалось бы, случайными именами вложенных папок. Перемещаясь по дереву папок, исследуйте эти три папки. Папка C представляет кэш, а T — временные файлы. Пользовательские файлы находятся в папке 0.
Проблемы с /private/var/folders
Быстрое сканирование с помощью OmniDiskSweeper показывает, что размер папки /private/var/folders составляет около 1 ГБ, а размер папки /private/var — около 4 ГБ. Размер этих папок может варьироваться в зависимости от системы, но не должен быть слишком большим.
Если эти каталоги занимают более 10 ГБ, это не повод для беспокойства.
Не следует пытаться вручную удалять файлы из любых каталогов /private/var, даже если они большие. Это может привести к повреждению основных файлов macOS, повреждению данных документов, а также к тому, что ваш Mac не сможет загружаться или вести себя должным образом. Тогда вам придется переустанавливать macOS с нуля.
Чтобы безопасно удалить эти файлы, закройте все приложения и выключите компьютер Mac. Когда вы перезагружаете свой Mac, вы запускаете встроенные механизмы очистки кэша. Это удалит ненужное содержимое, кеши и временные элементы в /tmp, /private/var и /private/var/folders.
Если по какой-то причине эти файлы не очищаются, перезагрузите Mac в безопасном режиме. macOS использует дополнительные встроенные механизмы для избавления от кешей и временных файлов в этом режиме. Затем перезагрузитесь в обычном режиме и снова проверьте доступное место на диске.
Другие важные папки в /private/var
Что касается места на диске, есть еще несколько папок, которые не следует трогать:
- /private/var/db: включает набор файлов конфигурации и данных macOS. К ним относятся база данных Spotlight, файлы конфигурации сети и многое другое.
- /private/var/VM: содержит файлы образов подкачки и сна. Если вы переведете свой Mac в режим гибернации, этот каталог займет более 5 ГБ дискового пространства.
- /private/var/tmp: еще один каталог временных файлов.
3. Папка системной библиотеки
Файловая система macOS содержит несколько папок библиотеки.Это сделано намеренно, и хотя между содержимым папок библиотеки существует много общего, каждая папка играет свою роль в файловой системе macOS. Вы найдете три папки библиотеки:
Папка основной библиотеки и системной библиотеки имеет глобальную область действия. Их содержимое поддерживает каждый аспект системы. Папка System Library содержит файлы, необходимые для работы macOS. Только ОС имеет право изменять свои данные, и на них должны влиять только события системного уровня. Вам не нужно ничего трогать в этой папке.
4. Папка пользовательской библиотеки
Папка «Библиотека» в домашнем каталоге — это личная библиотека вашей учетной записи. Здесь macOS хранит систему, стороннюю поддержку и файлы настроек. Он также включает настройки Mail, закладки Safari, данные истории просмотров, данные календаря и многое другое. В папку «Библиотека» также входят папки, которые необходимо время от времени очищать. Однако не ко всем папкам можно прикасаться.
~/Библиотека/Поддержка приложений
В этой папке как системные, так и сторонние приложения хранят файлы поддержки, обычно в подпапке, названной в честь соответствующего приложения. Они содержат регистрационные данные и даже хранят сохраненные данные приложения, используемые в конкретном сеансе. Не удаляйте содержимое файлов поддержки приложений напрямую. Вместо этого используйте приложение AppCleaner, чтобы удалить файлы поддержки вместе с приложением.
~/Библиотека/Настройки
Эта папка содержит все данные о настройках для стандартных и сторонних приложений. Опять же, не удаляйте содержимое папки Preferences; в противном случае приложение вернется в состояние по умолчанию или может аварийно завершить работу. AppCleaner позаботится о настройках при удалении приложения.
~/Библиотека/Мобильные документы
Это фактическое расположение папки iCloud. Документы, файлы настроек приложений, данные приложений iOS и многое другое находятся в этой папке. Вы не должны перемещать, переименовывать или удалять его. Это также папка, которая занимает много места на диске, если вы используете iCloud. Удалите ненужные файлы из iCloud Drive, чтобы уменьшить его размер.
~/Библиотека/Контейнеры
Он содержит файлы поддержки, кэшированные данные и временные файлы для приложений, загруженных из Mac App Store. Поскольку приложения в App Store изолированы, они не могут записывать данные в любом месте системы. Опять же, не удаляйте содержимое этой папки. Если папка «Контейнеры» занимает много места на диске, переустановите соответствующее приложение.
5. Скрытые папки в домашней папке
При нажатии клавиш Cmd + Shift + точка в Finder вы увидите множество файлов и папок в домашнем каталоге, которые обычно скрыты от глаз. Различные технологии и приложения macOS хранят свои данные в этих папках для бесперебойной работы вашего Mac. Вы не должны изменять или удалять какие-либо из этих папок:
Держитесь подальше от важных папок macOS
Работать с этими папками рискованно, так как это может повредить ваши приложения, документы и macOS. Хотя большинству пользователей Mac не нужно беспокоиться об этих папках, у вас может возникнуть соблазн начать изучение этих папок, когда место на диске станет проблемой.
В таких случаях необходимо иметь резервную копию, чтобы в случае потери данных их можно было относительно легко восстановить. К счастью, на вашем Mac уже есть множество способов помочь вам в этом.
Надеемся, вам понравятся товары, которые мы рекомендуем и обсуждаем! У MUO есть аффилированные и спонсируемые партнерские отношения, поэтому мы получаем долю дохода от некоторых ваших покупок. Это не повлияет на цену, которую вы платите, и поможет нам предлагать лучшие рекомендации по продуктам.
После моего недавнего сообщения в блоге мой старый друг @_Dark_Knight_ связался со мной и задал вопрос:
"Вы обычно вызываете пользовательские приложения, которые разрешают dyld_insert_libraries?"
И еще несколько подобных, и, честно говоря, я понятия не имел, о чем он говорит, если бы я только понял вопрос :D Несмотря на то, что мои последние сообщения в блоге и доклады посвящены macOS, я много занимаюсь больше с Windows каждый день, вероятно, около 95%, и macOS по-прежнему остается для меня совершенно новой территорией. Поэтому я решил углубиться в вопрос и узнать об этом немного больше.
Оказалось, что для macOS существует очень известная техника внедрения с использованием переменной среды DYLD_INSERT_LIBRARIES. Вот описание переменной из документа dyld man:
Короче говоря, он загрузит любые dylib, которые вы укажете в этой переменной, до того, как загрузится программа, по сути внедрив dylib в приложение. Давай попробуем! Я взял свой предыдущий код dylib, который использовал, играя с перехватом dylib:
Для быстрого теста я написал сложный код hello world C и попробовал его с ним. Чтобы установить переменную среды для запуска приложения, вам нужно указать DYLD_INSERT_LIBRARIES=[путь к вашей dylib] в командной строке. Вот как это выглядит:
Это также влияет на выполнение моего любимого приложения для создания заметок Bear (где я пишу это прямо сейчас):
Мы также можем увидеть все эти события в журнале (поскольку наша dylib помещает туда сообщение):
В следующих сообщениях блога есть два хороших примера того, как подключить само приложение:
Я не буду повторять их, поэтому, если вам интересно, прочтите их.
Можете ли вы предотвратить эту инфекцию? Майкл упомянул, что вы можете сделать это, добавив сегмент RESTRICTED во время компиляции, поэтому я решил изучить это подробнее. В соответствии с блокировкой внедрения кода в iOS и OS X есть три случая, когда эта переменная среды будет игнорироваться:
- установлены биты setuid и/или setgid
- ограничено правами
- сегмент с ограниченным доступом
Функция pruneEnvironmentVariables удалит переменные среды:
Если мы ищем, где установлена переменная sRestrictedReason, мы приходим к функции processRestricted:
Это сегмент кода, который идентифицирует ограниченный сегмент:
Теперь это старый исходный код, на который ссылались в статье выше — с тех пор он эволюционировал. Последний доступный код dyld.cpp выглядит немного сложнее, но по сути та же идея. Вот соответствующий сегмент кода, который устанавливает ограничение, и тот, который его возвращает ( configureProcessRestrictions , processIsRestricted ):
Для gLinkContext.allowEnvVarsPath будет установлено значение false, если:
- Основной исполняемый файл имеет ограниченный сегмент
- установлены биты suid/guid
- SIP включен (если кому интересно, CSR_ALLOW_TASK_FOR_PID — это флаг конфигурации загрузки SIP, но я мало что знаю об этом), и программа имеет флаг CS_RESTRICT (в OSX = программа была подписана с правами)
Но! Он не установлен, если установлен CS_REQUIRE_LV. Что делает этот флаг? Если он установлен для основного исполняемого файла, это означает, что загрузчик будет проверять каждую dylib, загруженную в приложение, на предмет того, были ли они подписаны тем же ключом, что и основной исполняемый файл. Если мы подумаем об этом, то в этом есть смысл, поскольку вы можете внедрить dylib только в приложение, которое было разработано одним и тем же человеком. Вы можете злоупотреблять этим только в том случае, если у вас есть доступ к этому сертификату подписи кода — или нет, подробнее об этом позже ;).
Есть еще один вариант защиты приложения — включение усиленной среды выполнения. Затем, если вы хотите, вы можете специально включить переменные среды DYLD: Разрешить права на переменные среды DYLD — Права. Приведенный выше исходный код, кажется, датирован 2013 годом, и эта опция доступна только с Mojave (10.14), который был выпущен в прошлом году (2018), вероятно, поэтому мы ничего не видим об этом в исходном коде.
Для справки, это значения флагов CS, взятые из cs_blobs.h
Это была теория, давайте посмотрим на все это на практике, если они действительно работают так, как рекламируется. Я создам проект Xcode и изменю конфигурацию по мере необходимости. Перед этим мы можем использовать наш исходный код для битового тестирования SUID, и, как мы видим, он работает так, как ожидалось:
Интересно, что в прошлом была ошибка LPE из-за неправильной обработки одной из переменных среды, а с файлами SUID можно было добиться повышения привилегий, здесь вы можете прочитать подробности: OS X 10.10 DYLD_PRINT_TO_FILE Локальная уязвимость повышения привилегий | Раздел Эйнс ГмбХ
Я создал полностью пустое приложение Cocoa для тестирования других вещей. Я также экспортирую переменную среды, поэтому нам не нужно указывать ее всегда:
Если мы скомпилируем его и запустим по умолчанию, мы увидим, что внедрена dylib:
Чтобы иметь раздел с ограниченным доступом, в настройках сборки -> Связывание -> Другие флаги компоновщика установите это значение:
Если мы перекомпилируем, мы увидим целую кучу ошибок, что dylibs игнорируются, например эти:
В качестве альтернативы мы можем использовать команду otool -l [путь к двоичному файлу] для той же цели, вывод будет немного другим.
Следующим шагом является настройка приложения (защищенная среда выполнения). Это можно сделать в разделе «Настройки сборки» -> «Подписание» -> «Включить защищенную среду выполнения» или в разделе «Возможности». Если мы сделаем это, перестроим приложение и попытаемся запустить его, то получим следующую ошибку:
Если я подпишу свой dylib, используя тот же сертификат, dylib будет загружен:
Если я использую другой сертификат для подписи кода, он не будет загружен, как показано ниже. Я хочу подчеркнуть, что эта проверка выполняется всегда, а не гейткипером.
Интересно, что даже если я установлю право com.apple.security.cs.allow-dyld-environment-variables на странице возможностей, я не смогу загрузить dylib с другой подписью. Не знаю, что я делаю не так.
Чтобы двигаться дальше, давайте установим требование проверки библиотеки ( CS_REQUIRE_LV ) для приложения. Это можно сделать, перейдя в Настройки сборки -> Подписание -> Другие флаги подписи кода и установив для него значение -o library. Если мы перекомпилируем и проверим подпись кода для нашего двоичного файла, мы увидим, что он включен:
И мы получим то же сообщение об ошибке, что и в защищенной среде выполнения, если попытаемся загрузить dylib с другим подписывающим лицом.
Последним пунктом, который нужно попробовать, будет установка флага CS_RESTRICT, но единственное, что я нашел по этому поводу, это то, что это специальный флаг, устанавливаемый только для двоичных файлов Apple. Если кто-то может дать больше информации, дайте мне знать, мне любопытно. Единственное, что я мог сделать, чтобы проверить это, — это попытаться внедрить в двоичный файл Apple, для которого не установлены предыдущие флаги, а не в suid-файл и не имеет сегмента RESTRICTED. Интересно, что флаг CS_RESTRICT не отражается утилитой подписи кода. Я взял Дисковую утилиту. Действительно наша dylib не загружена:
Я бы сказал, что это все, но нет. Вернемся к тому, что dylib можно внедрить даже в SUID-файлы, если установлен флаг CS_REQUIRE_LV. (Ведь возможно и к файлам с флагом CS_RUNTIME). Да, только дилибы с такой же сигнатурой, но есть потенциал (хотя и небольшой) для повышения привилегий. Чтобы показать, я изменил свою dylib:
Давайте подпишем это и тестовую программу тем же сертификатом, установим бит SUID для тестового двоичного файла и запустим его. Как мы видим, мы можем внедрить dylib, как и ожидалось, и он действительно будет работать от имени пользователя root.
Теоретически, чтобы использовать это, вам нужно одно из следующего:
- Имейте сертификат подписи кода исходного исполняемого файла (очень маловероятно)
- Имейте доступ на запись к папке, где находится файл с битом SUID -> в этом случае вы можете подписать файл своим собственным сертификатом (кодовый знак заменит файл, который вы подписываете, поэтому он удалит исходный файл и создаст новый). new - это возможно, потому что в системах *nix вы можете удалять файлы из каталогов, где вы являетесь владельцем, даже если файл принадлежит root), дождаться восстановления бита SUID (скрестим пальцы) и, наконец, внедрить свою собственную dylib . Можно подумать, что такого сценария не существует, но я нашел для него пример.
Последняя мысль по этой теме — GateKeeper. Вы можете внедрить помеченные карантином двоичные файлы в Мохаве, что на самом деле вполне ожидаемо.
Однако это больше не работает на Catalina, что также ожидается с внесенными изменениями:
Я думаю, что приложения должны защищать себя от такого типа внедрения dylib, и в нынешнем виде это довольно легко сделать, у вас есть несколько вариантов, поэтому на самом деле нет причин не делать этого. Поскольку Apple движется к нотариальному заверению, усиленная среда выполнения будет медленно включаться для большинства / всех приложений (это обязательно для нотариально заверенных приложений), поэтому, надеюсь, этот метод внедрения постепенно исчезнет. Если вы разрабатываете приложение, в котором вы устанавливаете бит SUID, обязательно правильно установите разрешения для родительской папки.
Читайте также: