CRACKS: Проблемы с пиратскими копиями

CRACKS: Проблемы с пиратскими копиями

Автор: Jaxon Hollis

Пиратские копии уже давно перестали быть запретной темой. Порой это единственный способ вообще достать какую-то определенную программу. В интернете сейчас можно найти множество софта для Спектрума, который когда-то продавался, а теперь доступен каждому. В этой статье Jaxon Hollis рассуждает о том, почему игру нужно нормально «крэкать», а не сбрасывать через снапшот. Хочу сразу заметить: хотя в тексте постоянно упоминается Multiface, как раз к нему претензий меньше всего, поскольку у него есть собственное ОЗУ. Автор здесь скорее имеет в виду ЛЮБОЙ хак-интерфейс, просто используя слово Multiface.

Наверное, каждый из вас хоть раз разочаровывался тем, в каком виде вам доставалась хорошая игра. Титульная картинка испорчена, меню выбора параметров пропало или еще чего-то не хватает. Особенно несладко приходилось пользователям 128K из-за некоего типа по кличке «CARGADOR», который сбрасывал 128k-программы в режиме 48k.

Я считаю верхом глупости «снапить» (или сбрасывать через Multiface) программы лишь для того, чтобы проще закинуть их на дискету (Золотые слова! — прим. L.C.D.). Быстро — возможно, но отнюдь не умно. Ниже я попробую объяснить почему:

Возьмем, к примеру, BETADISK. При нажатии на кнопку сброса (Snap) все регистры пушатся (PUSH) в стек под указатель SP. Это плохо, поскольку игра может использовать вызовы CALL, и загнанные в стек регистры способны затереть важные данные. (Кстати, в программу можно встроить защиту от нажатия кнопки NMI — любой кнопки SNAPSHOT, если постоянно опрашивать частоту процессора.)

В дисковых системах со встроенным ОЗУ этот метод работает проще, так как SNAP может сохранять регистры в этой своей памяти. То же самое касается и Multiface 128.

В остальных же случаях при нажатии кнопки Multiface под SP сохраняются PC (Program Counter, счетчик команд — адрес, на котором сейчас находится программа) и регистр AF. Но бездумно и повсеместно применять Multiface или снапшоты — большая ошибка.

Многие игры используют указатель стека для сохранения адреса возврата после команды CALL. Даже это еще полбеды. Проблемы начинаются тогда, когда программа использует SP для более хитрых вещей — например, для хранения переменных.

Пример: если под SP отведено всего 4 байта, потому что прямо под ним расположен код программы, в стек можно поместить лишь 2 адреса. Если в этот момент нажать кнопку Multiface, один из адресов будет затерт.

Другой пример: указатель стека задействован для чего-то нестандартного:

   LD SP, TABLE
   POP HL
   JP (HL)
   ...

Если нажать кнопку Multiface во время выполнения этой процедуры, таблица переходов (JP) повредится, и при возврате в игру программа начнет сбоить или попросту зависнет.

Еще один пример — использование SP для вывода графики:

   LD SP,GFX
   POP HL
   POP DE
   POP BC
   POP AF
   LD SP,20480
   PUSH AF
   PUSH DE
   ...

Здесь содержимое памяти под SP также будет перезаписано, и графика окажется испорченной. Этот прием встречается не так уж часто, но если он есть, графика будет безвозвратно уничтожена.

Все это лишь пара примеров, призванных показать проблемы с Multiface. В подобных ситуациях Multiface или Snapshot использовать нельзя. Я занимаюсь взломом уже 11 лет и повидал немало игр, которые вылетали сразу после загрузки. В качестве примера могу назвать «IRON LORD 128». Если применить Multiface в последней части, графика превратится в кашу. По сути, использовать Multiface или снятие снапшотов следует лишь для исследования какого-нибудь ЗАГРУЗЧИКА или ЗАЩИТЫ ОТ КОПИРОВАНИЯ — то есть строго ДО ТОГО, как вся игра развернется в памяти. Особенно если вы не уверены, есть ли у вашего Multiface (или что вы там используете) собственное ОЗУ, — вы никак не можете гарантировать целостность данных программы. Повторюсь: если дисковая система или хак-интерфейс имеет собственное ОЗУ, то с вероятностью 80% регистры сохраняются именно туда. Тогда проблем нет, и интерфейс можно задействовать для ковыряния в LOADER'ах и ЗАЩИТАХ. Интерфейс же без собственного ОЗУ лучше вообще не трогать.

Но как же тогда «крэкать» программы? Лучше всего использовать соответствующий софт (дизассемблеры, мониторы, работающие прямо в SCREEN$, то есть размещаемые в экранной памяти). Не существует настолько крутой защиты от копирования, которую нельзя было бы снять подходящей утилитой. Это золотое правило хакера. Multiface способен сильно помочь в обнаружении и анализе кода, с ним легко обойти, например, защиты «SPEEDLOCK» или «RAT FLASH». Но все то же самое можно сделать чисто программным путем, причем гораздо безопаснее, чем «железом». Multiface работает быстро, но не дает никакой гарантии сохранности данных (вспомните про 4 байта под SP, а у Betadisk, к примеру, сохраняются целых 24 регистра!). Из-за этого было испорчено огромное количество игр. Еще пример — «GRELL & FALLA 128». Кто-то сбросил ее снапшотом и затем перегнал в обычный файл. Когда игра попала ко мне, я заметил, что пропала музыка. Я полез внутрь и нашел ошибку, возникшую именно из-за снятия SNAPSHOT. Теперь всё работает как часы.

