Xtajit dll что это такое

Обновлено: 21.11.2024

64-разрядные приложения для Windows на Arm находятся в стадии разработки: некоторые из них являются родными, многие хорошо работают с новой 64-разрядной эмуляцией, но другим придется подождать дополнительной поддержки в инсайдерских сборках Windows.

13-дюймовый Surface Pro X работает под управлением Windows 10 на базе процессора Microsoft SQ1 на базе ARM, который был разработан совместно с Qualcomm.

Когда Microsoft впервые выпустила Windows 10 на Arm, она могла запускать только 32-разрядные приложения x86 в режиме эмуляции. Microsoft сообщила нам, что их телеметрия показала, что основная часть приложений Windows, которые клиенты хотели запускать, имели 32-разрядные версии, особенно старые приложения, разработчики которых вряд ли перекомпилировали их для Arm. Но это никоим образом не распространяется на все приложения Windows.

Многие игры являются 64-разрядными, но Microsoft сообщила нам, что игры для начальных устройств «не предназначены для целевого покупателя». Доступны 32-разрядные версии Adobe Photoshop, Illustrator, InDesign и Dreamweaver, но они относятся к более ранней версии (Creative Cloud 2018) и не содержат новых функций.

CorelDRAW по-прежнему имеет 32-разрядную версию, но новые функции на основе искусственного интеллекта работают только в 64-разрядной версии. Многие программы установки, даже для 32-разрядного программного обеспечения, также являются 64-разрядными.

Эмуляция 64-разрядной версии появится в Windows на Arm, чтобы помочь в этом. Он все еще находится в инсайдерской сборке, но результаты тестирования обнадеживают.

Инструменты для перехода на 64-разрядную версию

Возможно, Microsoft надеялась, что многие разработчики будут перекомпилировать приложения в виде нативных версий Arm, потому что причина, по которой они были 64-разрядными, часто заключалась в первую очередь в соображениях производительности, поэтому запускать их в эмуляции было бы не идеально.< /p>

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

Приобретение Microsoft компании jClarity означало, что она взяла на себя работу по портированию OpenJDK на Arm для Windows 10. Пока нет ни IIS, ни Go-lang, но у Python и Rust есть нативные сборки. Пакет совместимости OpenCL и OpenGL изначально был разработан, чтобы помочь Adobe перенести родной Photoshop, который в значительной степени зависит от ускорения графического процессора, в Windows 10 на Arm. Существует предварительная версия, которая поддерживает другие приложения OpenCL и OpenGL, но только для OpenCL 1.2 и более ранних версий и OpenGL 3.3 и более ранних версий.

Но в то время как разработчики быстро сделали свои приложения нативными для устройств Apple M1 Arm, прогресс в Windows был медленнее — даже для собственных приложений Microsoft. Office и Edge работают изначально, как и версия Minecraft для Windows 10 (Bedrock), но не исходная версия Java (требуется более поздняя версия OpenGL). Visual Studio Code только недавно поддерживается на Arm, Power Toys по-прежнему блокируется рядом зависимостей), и в настоящее время нет планов по выпуску собственной версии Visual Studio для Arm. Microsoft ожидает, что разработчики будут выполнять кросс-компиляцию из более мощной системы x86, а не выполнять свою работу по разработке на ПК Arm, хотя разработчики Clang создали собственный компилятор для Windows на Arm, который запускает сборки в два раза быстрее, чем в эмуляции. /p>

Adobe выпустила версию Lightroom для ARM для Windows и компьютеров Mac M1 в декабре, а также существует бета-версия Photoshop для ARM64; в последнем выпуске добавлены некоторые ключевые инструменты, такие как точечная восстанавливающая кисть и заливка и перемещение с учетом содержимого. Но поскольку вы не можете запустить две версии приложения Creative Cloud для настольных ПК, а для бета-версии требуется версия 5.3 или более поздняя (которая будет устанавливать только 64-разрядные приложения), вы не можете установить более старые 32-разрядные приложения Adobe для работы в эмуляции вместе с это — и дизайнеры обычно используют более одного приложения Creative Cloud в своем рабочем процессе.

