Защита исходного кода: Как защитить исходный код стартапа от воровста программистом, которые его пишет?

Как обезопасить исходники своего python-приложения / Хабр

Рано или поздно все python-разработчики стают перед выбором: отдать заказчику приложение в исходниках или скрыть их. И вот во втором случае у многих (особенно недавно знакомых с этим прелестным языком) начинаются проблемы: поиск по гуглу, как правило, ничего не дает, идей никаких (или все бредовые).

И что же делать в таком случае?

Первой мыслью было отдавать pyc-файлы. Тогда я ещё не вникал в то, что это такое на самом деле. После нескольких часов проведённых в поисках ответов чем это грозит был сделан единственно возможный вывод: вариант не пройдет. Для python < 2.7 «декомпиляторов» полно бесплатных, а 2.7 и выше за сравнительно небольшие деньги обещают выдать в виде исходных кодов. Да ещё и эта тулза, с которой я за считанные мгновения получил свой код один-в-один.

Вариант сборки в бинарник показался достаточно заманчивым. Вот только, как оказалось, все сборщики (ниже я приведу пример cx_Freeze) фактически только и делают что пакуют . pyc в архив, то есть абсолютно не защищают исходные коды.

А потом меня осенило.

Предложим у нас есть проект проект с такой структурой (это всего лиш пример):

TestModule/__init__.py

TestModule/Config.py

ui/__init__.py

ui/mainwindow.py

ui/loginwindow.py

main.py


Тут сразу хотелось бы отметить два момента:

1. В файле main.py у нас должен быть фактически только вызов главного модуля, если же там что-то большее — желательно оформить это в отдельный модуль
2. Файлы __init__.py желательно чтоб были вообще пустые.

Делаем несколько простых манипуляций:

1. $ sudo apt-get install cython
2. Создаем в корне проекта файл compile.py:

   from distutils.core import setup
   from distutils.extension import Extension
   from Cython.Distutils import build_ext
   
   ext_modules = [
       Extension("TestModule.Config", ["TestModule/Config. py"]),
       Extension("ui.mainwindow", ["ui/mainwindow.py"]),
       Extension("ui.loginwindow", ["ui/loginwindow.py"]),
       ]
   
   setup(
       name = 'Test App',
       cmdclass = {'build_ext': build_ext},
       ext_modules = ext_modules
   )
   

3. Там же (в корне проекта) выполняем
   $ python compile.py build_ext --inplace
4. теперь можем удалить все файлы в подкаталогах кроме *.so и __init__.py

После проверки на работоспособность все должно работать точно так же как и прежде.

Вот и все, исходники теперь точно никто не прочитает. Правда отдавать приложение пока рано, заказчик ведь не захочет устанавливать и настраивать питон со всеми использованными вами модулями. Потому собираем все в «пакет»:

1. $ sudo apt-get install cx-freeze
2. В корне проекта создаем файл pack.py:

   from cx_Freeze import setup, Executable   
   
   setup(   
       name = "Test App",   
       version = "0. 1",   
       description = "test",   
       executables = [Executable("main.py")])  
   

3. $ python pack.py build
4. Копируем «свои» папки из папки проекта в build/exe.linux-x86_64-2.7
5. Пробуем запустить полученный бинарник и, если надо, копируем недостающие библиотеки (в моем случае это был PyQt)

После проверки можно отдавать пакет заказчику.

P.S. Надеюсь кому-то это простое how-to сэкономит столько же времени, сколько могло бы сэкономить мне.

криптографическая защита программного кода — «Хакер»

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

Исследователи из Center for Encrypted Functionalities работают над методами математической обфускации кода. В некоторых приложениях это действительно помогает улучшить безопасность системы, поскольку в случае очевидных багов у злоумышленника теперь нет возможности посмотреть исходники и сразу же эксплуатировать найденные уязвимости. Кроме того, надёжная защита кода нужна в тех случаях, если код содержит важные торговые секреты фирмы. Это могут быть алгоритмы, над созданием которых авторы работали десятилетиями и не хотят ни с кем делиться, такие как алгоритмы в системе рекомендаций Amazon.

Обфускатор добавляет дополнительный этап на этапе компиляции кода. Вместо обычной компиляции здесь происходит обработка обфусцирующим компилятором, а для выполнения программы требуется пропустить результат через программу-верификатор, написанную на ассемблере, которая складывает кусочки «паззла» воедино.

Таким образом, если посторонний изменил фрагменты программы, то она не пройдёт проверку и не будет запущена на исполнение.

По мнению независимых экспертов, работа специалистов из Center for Encrypted Functionalities пока не готова для практического использования. Но это доказательство того, что идея имеет право на жизнь, пусть и не для всех видов программных приложений.

Криптографы давно обсуждали идею идеальной обфускации в «чёрном ящике», а в 2001 году вышла научная работа, которая доказывает невозможность такого шифрования без получения информации (ключа шифрования) извне. Тем не менее, работа оставила теоретическую возможность создания «неидеальной обфускации», когда расшифровка обфусцированного кода потребует слишком большого количества ресурсов у взломщика. Исследования в этой области продолжаются.

Приемы защиты исходных текстов и двоичного кода | Открытые системы. СУБД

Крупные производители тиражного программного обеспечения отказались от защиты своих продуктов, сделав ставку на их массовое распространение. Пусть лицензионные копии приобретает лишь несколько процентов пользователей, но, если число этих копий измеряется миллионами, даже считанные проценты выливаются в солидную сумму, с лихвой окупающую разработку. Однако для небольших коллективов и индивидуальных программистов такая тактика неприемлема. Им необходимо предотвратить «пиратское» копирование своего продукта.

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

Противодействие изучению исходных текстов

Вообще говоря, открытость исходных текстов — понятие расплывчатое. Автор статьи [1] справедливо задается вопросом: «Является ли бинарная программа в 1 Kбайт более открытой, чем миллион строк исходников без адекватной инфраструктуры и документации?» В самом деле, мало иметь исходный текст — в нем еще предстоит разобраться. Достаточно удалить все или, по крайней мере, большую часть комментариев, дать переменным и функциям бессмысленные, ничего не говорящие имена, как в программе не разберется и сам автор. А наличие и полнота комментариев к исходному тексту в контракте, как правило, не оговаривается. Получается, что контракт может быть формально выполнен, а предоставленный заказчику исходный текст практически бесполезен. «Практически» не означает «полностью»: такой простой прием не позволит обеспечить абсолютную защиту.