О себе: как я уже говорил, я крэкер. Лучшим крэкером в Чехии был MATAsoft, перенесший уйму игр на Betadisk и ленту. Он сделал около 200 релизов — все они были упакованы (PACK) и легко адаптировались под любую дисковую систему. В этом и заключается истинный смысл взлома и конверсий: дать возможность каждому пользователю легко перенести программу на свою дисковую систему (а их у Спектрума немало). Кроме того, упакованные программы быстрее грузятся и занимают меньше места на диске. Допустим, емкость пустой дискеты составляет 730 Кб. Обычная программа «весит» около 40960 байт (без картинки), а значит, на диск влезет примерно 17 штук. Если же программы упаковать, каждая займет около 25 Кб (зависит, конечно, от программы и метода сжатия), и на дискету поместится уже 29 игр. Согласитесь, есть разница: держать у себя полку из 50 дискет или из 150. Огромна эта разница и для 128k-программ. Многие игры под 128K весят порядка 110 Кб. После сжатия получается всего 50–60 Кб (в двух файлах), что колоссально влияет на скорость загрузки (особенно с кассеты). Попробуйте загрузить 60 Кб, а затем 110 Кб, и сравните, сколько времени вы сэкономите. Для примера возьмите любую адвентюру от LEVEL 9 (SNOWBALL или ADVENTURE QUEST) и попробуйте запаковать 128k-страницы. Иногда из 16384 байт получается всего 400! Разумеется, так жмется далеко не всё, но это наглядно показывает, чего можно достичь.

Пожалуй, пора закругляться. В любом случае, намного правильнее крэкать софт своими руками, чем полагаться на аппаратный интерфейс. Я знаю пользователей, которые ради быстрой переброски на диск тупо жмут кнопку SNAPSHOT, даже если программа уже кем-то сломана. Перенести уже готовый релиз проще простого: нужно лишь подправить бейсик-загрузчик (добавить дисковые команды), а остальное сделает любой копировщик. В грамотный крэк вкладывается куча труда. Пожалуйста, не портите чужую работу.

И не бойтесь браться за оригиналы и взламывать их самостоятельно. Вы делаете это для себя: учитесь видеть и понимать принципы защит. Эти знания помогут вам, а вы поможете другим людям, которым станет проще запускать софт. Правильный CRACK всегда требует больше времени, чем бездумный SNAP. Но со временем набиваешь руку, вырабатываешь систему, процесс идет быстрее и начинает приносить удовольствие.

Все написанное выше основано на моем личном опыте взлома, упаковки и конверсии программ. Для крэка я почти всегда использую только софт и добиваюсь успеха в 95% случаев. Кнопку NMI я нажимаю только тогда, когда совсем уж захожу в тупик, и исключительно ради анализа кода. За 11 лет я взломал около 200 программ; в частности, только за декабрь 1995 года я сделал около 50 конверсий.

— JAXON HOLLIS

---

К этому могу лишь добавить: наконец-то нашелся человек, чье мнение о крэках на все 100% совпадает с моим! В последний раз я пользовался MF для копирования еще в 87-м году и жалею об этом по сей день. К счастью, со временем мне удалось устранить часть тех косяков. Тот, кто делает сброс через Multiface, а потом слегка правит бейсик-лоадер — никакой не «крэкер»! Мне попадались такие «релизы», где авторы умудрялись даже увековечить свое имя в загрузчике. Они что, еще и гордятся этим?

То же самое касается снапшотов, перегнанных обратно на пленку. Верхняя треть экрана у них оказывается затерта и порой не восстанавливается, из-за чего игры выглядят убого. Возьмем, к примеру, стрелялку с 3D-графикой, где действие происходит в центре экрана. Верх и низ отданы под приборную панель. И вот приходит такой «крэкер» — назовем его условно «Бобби» — и снапит игру сразу после загрузки. Дальше ему плевать: игра ведь теперь на кассете в пригодном для копирования виде!

А до того, что верхняя часть экрана обезображена кусками кода загрузчика и мешает играть, Бобби дела нет. Размести он загрузчик всего на 2048 байт выше адреса 16384, игра после старта сама затерла бы его своей графикой, и никаких проблем бы не возникло. Когда ко мне попала эта игра, меня взбесило, что ее невозможно перенести на диск, да еще и эти полосы на экране... Я взял Art Studio, подправил титульную картинку, а код лоадера сдвинул на 2048 байт выше — к счастью, он был перемещаемым, так что труда это не составило. Затем я доломал ее так, чтобы она грузилась с любого дискового интерфейса. Сейчас я знаю, что в Польше ходит только эта кривая снапшот-версия, что говорит не в пользу тамошней крэк-сцены.

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

