Да, готовое решение тут правда проще, но у меня это целиком собственный кастомный стек, где я полностью контролирую все процессы и знаю, где что находится
Да, частично. OpenClaw тоже добавляет слой памяти, но это скорее memory-layer внутри агента: markdown-файлы, recall, compaction, wiki-слой, но это не универсальная память, а один из подходов под конкретный кейс.
Сравнение некорректно из-за различной нагрузки на процессор. WireGuard шифрует весь трафик, тогда как XTLS-Vision оптимизирует работу с TLS, исключая двойное шифрование. Моя конфигурация также ограничивает QUIC, торренты и UDP, снижая общую нагрузку.
При обычном домашнем использовании TR3000 загружен на 5-8% ЦПУ, обеспечивая скорость выше 300 Мбит/с. При полноценном туннелировании всего трафика, включая торренты, показатели меняются.
Конфигурации с полным туннелем, как Зероблок, имеют иные задачи и быстрее упираются в ограничения ЦПУ.
Intel SDM, Vol. 3C, стр. 24-3 прямо пишет: “Software enters VMX operation by executing a VMXON instruction.” . И я не спорю, что сам вод в VMX-режим делается из ring0, но у Hyper-V есть и user-mode component of the virtualization stack - VMWP, как прямо сказано у Microsoft - https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/architecture
Ты сейчас споришь с формулировкой, а не с сутью. VMXON и VMRUN из user-mode не запускаются, это ring0-only инструкции. А user-mode компоненты в Hyper-V есть, но они не исполняют сам вход в виртуализацию. Так что твой аргумент скорее просто подмена тезиса.
Спасибо за комментарий, тут действительно есть несколько упрощений с моей стороны.
По PatchGuard - да, вы правы: он не запрещает запуск гипервизоров сам по себе. Type-2 гипервизоры спокойно живут в user-mode. Я в тексте имел в виду именно сценарий с кастомным VMM + патчами ядра на этапе загрузки. В таком виде это уже не «обычная виртуализация», и без обхода PG оно быстро ловит BSOD. Про PG в целом: https://learn.microsoft.com/en-us/security-updates/securityadvisories/2007/932596
Смотря в какой части. Гипервизор отлично обходит проверки окружения VMProtect: анти-отладку, детекты виртуалок и тайминги. Протектор будет уверен, что работает на чистом железе.
Но саму виртуализацию кода (превращение x86-инструкций в кастомную кашу из байт-кода) этот метод магически не расшифрует. Реверсить логику всё равно придётся руками. Просто теперь VMP не будет бить по рукам и крашить процесс при попытке прицепить к нему отладчик
Ахах, вот поэтому я и люблю свой стек руками :)
Согласен, это больше хобби :)
А direct-by-default для меня сейчас просто практичнее: меньше сюрпризов с антифродом и российскими сервисами.
Спасибо!
Это тоже вариант, но, как я говорил ранее, я делал систему под себя, максимально прозрачной в собственном использовании
А там же вроде работала оплата через UnionPay, по крайней мере я как-то пополнял пару месяцев назад. В РСХБ карту делал
Да, готовое решение тут правда проще, но у меня это целиком собственный кастомный стек, где я полностью контролирую все процессы и знаю, где что находится
Да, частично. OpenClaw тоже добавляет слой памяти, но это скорее memory-layer внутри агента: markdown-файлы, recall, compaction, wiki-слой, но это не универсальная память, а один из подходов под конкретный кейс.
Это basically локальный RAG без саммари. Удобно, но это про retrieval, а не про память в широком смысле.
Спасибо, поправлю
Сравнение некорректно из-за различной нагрузки на процессор. WireGuard шифрует весь трафик, тогда как XTLS-Vision оптимизирует работу с TLS, исключая двойное шифрование. Моя конфигурация также ограничивает QUIC, торренты и UDP, снижая общую нагрузку.
При обычном домашнем использовании TR3000 загружен на 5-8% ЦПУ, обеспечивая скорость выше 300 Мбит/с. При полноценном туннелировании всего трафика, включая торренты, показатели меняются.
Конфигурации с полным туннелем, как Зероблок, имеют иные задачи и быстрее упираются в ограничения ЦПУ.
Да, я сейчас немного подпиливаю архитектуру и документацию, после выложу в опенсорс, чтобы посмотрели
РКН прокомментировал ситуацию для ТАСС — ведомство сообщает, что массовую рассылку писем от их лица ведут мошенники. Выдыхаем.
Я с вами согласен, уже многое переработал и готовлю статью со всеми изменениями в работе роутера, на след неделе планирую выпустить ч2
Согласен, тут я откровенно затупил. Зря приплел сюда архитектуру большого Hyper-V.
Обсуждаемый тонкий гипервизор - это драйверная история, признаю, был неправ :)
Intel SDM, Vol. 3C, стр. 24-3 прямо пишет: “Software enters VMX operation by executing a VMXON instruction.” . И я не спорю, что сам вод в VMX-режим делается из ring0, но у Hyper-V есть и user-mode component of the virtualization stack - VMWP, как прямо сказано у Microsoft - https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/architecture
По KUSER_SHARED_DATA Microsoft MSRC пишет, что kernel mapping находится по адресу 0xFFFFF78000000000, а user-mode mapping - по 0x7FFE0000 - https://www.microsoft.com/en-us/msrc/blog/2022/04/randomizing-the-kuser_shared_data-structure-on-windows. Это я и имел в виду.
Ты сейчас споришь с формулировкой, а не с сутью.
VMXONиVMRUNиз user-mode не запускаются, это ring0-only инструкции. А user-mode компоненты в Hyper-V есть, но они не исполняют сам вход в виртуализацию. Так что твой аргумент скорее просто подмена тезиса.Спасибо за комментарий, тут действительно есть несколько упрощений с моей стороны.
По PatchGuard - да, вы правы: он не запрещает запуск гипервизоров сам по себе. Type-2 гипервизоры спокойно живут в user-mode. Я в тексте имел в виду именно сценарий с кастомным VMM + патчами ядра на этапе загрузки. В таком виде это уже не «обычная виртуализация», и без обхода PG оно быстро ловит BSOD.
Про PG в целом: https://learn.microsoft.com/en-us/security-updates/securityadvisories/2007/932596
По DSE - тоже согласен, формулировка вышла слишком категоричной. Есть test mode, есть разные способы загрузки драйверов, тот же kdmapper сейчас используется повсеместно. В статье я описывал конкретную реализацию с EfiGuard, а не все возможные варианты.
Про test signing: https://learn.microsoft.com/en-us/windows-hardware/drivers/install/the-testsigning-boot-configuration-option
По KUSER_SHARED_DATA - да, в user-mode это всё ещё 0x7FFE0000, тут я не уточнил и получилось двусмысленно. Я имел в виду kernel mapping и подмену через EPT.
Про структуру: https://www.microsoft.com/en-us/msrc/blog/2022/04/randomizing-the-kuser_shared_data-structure-on-windows/
Если коротко: я описывал конкретный стек из crack-пакетов, а не всю экосистему в целом.
Смотря в какой части. Гипервизор отлично обходит проверки окружения VMProtect: анти-отладку, детекты виртуалок и тайминги. Протектор будет уверен, что работает на чистом железе.
Но саму виртуализацию кода (превращение x86-инструкций в кастомную кашу из байт-кода) этот метод магически не расшифрует. Реверсить логику всё равно придётся руками. Просто теперь VMP не будет бить по рукам и крашить процесс при попытке прицепить к нему отладчик
Ааа, это да, на самом деле сам по себе принцип такого обхода очень опасен для обычного юзера, это факт
Что вам не понравилось? Поделитесь?