Воспрепятствовать анализу можно отделением, абстрагированием алгоритма от языка реализации. Например, реализовать критичные для раскрытия компоненты на машине Тьюринга [2], а ее поддержку обеспечить на целевом языке. Уровней абстракции может быть несколько — чем их больше, тем труднее осуществлять анализ. Помимо машины Тьюринга для этой цели подходят стрелка Пирса, сети Петри и т.д. Такой подход дает превосходный результат, но требует глубоких математических знаний и значительных накладных расходов — программировать на машине Тьюринга намного сложнее, чем на ассемблере. (Отдельный вопрос — эффективность полученной программы. — Прим. ред.) Для многих проектов это неприемлемо, поэтому приходится использовать другие приемы.

Динамическое ветвление

Программу, состоящую из нескольких сотен тысяч строк, невозможно рассматривать как простую совокупность команд. На таком уровне детализации «за деревьями леса не видно». Сначала необходимо проанализировать взаимосвязь отдельных функций друг с другом, выделить интересующие фрагменты и лишь затем изучать реализацию самих функций. Чем выше степень дробления программы, тем труднее анализ. Элементарные функции, состоящие из десятка строк, сами по себе дают мало информации. Для формирования целостной картины необходимо рассмотреть вызывающий их код, поднимаясь по иерархии вызовов до тех пор, пока не удастся реконструировать весь алгоритм целиком или, по крайней мере, охватить его ключевой фрагмент. Чтобы построить дерево вызовов, нужно уметь отслеживать перекрестные ссылки в обоих направлениях: определять, какой функции передается управление данным вызовом, и, наоборот, находить все вызовы, передающие управление данной функции.

Этому легко воспрепятствовать, воспользовавшись динамическим ветвлением — т.е. вычислением адреса перехода непосредственно перед передачей управления. Если функция возвращает не результат своей работы, а указатель на следующую выполняемую функцию (результат работы можно возвратить через аргументы, переданные по ссылке), то статический

Защита кода в 1С

Рано или поздно перед профессиональным разработчиком встает задача защиты модулей конфигурации и обработок.

• Какая защита существует?
• Какой способ защиты самый надежный?
• Как выбрать защиту 1С конфигурации и при этом не прогадать?

На эти вопросы отвечу в данном обзоре. Речь пойдет в основном об 1С:8.X

Начну же его с другого вопроса:

Быстрый переход

Зачем защищать код в 1С?

• Разрешить работу только определенной фирме/компании, купившей ваш продукт.
• Ограничить количество работающих пользователей в базе.
• Скрыть «особенные» и уникальные алгоритмы от потребителей или конкурентов.
• Закрыть модули от заказчика до оплаты им разработанного модуля (конфигурации, подсистемы).
• Создать демонстрационную конфигурацию с определенными ограничениями в использовании.
• Скрыть методы обмена с каким-то веб-сервисом, сайтом/CMS.
• Не допустить полной утечки разрабатываемой совместно конфигурации недобросовестными фрилансерами.

Требования, предъявляемые вами к защите конфигурации будут в той или иной мере определять дальнейший выбор.

Какие способы защиты предоставляет 1С:Предприятие стандартно?

• Пароль пользователя к базе и хранилищу конфигурации.
• Роли конфигурации.
• Веб-клиент ограничивает доступ к «Конфигуратору».
• Пароли на текст модуля.
• Поставка без текста модулей (скомпилированный код).

Надежность пароля пользователя

В целом пароль пользователя к базе данных одним из слабых звеньев в защите 1С, поскольку отсутствует обработчик события ошибки ввода. В случае использования простого пароля существует опасность его подбора полным перебора (методом brute force/»грубой силы»).

Из этого вытекают важные правила:

• у пользователя имеющего полные права никогда не должно быть простого пароля.
• такой пароль не следует хранить в командной строке запуска 1С.
• у рядовых пользователей пароли должны меняться регулярно, данные должны иметь максимальное ограничение видимости даже на просмотр.
• можно убрать пароли пользователя привязав их к пользователю операционной системы, в случае если используются надежные операционные системы с политикой частой смены.
• сокрытие пользователя из списка незначительно повышает защиту (при очевидных именах).
• система предупреждает, если пароль «простой» 

В случае физического доступа к базе данных (при файловом или клиент-серверном вариантах) (для файлового, например при работе в режиме терминального доступа или с открытым доступом по сети, 1С без права на запись работать не может) у злоумышленника появляется возможность не просто повредить базу, но и сбросить механизм проверки паролей (как-будто пользователи вообще отсутствуют).

В данном случае рекомендуется создание механизма дополнительной проверки такого входа. На новых формата базы 8.3 не получилось проверить работоспособность данных средств (но не следует считать, что не существует новых) 

Данный взлом работает не совсем корректно, так как блокирует создание новых пользователей — база становится не вполне полноценной.

Если вам требуется все-таки сбросить пароль по вполне оправданной причине, следует после этого перенести данные в новую чистую базу и создать пользователей в ней.

Для sql баз возможен перенос таблиц пользователей из другой (исправной) базы.

В связи с перечисленными выше особенностями защиты паролями пользователей можно выделить  ряд правил.

Правила, повышающие парольную защиту

• в больших компаниях рекомендуется использовать клиент-серверный вариант, даже при достаточной производительности — для улучшения степени защищенности (серверная часть работает с базой по своему каналу).
  прямой доступ к SQL базе должен быть также ограничен надежным паролем, внешний доступ к базе закрыт.
• для уволенных сотрудников доступ должен сразу блокироваться, ни каких передач паролей приемникам.
• при длительных отпусках, командировках, болезнях доступ к базе должен приостанавливаться.

Пароль к хранилищу конфигурации.

Также имеет низкую защищенность, особенно при файловом хранилище.

• Рядовые программисты не должны иметь административных паролей к хранилищу. При увольнении, уходе в отпуск доступ должен блокироваться.
• Расположение хранилища это обычная файловая база, поэтому доступ должен быть ограниченным, лучше использовать для этого сервер хранилища. При работе с хранилищем не ведется журнал доступа к данным: только процесс захвата и помещения.
• Поэтому получив данные для подключения, злоумышленник может полностью скачать конфигурацию: а также любую доступную ее версию (отследить процесс разработки).
• Использование хранилища при разработке нового коммерческом продукта большой группой не желательно, либо следует задавать пароли для всех важных модулей (подробнее об этом ниже). Как вариант использовать хранилище только для версионного контроля.
• Это усложнит механизм взаимодействия.

Технология может быть такой:

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

Доступ к «Конфигуратору»

