Assembler *

Приветствую,

Эта статья будет о том, как не нужно делать, когда разрабатываешь SDK для своего продукта. А примером, можно даже сказать, самым ярким, будет IDA Pro. Те, кто хоть раз что-то разрабатывал под неё и старался поддерживать, при чтении этих строк, наверняка, сейчас вздрогнули и покрылись холодным потом. Здесь я собрал опыт сопровождения проектов, начиная с IDA v6.5, и заканчивая последней на момент написания статьи версии — v7.5. В общем, погнали.

http://mash-project.org
https://github.com/RoPi0n/mash-lang

Mash?

Это императивный язык программирования с динамической типизацией, сборкой мусора, ООП и поддержкой многопоточности.



Интересно? Тогда под кат!

Месяц назад я попытался сосчитать, сколько разных инструкций поддерживается современными процессорами, и насчитал 945 в Ice Lake. Комментаторы затронули интересный вопрос: какая часть всего этого разнообразия реально используется компиляторами? Например, некто Pepijn de Vos в 2016 подсчитал, сколько разных инструкций задействовано в бинарниках у него в /usr/bin, и насчитал 411 — т.е. примерно треть всех инструкций x86_64, существовавших на тот момент, не использовались ни в одной из стандартных программ в его ОС. Другая любопытная его находка — что код для x86_64 на треть состоит из инструкций mov. (В общем-то известно, что одних инструкций mov достаточно, чтобы написать любую программу.)

Я решил развить исследование de Vos, взяв в качестве «эталонного кода» компилятор LLVM/Clang. У него сразу несколько преимуществ перед содержимым /usr/bin неназванной версии неназванной ОС:

1. С ним удобно работать: это один огромный бинарник, по размеру сопоставимый со всем содержимым /usr/bin среднестатистического линукса;
2. Он позволяет сравнить разные ISA: на releases.llvm.org/download.html доступны официальные бинарники для x86, ARM, SPARC, MIPS и PowerPC;
3. Он позволяет отследить исторические тренды: официальные бинарники доступны для всех релизов начиная с 2003;
4. Наконец, в исследовании компиляторов логично использовать компилятор и в качестве подопытного объекта :-)

Начну со статистики по мартовскому релизу LLVM 10.0:
В прошлом топике комментаторы упомянули, что самый компактный код у них получается для SPARC. Здесь же видим, что бинарник для AArch64 оказывается на треть меньше что по размеру, что по общему числу инструкций.

А вот распределение по числу инструкций:

vvvphoenix упомянул в своей позавчерашней статье: «Кстати, я пытался найти график роста числа X86 инструкций по годам (или по поколениям). Пока не смог (может, есть у кого?)»

Я решил, что мне это тоже интересно — да настолько, что не жалко потратить выходной день на сведение en.wikipedia.org/wiki/X86_instruction_listings в одну табличку:



Считались различные мнемоники; например, десятки вариантов MOV считались за одну инструкцию.

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

В этой статье я хочу разобрать внутреннее устройство легендарной игры Sonic the Hedgehog для приставки Sega Mega Drive, а также способы ее модификации или, как еще говорят, хакинга. Эта игра насчитывает порядка сотни хаков, включающих как действительно достойные работы (такие как Pana Der Hejhog или Sonic Remastered), так и странные и даже жутковатые (вроде An Ordinary Sonic ROM Hack). Чтобы понять, как их создавать, нужно разобраться, как писать на языке ассемеблера Motorola 68K (обычно игры для приставок тех времен писались именно на ассемблере), откуда взять дизассемблированный вариант игры и какую архитектуру имеет ее движок.

Дизассемблирование ROM-файлов для Sega осуществляется при помощи коммерческого дизассемблера и дебаггера IDA Pro. Затем происходит кропотливый процесс разметки, структурирования и причесывания сырого ассемблерного кода с использованием дебаггера (и смекалки). Этот процесс требует хорошего понимания технических особенностей платформы Sega Mega Drive и игр для нее.

