Assembler *

Время, когда антивирусное ПО основывалось лишь на статическом, или сигнатурном, анализе, уже далеко в прошлом. Хотя в 2026 году оба вида анализа по-прежнему используются, они применяются не так активно, как раньше. В далёком прошлом антивирусное ПО могло делать выводы, основываясь лишь на анализе таблицы импорта, что, соответственно, вызывало множество ложных срабатываний. В результате этого появился термин "поведенческий анализ". Его основная идея заключается в том, что антивирусное ПО оценивает не только содержимое конкретного файла, но и действия, которые выполняет запущенный процесс. Система собирает телеметрию: отслеживает создание дочерних процессов, работу с файлами и реестром, загрузку библиотек, сетевую активность, попытки получить доступ к другим процессам и другие события. Каждому наблюдаемому действию или их комбинации может соответствовать определённое правило. Если процесс выполняет операцию, характерную для вредоносного ПО, ему увеличивается условный уровень подозрительности.

Собственно, рассмотрим примитивный пример в контексте поведенческого анализа. В системе появляется новый процесс с именем winloggon.exe - уже здесь внимательный наблюдатель заметит проблему, легитимный процесс называется winlogon.exe, а одна лишняя буква в имени для вируса вполне может оказаться попыткой замаскироваться под системный процесс под невнимательность пользователя. После инициализации наш герой совершает первую ошибку: обращается к реестру и прописывает себя в Run.

Ошибка первая. Самый примитивный способ записать себя в автозагрузку. CmRegisterCallbackEx позволяет зарегистрировать обратный вызов для операций с реестром. Процесс изменил нужный ключ - телеметрия уже собрана. Но, наш вирус как вы поняли, останавливаться не собирается. Следующим шагом он загружает прямиком с диска чистую библиотеку.

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

Ошибка третья. После чего в игру вступает антивирусный WFP драйвер - Windows Filtering Platform. Сетевой стек Windows позволяет системе защиты получать информацию о сетевых операциях и принимать решение, разрешать соединение или нет. В результате winloggon.exe, который только что прописал себя в автозагрузку, создал подозрительный файл и теперь пытается установить соединение наружу, оставляет ещё один вполне заметный след.

В результате чего основываясь на сборе телеметрии, начислении баллов, мы получаем не одно определенное событие, а полноценную законченную картину:

В этой части мы возьмём первый из пропусков BLIS — микроядро sgemm; сначала зафиксируем форму аккумулятора 32×32 в четырёх тайлах ZA, затем разберём горячий цикл по K, потом эпилог с alpha, beta и ловушкой NaN, а в конце посмотрим, какие числа производительности даёт именно это ядро. Следующая часть оставит структуру почти той же, но заменит геометрию тайла и условия существования ядра.

Когда я только знакомился с OSDev, я очень долго искал соответствующие материалы. Находил и на YouTube, и на Habr, и просто какие‑то англоязычные сайты (тогда я не сильно знал английский). Но почти все что я находил было либо незаконченным, либо недостаточно понятным и полным.

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

Когда я начал работать с CH32V203G6U6 и обнаружил, что там есть 64-битный аппаратный таймер, то подумал: ух, это же отлично, раз таймер аппаратный, то и о чтении/записи заботится сам микроконтроллер. И какое-то время это не вызывало вопросов. А потом…

Не потому, что контейнерному миру срочно нужен ещё один init. Есть Tini, есть docker run --init, и для большинства production-сценариев я бы по-прежнему начал именно с них.

Мне скорее хотелось разобрать задачу до самого нижнего уровня: без libc, без runtime, напрямую через Linux syscalls. Заодно проверить, насколько сильно будет отличаться одна и та же реализация на x86-64 и ARM64.

В итоге из небольшого эксперимента получился mini-init-asm: PID 1, который запускает приложение в отдельной process group, передаёт сигналы всей группе, собирает zombie-процессы и умеет корректно завершать контейнер с exit code приложения.

Позже туда добавились subreaper mode и простой restart-on-crash. А сам проект в итоге доехал сначала до Debian unstable, а затем и до testing.

Но началось всё с вопроса: что вообще должен уметь нормальный PID 1 внутри контейнера?

← Девятая часть

