Assembler *

Всем привет! В этой серии райтапов мы разберем известные задания по эксплуатации бинарных уязвимостей с Exploit Exercises (там их больше нет, поэтому я их перекомпилировал под Win). О том, что такое Buffer Overflow прекрасно и с примерами написано ТУТ (отличная статья от @Mogen). Кстати говоря, много крутых задачек на тему PWN есть на Codeby Games, так что рекомендую :)

Итак... мы будем решать наши задачки, используя статический (Ghidra) и динамический анализ (x64dbg). И самое главное, мы будем делать это без исходников уязвимой программы, в отличие от того, как это сделано ТУТ и ТУТ.

Stack0

Для решения этой задачки я буду использовать свою «песко‑реверс‑лабораторию», где у меня уже все «стоит» :)

Среди многочисленных демосценерских конкурсов, которые традиционно входят в программу различных demo party, незаслуженно недооценённым, на мой взгляд, является конкурс процедурной графики (procedural graphics). Смысл этого специфического вида компьютерного творчества — формирование статичного изображения при помощи короткой программы. Стандартные ограничения на размер — 4кб, 1кб, 256 байт.

Связана недооценка, думаю, с тем, что конкурс одновременно не вполне понятен как тем, кто любит демки (поскольку процедурная графика статична), так и тем, кто любит картинки (т.к. процедурная графика не позволяет нарисовать что хочешь). И всё же, его популярность хоть и медленно, но растёт.

Первые работы во многом были вызваны интересом к теме трассировки лучей (raytracing). Сам по себе алгоритм довольно простой, но требует много вычислений, поэтому работы стали возможны, когда распространились компьютеры с, во‑первых, достаточно высокой производительностью и, во‑вторых, с достаточным количеством отображаемых цветов (или, хотя бы, градаций серого). Я порылся на pouet и нашёл одну из первых работ в категории «procedural graphics» — Digital Phantasy by EG:

Приветствую всех обитателей Хабра и случайных гостей!
Этой статьёй я хотел бы начать цикл заметок, посвящённых моей научной работе в вузе, связанной с фаззинг-тестированием. Всего на данный момент я работаю над темой 2 семестра.

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

Надеюсь, кому-нибудь это да пригодится ;-)

Решил я, значит, изучить, как работают компьютеры на самом низком уровне. Это тот уровень, где работают всякие железяки, транзисторы, логические элементы и так далее. Чтобы полностью закрепить материал, я решил построить простенькую ЭВМ на редстоуне в Minecraft. Эта статья о том, как работают ЭВМ на уровне логических элементов и о том, как я построил прототип такой ЭВМ в Minecraft. В конце я оставил ссылку на GitHub-репозиторий с проектом.

В статье предпринята попытка разобраться в содержимое startup файла микроконтроллера STM32F4, построенного на базе ядра Arm Cortex M4. Для запуска ядра используется ассемблерный код, который и предстоит изучить. Для лучшего понимания материала необходимо иметь представление об архитектуре ядра Cortex M4. Сразу отмечу, что замечания и уточнения приветствуются, т. к. они позволят дополнить представленную информацию.

И это уже третья статья (первая и вторая) из цикла «Chrome Windows 7».

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

StarForce, DENUVO, VMProtect в Chrome?

В предыдущих статьях цикла был приведен пример реализации ведомого модуля JTAG на Verilog. Я предположил, что количество инженеров, знающих Verilog, меньше, чем количество инженеров, которым требуется понимание принципов работы JTAG. Поэтому, помимо реализации на Verilog, модуль JTAG был также реализован на Си.

Так как реализация на Си преследовала исключительно образовательную цель, то скорость её работы была принесена в жертву некоторой унифицированности подходов с реализацией на Verilog. Поэтому я был несколько удивлён, когда в личном сообщении @Sergei2405 спросил, нет ли способа ускорить работу примера для микроконтроллера, чтобы применить этот код в промышленном изделии.

Субъективно, практическое применение программного JTAG мне по‑прежнему видится не вполне оправданным.
Но, во‑первых, это хороший повод рассмотреть предельные возможности микроконтроллеров.
А во‑вторых, есть формальная причина сказать, что в данной статье предлагается Решение Прикладной Задачи :)

Итак, сегодня мы поговорим про прерывания, поллинг и прочее. А протокол JTAG станет фоном для повествования.

CE поддерживает 69 языков, более двух тысяч компиляторов и широкий спектр архитектур, включая x86, arm, risc-v, avr, mips, vax, tensa, 68k, PowerPC, SPARC и даже древний 6502.

Эта история началась с ухода в отпуск зимой. Вы только представьте! Полярная ночь, темно хоть глаз выколи и дикий мороз. И вот сижу я такой страдалец, не зная, чем себя занять горемычного. А тут выскакивает статья, что японцы собрали однобитный компьютер на четырех микросхемах. (Naoto64). И вот то ли от безделья, то ли от тоски, или азарт меня одолел, но решил я попробовать собрать «одноплатник» с минимальным количеством микросхем. Под словом «минимальным» я подразумеваю компромисс между функционалом и лишним корпусом микросхемы. В итоге получилось при минимальной комплектации 26 микросхем. Это конечно гораздо больше, чем у Naoto64, но за то это уже 4-х битный «одноплатник».

Наша задача - сделать так, чтобы программа выводила "Good" в независимости от того, что пользователь ввёл в поле пароля. Если вы захотели декомпилировать данную программу, закинув EXE-файл в программу по типу dotPeek или ILSpy, то у вас ничего не выйдет. Ведь данная программа написана не на C#, исходный код которого можно легко посмотреть, а на C++, декомпилировать который нельзя.

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

Всё началось в конце 2005 года, когда мне довелось писать движок для симуляции 3D-пространства. В этом движке было буквально всё, чем язык C++ мог похвастаться в 2005 году. Трёхзвёздочные указатели, восьмиуровневые зависимости, C-подобные макросы повсюду. Кое-где – вкрапления ассемблера. Итераторы в стиле Степанова и мета-код в стиле Александреску. В общем, всё. Кроме ответа на самый важный вопрос: зачем?

Но действительно ли это так? И что вообще значит «запустить»?

Ведь все так и делают)

А давайте возьмём простейший процессор и напишем его эмулятор на Python. Будем кормить его бинарниками и дебажить.

Статья для тех, кто всегда хотел разобраться в машинном коде, но боялся начать.

В мире компьютерных наук мало что может сравниться с созданием собственной операционной системы. В этой статье мы погрузимся в увлекательный мир разработки операционных систем, создав 16-битную ОС с помощью языка ассемблера NASM под архитектуру процессоров Intel x86-64. Мы рассмотрим каждый этап разработки, начиная с основ и заканчивая реализацией ключевых компонентов.

Друзья, коллеги, всех приветствую! В этой статье мы напишем шифратор на грязном "макро-чистом" Ассемблере и в качестве элементарного шифра будем использовать Шифр Цезаря (Шифр сдвига с ключом k = n). Статья написана для новичков, которые могут погрузиться в мир "первой" криптографии. З.Ы. Код можно доработать, как вы захотите (например, реализовать другой шифр), и использовать, например, в курсовой (в ВУЗе). Благо, в профильных ВУЗах еще уделяют какое-то время языку Ассемблера :)

"Что б они ни делали -- не идут дела. Видимо в прошивке багов дофига". Как я напомнил в прошлой статье (где я подготовил утилиты для перепрошивки сенсоров) -- я рассказываю про платформу для VR игр, как с ней интегрироваться и как добраться до ее сенсоров напрямую.

Её исходный ресивер обновляет сенсоры с частотой в 86Гц, тогда как технически возможно разогнать до 133 Гц, получив ощутимо ниже задержки, но связь была нестабильной.

Давайте начнём погружение в сенсоры -- посмотрим, что за игра ghidra_11.0_PUBLIC установлена у меня в C:\Games, заглянем одним глазком в саму прошивку и поковыряемся там грязными патчиками, да исправим race condition плюс выкинем немного отладочных глюков. В общем, готовимся к погружению. В этот раз -- всё серьёзно.

Я достаточно давно решил ознакомится с ассемблером архитектуры Arm. По большей части для ознакомления и понимания внутренних процессов архитектуры. Чем больше я изучал литературу и различные источники, тем больше я понимал, что нужна практика. Я решил вспомнить ассемблер для x86-х машин и заодно потренироваться на архитектуре Arm.

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

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

Но далеко не всё так плохо как кажется! В KolibriOS есть готовый редактор кода с подсветкой CEdit, и он поддерживает подсветку для нескольких языков программирования. Но я не уверен что он умеет компилировать под все эти языки. Но как минимум текст набрать можно. Fasm поддерживается полностью и собирать/запускать/отлаживать приложения можно "используя" данный редактор (не совсем, редактор запускает отдельно компилятор и так же запускает отдельно отладчик), что и позволяет полноценно разрабатывать программы.

Я бы хотел сразу предупредить, практически ни какого обучения в статье не будет. Всё рассчитано на то, что вы уже хотя бы немного знаете ассемблер x86 и уже создавали простые программы под данную архитектуру (под Windows, Dos, Linux, а так может и MacOS).