Не проверял, но в данном контексте это не имеет значения.
Функция манифеста появилась лишь в Visual Studio 2005 / MSVC 8, а описанная эвристика — ещё позже. На момент написания Казаков нельзя было предвидеть и избежать такого поворота. Это я и хотел выразить в данном предложении.
1. Да, именно так. rec-файл в основном состоит из буфера команд (ExBuf), которые передавались по сети. Действия ИИ рассчитываются заново при просмотре, так что игра как будто играется заново.
В процессе игры постоянно задействуются псевдослучайные числа из файла random.lst, и в определённом такте текущее случайное число сохраняется в записи. Это один из способов, которым игра проверяет синхронизацию. Про механизм синхронизации Казаков вообще можно отдельную статью написать :)
2. Наверняка сказать не могу, но скорее всего вычисляется во время воспроизведения, т.к. в механизме экрана статистики я не заметил разделения на игру и запись. При этом вполне возможно, что значения ресурсов периодически сохраняются в файле записи для проверки синхронизации.
При этом, например, grep PSET | grep free показывает, что кроме деструктора этот регион памяти освобождается и в функции ClearPingInfo() в Mplayer.cpp:3124. Также есть и несколько вызовов realloc(). А какой-либо синхронизации я нигде не увидел…
Да, по всему проекту около 250 ассемблерных вставок. Суровая оптимизация из 2000-ых. А ещё некоторые статические библиотеки ссылаются на канувшие в лету функции стандартных библиотек. Так, например, пришлось переписать отрывок в IChat/Chat/chatSocket.c и заменить в Peer.lib объект chatSocket.obj, чтобы убрать из линковки ссылку на устаревшую vsprintf() и хотя бы собрать этого динозавра в VS2015 :)
Всё указывает на это. Сложно сказать, где собака зарыта, т.к. DirectPlay сам по себе многопоточен, а помимо него используется и свой протокол на основе UDP. Может, мне просто «повезло» наткнуться на эту ошибку, т.к. в сети описание именно такого поведения я не нашёл.
В самом начале присваивается 0x01 на случай «обычного» заказа одной единицы, затем в сависимости от результатов GetKeyState другие значения (в примере выше 0x05, 0x14, 0x32, 0x0F или 0x24).
раз уж у нас stdcall
Честно говоря, достоверно мне это известно не было. Как можно проверить, что exe'шник придерживается calling convention и что регистр esi можно безопасно использовать?
И в случае stdcall я ведь всё равно обязан положить esi на стек, прежде чем использовать его в патче, а затем восстановить, не так ли?
Да, без ошибок не обошлось. По поводу регистра cx: к нему я пришёл, когда искал информацию про циклы в асм. В конце концов я от него отказался, как и от использования loop. Ну а на счёт dec и jnz вы, конечно, правы. Как-то даже стыдно, что сам не додумался. С другой стороны, как я уже писал, опыта с ассемблером до реверса «Казаков» у меня не было от слова совсем. Так что спасибо за совет, в следующий раз учту)
Была, но в некоторых случаях она не так удобна, как кажется. Например, цена наёмных драгунов в дипломатическом центре растёт с каждым драгуном, которого вы уже наняли. Т.е. намного дешевле сразу заказать 500 единиц, чем ставить на бесконечность. Или если вы хотите не отвлекаясь заказать подряд ровно по взводу пикинёров и мушкетёров в одной казарме или чередовать производство каждые 50 единиц.
Честно говоря, я сам удивился, когда услышал это. Даже подумал, что админ таким образом выгораживает пользователя, который всё-таки открыл приложение. Во всяком случае, мне это показалось более вероятным, чем подобная настройка почтового клиента в корпоративной среде. С другой стороны, медицинские учреждения часто не придают должного значения ИБ.
Только с утра прочитал статью, как в этот же день пришлось столкнуться с описанным троянцем. Правда, админ потерпевшей стороны уверял, что заражение произошло без открытия приложения: У пользователя в Outlook исполнение JavaScript в теле письма было разрешено по умолчанию...
Функция манифеста появилась лишь в Visual Studio 2005 / MSVC 8, а описанная эвристика — ещё позже. На момент написания Казаков нельзя было предвидеть и избежать такого поворота. Это я и хотел выразить в данном предложении.
1. Да, именно так. rec-файл в основном состоит из буфера команд (ExBuf), которые передавались по сети. Действия ИИ рассчитываются заново при просмотре, так что игра как будто играется заново.
В процессе игры постоянно задействуются псевдослучайные числа из файла random.lst, и в определённом такте текущее случайное число сохраняется в записи. Это один из способов, которым игра проверяет синхронизацию. Про механизм синхронизации Казаков вообще можно отдельную статью написать :)
2. Наверняка сказать не могу, но скорее всего вычисляется во время воспроизведения, т.к. в механизме экрана статистики я не заметил разделения на игру и запись. При этом вполне возможно, что значения ресурсов периодически сохраняются в файле записи для проверки синхронизации.
При этом, например, grep PSET | grep free показывает, что кроме деструктора этот регион памяти освобождается и в функции ClearPingInfo() в Mplayer.cpp:3124. Также есть и несколько вызовов realloc(). А какой-либо синхронизации я нигде не увидел…
Честно говоря, достоверно мне это известно не было. Как можно проверить, что exe'шник придерживается calling convention и что регистр esi можно безопасно использовать?
И в случае stdcall я ведь всё равно обязан положить esi на стек, прежде чем использовать его в патче, а затем восстановить, не так ли?
https://yadi.sk/d/z6rTlJfRpvRn8
(Не думал, что это настолько обсуждаемая тема — 492 тыс. ответов).