Автономный установщик самой последней 64-разрядной версии Photoshop также не работает из-за системных требований, но мы смогли установить 64-разрядные версии Creative Cloud 2019 для Windows нескольких приложений Adobe (включая Photoshop) вместе с родной бета-версией Photoshop. и они хорошо работали с новой 64-битной эмуляцией. Часто сложнее всего получить 64-разрядную версию: умные установщики часто автоматически устанавливают 32-разрядную версию, поэтому вам может потребоваться найти 64-разрядную версию и установить ее напрямую.

Состояние 64-битной эмуляции

Способ, которым Windows эмулирует приложения x86 в программном обеспечении на Arm, основан на том, как он эмулирует приложения x86 с помощью эмуляции аппаратных инструкций на ПК с архитектурой x64 — уровне абстракции «Windows на Windows». WoW64 не совсем то же самое на ARM64 (где он на самом деле эмулирует приложения x86 и ARM32, используя XTAJIT.DLL и WOWARMW.DLL соответственно, потому что ряд входящих приложений Windows, таких как Store, все еще 32-разрядные на Arm), но как Microsoft сообщила нам в то время, добавление поддержки x64 потребует больше работы, и это заняло некоторое время.

Первые инсайдерские версии эмуляции x64 вышли в конце 2020 года.В то время Хари Пулапака, главный менеджер группы разработчиков ядра Windows, указал, что окончательная версия 64-разрядной эмуляции должна запускать приложения так же быстро или — благодаря большему адресному пространству, доступному для 64-разрядных приложений, и тому, как 64 -битный код использует реестры — быстрее, чем 32-битный.

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

Приложения x64, которые мы тестировали на оригинальном Surface Pro X, в основном работали хорошо, хотя некоторые приложения аварийно завершали работу или просто закрывались, как только мы их открывали (а некоторые аварийно завершали работу в первый раз, но затем успешно работали). Для лучшей производительности запускайте приложения дважды: в первый раз код преобразуется для работы на Arm; во второй раз он запускается из кеша (и Windows провела некоторую дальнейшую оптимизацию во время кеша, что еще больше повысило производительность).

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

64-разрядные версии Signal, Slack, Bluestacks, Power BI Desktop, GIMP, Photoshop и приложения Xbox установлены и работают нормально. Приложения, требующие установки и запуска Uranium framework, но работающие медленно. Sketchbook от Autodesk имел отличную производительность даже для требовательных инструментов рисования, но был подвержен сбоям; у нас были аналогичные проблемы с Affinity Photo, который работал хорошо, за исключением случаев, когда он неожиданно закрывался.

У других 64-разрядных приложений было больше проблем. CorelDRAW и PHOTO-PAINT установились и открылись, но тут же закрылись. Camtasia была установлена от имени администратора, но вылетела при попытке записи. Это те проблемы, которые, вероятно, будут быстро исправлены, поскольку новые инсайдерские сборки выходят с приложениями DLL, которые требуются. Есть также такие приложения, как клиент синхронизации Dropbox, для которых требуются собственные драйверы, которые Dropbox не предоставляет, поэтому они вообще не будут работать в эмуляции.

Мы сравнили производительность 32-разрядной и 64-разрядной эмуляции для Photoshop, GIMP и Power BI Desktop в различных задачах (хотя нам не всегда удавалось найти одну и ту же версию программного обеспечения). Для обычных задач редактирования 32-разрядная версия Photoshop, работающая в режиме эмуляции, часто была немного быстрее, чем родная 64-разрядная и эмулированная 64-разрядная версии, которые имели очень схожую производительность: поскольку обе находятся в стадии бета-тестирования и не были полностью оптимизировано, что не является неожиданным, но разница обычно заключалась в том, что для завершения эффекта требовалось две и три секунды, и многие общие задачи редактирования выполнялись мгновенно в обеих версиях. Нативная версия имела явное преимущество в сложной последовательности задач, таких как фотообъединение панорам: она была более чем в два раза быстрее, чем 32-разрядная версия, и в четыре раза быстрее, чем 64-разрядная версия в эмуляции.

Точно так же простое редактирование фотографий было немного быстрее в 32-битной версии GIMP, чем в 64-битной версии, пока мы не запустили более сложные скриптовые действия, когда 64-битная эмуляция была в два-четыре раза быстрее.

