1 Отредактировано garnizon (01-08-2018 16:44)

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

dk_spb поделился интересной ссылочкой:

https://habr.com/post/417615/

2 Отредактировано Voldemar0 (01-08-2018 17:33)

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

Перевод местами так себе. Я подзавис на фразе "Она использовала защищённый диск против его самого, считывая каждый сектор с кодом самого диска (RWTS)". Залез в английскую версию - вроде там также, да не так: "...reading every sector of the disk with the disk’s own code (“RWTS”)..."  - литературно говоря, что -то вроде: "читает каждый сектор диска с собственным кодом [принадлжещаем диску] (RWTS)".

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

Интересно также описание "E7 bitstream". На Агате с таким не сталкивались, очевидно, потому, что на 140ку (да и вообще семёрку) никто особо защит не вешал (вроде только редактор Wordmaster немного был защищён). А на 9ке были уже 840ки со своими ограничениями. Да и мало кто досконально знал логику работы 840ки (хотя, сдаётся мне, можно там такой пасьянс разложить). А если и знал, то так изощряться с ней не было смысла - на агате мощных хакеров не было, а кто если и был - то, скорее, зарабатывал разработкой собственных прог. Я думаю, на тот момент так было гораздо выгоднее.

По сути, мы идём тем же путём. Разница лишь в том, что на Агате/840ке не было такого разнообразия защит и не было столь многократного повторения защит в одной проге (Ну два уровня у Бадера можно найти, наверное и у ещё некоторых авторов... но редко это. Обычно одним обходились). Соответственно, многие виды защит нейтрализуются единственным алгоритомом: прямой конвертацией нескольких треков из EIM напрямую в AIM - и это снимает процентов 40 защит средней сложности. Ещё 50% защит - низкой сложности - снимается ещё проще: повторением порядка секторов, привязки их к индексу, сохранением номеров томов и сохранением 1-2 GAP-байт, следующих за эпилогами полей. Это можно проделать даже при непрямой конвертации образов: EIM -> DSK+файлы_спутники -> AIM. И только оставшиеся процентов 10 уже требуют немного подумать, поэмулировать и поправить несколько байт в AIM вручную.

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

3

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

Voldemar0 пишет:

Соответственно, многие виды защит нейтрализуются единственным алгоритомом: прямой конвертацией нескольких треков из EIM напрямую в AIM - и это снимает процентов 40 защит средней сложности. Ещё 50% защит - низкой сложности - снимается ещё проще: повторением порядка секторов, привязки их к индексу, сохранением номеров томов и сохранением 1-2 GAP-байт, следующих за эпилогами полей. Это можно проделать даже при непрямой конвертации образов: EIM -> DSK+файлы_спутники -> AIM. И только оставшиеся процентов 10 уже требуют немного подумать, поэмулировать и поправить несколько байт в AIM вручную.

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


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

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

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

4 Отредактировано garnizon (11-12-2018 02:16)

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

А вот кстати про 4AMCrack.

Он как-то по правильному вскрывал игру "Alice in wonderland". Даже на диске оставил текстовый файлик с конспектом действий.
Я вытащил этот текстовик - в аттаче. Может кто-то хоть примерно сказать в чём там заключалось дело? Модификация ДОС?

Post's attachments

Attachment icon A 4AM CRACK 301.txt 9 kb, 256 downloads since 2018-12-10 

5

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

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

6 Отредактировано vvhitevvizard (28-08-2021 03:33)

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

Voldemar0 пишет:

Разница лишь в том, что на Агате/840ке не было такого разнообразия защит и не было столь многократного повторения защит в одной проге (Ну два уровня у Бадера можно найти, наверное и у ещё некоторых авторов... но редко это. Обычно одним обходились).

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

7 Отредактировано Voldemar0 (28-08-2021 09:29)

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

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

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

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

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

8

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

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

9 Отредактировано Voldemar0 (28-08-2021 11:16)

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

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

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

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

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.

==

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

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

10 Отредактировано vvhitevvizard (28-08-2021 13:52)

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

Вспомнил, что на PC сразу после Агатства втречал высший пилотаж. Защищающая себя программа использовала собственный интерпретатор (от скрипта до полноценного языка программирования). Взломать который было на порядок сложнее, чем самомодифицирующийся код, дешифрации, длинные обфускации и прочее прочее что взламывалось точкой останова в определенном месте и сдампливанием промежуточного результата (и повторялось при необходимости). Вариация - собственная виртуальная машина. А если такие "интерпретируемые" части были вложенными? С отложенными проверками... Для взломщика начинался адовый ад.

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

Тут есть нюанс - у Агата стек переключается одной инструкцией при желании (изменение привязки нулевого сегмента к нулевому банку). =) Я в своей проге (не с целью защиты но для оптимизации) использую переключаемые нулевые страницы, выполняя динамически модифицируемый код прямо в нулевой странице - побочным эффектом стало переключение стеков.
------------------------
Про официально купленный MouseGraf вспоминаю интересный факт - редактором пользовался часто, дискета изнашивалась быстро, резервную копию не создать. Через какое-то время мне надоело ездить в ЮСН для ее восстановления (перезаписи). И за пару дней я познакомился с применяемой методикой синхросбоев и научился копировать эту дискету самостоятельно...