Конфигуратор работает в режиме толстого клиента, поэтому получить конфигурацию через браузер или веб-сервер невозможно, если не используется режим обновления платформы и конфигурации через веб.

Получить же доступ к данным вполне возможно при использовании не шифрованного подключения — есть случаи перехвата паролей по незащищенному каналу.

• Рекомендуется использовать https.
• Рекомендуется использовать vpn сети для удаленных рабочих мест/филиалов.

Пароли на текст модуля 1С

Устанавливается в «конфигураторе» в меню «Текст/Установить пароль».  

Данная защита образует парадокс:

• Никто не берется взламывать пароль, так как используется надежное шифрование; по крайней мере в открытом доступе информация о таких случаях отсутствует.
• Если модуль идет без текста (поставка без текста), то оригинал его вообще не увидеть. (Меню «Конфигурация/Поставка/Настройка поставки») 
• Для корректного исполнения даже закрытого/отсутствующего модуля «1С» хранит модуль в формате байт-кодов(также называемых пи-кодами), для которых некоторые умельцы (например, Валерий Агеев/AWA,Samuray) создали работающие декомпиляторы данных модулей. 

Первый — самый распространенный, максимально доработанный под реальные условия, второй даже найти трудно, но текст его открытый — что будет интересно. (Данные разработки не могу рекомендовать для скачивания с моего или иного сайта, так как они нарушают авторские права, как минимум фирмы «1С»).

В результате их работы получается тексты в которых отсутствуют комментарии, изначальное форматирование, но этого достаточно, чтобы понять алгоритм и логику закрытого модуля.

Как они работают:
Через средства чтения внутреннего формата файлов 1С, они получают доступ к данным модулям и далее разбирают его собственными алгоритмами.

Не стоит считать, что это единственные декомпиляторы на рынке: как говорится оправданность взлома определяется ценой, которую за это готовы заплатить. Если конфигурация дорога и востребована, ее будут всегда пытаться взломать или обойти ее  защиту.

Получается защитить модуль никак нельзя?

Оказывается для байт-кода также возможна «обфускация» (запутывание) открытого кода, этим сохраняется исходная работоспособность, но вышеизложенные декомпиляторы обычно уже не могут раскрыть данные тексты.

Поэтому появились решения для защиты модулей:

• wiseadvice — защита конфигураций (комплексное решение с обфускацией и привязкой к ключам), подробно можете ознакомится https://wiseadvice-it.ru/programmy-1s/nashi-resheniya/
• awa-обфускатор (в открытом виде не распространяется).

Приведу (перескажу своими словами) информацию, которую урывками собирал с различных ресурсов.

Об wiseadvice:

• Первые версии до 2.0 включительно были достаточно быстро «распарсены» (обфускация не достаточно сильная, автор это признал).
• Разработчик говорит, что у него есть еще варианты усложнения обфускации (получается он их внедряет не сразу, а по мере, конечная версия не всегда максимально защищенная?).
• Валерий Агеев имеет не распространяемую публично версию  декомпилятора (которая открывает текущую защиту wiseadvice).
• Если возможность алгоритма позволяет поместить важные данные в hasp-ключи, это бесспорно улучшить защиту, но при наличии ключа и такие конфигурации отучают. Если ваше решение конечное (не динамически меняющееся), то скорее всего оно будет уязвимо.
• «Непонятки» с ценой: на инфостарте старая версия продается по 12500, на одном сайте их сайте: цена от 15000 , на оригинальном сайте продукта 3. 0.8 за 17500, раньше цена была 10000 (за 3-4 года выросла, но выросла ли настолько защищенность).
• Вроде пишут, что все просто и понятно, но на демо-версии пришлось потратить некоторое время, чтобы получить окончательный результат (так как версия ограниченная, полностью проверить не получается). Интерфейсно, согласен, очень удобное решение, но требования создать определенные имена функции, ошибки которые не понятные в процессе. Это придирки, может всё из-за демо-версии.
• Нельзя использовать «Выполнить\Вычислить» — с чем связано не понятно.
• Ключи следует покупать отдельно, и они достаточно дороги для простых решений.
• Оформляются документы на покупку решения (это может быть определяющим).

Набор данных фактов склонил меня к покупке второго обфускатора:

• привязка к ключам мне пока не нужна, в целом можно использовать их самостоятельно,
• можно скомбинировать решения (есть и такие случаи: используются библиотеки от первого, обфускация второго),
• цена его на момент покупки 7000 (достаточно дешево, чтобы просто попробовать),
• единственным минусом является то, что обфусцируются все защищенные модули без отбора.

Важно понимать, что при любой записи текста модуля его обфускация снимается: следует повторить ее процедуру.

Код модуля должен иметь как можно больше кода — это повышает надежность обфускации. В Wiseadvice даже есть встроенная проверка на это.

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

Следует переписать код продукта под такую стратегию:

• самое важное хранится в модулях.
• эти процедуры должны быть максимально проверены и отлажены, покупатель не сможет их исправить самостоятельно.

Существует риск, что 1С поменяет формат внутренних файлов или сделает алгоритм таких кодов неработоспособными, следует создавать тесты своих решений, для отладки (это гипотетические рассуждения).

Зачем нужны ключи в защите:

• организация демо версии /времени использования;
• ограничение работы по количеству пользователей;
• ограничение функционала;
• скрыть важные данные в ключе (небольшие объемы).

Внешние компоненты, как еще один вариант защиты:

Вынос исполнения кода, выполнение алгоритмов во внешние компоненты.

• Это не тиражные решение, может быть платформо-зависимым в отличии обускации п-кода.
• Достаточно много таких примеров на инфостарте.

Оценить надежность, пока не появится готовый продукт невозможно.

Почитать по теме защиты:

Книга знаний: Защита исходного кода конфигураций 

Можно дурачить всех все время, — при условии, что реклама ведется правильно, а расходы на нее достаточно велики.

— Джозеф Левин

Защита HTML от копирования | KV.by

Зачем это?

Труд веб-мастера нельзя назвать
совсем уж благодарным. Речь идет
даже не о деньгах, которые он
получает после завершения работы,
а, скорее, о вложении времени и
труда при создании сайтов.
Существует иная категория
«мастеров» — это те, которые
берут исходный код понравившегося
готового сайта, «исправляют»
его и выдают результат за плод
своих бессонных ночей. Не от того ли
сайты так похожи друг на друга?

Понятно, что человек,
придумывающий оригинал,
затрачивает гораздо больше сил, а
поэтому вправе заявить права на
свою интеллектуальную
собственность. Если права
музыкантов как-то еще защищаются
(уж сколько Napster натерпелся от
этого!), то веб-мастерам приходится
сражаться самостоятельно.

