Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / WinForms, .Net Framework Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5   вперед  Ctrl      все
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
Bimon Subio
Member

Откуда:
Сообщений: 142
Eolt
Bimon Subio
Наверно, в особо важных случаях уже сегодня можно оптравлять вместо диска с программой
блок OrangePI, залитый в компаунд, который будет использоваться мене защищенными
GUIями, например, через Ethernet по RPC.


Что помешает вскрыть этот блок, слить прошивку и декомпилировать ее?


Если в этом залитом блоке еще и токены Guardant и Rutoken без своих пластиковых корпусов, то при вскрытии есть вероятность их механического повреждения, тогда прошивку будет не достать, потому что она зашифрованна обфускатором Guardant.

Не каждый решится раздалбливать компаунд даже без токенов, потому что можно повредить и одноплатник тоже.
Я не в курсе химии защитных компаундов, может быть их можно растворять или еще как то по другому снимать без повреждения платы?
15 апр 19, 16:31    [21862777]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
Bimon Subio
Member

Откуда:
Сообщений: 142
Eolt
В общем CODE норм, остальное все в мусорку. Но с CODE проблема, только 4 кбайта памяти и низкая производительность микропроцессора ключа, там ARM Cortex, ресурсоемкие алгоритмы в него не запихнуть. Придется сильно много думать.


А когда 3 в одном CODE+TIME+NET тогда еще более норм :)

Если в CODE запихать всякие простенькие утилитки типа арифметики и другие мелкие полезности, неужели их перепишут по догадкам?

Чтобы расширить вычислительные возможности CODE можно было бы использовать одноплатник, как я описывал выше, неужели нельзя придумать механизм его защиты от доступа отладчиками аналогично Guardant CODE?

Обфускация дешифрующим токеном Guardant
+ механническая защита типа компаунда с поломкой токена Guardant при вскрытии, так что сдампить расшифрованную сборку DotNet Core не удастся
+ одновременно что-нибудь типа IBM eFuse (самостоятельное автоматическое пережигание части перемычек внутри чипа этим чипом), например вывод из строя одноплатника и токенов при обнаружении программного взлома
15 апр 19, 16:42    [21862794]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
Eolt
Member

Откуда:
Сообщений: 1480
Bimon Subio
Если в этом залитом блоке еще и токены Guardant и Rutoken без своих пластиковых корпусов, то при вскрытии есть вероятность их механического повреждения, тогда прошивку будет не достать, потому что она зашифрованна обфускатором Guardant.

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


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

К сообщению приложен файл. Размер - 146Kb
15 апр 19, 17:36    [21862871]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
Bimon Subio
Member

Откуда:
Сообщений: 142
Причем тут компаунд внутри токенов?

Я предлагал следующие цепочки взаимодействий софта:

1) клиентское приложение -> LAN -> мощный сервер приложений

2) клиентское приложение -> LAN -> микросервер приложений и он же защиты

3) мощный сервер приложений -> LAN -> микросервер приложений и он же защиты

4) микросервер приложений и он же защиты -> Internet -> сервер приложений и защиты разработчика


Микросервер приложений и защиты из пункта 2) я предлагал залить компаундом вместе с подсоединенными к нему и расчехленными от оригинального пластикового корпуса токенами Guardant и Rutoken ECP2. Если этот кирпич начать разламывать, то велика вероятность сломать токены и одноплатник, который работает под Linux и содержит код DotNet Core, зашифрованный Guardant. Без дешифрующего токена такая прошивка бесполезна, она обфусцирована шифровальщиком. Core возможно пока не поддерживается, но это дело времени.
15 апр 19, 18:24    [21862907]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
Bimon Subio
Member

Откуда:
Сообщений: 142
1) Нагрев с выходом новых ревизий железа токенов постепенно будет уменьшаться.
Одноплатники скорее всего уже существуют, которые не греются.
Например Beaglebone Black не греется по словам пользователей.

2) Тепло, наверно, можно отводить какиминибудь специальными отводами.
15 апр 19, 18:36    [21862920]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
Bimon Subio
Member

Откуда:
Сообщений: 142
Кроме того, может быть, уже есть или появятся одноплатники, которые не имеют внешних интерфейсов для отладки и уже содержат flash диск в том же чипе, что и процессор.
Они могли бы наверно аналогично токенам запрещать чтение файловой системы извне.
15 апр 19, 20:14    [21862971]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
ёёёёё
Member

