Спасибо за минус, но я не гордый. Зато мы тут с ИИ посовещались и поняли что ваш дамп ключа с ошибкой. По смещению 0x807 должен быть 0xF5, а не 0xF4. Это контрольная сумма, которую проверяет программа установки. И если его поправить то защита прекрасно ставится. Процедура чтения дампа находится по адресу seg001:175F в распакованном BUG_C.
Плата ставится в клиентские машины, софт для подписи находится только у автора подписываемого ПО и не передается клиентам, который купили это ПО. С чего вы взяли, что «софт доступен всем»?
Софт для подписи универсален и поставляется ВСЕМ кто купил SDK, а значит что для взломщика нет проблем получить к нему доступ.
В любом случае, могу только цитировать официальную инструкцию, это вернее, чем строить предположения, основанные только на опыте работы с другими устройствам.
Хотите доказать обратное — пожалуйста, софт для подписывания сейчас в открытом доступе, покажите, что для подписания необходимо наличие платы.
Если вы внимательно прочитаете мое сообщение, то увидите, что я утверждаю только одно - если для подписи не требуется аппаратный ключ то это фикция, а не аппаратная защита, в ключ тут только для галочки и разработчики этого устройства не компетентные дилетанты.
Здесь нет никакой секретной функции на плате, только ПЗУ и логика.
С точки зрения софта это тоже самое, это влияет только на стойкость самого физического ключа,т.к. считать ПЗУ намного проще чем выковырять алгоритм из ASIC. А вот то что это написано в инструкции, так это странно, потому что зачем тогда вообще нужна железка, если нужно значение можно получить без нее, только софтом который доступен всем и любой может его расковырять. Весь смысл в аппаратной защите, что не существует софта который может расчитать нужно значение без железки и именно поэтому она нужна вовремя установки защиты.
Установка защиты должна работать без подключения платы, но этого не происходит.
Нифига она не должна работать без платы. По опыту работы с HASP там вся защита строится на том что внутри ключа аппаратно реализованна секретная функция которая преобразовывает одно число в другое используя начальный вектор данных (дамп ключа), которое потом используется для шифрования куска кода при установке защиты. Поэтому во время установки защиты ключ тоже должен быть доступен. Установщик генерирует случайное число, потом посылает его ключу и получает ответ. Этот ответ используется для шифрования куска кода. Дальше установщик добавляет код для расшифровки во время исполнения программы и если ключ есть и совпадает, то тогда и ответ будет точно таким как и при установке и код нормально дешифруется. Останется только проверить контрольную сумму и если она не совпадет - выдать сообщение об ошибке и завершить программу.
Наверное не нужно было превращать простое приложение в 3D игрушку которой требуется RTX5090 для выбора 10 настроек особенно если приложение предназначено быть оптимизированным и быстрым. А причина уже давно найдена - вы выбрали Iced у которого 382 открытые проблемы половина из которых о том что эта херня лагает, жрет процессор/GPU и падает. И это уже не лечится.
Я скачал NEXT из релизов и запустил на виртуалке VMWARE и это полный абзац. Пользоваться невозможно вообще даже без соединения. Нагрузка на одно ядро 100%, интерфейс весь какими то прямоугольниками и разваливается на лету...провел мышкой через окно программы и половина элементов пропали в полной темноте. Такой херни я еще никогда не видел.
Статья похожа на на реферат нерадивого студента: одна и таже вода написана по 10 раз разными словами, двойные пустые строки после каждого предложения и т.п....вообщем воды много, а сути очень мало.
Кроме того, судя по конфигу go2rtc он транскодирует видео поток, но ЗАЧЕМ? наверняка камера и так уже вещает в H.264 и никакого смысла его транскодировать нет. Если убрать транскодирование, то это в СОТНИ раз снизит нагрузку на процессор.
Я говорю о главе "SoA и AoS" которая является полным бредом где вы разбиваете x y z на отдельные массивы и утверждаете что так быстрее, при этом ссылаетесь на статью в которой написано СТРОГО НАОБОРОТ. В статье по ссылке описывается Hot/cold splitting и основываясь на этом нужно было разбить так как я описал выше,т.к. x y z в 99.99999% случаев используются вместе поэтому их нужно группировать в одну структуру, а не разбивать по разным уголкам оперативной памяти чтобы потом собирать их отовсюду насилуя кэш процессора.
Незнаю что вы имете ввиду, но например в OpenGL загрузка координат идет массивом структур x,y,z, поэтому в том виде который указал автор их невозможно загрузить без предварительной обработки. Т.е. сплошной кусок памяти должен содержать по переменно x y z x2 y2 z2..., а не x x2...y y2..z z2 как у автора
Про "SoA быстрее AoS" это полный бред. Автор даже не понял суть статьи на которую он ссылается. Там весь упор был сделан не на SoA vs AoS, а на то что данные нужно группировать с умом и комбинировать ОБА подхода, а не тупо использовать только один из них как написал автор. Согласно указанной статье нужно было сделать структуру с x, y, z и потом сделать 3 вектора этих структур, а не 9 векторов с отдельными значениями. 9 векторов это ХУДШИЙ вариант, потому что для обработки ЛЮБОЙ величины (позиции, скорости или ускорения) одной точки нужно загружать данные как минимум из трех очень удаленных адресов (x любой величины лежит ооочень далеко от y и z), а их в 99% случаев обрабатывают вместе.
Ну а у в случае если вообще ничего не писать, так и вообще поддерживать легко...нет кода - нет проблем. Но мы же все таки пишем код и используем интерфейсы. Хотите реальный пример - есть у меня небольшой проект на Go - стриминг сервер, который раздает MPEGTS/HLS/SRT и т.п. Если бы я его писал на C++ то я бы сделал базовый класс входного потока и потом бы уже наследовался от него и реализовывал на его основе отдельно MPEGTS/HLS/SRT и т.п. Но в Go нет наследования и поэтому чтобы не плодить copy-paste реализуя все через интерфейс я переворачиваю эту модель задом наперед и делаю базовый класс входного потока финальным, а реализации MPEGTS/HLS/SRT через композицию в этот класс указателя на интерфейс имплементации конкретных протоколов,с неизбежными кросслинками между имплементацией и базовым классом. Вы думаете это упростило мне жизнь? да нихрена. Да все работает, нет copy-paste, но реализация в прямом смысле через зад - задом на перед. Это необходимые костыли, которые усложнили код и его поддержку.
Композиция это не частный случай наследования, это совсем другое
Не надо вытаскивать слова из контекста, я писал " есть структуры в которых нет методов и для структур композиция это и есть частный случай наследования". Если не верите, то возмите на с++ и напишите наследование и композицию для структур без методов и вы увидите что результат будет одинаковый. Я это лично проверял как разные компиляторы c++ располагают классы, структуры и таблицы виртуальных методов в памяти еще 30 лет назад.
Приведите, пожалуйста, реальную ситуацию, не изолированный воображаемый пример, когда наследование однозначно выгоднее
Выгоднее чего? Copy-paste реализации через интерфейсы. Так это аксиома что Copy-paste это плохо, а по другому там никак. Если вам нужны примеры, так откройте любую библиотеку на с++ где есть наследование и попробуйте подумать как это реализовать без наследования, а только композицией..да это будет возможно написать, но код будет намного сложнее чем через наследование.
Прелесть Го в том, что никто не передаст в функцию непойми что, что не нужно разбираться какая функция в реальности вызывается у класса и что кто-то в дочернем классе переопределил её на бог знает что
В каком смысле "не нужно разбираться какая функция в реальности вызывается у класса"??? Если функция в Go принимает ссылку на интерфейс то как раз нужно разбиратся что за немойми что это за экземпляр и кто реализует этот интерфейс и какая в реальности функция вызывается. и вполне возможно что что кто-то в дочернем классе реализовал вместо интерфейся бог знает что
А зачем вам вообще может понадобиться сразу отсортированный список везде? Что это за реальная задача, где это нужно?
Это не контр аргумент, а демогогия. И почему везде? То то и оно что где то нужен обычный список в котором не надо тратить время на сортировку, а где то нужен отсортированный. Задача хоть и упрощенная но вполне проецируется на реальные задачами. Суть это примера не в конкретной задаче, а в необходимости переопределить небольшое количество методов которым требуется доступ к внутренним данным класса.
можно использовать те же интерфейсы.
Да можно, но наследование изящние (если оно есть в языке) и почему это плохо,а композиция хорошо мне так никто и не сказал.
Так это всегда нужно делать, если вы меняете интерфейс, то все функции, что используют этот интерфейс должны быть изменены.
Да неужели? Если я добавляю 25 новых функций в базовый класс то я могу вообще не менять ни одного наследника и все будет рабоать. А в случае с интерфейсом я ОБЯЗАН менять ВСЕХ наследников причем в большинстве случаев с композицией это будет copy-paste.
Прелесть композиции и запрета наследования в Go в том, что Go гарантирует, что если у вашей функции есть 3 аргумента - структура, int и массив интов, то туда можно передать только структуру, int и массив интов, никаких дочерей, пасынков, родственников и друзей, только эти типы данных
А в чем прелесть то, со стороны разрабочика на Go (если вы конечно не мазахист и каждое ограничение вызывает у вас восторг)? То что это проще для разработчиков языка, да, но для разрабочика на Go это ограничение. В таком случае вам понравится писать на чистом ассемблере...абсолютная прелесть. Да и для справки, в Go вооще нет классических классов, так что о каком наследовании классов вообще идет речь это загадка.Там есть структуры в которых нет методов и для структур композиция это и есть частный случай наследования.
Вот тут вы полностью правы, вы НЕ так велики чтобы выдавать свое мнение за мнение разработчиков вышеупомянутых языков и не вам решать почему они приняли те или иные решения.
Так вы еще и читать не умеете? Я вас разве спрашивал о списке языков в которых есть "расширенная диспетчеризация вызовов без классического ООП"? Нет. Я утверждаю что композиция это НЕ альтернатива наследованию если язык поддерживает наследование. Использование композиции в качестве альтернативы наследованию это костыли которые приводят к меннее наглядному, менее качественному и создают сложности с поддержкой кода. Если вы не согласны с моим утверждением, то жду ваших АРГУМЕНТОВ, а не списка языков и учебников.
Мда, конкретика и аргументы достойны несостоявшегося программиста. Неужели все так плохо и такой теоретик не может даже аргумент сформулировать, раз уж код не получается. Вот вам ссылка что такое аргумент https://ru.wikipedia.org/wiki/Аргумент_(логика)
Это вы зря, у любого бухгалтера с компом под боком был админ которого хлебом не корми, только дай что нибудь сломать :-).
Там даже черный лак трогать не надо, потому что ключ полностью вычитывается софтом
Спасибо за минус, но я не гордый. Зато мы тут с ИИ посовещались и поняли что ваш дамп ключа с ошибкой. По смещению 0x807 должен быть 0xF5, а не 0xF4. Это контрольная сумма, которую проверяет программа установки. И если его поправить то защита прекрасно ставится. Процедура чтения дампа находится по адресу seg001:175F в распакованном BUG_C.
Софт для подписи универсален и поставляется ВСЕМ кто купил SDK, а значит что для взломщика нет проблем получить к нему доступ.
Если вы внимательно прочитаете мое сообщение, то увидите, что я утверждаю только одно - если для подписи не требуется аппаратный ключ то это фикция, а не аппаратная защита, в ключ тут только для галочки и разработчики этого устройства не компетентные дилетанты.
С точки зрения софта это тоже самое, это влияет только на стойкость самого физического ключа,т.к. считать ПЗУ намного проще чем выковырять алгоритм из ASIC. А вот то что это написано в инструкции, так это странно, потому что зачем тогда вообще нужна железка, если нужно значение можно получить без нее, только софтом который доступен всем и любой может его расковырять. Весь смысл в аппаратной защите, что не существует софта который может расчитать нужно значение без железки и именно поэтому она нужна вовремя установки защиты.
Нифига она не должна работать без платы. По опыту работы с HASP там вся защита строится на том что внутри ключа аппаратно реализованна секретная функция которая преобразовывает одно число в другое используя начальный вектор данных (дамп ключа), которое потом используется для шифрования куска кода при установке защиты. Поэтому во время установки защиты ключ тоже должен быть доступен. Установщик генерирует случайное число, потом посылает его ключу и получает ответ. Этот ответ используется для шифрования куска кода. Дальше установщик добавляет код для расшифровки во время исполнения программы и если ключ есть и совпадает, то тогда и ответ будет точно таким как и при установке и код нормально дешифруется. Останется только проверить контрольную сумму и если она не совпадет - выдать сообщение об ошибке и завершить программу.
Наверное не нужно было превращать простое приложение в 3D игрушку которой требуется RTX5090 для выбора 10 настроек особенно если приложение предназначено быть оптимизированным и быстрым. А причина уже давно найдена - вы выбрали Iced у которого 382 открытые проблемы половина из которых о том что эта херня лагает, жрет процессор/GPU и падает. И это уже не лечится.
Я скачал NEXT из релизов и запустил на виртуалке VMWARE и это полный абзац. Пользоваться невозможно вообще даже без соединения. Нагрузка на одно ядро 100%, интерфейс весь какими то прямоугольниками и разваливается на лету...провел мышкой через окно программы и половина элементов пропали в полной темноте. Такой херни я еще никогда не видел.
Посмотрите конфигурацию вашей камеры под дверью, наверняка в настройках можно поменять H.265 на H.264.
Статья похожа на на реферат нерадивого студента: одна и таже вода написана по 10 раз разными словами, двойные пустые строки после каждого предложения и т.п....вообщем воды много, а сути очень мало.
Кроме того, судя по конфигу go2rtc он транскодирует видео поток, но ЗАЧЕМ? наверняка камера и так уже вещает в H.264 и никакого смысла его транскодировать нет. Если убрать транскодирование, то это в СОТНИ раз снизит нагрузку на процессор.
Я говорю о главе "SoA и AoS" которая является полным бредом где вы разбиваете x y z на отдельные массивы и утверждаете что так быстрее, при этом ссылаетесь на статью в которой написано СТРОГО НАОБОРОТ. В статье по ссылке описывается Hot/cold splitting и основываясь на этом нужно было разбить так как я описал выше,т.к. x y z в 99.99999% случаев используются вместе поэтому их нужно группировать в одну структуру, а не разбивать по разным уголкам оперативной памяти чтобы потом собирать их отовсюду насилуя кэш процессора.
Незнаю что вы имете ввиду, но например в OpenGL загрузка координат идет массивом структур x,y,z, поэтому в том виде который указал автор их невозможно загрузить без предварительной обработки. Т.е. сплошной кусок памяти должен содержать по переменно x y z x2 y2 z2..., а не x x2...y y2..z z2 как у автора
Про "SoA быстрее AoS" это полный бред. Автор даже не понял суть статьи на которую он ссылается. Там весь упор был сделан не на SoA vs AoS, а на то что данные нужно группировать с умом и комбинировать ОБА подхода, а не тупо использовать только один из них как написал автор. Согласно указанной статье нужно было сделать структуру с
x, y, zи потом сделать 3 вектора этих структур, а не 9 векторов с отдельными значениями. 9 векторов это ХУДШИЙ вариант, потому что для обработки ЛЮБОЙ величины (позиции, скорости или ускорения) одной точки нужно загружать данные как минимум из трех очень удаленных адресов (x любой величины лежит ооочень далеко от y и z), а их в 99% случаев обрабатывают вместе.Orange Pi Zero 3W забыли. http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-Zero-3W.html
Ну а у в случае если вообще ничего не писать, так и вообще поддерживать легко...нет кода - нет проблем. Но мы же все таки пишем код и используем интерфейсы. Хотите реальный пример - есть у меня небольшой проект на Go - стриминг сервер, который раздает MPEGTS/HLS/SRT и т.п. Если бы я его писал на C++ то я бы сделал базовый класс входного потока и потом бы уже наследовался от него и реализовывал на его основе отдельно MPEGTS/HLS/SRT и т.п. Но в Go нет наследования и поэтому чтобы не плодить copy-paste реализуя все через интерфейс я переворачиваю эту модель задом наперед и делаю базовый класс входного потока финальным, а реализации MPEGTS/HLS/SRT через композицию в этот класс указателя на интерфейс имплементации конкретных протоколов,с неизбежными кросслинками между имплементацией и базовым классом. Вы думаете это упростило мне жизнь? да нихрена. Да все работает, нет copy-paste, но реализация в прямом смысле через зад - задом на перед. Это необходимые костыли, которые усложнили код и его поддержку.
Не надо вытаскивать слова из контекста, я писал " есть структуры в которых нет методов и для структур композиция это и есть частный случай наследования". Если не верите, то возмите на с++ и напишите наследование и композицию для структур без методов и вы увидите что результат будет одинаковый. Я это лично проверял как разные компиляторы c++ располагают классы, структуры и таблицы виртуальных методов в памяти еще 30 лет назад.
Выгоднее чего? Copy-paste реализации через интерфейсы. Так это аксиома что Copy-paste это плохо, а по другому там никак. Если вам нужны примеры, так откройте любую библиотеку на с++ где есть наследование и попробуйте подумать как это реализовать без наследования, а только композицией..да это будет возможно написать, но код будет намного сложнее чем через наследование.
В каком смысле "не нужно разбираться какая функция в реальности вызывается у класса"??? Если функция в Go принимает ссылку на интерфейс то как раз нужно разбиратся что за немойми что это за экземпляр и кто реализует этот интерфейс и какая в реальности функция вызывается. и вполне возможно что что кто-то в дочернем классе реализовал вместо интерфейся бог знает что
Это не контр аргумент, а демогогия. И почему везде? То то и оно что где то нужен обычный список в котором не надо тратить время на сортировку, а где то нужен отсортированный. Задача хоть и упрощенная но вполне проецируется на реальные задачами. Суть это примера не в конкретной задаче, а в необходимости переопределить небольшое количество методов которым требуется доступ к внутренним данным класса.
Да можно, но наследование изящние (если оно есть в языке) и почему это плохо,а композиция хорошо мне так никто и не сказал.
Да неужели? Если я добавляю 25 новых функций в базовый класс то я могу вообще не менять ни одного наследника и все будет рабоать. А в случае с интерфейсом я ОБЯЗАН менять ВСЕХ наследников причем в большинстве случаев с композицией это будет copy-paste.
А в чем прелесть то, со стороны разрабочика на Go (если вы конечно не мазахист и каждое ограничение вызывает у вас восторг)? То что это проще для разработчиков языка, да, но для разрабочика на Go это ограничение. В таком случае вам понравится писать на чистом ассемблере...абсолютная прелесть. Да и для справки, в Go вооще нет классических классов, так что о каком наследовании классов вообще идет речь это загадка.Там есть структуры в которых нет методов и для структур композиция это и есть частный случай наследования.
Вот тут вы полностью правы, вы НЕ так велики чтобы выдавать свое мнение за мнение разработчиков вышеупомянутых языков и не вам решать почему они приняли те или иные решения.
Так вы еще и читать не умеете? Я вас разве спрашивал о списке языков в которых есть "расширенная диспетчеризация вызовов без классического ООП"? Нет. Я утверждаю что композиция это НЕ альтернатива наследованию если язык поддерживает наследование. Использование композиции в качестве альтернативы наследованию это костыли которые приводят к меннее наглядному, менее качественному и создают сложности с поддержкой кода. Если вы не согласны с моим утверждением, то жду ваших АРГУМЕНТОВ, а не списка языков и учебников.
Мда, конкретика и аргументы достойны несостоявшегося программиста. Неужели все так плохо и такой теоретик не может даже аргумент сформулировать, раз уж код не получается. Вот вам ссылка что такое аргумент https://ru.wikipedia.org/wiki/Аргумент_(логика)