Power BI Desktop также немного быстрее загружал отчеты и импортировал данные из Excel при работе в 32-разрядной эмуляции, хотя производительность 64-разрядной эмуляции значительно улучшилась с последней инсайдерской сборкой Windows. Microsoft явно усердно работает над расширением и оптимизацией 64-разрядной эмуляции на Arm.

Подготовка на стороне сервера

Microsoft объявила о своих планах перенести Windows Server на Arm задолго до выпуска Windows для ноутбуков Arm. Он использовался для запуска внутренней инфраструктуры Azure, такой как хранилище, индексация и поиск, где особенно важны маломощное, недорогое оборудование и эффективность вычислений. Все могло быть отложено из-за того, что поставщики материнских плат для серверов отложили или отменили проекты, но Microsoft протестировала Windows Server на кремнии Arm от Ampere Altra, Fujitsu и Marvell ThunderX2 для Azure, и Marvell заявила в 2019 году, что ее портфель Arm используется для «внутренних, серверы производственного уровня».

На Arm DevSummit 2020 технический специалист Арун Кишан из команды ядра Windows сказал, что Microsoft также изучает возможность использования Windows Server на ARM64 для услуг размещения виртуальных машин и работает над сертификацией Arm on SystemReady для серверов, которая будет включать в себя запуск Windows Server, «чтобы сделать их на один шаг ближе к возможности развертывания в Microsoft Azure».

Это не означает, что полноценный Windows Server на Arm обязательно не за горами, но 64-разрядная эмуляция будет иметь решающее значение для рабочих нагрузок сервера Arm, которые они захотят запускать, и может быть еще одной причиной для Microsoft добавить его клиенту Windows.

Сервер Arm в Azure также заполнит важный недостающий элемент для разработчиков, ориентирующихся на Windows 10 на Arm: возможность создавать систему CI/CD (непрерывная интеграция/непрерывное развертывание) с помощью такого инструмента, как Azure Pipelines, чтобы они могли легко протестировать и внедрить исправления ошибок и новый код.

Разработчикам необходимо иметь возможность работать непосредственно на устройствах Arm для тестирования, — говорит Эд Вьельметти, который руководит проектом экосистемы Works On ARM в Equinix. Works On Arm предоставляет проекты с открытым исходным кодом с инфраструктурой Arm, включая Go, Node.js и несколько библиотек Python, чтобы помочь разработчикам заставить их код работать на Arm, чтобы его можно было запускать в центрах обработки данных.

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

Несколько проектов с открытым исходным кодом заинтересованы в переносе своего кода на Windows, сказал нам Вильметти, но они хотят работать на Windows Server, а также на настольных Windows; это еще не доступно для Arm. Им также нужны виртуальные машины Arm в облаке, чтобы они могли проводить масштабное тестирование. Это блокирует NodeJS и зависящие от него инструменты вроде GitHub Desktop.

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

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

И для этого автоматизированного тестирования требуется облачная инфраструктура, в данном случае с виртуальными машинами Arm.

"Доступность облачной инфраструктуры меняет ситуацию, потому что вы можете начать поддерживать проекты, скорость изменений которых превышает скорость, с которой может справиться аппаратное обеспечение настольных компьютеров", – пояснил Вьельметти. «Без такого полного доступа к этому ресурсу вычислений действительно трудно представить, что большие проекты очень удачливы в поддержании какой-либо частоты выпуска. Если вы пытаетесь разработать сложную систему, то, как быстро я смогу создать новую версию и протестировать ее, действительно имеет большое значение. В отсутствие этой экосистемы разработчикам Windows будет сложнее запустить этот благотворный цикл «создать, протестировать, попробовать».

Надеюсь, что когда Azure Pipelines наконец-то получат виртуальные машины Arm, это откроет доступ многим разработчикам к переносу кода в Windows на Arm. Тем временем эмуляция постоянно совершенствуется, чтобы поддерживать более широкий, если не полный, спектр программного обеспечения.

Еженедельный информационный бюллетень Microsoft

Будьте инсайдером Microsoft в своей компании, прочитав эти советы, рекомендации и памятки по Windows и Office.
Доставка по понедельникам и средам

Эмулятор WOW64 работает в пользовательском режиме. Он обеспечивает интерфейс между 32-разрядной версией Ntdll.dll и ядром процессора и перехватывает вызовы ядра. Эмулятор WOW64 состоит из следующих библиотек DLL:

Wow64.dll предоставляет базовую инфраструктуру эмуляции и переходники для функций точки входа Ntoskrnl.exe.
Wow64Win.dll предоставляет переходники для функций точки входа Win32k.sys.
(только x64) Wow64Cpu.dll обеспечивает поддержку запуска программ x86 на x64.
(только для Intel Itanium) IA32Exec.bin содержит программный эмулятор x86.
(только для Intel Itanium) Wowia32x.dll обеспечивает интерфейс между IA32Exec.bin и WOW64.
(только для ARM64) xtajit.dll содержит программный эмулятор x86.
(только для ARM64) wowarmw.dll обеспечивает поддержку запуска программ ARM32 на ARM64.

Эти библиотеки DLL вместе с 64-разрядной версией Ntdll.dll являются единственными 64-разрядными двоичными файлами, которые можно загрузить в 32-разрядный процесс. В Windows 10 на ARM двоичные файлы CHPE (Compiled Hybrid Portable Executable) также могут быть загружены в 32-разрядный процесс x86.

При запуске Wow64.dll загружает x86-версию Ntdll.dll (или версию CHPE, если она включена) и запускает свой код инициализации, который загружает все необходимые 32-разрядные библиотеки DLL. Почти все 32-разрядные библиотеки DLL являются неизмененными копиями 32-разрядных двоичных файлов Windows, хотя некоторые из них загружаются как CHPE из соображений производительности. Некоторые из этих библиотек DLL написаны так, чтобы вести себя в WOW64 иначе, чем в 32-разрядной Windows, обычно потому, что они совместно используют память с 64-разрядными системными компонентами. Все адресное пространство пользовательского режима, превышающее 32-битное ограничение, резервируется системой.Дополнительные сведения см. в разделе Производительность и потребление памяти в WOW64.

Вместо использования последовательности вызовов системных служб x86 32-разрядные двоичные файлы, выполняющие системные вызовы, перестраиваются для использования пользовательской последовательности вызовов. Перехват этой последовательности вызовов недорог для WOW64, поскольку он остается полностью в пользовательском режиме. При обнаружении пользовательской последовательности вызовов ЦП WOW64 возвращается в собственный 64-разрядный режим и вызывает Wow64.dll. Преобразование выполняется в пользовательском режиме, чтобы уменьшить влияние на 64-разрядное ядро и снизить риск ошибки в преобразовании, которая может вызвать сбой в режиме ядра, повреждение данных или дыру в безопасности. Преобразователи извлекают аргументы из 32-битного стека, расширяют их до 64-битных, а затем выполняют собственный системный вызов.

Переменные среды

Когда 32-разрядный процесс создается 64-разрядным процессом или 64-разрядный процесс создается 32-разрядным процессом, WOW64 устанавливает переменные среды для созданного процесса, как показано в следующей таблице.

< /tbody>

Процесс	Переменные среды
64-разрядный процесс	PROCESSOR_ARCHITECTURE=AMD64 или PROCESSOR_ARCHITECTURE=IA64 или PROCESSOR_ARCHITECTURE=ARM64 ProgramFiles=%ProgramFiles% ProgramW6432=%ProgramFiles% CommonProgramFiles=%CommonProgramFiles% CommonProgramW6432=%CommonProgramFiles% Windows Server 2008, Windows Vista, Windows Server 2003 и Windows XP: переменные среды ProgramW6432 и CommonProgramW6432 были добавлены, начиная с Windows 7 и Windows Server 2008 R2.
32-разрядный процесс	PROCESSOR_ARCHITECTURE=x86 PROCESSOR_ARCHITEW6432=%PROCESSOR_ARCHITECTURE% ProgramFiles =%ProgramFiles(x86)% ProgramW6432=%ProgramFiles% CommonProgramFiles=%CommonProgramFiles(x86)% CommonProgramW6432=%CommonProgramFiles%

Процесс

Переменные среды

64-разрядный процесс

