Реверс-инжиниринг *

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

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



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



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

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

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

Рассмотрим это на примере довольно редкого движка bitsquid. Он простой и компактный, но, тем не менее, имеет все необходимые для современных игр возможности. В прошлом году bitsquid вместе с его разработчиком был куплен компанией Autodesk, и теперь они собираются скрестить его с Maya и сделать свой собственный игровой движок, который, как они обещают, будет чем-то невероятным.

В этой статье мы исследуем аналог одной очень известной программы для Windows под названием «Блокнот» и напишем DLL расширяющее его возможности. Аналог называется NFOPad.

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

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

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

Спешим поделиться сразу двумя хорошими новостями.

По прошествии довольно длительного периода времени у проекта ReactOS вновь появился свой официальный канал на Youtube. А в качестве премьерного ролика мы покажем вам первый «официальный» ноутбук проекта. Им стал уже не очень молодой, но все еще бодрый Dell Latitude D531. Анонс данного события — именно то, что мы недавно обещали рассказать, говоря о компьютерах под маркой Dell.


Подписывайтесь, ставьте лайк, а видео на обзор присылайте вот сюда.

В предыдущей статье мы поговорили о возможном варианте решения ситуации с необходимостью указания ключа "/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. Если бы мы выбрали первый путь, то никакой статьи и не было, так что Вы уже должны были догадаться, к чему всё идёт.

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

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

В качестве примера одной из таких вещей можно назвать 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 начинает крашиться, предлагая отладить свой процесс. Ну, а что, почему бы и нет?

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

Современные версии ОС налагают на исполняемый код ограничения, связанные с требованиями безопасности. В таких условиях использование механизма исключений в инжектированном коде или, скажем, во вручную спроецированном образе может стать нетривиальной задачей, если не быть в курсе некоторых нюансов. В этой статье речь пойдет о внутреннем устройстве юзермодного диспетчера исключений ОС Windows для платформ x86/x64/IA64, а также будут рассмотрены варианты реализации обхода системных ограничений.

Вслед за обновлением эксплорера, благодаря стараниям и патчам разработчиков Ismael Ferreras Morezuelas, Stefano Toncich и Jared Smudde, в ReactOS значительно улучшилась поддержка как собственных, так и сторонних тем оформления. Ниже скриншоты примеров, как теперь может выглядеть рабочий стол.

Лет 7-8 назад мне случайно попалась игра CharmSolitaire, скопированная вместе с другими играми с чужого винта в процессе обмена информацией. Это такой не совсем обычный карточный пасьянс. В незарегистрированной версии на игру отводится один час, и открыта только половина уровней. В той копии время уже почти закончилось. Денег на покупку у меня не было, поэтому скорее всего я бы ее удалил. Но в то время я немного увлекался взломом и решил попробовать найти регистрационный код. Опыт был довольно интересным. В статье рассказывается об основных особенностях защиты, а также о том, как security through obscurity может ее ослабить.

В моей третьей статье про NES-игры я покажу техники, используемые для создания игровых движков, а именно реализацию скроллинга экрана, переключение банков памяти, организацию списка объектов, устройство системы анимаций персонажей, функции обновления игровых объектов (и обработку столкновений), устройство главной карты. Чтобы не быть голословным в описаниях, я буду приводить дизассемблированный код из конкретных игр (любимый всем «Darkwing Duck», с отсылками к «Chip & Dale» и «Duck Tales»), без него в этой статье не обойтись. В качестве примера рассматривается движок от «Capcom», на модификациях которого работает как минимум пара десятков игр.

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

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

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

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

В статье будет описан нестандартный способ поиска данных об уровнях в NES-играх — с помощью последовательного изменения всех данных в образе и исследования последствий («коррапт» в терминах ромхакеров). Для примера я покажу, как найти данные об уровнях в игре «Jackal» для NES и добавить один из её уровней в редактор CadEditor. Данный способ позволяет исследовать любую игру с блочной структурой уровней (почти любую игру на NES), без знания ассемблера X8502, требуются только начальные навыки работы со скриптовыми языками (Lua и Python).

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

За прошедшее время обнаружилось, что кристаллов «случайного моргания» — довольно много разновидностей. Фотографии и размышления авторов на тему принципа работы аналогичных кристаллов — siliconpr0n.org, cpldcpu.wordpress.com, hackaday.com. Удивляет то, что мало того, что кто-то предметно занимается разработкой и массовым производством такой казалось бы незначительной вещи как мерцающий светодиод — там еще есть и прогресс/конкуренция!

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

Данный способ я назвал «блочным» (оговорюсь, что многие термины в статье были придуманы мной, так как материалов на данную тему на русском нет; после исследования нескольких игр я занялся изучением англоязычных материалов и документации к редакторам игр для старых платформ, тогда уже нашлись некоторые аналогии, в таких случаях буду приводить свои термины с объяснением их значения и их английские версии). В качестве примеров я буду приводить уровни из игры «Darkwing Duck», а также других игр компании «Capcom», разобранных мной несколько лет назад.

Я постараюсь пропустить описание использования дизассемблера и техническую часть исследования (если будет интерес, можно сделать на эту тему отдельную статью), а остановлюсь на описании, как именно разработчики хранили данные. Зная, что именно искать, найти это внутри образа ROM станет намного проще. Бонусом я покажу готовый редактор уровней и несколько созданных на нём хаков классических NES-игр.

К сожалению, очень часто приходится слышать упреки, что ReactOS работает только в виртуальных машинах и компьютерах 15-летней давности. Спешим опровергнуть это расхожее мнение. Вашему вниманию предлагается видео, записанное одним из тестеров, с демонстрацией работы ReactOS на брендовом компьютере Dell Inspiron 530s.





Вскоре мы вновь вернемся к теме техники под маркой «Dell» с еще одной не менее интересной новостью.

Доброго здравия! Не удивлюсь, что Вы раньше даже не слышали об этой программе. Как и я, до того дня, когда мне пригодился Python Debugger. Да, знаю, есть pdb, но его функционал и то, как он представлен, мне совершенно не приглянулось. После непродолжительных поисков я наткнулся на этот замечательный продукт. Тут есть все, что может пригодиться в отладке ваших Python приложений (скажу сразу: данный язык я не изучал, поэтому, если какие-то неточности всплывут, просьба не ругаться).

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

Разбор ресурсов — это как разгадывание ребуса или кроссворда: начинаем с одной стороны, и постепенно узнавая значение все новых полей, разгадываем всё остальное. Сначала структура ресурсов игры была для нас как тёмный лес. Но постепенно мы узнавали о них всё больше и больше, одно тянуло за собой другое, и в итоге были исследованы и модифицированы практически все ресурсы игры: звук, текстуры, 3D-модели. Пример надписи, изменённой в виде модели вместе с текстурой, картами освещения и отражения, светящимися лампочками, бликами и тенью, можно видеть на картинке.

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

Многие обладатели хромобуков приобрели их исключительно для того, чтобы использовать их вместе с Windows. Установка данной ОС на хромобук сопряжена с рядом трудностей, например, с неработоспособностью встроенной клавиатуры и тачпада. В хромобуках используется Google embedded controller, для которого не существует драйверов под другие платформы.

Участник сообщества по «портированию» Windows на Acer C720 ($168.99), скрывающийся под ником coolstar, нашел оригинальное решение указанной проблемы. Он создал необходимый драйвер, взяв за основу исходные коды i8042prt из ReactOS.

Thanks to some code from @reactos & some patches I made, I have the Acer C720's keyboard working everywhere in Windows; with no kbdhelper :)

— CoolStar (@coolstarorg) 16 мая 2015