Помнится, я здесь как-то писал, что ещё занимаясь на РАДИО-86РК решил попробовать сделать алгоритм, восстанавливающий программу из одного лишь 16-битного CRC! Естественно, занятие абсурдно даже теоретически ввиду ограниченной ширины CRC. Сегодня задумался, можно ли все программы защитить на первой стадии нулевым CRC? Т.е. любое приложение или драйвер имеет маленький дамп таблицы с избыточным кодом, который в итоге приводит CRC всего файла к нулю. Кстати говоря, в мире софта имеется бессмысленное число CRC. А по идее, мы, программисты, должны стремиться к тому, чтобы, как и в природе, каждый мог бы купить не только домен в интернет, но и CRC для своих программ. Чтобы какбы все программы одной компании имели n-бит CRC одинаковые. А оставшиеся - код продукта и его версия. Без разбора экзешника с поиском сведений. Хочу заметить, что CRC можно легко аппаратно вычислять ещё на уровне чтения данных из ОЗУ в кэш. Зачем это нужно? Во-первых, CRC можно использовать как штрих-код, наравне с электронной подписью. В 64/128-битном CRC можно закодировать код фирмы-изготовителя данного ПО. Абсурд? И зачем же это нужно? Такой примитивный метод? И ненадёжный! А дело вот в чём. Как-то по телевизору в передаче увидел технологический процесс, где роботы вставляют в печатные платы микросхемы и радиодетали. Комментатор говорил, что используется сложная программа распознавания угла поворота чипов по текстовой маркировке. Задумался, а почему на все электронные компоненты не наносят штрих-код? Как у резисторов, диодов и т.д. Но, штрих-код в УФ-диапазоне. Т.е. для человека - обычная текстовая маркировка. А для машинной автоматики - УФ. Чтобы машина даже из хаотической кучи радиодеталей могла быстро извлечь нужное и развернуть как надо без специального сложнейщего алгоритма. Если идти дальше, то сама печатная плата должна иметь УФ-маркеры, чтобы робот даже без предварительной загрузки базы в память сам видел, где на плате какие должны стоять детали. Вы сами понимаете, УФ-спектр очень широк. Ещё будучи подростком я фантазировал: Пришёл на радиорынок с таким УФ-сканером и уже знаешь, в какую точку двигаться и у какого товарища спрашивать детали. Так-как тот заранее наряду с надписью "Транзисторы" и т.д. нанёс на бумагу УФ-штрих. Метод очень прост. Так-как даже в видимом диапазоне и семи цветов именно семь оттенков отличает человеческий глаз оптически, хотя технически спектрально можно обнаружить тысячи подоттенков. То в УФ-краске можно зашифровать миллиарды оттенков, где каждый может иметь своё назначение. Говоря проще, закодировать роман "Война и Мир" в одном лишь луче УФ-света! Всё лишь зависит от точности анализатора спектра. Представьте, что оптические диски дошли такой степени технологичности, где на участке, который раньше умещал всего 1 бит, записано миллиард байтов одним лишь оттенком УФ-спектра. Тем самым на оптическом диске можно разместить ни n-ное число файлов с суммарной ёмкостью 640Мб, а 640 миллионов файлов каждый с ёмкостью до 4Гб! Вы читаете и смеётесь, что я называю ни 4,7Гб DVD и даже ни 700Мб CD, ни говоря про BluRay. А именно 640Мб - устаревшую ёмкость. Я пишу так намеренно. И не буду обосновывать. Так-как желающие понять суть моих мыслей и так всё поняли... Надеюсь.
Крутяк. Осталось тока запатентовать и сымать сливки. Почему еще на хабре этого не было только непонятно
Paguo_86PK Вообще не вижу связи между CRC и цветовым кодированием. Ну да ладно. Никакого равна с электронной подписью у CRC нет и быть не может. Чем плох текущий формат экзешников с ресурсами и certificate table? Преимущество штрихкодов очевидно: относительная простота автоматического сканирования. А в чём преимущество CRC перед соответствующими полями в exe? В качестве электронной подписи вместо certificate table тоже не попользоваться, т.к. подделывается на раз (у CRC цель-то совсем в другом, а именно подтверждать целостность данных, причём тюнингован он под определённые распространённые типы ошибок при передаче данных). Это всё, конечно, круто звучит в качестве рекламы готового продукта, но пока не будет точного описания техпроцесса изготовления таких носителей, удовлетворяющего нижеуказанным условиям, это не более, чем сказочная идея. Условия: 1) Техническая простота чтения таких носителей. 2) Техническая простота записи таких носителей. 3) Высокая скорость чтения таких носителей (что-то мне подсказывает, что такие многотерабайтные носители будут читаться на скорости 1 кбпс в лучшем случае). 4) Высокая скорость записи таких носителей (аналогично). 5) Долговечность таких носителей (ща пять терабайт со своего винта отбэкаплю, а завтра уже половина этих данных не прочитается). P.S. http://bash.org.ru/quote/415726
и малейшее изменение влажности, запыленности или даже насыщенности углекислотой и данные читаются неверно скорей флэшь домучат (cf уже на (?)250гб видел)
l_inc http://bash.org.ru/ quote/415726 мля..сталобыть это уже было. ТС, хватит копипастить с хабры! ПС: кстати сказать, для генерации этакого 'избыточного кода', который для начала сделат црц равную нулю эти генеряшки тоже придется брутфорсеть.
Paguo_86PK > Помнится, я здесь как-то писал, что ещё занимаясь на РАДИО-86РК решил попробовать > сделать алгоритм, восстанавливающий программу из одного лишь 16-битного CRC! Q: как восстановить файл по md5? A: вбиваешь в осла, восстанавливаешь... так что идея не бредовая. как говорится: "зависит от..." > Сегодня задумался, можно ли все программы защитить на первой стадии нулевым CRC? от ошибок передачи данных -- можно. от хакеров -- нет. точнее, можно, если, например, сжимать файл и считать CRC уже сжатого файла. если хакер может воздействовать только на файл до его сжатия, то задача подделки CRC резко усложняется, но все еще остается возможной. потому что CRC для этого не предназначено. и ваш вопрос из серии -- а мобилу в качестве камеры видеонаблюдения использовать можно? > Т.е. любое приложение или драйвер имеет маленький дамп таблицы > с избыточным кодом, который в итоге приводит CRC всего файла к нулю. нет. это контрольная сумма H для блока данных D вычисляется так, что контрольная сумма DH равна нулю. даже если CRC хранится где-то в другом месте, ничего не стоит после хака программы добиться неизменности CRC (при условии, что править можно больше одного бита). > Хочу заметить, что CRC можно легко аппаратно вычислять ещё на уровне чтения данных из ОЗУ в кэш. в серверах по жизни стояла память, которая не только обнаруживала ошибки на хардверном уровне, но еще и правила их. > Во-первых, CRC можно использовать как штрих-код, наравне с электронной подписью. > В 64/128-битном CRC можно закодировать код фирмы-изготовителя данного ПО. на хрена для этого CRC? стойкости -- никакой. его не только подделать можно, оно может тупо совпать по иронии судьбы и предъяву не кинешь. > И зачем же это нужно? Такой примитивный метод? И ненадёжный! примитивный, ненадежный и оччччень геморойный. > Если идти дальше, то сама печатная плата должна иметь УФ-маркеры, > чтобы робот даже без предварительной загрузки базы в память сам видел а вы робота видели? "а суслик-то есть" (с) > Метод очень прост. Так-как даже в видимом диапазоне и семи цветов именно семь оттенков > отличает человеческий глаз оптически, хотя технически спектрально можно обнаружить > тысячи подоттенков. То в УФ-краске можно зашифровать миллиарды оттенков, где каждый что вы курили? какие в анал оттенки? краска имеет свойство менять цвет, что и ограничивает кол-во цветов, применимых на практике. и без всякого уф все работает. какие проблемы вы собрались решить? тех, которых нет? > Говоря проще, закодировать роман "Война и Мир" в одном лишь луче УФ-света! всю британскую энциклопедию можно закодировать в виде одной риски на карандаше. пусть она делит карандаш АB на отрезки AX и XB. AX/XB дает число, в котором можно закодировать бесконечное множество информации. и на фига вам эти винчестеры? > Вы читаете и смеётесь, что я называю ни 4,7Гб DVD и даже ни 700Мб CD, ни говоря про BluRay. > А именно 640Мб - устаревшую ёмкость. пишу так намеренно. И не буду обосновывать. мысли никому не интересны. а вот на прототип устройства я бы посмотрел.
