Assembler *

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

Вторая часть рассказа об ассемблере под Windows. Здесь я расскажу про 64-разрядные приложения в Windows, чем отличается MASM 64 от MASM 32, про макросы из MASM 64 SDK, как работать с Юникодом на примере простого консольного REPL'а, а ещё как обойтись без Visual Studio и пользоваться masm просто из командной строки.

Первая часть — Assembler для Windows в Visual Studio.

Пишем один код - собираем на разные 8 бит МК!

https://vm5277.ru- это универсальное решение для embedded-разработки, которое позволяет сократить время создания прошивки для 8 бит микроконтроллеров в разы.

Как это работает:

Пишешь код на Java подобном языке (чистое ООП, без головной боли с указателями и не читабельным кодом)

Компилятор автоматически генерирует оптимизированный ассемблерный код под выбранную платформу

Код работает поверх легковесной RTOS, написанной на ассемблере для максимальной производительности

Ассемблер-сборщик финализирует проект в бинарный файл прошивки

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

1. Математика — чистая математика
2. Haskell — язык для функционального программирования
3. C — язык для императивного программирования
4. Ассемблер — сравнительно удобочитаемое представление машинного кода
5. Машинный код для архитектуры x86-64 — вот это уже интересно

Если вам интересно, какие отличия бывают между языковыми стилями или любопытно, как ваш код может выглядеть после компиляции — добро пожаловать под кат!

Что на самом деле происходит, когда вы запускаете программу? Мы привыкли воспринимать это как данность, но за кадром скрывается целая вселенная — от регистров процессора и системных вызовов Linux до формата ELF и модели памяти процесса. Присоединяйтесь к погружению, где мы прольём свет на каждый байт программы «Hello, World!» и поймём, каким образом ОС её выполняет.

Практически сразу, в PC-DOS, вместе с .COM файлами,
появились .EXE файлы (полн. "EXEcutable" или "исполняемые"). Сегодня речь пойдет именно об этом.
Поскольку история происходит снова в Microsoft, запутаться можно очень легко, в любом месте.

Небольшое предупреждение! Я буду говорить не просто о том "Как запускаются комманды?", а покажу часть внутреннего мира операционных систем и покажу принципиальную разницу в их работе.

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

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

Всем здрасте, и сегодня мы начнем наше прохождение через низкоуровневый кодинг - написание ОС. Сегодня мы напишем загрузчик (точнее конфиг к GRUB) и простенькое ядро, которое будет выводить "Hello OSDev!"

Что нам понадобится:

Вы когда‑нибудь смотрели на.EXE‑файл своей любимой DOS‑игры и думали: «Что там внутри? Можно ли это понять без докторской по ассемблеру?» Эта не просто очередной обзор регистров. Это второй шаг в глубокое погружение туда, где байты начинают «говорить». Мы начинаем с тех, кто дал нам язык: с Рэя Доббса, чьи книги «Programming in the MS‑DOS Environment» и «Advanced MS‑DOS Programming» были библией поколения, с Рэндэлла Хайды, чья «The Art of Assembly Language» научила мыслить на языке машины, и с Ральфа Броуна, чей «Interrupt List» стал первым справочником, в котором каждое int 21h перестаёт быть чёрным ящиком и приобретает конкретный смысл. Вы узнаете, что AX, CX, DS:DX и EFLAGS — это не раздельные элементы. Вы поймёте, как они связаны, как передаются данные, как принимаются решения, как программа взаимодействует с системой. Как прерывания становятся точками соприкосновения с системой и как по ним можно восстановить логику программы. Мы начинаем движение от байтов к смыслообразующему коду. Готовы сделать следующий шаг?

Планировщик — мозг операционной системы. Его задача: решать, какая задача выполняется сейчас, и по каким правилам выдавать процессор другим задачам. Для embedded систем это особенно критично: ресурсы ограничены, реальное время важно, а поведение должно быть предсказуемым.

Это вторая из цикла статей про создание микроядерной операционной системы. В прошлой статье рассматривался таймер и HAL. Для вновь пришедших необходимо сначала ознакомиться с ней: ссылка.

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

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

Моя первая игра была на дискете. Она называлась Syndicate (1993, Bullfrog Productions), и я не понимал, как она работает. Я видел, как агенты стреляют, как взрываются здания, как звучит саундтрек, но не имел ни малейшего представления, что за этим стоит.

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

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

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

DOS-игры - другое дело: нет виртуальных машин; нет сборщиков мусора; нет драйверов. Есть только процессор, память и код, написанный на C/C++ или ассемблере. Это делает их идеальной школой для изучения реального программирования.

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

Как-то раз я послушал следующее интересное выступление (по-немецки): ссылка

В нём разобрано, как написать программу «hello world» для 64-разрядного дистрибутива Linux в шестнадцатеричном редакторе. Ассемблер здесь не используется, программа пишется непосредственно на машинном коде. Правда, в ней есть издержки на использование ELF.

Мне понравилась такая идея, и я решил повторить такой опыт, но немного в иной форме — а именно под 16-разрядной DOS в реальном режиме. У меня должен был получиться файл в формате COM, а не EXE, так как (на данном этапе) меня интересовал не столько формат файла, сколько кодировка инструкций. В вышеупомянутой лекции, если честно, не сообщается почти никаких подробностей о том, как именно перейти от ассемблерного кода к машинному — поскольку в случае разбора этих тем лекция, пожалуй, растянулась бы на несколько часов. Но здесь я всё разберу подробно, и при этом собираюсь пользоваться только документацией lntel, а также дизассемблировать код в целях верификации.

Также мы коротко поговорим о сегментации.

В качестве шестнадцатеричного редактора на этот раз воспользуемся hexedit.

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

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

Давным-давно, когда F11 и F12 еще не придумали, F1-F10 располагались слева, Ctrl жил на месте CapsLock, а IBM продавала компьютеры с гарантией на 90 дней, владельцы компьютеров работали в MS-DOS. Процессор еще не знал, что такое защищенный режим, память не делилась на области пользователя и ядра, виртуальной памяти не было, как не было и многозадачности. MS-DOS программа на счет "раз" нарушала работу ядра и компьютер приходилось перезагружать. Программы скромно умещались в 64 Кб, а, если превышали это ограничение, жизнь их становилась труднее.

Дизассемблируем 16-битную программу: InDuLgEo V3-B горит пламенем на экране, печатает текст и трезвонит, как старый телефон.

Большинство компиляторов — это монолитные черные ящики, унаследованные из прошлого. Мы отвергли этот путь. Мы разбираем архитектуру x86_64 до "первых принципов", чтобы понять, как на самом деле работает кремний. В этой статье мы вскрываем капот нашего компилятора ZGEN и его "фабрики машинного кода" — hwm. Никакой магии. Только чистая, детерминированная инженерия, которая превращает ассемблер в исполняемые биты.

Дарова! Сегодня я поделюсь с вами опытом, как я пытался написать собственную ОС и, что из этого вышло. Запасайтесь чайком с печеньками и присаживайтесь поудобнее! Пора окунуться в 16ти битный мир...

Мы не просто пишем код. Мы строим компиляторы, которые строят код. AsmX G3 — это не обновление, это переосмысление с первых принципов. Приготовьтесь к глубокому техническому погружению в архитектуру нашего нового компилятора ZGEN, где мы вскроем каждый компонент, от ядра до сборщика ELF, и покажем инженерные решения, которые определяют будущее системного программирования.

Это моя пятая попытка диалога с сообществом. Четыре предыдущие закончились баном. Но это не жалоба. Это деконструкция системы, которая наказывает за отклонение от нормы. Мы разберем, почему «низкий технический уровень» стал оружием конформизма и как продолжать строить, когда твой проект — системная аномалия.