Откуда:
Сообщений: 740
Eolt
[...Guardant...]
...
Посмотрел описание ключей на их сайте. Платформа осталась той же. SDK только новый появился.
Алгоритмы шифрования никто ломать не собирается, как я уже писал ломается код в точке обмена данных с ключом.
Гардантовские протекторы и обфускаторы снимаются стандартными путями, в общем не слышал на exelab чтобы с ними были какие-то особые проблемы. Никаких преимуществ перед HASP или СенсеЛок у гарданта нету. Особняком стоит CODE по-понятным причинам.
На нем можно реализовать действительно неломаемую защиту в некоторых случаях. Например программа для раскодировки автомагнитол, алгоритм удалось полностью поместить в ключ, оставив снаружи только дельфовый гуй. Программу так и не сломали, хотя очень хотели) В общем CODE норм, остальное все в мусорку. Но с CODE проблема, только 4 кбайта памяти и низкая производительность микропроцессора ключа, там ARM Cortex, ресурсоемкие алгоритмы в него не запихнуть. Придется сильно много думать.

Нет, платформа совсем иная: раньше базовыми аппаратными были ключи stealth, теперь sign, совершенно иное, кроме внешнего вида "базовых" ключей.
Да, SDK принципиально иной, ибо "платформа" и методы работы новые.
"Код ломать" в точке обмена с ключом - это если самый примитивный метод защиты, я выше писал о иных методах. Что толку во взломанном софте, который не сможет выполнить алгоритмы, завязанные на неизвестный дескриптор алгоритма? Да и "ломать код" не совсем легко: контора предоставляет не только обфускатор, но и встраивает виртмашину (о качестве сказать ничего не могу) в защищаемое приложение, часть инструкций выполняется уже в ее кодах.
Ни о каких преимуществах Guardant перед Hasp или SenseLock я не говорил; "топлю" за Guardant исключительно потому, что использую их, еще с тех версий, когда их ломали и эмулировали. Кстати, против эмуляции есть чрезвычайно простые методы, всего лишь следует их использовать.
"exelab" - покажите, пожалуйста, где они работают с ключами guardant sign. Каким образом, например, можно сформировать электронную подпись, не имея дескриптора алгоритма?
Да, Guardant Code более развиты в плане возможностей, но требуют большего от клиентов-разработчиков защиты.
И глюков и багов хватает и в железе и в SDK, да, но жить можно.
17 апр 19, 07:56    [21864387]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
ёёёёё
Member

Откуда:
Сообщений: 740
Bimon Subio
...У них есть редакция NET...

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

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

В качестве аппаратного ключа используем обычный, не NET, так как пользователь фактически всего один: сервер. Впрочем, в некоторых случаях NET также используем: иногда "на площадке заказчика" тупо нет usb коннекторов, приходится втыкать ключ бог знает где, лишь бы "по сети" доступ был, и тут NET ключи спасают; ну да - надо бы прокси написать, ну вот так вот, временное решение зависло на уровне рабочего...
17 апр 19, 08:09    [21864389]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
Bimon Subio
Member

Откуда:
Сообщений: 142
ёёёёё
Bimon Subio
...У них есть редакция NET...

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

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


А чем ваше решение лучше, чем, например:
http://www.infralution.com/products/licensing_system.html

Если лицензируемую инфралюшином программу защитить с помощью обфускатора Guardant и аппаратного токена?
Т.е. Guardant не использовать для лицензионных ограничений, кроме как только зашиты от копирования?
17 апр 19, 08:24    [21864396]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
ёёёёё
Member

Откуда:
Сообщений: 740
Bimon Subio
...
А чем ваше решение лучше, чем, например:
http://www.infralution.com/products/licensing_system.html
...

Извиняюсь, не понял, почему нужно сравнивать. Наше решение точно лучше, потому что оно полностью соответствует нашим желаниям. И именно мы его постепенно меняем именно в том направлении, которое считаем верным.
17 апр 19, 08:44    [21864402]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
Bimon Subio
Member

Откуда:
Сообщений: 142
ёёёёё
Bimon Subio
...
А чем ваше решение лучше, чем, например:
http://www.infralution.com/products/licensing_system.html
...

Извиняюсь, не понял, почему нужно сравнивать.


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

ёёёёё
Наше решение точно лучше, потому что оно полностью соответствует нашим желаниям. И именно мы его постепенно меняем именно в том направлении, которое считаем верным.


Чем было бы хуже сделать ваше либо:
1) На базе Infralution и сэкономить сотни нефти, выплаченной вам за изобретение велосипеда.
2) Общедоступным продуктом типа Infralution, если уже ваше действительно сильно лучше, уникальное. Кроме того это позволило бы вернуть сотни нефти обратно.
17 апр 19, 09:03    [21864416]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
Bimon Subio
Member

