Отладка *

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

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

Чтобы показать вам драматизм ситуации, я для примера провёл с помощью профилировщика PHP измерение ресурсозатратности каждой линейки семейства WordPress - это версии 1, 2, 3, 4, 5, 6 и недавняя 7.

Кому интересно, прошу под кат. Увидите, как от первых версий, на которых WordPress завоёвывал славу легковесной блоговой системы, он пришёл в конце концов к многократно утяжелённой платформе по множеству срезов измерения.

Цифровая идентификация и её значение для веба в последние годы стали темой горячих обсуждений. Они привнесли с собой множество спорных моментов: законы о проверке возраста и их влияние на онлайн-анонимность; Википедия потенциально будет вынуждена верифицировать в Великобритании личность пользователей; привязка к официальным операционным системам iOS и Android стала обязательным форм-фактором для кошельков цифровой идентификации; кроме того, стоит упомянуть ситуацию, когда американские цифровые аккаунты были закрыты потому, что их пользователь был судьёй Международного уголовного суда.

В своей истории я расскажу о швейцарской правительственной системе идентификации AGOV. Этот развёрнутый в 2024 году сервис сегодня насчитывает 1,6 миллиона аккаунтов и становится всё более необходимым: через него можно получать пособие по безработице, предоставлять налоговую декларацию (а это обязательное действие!) и выполнять множество других операций. В кантоне Цюрих это единственная возможность подачи заявления на гражданство.

В конечном итоге, я был вынужден создать аккаунт AGOV. К сожалению, его регистрация была довольно сложной задачей, пока я не нашёл причины странного бага accessibility. Вдохновившись статьёй «Просто дайте мне выделить текст», хочу представить вашему вниманию «Просто дайте мне ввести цифры».

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

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

Для поиска таких мест были созданы разные инструменты профилирования. Этим термином называют всестороннее измерение нагрузки, оказываемой исследуемым скриптом на сервер сайта. Например, для языка PHP наиболее известными профилировщиками кода являются следующие: Blackfire, Xdebug Profiler, Tideways, XHProf/XGHui.

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

Для решения подобной узкой задачи я разработал очень простой бесплатный профилировщик PHP. Так сказать, студийную версию профайлера, то есть урезанную до объёма, достаточного вебмастеру при работе над проектами в студии. И делюсь этим скриптом с сообществом. Кому интересно, прошу под кат.

В 1990-м Titus выпустила Fire & Forget II: гонку, где спорткар с пулемётом умеет взлетать. Я гонял её ребёнком с одной дискеты, а недавно полез внутрь её бинарника, просто посмотреть, как она устроена. Внутри оказалось неожиданно много: кооперативная многозадачность на голом 8086, собственный скриптовый язык с французскими мнемониками, две виртуальные машины, исполняющие один и тот же байткод, и полминуты игры самого разработчика, спрятанные в демо-записи. Их не видел никто и никогда. По дороге игра пересобралась на C11 и теперь живёт в браузере: не трогайте клавиатуру в меню, и увидите то самое демо. Но статья не про порт:

Под катом много пиксель-арта, игра «найди отличия», где каждое найденное отличие оказывается уроком об устройстве оригинала, и подробный разбор того, как один враг рождается в перетягивании каната между двумя виртуальными машинами.

Наш веб-краулер потреблял 128 МБ ОЗУ только на отслеживание посещённых URL. На встраиваемом устройстве с 256 МБ это была половина всей памяти.

Задача краулера была простой: отслеживать посещённые URL, чтобы не краулить одну и ту же страницу дважды. После обработки 1 миллиона URL (средняя длина 80 байт) хэш-таблица, в которой хранились эти URL, разрослась до 96 МБ плюс оверхед.

«Можем ли мы обменять точность на память? Нас вполне устроит несколько дублированных операций, если это позволит сэкономить большой объём памяти», — сказал мне мой менеджер во время ревью кода.

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