PROCESSOR_ARCHITECTURE=AMD64 или PROCESSOR_ARCHITECTURE=IA64 или PROCESSOR_ARCHITECTURE=ARM64
ProgramFiles=%ProgramFiles%
ProgramW6432=%ProgramFiles%
CommonProgramFiles=%CommonProgramFiles%
CommonProgramW6432=%CommonProgramFiles%
Windows Server 2008, Windows Vista, Windows Server 2003 и Windows XP: переменные среды ProgramW6432 и CommonProgramW6432 были добавлены, начиная с Windows 7 и Windows Server 2008 R2.

32-разрядный процесс

PROCESSOR_ARCHITECTURE=x86
PROCESSOR_ARCHITEW6432=%PROCESSOR_ARCHITECTURE%
ProgramFiles =%ProgramFiles(x86)%
ProgramW6432=%ProgramFiles%
CommonProgramFiles=%CommonProgramFiles(x86)%
CommonProgramW6432=%CommonProgramFiles%

Глобальные хуки

Функция SetWindowsHookEx может использоваться для внедрения DLL в другой процесс при соблюдении следующих условий:

32-разрядная библиотека DLL может быть внедрена только в 32-разрядный процесс, а 64-разрядная библиотека DLL может быть внедрена только в 64-разрядный процесс. Невозможно внедрить 32-разрядную DLL в 64-разрядный процесс или наоборот.
32-разрядные и 64-разрядные библиотеки DLL должны иметь разные имена.
Архитектуры библиотеки DLL и процесса должны совпадать. Например, вы не можете внедрить 32-разрядную x86-библиотеку DLL в 32-разрядный процесс ARM.

Учтите, что WH_MOUSE, WH_KEYBOARD, WH_JOURNAL*, WH_SHELL и низкоуровневые хуки могут быть вызваны в потоке, который установил хук, а не в потоке, обрабатывающем хук. Для этих ловушек возможно, что будут вызываться как 32-битные, так и 64-битные ловушки, если 32-битная ловушка опережает 64-битную в цепочке ловушек. Дополнительную информацию см. в разделе Использование хуков.

Обсудите и поддержите wow64cpu, wowarmhw, xtajit и т. д. файлы .dll отсутствуют? в Windows 10 Network and Sharing для решения проблемы; Когда я искал их в Google, мне показалось, что это важно. Но я их никогда не удалял. Почему они будут отсутствовать. Обсуждение в разделе «Сеть и общий доступ Windows 10», начатое пользователем ryzot, 6 января 2022 г.

отсутствуют файлы wow64cpu, wowarmhw, xtajit и т. д.?

отсутствуют файлы wow64cpu, wowarmhw, xtajit и т. д.? - Похожие темы - wow64cpu wowarmhw xtajit

отсутствуют файлы wow64cpu, wowarmhw, xtajit и т. д.?

отсутствуют файлы .dll

отсутствуют файлы .dll: всякий раз, когда я пытаюсь запустить определенные приложения, такие как minecraft, discord и steam, я получаю тот же код ошибки 0xc0000006, что-то о том, что они несовместимы. с Windows или что-то еще; Я пытался запустить проверки sfc и dism, но они встречают ошибки и не могут.

wow64cpu, wowarmhw, wow64, xtajit и wow64win на KnownDll

Файл DLL отсутствует

Отсутствует файл DLL: я недавно обновил свою Windows 10 до вер. 1903. У меня 64-битная операционная система. Когда я запускаю компьютер или даже перезагружаю компьютер, я получаю следующее сообщение: Возникла проблема при запуске.

Отсутствуют файлы DLL

Отсутствуют файлы DLL. Я без проблем запускал очень старую версию Quicken в Windows 10. По причинам, не связанным с Quicken, моя служба поддержки производителей рекомендовала мне переустановить Windows 10, что я и сделал. Однако, когда я переустановил Quicken, он не запустился так, как раньше.

Отсутствуют файлы .dll

Отсутствуют файлы .dll: Помогите! Все приложения Microsoft вылетают сразу после запуска. Все говорят, что SharedLibrary.dll и mrt100_app.dll не найдены. Кто-нибудь знает, как я могу исправить проблему или повторно загрузить файлы .dll.

файл dll отсутствует

отсутствует файл dll: Пожалуйста, мне нужна помощь. Я хочу установить глобальный картограф, а он говорит, что lti_dsdk_8.5.dll не найден.я пытался получить его бесплатно в Интернете, но не удалось. может кто-нибудь помочь мне, пожалуйста.

