Сегодня мне хотелось бы поделиться решением проблемы, с которой гарантированно сталкиваются владельцы современных процессоров Intel (архитектуры Alder Lake, Raptor Lake и новее) под управлением Windows 11, если они пытаются “крутить” тяжелые локальные модели (LLM) или использовать виртуализацию.

Речь пойдет о принудительной изоляции «тяжелого» софта от энергоэффективных ядер (E-cores) и полной передаче вычислений производительным ядрам (P-cores) со стороны излишне навязчивой в этом плане Windows 11.

Кратко о сути проблемы на примере моего ноутбука.
В моём ноутбуке установлен процессор Intel Core i7-13850HX. У этого процессора вполне себе отличная конфигурация: 8 производительных ядер (16 потоков) и 12 энергоэффективных ядер (12 потоков). Всего 28 логических процессоров.

По задумке Intel и Microsoft, встроенный контроллер Thread Director должен сам понимать, какую задачу и на какие ядра (логические процессоры) ему нужно отправлять, но на практике, например, тот же гибридный режим работы (CPU + GPU) локальных нейросетей буквально вводит Windows 11 в полный ступор с “раcкидыванием” процессов на ядра.

Когда я, например, запускаю тяжелую локальную модель (Qwen 72B весом 47 ГБ) в LM Studio и настраиваю частичный перенос слоев на дискретную видеокарту (в моем случае это “скромная” RTX 2000 ADA 8GB), вычисления делятся между VRAM и оперативной памятью (RAM).

В такой ситуации работа LLM делится на две очевидные фазы:

Считается, что связка из изолированной виртуальной машины, тотального запрета UDP на хосте и принудительного заворачивания TCP-процессов через Proxifier в локальный SOCKS5-порт — это своего рода “непробиваемый бункер” для обеспечения хотя бы условной сетевой анонимности. Ведь в такой схеме гостевая OS физически “слепа”, так как она не знает реального IP хоста и не имеет каналов для прямой утечки пакетов?

Но "бункер" может и пасть. И причины будут неприятными.

Я совершенно случайно обратил внимание, что внутри одной из моих совершенно изолированных виртуальных машин, мессенджер Element и популярный чекер 2ip.ru (через браузеры) продолжали с легкостью определять реальный IP-адрес хостовой OS! При этом классические тесты на утечки через WebRTC или DNS в браузерах показывали идеальную чистоту, а в логах Proxifier не было ни одного прямого (Direct) соединения.

В этой статье я хотел бы рассказать, как именно происходила деанонимизация, и почему корень проблемы лежал за пределами моего “железа” или софта?

Постановка задачи и конфигурация «стенда».

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

DISCLAIMER:
Решив использовать все описанные далее методы, предоставленный ниже код и перечисленные виды программного обеспечения, Вы должны предельно чётко понимать всю полноту юридической ответственности за их несанкционированное применение в условиях реального пентестинга и неукоснительно соблюдать требования Закона в этой области!

Пару недель назад я всерьёз открыл для себя новую “забаву” - использование локальных моделей ИИ для полуавтоматического “белого” пентестинга.

Мой исходный “суповой набор” из “железа” и софта.

Рано или поздно любой “удалёнщик” открывает для себя по-настоящему крутую связку софта для удаленного управления из двух бесплатных приложений - Sunshine (серверная часть) и Moonlight (клиентская часть).

Что же такого крутого в этом софте - спросит любой давний поклонник этих Ваших “rdp,vnc, энидесков, тимьюверов, замшелой удаленной консоли” и прочих типов удаленного доступа?

Если очень коротко, то суть именно этой “связки” софта в том, что она способна идеально “выжать” из возможностей Ваших видеокарты и процессора всё, на что они способны и реально выдать вплоть до 120FPS на 4K даже на не слишком “толстом” интернет-канале. А там где интернет-канал будет совсем “тонким”, эта "связка" софта способна “выжать” такие значения FPS, которые и не снились, ни rdp, ни прочим “хитрым” вариантам умной передачи экрана. Иными словами, Вы во многих ситуациях получите удаленную сессию управления, в которой будет абсолютно полное ощущение, что Вы работаете в конкретный момент не за удаленным рабочим столом, а просто локально. При нормальном интернете Вы даже сможете смотреть (или редактировать) даже 4K видео с 60FPS в удаленной сессии, если Вам это понадобится.

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