В 1994 году у меня появился первый компьютер: Intel i486 DX2-66 с 4 МБ ОЗУ и жёстким диском на 512 МБ. На нём были установлены IBM OS/2 и Microsoft Windows 3.11. Следующие четыре года я апгрейдил эту машину каждые несколько месяцев, добавляя больше ОЗУ (до 16 МБ), привод CD-ROM и карту SoundBlaster. Так я научился апгрейдить эту машину, устанавливать новое ПО, а потом и писать ПО на BASIC. Но я ни разу не касался процесса запуска и тонкостей MS-DOS.

В 2026 году, 32 года спустя, я узнал из скриншотов DDX3216, что в Behringer использовался настоящий процессор 386. В моём мозгу сразу же активировались какие-то нейроны и я начал размышлять о том, можно ли запускать на этом устройстве ПО или даже полнофункциональную операционную систему. Для этого мне нужно было разобраться, как запускается система x86, когда управление перехватывает DOS и что необходимо для попадания в оболочку.

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

Одним из ключевых механизмов такого взаимодействия является ACPI (Advanced Configuration and Power Interface). Эта спецификация определяет, каким образом прошивка платформы описывает аппаратную конфигурацию системы, а операционная система получает возможность управлять устройствами, питанием и событиями платформы без необходимости знать все детали конкретной реализации материнской платы или SoC.

Пользователь столкнулся с ошибкой в вашей программе. Трекер ошибок ее зафиксировал. Стек-трейс показывает место сбоя. Но что делал пользователь за несколько секунд до этого? Какие запросы выполнялись? На каком шаге сценарий пошёл не так?

Для ответа на эти вопросы в трекерах ошибок используются Breadcrumbs — цепочка событий, предшествующих ошибке. Разберём, как они работают в Хоуке и как помогают быстрее расследовать сбои в приложениях.

В процессе борьбы со всевозможными COM/Ethernet/WIFI/Bluetooth RS-485 устройствами, в том числе встраиваемыми, программаторами и тд. столкнулся с тем, что автоматизировать работу с устройством практически нечем. Т.е. написать полноценный сценарий для имитации целевого устройства, обеспечить обмен данными с во всех возможных вариантах без ручного управления не получится ничем. На форумах умники советую брать питон, что сложно для схемотехников и иногда медленно. Самые продвинутые терминалы позволяет создавать макросы, некоторые — группы макросов без возможности полноценного анализа. Поэтому пришлось наваять терминал со встроенным скриптовым языком.

Цель — создать инструмент для широкого круга пользователей, схемотехников, радиоинженеров, которые недолюбливают среды программирования. Поэтому скриптовый язык делался максимально простым, никаких рекурсий, сложных выражений, лямбд, грамматических конструкций и пр. Также сделать простым работу с данными, предоставить возможность работать с несколькими устройствами одновременно. Унифицировать способы подключения (COM/Ethernet/WIFI/Bluetooth) устройств. Иметь в распоряжении специфические функции, которые решают задачу в комплексе.

В статье я расскажу, как эмулировать работу USB-устройства без наличия физического устройства. Для этого мы соберем маленький Linux-дистрибутив в Buildroot (~60мб), который с помощью USB Gadget будет притворяться реальным периферийным устройством - Modbus Slave (но можно любым дргим: мышкой, камерой и т.д.). Запустим несколько таких “устройств” с помощью QEMU, подключим их в Windows через USBip.

Недавно я вспомнил о игре Star Wars Jedi Knight: Jedi Academy, на которую подростком потратил больше десяти тысяч часов. Изучая материалы о ней, я наткнулся на любопытную историю.

Оказывается в 2013 году, сразу после покупки Lucasfilm компанией Disney и закрытия LucasArts, разработчики Raven Software запаниковали, что их работа будет навсегда положена под сукно, поэтому они в спешке выложили весь исходный код Jedi Outcast и Jedi Academy онлайн.

Этот дамп был таким внезапным, что они даже не подчистили внутренние комментарии разработчиков. Весь код превратился в капсулу времени, прочитав которую, можно узнать о том, как вымотанные программисты сходят с ума, пытаясь реализовать физику светового меча на движке Quake 3.