В предыдущих постах мы подробно разбирали каждый слой: CPU, арифметику, скриптовый интерпретатор, оборудование. Вот, что окончательный отчёт о синтезе Quartus сообщает обо всех них: в готовой архитектуре используется 1593 логические ячейки из доступных в EP2C5 4608 (35% чипа) с 594 выделенными логическими регистрами и 17 блоками памяти M4K. Сам модуль CPU занимает 1173 из этих логических ячеек и 400 регистров. Остальная логика отдана периферии: драйверу ЖК‑дисплея (154 логические ячейки), сканеру клавиатуры (97), интерфейсу термопринтера (64), таймеру CTC (49) и аппаратному PRNG (20). 12 блоков памяти M4K занимает ROM микрокода (49152 бит: это полная программа калькулятора), 2 блока — ROM скриптинга (8192 бита), 1 — ROM BCD‑констант, 1 — таблица поиска для BCD‑умножения внутри CPU и 1 блок — ОЗУ. Меня это очень радует: полнофункциональный научный калькулятор уместился в 35% небольшой дешёвой FPGA.

В детстве я учился программированию на старом IBM PC с монохромным зелёным монитором, поэтому давно хотел создать программу для этой системы. За последние пятнадцать лет я написал более чем сотню небольших интро. В последнее время я был не так активен, но потрясающее интро «Rainbow Surf» автора Plex размером всего 16 байт мотивировало меня снова вернуться к старым наброскам и взяться за работу.

Создание этой программы сопровождалось привычными экспериментами. Я развлекался с клеточными автоматами в графике и звуке, а также исследовал трюки sizecoding. В частности: а) полиморфные ассемблерные команды (наподобие add [bx+si],al, имеющую машинный код 0x0000) б) переход в середины команд для экономии байт и многократного использования опкодов. Из сотен мелких экспериментов мне приглянулся один, интересный одним только своим названием.

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

В моём интро «M8trix» 2014 года по экрану уже бегали псевдослучайные буквы (в 8 байтах, а потом и в 7), но мне всегда было интересно, как добавить к ним красивый звук. Но хронологически в разработке «wakeup» я сначала занимался звуком. Хорошим подзаголовком к статье мог бы быть «16 байт, превращающие звук треугольника Серпинского в дождь символов из „Матрицы“».

Примечание: на каждом такте времени новая строка треугольника Серпинского а) воспроизводится через динамик б) отрисовывается на экране с шагом 56. Можно ощутить движение, но не увидеть его, потому что оно имеет «ширину» 8192 пикселей, но одна строка символов состоит всего из 80 байт. Если бы экран был гораздо больше, то можно было бы увидеть треугольник. Или если не пропускать пиксели и рисовать и все одновременно, он тоже был бы виден.

В этой части мы начнём с тупика, в который приводит голый цикл FMOPA; затем покажем, какую часть GEMM BLIS уже построил за нас; после этого разберём пять циклов BLIS и место микроядра внутри них. Финал главы должен сделать дальнейший план конкретным: что именно нужно добавить для Apple SME, а что уже относится к готовой «мебели» фреймворка.

Эта статья посвящена путешествию в мир ретропрограммирования. Надеюсь, в ней у меня получится передать вам то чувство восхищения, которое я испытал и которое заставило меня написать этот пост. Пост о том, как создавать ПО для компьютерной системы Atari ST, выпущенной в 1985 году.

Atari ST относится ко второй крупной волне домашних компьютеров. Первая волна, созданная на основе 8-битных CPU, принесла в наши дома такие знаковые машины, как Commodore C64 и Sinclair Spectrum. Вторую волну разрабатывали на основе 16-битных CPU; она породила Apple Macintosh, Commodore Amiga и, разумеется, Atari ST.

Atari ST 1040 STF с цветным монитором Atari SC1224

Типичный Atari ST (например, 1040 STFM) имел CPU Motorola 68000 с тактовой частотой 8 МГц и 1 МБ ОЗУ; он загружал ПО с 3,5-дюймовых гибких дисков. Его графические возможности состояли из монохромного режима высокого разрешения 640x400 и 16-цветного режима 320x200, получившего наибольшую популярность в играх.

Рабочий стол GEM Atari ST имел интерфейс, очень похожий на разработанный Xerox и Apple, у него были диспетчер файлов, иконки и многооконность. Это его монохромная версия высокого разрешения.

Если у вас нет реального Atari ST, то его можно просто эмулировать на современном компьютере. Первые эмуляторы появились ещё в 90-х. Хорошим считается Hatari, который существует для большинства современных платформ. В эмуляторе также есть современные инструменты разработки. В прошлом приходилось пользоваться неуклюжим ПО разработки, которое загружалось с дискет, а сегодня можно просто писать всё в VSCode и компилировать современным GCC. У нас есть доступ к современным графическим редакторам наподобие GIMP, и мы даже можем просить помощи у ИИ.

Три статьи я собирал файл и отдавал его эмулятору, ни разу в него не заглянув. Заглянул. Внутри два разных описания одних и тех же байтов, ответ на вопрос, откуда взялся адрес 0x80000000, и поле, которое я заполнял зря.

