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

Когда я спрашивал о причинах отказа, обычно мне отвечали так:

1. Опыт работы с неактуальными для нас технологиями

2. «Слишком разнообразный опыт: платёжные системы, мобильные платформы, аналитика данных и UX»

3. Работающие до договору обычно не особо сильны с технической точки зрения

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

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

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

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

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

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

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

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

Введение

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

Я всегда был фанатом шутеров с видом сверху. Hotline Miami и по сей день остаётся моей любимой инди-игрой, а недавно я решил проиграть в её духовную наследницу — OTXO.

Он всегда был моим любимым жанром. Моя первая «серьёзная» игра, Alien Killer (написанная на Flash, поэтому сегодня в неё практически не поиграешь), была шутером с видом сверху, вдохновлённым старой игрой Net Yaroze: Psychon.

В этой статье я расскажу, как разработал похожий на трёхмерный top down shooter без 3D-движка.

В апреле 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.

Утром 12 апреля 1981 года, ровна 20 лет спустя после дня, когда Юрий Гагарин стал первым человеком в космосе, в небо Флориды с грохотом устремился космический шаттл. При первом взлёте шаттла им управляли командир Янг и пилот Криппен. Но на самом деле запуском, как и большей частью полёта, руководили четыре компьютера в отсеках авионики одной палубой ниже экипажа. Пятый компьютер был готов перехватить управление в случае катастрофического компьютерного сбоя. Эти компьютеры Model AP-101B относились к семейству IBM System/4 Pi.

Семейство System/4 Pi, впервые представленное примерно в 1967 году, было линейкой компактных мощных компьютеров, предназначенных для задач в сфере авионики. Военные использовали эти компьютеры везде, от истребителя F-4 и бомбардировщика B-52 до сонарных систем подводных лодок и противокорабельных ракет «Гарпун». Другие компьютеры семейства System/4 Pi играли более мирную роль в разработке GPS и дистанционного управления полётами. В космосе компьютеры System/4 Pi управляли первой американской космической станцией Скайлэб, а также многоразовой лабораторией Спейслэб, выводившейся в космос шаттлом.

Несмотря на важную роль компьютеров System/4 Pi, информацию о них сложно найти —в Википедии полностью отсутствуют данные о моделях CC, SP и ML¹. Однако я нашёл кучу маркетинговых брошюр и статей о 4 Pi, благодаря чему могу заполнить множество пробелов в истории System/4 Pi.

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

Первый пиксель-арт сцены почти всегда копировался (или, если точнее, плагиатился) из других источников. В частности, достаточно широко заимствовались иллюстрации, связанные с фэнтези- и научно-фантастической литературой. Любимцами были фэнтези-художники Борис Вальехо и Фрэнк Фразетта, а также любитель хромированных распутных роботов Хадзимэ Сораяма.

Смысл пиксель-арта заключался не столько в оригинальности, сколько в труде. Сканеры и дигитайзеры были слишком дорогими для подростков, а изображения, создаваемые первыми потребительскими моделями, оказывались грубыми и малодетализированными. Для создания изображения, выделяющейся подробностями и чёткостью, требовалась ручная пикселизация, а это очень изощрённый процесс. Сначала нужно было вручную скопировать контур оригинала при помощи мыши (или джойстика на C64), затем как-то передать детали в условиях низкого разрешения (обычно примерно 320x256 пикселей), выбрать ограниченную индексированную палитру (обычно 16 или 32 цветов), вручную добавить дизеринг и антиалиасинг. Это был кропотливый труд.

Рендерер Scratch имеет долгую историю связанных с SVG уязвимостей. Их источником становится то, что Scratch парсит сгенерированный пользователем (то есть контролируемый нападающими) контент в элемент <svg> и добавляет его в основной документ для выполнения различных операций (например, для измерения ограничивающего прямоугольника SVG более надёжным образом, чем viewbox или width/height).

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

Я считаю, что подход Scratch к санации SVG обречён на провал. Чтобы объяснить это, нам нужно совершить путешествие по истории санации SVG в Scratch и посмотреть, насколько хорошо он с этим справлялся.

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

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

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

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

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

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

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

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

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

Я наткнулся на видео Simple Lucas с упражнением для повышения внимания и продуктивности. Оно очень простое:

1. Не пользоваться никакими экранами/развлечениями, когда пытаешься сосредоточиться на работе.

2. Когда начинаешь ощущать моральное истощение, сядь и смотри на стену в течение X минут, чтобы вернуть сосредоточенность.

Я попробовал, и это оказалось очень эффективное (хотя и сложное) упражнение.

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

Проблема 60%

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

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

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

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

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

