California Games

Увидел в одном ролике на Ютьюбе незнакомую ДОС-игру наподобие сокс. Заинтересовало, стал гуглить. Выяснил, что это сабж. В зоне загрузок наткнулся на сопроводительный комментарий:

Стало любопытно, что за странь. В play.bat обнаружил loadfix calgames.exe. Почитал про команду loadfix. Стало интересно выяснить, где же разработчики умудрились накосячить.

Посидел в отладчике. Оказалось, они для определения доступной памяти вызывают int 21h/48h с размером 7FFFh, ожидая, что вызов зафейлится и в BX будет лежать размер максимально доступного блока памяти. Любопытно, что когда вызов не фейлится они творят какую-то дичь и записывают в ту же переменную адрес сегмента выделенного блока и далее трактуют его как максимально доступный размер. Собственно, поэтому игра и не запускается в DOSBox без плясок с бубном (т.к. у DOSBox есть 7FFFh параграфов доступной памяти).

В общем написал загрузчик, который заменяет 7FFFh на FFFFh, чтоб вызов int 21h/48h гарантированно фейлился даже под DOSBox-ом, и словил следующие грабли. Оказалось, что полученное значение они сравнивают с 4D80h как числа со знаком (jge вместо jae) и здесь при объёме свободной памяти более 7FFFh параграфов (524272 байта) логика ломается во второй раз. Это тоже поправил.

Собственно логично было бы в загрузчик интегрировать и патч от NewRisingSun, но я с ходу не могу понять в чём его смысл. У меня и без него всё вроде бы как работает. По крайней мере никаких вопросов защиты от копирования не задаёт. (UPD: Это было ложное впечатление :-)

Собственно, у меня два вопроса:
1) Осталась ли какая-то информация о том патче? Что он улучшает и как это проверить?
2) Нужен ли сайту загрузчик, который бы позволял загружать немодифицированный оригинальный экзешник игры?

 

Похоже я кэш ФС у DOSBox забыл обновить, когда экзешники переименовывал. Теперь вижу, что без патча вылетает.

 

Конечно, осталась!
Я поднимал вопрос об этой игре на другом форуме года два назад. Тогда я заметил, что с ней есть две проблемы при использовании в DOSBox: без loadfix игра не запускалась, жалуясь на нехватку памяти, и в любом случае не работала клавиатура в режимах EGA/VGA и MCGA/VGA.
Первая проблема исправляется легко - я добавил в архив PLAY.BAT с загрузкой loadfix. А со второй разобрался зарубежный мастер NewRisingSun.
Если интересуют технические подробности, то вот что он тогда пояснил:

Трудно сказать. А он работает с выложенными на сайте образами дискет?
Исправленный ЕХЕ у выложенной дискетной версии не только правит указанный баг с клавиатурой, но и устраняет защиту от копирования.

 

Спасибо за ответы.

Я во втором посте исправился. Патч действительно нужен, я просто в ночи запутался подменяя экзешники.

Чтобы надолго не отвлекать общественность пока я пойму суть патча NewRisingSun, я просто затянул его в свой загрузчик. Теперь загрузчик можно использовать с немодифицированными файлами с оригинального образа.

Суть простая: загрузчик загружает оригинальный calgames.exe, уже в памяти патчит его на предмет определения свободной памяти + накладывает патч от NewRisingSun и возвращает управление. Я по-быстрому проверил в DOSBox и под MS-DOS 6.22. Вроде работает.

Если есть интерес попробовать, загрузчик выложил сюда: Забытый файл
Исходники доступны тут: GitHub - mintware/cgload: Loader for California Games (1988)

 

А что именно?
В выложенном на сайте ЕХЕ сидит далеко не только данный патч.
Он - это собственно семь байтиков, которые я внёс в имевшийся ЕХЕ по указанию NewRisingSun'а для исправления бага с клавиатурой:
B6 08 A1 5C 5E 0A E4 -> B4 00 CD 16 B4 00 C3
Вот только тот ЕХЕ был уже взломанный! И у меня такое впечатление, что там кроме взлома ещё всякий мусор есть или непонятно что.
Если получится во всём разобраться, то, возможно, лучше будет перевзломать оригинальный ЕХЕ.

 

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

Хм, это интересно, т.к. все отличия, что я видел, были исключительно в забивании NOP-ами (90). Сейчас ещё раз внимательно посмотрел и действительно дальше по смещению 980Bh было ещё одно отличие, которое я не заметил, как раз о котором вы пишете. Добавлю его сегодня в загрузчик и перезалью его. Спасибо!

Тем странее, что у меня без этого патча клавиатура работает и в DOSBox и на реальном железе в режиме EGA/VGA. Я правильно понимаю, что проблема возникает единственно только на экране выбора видеорежима, а в самой игре никак не проявляется?

 

Тогда у меня проблема была именно в игре - и на реальном оборудовании, и в DOSBox. Вот на этом экране - нельзя было набрать имя:


Если сейчас оно работает, то это и правда странно... Разве что в новых версиях DOSBox что-то исправили? Ну а на старых ПК спасала та строчка в CONFIG.SYS.

 

