Комментарии 54
Помню самый сложный был завернут как матрешка, сам в себя раз 10, и раскодировался по-этапно, причем кодирование было с применением шагового регистра (не помню уж, вроде меняется с каждой инструкцией), вот с ним пришлось повозиться )
Опять таки, потому что вместо дизассемблера была бумажная тетрадка со списком команд и цикл с «print peek x» на бейсике
А защита загрузчика, при наличии magic button — бессмысленна, и присутствовала в основном на оригинальных зарубежных кассетах, которые к нам доходили редко. У нас чаще были уже перехаканые версии, от того же Билла Гилберта и других.
Опять же, у вас около 42 кб на весь код. Тратить на защиту кучу кода бессмысленно, и опять же при наличии приличного магнитофона, кассета копируется просто напрямую,
физическим копированием.
По сегодняшним меркам, так защиты там не было вообще.
У меня была одна единственная бабина, переписанная напрямую на довольно приличном оборудовании, так с неё хорошо если треть игр загружалась. Но её так записывали не потому что какие-то защиты, просто человеку было лень возиться.
Кнопка меджик паганила многие игры. Еще ей подгрузку в лоб не скинешь.
Видимо, вы с фирменными играми не сталкивались. Но можете посмотреть в эмуляторе. Теперь, представье, как магнитофоном 80-х скопировать ускоренную запись и всякие приколы типа speedlock ))
Вообще этот регистр задумывался для регенерации памяти, но так и не использовался по назначению.
Уже не помню деталей, но по сравнению с Родионовым, у Гилберта защита была просто цветочки.
Основную защиту он сам снимал, делал свой загрузчик, в котором просто оставлял свой копилефт. В то время было модно сделать что-нибудь стильненькое.
Опять же, то что вы показываете — не защита, а именно стильненький загрузчик, не самый сложный. Мне больше нравились реализации различных «счетчиков»
Счётчики (как в Эксолоне от Билла Гилберта) — это мой любимый стильный загрузчик в своё время.
Сделан был этот последний способ для того, чтобы можно было без особых усилий и вообще не имея программатора и УФ-лампы «перешить» ПЗУ. А необходимость была — ATOSSOFT выпускал свою версию ПЗУ с турбозагрузчиком, автоопределяющим скорость подачи данных с магнитофона и загружающего именно на этой скорости.
Версий ПЗУ было несколько и можно было купить обновленную версию у автора прям на рынке на кассете и загружать и использовать её.
Я лично был знаком с Андреем (ATOSSOFT) и он мне показывал свой отладчик — внешне чем то напоминавший STS. Расположен он был именно в такой ОЗУ (загружался) и там же находился переделанный TF-COPY, позволяющий копировать его защищенные версии программ.
Т.е. У него по сути была своя прошивка записанная в микросхему и ОЗУ подставляемое в окно ПЗУ по щелчку тумблера (вот тут чутка могу ошибаться — возможно переход по NMI был, но это не суть). Каким-то макаром и стек для работы отладчика был тоже в области ОЗУ.
Извините если запутал и много написал, но вроде всё правильно.
Собственно выгружал он именно из отладчика.
Один раз загрузив отладчик с копиром в подПЗУ можно было легко запускать как одно так и второе. Получалось что то типа теневого отладчика что то.
Имея 128К или выше, можно, вполне. Это просто отправить новое значение в порт ввода-вывода.
Щелкнуть страничкой и переставить указатель между передачей байтов — это 4-5 команд. Значит, счётчики крутящиеся на экране, успевали делать одновременно с загрузкой, ну а страницы расширенной памяти переключить — это намного быстрее. Были даже ленточные копировщики, которые принимали поток, сжимая на ходу, а потом и выгружали… Всё успевали.
Опять же, можно грузить начиная чуть раньше, наплевав на экранную заставку (-6912)
Опять же, конкретно Гилберт особо защиты не ставил.
Книга Ларченко и Родионова «ZX Spectrum «Для пользователей и программистов»» — это да, кладезь информации в доинтернетую и доэмуляторную эпоху.
Была родионовская Elite, которая грузиласть с самого начала экрана и до упора
Потому что стэк можно было просто overwrite загрузкой =)
А звуки загрузки — ДА! Это просто нечто было. Я этот звук загрузки ELITE от Родионова ни с чем не перепутал бы. Он ВООБЩЕ не похож на загрузку других программ.
И ещё — это именно та версия игры, в которой если после загрузки в ответ на Load New Commander (Y/N) ответить Y, нажать 2. Save commander и введя любое имя выгрузить состояние, то после этого попадал в 47 галактику с рейтингом ELITE, немеряным баблом и товарами.
Ясно что глюк был — не инициализировал данные о пилоте, а выгружал по сути мусор, но это было просто мегакруто тогда!
Несмотря на то, что многие защиты по современным меркам кажутся примитивными, всё равно нахлынул какой-то внутренний зуд, хочется разобраться, как оно раньше работало. А из моделей спектрумов, ничего более крутого чем относительно стандарный 128К c AY и дисководом я до сих пор в глаза не видел.
До меня всё доходило на кассетах, а о дисководе можно было только мечтать.
Гениально кстати придумано. Вывод — копирование с помощью McDonald (медленно) или SOFT-COPY (намного быстрее).
А вообще маленький форматер написал, который эту самую дорожку форматировал и записывал злосчастные байты, а потом просто копирование без форматирования и всё норм.
1. В ней использовался модифицированный Microprotector, отличающийся отключенной индикацией. Помимо шифрованных basic-загрузчиков, как и в оригинальных реализациях, его наличие проверялсь рандомно при обращении к диску, когда производилось внутриигровое сохранение/загрузка. Впрочем эта защита снималась так же легко, как и оригинальный microprotector. В нём ключи (константы) шифрования были размещены на межсекторном пространтстве в конце образа нулевого трека. Обработка констант проводилась через команду контроллера чтение образа трека. Уязвимость состояла в том, что последний сектор в треке не был использован, поэтому было достаточно бережно перенести кусочек образа с константами в этот сектор, после этого дискета свободно копировалась. Процедура поиска констант начинала поиск заранее, поэтому информация с последнего сектора тоже успешно принималась.
2. Внутриигровые патчи в виде бесконечных жизней было реализовать сложнее — в игре было три образа кода, записанные на дискете, которые рандомно меняли друг друга, опять же при отгрузках состояний. Если патчить только первый образ, то он рано или поздно замещался оригинальной копией, со всеми вытекающими. В игре блокировался сюжет, и она становилась «кирпичом». Видимо, как раз такая багованная версия описана ниже kxl.
В том микропротекторе, что мне попадался, был именно один большой сектор. Это переполняло буфер TR-DOS и позволяло перетирать системные переменные, а точнее адрес возврата… Вот где были искомые байтики — я уже не помню…
Там дело не в том что код встроен в бейсик — кодовые блоки в подавляющем большинстве программ шли после оператора REM (данные после которого просто игнорировались интерпретатором Бейсика), а в неправильном указании длины бейсик-строки (первые два байта — номер, а вот вторые — именно длина) если поставить обчень большую длину — вот такой эффект со смещением и будет появляться при наборе MERGE "".
Я обходил так — заголовок (17 байт) грузил от одной ОЧЕНЬ длинной программы, а само тело — от взламываемой программы.
[…] кодовые блоки в подавляющем большинстве программ шли после оператора REM (данные после которого просто игнорировались интерпретатором Бейсика) […]Да. Именно так я и буду делать загрузчик для TR-DOS в следующих частях.
В случае с Pac-Man мне показалось, что кодовые блоки идут сразу за окончанием строки безо всякого соблюдения формата хранения бейсик-программы в памяти (2 байта номера, 2 байта длины, данные строки). Хотя, видимо, эффект тот же самый (байты, которые интерпретируются как длина содержат какое-то большое значение).
Видимо, «синтаксис» — не самая удачная формулировка.
Я обходил так — заголовок (17 байт) грузил от одной ОЧЕНЬ длинной программы, а само тело — от взламываемой программы.По идее, можно было загрузить заголовок от любого кодового файла, у которого длина больше длины бейсик-программы, и вменяемый адрес загрузки. А если с дисководом, то вроде бы можно было загрузить тело без заголовка в копировщик и сохранить его на диск как кодовый файл с тем же результатом.
По идее, можно было загрузить заголовок от любого кодового файла, у которого длина больше длины бейсик-программы, и вменяемый адрес загрузки.
Но при этом получали куда-то-там загруженные данные, которые являлись по сути бесик-программой (как минимум один оператор там ДОЛЖЕН был быть — иначе бы не запустилась кодовая программа).
А если заголовок именно от бейсик-программы, то и грузились данные именно в положенное место, после чего их можно было (хоть и не всегда) просмотреть в обычном бейсике, а не запускать какие то доппрограммы для просмотра листинга.
В случае с Pac-Man мне показалось, что кодовые блоки идут сразу за окончанием строки безо всякого соблюдения формата хранения бейсик-программы в памяти
Если честно — не смотрел сам загрузчик и как хранятся там данные, но про оператор REM я ж сказал что в подавляющем большинстве. Естественно были и другие варианты хранения кода — можно было, например переменной A$ присвоить значение в 50 пробелов, сохранить загрузчик, а потом в данные этой переменной всандалить код каким-нибудь отладчиком, походу подкорректировав адрес старта.
Да. Именно так я и буду делать загрузчик для TR-DOS в следующих частях.
В некоторых случаях, для ускорения делания дисковых версий, делался минимальный загрузчик со встроенным в REM кодом, который загружал данные размером в 1 сектор в, допустим, #5d3b (начало бейсика с инициализированным TR-DOS). Это очень упрощало написание загрузчика и встраивание его в REM (раньше не особо у многих был доступ к ПК для написания загрузчиков на языках более высокого уровня с последующей компиляцией и получения на выходе готового TRD образа).
Получается так — готовишь данные (допустим картинка и код) и пишешь загрузчик, который будет эти данные грузить в указанные места и указанной длины, откомпилированный, допустим, в адрес #5d3b. Потом на дискете выстраиваем файлы в таком порядке — универсальный Бейсик-загрузчик, кодовый загрузчик, картинка (если есть), код игры/программы и всё это «склеиваем» в моноблок. другие игра/программа — заменил кодовый загрузчик и всё — выстроил, склеил. Особо актуально если грузишь блоки в страницы и текстовочку на экран хочется вывести, а «впиливая» всё после REM можно не попасть в длину сектора одного. А так хоть и теряем один сектор, но полчаем удобство в сборке.
В регистр AX и DX скидываешь куда грузить и сколько.
Например загрузка экрана (могу уже в цифрах запутаться, но как-то так):
62
255
0
64 (это вроде как в AX загружаем 16384)
17
0
27 (в DX длину экрана с цветом)
55 (обнуляем флаги)
205 call (вызываем загрузку)
86
5
201 return (возвращаемся в бейсик)
вводишь через poke подпрограмму куда-нить в свободное место и randomize usr адрес
62 255 ld a,ff
221 33 00 64 ld ix, 16384
17 00 27 ld de, 6912
55 scf
205 86 5 call 1366
201 ret
Вы, конечно, можете делать из этого какие-то ретро статейки, но не вижу ничего такого выдающегося в скидывании состояния программы в лоб. Говорю вам это, как человек, которые адаптировал приличное количество игр для TR-DOS с cracktro, запаковкой (rle, rip, dcpack, dataglue), исправлением фирменных багов.
Допустим, в современных условиях это выглядит забавно, но в таком случае не вводите людей в заблуждение. Во-первых, вы описываете довольно неудобный способ для дизасемблирования. В различных speedlock и alcatraz есть XOR'ка и она там не одна. Удобней все это протрассить в том же UnrealSpeccy. И, как бы вам это сказать... скинуть просто кодовый блок без запаковки во всем времена на демосцене считалось ламерством (слово такое уже ныне архаичное) :)))
Нет, сейчас, конечно, в эмуляторе это сделать просто, но зачем? Разумеется и в 90-00 тоже для себя адаптировали и тупо так же "в лоб", или как бы это сказать, "в стол". Но, видите ли, aдаптация зачестую это процесс, самовырежение и поиск исторических моментов: крэктро, приветы, программные ноу-хау... это сцена и целая субкультура в конце концов! Я вас удивлю: некоторые интузиасты продолжают это делать красиво и по сей день, например: раз и два.
И, если уж браться за подобные раскопки, то третьей четвертой-частью цикла статей можно осветить более продвинутые варианты, хотя бы историческую справку, благо пока еще есть кого спросить на посвященных ресурах ))
Адаптация программ для ZX Spectrum к TR-DOS современными средствами. Часть 1