Не надо переписывать то, что не поломано

Код к этому посту доступен на Github.

Кодинг при помощи ИИ стал нормой; мы всё больше позволяем моделям наподобие Cursor, GitHub Copilot, Claude Code и Codex вмешиваться в наш код. Если вы в прошлом пользовались каким-то из этих инструментов, то, вероятно, сталкивались с чем-то подобным: вы просите модель устранить простой баг (допустим, ошибку смещения на единицу или не тот оператор). Модель устраняет баг, но половина функции оказывается переписанной. Появляется новая вспомогательная функция. Совершенно логичное имя переменной меняется на другое. Добавляется новая валидация ввода. И diff из-за этого становится огромным.

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

В своём посте я исследую эту проблему: имеют ли современные LLM склонность к избыточной редактуре и можем ли мы обучить модели редактировать код в должной мере?

Пауза в игре — настолько привычная функция, что вряд ли многие из нас о ней задумывались. Иногда мы обращаем на неё внимание, если в меню паузы играет красивая песня, или когда играем в онлайн-игру, в которой пауза на самом деле ничего не останавливает. В этих случаях мы на мгновение наблюдаем процесс приостановки видеоигры. Но это редкие исключения. Обычно мы ставим игру на паузу и снимаем её с паузы автоматически. Игроки просто ожидают, что в большинстве игр она позволяет приостановить действие.

Но как это работает на самом деле? Как разработчики обеспечивают возможность паузы в игре?

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

Гляньте-ка! Это я с сервером Minecraft, запущенным на компьютере UNIVAC 1219B:

А ниже будет эмулятор NES с первым отрендеренным кадром Pinball.

… и селфи, напечатанное на телетайпе при помощи техники многократной печати «overstrike».

Мы сделали ещё кучу безумных штук, и в том числе:

• Программы OCaml (!)

• Веб-сервер

• Шифрование Curve25519 + AES

• Интерпретатор BASIC

• ELIZA

• Игры наподобие Oregon Trail, Wordle и Battleship

… а также многое другое! И всё это на компьютере из 1960-х с частотой 250 кГц и всего с 90 КБ ОЗУ. Ради такого я и живу! Я одержим запуском кода в странных местах и преодолением технических ограничений. Этот проект стал для меня самым амбициозным на данный момент, он отнял у меня и других примерно восемь месяцев.

Исходники проекта я выложил на Github. Также можете посмотреть видео TheScienceElf об этом проекте!

Всю свою карьеру разработчика я пользовался Postman. Помню его ещё простым расширением Chrome, слегка облегчавшим тестирование API. Жизнь в времена была гораздо проще. Сегодня я присоединяюсь к растущей толпе разработчиков, отказывающихся от этих инструментов, потому что они продались.

Великое предательство: как наши любимые инструменты обернулись против нас

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

Postman, когда-то бывший любимцем всех разработчиков, стал наглядным примером такой трансформации. Переломным для многих моментом стало удаление Scratchpad (офлайн-режим). После этого — снижение производительности и привязка к облачному сервису. Внезапно мы оказались вынуждены синхронизировать свою работу с облаком Postman для доступа к базовому функционалу (привет, Microsoft?). Во-первых, это вставляет палки в колёса разработчиков, работающих над конфиденциальными проектами в сфере банкинга и здравоохранения, а также в государственном секторе. В этом и есть смысл — заставить их платить за инструмент, максимизировать прибыль руководства, поэтому наносимый отрасли сопутствующий ущерб не учитывается.

От переводчика: оригинал этой статьи был опубликован 30 марта 2026 года, за день до запуска миссии. Несмотря на её успешное завершение, приведённые в статье доводы не теряют актуальности.

«Наши испытательные установки не могут достичь тех показателей теплопотока, давления, нагрузок и других характеристик возвращающегося космического аппарата. Нам всегда приходится ждать лётных испытаний, чтобы пройти окончательную сертификацию системы», — Джереми Вандеркам, помощник руководителя по разработке теплозащитного экрана Ориона, 2022 год

В среду 1 апреля НАСА попытается отправить четырёх космонавтов в миссию Артемида-2 вокруг Луны. Это будет вторым полётом ракеты SLS НАСА и первым случаем, когда двадцатилетняя капсула Орион будет лететь с людьми на борту.

Проблема в том, что теплозащитный экран Ориона рассыпается на части. И не в каком-то переносном смысле: когда НАСА запустила точно такую же миссию в 2022 году, во время входа в атмосферу крупные куски материала отрывались от теплозащитного экрана Ориона, оставляя углубления. Кроме того, частично износились и расплавились большие болты, закреплённые в теплозащитном экране.