Сейчас я уже немного растерял сноровку и за сложные вещи не берусь, но готов поспорить: многие «топовые крэкеры» из-за банальной лени ушли недалеко от меня.

— L.C.D.

CRACKING WORKSHOP TEIL 4

В одном из писем меня спросили, как убрать пароли из игр, выходивших в SINCLAIR USER на кассетах-приложениях (Covertapes) в качестве так называемых Prize-games. Цель этих паролей заключалась лишь в том, чтобы заставить пользователя купить и следующий номер журнала, дабы узнать заветный код. SU больше выходить не будет, да и практика эта была откровенно свинской — главным образом потому, что иногда пароли в следующем номере попросту забывали напечатать. Очевидно, редакция SU больше заботилась о выкачивании денег, чем о читателях.

Для взлома я выбрал три игры: TWINZ (разновидность «Memory»), а также CAESEFIRE I и II (NIGHT RUN, действительно великолепная вещь!). Проблему муторного взлома загрузчика я легко обошел, так как, по моим предположениям, так называемые Reader Games обычно состоят из Бейсик-части и блока кода; память Бейсик-программы кодами MC не используется, ровно как и буфер принтера.

Порядок действий для всех трех программ был одинаков: я загружал SNAPOUT, затем саму программу, вводил пароль и ждал окончания декомпрессии игры. Как только появлялась титульная картинка, я нажимал кнопку сброса в Snapshot, а затем клавишу «e», в результате чего оказывался в Бейсике. Адрес очистки (Clear) может находиться прямо в Бейсике, а если нет, его можно узнать с помощью:

PRINT PEEK 23730+PEEK 23731*256

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

Тут у меня возник вопрос: каким же должен быть адрес запуска? В программе везде стояло лишь RANDOMIZE USR 16384, и это было отнюдь не ошибочное число: ключ к разгадке крылся в оригинальном загрузчике. Дело в том, что часть загрузчика копируется в экранную область. Этот блок, который копируется (начиная с адреса, указанного после LD HL!), необходимо просмотреть дисассемблером на предмет наличия команды JP (Jump) — адрес перехода и будет адресом запуска.

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

Был и еще один вопрос: где взять упомянутые упаковщики и скрин-компрессоры?
Ответ: в этом номере, как и в прошлом, есть список Freeware-софта — загляните туда!

На этом для Cracking Workshop #4 всё. Чтобы серия продолжалась, мне нужны ваши вопросы.

L.C.D.

MAUSTREIBER 2.0

Advanced Patience была первой игрой на Spectrum, которой можно было управлять мышью от Atari ST или Amiga. С тех пор у меня вышло уже четыре игры, предлагающих этот способ управления в качестве альтернативы привычным ранее методам. Область применения мыши не ограничивается одними лишь играми: благодаря ей можно значительно упростить управление в прикладных программах, однако до сих пор эти мышиные драйверы использовал только я. В одном из предыдущих номеров SPC Info я уже приводил листинг и описание одной из первых версий, но вот наконец готова вторая, улучшенная версия.

Вместо четырех требовавшихся ранее драйверов (мышь ST в Kempston-порт, мышь ST в Sinclair-порт, мышь Amiga в Kempston и мышь Amiga в Sinclair) объем кода удалось сократить: теперь есть только «Amiga/ST-мышь в Kempston» и «Amiga/ST-мышь в порт Sinclair Joystick». Кроме того, добавлена программа для управления курсором с помощью джойстика или клавиатуры.

Как обычно, порт джойстика должен выдавать +5 вольт на 7-м контакте (как интерфейс Kempston Plus, о котором я рассказывал в прошлом номере).

Все эти версии программ перед использованием необходимо скомпилировать, а перед запуском не забудьте занести через POKE максимальные координаты.

После вызова драйвера мыши вы можете перемещать по экрану курсор, состоящий из одного атрибутного знакоместа, до тех пор, пока не будет нажата кнопка «огонь». Из-за этого всё процессорное время уходит на расчет координат мыши, и выполнение основной программы продолжается только после нажатия кнопки. Впрочем, программы (которые вы найдете в рубрике «EXTRAS») можно модифицировать таким образом, чтобы по прошествии определенного времени они автоматически возвращались в основную программу, используя системную переменную FRAMES. Таким образом имитируются прерывания.

В режиме 128K ни одна из этих программ не работает! Они почему-то всегда включают второй экран; почему так происходит — не знаю, но, возможно, дело в компиляторе. Этому вопросу я непременно еще уделю внимание.

И еще: для компиляции используйте HiSoft Basic, поскольку USCHI не дружит с некоторыми Бейсик-функциями. Впрочем, при определенных условиях код можно переписать и под USCHI, однако в этом случае его длина ощутимо увеличится.

Если хотите посмотреть на скомпилированный драйвер мыши в действии — можете заценить игру ULTRA REFLECT из прошлого номера или PYRAMID PATIENCE из текущего. В обеих программах уже используется та же самая версия мышиного драйвера, которую я прилагаю к диску.

Что ж, теперь буду ждать первых мышиных программ, написанных кем-то, кроме меня.

Удачи и приятного времяпрепровождения!

L.C.D.