Откуда:
Сообщений: 142
ёёёёё
Да, SDK принципиально иной, ибо "платформа" и методы работы новые.
"Код ломать" в точке обмена с ключом - это если самый примитивный метод защиты, я выше писал о иных методах. Что толку во взломанном софте, который не сможет выполнить алгоритмы, завязанные на неизвестный дескриптор алгоритма? Да и "ломать код" не совсем легко: контора предоставляет не только обфускатор, но и встраивает виртмашину (о качестве сказать ничего не могу) в защищаемое приложение, часть инструкций выполняется уже в ее кодах.


Насколько я понимаю, в новом Guardant расшифрование происходит упрощенно по цепочке:

Фрагмент DotNet кода после обработки протектором Guardant хочет получить расшифрованную строку -> API протектора, навешанное и автоматически внедненное в код -> запрос на дешифрацию -> API работы с аппаратным ключом -> криптопроцессор внутри ключа дешифрует заранее (на компе разработчика) зашифрованную строку программы DotNet -> возврат расшифрованной строки программе DotNet

Что мешает добавить отладочный хук где-то в самом начале цепочки на пути к "API протектора" когда случайный сессионный Solt еще не подмешан, а зашифрованные данные в начале цепочки статичны при каждом запуске программы, несмотря на то, что на USB канале они случайны, но там их перехватывать никто и не собирается.
Отследить все вызовы и сделать на их базе эмулятор?

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

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


Пожалуйста, перечислите эти методы. Хотелось бы узнать и другие способы защиты от создания эмулятора.
17 апр 19, 09:35    [21864462]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
ёёёёё
Member

Откуда:
Сообщений: 740
Bimon Subio
Пожалуйста, перечислите эти методы. Хотелось бы узнать и другие способы защиты от создания эмулятора.

Да те же самые, которые сейчас используются "аппаратно, из коробки": путем обеспечения уникальности трафика между приложением и аппаратным ключом защиты.
Например, при реализации шифрования/дешифрования используем симметричные алгоритмы, обладающие взаимно перестановочными свойствами: блок данных перед расшифровкой (например) закрываем софтовым алгоритмом со случайным, всякий раз разным значением дескриптора, отправляем результат для расшифровки на аппаратный ключ, ключ возвращает в приложение данные, закрытые случайным дескриптором, затем в приложении еще раз открываем данные, используя тот же софтовый алгоритмом с тем же исходным дескриптором. Таким образом обеспечивается уникальность трафика между софтом и аппаратным ключом. Табличная эмуляция идет лесом.
Естественно, если утеряны дескрипторы шифрования аппаратного ключа, то "всё", ну тут уже вопрос административный, а не технический.
17 апр 19, 09:54    [21864494]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
ёёёёё
Member

Откуда:
Сообщений: 740
Bimon Subio
Что мешает добавить отладочный хук где-то в самом начале цепочки на пути к "API протектора" когда случайный сессионный Solt еще не подмешан, а зашифрованные данные в начале цепочки статичны при каждом запуске программы, несмотря на то, что на USB канале они случайны, но там их перехватывать никто и не собирается.
Отследить все вызовы и сделать на их базе эмулятор?

Ну, да, что тут сделаешь. Конкретно у нас данные меняются практически с каждым билдом для каждого конкретного юзера, и используемые алгоритмы дешифрования тоже меняются, то есть, каждый раз придется проделывать работу.
17 апр 19, 09:59    [21864499]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
Bimon Subio
Member

Откуда:
Сообщений: 142
ёёёёё
Bimon Subio
Пожалуйста, перечислите эти методы. Хотелось бы узнать и другие способы защиты от создания эмулятора.

Да те же самые, которые сейчас используются "аппаратно, из коробки": путем обеспечения уникальности трафика между приложением и аппаратным ключом защиты.
Например, при реализации шифрования/дешифрования используем симметричные алгоритмы, обладающие взаимно перестановочными свойствами: блок данных перед расшифровкой (например) закрываем софтовым алгоритмом со случайным, всякий раз разным значением дескриптора, отправляем результат для расшифровки на аппаратный ключ, ключ возвращает в приложение данные, закрытые случайным дескриптором, затем в приложении еще раз открываем данные, используя тот же софтовый алгоритмом с тем же исходным дескриптором. Таким образом обеспечивается уникальность трафика между софтом и аппаратным ключом. Табличная эмуляция идет лесом.
Естественно, если утеряны дескрипторы шифрования аппаратного ключа, то "всё", ну тут уже вопрос административный, а не технический.


Вопросы:

1) Зачем вы добавляете случайность внутри протокола Guardant?
Guardant самостоятельно разве не обеспечивает уникальность USB трафика?

