Assembler *

Как-то раз, решив сыграть во что-нибудь необычное, я обратил свой взгляд на MUD'ы — текстовые компьютерные многопользовательские игры с чатом. Играть в них можно как при помощи специализированных клиентов, написанных под конкретные сервера, так и по telnet'у.

Выбрав один из существующих на данный момент серверов (https://www.bat.org/), я вооружился дефолтным telnet-клиентом под Windows и… Почувствовал разочарование. Нет, дело вовсе не в игре, а в том, как с этой игрой взаимодействует telnet.exe. Печально осознавать, но ни один из вводимых мной символов (имя персонажа, разнообразные действия etc) не отображался на экране консоли. Да, команды отправлялись по нажатию клавиши Enter, но отсутствие даже минимального интерактива делало такую игру практически невозможной (особенно неудобно было удалять введённые ранее символы, ведь приходилось подсчитывать в уме, сколько символов ты уже удалил и на каком находишься в текущий момент).

Недолго думая, я решил попробовать приконнектиться к тому же самому серверу при помощи putty и… Вот это да! Я вижу вводимые мной символы!

Почему же echo не работает в telnet.exe? Можно ли это каким-то образом исправить? Давайте разберёмся.

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

Каждый, кто играл в эту игру, знает: если сейчас попытаться вытащить голубой шарик, на который показывает курсор, чтобы поставить вместо него бордовый, то один из приходящих новых трёх шариков скорее всего «заткнёт» это место. Если попытаться ещё раз вытащить — заткнёт снова. На протяжении всех долгих лет существования этого эффекта между моими коллегами периодически возникали споры, случайно ли это получилось, или нарочно сделана такая «подлянка», чтобы было труднее играть.

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

В этой статье вы сможете вернуться на 20 лет назад и увидеть, как примерно проходил тогда процесс реверс-инжиниринга. Мы рассмотрим 16-битный ассемблерный код, который выбирает место для шариков. Здесь не будет современных 32- и 64-битных инструкций, обрастающих специальными наборами команд, не будет вызовов всяких там dll, потоков и прочих ухищрений. Только простой код. Мне кажется, его поймут даже те, кто ни разу не видел ассемблера. Желающие смогут исправить алгоритм, чтобы он работал «честно».

Не так давно, закончив работу над очередной статьёй для Хабра, я решил оптравить её на ревью своему знакомому. Сохранив HTML-страницу со всем окружением (картинки, стили etc), я запаковал её в ZIP-архив и отправил адресату. Уже через пять минут я получил фидбек, который, вопреки моим ожиданиям, был связан вовсе не с самой статьёй, а с тем, что архив был абсолютно пустой. Почесав голову и решив, что я затупил с архивированием, я повторил процедуру, убедившись, что выделил все необходимые для запаковывания файлы. Спустя несколько минут знакомый снова разразился удивлённым «Ты что, шутишь?», в то время как я совсем не шутил.

Я начал собирать воедино все элементы паззла. Во-первых, я выяснил, чем он пытается открыть архив. Вдруг, в качестве viewer'а он использует какую-нибудь третьесортную фигню не пойми от какого разработчика? Однако им оказался дефолтный explorer.exe. Я же пользовался Total Commander'ом как для запаковки, так и для просмотра получившегося архива, и в моём случае он вовсе не был пустым:



Что, неужели это сборочка xxxWindowsUltimateEditionxxx подкачала? Я попытался открыть тот же самый архив на моём компьютере при помощи explorer.exe и наконец поверил своему знакомому — архив действительно выглядел пустым:



Кто же виноват в таком поведении? Давайте разберёмся.

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

Какая ассоциация связана у Вас с клавишей F5? Обновление страницы в браузере? Копирование файла из одной директории в другую? Запуск приложения из Visual Studio? А вот авторы notepad.exe подошли к этому вопросу довольно оригинально — по нажатию клавиши F5 происходит добавление текущей даты и времени в место, куда в этот момент указывает курсор. Всё было бы круто, если бы в notepad.exe была такая популярная и вполне естественная для большинства текстовых редакторов фича, как перечитывание содержимого текущего файла, которая, казалось бы, и должна быть назначена на F5 / Ctrl-R или ещё какой-нибудь общепринятый хоткей.

Мы можем ждать, пока её реализуют Microsoft, выбрать другой текстовый редактор (ведь это не единственное ограничение по функционалу стандартного notepad.exe) или… Взять в руки дизассемблер, отладчик и редактор PE-файлов.

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

В предыдущей статье мы поговорили о возможном варианте решения ситуации с необходимостью указания ключа "/D" для команды CD, входящей в поставку стандартного для операционных систем семейства Windows интерпретатора командной строки cmd.exe. Пришла пора поговорить о ещё одном поведении, которое тянется с незапамятных времён без особой на то причины.

На этот раз речь пойдёт об автодополнении путей, которое в большинстве сред и программных продуктов (и cmd.exe не является в данном случае исключением) осуществляется при помощи нажатия клавиш Tab / Shift-Tab. Думаю, никто не станет спорить с тем, что фича это довольно полезная и зачастую экономит до нескольких секунд времени, которое было бы потрачено на ручной ввод полного пути до интересущего пользователя файла или директории. Здорово, что она присутствует и в cmd.exe, однако…

Давайте поэкспериментируем. Запустим cmd.exe (Win-R -> cmd), начнём вводить команду «CD C:/», нажмём Tab, и… Вместо ожидаемых директорий наподобие «Program Files» и «Windows» получим первый по алфавиту объект из %HOMEPATH%, «слепленный» воедино с «C:/» (в моём случае это дало результат в виде «C:/.vim»). Почему? Думаю, те, кому по своему роду деятельности приходилось часто сталкиваться с cmd.exe, уже поняли, в чём тут дело — вместо forward slash'а для корректного автодополнения следовало использовать backslash (кстати, есть и другие исключения в этом плане). Особенно это непривычно для тех, кто большую часть своего времени проводит в других системах (например, *nix-like), где в качестве path separator'а используется как раз прямой слеш, а не обратный. Почему Microsoft решили использовать именно этот символ вместо уже ставшего на тот момент привычным для многих пользователей forward slash'а, объясняется, например, тут. Ну, а нам остаётся либо смириться с этим, либо взять в руки напильник отладчик и заняться исследованием cmd.exe. Если бы мы выбрали первый путь, то никакой статьи и не было, так что Вы уже должны были догадаться, к чему всё идёт.

Как протекал процесс, и что из этого вышло, читайте под катом (осторожно, много скриншотов).

В прошлой заметке я рассказывал о проблемах с рекурсией в функции Фибоначчи при использовании 64-битных переменных в качестве ее аргументов и компиляции кода с помощью Microsoft Visual C++. Выяснилось, что компилятор включает хвостовую рекурсию, когда используются 32-битные переменные, но не делает этого при переходе к 64-битным. На всякий случай напомню, что хвостовая рекурсия – это оптимизация, производимая компилятором, при которой некоторые виды хвостовых вызовов преобразуются в безусловные переходы. Узнать больше о хвостовой рекурсии.

В этот раз я хочу поделиться с вами одной проблемой, с которой столкнулся, когда решил сравнить итерационные и рекурсивные функции в C++. Между рекурсией и итерацией есть несколько отличий: о них подробно рассказано в этой стать. В языках общего назначения вроде Java, C или Python рекурсия довольно затратна по сравнению с итерацией из-за необходимости каждый раз выделять новый стековый фрэйм. В C/C++ эти затраты можно легко устранить, указав оптимизирующему компилятору использовать хвостовую рекурсию, при которой определенные типы рекурсии (а точнее, определенные виды хвостовых вызовов) преобразуются в команды безусловного перехода. Для осуществления такого преобразования необходимо, чтобы самым последним действием функции перед возвратом значения был вызов еще одной функции (в данном случае себя самой). При таком сценарии безусловный переход к началу второй подпрограммы безопасен. Главный недостаток рекурсивных алгоритмов в императивных языках заключается в том, что в них не всегда возможно иметь хвостовые вызовы, т.е. выделение места для адреса функции (и связанных с ней переменных, например, структур) на стеке при каждом вызове. При слишком большой глубине рекурсии это может привести к переполнению стека из-за ограничения на его максимальный размер, который обычно на порядки меньше объема оперативной памяти.

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

В качестве примера одной из таких вещей можно назвать cmd.exe. Да-да, это тот самый интерпретатор командной строки, входящий в поставку всех современных (и не очень) операционных систем семейства Windows. Исторических причин у него накопилось изрядное количество — достаточно вспомнить хотя бы то, как необходимо производить вставку и копирование в данный интерпретатор (ради справедливости стоит сказать, что в Windows 10 эту ситуацию наконец исправили, да и приложения наподобие ConEmu здорово в этом помогают). Но речь сегодня пойдёт о другом поведении, которое заствляет задуматься впервые столкнувшегося с cmd.exe человека, казалось бы, там, где этого совсем не требуется.

Как вы знаете, одной из команд, которые воспринимает cmd.exe, является «CD». Официальный хелп по этой команде сообщает следующее:

C:\Users\Nikita.Trophimov>CD /?
Displays the name of or changes the current directory.
[...]

Казалось бы, всё просто. Вызываешь CD без аргумента — в stdout выводится путь до текущей директории, передаёшь другую директорию в качестве аргумента — он сменяет текущую директорию на указанную. Подводные камни тут начинаются в том случае, если пользователь решил сменить директорию одновременно вместе с диском. Например, если вы находитесь в директории «C:\Windows\system32», то команда «CD D:\books» не сделает ровным счётом ничего. На мой взгляд, очевидного для новых пользователей в этом совершенно ничего нет, так что их спасает гугл или официальная документация, которая, кстати, сообщает:

Use the /D switch to change current drive in addition to changing current
directory for a drive.

Разумеется, этот вопрос, равно как и причины возникновения подобного поведения, уже не раз обсуждался в интернете (например, тут), так что останавливаться на подобных вещах мы не будем. Вместо этого мы попробуем отладить cmd.exe, чтобы убрать необходимость явного указания ключа "/D".

Как протекал процесс, и что из этого вышло, читайте под катом.

Перед разработчиками довольно часто встаёт выбор — сделать всё правильно, потратив на решение задачи уйму времени, или сделать так, чтобы работало, не особо вдаваясь в детали того, как именно это получилось. Со стороны заказчика, разумеется, наиболее привлекательной является некая золотая середина, которая в данном случае заключается одновременно и в хорошем понимании программистом выполненного таска, и в как можно меньшем количестве затраченных на него человеко-часов. С разработчиками тоже не всё так однозначно — с одной стороны, понимать, что происходит в своём собственном коде, это вполне естесственное желание (особенно если поддержка данного продукта также будет лежать на его плечах), а с другой стороны, если результаты работы приложения представлены в наглядном виде (графики / звуковые или видео-фрагменты etc), разработка разовая, и отдел тестирования говорит, что всё хорошо, то почему бы не проскроллить оставшуюся часть рабочего времени Хабр, посвятив время себе любимому?

Ближе к делу. В одной из предыдущих статей я уже упоминал о программе под названием «Говорилка». Несмотря на название, сама по себе она ничего не озвучивает, а лишь является связующим звеном между пользователем и речевыми движками, предоставляя более удобный интерфейс и возможность конфигурации. Одним из наиболее популярных в узких кругах движков является «Digalo 2000 text-to-speech engine» (далее — Digalo), ссылку на который можно найти как раз на сайте «Говорилки». Как вы уже, наверное, догадались из тематик моих предыдущих статей, не всё с ним так хорошо, и без багов тут также не обошлось. На этот раз проблема проявилась при озвучивании текста «ааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааааа». Немного поэкспериментировав, я обнаружил, что при достижении определённого количества «неразрывных» символов Digalo начинает крашиться, предлагая отладить свой процесс. Ну, а что, почему бы и нет?

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

Думаю, что большинство из местных обитателей знакомы с понятием сниффера. Несмотря на то, что конечная цель у них одна и та же (перехват пакетов, соответствующих определённым критериям), достигают они её совершенно разным образом. Какой-то софт слушает указанный сетевой интерфейс (например, Wireshark, где это реализовано при помощи библиотеки Pcap), а какой-то — перехватывает вызовы ответственных за взаимодействие с сетью WinAPI-функций. И у того, и у другого метода есть свои плюсы и минусы, однако если по задаче необходим перехват пакетов от конкретного заранее известного приложения, то второй вариант, как правило, банально удобнее. В этом случае нет нужды узнавать IP-адреса и порты, которые использует данная программа (особенно учитывая тот факт, что их может быть довольно много), и можно просто сказать «я хочу перехватывать все пакеты вот этого приложения». Удобно, не правда ли?

Пожалуй, самым популярным на сегодняшний день сниффером, работающим по принципу перехвата вызовов определённых WinAPI-функций, является WPE Pro. Возможно, многие из вас слышали о нём на различных форумах, посвящённых онлайн-играм, ведь именно для получения преимуществ в различных играх этот сниффер в большинстве случаев и используется. Свою задачу он выполняет прекрасно, однако у него есть один неприятный недостаток — он не умеет работать с 64-битными приложениями. Так уж вышло, что по одной из возникших задач мне как раз понадобилось перехватывать пакеты от 64-битного приложения, и я посмотрел в сторону Wireshark. К сожалению, использовать его в данной ситуации было не очень удобно — исследуемое приложение отправляло данные на разные IP-адреса, каждый раз открывая новый порт. Погуглив немного, я обнаружил, что готовых аналогов WPE Pro с поддержкой x64 нет (если они всё же есть, буду признателен за ссылки в комментариях — обратите внимание, что речь идёт о Windows). Автор WPE Pro не оставил никаких контактных данных на официальном сайте и в самом сниффере, так что я принял решение разобраться в этом вопросе самостоятельно.

Как протекал процесс и что из этого вышло, читайте под катом.

Все знают и любят ассемблер x86. Большинство его инструкций современный процессор исполняет за единицы или доли наносекунд. Некоторые операции, которые декодируются в длинную последовательность микрокода, или ожидающие доступа к памяти могут исполняться намного дольше — до сотен наносекунд. Этот пост — о рекордсменах. Хит парад из четырех инструкций под катом, но для тех, кому лень читать весь текст, я напишу здесь, что главный злодей — [memory]++ при определенных условиях.



КПДВ взята из документа Агнера Фога, который, наряду с двумя документами от Intel (optimization guide и architecture software development manual) содержат много полезного и интересного по теме.

Предлагаем Вашему вниманию интервью с Jeffrey Amelynck aka hidnplayr (на Хабре hidnplayr), бельгийским разработчиком в проекте KolibriOS. Ранее о некоторых его разработках уже была статья. Поговорим о Google Summer of Сode, Бельгии, сетевом стеке и перспективах сетевых программ для KolibriOS.

В предыдущей части разобрали и сняли первый слой обороны зловреда. Сделали дамп процесса после расшифровки основного кода, сохранив его в отдельном исполняемом файле.
Настало время разобраться с логикой и смысловой нагрузкой самого Downloader'а.

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

Что ж, ближе к делу. Есть такая широко известная в узких кругах программа под названием «Govorilka». Как объясняет её автор, это ничто иное, как «программа для чтения текстов голосом». По сути, так оно и есть. При помощи неё было озвучено множество популярных и не очень видео, рапространившихся по всей сети. Программа имеет консольную версию под названием «Govorilka_cp», которую удобно вызывать из своих собственных приложений, что, собственно, я и сделал в одном из своих проектов.

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

Учитывая, что говорилка не обновлялась уже несколько лет, а сам автор оставил вот такое «послание» на своём сайте



, я понял, что надеяться мне не на кого, и решать проблему придётся самому.

Как протекал процесс, и что из этого вышло, читайте под катом (осторожно, много скриншотов).

При создании программы на ассемблере (для примера будет приведён FASM) из-под ОС Windows возникает вопрос о том, какой выбрать формат файла.
Для определения формата создаваемого исполняемого файла используется директива «format» со следующим за ним идентификатором формата.
Под катом краткое описание COM-программы и EXE-программы форматов MZ и PE с шаблоном программ (в виде традиционного «Hello World!»).

Как-то вечером, сидя за компьютером, я наткнулся на одну инди-игру под названием «Shoot First» (игру можно скачать абсолютно бесплатно с сайта автора, а за донат любого размера вы получите специальную версию с двумя новыми видами оружия и ещё одним видом уровней). Геймплей её довольно незамысловат — игроку необходимо бегать по этажам в поисках прохода на следующий уровень, при необходимости собирая различные предметы (карты, ключи, etc) и попутно убивая встретившихся на его пути врагов. В общем, этакий action roguelike. Несмотря на кажущуюся простоту, игра меня довольно сильно зацепила, и я потратил не один час, пытаясь добраться как можно дальше и заработать как можно больше очков.

Кстати, об очках. После смерти персонажа и ввода имени игра отображает онлайн-таблицу рекордов:



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

Как протекал процесс, и что из этого вышло, читайте под катом (осторожно, много скриншотов).

Так бывает, что иногда реверсишь код, который занимается какой-то рутиной, не предполагающей каких-то серьезных вычислений и тут внезапно умножение на большую константу (поплачем, что на хабре нет хайлайтера для асма):

mov     edx, [ebp+end_of_buffer]
mov     eax, [ebp+src]
mov     ecx, edx
sub     ecx, eax
mov     edx, 80808081h
mov     eax, ecx
imul    edx
lea     eax, [edx+ecx]
mov     edx, eax
sar     edx, 7
mov     eax, ecx
sar     eax, 1Fh
sub     edx, eax
mov     eax, edx

Приветствую! Это мой первый пост на Хабре в принципе, но не первая статья о взломе ПО вообще, поэтому навык писать все с начала и по шагам, для начинающих крякеров, у меня есть. В данной статье я расскажу о том, как был отучен от триальности PVS-Studio.

^{HCF, n. Mnemonic for ‘Halt and Catch Fire’, any of several undocumented and semi-mythical machine instructions with destructive side-effects <...>
Jargon File}

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

^{Instructions, registers, and assembler directives are always in UPPER CASE to remind you that assembly programming is a fraught endeavor
golang.org/doc/asm}

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

1. Встраиваемые (embedded) системы.
2. Декомпиляция, обратная разработка (reverse engineering), компьютерная безопасность.
3. Высокопроизводительные вычисления (HPC) и оптимизация программ.

И конечно же, в каждой из этих областей существуют специфические требования, а значит свои понятия об инструментах и «свой» ассемблер. Эмбедщики смотрят в код через редактор и дебаггер, реверс-инженеры видят его в декомпиляторах вроде IDA и radare2 и отладчиках ICE, а HPC-спецы — через профилировщики, такие как Intel® VTune™ Amplifier, xperf или perf.
И захотелось мне рассказать об ещё одной области программирования, в которой ассемблеры частые спутники. А именно — об их роли при разработке программных моделей вычислительных систем, в простонародье именуемых симуляторами.