Заглянув в основной файл боёв (bg_saber.c), можно увидеть, что вся система схваток на световых мечах представляет собой огромную спагетти-конструкцию switch из пяти тысяч строк.

Я прошерстил кодовую базу и нашёл потрясающие комментарии...

«Задача абстракции — не быть расплывчатой, а создать новый семантический уровень, на котором можно достичь абсолютной точности», — Эдсгер Дейкстра

Взрывной рост количества промахов кэша

При определении топологии сети для обхода 500 коммутаторов нашей системе требовалось 37,5 миллисекунды. Вроде бы это не так медленно, если не учитывать количество промахов кэша: 8,5 миллиона. При 500 узлах это 17 тысяч промахов на узел.

Структура данных была фундаментально неподходящей для этой задачи.

Работа инструмента была простой: определение топологии сети при помощи обхода графа соединённых устройств. У каждого коммутатора было до 48 портов, а нам нужно было при помощи поиска в ширину найти все доступные устройства из начальной точки.

Реализация была как по учебнику — список смежности со стандартным BFS. В случае сети из 500 коммутаторов (в среднем по 12 соединений у каждого) статистика была такой: 8,5 миллиона промахов кэша на 500 узлов. Это 17 тысяч промахов кэша на узел!

Я переписал этот код, реализовав графовое представление, учитывающее кэш. Результаты: код стал в 3,75 раз быстрее, а количество промахов кэша уменьшилось в 7 раз.

В этой главе мы поговорим об эффективном описании и обходе графов.

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

Важные примечания: эта статья предназначена исключительно для образовательных целей. Я НЕ оправдываю и НЕ поддерживаю анализ, обход и взлом игр (будь то с защитой Denuvo или какой-то другой) и НЕ поддерживаю пиратство ни в каком виде. Пожалуйста, поддерживайте разработчиков, упорно трудившихся над этими играми и мерами защиты (мы любим тебя, Blaukovitch).

Цель этой статьи — проанализировать такой способ обхода и способ защиты от него со стороны Denuvo.

Почему был выбран этот способ

Почему вообще выбрали этот способ?

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

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

Введение

В этой статье мы проанализируем релиз обхода основной DLL из недавно выпущенной Resident Evil: Requiem с cs.rin.ru и подробно расскажем о том, как гипервизоры наподобие HyperDBG можно использовать для спуфинга аппаратных значений, фактически, обеспечив таким образом обход DRM Denuvo.

В апреле 2026 года Canonical раскрыла 44 CVE в uutils — реализации GNU coreutils на Rust, которая поставляется по умолчанию с версии 25.10. Большинство из уязвимостей обнаружилось при внешнем аудите, проведённом перед выпуском 26.04 LTS.

Я изучил список и решил, что из него можно многому научиться.

Примечательно то, что все эти баги оказались в кодовой базе на Rust, написанной людьми, которые знают, что делают, и ни один из багов не был отловлен механизмом проверки заимствований, clippy lints и cargo audit.

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

Кроме того, на нашем подкасте Rust in Production недавно был вице-президент по разработке Ubuntu Джон Сигер, заслуживший похвалы слушателей за честный рассказ о состоянии Rust в Canonical.

Если вы пишете системный код на Rust, то эта статья будет самым сжатым анализом того, где сейчас заканчивается безопасность Rust.

logzip — утилита для сжатия логов перед анализом в LLM. Вместо того чтобы отправлять в Claude/GPT сырые 10 МБ лога, мы сжимаем его до 3.4 МБ (−58%), сохраняя полную читаемость и видимость ошибок. Статья рассказывает о проблеме (Lost in the Middle, переплата за мусорные токены), архитектуре на Rust, алгоритме Recursive BPE и реальном ROI: −$2,070 в год на API.

Проект open source (MIT), интегрирован с Claude Desktop через MCP.