Будучи преданным поклонником линейки ноутбуков Thinkpad от компании Lenovo, вот уже около 15 лет я использую и в работе, и в быту исключительно такие ноутбуки.

К слову сказать, у меня до сих пор “в строю” ноутбуки Thinkpad X220, Thinkpad w520 и Thinkpad P50, которым всегда найдутся интересные задачи. И когда полтора года назад мне предоставилась возможность приобрести очередной топовый “финик”, после долгого и вдумчивого исследования предложений на рынке, я приобрёл ноутбук Lenovo Thinkpad P16 Gen 2 в следующей “заводской” конфигурации:

i7 13850HX.
2x16 RAM (Hunix, 5600).
Встроенная видеокарта Intel UHD Graphics + дискретная видеокарта Nvidia RTX 2000 ADA (8Gb).
OEM версия m.2 SSD диска Samsung на 512 gb.
Экран - 4K, IPS 3840x2400, 800 nit, с цветовым охватом по всем основным стандартам 100 и близко к 100 процентам.

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

И, конечно же, очень быстро после покупки я начал делать апгрейд! Забегая вперёд, апгрейд я делал всего 4 раза и только 1-ый из них, как оказалось, был не очень удачным в плане его не полной продуманности. Но именно этот, первый 1-ый апгрейд и стал фактической причиной написания этой статьи!

Итак, первый апгрейд, который я сделал еще полтора года назад, практически через неделю после покупки ноутбука, заключался в том, что я докупил два модуля памяти Samsung по 32 гигабайта (стандарта 4800) и установил их в два оставшихся свободных слота в ноутбуке, доведя суммарный размер памяти до 96 гигабайт. Моя логика была очень простой. В ноутбуке всего 4 слота под RAM, два из которых уже с “завода” были заняты 2x16 модулями от Hunix (стандарт 5800). При этом я сознательно не стал покупать 2x32 модули именно стандарта 5600, полагая, что так как спецификации ноутбука жестко “залочены” на понижение скорости при заполнении всех 4 слотов памяти по такой схеме:

«System comes with DDR5-5600 memory and will run at lower speed due to platform limitations: 4x 32GB / 4x 48GB configurations run at 3600 MT/s. Other configurations run at 4000 MT/s»,

Вводные данные:

— Имеются довольно старые, но до сих весьма высокотехнологичные умные часы — Garmin Fenix 6 Pro Solar, работающие на проприетарной системе компании Garmin.
— Умные интернет‑розетки от Xiaomi Smart Plug 2 Wi‑Fi.

Появилась задача, а скорее просто очередное дико зудящее желание в стиле «кулибинство» — управлять такими розетками (хотя бы удаленно включать и выключать их) прямо с указанных часов.

Желание есть, начинаю изучать задачу. И решать её, как это у меня обычно происходит, нестандартным путем.

Для начала выясняю, как вообще реализовано управление данными интернет‑розетками Xiaomi? Умные устройства Xiaomi преимущественно управляются через фирменное приложение Xiaomi Home, которое отлично работает, например, в OS Android. Приложение огромное по размеру, громоздкое, по сути — целый программный «комбайн» для управления огромным множеством умных устройств Xiaomi. Очень быстро становится понятно, что на часы Garmin никакого подобного приложения, или какого‑либо компактного форка нет и быть не может. Слишком уж скромные программные возможности у часов Garmin при работе с таким монструозным софтом!

И поэтому я решил пойти другим путём:

Около месяца назад я решил испытать один интересный технический сценарий организации кабельного скоростного канала передачи данных между двумя компьютерами/ноутбуками. Речь о штатной возможности Thunderbolt 3/4/5 портов работать в так называемом режиме Thunderbolt Networking. Суть этого способа кабельной передачи в следующем: