Assembler *

Этим летом вышла очередная игра из серии Batman Arkham, в ПК версии которой оказалось столько багов, что было принято беспрецедентное решение снять её с продаж. Я решил посмотреть, что же там такого ужасного.

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

На скриншоте изображён этот момент: вместо того, чтобы лететь вперёд, Бэтмен повернулся вниз головой, демонстрируя полнейшее пренебрежение к происходящему. Аналогичный баг был в предыдущей игре (Arkham Origins), и он до сих пор не исправлен. Видимо тот же самый кривой код был перенесён в новую игру. Попробуем найти, какие ошибки делают программисты в играх такого уровня, и исправить их.

Существуют различные мнения относительно производительности С++ и C#.

Например, сложно поспорить с тем, что код C# может работать быстрее за счет оптимизации под платформу во время JIT компиляции. Или например с тем, что ядро .Net Framework само по себе очень хорошо оптимизировано.

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

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

Попадались и утверждения о том, что код на С++ примерно в десять раз быстрее кода на С#.

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

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

Не очень хорошо помню, как я оказался в дебаггере DOSBox, и почему я ковырялся в 16-битном ассемблере, восстанавливая функцию распаковки ресурсных файлов MM3.CC – но это было здорово. Игра у меня появилась на какой-то из последних распродаж humble bundle, а потом в сети я наткнулся на страницу Джеффа Людвига, где описывались проблемы с модификацией игры, связанные с компрессией в MM3.CC. В частности, там было написано следующее:

Оказалось, что этот алгоритм довольно сложно взломать, и пока ещё никто не научился распаковывать эти данные.

Вызов был принят. В его статье расписано, как он пытался бороться с алгоритмом. Я же распишу, как это делал я сам, и в конце дам ссылку на утилиту с открытым кодом, которая умеет не только распаковывать, но и запаковывать файл MM3.CC file.

DOS Packer

Посмотрев на MM3.EXE, я обнаружил, что это сжатый исполняемый файл DOS, с неким несжатым оверлеем, в начале которого стоит FBOV. Я ничего не знал про ДОСовские компрессоры, но я подсмотрел у Джеффа Людвига, что он использует вещь под названием “Universal Program Cracker” v1.11. Я нашёл версию 1.10 (выпущенную 25 июня 1997 года) и распаковал ехе. И мне удалось даже правильно обработать данные оверлея. И всё равно мне хотелось узнать название паковщика. Мне подсказали, что нужно использовать программу Detect It Easy, и действительно – она выдала:

EXECUTRIX-COMPRESSOR(-)[by Knowledge Dynamics Corp]
Borland TLINK(2.0)[-]

Для любителей истории могу рекомендовать старые ветки обсуждений, касающихся этого софта – от 1991 и 1995 годов:

https://groups.google.com/forum/#!topic/comp.os.msdos.programmer/QsjHLY6Kb4s
https://groups.google.com/forum/#!topic/comp.compression/IAj2-VHbtl4

По сообщениям в комментариях к статье про блокнот, во всех версиях Microsoft Excel, начиная по крайней мере с '97 и до самых новых, в имени листа не всегда можно ввести большую букву Ж. Данная проблема обсуждается в сети уже давно, например на этом форуме забавно наблюдать, как некоторые утверждают, что у них проблемы нет, а у других есть, но не всегда, и никто не понимает, почему так. На первый взгляд можно подумать, что это просто недоработка программистов: они хотели не дать пользователю ввести символ ':', и просто не подумали о том, что Ж находится на той же кнопке.

На деле оказалось всё гораздо хуже. Описать нормальными словами то, что происходит в excel, когда вы просто нажимаете кнопку 'Ж', практически невозможно. Поэтому я попытаюсь обрисовать в целом процесс исследования, сократив его где возможно, и не слишком перегружая статью ассемблерным кодом. В итоге мы узнаем, почему получается так, что не любые символы можно ввести, и как это можно исправить.

В стандартном блокноте для всех версий Windows, начиная примерно с 2001 года, имеется ошибка, про которую практически все знают, но никто не собирается её исправлять. И это понятно, ведь это не критическая уязвимость, ничьей безопасности она не угрожает. Да и пользуется ли кто блокнотом вообще?

Тем не менее, сам факт довольно странный, поэтому мы попробуем найти эту ошибку в коде 64-битного и 32-битного notepad.exe от windows 7, исправим её, и выясним наконец, почему же она возникла. Заключается ошибка в следующем:

Если в блокноте включена опция «перенос по словам» (word wrap), то после сохранения файла начинаются всевозможные глюки: строки начинают разъезжаться, курсор улетает, текст вводится не туда, куда вы ожидаете, и так далее.

Удивительно, но никто не написал ничего про игрушку «TIS-100», которая недавно появилась в Steam (стоит всего 150 рублей, уже 460 положительных отзывов против 6 отрицательных).

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

Итак, о чем игра?

Одна из немногих стандартных утилит Windows, которой я пользуюсь практически каждый день — это snippingtool, или, попросту говоря, «Ножницы». Свою задачу она выполняет на ура (впрочем, многого от неё я и не требую), а из прочих полезностей можно отметить вставку выделенного региона напрямую в Skype, без необходимости сохранять изображение в файл — достаточно всего лишь нажать Ctrl-V в окне ввода сообщений. Приятно, что название файла в таком случае будет состоять из даты и времени вместо, например, хеша.

Несмотря на то, что в самом Snipping Tool имеется возможность обводить определённые части изображения, порой этого недостаточно:

• Во-первых, «Ножницы» не умеют обрабатывать комбинацию клавиш Ctrl-Z, т.е. сделать в них Undo не получится, в связи с чем одна-единственная ошибка в редактировании может заставить начать всё с начала
• Во-вторых, обводить изображение можно только при помощи Pen'а и Highlighter'а, что не очень удобно, когда надо, например, указать на прямоугольную область

Именно по этим причинам я зачастую обращаюсь к mspaint. А вот у него есть обратный недостаток — вставить изображение напрямую из буфера обмена в Skype уже не получится.

В чём же причина такого поведения? Можно ли его исправить? Давайте разберёмся.

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

Все проблемы в области Computer Science могут быть решены введением дополнительного уровня косвенности. За исключением одной: слишком большого числа уровней косвенности.
All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection.

Программные интерпретаторы известны своей невысокой скоростью работы. В этой статье я расскажу, как их можно ускорить.
Я давно уже хотел поподробней остановиться на создании интерпретаторов. Прямо таки обещал, в том числе самому себе. Однако серьёзный подход требовал использования более-менее реалистичного кода для примеров, а также проведения измерений производительности, подтверждающих (а иногда и опровергающих) мои аргументы. Но наконец-то я готов представить почтенной публике результаты, причём даже чуть более интересные, чем собирался.
В данной статье будет описано семь способов построения программной ВМ для одной гостевой системы. От самых медленных мы проследуем к более быстрым, поочерёдно избавляясь от различных «неэффективностей» в коде, и в конце сравним их работу на примере одной программы.
Тех, кто не боится ассемблерных листингов, испещрённого макросами кода на Си, обильно удобренного адресной арифметикой, goto и даже longjmp, а также программ, использующих копипаст во имя скорости или даже создающих куски самих себя, прошу пожаловать под кат.

В данной статье сделана попытка подробно описать исследование одного занимательного crackme. Занимательным он будет в первую очередь для новичков в реверс-инжиниринге (коим и я являюсь, и на которых в основном рассчитана статья), но возможно и более серьезные специалисты сочтут используемый в нем приём интересным. Для понимания происходящего потребуются базовые знания ассемблера и WinAPI.

Думаю, многие из вас хотя бы раз в своей жизни занимались модификацией любимой компьютерной игры. Это могло быть редактирование ресурсов (например, моделей персонажей и объектов из GTA), написание разнообразных скриптов (к примеру, планировщик задач для Dwarf Fortress, запускаемый при помощи DFHack) или разработка модов для своего сервера Minecraft, которые работали под управлением Minecraft Forge.

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

Сидя однажды вечером за одной из своих любимых игр под названием UnReal World (далее — URW), я в очередной раз столкнулся с невероятно неудобным для меня поведением. Естественное желание практически любого игрока при встрече с более-менее сильным врагом — моментально сохраниться, чтобы не потерять всё, чего он достиг на данный момент (да, некоторые сочтут это «хамством» / «читом» / etc, но о вкусах не спорят). Проблема заключается в том, что сохраниться-загрузиться по-быстрому в URW просто не получится. При сохранении персонажа автоматически выполняется выход в главное меню, а выйти не сохранившись, чтобы вернуться к предыдущей точке сохранения, можно лишь убив процесс игры через taskmgr. В итоге в большинстве случаев сложные бои на поздних этапах игры (когда уже действительно жаль терять всё то, что накопил за долгое время) заканчивались безумными комбинациями и заученными наизусть сочетаниями клавиш.

И тут я задумался. А что мешает нам добавить своё собственное меню быстрой загрузки и сохранения? Вооружившись отладчиком, редактором и анализаторами PE-файлов, я принялся за работу.

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

Я много раз сталкивался с задачей динамической генерации кода (например, при написании эффективного сериализатора или компилятора DSL). Это можно делать разными способами, какой из них лучший – дискуссия для отдельной статьи. По ряду причин я предпочитаю Reflection.Emit и CIL (Common Intermediate Language) и расскажу, с какими проблемами пришлось столкнуться на этом пути, а также об их решении: умной обертке над ILGenerator – GroboIL из библиотеки Graceful Emit.

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

Если вы ни разу не сталкивались с использованием IL-кода, то статья может показаться сложной для понимания, поскольку содержит много примеров кода с использованием IL. Для получения базовых знаний рекомендую прочитать статью Introduction to IL Assembly Language.

Всем привет. Я решил попробовать начать цикл статей по модернизации нашей с вами любимой IDA Pro.
В каждом из туториалов я попытаюсь раскрыть довольно таки сложную и мало изученную тему: написание различных модулей:

• загрузчики;
• плагины;
• дебагер-плагины;
• процессорные модули;
• скрипты.

И, если процессорные модули, плагины и скрипты — тема все таки более менее раскрытая, то все остальное — практически полный мрак (в конце статьи я дам список литературы и проектов, где есть хоть что-то).

Итак, первая статья из цикла будет посвящена написанию плагина-отладчика, а точнее предварительной теории. В штатной поставке IDA SDK уже имеются исходники основных дебагеров (Windows, Linux, Mac). Но как быть, например, с Amiga, M68000?

Так как тема реверс инжиниринга довольно популярна на хабре, решил поделиться своими наработками по этой теме. Мне, как и многим любителям визуальных новелл, знакома такая программа, как AGTH (Anime-Game-Text-Hooker). Она позволяет извлекать текст из новелл для последующего перевода(большинство игр – японские). Разработка этой программы, судя по всему, была прекращена ещё в 2011м году, исходников найти не удалось, а так как душа хотела дополнительных фич, было принято решение отреверсить эту программу и на основе полученных данных воссоздать альтернативную оболочку со всеми недостающими мне функциями.

В прошлом топике (1 ) мы говорили о числах с плавающей точкой/запятой, нормализованных в соответствии со стандартом IEEE754. Там же были рассмотрены денормализованные числа, искусственное введение которых в стандарте привело к чудовищным программно-аппаратным затратам, тормозящим процессы компьютерной обработки чисел в десятки и сотни раз. Но, так уж ли нужна эта самая нормализация и тем более оправдано ли введение экзотического класса денормализованных чисел в компьютерную арифметику? Попробуем разобраться с этим вопросом.

В комментариях к предыдущей статье у нас разразился небольшой спор на тему того, помогает ли команда «set localecho» в решении проблемы с отсутствием echo при взаимодействии с сервером bat.org. Я стоял на том, что команда эта не сделает ровным счётом ничего для исправления рассмотренной ситуации, и говорил это вовсе неспроста — специально после одного из комментариев я решил ещё раз проверить мою правоту в данном вопросе. Проделав все необходимые действия (запуск telnet.exe, нажатие Ctrl-], ввод команды «set localecho» и двойное нажатие клавиши Enter), я в очередной раз убедился, что был прав. О чём же тогда так уверенно твердят остальные?

Я попросил выслать мне бинарник «работающего» telnet-клиента и версию ОС, на котором он запускался, в личку. Убедившись, что версии ОС совпадают (использовалась Windows 7 SP1 x64), я обратил своё внимание на сам telnet-клиент. Хеши совпали. Запустив «работающий», по заверению пользователя k0ldbl00d, бинарник, я с удивлением обнаружил, что на моём компьютере не работает и он.

Может быть, дело в окружении, в котором выполняется telnet.exe? Оригинальный исполняемый файл был взят из директории "%WINDIR%\System32", так что я запустил свой telnet-клиент оттуда, и… Обнаружил, что команда «set localecho» корректно отрабатывает при таком раскладе. А если скопировать тот же самый исполняемый файл в любую другую директорию и воспользоваться уже им, то, несмотря на то, что основной функционал telnet.exe будет продолжать работать, команды перестанут выполнять то, что от них требуется.

В чём же дело? Давайте раберёмся.

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

Как-то раз, решив сыграть во что-нибудь необычное, я обратил свой взгляд на 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-файлов.

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