Здравствуйте, Poseidon, Вы писали:

P>Друзья, отстал от жизни. Был у меня Armadillo, ещё до того как его с треском взломали.... А что теперь? Хотелось бы как минимум обфускатор, защитить код программы. Ну и желательно какую то схему генерации и проверки ключей. Или мухи отдельно, котлеты отдельно?

Так ведь было же уже:
http://rsdn.org/forum/shareware/7703537.all

Автор: sergey2b
Дата: 11.04.20

А что там нынче с DotNet Core RT и Mono AOT — компиляция в native, вроде бы в DotNet Core v6 обещают уже официальную поддержку?
Если сначала обработать Eazfuscator-ом, а потом скомпилировать в native, то так получится?
Вероятно придется отказаться от reflection, ну можно же только часть кода так защитить, например какую-нибудь особо важную свою библиотеку?
После компиляции в native ее уже не вызвать как managed, только через cdecl?

Вот еще понравились примеры вызова нативных либ, скомпиленных на GO:
https://github.com/vladimirvivien/go-cshared-examples

Наверно, с DotNet -> native такие фокусы тоже возможны?

А по активации наверно https://www.guardant.ru/ ?

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

Т.е. приготовить либу примерно так: DotNet либа -> Eazfuscator -> DotNet компилятор в native -> EnigmaProtector

А потом даже если ее отстригнут от основного DotNet приложения, то только вместе с важным в ней функционалом, после чего приложение придется переписывать самостоятельно, а у кулхацкеров останется только отвязанный от защиты GUI, который кстати можно все же завернуть хотя бы одним обфускатором без native компиляции типа Eazfuscator или Babelfor.

Здравствуйте, Poseidon, Вы писали:

P>Друзья, отстал от жизни. Был у меня Armadillo, ещё до того как его с треском взломали.... А что теперь? Хотелось бы как минимум обфускатор, защитить код программы. Ну и желательно какую то схему генерации и проверки ключей. Или мухи отдельно, котлеты отдельно?

Так ведь было же уже:
http://rsdn.org/forum/shareware/7703537.all

Автор: sergey2b
Дата: 11.04.20

А что там нынче с DotNet Core RT и Mono AOT — компиляция в native, вроде бы в DotNet Core v6 обещают уже официальную поддержку?
Если сначала обработать Eazfuscator-ом, а потом скомпилировать в native, то так получится?
Вероятно придется отказаться от reflection, ну можно же только часть кода так защитить, например какую-нибудь особо важную свою библиотеку?
После компиляции в native ее уже не вызвать как managed, только через cdecl?

Вот еще понравились примеры вызова нативных либ, скомпиленных на GO:
https://github.com/vladimirvivien/go-cshared-examples

Наверно, с DotNet -> native такие фокусы тоже возможны?

А по активации наверно https://www.guardant.ru/ ?

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

Т.е. приготовить либу примерно так: DotNet либа -> Eazfuscator -> DotNet компилятор в native -> EnigmaProtector

А потом даже если ее отстригнут от основного DotNet приложения, то только вместе с важным в ней функционалом, после чего приложение придется переписывать самостоятельно, а у кулхацкеров останется только отвязанный от защиты GUI, который кстати можно все же завернуть хотя бы одним обфускатором без native компиляции типа Eazfuscator или Babelfor.

И если такую нативно защищенную либу распространять, как BLOB ресурс DotNet приложения, то вероятно и антивирусы не будут злобствовать, как если бы просто защитить Энигмой executable ?