Assembler *

__m512i _mm512_mask_ternarylogic_epi32 (__m512i src, __mmask8 k, __m512i a, __m512i b, int imm8)
FOR j := 0 to 15
    i := j*32
    IF k[j]
        FOR h := 0 to 31
            index[2:0] := (src[i+h] << 2) OR (a[i+h] << 1) OR b[i+h]
            dst[i+h]   := imm8[index[2:0]]
        ENDFOR
    ELSE
        dst[i+31:i] := src[i+31:i]
    FI
ENDFOR
dst[MAX:512] := 0

В предыдущей части я приблизительно описал, как можно загрузить eBPF функции из ELF-файла. Теперь пришла пора перейти от фэнтези к советским мультикам, и следуя мудрому совету, потратив один раз некоторое количество усилий, сделать универсальный инструмент инструментации (или, сокращённо, УИИ!!!). При этом я воспользуюсь антипаттерном проектирования «Золотой молоток» и сооружу инструмент из относительно знакомого мне QEMU. Бонусом за это мы получим кросс-архитектурную инструментацию, а также инструментацию на уровне целого виртуального компьютера. Инструментация будет вида «небольшой нативный so-шничек + небольшой .o-файл с eBPF». При этом eBPF-функции будут подставляться перед соответствующими инструкциями внутреннего представления QEMU перед оптимизацией и кодогенерацией.

В итоге сама инструментация, добавляемая при кодогенерации (то есть, не считая пары килобайтов обычного сишного рантайма), выглядит вот так, и это не псевдокод:

#include <stdint.h>

extern uint8_t *__afl_area_ptr;
extern uint64_t prev;

void inst_qemu_brcond_i64(uint64_t tag, uint64_t x, uint64_t y, uint64_t z, uint64_t u)
{
    __afl_area_ptr[((prev >> 1) ^ tag) & 0xFFFF] += 1;
    prev = tag;
}

void inst_qemu_brcond_i32(uint64_t tag, uint64_t x, uint64_t y, uint64_t z, uint64_t u)
{
    __afl_area_ptr[((prev >> 1) ^ tag) & 0xFFFF] += 1;
    prev = tag;
}

Что же, пора загрузить нашего эльфа в Матрицу. Ну, как загрузить, скорее вмазать распылить.

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

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

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

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

В этой статье я расскажу, как выполнить такую адаптация на примере игры Pac-Man, а именно, оригинального образа Pac-Man.tzx.

Раз уж прошлая моя статья, к моему большому удивлению, вас заинтересовала. Я решил дополнить её результат, хакнутую версию игры "Contra (J) [T+Rus_Chronix]", небольшим функционалом, заодно показав "code injection" на NES. В этот раз я сделаю так, чтоб игроки начинали игру с прокачанным Spreadgun, для его получения в игре нужно подобрать иконку "S", а за ней "R".

Все заинтересовавшиеся welcome под кат.

Поскольку некоторая японская компания, до сих пор тщательно бдит свои авторские права. Я не могу предоставить вам ни мою версию рома ни использованный мною исходник. Скажу лишь, что нашёл его в торрент сборнике "Все игры на Dendy". Взяв оттуда переведённую на русский язык японскую версию игры "Contra (J) [T+Rus_Chronix]" я несколько раз её прошёл и будучи крайне любознательным человеком решил немного расковырять ROM образ, в частности подарить немного жизней игрокам.

Первая часть
Вторая часть

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

Как я уже говорил в первой статье, я решил использовать страницы размером 4 МБ, чтобы упростить себе жизнь и не иметь дела с иерархическими таблицами. В дальнейшем я надеюсь перейти на страницы размером 4 КБ, как большинство современных систем. Я мог бы использовать готовый (например, такой блочный аллокатор), но написать свой было чуть интереснее и хотелось чуть больше понять, как живет память, так что мне есть, что вам рассказать.

Введение

Предмет исследования

Первая часть

Первая статья еще не успела остыть, а я решил не держать вас в интриге и написать продолжение.

Итак, в предыдущей статье мы поговорили о линковке, загрузке файла ядра и первичной инициализации. Я дал несколько полезных ссылок, рассказал, как размещается загруженное ядро в памяти, как соотносятся виртуальные и физические адреса при загрузке, а так же как включить поддержку механизма страниц. В последнюю очередь управление перешло в функцию kmain моего ядра, написанного на Rust. Пришло время двигаться дальше и узнать, насколько глубока кроличья нора!

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

Я решил написать статью, а если получится — то и серию статей, чтобы поделиться своим опытом самостоятельного исследования как устройства Bare Bone x86, так и организации операционных систем. На данный момент мою поделку нельзя назвать даже операционной системой — это небольшое ядро, которое умеет загружаться из Multiboot (GRUB), управлять памятью реальной и виртуальной, а также выполнять несколько бесполезных функций в режиме многозадачности на одном процессоре.

При разработке я не ставил себе целей написать новый Linux (хотя, признаюсь, лет 5 назад мечтал об этом) или впечатлить кого-либо, поэтому особо впечатлительных прошу дальше не смотреть. Что мне на самом деле захотелось сделать — разобраться, как устроена архитектура i386 на самом базовом уровне, и как именно операционные системы делают свою магию, ну и покопать хайповый Rust.

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

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

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

Введение

Предмет исследования

Итак, сразу к делу. Писать будем под Linux, на NASM и с использованием QEMU. Установить это легко, так что пропустим этот шаг.

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