Там похоже как раз отключение защиты от копирования было. Я его пока не анализировал на предмет оптимизации, скопировал как есть.

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

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

 

В том ЕХЕ, помимо семи байтов патча для клавиатуры, было задолго до нас изменено ещё аж 22 байта, все - на 90. Либо это чей-то неоптимальный взлом, либо ещё какие-то правки. Скорее, думаю, первое. Ибо для оптимального взлома, насколько я понял, достаточно всего трёх байтиков (это из чьего-то другого ЕХЕ):
51 -> 90 @ 43C2;
33 C0 -> EB 7D @ 43C8

А чем неоптимальным и как переделали, если не секрет?

 

Не секрет. Оригинальный код там такой:

Код:

seg000:982C readKeyWithEcho proc near
seg000:982C                 mov     dh, 1
seg000:982E                 jmp     short @common
seg000:9830 ; ---------------------------------------------------------------------------
seg000:9830
seg000:9830 readKey:
seg000:9830                 mov     dh, 8
seg000:9832
seg000:9832 @common:
seg000:9832                 mov     ax, ds:word_5E5C
seg000:9835                 or      ah, ah
seg000:9837                 jnz     short @int21
seg000:9839                 mov     ds:word_5E5C, 0FFFFh
seg000:983F                 jmp     short @coda
seg000:9841 ; ---------------------------------------------------------------------------
seg000:9841
seg000:9841 @int21:
seg000:9841                 xchg    ax, dx
seg000:9842                 int     21h
seg000:9844                 mov     ah, 0
seg000:9846
seg000:9846 @coda:
seg000:9846                 retn
seg000:9846 readKeyWithEcho endp

Это две функции с общим телом. Одна читает символ со стандартного ввода с эхом, другая -- без. Здесь видно, что в регистре AX ничего не ожидается, т.к. его значение безусловно перезаписывается (mov ax, ds:word_5E5C).

После наложения патча от NewRisingSun код становится таким:

Код:

seg000:982C readKeyWithEcho proc near
seg000:982C                 mov     dh, 1
seg000:982E                 jmp     short @common
seg000:9830 ; ---------------------------------------------------------------------------
seg000:9830
seg000:9830 readKey:
seg000:9830                 mov     ah, 0
seg000:9832
seg000:9832 @common:
seg000:9832                 int     16h
seg000:9834                 mov     ah, 0
seg000:9836                 retn
seg000:9837 ; ---------------------------------------------------------------------------
seg000:9837                 jnz     short @int21
seg000:9839                 mov     ds:word_5E5C, 0FFFFh
seg000:983F                 jmp     short @coda
seg000:9841 ; ---------------------------------------------------------------------------
seg000:9841
seg000:9841 @int21:
seg000:9841                 xchg    ax, dx
seg000:9842                 int     21h
seg000:9844                 mov     ah, 0
seg000:9846
seg000:9846 @coda:
seg000:9846                 retn
seg000:9846 readKeyWithEcho endp

Меня в нём напрягает то, что в случае вызова readKeyWithEcho значение регистра AH не инициализируется, а наследуется от вызывающей функции, где оно может быть каким угодно. Поэтому я сделал так:

Код:

seg000:982C readKeyWithEcho proc near
seg000:982C                 mov     dh, 1
seg000:982E                 jmp     short @common
seg000:9830 ; ---------------------------------------------------------------------------
seg000:9830 readKey:
seg000:9830                 mov     dh, 8
seg000:9832
seg000:9832 @common:
seg000:9832                 jmp     short @int16
seg000:9834 ; ---------------------------------------------------------------------------
seg000:9834                 pop     si
seg000:9835                 or      ah, ah
seg000:9837                 jnz     short near ptr @int16+1
seg000:9839                 mov     word ptr ds:5E5Ch, 0FFFFh
seg000:9839 ; ---------------------------------------------------------------------------
seg000:983F                 db 0EBh ; d
seg000:9840 ; ---------------------------------------------------------------------------
seg000:9840
seg000:9840 @int16:
seg000:9840                 mov     ah, 0
seg000:9842                 int     16h
seg000:9844                 mov     ah, 0
seg000:9846                 retn

Т.о. AH всегда инициализируется в 0, а за счёт переиспользования хвоста от оригинальной функции патч меняет только 5 байт против 7 у NewRisingSun.

--- добавлено 21 июн 2023, предыдущее сообщение размещено: 21 июн 2023 ---

Да, этот вариант выглядит лучше и на первый взгляд работает как надо. Затянул его в загрузчик вместо старого. Ссылку обновил.

--- добавлено 21 июн 2023 ---

После некоторых раздумий и экспериментов патч обхода защиты от копирования удалось сократить до одного байта. Ссылку обновил.

 

@unterwulf, я вижу, вы отлично разбираетесь в ассемблере.
Но ведь "California Games" и так уже работала. А не будет ли вдруг желания посмотреть одну игру, которую пока заставить работать не удалось?
Если будет, напишу в личной переписке.

 

Просто на досуге ковыряюсь со старьём, ограничиваясь 16-битным реальным режимом.

Можно попробовать. Но если местные спецы уже пробовали и не осилили, то прогноз скорее всего неутешительный.

Ок. Буду ждать.