В 2024 году bjiru выложил видео о портативном устройстве ME2 — выпущенной примерно в 2008 игрушке, способной при помощи USB синхронизировать очки и драгоценности между устройством и онлайн-миром. Игра была крайне нишевой, поэтому никто не архивировал её ПО, драйверы и ресурсы; по крайней мере, до тех пор, пока bjiru не создал онлайн-клиент игры.

Я руководитель Miuchiz Reborn — созданного в 2015 году проекта по реверс-инжинирингу, эмуляции и поддержке доступности похожей игры, состоящей из онлайн-части и портативного устройства, соединяемых через USB. ME2 тоже была старой игрой подобного типа, поэтому моя группа Miuchiz рассказала мне о ней ещё в 2018 году; она считала (ошибочно), что они могут быть архитектурно схожи. Несмотря на то, что я уже несколько лет знал о существовании устройства, именно видео bjiru подтолкнуло меня начать его исследование.

Поначалу я занимался исключительно воссозданием сервера, необходимого для обеспечения функциональности копии компьютерной игры, принадлежащей bjiru, но со временем я обратил внимание и на портативное устройство. Разумеется, воссоздание онлайн-игры не было бы полным без механизма синхронизации очков с устройством. В конце концов, это общение между компьютером и устройством ME2 было основной «фишкой» игры. Я подумал, что мой предыдущий опыт работы с портативными устройствами Miuchiz поможет мне в анализе ритуала необходимого им общения... если мне удастся выполнить реверс-инжиниринг кода.

«В Computer Science есть только две сложные вещи: инвалидация кэша и придумывание названий», — Фил Карлтон

Разрыв в производительности

Наш парсер логов обрабатывал 800 тысяч строк в секунду. Нам требовалось 3 миллиона строк в секунду. От нужного нам показателя мы отставали в 3,75 раза.

Задача инструмента заключалась в парсинге строк логов в реальном времени, извлечении временных меток, уровней логов и сообщений из миллионов строк в секунду. Обработка миллиона строк логов в текущей реализации требовала 1,25 секунды — слишком долго для анализа в реальном времени.

Профилировщик показывал 85 миллионов промахов кэша. Для обработки строк это казалось слишком большим показателем.

В реализации использовались стандартные строковые функции C — простые, читаемые, но, очевидно, слишком медленные.

Я переписал этот код, добавив обработку строк с учётом кэша. Результаты были такими:

В 4,5 раза быстрее и в 7 раз меньше промахов кэша.

В этой главе мы поговорим о том, как эффективно использовать кэш при обработке строк.

В прошлой статье я рассказал, как можно сделать профилировщик памяти ориентированный на многопоточные приложения, который в 16 раз быстрее heaptrack.

Сегодня рассмотрим как получилось совместить быстрый профайлинг с удобством визуализации в Grafana в реальном времени.

Ключевые особенности:
Flamegraph аллокаций и деаллокаций за интервал времени
График потребления памяти с детализацией до функции/строчки в коде(настраиваемо)
Flamegraph в момент пика памяти
Flamegraph суммарного числа аллокаций
Flamegraph суммарного объема аллокаций

«Блокировки — это goto конкурентного программирования», — Морис Херлихи

Проблема 60%

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

Восемь ядер, пытавшихся записывать сообщения логов, имели общий кольцевой буфер. Реализация была простой: буфер защищался мьютексом. При высокой нагрузке, когда все ядра записывали логи одновременно, профилировщик демонстрировал ужасный паттерн: 60% тактов CPU тратилось на операции с мьютексом.

Пропускная способность: 850 тысяч сообщений в секунду. В восьмиядерной системе она должна быть гораздо выше.

«Можно ли улучшить ситуацию, отказавшись от блокировок?», — спросил меня мой менеджер во время ревью производительности.

Этот вопрос привёл к полной смене архитектуры...

В этом тексте я показал как настроить потоковую запись ADC семплов на микроконтроллере STM32.

ADC модуль это основа любого электронного измерения. Основа любого DMM. Всё что за корпусом микроконтроллера - это аналоговый мир. ADC это портал который позволяет аналоговым сигналам просачиваться в мир цифры.