Как создать файл лицензии для программы
Обновлено: 08.07.2024
Вот сгенерировал я ключик, а как заставить программу проверять, подходит ли этот ключик? С чего конкретно надо начать?
1) А с помощью каких средств можно заставить программу обращаться к удаленному серверу и где этот сервер вообще должен находиться? На интернет сайте? А как вложить на сайт этот сервер, который будет проверять правильность введенных ключей?
Где он должен находиться - это не принципиально для построения защиты, но можно считать (как делается в большинстве подобных программ), что он удален. Необходимо организивать доступ к нему по защищенному протоколу - но это уже технические подробности.
Файл - никак. Файл - это просто набор байтов.
Ты можешь его послать кому-то его в зашифрованном виде, но если получатель имеет возможность его расшифровать - ты никак технически не запретишь ему его распространять в расшифрованном виде. Можно установить на файл какие-то юридические права - и тогда распространение копий будет преследоваться.
Вот сгенерировал я ключик, а как заставить программу проверять, подходит ли этот ключик? С чего конкретно надо начать?
Какой конкретно ключ? Поясни. В примитивном случае - можно хранить в программе некоторые массивы структур типа
char hash[length]; // Хэш ключа.
enumState state; /* Описание его состояние - свободен, занят, скомпрометирован.*/
>
И при попытке вставить ключ - вычислить от него хэш, и проверить, совпадает ли он с каким либо. Далее, смотря по состоянию - либо регистрируем программу, либо сообщеем, что такой ключ уже кем то используется, либо (в худшем случае:)) сообщаем о попытке взлома куда следует;).
Какой конкретно ключ? - А какие способы бывают? Желательно какие-нибудь легкореализуемые))
А вот еще насчет приведенного кода: в какой среде этот код писать? В той же, в которой написана и программа?
А что такое хэш ключа? Откуда он берется?
Ключ регистрации (не принципиально, что именно он из себя представляет).
- А какие способы бывают? Желательно какие-нибудь легкореализуемые))
Легче всего - распространять под GPL:) Про способы защиты программ от копирования - посмотри прилепленные ссылки раздела "Компьютерная безопасность", и несколько тем там были, могут быть полезны. И потом уже задавай конкретные вопросы. А так же определись, что тебе все таки нужно - шифровать файлы, или реализовать регистрацию программ?
А вот еще насчет приведенного кода: в какой среде этот код писать? В той же, в которой написана и программа?
Ты имеешь в виду IDE? Неважно, я показал пример, как может храниться информация о ключах. Ее можно хранить на удаленном сервере - тогда, пользователь получил ключ (некоторый файл) - например, зашифрованной почтой. Он в программе на своей стороне выбирает - установить ключ. И тогда программа по защищенному протоколу лезет на заданный тобой сервер, где хранится база ключей, и проверяет - каков статус этого ключа. А показанная структура - такой может быть, например, структура записи БД на сервере, где хранится информация о ключах.
Вычисляется спец. хэш - функцией. Советую спрева почитать FAQ по криптографии в разделе КБ.
Перечитай посты выше, там тебе указали несколько способов.
Ты игнорировал мой совет почитать фак по криптографии:). Поясню терминологию (в некоторых местах может упрощу). В общем случае - есть подтвержденное и заверенное (скажем, купленное, полученное по наследству или выигранное в лотерею) право пользователя юзать полнофункциональную версию программы. Как это право воплотить и защитить от посягательств? Берем некоторые данные, которые злоумышленнику будет трудно подобрать - это назовем ключ активации, регистрационный код и.т.д. Пользователь получает его в виду ценного письма, на мыло, или еще как то. Далее - установленная программа должна как то проверить, что те данные, которые ввел пользователь, пытаясь зарегаться - корректны, т.е. -
1) Данный ключ является правильным (официальным, оплаченным) ключом.
2)Данный ключ не был до этого кем-то использован.
Теперь как это реализовать. Программа принимает введенный пользовтелем ключ, и отсылает его по защищенному протоколу на сервер регистрации. На СР хранится централизованная, управляемая издателями программы БД. В ней хранятся хэши существующих ключей, и для каждого ключа есть статус - свободен ключ (ввод такого ключа означает успешную регистрацию), или занят .
Для этого мы при при проверке ключа считаем его хэш и смотрим, есть ли такой в БД, и если есть - то каков его статус. Далее по обстоятельствам.
Как понятней-то объяснить?
поскольку использование лицензионного ключа, как это обычно, мне интересно:
- как это обычно решается?
- как может Я генерирую ключ и как он может быть проверен приложением?
- как я могу также избежать публикации ключа в интернете и использования другими, которые не заплатили лицензию (ключ, который в основном не является "их").
Я думаю, что я также должен связать ключ с версией приложения так или иначе, чтобы можно было взимать плату за новые ключи в версиях функций.
что-нибудь еще, о чем я должен думать в этом сценарии?
предостережение: вы не можете запретить пользователям пиратство, но только облегчить честным пользователям делать правильные вещи.
предполагая, что вы не хотите делать специальную сборку для каждого пользователя, а затем:
- создайте себе секретный ключ для продукта
- имя пользователя
- Concatentate имя пользователя и секретный ключ и хеш (например) и SHA1
- распакуйте хэш SHA1 в виде буквенно-цифровой строки. Это индивидуальность "ключ продукта" пользователя
- в программе выполните тот же хэш и сравните его с ключом продукта. Если равны, хорошо.
но, повторяю: это не помешает пиратству
недавно я прочитал, что этот подход не является криптографически очень здравым. Но это решение уже слабое (как само программное обеспечение должно включать секретный ключ где-то), поэтому я не думаю, что это открытие отменяет решение насколько она уходит.
просто подумал, что я действительно должен упомянуть об этом; если вы планируете извлечь из этого что-то еще, будьте осторожны.
существует много способов создания лицензионных ключей, но очень немногие из этих способов действительно безопасны. А жаль, ведь для компаний лицензионные ключи имеют почти такую же ценность, как и реальные деньги.
В идеале вы хотели бы, чтобы ваши лицензионные ключи имели следующие свойства:
только ваша компания должна иметь возможность генерировать лицензионные ключи для ваших продуктов, даже если кто-то полностью реверсирует ваши продукты (что произойдет, я говорю от опыт.) Запутывание алгоритма или скрытие ключа шифрования в вашем программном обеспечении действительно не может быть и речи, если вы серьезно относитесь к контролю лицензирования. Если ваш продукт будет успешным, кто-то сделает ключевой генератор в течение нескольких дней с момента выпуска.
лицензионный ключ должен использоваться только на одном компьютере (или, по крайней мере, вы должны иметь возможность контролировать это очень плотно)
лицензионный ключ должен быть коротким и простым для ввода или диктуйте по телефону. Вы не хотите, чтобы каждый клиент звонил в службу технической поддержки, потому что они не понимают, содержит ли ключ "l" или "1". Ваш отдел поддержки поблагодарил бы вас за это, и у вас будут более низкие расходы в этой области.
Итак, как вы решаете эти проблемы ?
ответ прост, но технически сложен: цифровые подписи с использованием криптографии с открытым ключом. Лицензионные ключи должны быть подписаны "документы", содержащие некоторые полезные данные, подписанные закрытым ключом вашей компании. Подписи должны быть частью лицензионного ключа. Продукт должен проверить лицензионные ключи с соответствующим открытым ключом. Таким образом, даже если кто-то имеет полный доступ к логике вашего продукта, он не может генерировать лицензионные ключи, потому что у него нет закрытого ключа. Лицензионный ключ будет выглядеть так: BASE32 (CONCAT (DATA, PRIVATE_KEY_ENCRYPTED (HASH (DATA)))) Самая большая проблема здесь заключается в том, что классическая алгоритмы открытого ключа имеют большие размеры сигнатур. RSA512 имеет 1024-битную подпись. Вы не хотите, чтобы ваши лицензионные ключи до сотни символов. Одним из наиболее мощных подходов является использование криптографии эллиптических кривых (с осторожными реализациями, чтобы избежать существующих патентов). Ключи ECC как 6 времен более коротких чем ключи RSA, для такой же прочности. Вы можете дополнительно уменьшить размеры подписи, используя алгоритмы, такие как алгоритм цифровой подписи Шнорра (патент истек в 2008 году - хорошо :) )
ну, просто удалите избыточные символы, такие как" 1"," l"," 0"," o " из ваших ключей. Разделите строку лицензионного ключа на группы символов.
простой ответ-независимо от того, какую схему вы используете, ее можно взломать.
Не наказывайте честных клиентов системой, предназначенной для предотвращения хакеров, поскольку хакеры взломают ее независимо.
простой хэш-код, привязанный к их электронной почте или аналогичный, вероятно, достаточно хорош. Идентификаторы на основе оборудования всегда становятся проблемой, когда людям нужно переустановить или обновить оборудование.
при создании ключа не забудьте объединить версию и номер сборки в строку, в которой вы вычисляете хэш. Таким образом, не будет ни одного ключа, который открывает все, что вы когда-либо выпустили.
после того, как вы найдете некоторые ключи или патчи, плавающие в Асталависта.ящик.СК Вы будете знать, что вам удалось сделать что-то достаточно популярным, что кто-то потрудился взломать. Радуйтесь!
кроме того, что уже было сказано.
вы даже не можете использовать аппаратные значения для создания ключа больше. Виртуальные машины теперь позволяют кому-то создавать образ "лицензированной" машины и запускать ее на любой платформе выбирать.
Если это дорогое программное обеспечение, есть и другие решения. Если это не так, просто сделайте это достаточно сложным для случайного хакера. И принять тот факт, что в конечном итоге будут нелицензированные копии.
Если ваш продукт сложен, то своиственные вопросы поддержки будут создавать некоторую защиту для вас.
Он основан на системе" частичной проверки ключа", которая означает, что только подмножество ключа, которое вы используете для создания ключа, должно быть скомпилировано в ваш дистрибутив. Вы создаете ключи самостоятельно, поэтому реализация лицензии уникальна для вашего программного обеспечения.
Как указано выше, если ваш код можно декомпилировать, его относительно легко обойти большинство систем лицензирования.
Я не знаю, насколько подробно вы хотите получить
Они будут держать их от переключения машин после того, как у них есть ключ.
Я использовал Crypkey в прошлом. Это один из многих доступных.
вы можете защитить программное обеспечение только до точки с любой схемы лицензирования.
единственный способ сделать все, что вы просили, это требует доступа в интернет и верификация с сервером. Приложение должно войти на сервер с ключом, а затем вам нужно сохранить детали сеанса, такие как IP-адрес. Это предотвратит использование ключа на нескольких разных машинах. Обычно это не очень популярно у пользователей приложения, и если это не очень дорогое и сложное приложение, оно того не стоит.
вы может просто иметь лицензионный ключ для приложения, а затем проверить клиентскую сторону, если ключ хорош, но легко распространять этот ключ другим пользователям, и с помощью декомпилятора могут быть созданы новые ключи.
на мой взгляд, если вы не используете веб-лицензирование, нет никакого реального смысла защищать программное обеспечение вообще. С головной болью, которую может вызвать DRM, это несправедливо по отношению к пользователям, которые на самом деле заплатили за это.
Я твердо верю, что только система лицензирования на основе криптографии с открытым ключом является правильным подходом здесь, потому что вам не нужно включать в свой исходный код необходимую информацию, необходимую для генерации лицензии.
в прошлом, я использовал библиотека лицензирования Treek много раз, потому что он заполняет эти требования и предлагает действительно хорошую цену. Он использует ту же защиту лицензии для конечных пользователей и себя, и никто не взломал до сих пор. Вы также можете найти хорошие советы на сайте, чтобы избежать пиратства и взлома.
невозможно полностью предотвратить пиратство программного обеспечения. Вы можете предотвратить случайное пиратство, и это то, что делают все лицензионные решения.
заблокированное лицензирование узла (машины) лучше всего, если вы хотите предотвратить повторное использование лицензионных ключей. Я использую Cryptlex около года для моего программного обеспечения. У него есть свободный план также, Так что если вы не ожидаете слишком много клиентов, вы можете использовать его бесплатно.
Как и некоторые другие упомянутые, я огромный противник враждебности к клиентам по умолчанию-то, что индустрия лицензирования печально известна. Поэтому я расширю хорошее решение для вашей проблемы, что также предлагает хороший клиент UX.
для начала вы упомянули, что у вас есть "ограниченная" версия вашего программного обеспечения, которую вы используете, чтобы попытаться преобразовать клиентов в "обновление" для дополнительных функций. Так что вы ищете лицензии для вашего продукта, например, клиент может приобрести лицензию на функция-X или особенность-Y.
Я построил кейген С учетом этого типа лицензирования. Keygen-это лицензионный REST API, который позволяет управлять учетными записями пользователей, лицензиями, а также отслеживать использование/ассоциации машин.
что бы я сделал, это настроить 2 типы лицензий (a политика в пределах Keygen) где одно основание политика для ограниченной бесплатной версии, а другая-политика для платной версии.
Я не уверен, что вы используете для платежей, но предположим, что вы используете что-то вроде Stripe (довольно стандартное в настоящее время), которое предлагает веб-перехватчиков. Keygen также имеет webhooks (используете ли вы его или нет, все это по-прежнему применимо). Вы можете интегрировать Keygen, чтобы поговорить с вашим поставщиком платежей, используя веб-крючки с обеих сторон (подумайте: customer.created ->создать базовую лицензию для клиента, license.created - >поручите клиента для новой лицензии).
таким образом, используя webhooks, мы можем автоматизировать создание лицензий для новых клиентов. Итак, как насчет проверки лицензии в самом приложении? Это можно сделать различными способами, но самый популярный способ-потребовать от вашего клиента ввести длинный лицензионный ключ в поле ввода, которое вы можете проверить; я думаю, что это Грозный способ обработки проверки лицензии в вашем приложении.
почему Я так думаю? Ну во-первых, вы требуете, чтобы ваш клиент вводил утомительно длинный лицензионный ключ, предназначенный для потребления машины, и во-вторых вы требуете, чтобы вы и ваш клиент отслеживали указанный утомительно длинный лицензионный ключ.
хорошо, так какая альтернатива? Я думаю, что лучшая альтернатива делает то, что все ваши клиенты привыкли: позволяет им создать учетную запись для вашего продукта с помощью электронной почты / пароля. Тогда вы можете свяжите все их лицензии и машины С этой учетной записью. Поэтому теперь вместо ввода лицензионного ключа они могут просто войти в систему, используя свои учетные данные.
какое преимущество это дает? во-первых, он избавляется от необходимости для вас и ваших клиентов, чтобы отслеживать лицензионные ключи, поскольку все это обрабатывается за кулисами внутри их учетной записи пользователя и главное: Теперь вы можете предложить своим клиентам самообслуживание лицензия и активация машины! т. е. поскольку все их лицензии и машины связаны с их учетной записью пользователя, вы можете предложить им приобрести лицензию, когда они запускают ваше приложение на непризнанной машине.
теперь на проверку лицензии: всякий раз, когда ваш клиент входит в ваше приложение со своей электронной почтой/паролем, вы можете запросить их учетную запись пользователя для лицензий, которыми они владеют, чтобы определить, могут ли они использовать функция-X или особенность-Y. И так как ваше приложение теперь самообслуживание, вы можете позволить своим клиентам купить дополнительные функции прямо из вашего приложения!
Итак, мы ввели Т автоматизации нашей системы лицензирования, мы можем лицензировать отдельных особенности (т. е. ограниченная и полная версия), мы предложили высокий UX для наших клиентов и мы также разрешали одну из самых больших причин для запросы поддержки:восстановление лицензионного ключа.
в любом случае, это долго, но, надеюсь, это поможет кому-то!
Я один из разработчиков за Cryptolens платформа лицензирования программного обеспечения и работает над системами лицензирования с 14 лет. В этом ответе я включил несколько советов, основанных на опыте, приобретенном за эти годы.
лучший способ решить эту проблему-настроить сервер лицензионных ключей, который будет вызывать каждый экземпляр приложения для проверки лицензионного ключа.
преимущества сервера лицензионных ключей
в преимущества лицензионного сервера ключей в том, что:
- вы всегда можете обновить или заблокировать лицензионный ключ с немедленным эффектом.
- каждый лицензионный ключ может быть заблокирован на определенное количество машин (это помогает предотвратить публикацию лицензионного ключа в интернете для других пользователей).
соображения
хотя проверка лицензии онлайн дает вам больше контроля над каждым экземпляром приложения, подключение к интернету не всегда присутствует (особенно если вы нацелены на более крупные предприятия), поэтому нам нужен другой способ выполнения проверки лицензионного ключа.
решение заключается в том, чтобы всегда подписывать ответ лицензионного ключа с сервера, используя криптосистему с открытым ключом, такую как RSA или ECC (возможно, лучше, если вы планируете работать на встроенных системах). Ваше приложение должно иметь только публичный ключ для проверки ответа лицензионного ключа.
таким образом, если нет подключения к интернету, вы можете использовать вместо этого предыдущий ответ лицензионного ключа. Обязательно сохраните оба дата и машина идентификатором в ответе и проверьте, что он не слишком старый (например. вы разрешаете пользователям находиться в автономном режиме не более 30 дней и т. д.) И что ответ лицензионного ключа принадлежит правильному устройству.
защита секретных алгоритмов
I в большинстве случаев цель любого решения для лицензирования программного обеспечения-помочь честным людям быть честными (т. е. честные пользователи, которые готовы платить, не забывают платить после окончания пробной версии и т. д.).
тем не менее, у вас все еще может быть некоторый код, который вы никоим образом не хотите просочиться в общественность (например. алгоритм для прогнозирования цен на акции и т. д.). В этом случае единственный способ - создать конечная точка API что ваше приложение будет звонить каждый раз, когда метод должен быть выполненный. Для этого требуется подключение к интернету, но это гарантирует, что ваш секретный код никогда не выполняется клиентской машиной.
реализация
Если вы не хотите реализовать все самостоятельно, я бы рекомендовал взглянуть на в этом уроке (часть Cryptolens)
ваше программное обеспечение по-прежнему будет взломать, но для случайного взломщика вполне может быть достаточно, чтобы отложить их, и эти простые шаги также предотвратят извлечение кода и повторно используется.
Новый файл лицензии для сетевого сервера необходимо создавать только в следующих случаях:
- получение или продление лицензии по подписке;
- добавление подписок для программы с сетевой лицензией;
- добавление программ на сервер сетевых лицензий;
- добавление лицензий к новой версии программы по сетевой лицензии;
- смена сервера сетевых лицензий;
- реконфигурация сервера сетевых лицензий.
Сбор сведений о сервере лицензий
Для создания файла лицензий необходимо иметь следующие сведения.
- В конфигурации с одним сервером: имя узла сервера и его MAC-адрес (двенадцатизначный идентификатор узла)
- В конфигурации с резервными серверами: имена узлов серверов и MAC-адреса главного сервера и двух резервных серверов
- В конфигурации с распределенными серверами:
- количество серверов;
- имена узлов и MAC-адреса всех серверов;
- количество подписок для каждого сервера.
Поиск имени и MAC-адреса узла с помощью утилиты LMTOOLS в ОС Windows
- Войдите в систему с правами администратора на локальном компьютере, нажмите «Все программы» > Autodesk > Network License Manager > LMTOOLS Utility.
- В окне LMTOOLS перейдите на вкладку Systems Settings (Настройки системы).
- Найдите поле Computer/Hostname (Компьютер/Имя хоста). Это окно содержит имя узла.
- Найдите поле Ethernet Address (Адрес Ethernet узла сервера). Двенадцатизначный адрес идентификатора узла, также называемый MAC-адрес.
Поиск имени и идентификатора узла с помощью командной строки в ОС Windows
- Откройте командную строку Windows.
- Введите ipconfig /all. Появится список данных конфигурации.
- В разделе «Настройка протокола IP для Windows» найдите имя узла и запишите его.
- В разделе «Ethernet-адаптер» > «Подключение по локальной сети» введите MAC-адрес без дефисов. MAC-адрес — это двенадцатизначный идентификатор узла.
Поиск имени и идентификатора узла в macOS или Linux
- Откройте окно Терминала.
- Перейдите в папку, в которой установлен файл .lmutil.
- Получите имя узла, введя следующий запрос:
<prompt>./lmutil lmhostid -hostname - Получите идентификатор (MAC-адрес) узла, введя следующий запрос:
./lmutil lmhostid
Создание файла лицензии в учетной записи на портале Autodesk Account
Для создания сетевой лицензии необходимы права администратора. Для программы, на которую требуется сетевая лицензия, также необходимо приобрести подписку с многопользовательским доступом. Если используются разные программы и требуется создать файл лицензии для них всех, это можно сделать для одной программы за раз.
Создание файла лицензии
Сохранение файла лицензии
Получив файл лицензии, сохраните его в папке, где установлен Network License Manager. Имя файла лицензии может быть любым, но его расширение должно быть .lic. Ниже приводятся примеры папок с файлами лицензий для различных операционных систем.
- Windows:C:\Autodesk\Network License Manager\Licenses
- macOS:/Users/<user>/local/flexnetserver
- Linux:/opt/flexnetserver
Подтверждение правильности файла лицензии
После сохранения файла лицензии подтвердите, что он содержит верную информацию. Файл лицензии работает только на компьютере c MAC-адресом, указанным при получении лицензии.
Сбор информации о сервере сетевых лицензий, создание файла лицензий и сохранение его на локальном сервере.
Целевая аудитория Администратор Решение о необходимости создания нового файла лицензий
Новый файл лицензий для сетевого сервера создается в следующих случаях:
- Приобретение или продление подписки на лицензию
- добавление мест для продукта по сетевой лицензии;
- добавление новых продуктов на сервер сетевых лицензий;
- добавление лицензий к новой версии продукта по сетевой лицензии;
- смена сервера сетевых лицензий;
- изменение сведений о конфигурации сервера сетевых лицензий.
Сбор сведений о сервере лицензий
Для создания файла лицензий необходимо иметь следующие сведения.
- В конфигурации с одним сервером — физический адрес и имя узла сервера.
- В конфигурации с резервными серверами — имена узлов серверов и физические адреса главного сервера и двух резервных серверов.
- В конфигурации с распределенными серверами:
- количество серверов;
- имена узлов и физические адреса всех серверов;
- количество рабочих мест для каждого сервера.
Если используются серверы Windows, для поиска имени узла можно запустить утилиту LMTOOLS, которая поставляется вместе с программой Network License Manager. Если используются серверы macOS или Linux Server, для поиска имени узла используйте команды терминала.
Прим.: Дополнительные сведения о поиске имени узла и физического адреса см. на странице Поиск физического адреса и имени хоста.Создание файла лицензии
Обычно при приобретении новых рабочих мест для программного обеспечения Autodesk каждое рабочее место связано с учетной записью на портале Autodesk Account. В некоторых случаях Autodesk отправляет серийный номер и ключ продукта, которые необходимы для создания файла лицензий. Кроме того, эти сведения можно найти в учетной записи на портале Autodesk Account.
Создать сетевую лицензию в учетной записи на портале Autodesk Account могут администраторы учетной записи, ответственные за подписку и программные координаторы. Для программы, на которую требуется сетевая лицензия, также необходимо приобрести подписку с многопользовательским доступом. Чтобы создать файл лицензии в учетной записи на портале Autodesk Account, выполните следующие действия.
Сохранение файла лицензии
Получив файл лицензии, сохраните его в папке, где установлен Network License Manager. Имя файла лицензии может быть любым, но его расширение должно быть LIC. Ниже приводятся примеры папок с файлами лицензий для различных операционных систем.
Windows: C:\Autodesk\Network License Manager\Licenses
Подтверждение правильности файла лицензии
После сохранения файла лицензии подтвердите, что он содержит верную информацию. Файл лицензий работает только на компьютере, который имеет физический адрес, указанный при получении лицензии.
- Откройте файл лицензии. В ОС Windows используйте программу "Блокнот". Для macOS используйте редактор TextEdit. В Linux используйте аналогичный текстовый редактор. Не используйте Microsoft Word или другой текстовый редактор. Эти программы могут вызвать ошибки форматирования или изменить файл.
- Убедитесь в том, что физический адрес соответствует адресу сервера. В первой строке файла лицензий, начинающейся со слова SERVER, отображается имя узла и физический адрес. В случае их несоответствия запросите новый файл лицензии с нужными сведениями.
Объединенные файлы лицензий
Если вам необходим объединенный файл лицензий, который содержит лицензии для разных программных продуктов, на портале Autodesk Account можно создать комбинированный файл лицензий для каждого сервера. Полученный файл лицензий содержит количество рабочих мест для каждого продукта с сетевым лицензированием, независимо от плана подписки для этого продукта.
При необходимости для создания объединенного файла лицензий можно использовать традиционный метод. Этот метод включает в себя загрузку файлов лицензий для отдельных продуктов с веб-сайта Autodesk Register Once и объединение их в один файл лицензий вручную. Чтобы использовать этот метод, необходимо выполнить следующие действия.
Читайте также: