Признания взломщика дисков для Apple II: секреты 4am

Немного не в тему.

Всегда удивляло, еще 30 лет назад, это как делали защиту дисков. Я вот ключ записывал на 160-ю или 161-ю дорожку и всего делов.

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

https://idpixel.ru/news/2065-platformer … na-apple2/

Тут вопрос в том, насколько далеко её можно отложить?
До какого момента?

В ТОР (Текстовый Оконный Редактор), вторая ступень защиты всплывала на сохранении текста.
Набрал текст, а записать не смог.

Можно было бы отложить по времени (через 20 минут работы, например).
Но тогда можно работать 15 минут, перегрузиться и работать дальше.
Не суперудобно, но зависит от типа проги/стиля работы.

Самая занятная вторая ступень была в ONIX: там примерно на каждое 256е обращение к драйверу дисковода возвращалась ошибка.
На первый взгляд: решение отличное.
Но эта защита быстро обнаруживалась тем, что у нас диск с демками, которые много чего читают с диска. Соответственно, чуть раньше или чуть позже демка ломалась. Уже на этом было видно, что защита или ошибка присутствует. Дальше дело техники: раскопать код части, которая возвращает ошибку и обнаружить немного необычно устроенный счетчик.
Не помню, что именно там было необычного, может быть его инкремент был нулевым если защита не сработала или ещё какая-то особенность.
Или он считал вниз до нуля, а на единице ломал драйвер. Т.е. если начальное значение  0 - то всё работало, если другое число - то рано или поздно всё ломалось.

Игорь несколько раз просил написать статью для сайта по защитам агатовских прог,
но я так и не придумал, как её лучше сделать. Напишешь много - будет скучно и долго  - получиться справочник, а коротко описать можно одной фразой: игры с форматом записи на дискету.

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

Итак, защиты на агате были четырёх типов:

0) Стандартный формат записи, в котором прога читала обычные сектора, но искала там что-то особенное: определённый размер какого-то файла. Где-то одна такая наивная прога попадалась.

1) Стандартный формат записи, дополненный какими-то особенностями или данными.

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

Метку тома типичный копировщик не копирует, а форматтер должен записывать её везде одинаковой.
Как правило, авторы защит делали одно и то же: либо метка тома менялась для каких-то треков,
либо была равна номеру сектора.

Дальше шли варианты от дописывания нескольких байт за эпилогами полей, до создания новых служебных полей или даже 22-го сектора. Да, он вполне влазил.

Нередко применялся метод привязки определённого сектора к сигналу индекса дисковода.
КПОН это дело любил, но и не только он.

Преимущества таких защит: вы вроде как успешно скопировали диск, но, уже приехав домой,  обнаружили, что диск не работает.

Однажды ("Фонограф") встретился вариант со специально нечитающимся сектором. Прога просто проверяла стандартным обращением к драйверу дисковода, что сектор 0/20 не читается.

ROM-драйвер дисководов не анализировал эпилоги полей. А нормальные драйвера их должны анализировать. Это тоже использовалось защитами. Загрузчик сектор без эпилога читает, а типичный копировщик говорит об ошибке чтения.

Отдельно была тема ("Бейсик Серкова" ?) про дубли секторов. Идея такая: есть два сектора с одинаковыми номерами. ROM-загрузчик читает первый по порядку сектор, у него как раз эпилог отсутствует, а второй сектор - отвлекающий: у него формат в порядке, поэтому если копировщик копирует диск, то он первый сектор пропустит, а схавает второй. А там просто надпись "Привет пиратам".

Ещё однажды ("MouseGraph") встретилась защита, которая делал две вещи:
a) Путала местами сектора (т.е. адресные поля не соответствовали порядку чтения секторов). Никакой таблицы правильного порядка в коде не было, код просто читал все встретившиеся сектора подряд, не анализируя их номеров. Секрет был в том, что на оригинальном диске они шли в нужном порядке, но стандартный копировщик на копии бы расставил их в порядке номеров - т.е. перепутал.
b) Там же был сектор с синхросбоем. Стандартный копировщик бы сказал, что тут ошибка чтения, но оригинальный загрузчик флаг синхросбоя пропускал и знал, что данные там верны.

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

3) Собственный формат записи.
Например, давайте сделаем один сектор размером во всю всю дорожку, прикрутим ему специальные пролог и эпилог и забъём кучей данных. А чтобы было сложнее читать, закинем туда блоки по 256 байт, чередуя с типа как бы GAP-полями. GAP состоит из байт-счётчика и мусора. При чтении пропускаем столько байт, сколько указывает счётчик и читаем блок из следующих 256 байт.

Игротеки этим баловались, например.

4) Способ вне нумерации: запись чего нибудь за 35 или 160ю дорожку. Очень редкий способ.
Возможно потому, что софт читался от начала диска и головка, заехавшая в центр диска, была бы слишком демаскирующей.

==

Надо сказать, что, как минимум, в двух случаях (JukeDOS и четырёхтомная модификация dos33) использовали игры с п1 и п3 для своего удобства или исходя из взглядов авторов на жизнь,
а не с целью защиты.

==

Иногда при анализе защиты складывалось впечатление, что авторы пытаются усложнить жизнь тем, кто будет анализировать их формат записи. Но они ошибались, потому что практически всегда вёлся анализ кода, читающего диск и распознающего ключи защиты, а не формата записи.

==

Воздействие защиты на прогу:
Самое простое и часто употребляемое: прога искала какой-то признак защищённого диска.
Если его нет - это считалось пираткой.

В промежутке был способ, при котором секретка содержала ключ шифрования (сборник Пушер&Клондайк, например). В mousegraph тоже было нечто подобное. Обе проги Р. Бадера.

Но особо талантливые защитники (в Onix, например) делали по другому: они формировали заранее ошибочный загрузочный код какого-то участка проги, а потом, из секретки, считывали правильную версию, если она присутствовала на диске.

==

И отдельно надо сказать о обфускации кода (защите от изучения).

0) Процентов 70-80 защит его не имели.

1) Несколько прог имели пару уровней защиты, т.е. нужно было продраться через кучу кода, прежде чем находился второй уровень.

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

2) Код в отдельном месте дополнялся недокументированными командами.
Никакой полезной логики этот код, обычно, не имел, секрет был именно
в том, с какого момента начинается валидный код.
А для этого нужно было как-то разобраться в шагах ЦП.
FantaVision, перенесённая на агат, на 840ку, так была защищена.
И ещё где-то такое было.
В этой же защите как раз применялась методика, оценивающая размер трека (кажется, 6-го).

3) Хардкор отмечался у Бадера (шифрованное тело проги, ключ читался из секретки).

4) Лидер хитпарада: группа Цикозы со Спрайт-ОС. Там несложная защита по формату 0 и 1-й дорог (вроде как контрольная сумма секторов считалась нестандартно), но обфускация кода была суровой: часть кода просто копировалась на стек и исполнялась оттуда. Естесно, всё было расчитано так, чтобы по УПР-СБР или какой-либо другой остановке сисмон начинал использовать для себя ту же область стека.

Встречались защиты, при срабатывании которых часть кода обнулялась в памяти, но это, конечно, никак не мешало его изучать прямо на диске. Уж лучше бы мусором закидывали или шифровали как нибудь по дурацки.

--

Отдельно вспоминается какой-то бейсиковсий квест, который защиты от копирования вроде бы не имел, но обфускация была безумной: цепочки chain-прог, ассемблерные вставки, формирование ассемблерного кода по частям из разных прог, случайно разбросанные по коду poke,
чтение каких-то ячеек из региона дос, вроде бы чтение некоего свободного сектора, в котором лежала какая-то информация....

Разработчики оторвались по полной, но практического смысла почти никакого.

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

--

Некоторую защиту имели АОС от Логосъ: у них бейсик проги либо имели простую блокировку от просмотра (нулевой байт вместо строки, но этот байт менялся в первых же строках программы).
(или мне это приснилось?)

Второй их вариант: это загрузка B- файлов, фактически, содержащих A- проги.
Т.е. делаешь BLOAD - ничего нет. А если BRUN, то в первых же командах прога патчит себя и передаёт управление на RUN бейсика. Возможно, она блокировала при этом УПР-СБР и УПР-C.

--

Отдельные граждане защищали свои Игротеки (из уникального там была только несложная запускалка игр, написанная на бейсике) тем, что патчили бейсик и команду LIST заменяли на что нибудь вроде HOQT.

==

Вредоносные действия защит:
практически не встречались. Как максимум, где-то был вариант, что по кругу быстро переключались видеорежимы. Может быть кто-то расчитывал спалить монитор или просто изобразить зависшую от бага прогу.

Крайне редко защиты говорили явно о пиратстве. Чаще вешались или уходили в перезагрузку.