К счастью, на GitHub уже есть дизассемблированные и размеченные версии всех игр серии Sonic the Hedgehog, созданные энтузиастами при поддержке сайта Sonic Retro. Лучше всего размечен и структурирован исходный код именно первой игры серии. Эта версия кода находится в репозитории sonicretro / s1disasm и именно она будет разобрана в статье.

Погружение в внутреннее устройство игрушки начнем с теории.

23 июля 2013 года был опубликован исходный код демо Second Reality (1993 год). Как и многим, мне не терпелось взглянуть на внутренности демо, которое так вдохновляло нас на протяжении всех этих лет.

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

• Командная работа.
• Обфускация.

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

Часть 1: введение

Демо

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

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

Про что статья

Про алгоритмы генерирующие псевдослучайные числа, которые отличаются между собой качеством результата и скоростью исполнения. Статья будет полезна тем, кто хочет получить высокопроизводительную генерацию чисел в своих программах или разработчикам софта для микроконтроллеров и старых платформ по типу ZX Spectrum или MSX.

Введение

Привет! Меня зовут «HellMood», а эта статья посвящена небольшой программе для MS DOS под названием «Memories». Эта программа имеет размер 256 байт, она выиграла в категории «PC 256 byte» соревнований демосцены «Revision» 2020 года, а также получила приз зрительских симпатий. Видео вывода программы можно посмотреть здесь, а видео с реакцией онлайн-аудитории и модераторов — здесь. Скачать релиз и оставить комментарии можно здесь. В этой статье будет представлен глубокий анализ программы, рассказано об исторических отсылках и этапах разработки. Статья выложена в sizecoding wiki. Она не только позволит вам понять внутреннее устройство «Memories», но и поможет самим создать нечто похожее. Изучите её! Если вы новичок в sizecoding-е (написании программ в рамках нужного размера) или в ассемблере x86, то рекомендуется начинать с основ этой wiki. Принципы понять легко, но с подробностями реализации разобраться бывает не так просто.

Краткий обзор

В этой статье мы будем говорить об отправленной на конкурс версии для DosBox (256 байт). В архиве также содержатся версии для FreeDos и Windows XP DOS, которые на момент написания поста работали не на всех компьютерах. Эти альтернативные версии были включены в архив как proof of concept, чтобы показать, что программа не только работает в эмуляторе. В категории «PC 256 bytes» соревнований «Revision» 2020 года можно было указать в качестве платформы «FreeDos» или «DosBox» (последняя в конкретной конфигурации). Как доказывают альтернативные версии, на самом деле можно модифицировать версию для DosBox так, чтобы она работала во FreeDos, MS DOS, WinXP и Win98, но статья будет не об этом.

В современных x86 процессорах Intel конвеер можно разделить на 2 части: Front End и Back End.

Front End отвечает за загрузку кода из памяти и его декодирование в микрооперации.

Back End отвечает за выполнение микроопераций, пришедших от Front End. Поскольку эти микрооперации могут выполняться ядром не по порядку, то Back End также следит за тем, чтобы результат выполнения этих микроопераций строго соответствовал порядку в котором они идут в коде.

В большинстве случаев неэффективное использование Front End'a не оказывает заметного влияние на производительность. Пиковая пропускная способность на большинстве процессоров Intel — 4 микрооперации за такт, поэтому, например, для Memory/L3-bound кода ЦПУ не сможет полностью ее утилизировать.


Однако в некоторых случаях различие в производительности может быть достаточно существенно. Под катом — анализ влияния кэша микроопераций на производительность.

В первой части мы установили несколько инструментов, которые будут полезны для нас для прохождения этого курса. Их особенность в том, что они все бесплатны. Мы не будем использовать какой-либо платный инструмент, а из тех, у которых есть платная версия, таких как IDA или PYCHARM, мы будем использовать версию FREE или COMMUNITY.

Очень часто при цифровой обработке сигналов необходимо вычислить длину вектора, обычно это делается по формуле A=SQRТ(X^2+Y^2). Здесь возвести в квадрат значение не сложно, но операция вычисления квадратного корня не является простой операцией, особенно для микроконтроллеров. Кроме того, алгоритмы вычисления корня выполняются не стабильное время, и для алгоритмов, в которых таких вычислений много, становится сложно прогнозировать время, необходимое для вычислений.

С такой задачей столкнулся и я. О том, как я отказался от процедуры вычисления корня, читайте ниже.

Итак, друзья, 1-е апреля прошло, пора раскрывать карты, что же такое "2B or not 2B" на самом деле. Это совместный текст от автора работы jin_x и уже знакомого вам деда unbeliever



Обязательно скачайте архив с работой на Pouet и прочитайте вводную (первоапрельскую) статью, а так же комментарии к ней. Посмотрите первое видео с практической демонстрацией того, как работает код из «двух байт» на x86. И вот уже потом попробуйте осилить весь текст ниже.


Да, 2B or not 2B — это действительно среда для запуска различных sizecoding-работ, очень простая и, пожалуй, самая маленькая из существующих. При этом она имеет свои требования и ограничения.

Если кто-то ещё не уловил, тул 2b.com запускается из-под DOS (DOSBox, FreeDOS, MS-DOS) и осуществляет прыжок в область командной строки (по смещению $82* сегмента PSP), запуская на исполнение код, который передан в командной строке в двоичном виде. Собственно говоря, код этот вполне может иметь вид строки, которую можно набрать на клавиатуре (т.е. состоять из ASCII-символов с кодами от 33 до 126), но об этом немного позже.

Честь по чести и часть за частью. Примерно так мы будем погружаться с вами в увлекательный мир демосцены. Сегодня поговорим о конкретной работе в области sizecoding. Дело в том, что некоторые релизы не только имели культовый статус в узких кругах — они прямо и явно воздействовали на умы людей, заставляя учить IDA Pro, смотреть код, проникать во все мельчайшие детали. Было просто непонятно и очень интересно, как же такая магия работает.

Речь идет о cross by Queue Members Group — 128 байт интро для PC из далекого 1996 года:



Вот видеозапись работы:

Дамы, господа, сегодня отличный день!

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


Одной из форм соревнования на демосцене является sizecoding — программирование визуальных эффектов в крайне ограниченном объеме машинного кода. Прежде чем мы перейдем к достижениям сегодняшнего дня (а они есть и более чем масштабные), давайте очень быстро пробежимся по наследию дедов. Все приведенные ниже работы сделаны в разные годы, объединяет их требование к платформе — PC, x86, DOS (никакого GPU, обычная видеокарта). В идеале вам стоит поставить DosBox и запускать каждую работу самостоятельно, благо авторы не особенно озадачиваются созданием видео и загрузкой его на YouTube. Мы постарались выбрать по одной показательной работе в каждой номинации.

Разворачивал в очередной раз Linux-образ на USB-drive (почему-то им оказался Manjaro, но это совсем другая история), и в голову пробрались странные мысли: BIOS увидел флешку, а дальше-то что? Ну да, там MBR, скорее всего GRUB и… А раз в MBR затесался чей-то кастомный код, значит и простой человек из Адыгеи может запрограммировать что-нибудь на «большом» компьютере, но вне операционной системы.

А так как делать такие штуки на языках высокого уровня слишком жирно, а ассемблеров мы не знаем, будем шпарить прямо на опкодах для 8086.

Security Linux Assembly Expert — онлайн-курс и экзамен по основам 32-битного языка ассемблера процессоров семейства Intel в Linux-системах в контексте информационной безопасности. Курс будет полезен пентестерам, инженерам по информационной безопасности и всем, кто желает разобраться в основах ассемблера и научиться писать простые шеллкоды. После прохождения курса вы научитесь пользоваться основными системными вызовами Linux'a, писать простые шеллкоды, начнете понимать базовые принципы работы операционной системы на уровне ядра. В данной статье будут рассмотрены задания, необходимые для прохождения экзамена по этому курсу.

По условиям экзамена необходимо выполнить 7 заданий:

1. Написать TCP Bind Shell
2. Написать Reverse TCP Shell
3. Разобраться с техникой egghunter и предоставить пример этой техники
4. Написать кодировщик кода
5. Проанализировать 3 шеллкода, сгенерированных msfvenom'ом при помощи GDB/ndisasm/libemu
6. Выполнить полиморфное преобразование 3 любых шеллкодов и shellstorm'а.
7. Написать шифровальщик кода

Дамы, господа, как бодрость духа?

От лица =RMDA= приглашаю вас на Revision Online 2020. Как вы отлично знаете, коронавирус лютует, отменены не только крупные мировые конференции, но даже крошечные мероприятия вокруг демосцены по всей Европе (Forever, Speccy.pl и многие другие). Ребята из команды Revision две недели боролись с муниципалитетом микроскопического городка в Германии, но не смогли отстоять право на проведение демопати. Они решили сделать мероприятие онлайн.

С 10 по 14 апреля, 72 часа непрерывного онлайн-потока по всем платформам и аспектам демосцены ждут вас! Все тут: 2020.revision-party.net

Мы активно участвуем в организации Revision Online 2020 и уже выпустили первую работу по теме: Revitro, 256 bytes intro, PC, x86

Человек веками мечтал о небе. Братья Уилбур и Орвилл Райт, Альберто Сантос-Дюмон и братья Вуазен подарили его людям. И человек с каждым десятилетием поднимался всё выше и выше, увеличивал скорости, манёвренность, предельные перегрузки, преодолевал звуковой барьер, сталкивался раз за разом с труднейшими инженерными вызовами.

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

Но с ростом скоростей и расстояний повысились требования к управляющим системам летательных аппаратов — микроконтроллерам, прошивкам, автопилотам.

Мне повезло познакомиться с отечественным разработчиком Владом Гордеевым, который занимается как разработкой систем дистанционного управления полетом самолётов, так и систем автоматического управления полетом ЛА. Я задал ему несколько вопросов — и оказался на пару часов в мире, где всё решают миллисекунды, такты, алгоритмы и нет права на ошибку.

You've run into a really hairy area of asm code.
My first suggestion is not try to call from assembler into Go. — Ian Lance Taylor

До тех пор, пока ваш ассемблерный код делает что-то простое, всё выглядит неплохо.

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

Но что если вам это очень-очень нужно? В таком случае, прошу под кат.

Речь пойдёт о способе защиты програмного обеспечения, который реализован в самом процессоре. Для экспериментов я выбрал мультимедиа приставку Comigo Quattro. Цель — запустить своё ядро линукс.

Краткий обзор

На первый взгляд ПО приставки является клоном Android. Доступ по ssh закрыт. Работает только с действующим абонементом от дистрибьютора. Стоковая прошивка полностью шифрована. Всё глухо, как в танке.

Подготовка

Первым делом я подробно ознакомился с техническим описанием процессора. Порадовали меня две вещи: у процессора был интерфейс UART и он поддерживал загрузку системы с разных источников (USB, SD и т.д.), которая могла настраиваться снаружи при помощи конфигурационного регистра. На борту приставки также имелось место для mSD карты, но разьём был не припаян. Для того, чтобы найти пятачки конфигурационного регистра и пины UART мне пришлось спаять процессор и прозвонить дорожки. Когда все контакты были найдены, я подключил адаптер UART и запустил приставку. На экрана высветился U-Boot. Загрузка системы прерывалась нажатием клавиш и U-Boot выходил в режим ввода, но ни на какие клавиши кроме enter, никак не реагировал. И эта лазейка тоже была закрыта.