Первым делом НАСА попыталось прикрыть проблему. В первых пресс-релизах агентство подчёркивало, что и ракета, и космический аппарат превосходно справились с задачей, в то же время отказываясь публиковать послеполётный отчёт. Впервые повреждения экрана упомянул руководитель программы «Орион» Говард Ху при разговоре с репортёрами в марте 2023 года. Ху сказал: «мы наблюдали более существенные изменения теплозащитного экрана, чем ожидалось; часть обуглившегося материала абляционно разрушилась иначе, чем предсказывали наши компьютерные модели и наземные испытания».

Я по горло сыт стандартно выглядящими приложениями. Сегодня все десктопные приложения Windows выглядят одинаково, да и внутри устроены одинаково: их создают на основе дурацких браузерных обёрток React, Electron, electronbun и Tauri, имитирующих реальные десктопные приложения. Они медленно работают и занимают кучу памяти — по сути, это bloatware. Блокнот — это, блин, приложение для простых ЗАМЕТОК, а не замена Word, калькулятор — это калькулятор, а не планировщик лунной миссии НАСА. На каком-то этапе Microsoft сбилась с курса, как будто сдалась и передала бразды правления куче веб-разработчиков, незнакомых с концепцией оптимизации.

Чёртов Блокнот занимает в памяти почти 50 МБ, хотя эквивалентное приложение, написанное на чистом Win32 C, занимает 1,8 МБ. Вроде бы, по современным меркам 50 МБ — это не так много, но в том-то и смысл: эти мегабайты постепенно накапливаются. Недавно я купил новый Intel Ultra 9 285 с 32 ГБ ОЗУ, но при запуске Windows 11 память уже была заполнена на 77%.

Программирование на Win32 API — утерянное ныне искусство; я с ностальгией вспоминаю, как когда-то программировали приложения для Windows. Процесс был запутанным, но обеспечивал полный контроль.

«Плохие программисты беспокоятся о коде. Хорошие программисты беспокоятся о структурах данных и их взаимосвязях», — Линус Торвальдс

Споры о планировщике

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

Вставлять новые задачи с приоритетом (O(log n))

Запрашивать задачу с наибольшим приоритетом (O(1))

Удалять задачу с наибольшим приоритетом (O(log n))

Кто-то предложил: «Давайте используем отсортированный массив». Но вставка будет занимать O(n) — придётся сдвигать элементы.

Кто-то ещё сказал: «Возьмём связанный список». Однако поиск наибольшего выполняется за O(n) — необходимо сканировать весь список.

Третий вспомнил о двоичном дереве поиска. Но из Главы 9 мы уже знаем, что BST ужасно ведут себя с кэшем.

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

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

Наблюдая на прошлой неделе за миссией Артемида-2, я был поражён некоторыми параллелями и различиями между ней и Аполлоном-13. Космический аппарат Integrity Артемиды-2 приземлился 11 апреля, в тот же день, когда был запущен Odyssey Аполлона-13. Внешне эти две капсулы выглядят похоже, но Integrity больше и несёт в себе экипаж из четырёх астронавтов, а не трёх. Однако внутри их разделяет больше полувека технологического прогресса. Наиболее очевидно это на примере имеющейся у астронавтов вычислительной мощности. Сегодня компьютеры захватили мир, но в 1960-х они были на ранних этапах своего развития, и прилунение стало не только триумфом труда, изобретательности и упорства человека, но и триумфом одного из самых новых инструментов человечества — компьютера.

Когда я жила в Нэшвилле, мы с моими подругами часто выезжали на «экскурсии» по штату. Однажды мы поехали искать белоголовых орланов в западном Теннесси; в туалете национального парка нам встретилась женщина с кучерявыми волосами, которая сообщила, что вчера видела 113 орланов. Мы же за всю поездку увидели... двух.

Летом 2017 года мы поехали на ещё одну экскурсию на завод Манхэттенского проекта в Ок-Ридже. В 1942 году Ок-Ридж был выбран в качестве места создания завода по обогащению плутония и урана в рамках Манхэттенского проекта — совершенно секретного мероприятия по разработке первой атомной бомбы. Маленькое сельское поселение, расположенное в долине западного Теннесси, благодаря срочному проекту по созданию атомной бомбы превратилось в тайный посёлок под названием «Site X», увеличив своё население с трёх тысяч человек в 1942 году до 75 тысяч к 1945 году. Наряду с ростом населения были построены огромные здания комплекса.

Я только что выпустил обновление моей игры Blackshift, в котором, среди прочего, были добавлены эти тайлы песка:

Всё было хорошо, пока не начали поступать отчёты о багах.

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