Отсутствует файл DLL

Отсутствует файл DLL: не удается понять, где и почему возникает эта ошибка. Я заменил свой принтер, который был HP 6700. Я использовал панель управления и удалил ее из устройств и принтеров. Затем я установил новый, HP 7610. Он работает нормально. Но каждый раз, когда я запускаю систему.

Autoruns — это бесплатный инструмент Sysinternals от Microsoft, который перечисляет все программы, которые автоматически запускаются на компьютере с Windows. … При использовании Autoruns вам будет представлен список всех исполняемых файлов на вашем компьютере, которые запускаются автоматически.

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

Используйте функцию сравнения Autoruns, чтобы упростить поиск нежелательного программного обеспечения, сохраняющегося на вашем устройстве. Вы можете сделать это, запустив Autoruns на чистом устройстве, выбрав «Файл», а затем «Сохранить». Вывод теперь будет сохранен как файл «AutoRuns Data» с расширением «. arn’Автозапуск.

Какова цель Autoruns?

Autoruns — бесценное дополнение к набору программных инструментов любого компьютерщика. Он позволяет отслеживать и контролировать все программы (и программные компоненты), которые автоматически запускаются в Windows (или в Internet Explorer).

Что такое автозапуск изображений?

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

Можно ли удалить автозапуск?

Autoruns v14 не может отключить или удалить записи с ошибкой. Но v13 работает хорошо. Когда я убираю записи, они остаются отмеченными после повторного запуска автозапуска, а также некоторые записи не могут быть сняты с ошибкой «Не удалось отключить».

Безопасен ли Microsoft Autoruns?

Microsoft: поскольку это бесплатное ПО от Microsoft Sysinternals, вы можете быть уверены, что Autoruns безопасен в использовании и полностью совместим с Windows.

Что такое автозапуск Windows 10?

Этот портативный инструмент при запуске предоставляет полный список всех программ, которые настроены для запуска при запуске Windows. … Autoruns — это утилита очистки запуска, похожая на утилиту MSCONFIG, но более мощная.

Что означают цвета в Autoruns?

Некоторые элементы в Autoruns выделены красным или желтым цветом: Желтый означает, что элемент существует в реестре, но файл не найден. Красный означает, что элемент есть в реестре, файл на месте, но строка издателя пуста.

Что означает розовый цвет в Autoruns?

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

Что означает красный цвет в Autoruns?

Что означает желтый цвет в Autoruns?

Что такое Xtajit DLL?

(только для ARM64) xtajit. dll содержит программный эмулятор x86. (только для ARM64) wowarmw. dll обеспечивает поддержку запуска программ ARM32 на ARM64.

Как получить доступ к Autoruns?

0:434:19Как использовать Microsoft Autoruns – YouTubeYouTube

Что такое Iexplorer EXE?

Файл iexplore.exe называется исполняемым файлом Microsoft Internet Explorer. Графический пользовательский интерфейс файла iexplore.exe состоит из графических интернет-страниц, просматриваемых пользователем.

Что такое система WOW64?

При вычислениях на платформах Microsoft WoW64 (32-разрядная версия Windows на 64-разрядной версии Windows) представляет собой подсистему операционной системы Windows, способную запускать 32-разрядные приложения в 64-разрядной версии Windows.

Что такое iExplorer и безопасно ли это?

Это на 100 % безопасно. В целях вашей конфиденциальности и безопасности iExplorer никогда не получит доступ ни к одному из ваших личных паролей на вашем iPhone или iPad. Он также не получит доступа к вашим Touch ID, кредитным картам и другой конфиденциальной информации, поэтому никакая эта информация также не загружается в Интернет.

Как получить iExplorer бесплатно?

0:093:45Как получить iExplorer бесплатно! *РАБОТАЕТ* – YouTubeYouTube

Что делает эмулятор WOW64 в Windows?

WOW64 — это эмулятор x86, который позволяет 32-разрядным приложениям на базе Windows беспрепятственно работать в 64-разрядной версии Windows.Это позволяет 32-разрядным (x86) приложениям Windows беспрепятственно работать в 64-разрядной (x64) Windows, а также 32-разрядным (x86) и 32-разрядным (ARM) приложениям Windows беспрепятственно работать в 64-разрядной ( ARM64) Windows.

Несколько дней назад я заметил, что исследователь безопасности Колин Харди опубликовал видео, в котором он продемонстрировал технику, которую вредоносное ПО использовало для проникновения в целевую систему. В двух словах, двоичная полезная нагрузка была помещена в доступное для записи место с исполняемым файлом Microsoft OneDrive, замаскированным под системную DLL. Это позволяло загружать такую DLL в программу OneDrive каждый раз, когда пользователь входил в систему.

У меня возник вопрос: как возможно, что вредоносное ПО может так легко внедряться в один из собственных процессов Microsoft в последней версии Windows 10?

Эта запись в блоге прольет свет на этот вопрос.

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

хитрости

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

Итак, если вы прочитаете где-то в середине, вы увидите, что DLL будет сначала загружена из:

Если такая DLL не является одной из так называемых KnownDLL, ее можно найти в следующем разделе реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs

Однако проблема с KnownDLL заключается в том, что список очень короткий. Например, это библиотеки DLL, которые перечислены в моей Windows 10:

Все это означает, что если кто-то может записать в каталог, из которого запускается исполняемый файл, он может создать клон системной DLL, которая импортируется исполняемым файлом (и не указана в списке KnownDlls) и тому подобное. DLL будет загружена в процесс-жертву и выполнена в его контексте.

Поэтому давайте посмотрим, как легко мы сможем это воспроизвести.

Сначала давайте посмотрим, какие файлы находятся в папке, в которой запускается исполняемый файл OneDrive:

Есть только два исполняемых файла и нет библиотек DLL. Это хорошо для вредоносных программ. OneDrive.exe — это двоичный файл, который запускается каждый раз при открытии OneDrive. Для вредоносных программ также хорошо, что OneDrive.exe запускается автоматически, когда каждый пользователь входит в систему. Это гарантирует сохранение. Это делается самой Windows и не должно вызывать никаких подозрений у антивирусного программного обеспечения.

Тогда посмотрим, какие модули импортирует OneDrive.exe. Для этого я буду использовать свое приложение WinAPI Search:

Тогда давайте выберем модуль, которого нет в списке KnownDLL. Вредоносное ПО, с которым работал Колин, использовало Version.dll , так что давайте воспользуемся и им.

Далее нам нужно посмотреть, какие функции процесс OneDrive.exe импортирует из Version.dll . Для этого мы также будем использовать приложение WinAPI Search:

Когда мы получим список импорта, обязательно отсортируйте его по столбцу «Модуль из/в» и прокрутите до раздела Version.dll. Как видите, из этого модуля импортируются только три функции:

Это позволит нам очень легко закодировать нашу поддельную версию.dll для загрузки в процесс OneDrive.exe.

Создание DLL Hijack

Давайте откроем Visual Studio, создадим новый проект и выберем Библиотека динамической компоновки (DLL) для C++.

При создании нового проекта DLL добавьте в него новый файл в папке «Файлы заголовков». Вы можете использовать шаблон файла заголовка (.h), просто не забудьте переименовать его в exports.def .Затем поместите в него имена импортированных функций, которые мы нашли выше, как таковые:

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

Перейдите в Linker -> Input -> "Module Definition File" и добавьте в него файл export.def.
Затем перейдите в Linker -> General -> "Output File" и измените имя полученного модуля на $(OutDir)version$(TargetExt), чтобы убедиться, что вы скомпилировали его в файл version.dll.
Кроме того, я бы также перешел на C/C++ -> Генерация кода -> "Библиотека времени выполнения" и установил многопоточность (/MT) . Это гарантирует, что DLL компилируется без каких-либо зависимостей от более новых библиотек run-tine, которые могут отсутствовать на целевой машине.

Затем в dllmain.cpp добавьте минимальный код для проверки нашего эксплойта:

В приведенном выше коде мы только что создали три ошибки для импортированных функций. Они должны быть у нас, иначе загрузчик отклонит нашу DLL при загрузке в OneDrive.exe. Но на самом деле нам не нужно предоставлять какой-либо код в этих функциях, так как мы не заинтересованы в их запуске. Таким образом, мы только что создали бесконечную задержку в каждой функции с помощью Sleep API. Это остановит вызывающий поток внутри процесса OneDrive.exe.