2) Как все эти меры по обеспечению уникальности трафика помешают создать эмулятор, описанным мной способом, когда снифят хуками в коде еще до уникализатора? Хоть зауникализируйтесь.

3) Поможет ли наполнение программы большим количеством фрагментов с обращениями к токену и вызов этих фрагментов по нечеткой логике случайным образом очень редко (может быть 1 раз в день/месяц/год). Взломщик замучается ждать столько времени, а время, наверно, можно проверять через токен NET. При обнаружении потери оригинального токена наверно можно втихоря совершать действия, которые мешают использовать защищаемую программу, но еще не подпадают под УК в области компьютерных преступлений.
17 апр 19, 10:07    [21864507]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
ёёёёё
Member

Откуда:
Сообщений: 740
ёёёёё
Bimon Subio
Что мешает добавить отладочный хук где-то в самом начале цепочки на пути к "API протектора" когда случайный сессионный Solt еще не подмешан, а зашифрованные данные в начале цепочки статичны при каждом запуске программы, несмотря на то, что на USB канале они случайны, но там их перехватывать никто и не собирается.
Отследить все вызовы и сделать на их базе эмулятор?

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

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

Ну, дополнительно задействуем алгоритмы ЭЦП: например, общаемся с центральным сервером (находящимся в контролируемой зоне), который требует выполнять подпись всякий раз нового блока данных и на основе результата обеспечивает клиента некими "важными данными", без которых клиент не сможет правильно функционировать. Да, можно воткнуть прокси посередине и "все выловить и подменить", но сие достаточно объемная работа, и снова - лишь до очередного апдейта.
17 апр 19, 10:07    [21864508]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
Bimon Subio
Member

Откуда:
Сообщений: 142
Bimon Subio
При обнаружении потери оригинального токена наверно можно втихоря совершать действия, которые мешают использовать защищаемую программу, но еще не подпадают под УК в области компьютерных преступлений.


Это, наверно, даже явно в условиях лицензионного договора можно прописать, например, что при попытке взлома, качество работы программного обеспечения может снизиться, и что пользователь полностью согласен с этим условием, как и с тем, что лицензионный договор в таком случае будет прекращен с сохранением оплаты за него (, а не отменен с возвратом).
17 апр 19, 10:12    [21864514]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
Bimon Subio
Member

Откуда:
Сообщений: 142
ёёёёё
Bimon Subio
Что мешает добавить отладочный хук где-то в самом начале цепочки на пути к "API протектора" когда случайный сессионный Solt еще не подмешан, а зашифрованные данные в начале цепочки статичны при каждом запуске программы, несмотря на то, что на USB канале они случайны, но там их перехватывать никто и не собирается.
Отследить все вызовы и сделать на их базе эмулятор?

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


Наверно, только выносить часть кода через RPC на охраняемый сервер.
17 апр 19, 10:14    [21864519]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
ёёёёё
Member

Откуда:
Сообщений: 740
Bimon Subio
ёёёёё
пропущено...

Да те же самые, которые сейчас используются "аппаратно, из коробки": путем обеспечения уникальности трафика между приложением и аппаратным ключом защиты.
Например, при реализации шифрования/дешифрования используем симметричные алгоритмы, обладающие взаимно перестановочными свойствами: блок данных перед расшифровкой (например) закрываем софтовым алгоритмом со случайным, всякий раз разным значением дескриптора, отправляем результат для расшифровки на аппаратный ключ, ключ возвращает в приложение данные, закрытые случайным дескриптором, затем в приложении еще раз открываем данные, используя тот же софтовый алгоритмом с тем же исходным дескриптором. Таким образом обеспечивается уникальность трафика между софтом и аппаратным ключом. Табличная эмуляция идет лесом.
Естественно, если утеряны дескрипторы шифрования аппаратного ключа, то "всё", ну тут уже вопрос административный, а не технический.


Вопросы:

1) Зачем вы добавляете случайность внутри протокола Guardant?
Guardant самостоятельно разве не обеспечивает уникальность USB трафика?

2) Как все эти меры по обеспечению уникальности трафика помешают создать эмулятор, описанным мной способом, когда снифят хуками в коде еще до уникализатора? Хоть зауникализируйтесь.

3) Поможет ли наполнение программы большим количеством фрагментов с обращениями к токену и вызов этих фрагментов по нечеткой логике случайным образом очень редко (может быть 1 раз в день/месяц/год). Взломщик замучается ждать столько времени, а время, наверно, можно проверять через токен NET. При обнаружении потери оригинального токена наверно можно втихоря совершать действия, которые мешают использовать защищаемую программу, но еще не подпадают под УК в области компьютерных преступлений.

1. Использовали еще в старых версиях Guardant, когда этого еще не было. А что в новых - тоже неизвестно, ибо ничего, кроме декларации от производителя, не имеем.
2. Исходных данных (которые закрываются/открываются) много, используются нерегулярно, эмулятор просто не соберет все данные за разумное время. Да, если получить исходник программы и знать, что за данные, можно построить табличку. Но до выхода очередного билда.
3. Да, такие приемы описаны и в SDK. И да, вовсе необязательно сразу кричать "все пропало", можно, например, задизэйблить некоторые (всякий раз разные) пункты контекстного меню. Или, например, тупо запускать очередной тред, съедающий ресурсы: программа работает, но медленно. Или память жрет как не в себя.
17 апр 19, 10:15    [21864521]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
Bimon Subio
Member

Откуда:
Сообщений: 142
ёёёёё
ёёёёё
пропущено...

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

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

Ну, дополнительно задействуем алгоритмы ЭЦП: например, общаемся с центральным сервером (находящимся в контролируемой зоне), который требует выполнять подпись всякий раз нового блока данных и на основе результата обеспечивает клиента некими "важными данными", без которых клиент не сможет правильно функционировать. Да, можно воткнуть прокси посередине и "все выловить и подменить", но сие достаточно объемная работа, и снова - лишь до очередного апдейта.


Вы про размещение части кода только на своем охраняемом сервере? А как его можно подменить, если обрабатываемые данные постоянно меняются ?
17 апр 19, 10:17    [21864524]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
ёёёёё
Member

Откуда:
Сообщений: 740
Можно подменить обращение к локальному ключу защиты, да. Все запросы от копий клиента отправляются на единый сервер, а он работает с одним единственным ключом. Быстродействия ключа и сети хватило бы, на какое-то количество копий.

Нужно лишь слой работы с ключом подменить. Лишь.
17 апр 19, 10:29    [21864543]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
Bimon Subio
Member

Откуда:
Сообщений: 142
ёёёёё
Можно подменить обращение к локальному ключу защиты, да. Все запросы от копий клиента отправляются на единый сервер, а он работает с одним единственным ключом. Быстродействия ключа и сети хватило бы, на какое-то количество копий.

Нужно лишь слой работы с ключом подменить. Лишь.


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

А если бы каждый пользователь авторизовался в программе по Rutoken ECP2, то было бы еще проще.
Опять же все зависит от так называемой глубины отлома и защиты наверно тоже :)
17 апр 19, 10:45    [21864574]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
Bimon Subio
Member

Откуда:
Сообщений: 142
Вот еще про Infralution:

https://jaxenter.com/best-licensing-software-for-net-professionals-120766.html

Что-то у них непонятно с поддержкой DotNet Core.
17 апр 19, 10:48    [21864583]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
Bimon Subio
Member

Откуда:
Сообщений: 142
ёёёёё
Можно подменить обращение к локальному ключу защиты, да. Все запросы от копий клиента отправляются на единый сервер, а он работает с одним единственным ключом. Быстродействия ключа и сети хватило бы, на какое-то количество копий.

Нужно лишь слой работы с ключом подменить. Лишь.


Это в смысле из аппаратного ключа НЕ редакции NET такой сделать?

Если прокси навешивать только сбоку там без глубинного взлома, где уже есть уникальность протокола, то почему бы в Guardant глубинно не обеспечивать аутентификацию разных компов по их железу, когда внутри токена будет видна разница, чтобы локальный НЕ NET токен обнаруживал такую аномалию. Может это уже есть в локальных токенах, потому что токен NET ведь как-то подсчитывает количество плавающих лицензий?

Лично я собираюсь использовать Guardant NET+CODE+TIME только для защиты от реверсинга, а применять лицензионные ограничения с помощью других инструментов типа Infralution или Enigma.
17 апр 19, 11:01    [21864603]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли каким то образом задействовать Native UWP в Dekstop приложении?  [new]
ёёёёё
Member

Откуда:
Сообщений: 740
Bimon Subio
ёёёёё
Можно подменить обращение к локальному ключу защиты, да. Все запросы от копий клиента отправляются на единый сервер, а он работает с одним единственным ключом. Быстродействия ключа и сети хватило бы, на какое-то количество копий.

Нужно лишь слой работы с ключом подменить. Лишь.


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


Ну мы вроде как рассматриваем "полный взлом", когда клиентский код весь доступен, понятен и легко модифицируется. Или до такого маразма все же не будем опускаться?
17 апр 19, 11:21    [21864638]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5   вперед  Ctrl      все
Все форумы / WinForms, .Net Framework Ответить