как защитить программу?
интересуют моменты:
- как защитить от копирования (ну или дать скопировать, но не дать запустить скопированный модуль)
- как реализуется защита серийным номером. что-то в духе запускаю программу - она спрашивает номер, после ввода правильного значения программа работает (про серийный номер не спрашивает)
- как (хэш, или....) и где (в коде, в файле, в...) хранить пароли, тот же серийный номер и т.п.
Это может быть например серийник проца, ну или на что хватит фантазии.
При защите серийником соответственно надо его гдето хранить в коде и проверять. Причем желательно хранить не сам серийник а его хеш например. Соответсвенно необходимо шифровать файл, дабы это не сразу бросалось в глаза. Ну и надо учитывать собственно ценность программы - разработка защиты, не дешевое удовольствие.
интересуют моменты:
Это очень широкая тема:) Если хочешь сам ее копнуть глубже, советую посмотреть ссылки в прилепленной теме, и в первую очередь Скляров, Искусство защиты и взлома информации.
Кратко постараюсь на твои пункты: ( Если уточнишь то, что тебе больше всего в данный момент интересует, постараюсь помочь поконкретней.)
- как защитить от копирования (ну или дать скопировать, но не дать запустить скопированный модуль)
1. Регистрационные коды.
а) Черный ящик - просто в реализации, сравн. легко взломать.
б) Алгоритмически сложная задача - стойки, но сложны в самостоятельной реализации, требуют длинного ключа, и многие алгоритмы покрыты патентами.
в) Табличный - можно полностью блочить скомпрометированные коды, но занимает много места, если пользователей много, и не позволяют привязать код к имени пользователя.
По-моему, есть открытые библиотеки для разработки РК, но их надежность надо выяснять:)
2. Привязка к носителю.
Тут kot_ высказался, от себя добавлю, что:
а) Есть три уровня такой защиты - файловой системы, секторов диска и команд контроллера.
а) Очень многие "самодельные варианты" открыватся легко разными "виртуалками".
Наилучшая из этих защит - StarForce Professional (IMHO).
3. Аппаратные ключи.
4. Использование протекторов. (ASProtect, и. т.д.)
По этим двум долго рассказывать, спрашивай конкретнее:)
- как реализуется защита серийным номером. что-то в духе запускаю программу - она спрашивает номер, после ввода правильного значения программа работает (про серийный номер не спрашивает)
С прикладной точки зрения - проще всего использовать протекторы. Самостоятельная разработка и реализация стойкой защиты трудновата;)
Уточни, ты хочешь знать алгоритм защиты, примеры, как они могут быть реализованы для регистрационных кодов, или просто знать, какие есть средства для защиты программ?
- как (хэш, или....) и где (в коде, в файле, в...) хранить пароли, тот же серийный номер и т.п.
Вычисляешь хэш-функцию от заданного пароля (что такое ХФ и их виды читай фак по криптографии в прилепленной теме), и хранишь ее в конф. файле, например. Потом от введенного юзером пароля считаешь хэш, и сравниваешь с сохраненным.
привязка к номеру процессора и т.п. всё равно сведётся к проверке и какому-то jmp **** в коде или как-ть элегантнее это можно реализовать? (чтоб патчилось не сходу :) )
научи, как получить серийный номер процессора (лучеб средствами VC++). В VC++ есть библиотеки, которые хэши считают?
2Zorkus:
Есть три уровня такой защиты - файловой системы, секторов диска и команд контроллера. - не оч уловил я об чём речь - чтоб полистать (для общего развития)?
StarForce Professional - это что-то коммерческое только для CD? (мне интересно пока про копирование с машины :) )
про ASProtect (он свободный бывает?) пока ничего не спрошу - покапаю методическую литературу:)
привязка к номеру процессора и т.п. всё равно сведётся к проверке и какому-то jmp **** в коде или как-ть элегантнее это можно реализовать? (чтоб патчилось не сходу )
научи, как получить серийный номер процессора (лучеб средствами VC++).
Лично я не советую юзать для защиты жесткую аппаратную привязку. Потому что чем сложней такая система, тем больше вероятность ее ложного срабатывания (например, человек поменял проц, и что?:) ему новую копию покупать?), потому что аппаратные составляющие системы, как и некоторые любимые разработчиками защитных схем програмные части, как, скажем, реестр, могут меняться совершенно непредсказуемо по самым разным и часто абсолютно тривиальным причинам. Вдобавок, за компом сидит человек, которые, соббсна, совсем не обязан быть экспертом в IT, и может сделать в любой момент что то "не так, как предусматривалось". Короче, отладить такую защиту и обеспечить ее стабильность будет крайне сложно.
В VC++ есть библиотеки, которые хэши считают?
Eсть, конечно (а в яве так вообще, любой объект может сам свой хэш посчитать:)). Посмотри ссылки припленные ,говорю. Из самых известных алгоритмов хэширования - MD5 и SHA-1 полно инфы в инете и готовых открытых реализаций.
2Zorkus:
Есть три уровня такой защиты - файловой системы, секторов диска и команд контроллера. - не оч уловил я об чём речь - чтоб полистать (для общего развития)?
Самый высокий - уровень файловой системы - на этом уровне это список каталогов и файлов. Данные записываются на диск в каком то формате (ISO 9660, например), и и драйвер файловой системы CD (CDFS)с ними работает. На этом уровне возможно химичить c метками тома, в том числе, атрибутами файлов, и т.п.. Но против посекторного копирования ниче не сделать.
Далее - Уровень секторов, данные = последовательность секторов и таблица, опис. содержимое диска (TOC). На этом уровне можно умышленно нарушать стандарт записи на диск, (потому что вышеупомянутый драйвер берет далеко не всю инфу, что можно узнать о диске, а только то, что ему надо для работы с файлами) и тогда диск будет читаться, а вот проги посекторного копирования могут заорать, что диск запоротый:). Да и некоторое железо может начать глючить после такого.
Третий - Уровень команд контроллера (сам знаю весьма приблизительно). Они могут различаться для приводов, естественно. Но дают самую полную инфу о диске. Для этого надо свой драйвер писать, вроде.
Насчет SF - да, примерно. Но пока, думаю, тебе оно не особо нужно:)
привязка к номеру процессора и т.п. всё равно сведётся к проверке и какому-то jmp **** в коде или как-ть элегантнее это можно реализовать? (чтоб патчилось не сходу :) )
научи, как получить серийный номер процессора (лучеб средствами VC++). В VC++ есть библиотеки, которые хэши считают?
2Zorkus:
Есть три уровня такой защиты - файловой системы, секторов диска и команд контроллера. - не оч уловил я об чём речь - чтоб полистать (для общего развития)?
StarForce Professional - это что-то коммерческое только для CD? (мне интересно пока про копирование с машины :) )
про ASProtect (он свободный бывает?) пока ничего не спрошу - покапаю методическую литературу:)
Ты бы почитал бы всеже - тема действительно необъятная - рассказывать можно долго. Характеристики процессора можно получить из реестра
и через
GetSystemInfo(&test);
ShowMessage(IntToStr(test.dwOemId));
можно использовать асм - на нем есть специальная команда для получения х-к проца.
Кроме того надо знать, что серийный номер ты можешь получить фактически только для третьего пня. До него такого параметра не было, а теперь он закрыт.
Тоже и с jmp - понятно что если у тебя будет простой переход на адрес где хранится эталон - то защита твоя будет снята легко. Поэтому и используются протекторы (упаковщики и шифровалки) что бы скрыть исходный код - проверка должна производится ... вобщем подними литературу почитай. Слишком уж обширная тема.
И тот того, кого ты видишь своим противником :)
И от того сколько денег ты потеряешь если без защиты. Мой совет - если сумма составляет до 500 бакинских - защиту делаешь самую простую и особо на этом не акцентируйся. Не рентабельно. Потому как написание классной защиты займет у тебя как минимум 7 дней хорошей работы. Это очень оптимистично если очень хорошо вкалывать. Т.е. 16 часов в день Х твой час в у.е. час Х 7 - вот тебе минимальный размер потерь ради которого вобще стоит заморачиватся.
Для сугубо прикладного PC-приложения? Поясни схему, которая будет удобна и практична:)
На самом деле это пока набор немного несвязных идей, но тем не менее.
1. Рассуждения на тему защиты программно - аппаратного комплекса
2. Попытка исполнить SQL-код на MSSQL2000 так, чтобы никто не мог его подсмотреть и отладить. Здесь была написана хранимая процедура, которая имела один параметр - пользовательский ввод. В свою очередь она вызывала расширанную хранимую процедуру, которая присоединялась к базе и на основе строки, введенной пользователем расшифровывала SQL-запрос с последующим выполнением. Перенося на случай прикладного ПО: хранимая процедура - это ПО, а расширенная хранимая - это микроконтроллер.
Как результат - это а)либо скрытие части исполняемого кода (либо части данных, необходимых для инициализации ПО) в микроконтроллере с последующей его восстановкой при успешной авторизации, б)либо непосредственно реализация части расчетов в микроконроллере.
Буду рад обсудить этот подход.
Я тоже:) Но боюсь, буду жестковат в критике, характер такой;)
По ссылке ходил и читал, пока без необходимости комментировать не буду оттуда посты. Как ты и хотел, постараюсь максимально абстрагироваться от возможных реализаций, но все же буду ссылаться на примеры, чтоб не быть голословным.
2. Попытка исполнить SQL-код на MSSQL2000 так, чтобы никто не мог его подсмотреть и отладить. Здесь была написана хранимая процедура, которая имела один параметр - пользовательский ввод. В свою очередь она вызывала расширанную хранимую процедуру, которая присоединялась к базе и на основе строки, введенной пользователем расшифровывала SQL-запрос с последующим выполнением. Перенося на случай прикладного ПО: хранимая процедура - это ПО, а расширенная хранимая - это микроконтроллер.
Я не знаю БД, и тут ничего не скажу, с такими вещами не в этот раздел..
Как результат - это а)либо скрытие части исполняемого кода (либо части данных, необходимых для инициализации ПО) в микроконтроллере с последующей его восстановкой при успешной авторизации, б)либо непосредственно реализация части расчетов в микроконроллере.
Сделаю несколько принципиальных замечаний.
В самом начале обсуждения той темы сказано, что автор имеет железо, и имеет приложение, работающее с ним через собственный драйвер. Но из дальнейшего обсуждения не понял - все таки, ты свою идею позиционируешь как систему защиты единичной системы, конкретной
- плата + драйвер + прикладное приложение? Или ты хочешь создать универсальную систему защиты? Учти, что если для отдельной системы - то задача облегчается тем, что можно сокрыть описание - схемы и реализации, но с другой стороны - сложней будет проверить корректность работы, и практическая ценность будет невелика. Производитель может делать со своей платой что хочет, его право.
Если же ты считаешь, что это система для более-менее универсальной защиты, то тогда мы говорим об аппаратных ключах, причем как я понял, из последнего поста - ключах с программируемым алгоритмом.
Они хорошо описаны, но я укажу несколько особенностей такого подхода:
- Сложность алгоритма будет ограничена объемом памяти и системой команд ключа.
- Для создание действительно стойкого алгоритма потребуется отличное знание криптографии + потребуется найти такую функцию, чтобы противник не смог догадаться по контексту работы, какие именно операции происходят внутри вычислительного модуля ключа.
- Для многих популярных ключей (вроде, в ключах HASP, но точно не помню) используемые алгоритмы известны, т.о. "стандартные", так сказать, варианты тут не прокатят.
Для поддержание обсуждения, добавлю такое общее соображение, навеяно темой, которую ты тут дал. Постараюсь вкратце тут обощить и развить те возражения, которые высказывались разными людьми в твоей ссылке:
- Во многом, сложность состоит в правильности выбранного генератора. Многие неверно считают, что хорошим криптогенератором является любой физический/аппаратный источник. Но это же не так. Этот вопрос можно обсудить отдельно, вкратце - какой ты предлагаешь?
- Аппаратный ключ будет бессилен, если удастся внедрить между ним и приложением, реализующим логику, эмулятор. Какую защиту от эмуляции предлагаешь ты? Тот факт, что часть вычислений выполняется внутри ключа и не может быть перехвачена, еще не дает полной гарантии, как я указал выше.
- Существенным является выбор условий для хэширования. Зачастую, кажущиеся безопасными и натурально, случайные, условия, легко эмулируются. Там много об этом писалось, я не вспомню щас точно пример, но была какая то защита, где начальные условия брались на основе текущей даты, ID процесса и еще чего-то (где-то брали состояние фрейм-буфера, это частности). Это все легко подделать.
- Проектируя строение ключа, необходимо учитывать, что он должен быть не слишком дорогим. Это накладывает ограничения на инновации в реалилизации.
- Программная защита реализуется проще, и ключ следует использовать, когда он имеет очевидные и недостижимые преимущества. Перечисли и обоснуй их:)
2. Попытка исполнить SQL-код на MSSQL2000 так, чтобы никто не мог его подсмотреть и отладить. Здесь была написана хранимая процедура, которая имела один параметр - пользовательский ввод. В свою очередь она вызывала расширанную хранимую процедуру, которая присоединялась к базе и на основе строки, введенной пользователем расшифровывала SQL-запрос с последующим выполнением. Перенося на случай прикладного ПО: хранимая процедура - это ПО, а расширенная хранимая - это микроконтроллер.
В дополнение к вышесказанному.
Пример ХП крайне неудачный. Это скорее пример нерационального усложнения проекта и непонимания основ проектирования БД
Вы не поняли суть. С пониманием основ проектрирования у меня все ОК.
И при разработке обычной системы этого я такого бы не стал делать.
То, что я написал - это добавление к системе уязвимости. Её необходимо сделать такой, чтобы даже если кто - то заподозрит, что она есть, не смог ее исследовать.
Этот пример считаю неплохим. Позже, когда отпишусь на пост Zorkusа, попытаюсь это пояснить.
наилучшая защита это распространение только демо версии, а если пользователю она понравилась то пускай сначала даёт деньги потом получает полную версию..... конечно же ничто потом ему ничего не мешает распространять полную версию, но это намного лучше, чем распространять полную версию, которая работает на полную когда в неё введёшь какой нибудь регистрационный код
Никто не спорит. Но есть же ограничения.
- Например, многие ассиметричные алгоритмы основаны на решении сложной математической задачи (факторизация длинного числа, вычисление конечного логарифма в дискретном поле). Пока нет эффективных способов решения этих задач - взломать основанных алгоритм не получится. Ясно, что если придет новый Перельман, и найдет гениально эффективное решение, то все сдохнет. Но - не думаю, что в этом случае к создателям систем защиты, сделавшим все верно, будет предъявлять претензии:).
- Можно взломать, конечно, любой ключ можно найти полным перебором. Но мы же не предполагаем, что любой взломщик, желающий попробовать на зуб нашу защиту, располагает мощностями, скажем, как у NSA;)
наилучшая защита это распространение только демо версии, а если пользователю она понравилась то пускай сначала даёт деньги потом получает полную версию..... конечно же ничто потом ему ничего не мешает распространять полную версию, но это намного лучше, чем распространять полную версию, которая работает на полную когда в неё введёшь какой нибудь регистрационный код
Ну так, речь о защите полных версий. Демки-то чего защищать:)
В диспетчере задач некоторые процессы имеют такой приоритет, что их нельзя завершить. А как я могу дачть своему приложению такой приоритет, как процессу lsass.exe?????????
Принимаю два варианта как сделать:
1. Через системный реестр
2. Кодом C#
В диспетчере задач некоторые процессы имеют такой приоритет, что их нельзя завершить. А как я могу дачть своему приложению такой приоритет, как процессу lsass.exe?????????
Принимаю два варианта как сделать:
1. Через системный реестр
2. Кодом C#
здесь драйверок писать придется, который бы не позволили завершить твою программу и вряд ли для этого решетка подойдет.
это конечно можно использовать, но:
1. обходится и взламывается;
2. как быть с пользователями, у которых нет выхода в интернет?
Это факт. Но это мало важно. Потому что если мы пишем, скажем, прогу для реализации лабораторок - то мы не предполагаем, что будем иметь дело с соперниками уровня ФСБ или АНБ. И в целевом контексте - она может быть сделана практически неломаемой.
И еще - когда мы пишем прикладную прогу - мы не стремимся сделать ее неломаемой. Мы просто хотим немного повысить прибыль от продаж.
И твое "никому не нужна" - надо понимать как "Ее взломать настолько трудно, что это превысит наши затраты. Или возможности."
А как MS - по телефону.
Гм. И ты будешь записывать полторы сотни бессмысленных знаков?;) И потом думать, почему введенное неправильно?
Для того чтобы как мелкософт по телефону - для этого надо иметь каллцентр который как минимум будет работать в светлое время суток :) Иначе ситуация когда общаешься с гайцом например и тут звонит клиент...:)
Оффтоп..
Не сыпьте мне соль на рану, пожалуйтса)) У меня не работал месяц инет, вот сегодня настроили наконец. И все это время я каждый день звонил в техподдержку...
1) Могут подслушать
2) Можно ослышаться
3) можно оговориться
4) Может быть плохая связь
5) задолбаешься писать и сверять
:)
Когда не авторизует, не докопаться до истины. В чем ошибка?
Неправильный код выдали (всмысле, он в разных базах расхидится), неправильно продиктовали, неправино услышал, неправильно записал, неправильно ввел...
1) Могут подслушать
2) Можно ослышаться
3) можно оговориться
4) Может быть плохая связь
5) задолбаешься писать и сверять
:)
Когда не авторизует, не докопаться до истины. В чем ошибка?
Неправильный код выдали (всмысле, он в разных базах расхидится), неправильно продиктовали, неправино услышал, неправильно записал, неправильно ввел...
Ну это уже огмеры. у нас центер калла :) обслуживат порядка 3-5 тышч и ничего. Научили.
Ну согласись, что куда проще и приятней купить карточку/подрубить мобилу к компу для тех, у кого норм. инета нету, и зарегиться через сеть.
все равно необходимо иметь центр поддержки. разницы большой нет.
В диспетчере задач некоторые процессы имеют такой приоритет, что их нельзя завершить. А как я могу дачть своему приложению такой приоритет, как процессу lsass.exe?????????
Принимаю два варианта как сделать:
1. Через системный реестр
2. Кодом C#
Твой процесс должен запускаться от системы (в режиме ядра) а не от юзера. А С# тут каким боком?
Так я и не спорю с тем, что поддержка по телефону необходима. Для консультирования. Это удобней, чем по почте переписываться или даже по аське.
Но для передачи большого кол-ва точных данных рег. кода это неудобно!
Дело даже не в орг. вопросах, диктовать по телефону десятки/сотни бессмысленных знаков - это неудобно.