Unauthorized.

Blue pill/red pill - the matrix has windows longhorn

2011.10.08

Blue pill/red pill - the matrix has windows longhorn

Автор: (c)Крис Касперски ака мыщъх

Совершенствование stealth-технологий в конечном счете (в середине 2006 года) привело к созданию rootkit'ов принципиально нового типа, которых практически невозможно обнаружить, а тем более остановить. Стоит только компьютеру проглотить "голубую пилюлю", как операционная система погружается в виртуальный мир, полностью контролируемый rootkit'ом. Прежний, реальный мир перестает существовать и, чтобы увидеть его, необходимо проглотить "красную пилюлю", над созданием которой бьются лучшие хакерские умы, но... пока не слишком успешно.

Введение

Не успела Windows Vista/Server Longhorn поступить в продажу, как была зверски взломана польской пани Жанной Рутковской (Joanna Rutkowska), выступившей 21 июля 2006 года на конференции SyScan (Сингапур) и двумя неделями позже - на Black Hat'е (3 августа, США, Лас-Вегас) где она и продемонстрировала rootkit нового поколения, получивший название "Blue Pill" ("Голубая Пилюля") - явный реверанс в сторону "Матрицы" (текст самой презентации вместе с кучей других полезных материалов и утилит можно найти на сайте Жанны: www.invisiblethings.org).

Пилюли

Рисунок 1. Выпив голубую пилюлю, мы попадем в виртуальный мир, выпив красную - обретаем способность видеть мир таким, какой он есть.