Возникает сразу встречный вопрос:
где же еще начинающим мастерам
учиться, как не на работах
профессионалов? Вот мнение Артемия
Лебедева, основателя одноименной
студии: «Я нормально отношусь к
тому, что мои работы берут за основу
другие дизайнеры — в конце концов,
не все в состоянии самостоятельно
придумывать что-то свое. Я привык.
Но когда передирают практически
каждый байт, включая
необязательные фрагменты кода, —
оставлять подобное поведение без
внимания нельзя.» Получается, что
«можно, если осторожно». Но не
всем веб-мастерам понравится такой
вариант отношения к своему
творчеству — кому-то хочется
полностью защитить свои работы от
копирования. Именно для них и
создана утилита HTML Guard.

Как это происходит

HTML Guard обладает рядом
замечательных возможностей,
которые защитят html-код от
копирования. Красивые слова, но что
это означает на практике? Очень
просто — случайному посетителю НЕ
удастся:

• скопировать содержимое
  страницы и поместить его в
  буфер обмена;
• распечатать страничку;
• скопировать изображения или
  ссылки, используя правую
  кнопку мышки. На каждую такую
  попытку могут выдаваться
  сообщения типа «Спасибо за
  ваш правый клик» или «Эй,
  приятель! Возьми учебник в руки
  и сделай что-нибудь сам».
  Подобные подсказки могут
  порядком надоесть, особенно
  если пользователь пытается
  двадцать пятый раз вызвать
  контекстное меню, поэтому их
  вывод лучше отключать.

В программе возможны два способа
защиты. Первый — непосредственное
кодирование с использованием Java
Script. С его помощью содержимое тегов
<Body></Body> преобразовывается в
малопонятный набор символов. В
получаемый код вставляется также и
сам ключ (скрипт), при выполнении
которого браузер «понимает»,
как правильно отобразить страницу.
В результате получается
обыкновенная страница, которую
можно только просмотреть, и не
более того.

Второй подход — из исходника
убираются все пробелы и знаки
переноса на новую строку. После
этого остаются одни сплошные
строки символов. Однако этот метод
не является надежным: если вручную
и придется попотеть, делая текст
читаемым, то «продвинутые»
html-редакторы смогут разобраться с
ним без труда.

Обратный способ — к началу
исходного текста добавляются
пустые строки. После этого в самом
верху видна надпись «Исходный
текст недоступен» (или еще что-то
в этом роде), а сам код страницы
скрывается гораздо ниже. Этот
простенький способ работает с
одним из двух названных методов
шифрования. Следует также помнить
про увеличивающийся размер файла с
каждой добавляемой строкой.

А как насчет надежности?

На сайте программы находится
предупреждение «HTML Guard не может
гарантировать даже одного процента
надежности». Удивлены? Конечно,
использование в качестве защиты
скриптов — это что-то вроде замка с
ключом: кто знает, тот откроет. Но
даже в этом случае надо будет
приложить немало усилий. Ну а кто не
знает Java Script, тот и подавно не
«передерет» html-страницу.

Таким образом, HTML Guard защитит как
html-код, так и содержимое страницы от
«быстрого» копирования. Еще
одна цитата с сайта: «99 процентов
интернетчиков эта защита
остановит».

Скачать эту условно бесплатную
программу можно с www.aw-soft.com/hgsetup.exe.

Павел БАДЯЛИК,
[email protected]

Защита конфигураций 1С, отчетов и обработок. Как защитить программный код 1с?

Очень часто у программистов 1С возникает желание каким – то образом защитить свою конфигурацию 1С, обработку или отчет от редактирования и плагиата. Для  решения такой задачи существует несколько способов, отличающихся как по степени защиты, так и по трудоемкости. И сегодня мы с вами рассмотрим наиболее популярные, а заодно поговорим про защиту программного кода 1с в целом.

1 способ. Защита кода 1с с помощью пароля (штатный способ)

Это самый простой способ защиты программного кода 1С. С его помощью можно защитить только модули объектов,  так как для модулей форм такой опции нет. Подробно про виды программных модулей я рассказывал в этой статье. 

Для защиты выбранного модуля объекта необходимо его открыть, а затем в меню выбрать Текст – Установить пароль.

Для повышения эффективности данного способа рекомендуется перенести (или сразу размещать) большую часть программного кода из модулей форм в модули объектов. Не забудьте протестировать работоспособность объекта после переноса кода.

2 способ. Исключение текстов модулей объектов из поставки конфигурации (штатный способ)

С помощью данного штатного способа можно добиться, чтобы модули объектов вообще не содержали никакого программного кода. Как и в предыдущем случае, данным методом нельзя скрыть  программный код модулей форм. Поэтому, настоятельно рекомендуется переносить большую часть программного кода из модулей форм в модули объектов.

Для работы с поставкой конфигурации выполняем следующие действия:

1) Прежде всего, требуется настроить саму поставку, исключив тексты требуемых модулей объектов и при необходимости запретить изменения отдельных или всех объектов конфигурации.

Для этого переходим в меню Конфигурация – Поставка конфигурации – Настройка поставки.

В открывшемся окне правил поставки мы для каждого объекта конфигурации можем разрешить или запретить изменения, а также скрыть текст программных модулей (снять галку «Включать поставку исходный текст модулей объектов»).

2) В свойствах конфигурации необходимо указать версию и Поставщика. Затем сохранить все изменения с помощью кнопки «Обновить конфигурацию» или горячей клавишей F7.

3) Создаем файл поставки Конфигурация – Поставка конфигурации – Создать файл поставки и обновления конфигурации. В результате мы получим .cf-файл нашей конфигурации без текстов программных модулей.

4) Создаем новую конфигурацию и с помощью меню Конфигурация – Загрузить конфигурацию из файла загружаем полученный в 3 шаге наш .cf-файл. В результате мы получим конфигурацию без текстов программных модулей.

3 способ. Запутывание (обфускация) программного кода 1с

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

— удалить все комментарии;
— удалить форматирование, сделать весь код сплошным текстом;
— использовать вперемешку английские и русские названия ключевых слов и функций;
— использовать вперемешку разные регистры в ключевых словах и переменных.

В результате другому программисту будет проще переписать код «с нуля», чем копировать куски из вашей авторской разработке.

Обфускацию можно выполнить как вручную, так и с помощью различных обработок и сервисов. Перед его применением обязательно следует сделать резервную копию информационной базы для того, чтобы потом самому не «копаться» в плохо читаемом коде при внесении изменений в конфигурацию.

Выводы по защите программного кода в 1С

К сожалению, программа 1С слишком популярна, чтобы защиту программного кода, созданного с её помощью, можно было бы считать абсолютно надежной. На сегодняшний день ни один из имеющихся способов защиты, в том числе коммерческие, не дают 100 % защиты. Тем не менее, применение рассмотренных 3 способов в различных комбинациях могут обеспечить приемлемый уровень защиты ваших авторских прав.

С другой стороны самая сильная сторона конфигураций 1С – это их открытость и возможность доработки. И не стоит главное достоинство системы переводить в её недостаток.

Защита исходного кода, запутывание исходников. Решение для кода c ++

Главная> Решения> Защита исходного кода и обфускация

против взлома, реверс-инжиниринга и модификации

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

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

Решения StarForce для защиты исходного кода основаны на ряде проприетарных технологий:

Обфускация C ++ или.Граф алгоритма программы в сети затрудняет понимание алгоритма программы. Обфускация — это процесс, цель которого — усложнить анализ программного кода. Обфускация источников — это программы, реализующие это.

Чтобы усложнить обратный инжиниринг, в продуктах StarForce используются наш собственный язык программирования StarForce P-code и компилятор StarForce. Это лучший способ настроить защиту исходного кода .

Для защиты кода приложения StarForce разработала два решения: StarForce Crypto и StarForce C ++ Obfuscator.

Защита двоичного кода для приложений Windows

Продукт: StarForce Crypto

StarForce Crypto защищает двоичный код приложений на базе Windows от обратного проектирования и модификации, а также скрывает и защищает любые файлы данных приложения, доступные только для чтения, от подделки и модификации

StarForce Crypto рекомендуется для защиты приложений на базе Windows, которые могут распространяться на CD / DVD-дисках, USB-накопителях и через Интернет (включая Steam), от взлома, модификации и обратного проектирования. Используя нашу программу защиты исходного кода , вы можете быть уверены, что ваши продукты защищены от любых третьих лиц.

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

Наше решение для обеспечения безопасности исходного кода поддерживает защиту двоичных (скомпилированных) исполняемых файлов и данных только для чтения.Он также совместим с аппаратными платформами x8632 и x8664.

StarForce Crypto устанавливается через Интернет в любом месте и в любое удобное для разработчика время.

Вы можете дополнительно усилить защиту исходного кода , используя специальную технологию, которая обеспечивает привязку защищенного приложения к CD / DVD-диску, ПК или серверу с помощью других продуктов StarForce.

Защита исходного кода для всех платформ
(Windows, macOS, iOS, Android)

Продукт: StarForce C ++ Obfuscator

Решение предназначено для обфускации (преобразования) исходного кода программ C / C ++ (текстовых файлов) для всех операционных систем.

StarForce C ++ Obfuscator рекомендуется для случаев, когда критически важна защита программного обеспечения от взлома, например, защита ключей DRM или других конфиденциальных данных, которые не должны быть потеряны. Если такое нарушение происходит, оно затрагивает как разработчика программного обеспечения, так и поставщика услуг и может стоить больших денег. Безопасность исходного кода помогает решить эту проблему.

В отличие от StarForce Crypto, этот продукт обеспечивает защиту программного обеспечения, написанного для любой операционной системы (Windows, macOS, iOS, Android), и совместим со всеми аппаратными платформами (процессорами и MCU), что делает его кроссплатформенным продуктом.

Основная особенность решения — поддержка более 30 методов обфускации кода , которые можно включать и выключать независимо друг от друга и настраивать.

Основные методы, которые используются в StarForce C ++ Obfuscator

Расширенные методы

StarForce C ++ Obfuscator — это отдельное решение, которое устанавливается на стороне клиента. Это эксклюзивный продукт исходного кода для обфускации StarForce , который содержит уникальные алгоритмы обфускации.

Этот продукт является одним из лучших обфускаторов на рынке благодаря большому набору методов защиты исходного кода и длительной эксплуатации без компрометации.

Заинтересованы в решениях для защиты исходного кода StarForce?
Отправьте нам заявку на бесплатное тестирование!

Защита исходного кода в Studio 5000 Logix Designer

Во время работы с заказчиком над недавним проектом RSLogix 5000 (теперь называемым Studio 5000) возникла необходимость защитить некоторый частный исходный код.В данном конкретном случае DMC разработала специальную инструкцию Add-On Instruction (AOI) для использования в проекте, содержащую некоторую уникальную логику, которую клиент хотел защитить. Это невероятно просто. Rockwell предоставляет для этого простой инструмент, который поставляется в комплекте с RSLogix.

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

Обратите внимание, что всю приведенную ниже информацию можно найти в различных формах в двух полезных документах, опубликованных Rockwell Automation, которые я настоятельно рекомендую вам загрузить для справки:

Включение защиты источника

По умолчанию защита исходного кода не включена в RSLogix 5000. Так что, если вы никогда не использовали ее, велика вероятность, что она никогда не была активирована.Чтобы проверить, откройте проект, над которым вы работаете, и посмотрите в Инструменты >> Безопасность. Если вы не видите параметр «Настроить защиту источника», вам необходимо включить его.

Я бы предположил, что вам действительно нужно только быстро внести изменения в реестр, но это даже проще, чем это, поскольку Rockwell предоставляет бесплатный инструмент, который вы можете загрузить и запустить, чтобы позаботиться об этом за вас. Аллен Брэдли дает несколько хороших инструкций для процесса, в которых описываются различные методы для разных версий RSLogix в Logix5000 Controllers Security.В моем случае, используя rev 20, мне нужно было загрузить Source Protection Tool Аллена Брэдли. Чтобы найти его, я начал с их страницы загрузки программного обеспечения и поискал RSLogix Downloads. Вы должны увидеть его в списке как «Инструмент защиты исходного кода RSLogix 5000». Это быстрая загрузка. После запуска перезапустите RSLogix, и вы должны увидеть новую опцию в Tools >> Security: Configure Source Protection.

Хорошо, после включения вы можете выбрать новую доступную опцию, и теперь вам будет предложено указать местоположение файла исходного ключа.Идите вперед и выберите место. Если у вас нет файла исходного ключа в указанном каталоге, вас спросят, хотите ли вы его создать. Этот файл исходного ключа будет содержать ваши ключи для любой установленной вами защиты. Этот файл можно переместить с компьютера на компьютер или создать локально, добавив созданные вами ключи. Идите вперед и создайте новый; как только вы это сделаете, вы будете готовы заблокировать свой код.

Защита AOI

Для быстрой демонстрации я создал новый проект с единственной подпрограммой MyRoutine и одним AOI MyAddOnInstruction.«Как только вы откроете« Конфигурация защиты исходного кода »в меню« Инструменты >> Безопасность », вы увидите, что ваши программы и инструкции надстроек будут доступны. Вы можете настроить разные ключи и параметры для каждой программы и AOI, но давайте просто рассмотрим конфигурацию MyAddOnInstruction. Взгляните и обратите внимание, что в настоящее время ключи источника не определены.

Выберите свой AOI, который вы хотите защитить, и выберите «Защитить».«Откроется диалоговое окно« Ключ источника », в котором вы сможете выбрать или создать ключ источника для применения к выбранному компоненту (в данном случае — к нашему AOI). Я собираюсь создать новый,« MyKey », и назову его DMC. Если вы решите не показывать ключ (символы не будут отображаться на экране), вам нужно будет подтвердить ключ во второй раз. Я предпочитаю просто видеть, что я печатаю. Вы также можете определить имя исходного ключа. Это на самом деле просто понятное имя, которое будет ассоциироваться с вашим ключом (подумайте о user name :: password, key name :: key), которое будет отображаться в диалоговом окне защиты источника для защиты вашего ключа от посторонних глаз.

Флажок в этом диалоге заслуживает более подробного обсуждения. У вас есть два варианта включения уровня защиты. Если оставить этот флажок снятым, исходный код кода будет полностью заблокирован и скрыт от всех, у кого нет ключа. Любой, кто просматривает проект (или любой проект, содержащий этот AOI) без ключа, не сможет просматривать, получать доступ или редактировать исходный код инструкции. Установка этого флажка позволит пользователю просматривать, но не изменять исходный код, фактически делая его доступным только для чтения.Конечно, при любом выборе, если у вас есть ключ, у вас будет полный доступ.

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

Возвращаясь к нашему пошаговому руководству, давайте продолжим и оставим флажок снятым и выберите ОК. Это снова вернет нас к диалоговому окну «Конфигурация защиты источника», но теперь вы увидите, что ключ «DMC» был добавлен в наш AOI, и он не выбран для просмотра кем-либо без ключа.

Мы закончили здесь. Выберите «Закрыть», чтобы выйти из диалогового окна и взглянуть на дерево проекта. Вы не должны заметить никаких изменений. Вы все еще можете развернуть и увидеть и теги, и логику для только что защищенного AOI. Однако, чтобы увидеть, как это выглядит для кого-то без ключа, я собираюсь сохранить проект, выйти из RSLogix и удалить свой файл ключа. Теперь, после повторного открытия проекта, мы видим, что я не могу расширить AOI — нет доступа к тегам или логике для инструкции.

Если мы копнем немного глубже и снова откроем диалоговое окно Source Protection Configuration, мы увидим, что MyAddOnInstruction защищена и имеет неизвестный исходный ключ. Выбор AOI и выбор «Protect» вернет нас к диалоговому окну «Apply Source Key». Попытка применить новый исходный ключ, отличный от того, который мы уже создали для этой инструкции, приведет к ошибке и не позволит нам разблокировать его. Однако, к счастью, я сделал снимок экрана, показывающий, что я использовал ключ MyKey.Конечно, ввод этого ключа разблокирует AOI и снова разрешит доступ к исходному коду.

Здесь также стоит потратить время на экспорт нашего AOI. Обычно экспортированный AOI сохраняется в виде удобочитаемого текста в формате типа XML (попробуйте!). Однако, когда защита источника включена, этот экспортированный файл зашифрован.

Прежде чем закончить, я хочу вернуться еще к одному моменту. Я уже упоминал об этом ранее, но стоит упомянуть, что есть много причин, по которым можно использовать Source Protection в своем проекте.Помимо защиты закрытого кода, он также может быть полезным методом контроля версий. Хорошим примером может быть реализация нестандартного двигателя в большом проекте. После завершения разработки и тестирования инструкции или процедуры код может быть заблокирован создателем, чтобы предотвратить любые случайные изменения другими. Блокируя и затем экспортируя в библиотеку, другие разработчики могут использовать эту инструкцию и гарантировать, что исходный код не был изменен.

Это в сочетании с информацией о версии, доступной для каждого AOI и подпрограммы, может быть отличным способом управления общей библиотекой многократно используемого кода.DMC стремится сделать код максимально пригодным для повторного использования, чтобы сократить время разработки (и стоимость), повысить надежность и обеспечить масштабируемость и модульность. Сочетание этого с программным обеспечением для управления версиями, таким как SVN, обеспечивает простой способ поддержки библиотеки для всех наших инженеров.

Наконец, небольшое заявление о безопасности. Я лично не разбирался в том, насколько зашифрован или скрыт этот метод защиты исходного кода, но он, вероятно, будет служить для большинства целей. В случае чрезвычайно ценной интеллектуальной собственности я всегда настоятельно рекомендую проконсультироваться с экспертами, прежде чем полагать, что это пуленепробиваемое. За последние годы DMC накопила богатый опыт защиты ценной информации и на этот случай имеет экспертов.

Свяжитесь с DMC с любыми вопросами или для начала работы над следующим проектом.

Узнайте больше об услугах DMC по программированию ПЛК Allen Bradley.

Исключения — OSDev Wiki

Исключения , как описано в этой статье, представляют собой тип прерывания, генерируемого ЦП при возникновении «ошибки».Некоторые исключения в большинстве случаев не являются ошибками, например, ошибки страниц.

Исключения классифицируются как:

• Ошибки : Их можно исправить, и программа может продолжаться, как будто ничего не произошло.
• Ловушки : Ловушки сообщаются сразу после выполнения инструкции перехвата.
• Прерывание : серьезная неисправимая ошибка.

В некоторых исключениях 32-битный «код ошибки» помещается в верхнюю часть стека, что дает дополнительную информацию об ошибке.Это значение должно быть извлечено из стека перед возвратом управления обратно запущенной программе. (т.е. перед вызовом IRET)

Исключения

Неисправности

Ошибка деления на ноль

Ошибка деления на ноль возникает при делении любого числа на 0 с помощью инструкции DIV или IDIV, или когда результат деления слишком велик для представления в месте назначения. Поскольку сбойную инструкцию DIV или IDIV очень легко вставить в любое место кода, многие разработчики ОС используют это исключение, чтобы проверить, работает ли их код обработки исключений.

Указатель сохраненной инструкции указывает на инструкцию DIV или IDIV, которая вызвала исключение.

Превышен граничный диапазон

Это исключение может возникнуть при выполнении инструкции BOUND. Инструкция BOUND сравнивает индекс массива с нижней и верхней границами массива. Когда индекс выходит за границы, возникает исключение Bound Range Exceeded.

Указатель сохраненной инструкции указывает на инструкцию BOUND, которая вызвала исключение.

Неверный код операции

Исключение недопустимого кода операции возникает, когда процессор пытается выполнить недопустимый или неопределенный код операции или инструкцию с недопустимыми префиксами.Это также происходит в других случаях, например:

• Длина инструкции превышает 15 байтов, но это происходит только с избыточными префиксами.
• Инструкция пытается получить доступ к несуществующему регистру управления (например, mov cr6, eax ).
• Команда UD выполнена.

Указатель сохраненной инструкции указывает на инструкцию, которая вызвала исключение.

Устройство недоступно

Исключение «Устройство недоступно» возникает, когда выполняется попытка выполнения инструкции FPU, но нет FPU.Это маловероятно, поскольку современные процессоры имеют встроенные блоки FPU. Однако в регистре CR0 есть флаги, которые отключают инструкции FPU / MMX / SSE, вызывая это исключение при попытке их выполнения. Эта функция полезна, поскольку операционная система может определять, когда пользовательская программа использует регистры FPU или XMM, а затем сохранять / восстанавливать их соответствующим образом при многозадачности.

Указатель сохраненной инструкции указывает на инструкцию, которая вызвала исключение.

Недействительный TSS

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

Когда исключение возникло перед загрузкой селекторов сегментов из TSS, сохраненный указатель инструкции указывает на инструкцию, которая вызвала исключение. В противном случае, что встречается чаще, он указывает на первую инструкцию в новой задаче.

Код ошибки: Исключение Invalid TSS устанавливает код ошибки, который является индексом селектора.

Сегмент отсутствует

Исключение «Сегмент отсутствует» возникает при попытке загрузить сегмент или логический элемент, для которого бит присутствия установлен в 0.Однако при загрузке селектора сегмента стека, который ссылается на дескриптор, которого нет, возникает ошибка сегмента стека.

Если исключение происходит во время переключения аппаратной задачи, обработчик не должен полагаться на значения сегмента. То есть обработчик должен проверить их, прежде чем пытаться возобновить новую задачу. Согласно документации Intel, есть три способа сделать это.

Указатель сохраненной инструкции указывает на инструкцию, которая вызвала исключение.

Код ошибки: Исключение «Сегмент отсутствует» устанавливает код ошибки, который является индексом селектора сегмента дескриптора сегмента, вызвавшего исключение.

Ошибка сегмента стека

Сбой сегмента стека возникает, когда:

• Загрузка сегмента стека, ссылающегося на дескриптор сегмента, которого нет.
• Любая инструкция PUSH или POP или любая инструкция, использующая ESP или EBP в качестве базового регистра, выполняется, в то время как адрес стека не имеет канонической формы.
• Когда проверка предела стека не удалась.

Если исключение происходит во время аппаратного переключения задачи, обработчик не должен полагаться на значения сегмента. То есть обработчик должен проверить их, прежде чем пытаться возобновить новую задачу. Согласно документации Intel, есть три способа сделать это.

Указатель сохраненной инструкции указывает на инструкцию, которая вызвала исключение, если только ошибка не произошла из-за загрузки отсутствующего сегмента стека во время аппаратного переключения задачи, и в этом случае он указывает на следующую инструкцию новой задачи.

Код ошибки: Stack-Segment Fault устанавливает код ошибки, который является индексом селектора сегмента стека при обращении к отсутствующему дескриптору сегмента или при ошибке проверки предела во время переключения аппаратной задачи. В противном случае (для существующих сегментов и уже используемых) код ошибки — 0.

Общая ошибка защиты

Ошибка общей защиты может возникать по разным причинам. Наиболее распространены:

• Ошибка сегмента (привилегия, тип, ограничение, права чтения / записи).
• Выполнение привилегированной инструкции при CPL! = 0.
• Запись 1 в зарезервированное поле регистра или запись недопустимых комбинаций значений (например, CR0 с PE = 0 и PG = 1).
• Ссылка на нулевой дескриптор или доступ к нему.

Указатель сохраненной инструкции указывает на инструкцию, которая вызвала исключение.

Код ошибки: Ошибка общей защиты устанавливает код ошибки, который является индексом селектора сегмента, когда исключение связано с сегментом.В противном случае 0.

Ошибка страницы

Ошибка страницы возникает, когда:

• Каталог страниц или запись в таблице отсутствуют в физической памяти.
• Попытка загрузить TLB инструкции с переводом для неисполняемой страницы.
• Ошибка проверки защиты (привилегии, чтение / запись).
• Зарезервированный бит в каталоге страниц или записях таблицы установлен в 1.

Указатель сохраненной инструкции указывает на инструкцию, которая вызвала исключение.

Код ошибки

Ошибка страницы устанавливает код ошибки:

 31 4 0
+ --- + - - + --- + --- + --- + --- + --- + --- +
| Зарезервировано | Я | R | U | W | P |
+ --- + - - + --- + --- + --- + --- + --- + --- +
 

	Длина	Имя	Описание
п	1 бит	Настоящее время	Если установлено, ошибка страницы была вызвана нарушением защиты страницы.Если не установлен, это было вызвано отсутствием страницы.
Вт	1 бит	Написать	Если установлено, ошибка страницы была вызвана доступом для записи. Если не установлен, это было вызвано доступом для чтения.
U	1 бит	Пользователь	Если установлено, ошибка страницы была вызвана, когда CPL = 3. Это не обязательно означает, что ошибка страницы была нарушением привилегий.
п.	1 бит	Зарезервированная запись	Если установлено, одна или несколько записей каталога страниц содержат зарезервированные биты, для которых установлено значение 1.Это применимо, только когда флаги PSE или PAE в CR4 установлены на 1.
Я	1 бит	Получение инструкции	Если установлено, ошибка страницы была вызвана выборкой инструкции. Это применимо только в том случае, если бит No-Execute поддерживается и включен.

Кроме того, он устанавливает значение регистра CR2 на виртуальный адрес, который вызвал ошибку страницы.

x87 Исключение с плавающей точкой

Исключительная ситуация с плавающей запятой x87 возникает, когда выполняется инструкция FWAIT или WAIT или любая ожидающая инструкция с плавающей запятой, и выполняются следующие условия:

• CR0.NE равно 1;
• немаскированное исключение x87 с плавающей запятой ожидает обработки (т.е. бит исключения в регистре слова состояния с плавающей запятой x87 установлен в 1).

Указатель сохраненной инструкции указывает на инструкцию, которая должна быть выполнена, когда возникла исключительная ситуация. Регистр указателя инструкций x87 содержит адрес последней инструкции, вызвавшей исключение.

Код ошибки: Исключение не отправляет код ошибки. Однако информация об исключении доступна в регистре слова состояния x87.

Проверка центровки

Исключение проверки выравнивания возникает, когда проверка выравнивания включена и выполняется ссылка на невыровненные данные памяти. Проверка соосности выполняется только в CPL 3.

По умолчанию проверка выравнивания отключена. Чтобы включить его, установите биты CR0.AM и RFLAGS.AC в 1.

Указатель сохраненной инструкции указывает на инструкцию, которая вызвала исключение.

Исключение для чисел с плавающей запятой SIMD

Исключительная ситуация с плавающей запятой SIMD возникает, когда возникает немаскированная 128-битная исключительная ситуация с плавающей точкой носителя и CR4.Бит OSXMMEXCPT установлен в 1. Если флаг OSXMMEXCPT не установлен, то исключения с плавающей запятой SIMD вместо этого вызовут исключение Undefined Opcode.

Указатель сохраненной инструкции указывает на инструкцию, которая вызвала исключение.

Код ошибки: Исключение не отправляет код ошибки. Однако информация об исключении доступна в регистре MXCSR.

Ловушки

Отладка

Исключение отладки возникает в следующих случаях:

• Точка останова при получении команд (неисправность)
• Общее состояние обнаружения (неисправность)
• Точка останова чтения или записи данных (ловушка)
• Точка останова для чтения или записи ввода-вывода (Trap)
• Одношаговый (ловушка)
• Переключатель задач (Ловушка)

Когда исключение является ошибкой, сохраненный указатель инструкции указывает на инструкцию, которая вызвала исключение. Когда исключение является ловушкой, указатель сохраненной инструкции указывает на инструкцию после инструкции, вызвавшей исключение.

Код ошибки: Исключение отладки не устанавливает код ошибки. Однако информация об исключении предоставляется в регистрах отладки (CPU_Registers_x86 # Debug_Registers).

Точка останова

Исключительная ситуация точки останова при выполнении инструкции INT3. Некоторые программы для отладки заменяют инструкцию инструкцией INT3.Когда точка останова перехвачена, он заменяет инструкцию INT3 исходной инструкцией и уменьшает указатель инструкции на единицу.

Указатель сохраненной инструкции указывает на байт после инструкции INT3.

Перелив

Исключение переполнения возникает, когда инструкция INTO выполняется, когда бит переполнения в RFLAGS установлен в 1.

Указатель сохраненной инструкции указывает на инструкцию после инструкции INTO.

Отмена

Двойная ошибка

Двойная ошибка возникает, когда исключение не обработано или когда исключение возникает, когда ЦП пытается вызвать обработчик исключений. Обычно два исключения одновременно обрабатываются одно за другим, но в некоторых случаях это невозможно. Например, если возникает ошибка страницы, но обработчик исключений находится на странице отсутствия, произойдет две ошибки страницы, и ни одна из них не может быть обработана. Произойдет двойная ошибка.

Двойная ошибка всегда генерирует код ошибки с нулевым значением.

Указатель сохраненной инструкции не определен. Двойную ошибку устранить нельзя. Процесс сбоя должен быть прекращен.

В некоторых начальных операционных системах для хобби двойная ошибка также довольно часто является ошибочно диагностированным IRQ0 в тех случаях, когда PIC еще не был перепрограммирован.

Машинный чек

Исключение Machine Check зависит от модели, и реализации процессора не требуются для его поддержки. Он использует регистры, зависящие от модели, для предоставления информации об ошибках. По умолчанию он отключен. Чтобы включить его, установите бит CR4.MCE в 1.

Исключения проверки машины возникают, когда процессор обнаруживает внутренние ошибки, такие как плохая память, ошибки шины, ошибки кеша и т. Д.

Значение сохраненного указателя инструкции зависит от реализации и исключения.

Тройной отказ

Основная статья: Triple Fault

Тройной сбой на самом деле не является исключением, потому что он не имеет связанного номера вектора. Тем не менее, тройная ошибка возникает, когда создается исключение при попытке вызвать обработчик исключений двойной ошибки. Это приводит к перезагрузке процессора. См. Основную статью для получения дополнительной информации о возможных причинах и о том, как их избежать.

Код ошибки селектора

 31 16 15 3 2 1 0
+ --- + - - + --- + --- + - - + --- + --- + --- + --- +
| Зарезервировано | Индекс | Tbl | E |
+ --- + - - + --- + --- + - - + --- + --- + --- + --- +
 

	Длина	Имя	Описание
E	1 бит	Внешний	Если установлено, исключительная ситуация возникла вне процессора.
Тбл	2 бита	Таблица IDT / GDT / LDT	Это одно из следующих значений: Значение Описание 0b00 Индекс селектора ссылается на дескриптор в GDT. 0b01 Индекс селектора ссылается на дескриптор в IDT. 0b10 Индекс селектора ссылается на дескриптор в LDT. 0b11 Индекс селектора ссылается на дескриптор в IDT.
Индекс	13 бит	Селекторный указатель	Индекс в GDT, IDT или LDT.

Наследие

Следующие исключения случаются с устаревшей технологией, но они больше не используются или их следует избегать.Они применимы в основном к Intel 386 и ранее, и примерно в то же время могут включать в себя процессоры других производителей.

Ошибка прерывания FPU

Раньше модуль с плавающей запятой представлял собой специальный чип, который можно было присоединить к процессору. В нем не было прямого подключения ошибок FPU к процессору, поэтому вместо него использовалось IRQ 13, что позволяло процессору самостоятельно устранять ошибки. Когда 486 был разработан и добавлена ​​поддержка мультипроцессоров, FPU был встроен в кристалл, и глобальное прерывание для FPU стало нежелательным, вместо этого появилась возможность прямой обработки ошибок.По умолчанию этот метод не включен при загрузке для обратной совместимости, но ОС должна соответствующим образом обновить настройки.

Переполнение сегмента сопроцессора

Когда FPU все еще был внешним по отношению к процессору, у него была отдельная проверка сегмента в защищенном режиме. Начиная с 486, это обрабатывается GPF вместо того, как это уже было с доступом к памяти без использования FPU.

См. Также

Внешние ссылки

.