Comments 22
Интересно, спасибо.
Разбирал когда-то защиту досовской программы, основанную на использовании критической ошибки. На дискете присутствовал прокол, сделанный иголкой. При невозможности прочитать сектор без ошибки вызывался заботливо подставленный собственный обработчик, делавший свою работу.
красиво
А еще были механики защиты на дискетах, когда контроллер программировали напрямую и при записи сектора сама запись прерывалась на середине. Таким образом появлялись "плавающие" биты, которые с какой-то вероятностью считывались либо нулем, либо единицей. При копировании соответственно копировалось какое-то одно значение. При проверке сектор считывался несколько раз и статистически должно было получаться, что данные в секторе каждый раз были разные. Копия же выдавала стабильно одно и то же.
Все-таки не очень понятно, на чем эта защита основывалась. Ну допустим, не заводе записали дискету таким макаром. Но в итоге же на ней будет записал либо 0, либо 1, завод этого не узнает. Как это знание поможет в проверке защиты на компьютере пользователя?
На том, что при чтении правильной дискеты у вас считывались РАЗНЫЕ значения, а на скопированной - всегда одно и тоже.
Почему разные? Это записаться может что угодно, а считывается всегда что-то одно. Да, неизвестно что, но если сравнивать только результаты самих попыток, они одинаковые будут всегда. Эталона для сравнения то нет
Так на дискете ноль это же не отсутствие намагниченности, там же еще и клок-биты пишутся. Дисковод клока не видит на ненамагниченной области, коэффициент усиления повышает и шум считывает. Можно по "weak bits" поискать в Сети.
При правильно подобранных таймингах записывалась только половинка от нормального размера магнитного домена (бита).
Если я правильно понял, цель защиты в том, чтобы при записи недостаточно намагнитить элемент, чтобы он читался неуверенно. Но разве при этом не должна возникать ошибка чтения? Почему читается случайное значение, если дисковод видит, что уровня сигнала недостаточно для однозначного определения, логический 0 там, или 1? А коды исправления ошибок? Разве их там нет?
Была ещё в эпоху спектрумов подобная защита в УФ-ПЗУ. Тоже спецпрограмматором создавали такие биты. Проблема была в том, что потом заряд из ПЗУ уплывал, а дискеты размагничивались, и защищённый таким образом софт приобретал непригодный вид.
Ещё такая фишка была - один сектор критической информацией делался дублированным, т.е. имеющим физически одинаковый номер. "Двойник" размещался в противоположной по периферии трека позиции относительно законного, так, чтобы процедуры чтения наиболее вероятно считали именно его, а не двойника. Впихнуть такой сектор технически возможно за счёт сокращения межсекторных маркеров, которые формируются с запасом по надёжности считывания. Именно за счёт них были доступны форматы дискет >720 КБ (800, 900) для 5.25, для 1,44 дискет тоже было подобное. Так вот, при копировании обычными средствами критическая информация терялась. Доступ к секретному сектору осуществлялся низкоуровневым фиктивным чтением сектора, идущего непосредственно до секретного, следом сразу запрашивался секретный.
Такой способ защиты использовал, скажем, Турбо Бухгалтер 3.х под ДОС.
Да, шифрование XOR-ом - это еще та криптография. Помню, надо было какой-то файл документации прочитать напрямую, подготовленный в программе Norton Guides. Как оказалось, файл был частично зашифрован. Только вот шифрование было через XOR одного единственного байта. Мало того, это значение всегда было фиксировано и прямо глазами было видно в шестнадцатеричном редакторе, поскольку нулей в данных обычно довольно много и этот байт визуально нули заменял.
Так то одноразовый криптоблокнот тоже XOR использует, spy grade как-никак. Все зависит от выбора второго аргумента XOR (негодный вариант как раз Вы и привели).
Так вопрос не в XORе как таковом, а в его применении в подобных системах шифрования. Одноразовый блокнот можно и не на XORe сделать, лишь бы была обратная функция. В принципе так же хорошо подойдет и простое суммирование. просто XOR удобнее, поскольку позволяет работать с любым количеством бит и является обратной функцией к самому себе. Но вот только одноразовый блокнот должен базироваться на большом одноразовом и абсолютно секретном ключе.
Кстати. вспомнил еще одно применение XORа, с которым приходилось сталкиваться. Была одним студентом написана самопальная защита для мелкой утилитки. Защищаемый код был заксорен так же одним байтом, а расшифровка запускалась по шаговому прерыванию отладки. Сломана такая "защита" была, естественно, за несколько минут.
hiew в те времена очень помогал, но оказывается и сейчас живет и здравствует https://www.hiew.ru/
Декодируем 90-ые: реверс-инжиниринг и криптография на заре разработки ПО