Вышла 127 версия браузера Google Chrome.
Вы уже предвкушавшие, что статья будет посвящена обзору нововведений в популярном браузере? Вообще-то да, только в очередной раз делать это будем через отладчик x64dbg (или любой другой по вкусу, кроме gdb).
Всем доброго времени суток! Набираем обороты... Сегодня мы будем 'пывнить" stack3.exe (ссылочка на файл, как обычно, на Github).
Stack3
Закидываем в Ghidra:
После того как я собрал систему на самом первом процессоре от Intel (4004), логичным, в каком-то смысле, шагом было перейти к Intel 8008. Концепция проекта та же - компилируем ассемблерный код на обычном ПК, отправляем скомпилированный бинарник на системную плату через USB, а современный микроконтроллер (stm32) эмулирует ПЗУ и ОЗУ для реального 50-летнего процессора, вставленного в DIP-сокет.
Вполне возможно собрать систему на аутентичных микросхемах, но такое решение проигрывает в удобстве использования - вместо запуска одной команды на ПК нужно будет постоянно перепрограммировать ПЗУ. Да и для меня основной интерес представляет сам процессор, а не его обвязка.
Так же как и в случае с 4004, моя плата эмулирует максимально возможный объем памяти, который нативно адресуется процессором. В данном случае, это 16Кб с некоторыми нюансами (об этом отдельно расскажу ниже).
И, конечно же, было занятно сравнить 4004 и 8008 в небольшой нишевой задачке. Да, сравнение весьма условное и какие-либо выводы по нему сделать сложно, но всё равно результаты вышли интересными.
Друзья, всех приветствую! Это третья часть нашего "пывна" :) Сегодня будем изучать работу Stack2.exe (скачать можно ТУТ).
Ссылки на предыдущие части:
Эксплуатация бинарных уязвимостей или учимся «пывнить» (Часть 1 / Stack0)
Реверсинжиниринг PWN-тасков или эксплуатируем бинарные уязвимости (Часть 2 / Stack1)
Stack2
Начнем мы, как обычно, со статического анализа. Запускаем GHIDRA:
При создании оконного клиента под MS-Windows для удалённого взаимодействия с LED-матрицами стояла задача сделать автоматический поиск всех табло в сети. Моей первой идеей было перебирать все существующие IP-адреса конкретной подсети, по очереди посылая на них запросы и ожидая что одно или несколько устройств отправят соответствующий ответ. Я быстро отказался от этой задумки, ведь подобный брутфорс будет сильно нагружать сеть, да и сам алгоритм не самый быстрый. Других идей по реализации на тот момент у меня не было. Мне предоставили копию другого клиента, где поиск осуществляется моментально по нажатию одноимённой кнопки, а приложение в табличном виде выводит IP и MAC-адреса с рядом другой информации об обнаруженных матрицах, если таковые нашлись. Эти данные затем могут быть использованы для подключения, конфигурации и отправки команд на найденные устройства. Не имея исходного кода, я подготовил дизассемблеры, отладчики и hex-редакторы, готовясь к глубокому анализу и разбору проприетарного алгоритма поиска, чтобы реализовать что-то подобное уже в своей программе.
Друзья всех приветствую! Продолжаем «пывнить» :) Кто не прочитал первую статью — она есть ТУТ!
Перед началом оставлю пару полезных ресурсов:
Теория — Статьи на тему, что такое и с чем едят Buffer Overflow
Практика — Крутые таски на тему PWN от Codeby Games
В этой статье будем решать таск Stack1 (скачать EXEшник можно ТУТ).
Продолжаем разговор об игрушечном компиляторе мной придуманного простейшего языка wend. На этот раз мы добрались до определённой вехи: наконец-то будем генерировать не питоновский код, а ассемблерный.
Ну а когда оно заработает, предлагаю решить задачу: как сэмулировать побитовые операции and-not-xor-or при помощи четырёх арифметических.
Компиляторы плохо справляются с генерацией кода для интерпретаторов, и можно превзойти их, написав интерпретатор на языке ассемблера.
Всем привет! В этой серии райтапов мы разберем известные задания по эксплуатации бинарных уязвимостей с 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. Сразу отмечу, что замечания и уточнения приветствуются, т. к. они позволят дополнить представленную информацию.
В предыдущих статьях цикла был приведен пример реализации ведомого модуля 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-подобные макросы повсюду. Кое-где – вкрапления ассемблера. Итераторы в стиле Степанова и мета-код в стиле Александреску. В общем, всё. Кроме ответа на самый важный вопрос: зачем?
