Предположение 1.
Необходимые данные содержатся в оперативной памяти с постоянным смещением от начала сегмента данных игры.
Предположение 2.
Указатель на необходимые данные можно найти в качестве значения переменной, находящейся в оп с постоянным смещением.
Второе предположение расширяет первое - то есть маловероятно, что для каждой карты, сегмент с определенными данными имеет одинаковое смещение от начала сегмента памяти игры, наиболее вероятно что в некоторых ячейках с постоянным смещением хранятся указатели на определенные сегменты.
Предположение 3.
Необходимые данные не могут быть ослежены по указателям, либо они находятся в недоступном сжатом или зашифрованном виде.

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

Первый вариант - динамический скрипт - то есть, фактически это j файл, который изменяется в процессе выполнения. Как это может выглядеть - очевидно, что при загрузке карты, скрипт загружается в память игры (в каком виде - неизвестно - как есть, или в перешифрованном виде?), этот сегмент, очевидно имеет свое смещение, теоретически начало этого сегмента можно найти, и при условии что скрипт загружается с малыми изменениями, мы его можем редактировать прямо "на лету".
Минусы:
- Вероятность Crash'a игры с ошибкой I/O - одновременной записи и чтения. Как известно, каждая операция занимает время, и, вероятно, нет возможности смастерить механизм транзакций - то есть обьединить несколько операций в одну неделимую - вряд ли возможно. Значит вероятность пропорциональна количеству изменяемых в памяти байтов.
- Если скрипт перешифровывается, вероятность найти его и дешифровать, изменить и зашифровать, ничтожно мала.

Второй вариант - обеспечить чтение и интерпретацию, скажем, текстовых строк, введенных с клавиатуры. Интерпретация осуществляется J-скриптом. Затем с помощью сообщений, заставить игру, посылать скрипту текстовые сообщения - как угодно - хоть работая напрямую с памятью, хоть при помощи VKEY. Второй вариант при условии работы с VKEY или аналогами, обеспечивает стабильную работу самой игры - ибо манипуляции с памятью не производятся.

Следует отметить, что второй вариант при использовании VK - аналог 13 игрока, фактически исполнение игрока - сервера, который осуществляет манипуляции с картой(в пределах интерпретатора J) с помощью клавиатурных команд.

Возможен ли хоть один из описанных вариантов, и насколько он реализуем?

NETRAT добавил:
Предположение 2 не нашло подтверждения =( хотя так оно и должно быть на самом деле...

Скрипт оцифровывается в момент инициализации карты - от него остаются только имена переменных и функции - то есть динамический скрипт создать достаточно геморрно.

VKEY - кажется более геморрный вариант чем поставить все на переменные. Для кодирования функций с параметрами понадобится всего лишь штук 10 переменных всего, типа real, int, string и база данных по функциям. Изменение переменных вполне устойчиво. Таким образом можно заставить карту играть бесконечно изменяя ее с внешней подпрограммы. То есть, скажем, управление игрой можно осуществлять с удаленного хоста. Жаль только что подключение юзеров после старта "сервера" довольно геморрно... Хотя, теоретически, можно сформировать скрипт, который будет обмениваться данными с программой, а программа - с другими программами, те программы опять с варкрафтом - то есть прога + скрипт будут синхронизовывать содержимое всех карт с помощью эмуляции - выполнения J команд.

TONIC да забей - там все что нужно выдирается простым поиском, шанс ошибки ничтожно мал, несколькими тестами можно обнаружить зависимость в смещении данных. При чем тут взлом - если бы в варике была защита от взлома, то
1) адрес переменной постоянно бы менялся
2) значение шифровалось бы ключем
С необходимыми мне данными такое не производится, следовательно - фиг с ним

Когда ВОВ ломать буду, гляну =)