Вы запускаете программу, о которой ничего не знаете. Она вежливо просит строку, а в ответ на ваш ввод насмешливо отвечает: «Bro, what are you trying to do?» И правда, что мы пытаемся сделать? Пытаемся понять ее.

Перед нами crackme – программа-головоломка, написанная для тренировки навыков обратной разработки: бинарник под Linux x86-64 без исходников и документации, который издевается над каждым, кто не смог его разгадать. Это первая статья цикла из трех о гибридном анализе крякми Getting Started Keygen (Mazzottis). Мы осмотрим файл штатными утилитами, найдем main в Ghidra, расшифруем «бессмысленные» имена переменных в реальную раскладку стека и подтвердим гипотезы в GDB. По пути встретим оптимизированный пролог без RBP, «хитрое» беззнаковое условие и std::string, спрятавшийся в трех переменных, которые на первый взгляд никак не связаны.

Во второй части цикла – мутационное тестирование и реконструкция скрытой структуры, в третьей – полный разбор хеш-функции и восстановление алгоритма на Python.

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

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

Написал рекурсию тем же приёмом, что во второй статье, и программа повисла навсегда: возвращаться ей было некуда. Чиню, завожу стек и по дороге выясняю, что регистра sp в наборе команд нет вовсе. А потом урезаю стек до 128 байт, и сборка об этом не говорит ни слова.

В этой части мы проверим, есть ли у SME учебная дорога, сравнимая с той, которую получили тензорные ядра GPU; затем разберём два реально полезных источника: Arm Learning Path и KleidiAI; после этого отделим то, чему они действительно учат, от того, где они останавливаются. К концу главы станет видно, какая именно «середина лестницы» отсутствует и почему следующая часть неизбежно приводит к BLIS.

Это продолжение статьи Материалы по хакингу на русском.

Вкратце — я собираю автоматические переводы материалов по хакингу и выкладываю их на сайте библиотеки. В этой подборке — книги для тех, кто хочет понимать программы, железо и протоколы не по документации, а изнутри: от устройства компьютера и ассемблера до Windows Kernel, ARM, Java-байткода, автомобильных шин, VoIP и аппаратного реверса.

Через четыре часа после первой статьи пришёл комментарий: в моём коде не хватает трёх инструкций, и на настоящей плате он рассыплется.

Читатель arteast был прав.

Сел воспроизводить поломку. Собрал два варианта, свой и правильный, прогнал на строке в 231 байт. Вывод побайтово одинаковый. Замедлил линию до предела. Ничего не изменилось. Написал программу, которая смотрит, бывает ли передатчик занят хоть когда-нибудь. При выводе в консоль не бывает.

Моя ошибка внутри эмулятора не проявляется вообще. Проверить себя было нечем.

Пришлось чинить эмулятор.

Без библиотек, без обвязок, без операционной системы под ногами. Реальный код на реальном железе — ну, почти реальном.
Пустая эмулируемая машина RISC-V, десяток строк ассемблера, и в терминале:
Сначала думал вывести «hello», как все.
Пусть будет «Привет, мир!»

Часть 1 цикла о программировании Apple Scalable Matrix Extension (SME2) — от первых принципов до промышленной реализации GEMM.

← Восьмая часть

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

Но «большинство» это не «все», а «примерно 12» — это не 15-16 разрядов, которые может и должна обеспечивать 16-разрядная BCD-машина. Существовали пограничные случаи, в которых результаты оказывались совершенно неверными. Имелись итеративные алгоритмы с точностью приемлемой, но не такой, какой она могла быть. Кроме того, в процессе тестирования я обнаружил ошибки, при отладке которых обнаружились фундаментальные баги в коде прототипа на C++. Это привело меня в смятение, ведь для их устранения мне бы пришлось переделать заново код прототипа. В конечном итоге, так я и поступил. Старый код я оставил в репозитории (Pathfinding/Methods) и с нуля разработал совершенно новую версию (Pathfinding/Proof). Я пообещал себе, что занимаюсь этим последний раз в жизни, поэтому стремился делать всё идеально.

В итоге, версия 2025 года устранила найденные мной проблемы. Это был не патч, а почти полное переписывание арифметического движка, расширение набора команд CPU и существенное увеличение библиотеки функций. В этом посте я расскажу об изменениях и их причинах.

В июле 1980 года Recreational Computing напечатал листинг The Wizard's Castle — рогалика на BASIC для микрокомпьютера Exidy Sorcerer. Первая строка выглядела так: 10 REM"_(C2SLFF4 .

REM — это комментарий: интерпретатор его пропускает, писать туда что-то имеет смысл только для человека. Вот только читать здесь нечего, сплошная абракадабра из символов.

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