Всем добрый день.
Решился поделиться подходом, который может кому то пригодиться :-)

Предисловие: я читер. До глубины души. Играть честно - не прикольно ;-) А для того, что бы не играть честно, я очень часто ломаю игрушки. Как многие знают - для War3 сейчас появилось достаточно много карт с save системой. Ну, например DotD, NotD, ORPG, etc. Играть хочется, но убивать свободное время на "кач" не интересно, в связи с чем были испробованы разные подходы к генерации нужных мне save параметров.
Первой картой, которую ковырял, была NotD. Там функция генерации save информации была очень простой, я ее выдернул из war3map.j и запихнул в C (один в один), и с помощью препроцессора C скомпилировал. Синтаксис у Jass очень похож на C'шный, поэтому проблем не возникло. Вот у NotD и ORPG сохранение данных "размазано" по всему скрипту. Честно говоря, влом было собирать эти куски в месте, да и писать даже урезанный интерпритатор Jass (что, в принципе не сложно, BNF грамматика лежит в открытом доступе) тоже не хотелось. Решил все очень просто - подстановка нужных мне данных при загрузке оных.

Как известно, работа с паками идет через storm.dll. В ней замечательная функция SFileOpenFileEx, через которую все и работает. Когда war3 нужно достать какой либо файл, он дергает данную функцию.

Прототип функции (честно украденный из Inside MoPaQ):
BOOL WINAPI SFileOpenFileEx(HANDLE hMPQ, LPCSTR lpFileName, DWORD dwSearchScope, HANDLE *lphFile);

Как с ней работать:
hMPQ это HANDLE открытого MPQ архива (сразу скажу, по наблюдениям тут почти всегда NULL, кроме когда читают '(attributes)' из карты)
lpFileName - имя открываемого файла.
dwSearchScope - если 0, то ищем в MPQ файлах, если 1 то по файловой системе.
lphFile - куда поместить хендл файла.

Что я сделал: повесил hook на SFileOpenFileEx. В смысле сделал wrapper вокруг функции - когда вызывают оригинальную функцию, мой код получает управление, смотрит с какими параметрами ее вызвали и решает что делать дальше. Например - по маске заменяет с какими параметрами вызывать оригинальную SFileOpenFileEx.
Так как меня интересовала подмена war3map.j, я проверял что находится в lpFileName, если это war3map.j, то вызывал оригинальный SFileOpenFileEx с такими параметрами: SFileOpenFileEx(NULL, "путь_к_моему_war3map_j_на_винте", 1, lphFile). Т.е. открывал файл на винте. Если не такой файл - передавал параметры как есть.
Вот и все, собственно.

Почему выбрал такой подход: я, к сожалению (или к счастью? :-) ) не сильно разбираюсь во внутреннем формате карт. Если я и смог восстановить частично имена файлов в карте, то обратно воссоздать карту я так и не смог (что бы она грузилась в war3). Любая модификация карты as-is приводила к крешу в storm.dll.

Для чего может быть полезно, кроме читов: даже и не знаю. Для читов аж на ура подходит: CRC и имя карты не меняется, но зато можно подпихнуть свой скрипт. Т.е. хост может себе много всего хорошего начитить.
Для мапмейкеров это может быть полезно тем, что можно редактировать скрипт не пересобирая карту. В смысле - запустили War3, запустили карту, потестили, изменили чуть скрипт, запустили и так далее. Может это и не надо, я не знаю какие по "мощности" тулзы у War3.
В принципе, таким подходом я могу подпихнуть любые данные в игру, например заменить стандартные ресурсы своими, не изменяя вообще исходных данных игры (мод).
Ах да, логировать какие файлы грузит war3 я тоже могу :-)

Вобщем, если народ будет ЗА, то смогу выложить тузлу.

Edit: Тулза с исходниками в аттаче. Собственно как пользоваться:

1. Запускаем exe.exe, он должен висеть пока работает war3
2. Запускаем war3
3. Смотрим на логи в файле c:\logger.txt
4. Если war3 попытается открыть файл "war3map.j", оно его перенаправит на c:\myWar3Map.j

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

Я это видел уже и не раз.

Читов повесить невозможно, синхронизационные потоки не позволят это сделать.

А вот листфаил карты можно восстановить легко и быстро

Гм, не силен во внутренностях war3, но смею предположить, что такое синхронизационный поток.
Получается, что скрипт работает не только на сервере? Соответственно, есть некая синхронизация между тем, как клиенты исполняют один и тот же скрипт? Соответственно, те сервер сплиты, что иногда бывают - могут быть вызваны ошибками связанными с разными ветками исполнения?
Я правильно понял?

Скрипт выполняется локально и синхронизируется с сервером, провал синхронизации = дисконект

Гм, получается что все работают со своими скриптами. Т.е. у War3 не честная client/server архитектура. Ясно. Есть более подробное описание что именно проверяется при синхронизации? Ну, скажем, текущий Instruction Pointer в скриптах или состояние игровых объектов или что?

О мэпхаке слышал?

Так вот мэпхак это пример того, что нечестная клиентская часть может быть построена.

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

Мэпхек это не совсем то. Мепхек убирает или модифицирует поведение клиента. А я хотел модфицировать поведение скрипта, без изменения карты. Но в целом, да, Близзы молодцы, защиту от дурака предусмотрели.

P.S. Про КС можешь не рассказывать ;-)
P.S.S. А кого либо интересует возможность добавления новых функций в интерпритатор jass? (пока не говорим о возможности получения каких либо новых данных из движка, ибо эти данные еще нужно найти и интерпретировать)

Нативки в вар уже добовлять давно научились, требуется хук и C++ ну и руки, только это будет требовать модифицированый сервер и клиентов.

Мэпхак перекрывает часть байтов памяти, то про что ты написал есть ОРДЕР ХАК, прога которая "добовляет" к коду каждой карты некий триггер который используя Локал Плэера показывает все приказы отданые войскам другого игрока владельцу чита, на данный момент это недоступно большинству но существует уже давно

Ясно, понял, спасибо за объяснения :-)
В целом, Америки не открыл. :-)

Ладно, поковыряюсь во внутренностях, может чего хорошего еще найду.

Edit: Про добавление нужной мне функциональности в карту - легко решается использованием нативных функций jass без изменения скриптов. Т.е. никакой рассинхронизации и подмены скриптов. По сути, аналог client-hook читов для CS. Кстати, если уж так посмотреть, то можно сделать client-side бота, играющего за человека. Но кому такое надо - хз.

Програмист уровня професионала напрограмирует что угодно, но таким людям до вара нет никакого дела вообще...

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

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

тулза интересует, выкладывай:) желательно с исходниками)))

Лучше исходник выкладывай, сами скомпилируем, да и весит исходник меньше

Ок ок, я его немного "урежу", там у меня пара своих закрытых библиотек используется. Никто не будет против, если он в один прекрасный момент перестанет работать на какой то "странной" версии storm.dll? :-)

Без эксплойтов пожалусто, нам не надо сурсов ворования паролей через левые стормы

Блин, да зачем мне это надо? У меня просто есть своя готовая библиотека-патчер с дизассемблером. Делиться ею я не хочу. Вот ее уберу, а что бы заместить ее утрату, прийдется делать все хард-кодом (т.е. сравнение старта функции по маске). Да и вообще, там кода на 200 строк, на все про все.

Обновил шапку.