У всех длинных предметов -два конца. Задний называется хвостом, а передний -х...м. Лучше уж плестись в хвосте у прогресса, чем сидеть на х... у производителей софта и харда. Согласитесь - больно много вы поимели пользы от 64-разрядного железа/софта по сравнению с предыдущими версиями ? Не будем брать во внимание игроманов и биткоинщиков - это особый тупиковый мир. А нормальному технарю оно надо ?
Ariadna-on-Line писал(а): Чт май 21, 2026 20:03:47
У всех длинных предметов -два конца. Задний называется хвостом, а передний -х...м. Лучше уж плестись в хвосте у прогресса, чем сидеть на х... у производителей софта и харда. Согласитесь - больно много вы поимели пользы от 64-разрядного железа/софта по сравнению с предыдущими версиями ? Не будем брать во внимание игроманов и биткоинщиков - это особый тупиковый мир. А нормальному технарю оно надо ?
Совершенно согласен.
А так сравнивал этот насквозь багнутый 64-х битный протеус с 32-х битным при симуляции одной и той же цифровой схемы в надежде увидеть непревзойдённую скорость и производительность (как заявлено в описании) - результат совершенно одинаковый, к тому же памяти 64-х битный расходует больше. Классики давно уже писали, что нет такого преступления, которое не могло бы быть оправдано капиталом. Что тут уж говорить об "безобидном" обмане, который стал нормой в западном мире.
Посему наверно опишу здесь в скором будущем механизм лицензирования, который используется в протеусе, исключительно в образовательных целях.
Nemo78 писал(а): Сб май 30, 2026 22:25:02
Посему наверно опишу здесь в скором будущем механизм лицензирования, который используется в протеусе, исключительно в образовательных целях.
Nemo78 писал(а): Сб май 30, 2026 22:25:02
Посему наверно опишу здесь в скором будущем механизм лицензирования, который используется в протеусе, исключительно в образовательных целях.
А вдруг они осмелятся сменить?
И такое может быть. Но мне думается что самой последней с наименьшим количеством багов и быстрой в плане симуляции микроконтроллеров была версия 8.12, во всех версиях после прослеживается нарастающая тенденция к деградации. Потому не сильно пугает такая вероятность. И потом учитывая цену за которую продаётся лицензия и количество уже купивших её скорее поменяется не механизм лицензирования, а способ защиты этого механизма, что в общем-то один раз уже было после того как наш соотечественник понял механизм и написал генератор лицензии.
Содержимое лицензионного файла условно можно разделить на две части. Первая часть содержит сведения о обладателе лицензии и сроке её действия, вторая часть определяет функционал с помощью идентификаторов. Идентификаторов может быть один или несколько в зависимости от оплаченного функционала. Вот список функций и их идентификаторов для восьмой версии:
Proteus VSM for MC8051 - 10000100
Proteus VSM for 8086 - 10001A00
Proteus VSM for Arduino AVR - 10000800
Processor Bundle - 20000000
Proteus VSM for Arduino STM - 10001C00
Proteus VSM for ARM7 - 10001302
Proteus VSM for AVR - 10000800
Proteus VSM for Cortex-M0 - 10001E00
Proteus VSM for Cortex-M3 - 10001C00
Proteus VSM for Cortex-M4 - 10002000
Proteus VSM for MSP430 - 10001500
Proteus VSM for PIC10 - 10001104
Proteus VSM for PIC12 - 10001100
Proteus VSM for PIC16 - 10000000
Proteus VSM for PIC18 - 10001200
Proteus VSM for PIC24 - 10001600
Proteus VSM for dsPIC33 - 10001700
Proteus VSM for PICAXE - 10001900
Proteus VSM for PICCOLO - 10001B00
Visual Designer for Arduino - 60000001
Visual Designer for Raspberry Pi - 10001F00
IoT Builder - 60000002
Advanced Simulation Features - 403
Proteus PCB Design Starter Kit - 500
Proteus PCB Design Level 1 - 501
Proteus PCB Design Level 1+ - 502
Proteus PCB Design Level 2 - 503
Proteus PCB Design Level 2+ - 504
Proteus PCB Design Level 3 - 505
Последний раз редактировалось Nemo78 Пт июн 19, 2026 18:48:46, всего редактировалось 4 раза.
Здесь:
CUSTOMER - номер лицензии, присваивается производителем при покупке;
TSTAMP - числовое представление момента времени создания данной части лицензии;
USERS - число пользователей лицензии;
NAME - имя покупателя лицензии;
COMPANY - организация покупателя лицензии
FAMILY - тип лицензии, в ранних версиях было Lite или Professional
EXPIRY - дата окончания лицензии
KEY - это специальным образом рассчитанный ключ (как он формируется будет рассказано в следующих главах).
Идентификационная часть лицензии (вторя часть) имеет следующую структуру (это демонстрационный пример только для описания):
Здесь:
PRODUCT - соответствует номеру лицензии;
TSTAMP - числовое представление момента времени создания данной части лицензии;
CODE - идентификатор функции;
DESC- описание функции;
ORDER - номер ордера;
KEY - это специальным образом рассчитанный ключ (как он формируется будет рассказано в следующих главах).
Ключ представляет собой последовательность из 152 байт, первые 24 байта - это своего рода служебная информация, оставшиеся 128 байт - это ни что иное как цифровая подпись содержимого лицензии.
В данном случае цифровая подпись создана для строки, составленной из значений параметров CUSTOMER, TSTAMP, USERS, NAME, COMPANY, FAMILY, EXPIRY. Для этой строки вычислен хеш по алгоритму MD5, а полученное значение хеша зашифровано алгоритмом RSA. Результат шифрования - это и есть цифровая подпись. Не трудно догадаться что длина ключа шифрования составляет 1024 бит (128 байт).
При запуске программы сначала проверяется служебная информация ключа, а за тем выполняется проверка цифровой подписи. И если обнаруживается, что цифровая подпись не соответствует данным, лицензия сразу же признаётся недействительной. Таким образом попытка использовать легальный лицензионный файл с истёкшим сроком действия и изменённым значением EXPIRY ни к чему не приведёт.
Значение байт служебной информации ключа исследовано не полностью. Вот для примера служебная часть двух ключей:
Первые 6 байт у них совпадают (предположительно это какие-то идентификаторы) . Следующие 4 байта - это закодированная метка времени . Значение следующих десяти бай неизвестно, но видно что они заканчиваются одинаковой последовательностью 01 01. Следующие два байта - это первые два байта рассчитанного значения хеша данных лицензии . Последние два байта - это предположительно размер данных цифровой подписи (HEX 400 = DEC 1024).
Чтобы выполнить проверку цифровой подписи само собой нужен публичный ключ. И он имеется в недрах программы и его не трудно от туда извлечь или заменить. И казалось бы, зная всё это, можно соорудить свой лицензионный файл, который будет воспринят программой как легальный. Но не тут-то было. В программу встроен механизм проверки целостности файла с использованием цифровой подписи по аналогии с цифровой подписью лицензии, но немного сложней на определённом этапе. Об этом в следующей части.
Итак, файл лицензии - это набор параметров, их значений и цифровая подпись. Значение параметров может быть любое, за исключением значений параметра CODE (его наличие и значение проверяется при запуске программы, при запуске симуляции, при выполнении автоматической разводки дорожек и т.д. и т.п.), EXPIRY и TSTAMP. Цифровая подпись - это служебные данные + зашифрованный RSA алгоритмом MD5 хеш строки, составленной из значений параметров. RSA шифрование должно быть выполнено приватным ключом, расшифровка публичным ключом. Поскольку приватный и публичный ключ генерируются парой, существующий публичный ключ в программе должен быть изменён. Длина ключа 1024 бита.
Последний раз редактировалось Nemo78 Чт июл 02, 2026 19:54:52, всего редактировалось 5 раз.
В части 1 главе 3 описывалась служебная часть цифровой подписи.
Так вот спустя некоторое время структура служебной части стала чуть-чуть более понятна. С большой степенью вероятности это так называемый CMS контейнер с нестандартным наполнением. Рассмотрим его с новым пониманием.
89 00 95 02 0500 64 36 5B 70 DB 0B FA 50 0C 62 78 69 01 01 AD E0 04 00
89 - с большой вероятностью это тег класса Application и номер тега 4; 00 - это, вероятно, разделитель; 95 - это, вероятно, идентификатор, обозначающий метку времени; 02 - это, вероятно, идентификатор формата метки времени, а именно INTEGER, т.е. 32-х битное число; 05 - это, вероятно, длина метки времени в байтах; 00 64 36 5B 70 - метка времени с дополнительным нулевым байтом чтобы число интерпретировалось всегда как положительное; DB 0B FA 50 0C 62 78 69 01 01 - значение этих байтов всё еще под вопросом; AD E0 - это первые два байта вычисленного значения MD5;
04 00 - это либо размер данных RSA блока, который следует далее, либо строка-заглушка, обозначающая окончание служебных данных.
В самом основном файле, отвечающем за механизм лицензирования, а также в нескольких других, отвечающих за симуляцию цифровой и аналоговой части, присутствует механизм защиты от изменения, т.е. контроль целостности. Основан этот механизм на цифровой подписи. Цифровая подпись файлов устроена аналогично цифровой подписи лицензионных данных файла лицензии, т.е. это служебные данные + зашифрованный RSA-1024 алгоритмом MD5 хеш. MD5 хеш рассчитывается не для всего файла целиком, а для большей его части начиная от PE заголовка включительно и до последнего байта. Пространство от DOS до PE заголовка при расчёте не учитывается. Так вот в свободном пространстве между DOS и PE заголовком и размещена цифровая подпись. Распознать её легко по сигнатуре, она так же как в лицензии начинается с вполне узнаваемой последовательности байт.
Судя по одинаковой последовательности байт, той самой неизвестной её части (описанной ранее), можно смело утверждать, что это первые 8 байт публичного ключа, которым должна быть выполнена дешифровка хеша + два байта 01 01 (вероятно разделитель или тег или какие-то флаги).
Но наличие цифровой подписи внутри файла совсем не означает, что и проверка этой цифровой подписи организована в нём же. Если выполнить сигнатурный поиск цифровой подписи и сигнатурный поиск алгоритма проверки цифровой подписи и составить списки, то состав файлов в этих списках будет отличаться - часть файлов будет совпадать, часть будет присутствовать в одном списке и отсутствовать в другом и наоборот. Т.е. используется перекрёстная проверка.
Сама проверка цифровой подписи файлов происходит в разные моменты жизнедеятельности программы. Если совсем упрощенно - в момент запуска программы проверяются самые основные файлы, которые участвуют в проверке лицензии, а также в жизнедеятельности основной части программы, при запуске симуляции проверяются другие файлы, которые отвечают за функционирование симуляции цифровой или аналоговой части в зависимости от состава схемы и т.д. и т.п. И если вдруг окажется, что какой-либо из означенных файлов изменён, т.е. его цифровая подпись недействительна, после проверки почти всегда выполняется создание нового потока (что такое потоки в программе можно узнать у Алисы), в котором выполняется завершающий работу программы таймер (т.н. килл-таймер). Именно из-за этого программа "схлопывается", как некоторым пользователям кажется, совершенно случайным образом (само собой если у пользователей программа нелегальная или зараженная вирусом).
Теперь самое интересное. Публичный ключ для проверки цифровой подписи файлов, в отличии от публичного ключа для проверки лицензии, храниться в недрах программы в зашифрованном виде и алгоритм его шифрования нестандартный. На данный момент известно, что это модификация одного из известных блочных алгоритмов или комбинация из двух или более блочных алгоритмов. Исследование в этом направлении ещё ведётся, цель исследования - сгенерировать зашифрованный публичный ключ, который при замене будет успешно расшифрован реализованным в программе алгоритмом.