Реакция представителей Microsoft оказалась на удивление спокойной: подумаешь, подломали бету! Никто же и не утверждал, что взломать Висту/Longhorn невозможно! Идет нормальный процесс "обкатки" системы и чем больше ошибок будет выявлено на стадии бета-тестирования, тем меньше их окажется в финальной версии продукта. Однако Vista RC1, выпущенная двумя месяцами позже, не претерпела никаких изменений и по-прежнему остается уязвимой. Microsoft проанализировала ситуацию и, вместо того, чтобы заткнуть дыру, сделала вид, что никакой дыры здесь нет! (см. выступление одного из сотрудников Microsoft: http://blogs.msdn.com/windowsvistasecurity/archive/2006/08/07/691441.aspx).

Мол, с правами администратора (а "Голубая Пилюля" требует их) еще и не такое возможно! А, что, собственно говоря, с ними возможно?! Загрузить неподписанный драйвер, либо каким бы то ни было другим легальным способом проникнуть на уровень ядра нельзя, что доставляет множество проблем как самим администраторам, так и разработчикам. Во имя ее величества Безопасности с этим можно было бы и смириться, если бы Microsoft заткнула все лазейки, а так получается, что нас вынуждают поступиться частью свобод и удобств, предлагая взамен... ничего! Где логика?! Как всегда, логика на стороне Microsoft, преуспевшей только в одном - в продвижении своих глюкодромов на рынок.

Жанна Рутковская на конференции Black Hat

Рисунок 2. Жанна Рутковская на конференции Black Hat.

Жанна или Джоанна

Польское имя Жанны, записанное латиницей, многие переводчики переводят буквально - "Джоанна" (Joanna), забыв о том, что существует специальные правила транслитерации (и даже ГОСТ!), которые никто не отменял. Смотрели фильм "Joanna d'Arc"? Нет?! Значит, вы определенно не поляк, поскольку в американский прокат фильм вышел под названием "The Messenger: The Story of Joan of Arc", в то время как на французском имя главной героини записывается как "Jeanne d'Arc", то есть Joanna - эта Жанна, записанная на польский манер. И никакая она не "Джоанна". Эх, из чего же только не делают переводчиков. ;(

Жанна д'Арк (слева) и Жанна Рутковская (справа)

Рисунок 3. Жанна д'Арк (слева) и Жанна Рутковская (справа).

Что же касается выбора между "Рутковска" (Rutkowska) или "Рутковская", то тут правила транслитерации допускают определенную вольность: сохранить оригинальное написание - Рутковска (поимев при этом проблемы склонения) или переложить его на русский манер, добавив окончание "-ая" - Рутковская. Это уже как кому больше нравится. Подробнее о переводе польских имен можно прочитать на http://www.spelling.spb.ru/rosenthal/alpha/r149.htm и http://www.proz.com/kudoz/593898.

Внутри "blue pill"

"Голубая Пилюля" базируется на двух основных концепциях - обходе цифровой подписи драйверов (обязательной в x86-64 редакциях Windows, начиная с Vista Beta 2 build 5384) и установке гипервизора (hyper-visor), использующего технологии аппаратной виртуализации AMD Pacifica/Intel Vanderpool, позволяющие запускать операционную систему на эмуляторе, контролирующим все "интересные" события. В грубом приближении это можно проиллюстрировать на примере 80836 ЦП, поддерживающего режим "виртуального 8086" (он же V86), обеспечивающего одновременную работу нескольких MS-DOS сессий. Ну вот, а теперь появился режим "виртуального 386+", причем правильно спроектированный гипервизор (также называемый Монитором Виртуальных Машин - Virtual Machine Monitor, VMM) не позволяет гостевой системе определить: исполняется ли она на "живом" процессоре или нет.

Технология обхода цифровой подписи драйверов актуальна только для 64-битных версий Windows (в 32-битных загрузить неподписанный драйвер можно и так), а механизмы аппаратной виртуализации никак не связаны с конкретной осью и замечательно работают на Linux, BSD, Mac OS и т.д. (разумеется, при поддержке со стороны процессора). Любая ось, позволяющая хакеру пробиться на уровень ядра, может быть атакована.

Таким образом, "Голубая Пилюля" состоит из двух компонентов, лишь один из которых по-настоящему "голубой". Он-то и отвечает за погружение операционной системы в виртуальный мир. Другой компонент - независимая "затравка", специально спроектированная для обхода защиты 64-битных версий Windows и забрасывающая (точнее, сбрасывающая) на ядерный уровень любую полезную нагрузку, в роли которой вполне может выступать и обычный rootkit.

Два компонента

Рисунок 4. Два компонента "Голубой Пилюли" - один пробивается на уровень ядра, другой погружает ось в виртуальный мир.

Обход цифровой подписи

Механизм обхода цифровой подписи, предложенный Жанной, основан на модификации файла подкачки на секторном уровне (назовем его page-file attack). Сама атака состоит из шести этапов:

  1. Находим в каталоге /WINNT/System32/Drives редко используемый драйвер (например, NULL.SYS), считываем его содержимое и выделяем уникальную последовательность байт (сигнатуру), позволяющую однозначно отождествить его. Сигнатура должна находиться в ветке IRP_MJ_DEVICE_CONTROL процедуры DeviceDispatcher (адрес последней легко определить путем дизассемблирования драйвера), причем сигнатура не имеет права пересекать границы страницы (в файле подкачки соседние страницы не всегда оказываются рядом друг с другом), то есть должно выполняться условие: (virtual_address_of_signature % 1000h) + sizeof(virtual_address_of_signature) < 1000h;

  2. Запускаем программу "memory-eater", "съедающую" всю доступную память (например, путем вызова API-функции VirtualAlloc) и вынуждающую операционную систему свопиться на диск, вытесняя в том числе и ядерные компоненты (внимание! если параметр "DisablePagingExecutive", находящийся в ветке реестра HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\MemoryManagement, равен 1 (по умолчанию 0), ядерные компоненты вытесняться не будут! Изменения вступают в силу только после перезагрузки);

  3. Открываем устройство "\\.\C:" (логический диск) или "\\.\PHYSICALDRIVE0" (физический диск) API-функцией CreateFile и читаем/пишем на секторном уровне API-функциями ReadFile/WriteFile, соответственно. Также можно воспользоваться хорошо документированным интерфейсом SPTI, позволяющим передавать диску SCSI-команды через API-функцию DeviceIoControl, за что отвечает IOCTL-код IOCTL_SCSI_PASS_THROUGH_DIRECT (4D014h). Ось автоматически транслирует pseudo-SCSI команды в native-команды конкретного накопителя (например, IDE HDD). два недокументированных IOCTL-кода IOCTL_IDE_PASS_THROUGH и SCSIOP_ATA_PASSTHROUGH позволяют передать IDE-накопителям native-ATA команды, что дает над ними неограниченную власть, правда ухудшает совместимость (что, если у жертвы установлен SCSI-диск?!). Все вышеупомянутые интерфейсы требует администраторских прав, которые не всегда у нас есть, однако ASPI-интерфейс, разработанный компанией Adaptec, не отягощен такими ограничениями!!! И, хотя корректно установленный ASPI-драйвер (кстати говоря, исключенный из штатной поставки Windows много лет тому назад) дает доступ только к ATAPI-устройствам (таким как CD, DVD), достаточно часто в этот список попадают и жесткие диски, то есть атаку (теоретически) можно реализовать даже без администраторских прав!!! Если ASPI-драйвер на целевой машине не установлен, rootkit должен либо установить его самостоятельно (кстати, сам драйвер подписан и бесплатен), либо поискать другие драйвера, установленные приложениями, работающими с HDD-, CD- или DVD-дисками на низком уровне (дисковые редакторы, копировщики защищенных дисков, программы для прожига CD/DVD). Многие из них позволяют манипулировать жесткими дисками, не требуя прав администратора (подробнее обо всем этом можно прочитать в моей книге "Техника защиты лазерных дисков от копирования", черновую версию которой можно найти на ftp://nezumi.org.ru/, только помните, что сервер работает не всегда);

  4. Дождавшись выгрузки драйвера на диск (момент которого легко определить эвристическим путем -- при исчерпании оперативной памяти, система вытеснит часть страниц только что выделенных VirtualAlloc, скачкообразно увеличивая количество доступной физической памяти, объем которой легко определить API-функцией VirtualQuery), начинаем прочесывать диск на секторном уровне в поисках ранее обозначенной сигнатуры драйвера-жертвы;

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

  6. Вызываем API-функцию CreateFile, передавая ей имя хакнутого драйвера (в данном случае NULL.SYS) и... операционная система тут же считывает модифицированные страницы с диска, вызывает IRP_MJ_DEVICE_CONTROL, передавая shell-коду управление, ну а дальше, как говорится, дело техники!

Успешно осуществив атаку, Жанна (как и положено "белому" хакеру) тут же предложила несколько контрмер: самое простое, но не самое умное, что может сделать Microsoft - это заблокировать выгрузку ядерных компонентов на диск (тем более, что все необходимые ингредиенты у нее уже есть, достаточно только убрать из реестра ключ DisablePagingExecutive, пожизненно установив его значение в "1"). В результате мы потеряем некоторое количество физической памяти (по подсчетам Жанны около 80 МБайт, а по подсчетам мыщъх'а даже меньше: совокупный объем драйверов на мыщъх'иной машине составляет 30 Мбайт, и мыщъх не думает, чтобы на Висте их размер был бы сильно больше), гарантируя при этом, что никакой драйвер не будет скомпрометирован.

Учитывая, что сама Виста требует не менее 1 Гбайта RAM (а для реальной работы понадобиться как минимум два), потеря 30-80 Мбайт навряд ли покажется значительной, однако можно пойти другим путем, подсчитывая контрольную сумму каждой страницы перед вытеснением ее на диск и проверяя ее при загрузке. Но, поскольку контрольные суммы надо где-то хранить (причем не на диске, а в невытесняемой оперативной памяти), мы не получаем никакого выигрыша, впустую расходуя процессорное время. Можно, конечно, шифровать страницы каким-нибудь высокоскоростным криптоалгоритмом, храня в памяти всего лишь ключ, случайным образом генерируемый при загрузке, но это уже чересчур. К тому же, существует возможность модификации самого файла ядра операционной системы, отключая все защитные механизмы и тут же инициируя перезагрузку, против которой предложенные защитные меры бессильны!

Атака на файл подкачки - это действительно прорыв, который Microsoft закроет не скоро (во всяком случае, в Vista RC1 еще не закрыла). Важно отметить, что все вышесказанное относится исключительно к 64-битной версии Windows, поскольку только в ней администраторы лишены прав загружать неподписанные драйвера.

Погружение в виртуальный мир

Механизмы аппаратной виртуализации (известные под кодовым именем "Pacifica") реализованы во всех процессорах семейства Athlon 64/Turion 64, выпущенных фирмой AMD после мая 2006 года, также планируется поддержка виртуализации в Opteron'е. Но это все x86-64 платформы, которые нам не сильно интересны, поскольку их рыночная доля крайне мала. AMD не смогла справится с виртуализацией x86, сославшись на сложность реализации и непригодность этой архитектуры для подобных целей (читай: кишка тонка), а вот Intel смогла, за что ей честь и хвала!

Технология аппаратной виртуализации Pacifica

Рисунок 5. Технология аппаратной виртуализации Pacifica, реализованная в процессорах фирмы AMD: при выполнении машинной команды VMRUM процессор создает новую SVM (Secure Virtual Machine - Защищенную Виртуальную Машину), управляемую гипервизором (hyper-visor) и структурой данных под названием Virtual Memory Control Block (Блок Управления Виртуальной Памятью) или, сокращенно VMCB.

Технология с кодовым именем "Vanderpool", воплощенная в процессорах Intel Pentium 4 6x2, Pentium D 9xx, Xeon 7xxx, Core Duo, Core 2 Duo и перекочевавшая туда из Itanium'а (IA64), где она была известна под именем "Silvervale", теперь во избежании путаницы объедена с последней в обезличивающую официальную аббревиатуру VT-X (Virtualization Technology X - X-Технология Виртуализации).

VT-X существенно отличается от Pacific'и, но по сути предоставляет те же самые возможности, а именно - запуск гипервизора, захватывающего контроль над операционной системой и переводящего ее в "гостевой" виртуальный режим, который с ее точки зрения ничем не отличается от "реального".

Технология аппаратной виртуальной виртуализации

Рисунок 6. Технология аппаратной виртуальной виртуализации Vanderpool/Silvervale, реализованная в процессорах фирмы Intel - монитор виртуальных машин (VM Monitor), запускаемый машинной командой VMXON, создает столько "виртуальных" процессоров, сколько угодно.

Гипервизор (в случае VT-X называемый Монитором Виртуальных Машин - "Virtual Machine Monitor" или, сокращенно, VMM) передает гостевой операционной системе управление и получает его назад при наступлении определенных "интересных" событий: возбуждении аппаратного/программного прерывания, обращения к служебным регистрам процессора и т.д.

Гипервизор не может непосредственно перехватывать API-функции гостевой операционной системы, но способен следить за обращениями к портам ввода/вывода или самостоятельно взаимодействовать с оборудованием в обход оси. Косвенный перехват API-функций осуществляется путем установки аппаратных точек останова на исполнение (которых, увы, всего четыре) с последующим пресечением попыток гостевой системы "подсмотреть" истинное содержимое регистров DRx.

Подробное описании технологии Pacifica содержится в техническом руководстве "AMD64 Architecture Programmer's Manual Vol. 2: System Programming", выложенным в общий доступ на http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf.

В отличие от AMD, Intel выпустила отдельный документ, а не стала валить все в одну большую кучу: ftp://download.intel.com/technology/computing/vptech/C97063-002.pdf (и хотя без руководства по системному программированию при написании собственного монитора виртуальных машин все равно не обойтись, его основные положения большинству хакеров уже известны. Конечно, для тех, кто еще не знаком с защищенным режимом, создание "Голубой Пилюли" окажется настоящим испытанием, но... это уже их проблемы).

Выполнение машинной команды VMRUN

Рисунок 7. Выполнение машинной команды VMRUN на процессорах AMD x86-64 приводит к захвату контроля над операционной системой.

Рассмотрим устройство "Голубой Пилюли", заточенной Жанной специально под процессоры AMD x86-64 (на процессорах Intel все будет точно также, только немного по-другому). Проглотив "Голубую Пилюлю" (CALL bluepill) ядро передает управление главной функции rootkit'а (условно обозначенной "PROC blue-pill"), которая создает виртуальную машину, подготавливает все необходимые структуры данных и вызывает машинную команду "VMRUM" (на Intel-процессорах это будет "VMXON"), устанавливающую гипервизор/VMM, погружающий операционную систему в виртуальный мир и натягивающий на ее глаза "очки", перехватывающие все каналы взаимодействия последней с "внешним миром" - портами ввода/вывода, служебными регистрами процессора, физической оперативной памятью и т.д.

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

Упрощенная блок-схема

Рисунок 8. Упрощенная блок-схема "Голубой Пилюли", разработанная Жанной.

Гипервизор/VMM представляет достаточно сложную программу, которую не так-то просто написать и еще сложнее отладить, но ведь нам так хочется реализовать свою собственную "Голубую Пилюлю", не правда ли? Сама Жанна, кстати, так и не справилась с этой задачей, о чем открыто признается в своем блоге в заметке "The Blue Pill Hype" ("Слухи вокруг Голубой Пилюли"): http://theinvisiblethings.blogspot.com/2006/07/blue-pill-hype.html, фрагмент из которой мыщъх цитирует ниже:

"All the hype started from this article in eWeek by Ryan Naraine (http://www.eweek.com/article2/0,1895,1983037,00.asp). The article is mostly accurate, despite one detail - the tile, which is a little misleading... It suggests that I already implemented "a prototype of Blue Pill which creates 100% undetectable malware", which is not true. Should this be true, I would not call my implementation "a prototype", which suggests some early stage of product... The Blue Pill prototype I currently have is not yet complete, but this is not that important, because having successfully moved the OS into a virtual machine, implementing all the other features is just a matter of following the Pacifica specification"
(Все началось со статьи Нарьяна Рьяна из eWeek. Статья вполне адекватная, за исключением одной маленькой детали, вводящей читателей в заблуждения. В статье утверждается, что я уже реализовала "прототип Голубой Пилюли, создающую на 100% не обнаруживаемую мальварь", что неправда. Если бы это было правдой, я бы не стала называть свою реализацию "прототипом", подразумевающего наличие опытного продукта... Прототип "Голубой Пилюли", имеющийся у меня в настоящий момент, еще не полностью реализован, но это неважно, поскольку создание виртуальной машины для запуска операционной системы и реализация всех остальных фич - это всего лишь вопрос следования спецификациям на Pacific'у - перевод мыщъх'а).

Операционная система проваливается в виртуальный мир

Рисунок 9. Проглотив "Голубую Пилюлю", операционная система проваливается в виртуальный мир.

Чтобы приблизить себя к цели на несколько световых лет и не повторять уже сделанное, мы можем "выдрать" ядро из готового эмулятора и слегка доработать его "напильником" для наших хакерских целей, дописав сравнительно небольшую порцию кода. Естественно, это должен быть эмулятор, распространяющийся в открытых исходных текстах на бесплатной основе - например, XEN, поддерживающий обе архитектуры (Pacifica + Vanderpool одновременно) и абстрагирующий нас от конкретных аппаратных особенностей, хотя и не избавляющий реализовывать отдельные версии rootkit'а для x86 и x86-86 платформ. Архив с исходными текстами третьей версии XEN'а (текущей стабильной версии на данный момент) можно слить с http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/xen-3.0-testing-src.tgz, а сам сайт находится по адресу http://www.cl.cam.ac.uk/Research/SRG/netos/xen.

В частности, ядро, отвечающее за поддержку x86 процессоров Intel, сосредоточено в файле /xen-3.0-testing/xen/include/asm-x86/hvm/vmx/vmx.с.

Красная пилюля

В "Матрице", чтобы увидеть реальный мир было достаточно принять красную пилюлю. А как насчет операционной системы? Может ли она каким-нибудь образом определить, что работает под виртуальным эмулятором? Программу, позволяющую обнаружить присутствие эмулятора, обычно называют "Красной Пилюлей" и такие пилюли находят самое широкое применение как в хакерской, так и администраторской среде (первые используют их для детектирования VM Ware или других программных эмуляторов, вторые - для обнаружения rootkit'ов). С аппаратной виртуализацией все намного сложнее...

Операционная система обнаруживает эмулятор

Рисунок 10. Приняв "Красную Пилюлю", операционная система обнаруживает эмулятор (если он есть).

Первое, что приходит на ум - попытаться вызывать VMCALL/VMXON и, если мы находимся под эмулятором (процессор не поддерживает аппаратной виртуализации или она отключена в BIOS), вызов проваливается. Написать такую программу - плевое дело, имея готовый скелет драйвера, это можно сделать меньше, чем за минуту, вот только... как отличить ситуацию "процессор не поддерживает" от "мы под эмулятором"?! Существует только один путь - отодрать от кремния радиатор и физически посмотреть на его маркировку, сличив ее с "показаниями" машинной команды CPUID (эмулятор, если только он не лось, возвратит подложные данные, убеждая нас в том, что поддержка аппаратной виртуализации на этом процессоре отсутствует). Но какой процент пользователей отважится на столь радикальный шаг?! Отодрать радиатор они, положим, отдерут, но вот приставят ли обратно?

Тем более, что путем некоторых ухищрений гипервизор может эмулировать выполнение команд VMCALL/VMXON, реализуя вложенную виртуализацию. Это как бы один виртуальный мир в другом и уровень вложенности, в принципе, неограничен. Естественно, с каждой проглоченной "Голубой Пилюлей" мы будем терять производительность. Уже в первом виртуальном мире быстродействие операционной системы сокращается на десятки процентов (никто никогда и не утверждал, что аппаратная виртуализация дает 100% КПД).

Виртуальные миры

Рисунок 11. Виртуальные миры, вложенные друг в друга как матрешки.

Стоп! Стоп! Стоп! Производительность! Вот она - нить Ариадны! Замеряя время выполнения машинных инструкций, перехваченных гипервизором (и, в первую очередь, инструкции RDMSR EFER, читающий регистр EFER, 12-й бит которого указывает на присутствие гипервизора), мы легко заметим, что в виртуальном мире они выполняются намного дольше, чем в реальном.

Вся проблема в том, что нам нечем измерить время их исполнения. Команда RDTSC (читающая значение регистра, увеличивающегося с каждым тактом процессора) отпадает сразу и однозначно, поскольку контролируется гипервизором, корректирующим ее показания так, как будто бы мы находится в реальном мире. Для упрощения решения этой задачи, процессор поддерживает специальную "калибровочную" переменную VMCB.TSC_OFFSET, указывающую, сколько экстра-тактов ему следует вычитать при выполнении команды RDTSC. Так что, корректировка показаний RDTSC происходит автоматически даже без вмешательства эмулятора.

Корректировка времени выполнения инструкций, перехваченных гипервизором

Рисунок 12. Корректировка времени выполнения инструкций, перехваченных гипервизором.

Теоретически можно воспользоваться часами реального времени, атомными часами, доступными через сеть или даже внешним (по отношению к компьютеру) хронометром. Гипервизор способен "подкручивать" часы реального времени (правда, при этом они начнут отставать, что пользователь сможет заметить), перехватывать и корректировать сетевой трафик, если в нем присутствует атомное время (хм, а не надорвется он это делать?!), но на хронометр, сжимаемый ладонью пользователя он воздействовать не в состоянии (если, конечно, пользователь сам не находится в виртуальном мире ;-)).

Попытка обнаружить присутствие гипервизора

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

Отличная "Красная Пилюля" получилась, нечего сказать... "Сейчас будет запущена тестовая программа, пожалуйста, воспользуйтесь своими электронными часами и определите время ее выполнения, для уменьшения погрешности продолжительность теста составит около 60 секунд". Ну и кто это будет делать?! А с чем сравнивать полученные показания, мы подумали?! Чтобы обнаружить присутствие гипервизора необходимо иметь эталонный компьютер с таким же точно процессором, погруженным в термостат, поскольку многие процессоры меняют свою тактовую частоту в зависимости от температуры. Но даже в этом случае, гипервизор может распознать команду RDMSR EFER, выполняющуюся в цикле, и пропускать некоторые итерации для достижения идентичного времени выполнения.

Некоторые горячие головы предлагают читать содержимое оперативной памяти через DMA, записывая ее на диск, а потом искать в этой куче дерьма следы присутствия гипервизора. Ну, во-первых, они очень сильно переоценивают возможности контроллеров DMA по чтению памяти, во-вторых, гипервизор, контролируя обращения к портам ввода/вывода, легко это отследит, а, в-третьих, даже если и не отследит - что искать-то?! При условии, что сигнатура "Голубой Пилюли" неизвестна (или она построена на полиморфной основе), мы ни за что не различим ее!

Вместо заключения

Так что же, выходит, "Красной Пилюли" не существует?! А это еще как сказать... Ведь и "Голубой Пилюли" не существует тоже. Во всяком случае, пока... Да, технологии аппаратной виртуализации позволяют создать "Голубую Пилюлю", которую никак нельзя обнаружить. Теоретически. Практически же все упирается в сложность реализации, так что не стоит обсуждать конструкцию сферических коней в вакууме, а лучше решать проблемы по мере их возникновения.

https://nebka.ru/?uid=1&post=20955