Наконец наша «полезная нагрузка» попадает в DllMain. Он будет выполнен сразу после сопоставления OneDrive.exe с памятью. Это также очень удобно для вредоносного ПО, так как в это время никакому коду внутри OneDrive.exe еще не суждено запуститься (кроме кода в функциях DllMain в ранее загруженных модулях).

В нашем случае мы просто покажем системное модальное окно сообщения о том, что наша фальшивая DLL была загружена. Это говорит нам о том, что код вредоносного ПО выполнился.

Подтверждение концепции

Скомпилируйте приведенный выше проект DLL в качестве конфигурации выпуска и переместите получившуюся поддельную версию.dll на целевой компьютер в каталог %UserProfile%\AppData\Local\Microsoft\OneDrive. Обратите внимание, что нет приглашения UAC для перемещения этого файла. Это означает, что почти каждый может это сделать.

Затем перезагрузите компьютер, войдите в систему под этим пользователем и дождитесь результата:

Наша поддельная версия.dll была загружена в процесс OneDrive, который, кстати, Microsoft навязывает почти каждому пользователю Windows, что является очень удобным способом автозапуска (т.е. постоянство) для вредоносного ПО.

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

Недоступное для записи местоположение

К счастью для нас, Microsoft предусмотрела возможное решение. На диске есть места, для записи в которые требуются права администратора. И одним из таких мест является каталог %ProgramFiles% или %ProgramFiles(x86)% для 32-битных программ. (Кстати, это рекомендуемое место для размещения исполняемых файлов Windows.)

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

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

Динамическая загрузка DLL

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

Основная идея заключается в том, что, загружая свои DLL с полным путем, вы устраняете любые неоднозначности порядка поиска DLL.

Позвольте мне привести пример того, как вы могли бы загрузить функции, которые мы видели выше, из подлинной Version.dll:

Или, если вы ориентируетесь на операционные системы более новые, чем Windows 7 (он также может работать в Windows 7, но требует наличия KB2533623), вы можете использовать следующий более новый метод с флагом LOAD_LIBRARY_SEARCH_SYSTEM32, который работает без явного указания системы. папка при загрузке DLL:

Наконец, с теми же ограничениями, наложенными на операционную систему (все, что старше Windows 7, или вам потребуется установить KB2533623), вы можете использовать следующий альтернативный метод указания порядка поиска в глобальном масштабе с помощью функции SetDefaultDllDirectories:

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

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

Защита целостности кода

Похоже, у Microsoft была хорошая идея с Code Integrity Guard или CIG. Это только в том случае, если они полностью реализовали это.

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

CIG также не очень хорошо задокументирован. Вы можете найти скудные ссылки на него в документации по функции SetProcessMitigationPolicy для флага ProcessSignaturePolicy. И в документации по структуре PROCESS_MITIGATION_BINARY_SIGNATURE_POLICY.

Основная проблема с CIG в нашем случае заключается в том, что мы не можем включить его через сам двоичный файл образа или через PE-файл. Если бы мы могли, любые попытки сопоставить неподписанную DLL были бы сорваны во время загрузки статически связанных модулей, таких как наша поддельная версия.dll .

В настоящее время CIG может быть включен процессом для самого себя, вызвав SetProcessMitigationPolicy :

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

Второй вариант включения CIG — это родительский процесс, когда дочерний процесс создается с помощью функции UpdateProcThreadAttribute с использованием расширенных атрибутов с флагом PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY и PROCESS_CREATION_MITIGATION_POLICY_PROHIBIT_DYNAMIC_CODE_ALWAYS_ON. Но чтобы этот вариант работал, процесс, который запускает OneDrive.exe или в нашем случае проводник Windows, должен его поддерживать, чего в настоящее время нет.

К сожалению, способ загрузки DLL в программы увяз в наследии Windows, что становится настоящим кошмаром для безопасности. И пока Microsoft не выпустит достойную версию Code Integrity Guard, на горизонте не появится гарантированного решения против перехвата DLL.

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

Обязательно ознакомьтесь с собственными предложениями Microsoft по безопасной реализации библиотек DLL и их общими передовыми практиками для разработчиков.

Читайте также: