Самая хитрая защита флоппи-дисков

Original author: scarybeastsecurity
  • Translation

Введение


Недавно я затеял одиссею по изучению защит гибких дисков

В своих предыдущих постах я уже рассказывал (напрямую или косвенно) о примерах интересных схем защиты гибких дисков:

  • Слабые биты. [ссылка: Weak bits floppy disc protection: an alternate origins story on 8-bit]. Защита «слабыми битами» реализуется так: часть поверхности диска оставляется пустой изменений потоков намагниченности. В условиях отсутствия сигнала привод гибких дисков повышает коэффициент усиления своего усилителя и видит шум, проявляющий себя как недетерминированные цифровые сигналы с диска.
  • Нечёткие биты. [ссылка: Technical Documentation — Dungeon Master and Chaos Strikes Back — Detailed analysis of Atari ST Floppy Disks]. При защите «нечёткими битами» изменения потоков намагниченности записываются с интервалами, отличающимися по времени от спецификации (например, MFM). Благодаря использованию интервалов прямо посередине пары ожидаемых значений (например, 5 мкс вместо ожидаемых 4 мкс или 6 мкс) можно заставить контроллер дисков возвращать недетерминированные цифровые сигналы.
  • Длинные/короткие дорожки. [ссылка: Turning a £400 BBC Micro (1981) into a $40,000 disc writer (1987)] [см. раздел «Capabilities Unlocked»] [Перевод статьи на Хабре]. При защите длинными дорожками запись переходов намагниченности выполняется чуть быстрее, чем обычно. Это может быть целая дорожка или только её часть. В любом случае, будет казаться, что дорожка содержит больше байтов, чем обычно должно быть в дорожке. Такая защита работает, потому что у контроллера гибких дисков обычно есть широкий допуск на битрейт, чтобы учитывать тот факт, что дисковые приводы естественным образом крутятся на разных скоростях.

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

Western… что?


Не так легко найти компанию «Western Security, Ltd.», связанную с компьютером BBC Micro. Как же понять, что она существует? Во-первых, при разработке моего эмулятора beebjit [ссылка] я сделал множество ошибок и получил кучу багов. Разбираясь с точной эмуляцией гибких дисков, чтобы иметь возможность загрузки оригинальных защищённых образов дисков, я наткнулся на следующее:


Игра Jolly Jack Tar компании Sherston Software

Разумеется, автор оригинала не мог учесть такой ситуации. Дело или в неисправном диске (это не так), или в незаконной копии (не совсем правда)… или в эмуляторе с багами. Вот ещё один экран ошибки. Вероятно, это более ранняя версия схемы защиты? В сообщении написано «disk» вместо «disc» и даже не учитывается то, что диск может быть повреждён:


Игра Phantom Combat компании Doctor Soft

(Я рискую сильно отклониться от темы, но вот ещё один скриншот. Он не связан с Western Security Ltd., но на нём тоже представлен специальный экран, отображаемый при сбое защищённого загрузчика диска. Этот случай интересен тем, что при обычной работе пользователь не увидит такого замечательного изображения!)


Такое сообщение показывает Disc Duplicator 3, если считает, что создаётся незаконная копия

Во-вторых, мы знаем название Western по маркерам дубликаторов дисков. Маркер дубликаторов дисков — это специальная дорожка, написанная одним из коммерческого ПО для дублирования дисков. Обычно это одна дорожка после конца обычного диска, например, 41-я или 81-я дорожка диска. Несмотря на то, что она находится «вне пределов» диска, большинство приводов дисков ищет хотя бы одну дорожку за его границами. На этой дорожке обычно можно найти один заголовок сектора и тело сектора с ошибкой CRC. Это необычная конструкция, которая выявляется, например, когда моя программа discbeast [ссылка] изучает диск Jolly Jack Tar:


Просмотр Jolly Jack Tar в Discbeast

В маркере дубликатора есть дата и одна-две текстовые строки. В случае Jolly Jack Tar это:

86 07 01 (1986, July 1st)
523-037E WESTERN NM,10/256 PROT DUP 5"-48/40 1S SD SS
32173-2Aw

Существует и ещё одна менее распространённая строка маркер дубликатора, связанная с Western security, например, в Tens and Units компании Sherston Software. Похоже, это более ранняя версия-прототип:

85 10 31 (1985, October 31st)
523-037C BBC NM,10/256 WESTERN SEC. PROTO1 DUP 5"-48/40 1
70422-00w

Вкратце повторим основы защиты дисков


