sandboxed process 0 что это

Что такое «sandboxd» и что он делает в моем Mac

Открыли «Мониторинг системы» и обнаружили непонятный процесс под названием «sanboxd»? Давайте вместе разбираться что это такое. «sandboxd» — это демон (от анг. daemon), процесс, который выполняет определенную задачу в фоновом режиме, как правило у всех daemon-процессов буква «d» в окончании. Если конкретнее, sandboxd отвечает за работу процесса «песочницы». Запустите терминал и введите команду «man sandboxd» (без кавычек) и вы получите описание процесса:

Приложения, которые работают из «песочницы» делают запрос на доступ к файлам и функциям системы, например, на доступ к веб-камере — этот процесс добавляет дополнительный уровень безопасности ОС. Использование «песочницы» является одним из самых основных требований к приложениям, которые распространяются через Mac App Store — это одна из причин по которой некоторого софта нет в Mac App Store. Процесс «sandboxd» не расходует много системных ресурсов.

И самое главное, не забудьте подписаться на наш канал в Telegram

Источник

Оценка вредоносности файлов с помощью песочниц: Часть 2. Анализ в оффлайн

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

— Доступ к интернет затруднителен
— Онлайн-песочницы в данный момент перегружены, а выполнение анализа критично по времени
— Выполнение в онлайн песочницах блокируется изучаемым файлом
— Необходима более тонкая настройка режима выполнения файла при анализе, например — увеличение времени задержки с момента запуска

В этом случае на помощь нам приходит оффлайн-решение проблемы.

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

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

Комплекс Buster Sandbox Analyzer + SandboxIE

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

Одним из таких плагинов является Buster Sandbox Analyzer или BSA. Этот плагин работает во многом подобно уже обсуждённой CWSandbox — внедряет динамическую библиотеку в адресное пространство исследуемого процесса, позволяя отслеживать API-вызовы в ходе выполнения. Кроме того, программа позволяет отслеживать сетевую активность, производить анализ изменённых файлов и другие полезные вещи.

Чтобы оценить работу этой системы, вначале построим её. Дополнительно нужно будет скачать такие два аддона на SandboxIE: Block Process Access и Antidel. Эти плагины позволяют с одной стороны скрыть от анализируемого процесса наличие других процессов вне песочницы, а с другой — воспрепятствовать удалению файлов в ходе работы (полезно при анализе некоторых дропперов).

1. Устанавливаем SandboxIE.

2. Создаём дополнительную песочницу через Песочница — Создать новую песочницу. Я её назвал BSA — пусть и у вас будет так же для простоты.

3. Правой кнопкой мыши щёлкаем на песочницу BSA в списке окна программы и выбираем Настройки песочницы.

4. Критично:
Поведение — Отображать границу вокруг окна — выбрать красный
Recovery. — Немедленное восстановление — убрать галку И вообще убедиться, что ни одной папки нет в восстановлении.
Delete — поснимать все галки про удаление.
Restrictions — Доступ в Internet — поудалять все программы, пока не появится надпись «Ни одна программа не сможет получить доступ в Internet». Запомните эту опцию — для некоторых зловредов доступ нужно будет открывать, но учтите, что в этом случае все пароли и информация с хостовой машины уйдут злоумышленнику.
Restrictions — Доступ на запуск и выполнение — разрешить всем.
Доступ низкого уровня и аппаратные средства — все галки поснимать. Это важно, иначе низкоуровневые вирусы типа TDSS, Mebratix, Mebroot пролезут из песочницы в систему.
Остальные опции оставить по умолчанию. В дальнейшем можно их настроить на свой вкус — там всё достаточно понятно.

5. В папке, куда установили SandboxIE, создаём папку Buster Sandbox Analyzer, куда распаковываем всё, что скачано выше.

6. Файл LOG_API.DLL переименовываем во что хотите. Я его назвал LAPI.DLL. Также переименовываем HideDriver.sys.

7. В главном окне SandboxIE выбираем Настроить — Редактировать конфигурацию. В открывшемся текстовом документе находим раздел BSA сразу под этими буквами добавляем строки:

InjectDll=C:\Program Files\SandboxIE\Buster Sandbox Analyzer\sbiextra.dll
InjectDll=C:\Program Files\SandboxIE\Buster Sandbox Analyzer\antidel.dll
InjectDll=C:\Program Files\SandboxIE\Buster Sandbox Analyzer\LAPI.dll
OpenWinClass=TFormBSA

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

Теперь обратите внимание на раздел GlobalSettings, а конкретно на параметр FileRootPath:

FileRootPath=C:\Sandbox\%SANDBOX%
(у вас может отличаться).

Запомните его значение.

8. Сохраняем текстовый файл по оригинальному пути. В главном окне SandboxIE выбираем Настроить — Перезагрузить конфигурацию.

9. В главном окне SandboxIE выбираем: Настроить — Интеграция в проводник Windows — Запустить управление SandboxIE — когда запускается программа в песочнице и Действия «запускать в песочнице» — добавить пункт контекстного меню «Запустить в песочнице» для файлов и папок.

10. Запускаем Buster Sandbox Analyzer (вручную, из одноимённой папки путём запуска bsa.exe.

11. Выбираем Options — Analysis mode — Manual и Options — Program Options — Windows Shell Intagration — Add right-click action «Run BSA».

Всё готово для работы.

Как это использовать?

1. Отключаем резидентный антивирус (если имеется).

2. Наводим мышкой на изучаемый процесс и жмём правой кнопкой Run BSA. Откроется окно BSA.

3. Убедитесь, что в строке Sandbox folder to check указана папка, которая совпадает со значением параметра FileRootPath SandboxIE (см. выше), только вместо %SANDBOX% в ней указано BSA. В моём случае при параметре

в BSA должно стоять

4. Нажмите Start Analysis.

5. Наводим мышкой на изучаемый процесс и жмём правой кнопкой Запустить в песочнице. В предлагаемом списке песочниц выбираем BSA.

Всё. Процесс пойдёт. Вы будете видеть лог API-вызовов в BSA и активные процессы в главном окне SandboxIE. Иногда процесс завершится, тогда в BSA жмите Finish Analysis, иногда — его нужно прибить в SandboxIE (например, для файловых инфекторов), выбрав на правой мышкой на активной песочнице BSA Завершить программы.

По окончании BSA выдаст детальный отчёт об изменениях в системе, можно также через Viewer ознакомиться с другими отчётами. Если поставите в систему WinPcap — сможете даже перехватывать пакеты из песочницы, хотя там это не очень здорово организовано, нет, например, персонализации UDP-пакетов. Но если очень хочется — то можно, но при этом на хостовой системе следует заглушить все сетевые приложения, особенно торренты.

После работы, кликнув на песочнице BSA правой мышкой можно выбрать Просмотреть содержимое и изучить все файлы, созданные или изменённые процессом в ходе работы.

Логи BSA и файлы песочницы хранятся до следующего запуска нового процесса на исследование.

Следует заметить, что возможен прямой анализ изменений, вносимых в систему изучаемым файлом. Учитывая то, что виртуализованный реестр хранится C:\Sandbox\%SANDBOX%\RegHive, то перевести его в «понятный» вид крайне просто вот таким командным скриптом:

REG LOAD HKLM\uuusandboxuuu C:\Sandbox\DefaultBox\RegHive
REG EXPORT HKLM\uuusandboxuuu C:\Sandbox\sandbox.reg
REG UNLOAD HKLM\uuusandboxuuu

Только учтите, что «DefaultBox» у каждого будет индивидуален — но об этом уже мы говорили выше.

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

Возможность SandboxIE инжектировать динамические библиотеки в процесс может быть эффективно использована зловредного кода, выполняемого не в виде PE-исполняемого файла, а виде библиотеки, инжектируемой в адресное пространство процессов или регистрируемой в качестве сервиса. Но об этом — совершенно другой и непростой разговор.

Одним из наиболее распространённых приёмов автоматизации изучения зловредного кода является объединение выполнения ряда операций и утилит на Linux-системе с помощью скриптов Python. Именно так поступил Joxean Koret при создании своего проекта ZeroWine. ZeroWine — это образ виртуальной машины QEmu (который, однако, легко может быть конвертирован для других систем, в том числе VBox и VMWare), построенный на базе Debian. Вредоносный файл можно загрузить через веб-интерфейс, в результате чего он выполняется в среде wine, работа его контролируется рядом утилит, автоматизированных скриптом на Python. В результате, пользователь может получить информацию о вызываемых командах, дампы памяти процесса, перехват сетевых пакетов и др.

Другим «лицом» проекта ZeroWine является ZeroWine-tryouts? в котором внесено несколько дополнительных функций.

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

От себя хочу добавить, что хоть ZeroWine обновился в декабре прошлого года, мне лично больше понравился старый (с 2009 года) ZeroWine-tryout — может быть из-за более гибкой настройки и управления сканированием, а может быть — потому что он у меня запустился нормально, в отличие от новой версии 🙂

Распределённые системы анализа

Это — наиболее серьёзные и сложные решения аналитического характера. Обычно, распределённые системы представляют собой Linux-систему, работающую как сервер, принимающую и обрабатывающую дампы и логи, получаемые с заражённой Windows-системы. Такой механизм может быть построен в рамке взаимодействия виртуальных машин, либо виртуального Windows-гостя с Linux-хостом. По последнему принципу построен MINIBIS — Вы можете свободно скачать всё необходимое для развёртывания такой системы, базирующейся на выполнении виртуальной Windows XP в среде Ubuntu. Ещё одним интересным подходом является использование гипервизора, как в проекте Ether.

Однако если уж Вы решили заняться данным вопросом серьёзно — наиболее правильным подходом является построение своей собственной системы на базе двух физических машин. При этом Linux-система обычно работает в роли эмулятора сетевого соединения и конечной станции обработки информации, а Windows — как исследуемая база, на которой выполняется зловредный код. В сети свободно распространяются как готовые решения — например Truman, так и примеры Linux-систем, например REMnux и SIFT Workstation.

Безусловно, Вы можете сами создать любую аналогичную систему на базе любимого дистрибутива Linux (настоятельно рекомендую Ubuntu, но не потому что являюсь её фанатом, а потому что к сожалению специализированный софт был заточен под Debian, а сейчас — почти всегда под Ubuntu), дополнив её необходимым софтом и скриптами по образу и подобию описанных выше или по собственному разумению. Однако описание создания таких систем чрезвычайно сложно и длительно, поэтому я приведу ряд ссылок на проекты, которые могут быть интересны и полезны в такой работе.

— Невидимый прокси-сервер для перехвата и анализа http/https-трафика, используемого для связи с C&C и скачивания модулей. Пример — Burp Suite.
— Симулятор интернета, например INetSim.
— Централизованная система восстановления образов, например FOG.
— Система анализа дампов памяти, лучшая имхо тут Volatality Framework.
— Антивирусная система ClamAV для автоматизации классификации найденных зловредов. Я сознательно не пишу коммерческие антивирусы не по причине убеждённости, что ClamAV круче (что неверно), а по причине возможности добавления собственных сигнатур в ClamAV, чего нет в коммерческих вариантах. В крайнем случае можно использовать для тех же целей YARA.
— Утилиты для анализа и деобфускации JS, PDF, Flash, java-скриптов, парсинга файловой системы Windows, работы с сигнатурами файлов и распаковки — всё это есть в большом количестве в сети, описать всё невозможно и всегда является делом вкуса. В частности, ряд таких утилит упомянут на сайте проекта REMnux и входит в его состав.

На этой оптимистической ноте я заканчиваю (?) свой опус, если всё же возникнут вопросы — буду рад отписаться в комментах. Спасибо тем, кто дотерпел и дочитал это до конца 🙂

Источник

Как решить, когда запускать различные компоненты приложений Android в отдельном процессе

Здесь я прочитал следующие утверждения

—supports an android:process attribute that can specify a process in which that component should run. One can set this attribute so that each component runs in its own process or so that some components share a process while others do not.

Я хочу знать, в каких сценариях разработчик хотел бы это сделать и запускать разные компоненты в разных процессах и какую выгоду он получит от этого?

Другое заявление, которое я прочитал, – это

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

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

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

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

То же самое относится к браузеру. Если одна веб-страница неверно работает, она выводит на экран весь браузер, если веб-страницы, открытые на других вкладках, недоступны. Следовательно, была построена многопроцессная архитектура.

Вот фрагмент файла манифеста хрома:

Вот вывод оболочки adb:

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

Это позволяет компонентам в разных приложениях совместно использовать процесс, уменьшая использование ресурсов.

Резюме преимуществ:

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

Обновление 1 : добавление комментария @Budius

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

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

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

Вы можете прочитать больше здесь

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

Service которую вы объявляете в отдельном процессе, может быть либо приватной для приложения:

Или он может быть глобальным:

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

This allows components in different applications to share a process, reducing resource usage.

Источник

Are processes «sandboxed» by hardware?

1 Answer 1

If you count MS-DOS as an «operating system», then processes can do anything (and aren’t monitored). Even Windows95 doesn’t have real memory protection, and a buggy process can crash the machine by scribbling over the wrong memory.

If you only count modern OSes with privilege separation (Unix/Linux, Windows NT and derivates), then processes are sandboxed.

AFAIK, there aren’t really systems where there’s monitoring of any kind other than «fault if you try to do something». The kernel sets the boundaries, and the user-space process gets a fault if it tries to go outside them.

If you’re imagining that maybe the kernel looks at what an unprivileged process does, and adapts accordingly, then no, that’s not what happens.

https://en.wikipedia.org/wiki/Memory_protection: Usually achieved by giving each process its own virtual address space (virtual memory). This is hardware-supported: every address your code uses is translated to a physical address by a fast translation cache (TLB), which caches the translation tables set up by the OS (aka page tables).

A process can’t directly modify its own page tables: it has to ask the kernel to map more physical memory into its address space (e.g. as part of malloc()). So the kernel has a chance to verify that the request is ok before doing it.

Also, a process can ask the kernel to copy data to/from files (or other things) into its memory space. (write/read system calls).

Источник

Sandboxie как пользоваться

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

Но не стоит рисковать и запускать потенциально опасное ПО на своём компьютере без какой-либо защиты. В данном случае Sandboxie предоставляет возможность запуска программ в специальной среде, где вы можете проследить за тем, как себя будет вести запускаемая программа.

Как работает эта программа

Принцип работы Sandboxie заключается в создании системном диске определённого ограниченного пространства с симуляцией работы системы. Данное пространство закрыто от основной системы, что позволяет не выносить все изменения в нём за его пределы. По завершению работы с файлами в «песочнице» вся информация очищается, поэтому не стоит боятся, что у вас на компьютере где-то останется вирус, пускай и в закрытом дисковом пространстве.

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

Рассмотрим работу в программе более подробно.

Меню «Файл»

По умолчанию интерфейс «песочницы» не представляет из себя ничего интересного. Управляющие элементы расположены только в верхнем меню. Рассмотрим более подробно параметр «Файл». По клику на него появляется контекстное меню со следующими параметрами:

Меню «Вид»

При нажатии на кнопку «Вид» вы получите доступ к пунктам, отвечающим за отображение элементов в интерфейсе программы (пункты меню «Программы» и «Файлы и папки»).

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

Элемент «Песочница»

Здесь сосредоточен основной функционал программы. Этот элемент меню отвечает непосредственно за работу с «песочницей». Рассмотрим его содержимое более подробно:

Пункт «Настроить»

Как ясно из названия – этот пункт меню отвечает за настройку программы. С его помощью можно настроить следующее:

Преимущества и недостатки программы

Программа имеет свои преимущества, но и не лишена недостатков.

Преимущества

Недостатки

Как запустить программу в «песочнице»

Рассмотрим работу программы на примере запуска в её среде другой программы, которая имеет в своём установочном файле нежелательное ПО:

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

Источник