Прежде чем начать разбираться в работе защиты Western Security, давайте повторим основы защиты дисков. Существуют различные специфические нюансы, но в целом принцип довольно прост:

  • Диск легко считать, но сложно записать.

Диск должен относительно легко считываться. Если диск не может считываться стандартными контроллерами дисков, то вы не сможете продать диск, потому что покупатели не смогут его загрузить!

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

Защита дисков BBC Micro не пошла по этому пути — первые диски, а также многие последующие диски были экзотичными, но их было не особо сложно создать при помощи стандартного контроллера дисков. Однако требовалась специальная программа. У компаний-производителей ПО, в отличие от пользователей, была их специальная программа мастеринга, поэтому в этом смысле диск было «сложно» записать. Но позже, когда появились стандартные программы копирования наподобие Disc Duplicator 3, диски внезапно оказалось копировать «легко», если у вас или у друга была продвинутая программа для копирования дисков.

Однако некоторые первопроходцы BBC Micro действительно записывали диски, которые «нельзя» записать при помощи стандартного контроллера дисков. Наиболее примечательные из них:

  • Схема со слабыми битами Саймона Хослера, ссылка есть выше. (И здесь: [ссылка].) [1]
  • Многие диски, например, The Sentinel компании Firebird, прятали данные между секторами. [2]

[1] Одна из основных задач контроллера дисков — запись точных поверхностей дисков, т.е. никогда не записывать слабые биты. Однако в современную эпоху я нашёл способ хитростью заставить контроллер Intel 8271 записывать слабые биты. Насколько я знаю, эта техника не была открыта и не использовалась в те времена.

[2] Я думаю, что при умном программировании данные между секторами можно записывать стандартными контроллерами дисков. Для этого потребуется выполнять запись на дорожку несколько раз и сбрасывать контроллер дисков в критические моменты времени. Однако я не встречал старых программ копирования дисков, пытавшихся копировать такие диски.

Анализ защищённого загрузчика Western Security Ltd.



В этой версии The Wizard's Revenge компании Sherston Software используется защита диска Western Security Ltd.

Вот скриншот из игры.


А вот, что делает с диском discbeast:


Здесь нет ничего особо необычного. Красный блок в конце обозначает дорожку с одним сектором, имеющим ошибку CRC. Это не часть защиты диска, а маркер дубликатора. Зелёным цветом обозначена стандартная схема секторов, в которой нет ничего особо экзотичного. Буквой «D» обозначено наличие удалённых секторов. Это защита диска, но она не экзотична и не сложна в копировании. Однако при загрузке диска в мой эмулятор beebjit при помощи контроллера гибких дисков Western Digital WD1770 и -log disc:commands мы получаем нечто весьма необычное:

info:disc:1770: command $E4 tr 1 sr 3 dr 1 cr $29 ptrk 1 hpos 1884

Команда $E4 обозначает «считать дорожку». Она не используется при обычном выполнении загрузки диска, да и в любом другом известном защищённом загрузчике.

Настало время немного разобраться в загрузчике, чтобы понять, что происходит. Цель этого поста заключается не в подробном описании всех мельчайших деталей загрузчика. Как и многие защищённые загрузчики, он «зашифрован», а точнее обфусцирован. Деобфускация производится им самостоятельно при помощи множества слоёв самомодификации. На PC $0657 выполняется вызов диска для загрузки части загрузчика из удалённых секторов в дорожке 9. Подобное легко можно спутать с частью защиты, но это не так. Ниже, на PC $3CF7, есть цикл:

[ITRP] 3CF7: JSR $3D16
[ITRP] 3CFA: LDA $75
[ITRP] 3CFC: SEC
[ITRP] 3CFD: SBC $3F4E
[ITRP] 3D00: TAX
[ITRP] 3D01: LDA $86
[ITRP] 3D03: STA $3F71,X
[ITRP] 3D06: INC $75
[ITRP] 3D08: LDA $3F4F
[ITRP] 3D0B: CMP $75
[ITRP] 3D0D: BCS $3CF7

Я не ожидаю, что его назначение будет понятно из данного фрагмента (без всех подпроцедур), но здесь в цикле обходятся дорожки с 1 по 8 включительно. Каждая дорожка полностью считывается и длина дорожки сохраняется в таблице по адресу $3F71. Ниже, на PC $3CB6, эти длины сравниваются с таблицей, расположенной по адресу $3D9B. Эта проверка особенно интересна. Чтобы защита от копирования считалась выполненной, подсчитывается количество дорожек, длина которых находится в пределах ±1 от ожидаемой, и это количество должно быть равно 7 или 8. Мы сразу же видим, что эта защита не является точной технологией. И этого стоило ожидать: диски являются аналоговыми носителями, поэтому в начале и конце дорожки присутствует немного шума. При разных считываниях один и тот же диск на одном приводе и контроллере может демонстрировать незначительные вариации длин дорожек. Посмотрев на загрузку в beebjit, можно увидеть подсчитанные и ожидаемые длины. (0x4A == 3122 байта.)

Перехват с моего диска:

3F71: 4A 4D 4B 4A 4B 4D 4D 4A

Ожидания:

3D9B: 4A 4C 4B 4A 4B 4D 4C 4A

Как видите, мои считывания с диска почти в точности равны ожидаемым, за исключением дорожки 2, на которой насчитали 3125 байт вместо ожидаемых 3124. Эта разность находится в интервале погрешности ±1, поэтому проверку прошли все 8 дорожек (а требуется 7 или больше).

Объясню подробнее: защищённый загрузчик ожидает, что длина дорожек с 1 по 8 (в байтах закодированных частотной модуляцией) должна быть равна 3122, 3124, 3123, 3122, 3123, 3124, 3123, 3122. Это невероятный уровень точности и прецизионности записи для технологий 1985 года. Каждый байт занимает на вращающемся диске примерно 64 мкс, но для приводов дисков той эпохи часто указывали отклонение RPM (оборотов в минуту) «меньше ±1,5%». При 300 об/мин, ±1,5% — это ±3 мс на оборот! По моему опыту, приводы обладают гораздо большей точностью, но тем не менее! Как с этим справлялись технологии 1985 года?

Дополнительное примечание о контроллерах дисков WD1770 и Intel 8271. Мы сосредоточились на анализе защиты на контроллере WD1770. Этот диск также нормально загружается на контроллере Intel 8271. В нём используется совершенно другой путь выполнения кода, чтобы в данном случае вычислять длину дорожек косвенно. Это удалось сделать, потому что все байты-заполнители, записанные до конца дорожки, равны 0x00, а не обычному значению 0xFF. Используется «чтение с выходом за границы» последнего сектора дорожки, а длина дорожки определяется по смене считываемых значений с 0x00 на 0xFF.

Гениальный ход


И потом мы осознаём гениальность этой схемы. Что если они не записывали дорожки с чрезвычайной точностью, потому что таких технологий ещё не существовало? Что если они просто записывали дорожку любым способом, а затем изучали результат? Думаю, создатели защиты делали следующее:

  • Форматировали диск. (И всё — достаточно обычного форматирования диска, и вы получите ужасно сложно защищённый диск.)
  • Считывали длины дорожек 1-8 диска, которые только что были записаны.
  • Для каждого диска генерировались, обфусцировались и записывались в загрузчик на дорожке 9 соответствующие таблицы ожидаемых длин дорожек.

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

  • Диск должно быть легко считывать, но сложно записывать.

Однако защиту Western Security Ltd. довольно легко записать, достаточно отформатировать диск. Поэтому, вероятно, мы должны сказать:

  • Диск должно быть легко считывать, но сложно воссоздать.

Защиту Western Security легко записать, легко считать, но очень сложно скопировать. Одно из преимуществ такой защиты заключается в том, что для экономии можно записывать её на обычном домашнем компьютере. Тем не менее, многие диски, с которыми я сталкивался, имели маркеры дубликаторов, обычно оставляемые дорогими машинами дублирования дисков.

Чем мы можем подтвердить свою теорию? Например, найти второй диск с той же игрой The Wizard's Revenge и посмотреть, отличаются ли они. Я нашёл диск, и да, они отличаются. Мой первый диск, который рассматривался выше:

Track 0 sectors 10 length 3124 fixups 1 CRC32 2E6B86E9
Track 1 sectors 10 length 3122 fixups 0 CRC32 37E30EC8
Track 2 sectors 10 length 3125 fixups 1 CRC32 F7BDE89B
Track 3 sectors 10 length 3123 fixups 0 CRC32 BB1E32C3
Track 4 sectors 10 length 3122 fixups 1 CRC32 2EC84AF1
Track 5 sectors 10 length 3123 fixups 0 CRC32 58FD732B
Track 6 sectors 10 length 3125 fixups 0 CRC32 43416F5A
Track 7 sectors 10 length 3125 fixups 1 CRC32 B3D8AB10
Track 8 sectors 10 length 3122 fixups 1 CRC32 8D02AC32
Track 9 sectors 10 length 3125 fixups 1 CRC32 75B1F57B
Track 10 sectors 10 length 3123 fixups 1 CRC32 D2B0A1EF
[...]

Другой диск:

Track 0 sectors 10 length 3126 fixups 1 CRC32 2E6B86E9
Track 1 sectors 10 length 3129 fixups 1 CRC32 37E30EC8
Track 2 sectors 10 length 3127 fixups 1 CRC32 F7BDE89B
Track 3 sectors 10 length 3127 fixups 1 CRC32 BB1E32C3
Track 4 sectors 10 length 3127 fixups 1 CRC32 2EC84AF1
Track 5 sectors 10 length 3129 fixups 1 CRC32 58FD732B
Track 6 sectors 10 length 3129 fixups 1 CRC32 43416F5A
Track 7 sectors 10 length 3128 fixups 1 CRC32 B3D8AB10
Track 8 sectors 10 length 3128 fixups 1 CRC32 8D02AC32
Track 9 sectors 10 length 3127 fixups 1 CRC32 1F5ABD44
Track 10 sectors 10 length 3128 fixups 0 CRC32 D2B0A1EF
[...]

Как мы видим, данные секторов (указанные в CRC32) дисков одинаковы, за исключением дорожки 9, на которой хранится таблица ожидаемых длин дорожек. А длины самих дорожек отличаются. В обоих случаях присутствуют колебания длин дорожек, а в случае второго диска дорожки чуть длиннее. Это значит, что привод, форматировавший диск, работал с чуть меньшим RPM, позволяя записать больше байтов за один оборот.

Есть и второй способ подтверждения нашей теории. Я спросил у Саймона Хослера, написавшего в 1980-х много игр для Sherston Software, помнит ли он какие-нибудь подробности. Он рассказал следующее:

«Western Security создавал не я, но думаю, она работала так… Она работала потому, что каждый привод дисков работает на своей скорости. Поэтому когда привод создаёт дорожку на диске, то после добавления всех заголовков, секторов и прочего, остаётся немного незаполненного пространства, куда он записывает немного „заполняющих“ битов, которые ничего не делают. Количество заполняющих битов зависит от точной скорости форматирующего привода. Поэтому при копировании оно будет отличаться. Помню, эта система доставляла много проблем, потому что приводы дисков постоянно менялись (?). [...] систему называли „Fingerprinting“»

Остаётся загадкой, как с созданием таких дисков мог справляться коммерческий дубликатор. Я нашёл отсылки к скрипту «Freeform» [ссылка], использовавшемуся совместно с дубликаторами Trace. Мне не удалось найти руководства по этому скриптовому языку. После деобфускации в памяти загрузчика остаются какие-то странные фрагменты, возможно они как-то с ним связаны?

3F80: 54 70 00 41 44 44 20 20 20 20 20 72 00 4D 4F 56 Tp.ADD r.MOV
3F90: 45 54 4F 20 20 74 00 55 4E 49 54 20 20 20 20 75 ETO t.UNIT u
3FA0: 00 54 52 41 43 4B 20 20 20 76 00 53 45 43 54 4F .TRACK v.SECTO
3FB0: 52 20 20 77 00 54 4F 50 54 52 41 43 4B 78 00 55 R w.TOPTRACKx.U

Воссоздание защищённых дисков в стиле Western Security


У меня завалялась пара сильно отличающихся приводов дисков, поэтому я решил их попробовать. Я отформатировал диск в каждом приводе, затем посмотрел на длины дорожек (в байтах), считанных контроллером дисков WD1772 в реальном компьютере BBC Micro model B.


Первый претендент: мой привод Chinon F-051MD. Это более старый привод, всего с 40 дорожками и только односторонний. Механизм дверки с защёлкиванием позже вышел из моды (может, был менее надёжным?). Ещё один способ его датировки — крупный основной чип в стиле DIP. Это NEC D8048, который был клоном Intel 8048! (В нём есть ROM, который мне когда-нибудь ещё предстоит извлечь!)


Второй претендент: не мой Mitsuibish MF504C, но довольно похожий. Гораздо более новый привод, с 80 дорожками и двухсторонний. Обратите внимание на более новые чипы, опрятную проводку и упрощённый механизм защёлкивания. Здесь этого не видно, но у него ещё и шаговый двигатель меньшего размера (следующее поколение?).

Длины дорожек с Chinon F-051MD:

[...]
Track 1 sectors 10 length 3137 fixups 1 CRC32 67F0950E
Track 2 sectors 10 length 3138 fixups 1 CRC32 67F0950E
Track 3 sectors 10 length 3138 fixups 1 CRC32 67F0950E
Track 4 sectors 10 length 3139 fixups 1 CRC32 67F0950E
Track 5 sectors 10 length 3138 fixups 1 CRC32 67F0950E
Track 6 sectors 10 length 3140 fixups 1 CRC32 67F0950E
Track 7 sectors 10 length 3140 fixups 1 CRC32 67F0950E
Track 8 sectors 10 length 3139 fixups 1 CRC32 67F0950E
Track 9 sectors 10 length 3140 fixups 1 CRC32 67F0950E
Track 10 sectors 10 length 3140 fixups 1 CRC32 67F0950E
[...]

Длины дорожек с Mitsubishi MF504C:

[...]
Track 1 sectors 10 length 3119 fixups 1 CRC32 67F0950E
Track 2 sectors 10 length 3119 fixups 1 CRC32 67F0950E
Track 3 sectors 10 length 3118 fixups 0 CRC32 67F0950E
Track 4 sectors 10 length 3119 fixups 1 CRC32 67F0950E
Track 5 sectors 10 length 3119 fixups 1 CRC32 67F0950E
Track 6 sectors 10 length 3119 fixups 1 CRC32 67F0950E
Track 7 sectors 10 length 3119 fixups 1 CRC32 67F0950E
Track 8 sectors 10 length 3119 fixups 1 CRC32 67F0950E
Track 9 sectors 10 length 3118 fixups 1 CRC32 67F0950E
Track 10 sectors 10 length 3119 fixups 1 CRC32 67F0950E
[...]

Эти два привода определённо имеют уникальные «отпечатки пальцев»! У более старого привода присутствует чуть больше вариативности/колебаний в длинах отдельных дорожек. На самом деле, похоже, что в последних секторах он может уместить больше байтов на дорожку — большинство последних дорожек имеет длину 3142. Кроме того, старый привод обычно может уместить 20 или чуть больше байтов на дорожку. Это означает, что он вращается чуть медленнее. Более новый привод работает как часы, с минимальными флуктуациями длин дорожек. Из-за этого он чуть меньше подходит для генерации уникальных для каждого диска «отпечатков пальцев», но копирование диска на домашнем компьютерном оборудовании всё равно будет сложным — в используемой машине должен быть установлен привод с точно такой же прецизионностью, и привод должен работать точно с такой же скоростью, что и при записи оригинального диска.

В последний раз взглянем на длины дорожек, на этот раз с диска игры Phantom Combat компании Doctor Soft. В этом диске используется защита Western Security Ltd.:


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

[...]
Track 1 sectors 10 length 3152 fixups 0 CRC32 67F0950E
Track 2 sectors 10 length 3152 fixups 1 CRC32 67F0950E
Track 3 sectors 10 length 3152 fixups 0 CRC32 67F0950E
Track 4 sectors 10 length 3152 fixups 1 CRC32 67F0950E
Track 5 sectors 10 length 3151 fixups 0 CRC32 67F0950E
Track 6 sectors 10 length 3152 fixups 0 CRC32 67F0950E
Track 7 sectors 10 length 3150 fixups 0 CRC32 67F0950E
Track 8 sectors 10 length 3151 fixups 0 CRC32 67F0950E
[...]

Это и есть защита диска, скрытая под самым нашим носом. Это 8 защищённых дорожек, которые на самом деле являются дорожками с совершенно стандартным форматированием (CRC32 67F0950E). В них правильное количество секторов и там нет удалённых секторов. Программа discbeast отобразит эти дорожки сплошным зелёным цветом, то есть скажет, что ничего необычного в них нет!

Длина дорожек немного колеблется, а кроме того, дорожки необычно длинные (в идеале их длина составляет 3125 байтов). Не совсем понятно, намеренно ли дорожки записывались чуть длиннее, но это определённо помогает защите дисков. Любой привод дисков, который будут использовать для воссоздания этих дорожек, вряд ли будет вращаться с такой скоростью, потому что она на 0,8% медленнее, а технология двигателей приводов дисков обычно даёт результаты лучше. Интересно заметить, что простая защита длинными дорожками является всего лишь ещё одним вариантом в схеме Western Security.

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

Заключение


В статье мы рассмотрели самую мощную схему защиты дисков BBC Micro model B среди всех, найденных мной в процессе изучения большинства дисков с защитой от копирования, выпущенных для этой машины. Очень хитро, что для создания или считывания диска не требуется специализированного оборудования. Однако с дублированием диска возникнут проблемы.

Подозреваю, что даже современное оборудование, например, Greaseweazle, будет испытывать проблемы с достижением побайтовой точности; необходимо дополнить его высококачественным приводом дисков, вращающимся с очень стабильной скоростью (например, моим Mitsubishi MF504C).

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

Similar posts

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 29

    0
    Оставалось придумать как подписать таблицу ожидаемых длин и такой диск было бы абсолютно невозможно скопировать (не трогая код программы конечно)
      0
      В сообщении написано «disk» вместо «disc»
      Потому что disc-это круглое, а disk-это квадратное. ;)
        +1
        На самом деле «disc» — с музыкой, все остальное — «disk». Но потом много чего поменялось…
        +6

        Переведено промтом? Очень много ошибок.


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

        Ещё, в вашем контексте fingerprints не надо переводить как «отпечатки пальцев». Там другой смысл. Лучше просто «отпечатки».

          0
          Когда-то давно, лет 25 назад, я делал простенькую защиту проги при помощи ключевой дискеты путем записи инфы в сектора нестандартного формата на отдельных дорожках. Штатными средствами эти сектора не считывались, дискета не копировалась, а специальный модуль в защищаемой проге эти сектора нормально считывал.
            +2

            Когда-то давно, лет 25 назад, была парочка мощных программ копирования защищенных дискет, прилетевшая из Фидо.


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

            0

            Это конечно круто, но зачем пытаться копировать, то что не копируется? Легче просто снять защиту. В большинстве случаев было достаточно поменять пару байт :)

            0
            Я думаю, можно копировать такие диски следующим образом (с применением специализированного оборудования, конечно):
            1) Контроллер измеряет скорость вращения диска с высоким разрешением и опорой на собственную тактовую частоту; и
            2) подстраивает скорость записи (битовую частоту) таким образом, чтобы на дорожку влезло заданное количество бит в пределах допуска.
            3) если оказалось, что записалось недопустимо много больше или меньше бит (это можно проверить путём измерения сигнала датчика индексного отверстия) — то повторять попытку, пока не запишется.

            Для этого контроллер должен уметь подстраивать битовую частоту с высоким разрешением. Но для современных микроконтроллеров или FPGA это не проблема.
              0
              это можно проверить путём измерения сигнала датчика индексного отверстия

              У многих дисководов этот сигнал выдавался от балды, о чем писал Питер Нортон в своей книге. Когда-то — в семидесятые — индексное отверстие действительно совпадало с началом первого сектора на дорожке, потом же стали просто писать сектора при форматировании на первую дорожку с началом в произвольном месте, а на остальные дорожки — ориентируясь на первую.
                +1
                на первую дорожку с началом в произвольном месте, а на остальные дорожки — ориентируясь на первую

                Не совсем так, сколько помню, и FFormat тому яркий пример — он размещал при форматировании дорожки таким образом, чтобы максимально увеличить скорость последовательного чтения (и на слух это звучало как "тук… тук… тук… тук" при стандартном форматировании и "тук-тук-тук-тук" при FF) выигрыш мог быть почти в 2 раза.
                А идею с "дублированием в высоком разрешении", думаю, можно реализовать на "слегка модифицированном" LS-120, но это только про 3.5", да и "зачем?"...

                  0
                  Это вроде как через BIOS делалось. Что-то типа: заказываем чтение первого сектора, после того, как получили, смещаем головку и пишет новую дорожку. Как раз получается смещение, чтобы диск не делал лишнего оборота. Но не всегда это работало, потому что контроллеры в самих дисководах были сильно разными.
                    +2
                    Всё немного иначе.

                    Считывание данных с дискет контроллером Intel 8272 может производиться в двух режимах: поиск и чтение отдельного сектора; или чтение дорожки целиком. Именно первый режим использовался для считывания операционными системами. Второй режим использовался только в защитах и спец утилитах.

                    При поиске сектора сигнал индексного отверстия не используется. Контроллер просто анализирует поступающие с дисковода данные на предмет заголовка нужного сектора. Как только будет найден заголовок — то за ним следуют данные, которые контроллером передаются в систему через DMA. По окончании чтения сектора генерируется прерывание процессора.

                    Если драйвер дисковода достаточно расторопный — то он может, получив данные одного сектора, сразу дать контроллеру команду на чтение следующего. Таким образом можно прочитать все секторы с дорожки за один оборот диска. Но, если драйвер диска слишком медленно думает — то следующий сектор может проскочить под головкой до того, как драйвер даст контроллеру команду на его считывание. В результате придётся ждать следующего оборота диска и тратить по обороту на каждый сектор, что в разы замедляет скорость чтения.

                    Если PC работает стабильно медленно, и драйвер дисковода никогда не успевает считать 2 рядом расположенных сектора подряд — то применяется система перемежения секторов — «Interleave». Сектора размещаются на дорожке с чередованием номеров:

                    1, 6, 2, 7, 3, 8, 4, 9, 5

                    Приведённая выше последовательность называется «2:1 Interleave». В такой системе, получив от контроллера данные первого сектора, процессор имеет ещё время, пока под головкой пробегает сектор 6, для выдачи контроллеру команды на чтение второго сектора, и при этом второй сектор будет считан на том же обороте диска. Все секторы дорожки можно считать за 2 оборота диска, что хуже, чем 1, но лучше, чем 9 (когда процессор не успевает без Interleave).

                    Стандартный формат MS-DOS использовал 2:1 Interleave.

                    Было ещё одно явление, замедляющее процесс считывания. Оно возникало при чтении секторов с нескольких дорожек. В идеале, если процессор и драйвер достаточно быстрые, и Interleave не используется — то две соседние дорожки можно прочитать за два оборота диска. В реальности, однако, после перевода головки на соседнюю дорожку предписывалось подождать 5мс для релаксации механических колебаний головки. На хороших дисководах ждать было не обязательно, но всё равно был риск прихода ошибочных данных в первые миллисекунды после перевода головки.

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

                    Для борьбы с этим явлением было придумано смещение нумерации секторов на соседних дорожках:

                    Дорожка 0 — 1, 2, 3, 4, 5, 6, 7, 8, 9
                    Дорожка 1 — 9, 1, 2, 3, 4, 5, 6, 7, 8
                    Дорожка 2 — 8, 9, 1, 2, 3, 4, 5, 6, 7

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

                    Подобные форматы дискет можно было реализовать только спец утилитами. Стандартные команды форматирования в DOS и Windows это не поддерживали и форматировали все дискеты с 2:1 Interleave.
                  0
                  У многих дисководов этот сигнал выдавался от балды, о чем писал Питер Нортон в своей книге

                  Можно пруф? Я не встречал ни одного исправного дисковода, который бы выдавал индексный сигнал от балды.

                  Индексный сигнал при работе дисковода необходим для следующих вещей:
                  1) Маркировать начало и конец записи во время форматирования: запись дорожки целиком ведётся от индекса до индекса;
                  2) Вести счёт оборотам диска при поиске сектора на дорожке. Если сектор не был найден после заданного числа индексных импульсов — то контроллер выдаёт ошибку «Sector not found».
                  3) Маркировать начало и конец считывания для операции «чтение дорожки целиком». Правда, эта операция в операционных системах обычно не использовалась, а использовалась только в защитах и сервисных утилитах для анализа и восстановления дисков.

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

                  Форматирование дорожки — это просто её полная перезапись, включая индексные метки секторов, преамбулы для настройки ФАПЧ, промежутки между секторами и индексными метками и т.д. При форматировании некоторые контроллеры (напр. КР1818ВГ93) позволяют произвольным образом задавать структуру, расположение и содержание данных на дорожке. При этом можно разместить секторы произвольных размеров в произвольной последовательности, не обязательно начиная с первого. Возможно, именно это явление описывалось у Нортона.

                  Индексный сигнал дисковода используется контроллером дисковода при форматировании. Контроллеры на всех PC были одинаковые — это микросхема Intel 8272. В более поздних вариантах она была интегрирована в микросхемы чипсета, но логика её работы осталась неизменной.

                  Таким образом, если на каких-то дисководах индексный сигнал формируется не от датчика положения диска — то на таких дисководах, как минимум, будет невозможно форматирование дискет. Как максимум — драйвер будет зависать в случае ошибки чтения вида Sector Not Found.
                +2
                В 1990 году мне рассказывали про метод «прокола иголкой».
                Прокалываем дискету, ищем где сбой чтения и этот адрес вписываем в прогу. И теперь она работает только с этого диска.
                Уж и не знаю насколько это было эффективно.
                  +3
                  Это делалось промышленным способом, только кололи не иголкой, а жгли лазером, и не абы где, а в нужном месте конвейерным способом. Помню, изучал комплект 3,5” дискет для школьного класса с какой-то обучалкой — дырка еле-еле была видна на просвет, но находилась в одной и той же позиции. Скорее всего, сначала жгли гибкий носитель с закрепленной на нем металлической фигней, потом упаковывали в корпуса, потом — на дупликатор.
                  0
                  Еще гулял достаточно crasy метод:
                  — форматируем дорожку каким-либо форматом, пишем нужное
                  — начинаем форматировать эту же дорожку другим форматом и прерываем операцию к моменту окончания записи заголовка

                  чтобы считать содержимое — требуется опять же начать и успеть прервать форматирование нужным (известным) форматом… соответственно расставив точки останова или попытавшись пошагово пройтись — необратимо убьём содержимое.
                    +3
                    Во времена, когда такого рода защиты были популярны, был копир, которому было абсолютно наплевать на это все. Идея была проста и очевидна — уйти от цифры. Два диска на одном шинделе, две головы и чисто аналоговый способ переноса намагниченности поверхности. А дырки в дисках, на этой же штуке, стали делать при помощи оптопары и иголки на соленоиде. Что касается длины дорожки, то посмотрев на формат дорожки становится все понятно Pre_gap — sector — gap — sector… Остаток дорожки. Играясь размерами гапов можно было выгадать на дорожке ещё несколько сотен байт для хранения чего нибудь «нужного», а фактическая длина дорожки измеряема. Уж сейчас не вспомню последовательность байт, но смысл простой — ставим размер сектора заведо больше, читаем последний сектор. При проходе индесного отверстия чтение завершается с ошибкой, но в буфере остаётся все что считано. По изменению в последовательности можно вычислять длину дорожки с точностью до полубита. Один из моих модулей в дипломной работе как раз этим и занимался. Правда задача решалась другая — определить мы все ещё на том же хосте работаем или уже попробовали на другом запустить. 95 год :-):-):-):-)
                      0
                      Проблема этого копира была в его малой доступности. Этак возможно пара штук на город-миллионник. Поэтому он как таковой в расчет особо не брался…
                      Хотя 95 год… уже наверное коммерциализировался в том числе и рынок пиратки. Правда и CD-диски пошли уже.
                        0
                        Для 5.25 собирался ручками за вечер, в общем-то…
                          0
                          CD уже были. Только, зараза, дорогие — и сами приводы, и диски пиратские, так что народ в 1995 больше пиратил на дискетах. Но на CD той поры встречались интересные вещи. Например, одна софтина ставилась только с дискет, которые нужно было менять (отслеживалось открытие дверцы), и в дискете, видимо, была та самая «дырка». Так вот, на CD лежали образы дискет, а к ним прилагалась специальная программа для записи образа и последующей «порчи» нужного сектора.
                            0
                            Софтинка была «недоланной» :-) были «неприятные» софтинки, которые наличие дырки проверяли записью сектора :-(
                              0
                              Уж не «Лексикон» ли?
                                0
                                Не, какая то бухгалтерия. И, как ни странно, это было не совсем пиратство. Софтинка была честно купленной и умела деинсталлироваться, увеличивая счётчик на еденичку. Но разработчики почему то считали, что умерший носитель обязывает клиента купить софтину ещё раз. Кончилось банальным пиратством — один раз восстановил носитель, потом инсталляция, снанпшот, деинсталл, вернуть снанпшот (задумался… а ведь тогда и термина такого не было ведь :-)), деинсталл и так далее. На итерации так 10ой я сдался и бросил это занятие, тем более что это была просьба от друзей, а не заработок. :-)
                              0
                              По-моему в 95-96 уже на сотню развалов на митинском рынке 1-2 были с дискетами, остальные торговали «болгарами» и «золотом».
                                0
                                В Москве — может быть, тем более, что пиратка, в основном, оттуда по стране расходилась. У нас же CD как-то так массово появились в 1996, сначала — с игрушками и с комплектами Windows 95 + Office 95. Ставить 95-ую «Винду» с офисом с дискет — то еще удовольствие…
                                  0
                                  Ну это для тех кто Novell Netware 2.15 не ставил)
                                    0
                                    Дык и Windows 95 с дискет ставили, и OS/2. «Винда» вообще имела нестандартный формат дискет, и не на каждую 3,5” 1.44 Mb ее можно было писать. Просто народ стал ленивым, и потребовал установки с CD, тем более, что железо потихоньку стало дешеветь.
                        0
                        Сложная защита с точки зрения попытки копирования «как есть», но элементарная с точки зрения создания взломанной версии. Достаточно изменить один байт — операцию сравнения, чтобы всегда происходил переход как если сравнение показало совпадение таблиц длин.

                        Only users with full accounts can post comments. Log in, please.