Здравствуйте, Sharov, Вы писали:
S>А чего сразу весь managed код не заобфусцировать? Ну или часть.
А смысла никакого нет.
Во-первых, в 99% случаев идеально работает защита неуловимого Джо.
Ну ок — добыли конкуренты исходники продукта, что они с ним делать будут?
Продавать впрямую — палево. Развивать самостоятельно — не потянут, ибо воспроизвести весь процесс разработки малореально, а без него от кода толку 0. Заимствовать куски инфраструктурного кода — в большинстве случаев проще с гитхаба/stackoverflow оригинал взять.
Во-вторых, обходится оно элементарно, unpackme для того же .net reactor — дело пары часов, вот относительно свежий пример.
Пока есть managed-код — есть возможность без особых проблем его поменять.
Пытаемся перевести в натив — начинаются веселейшие баги, от падений биндинга и до повреждения сериализуемых данных (как правило тут вина не самого обфускатора, а некорректной настройки, но тем не менее).
В третьих, как показывает практика, те, кто готовы использовать взломанный вариант, покупать не будут всё равно.
В общем, лучше потратить время на то, что реально нужно клиентам — всяко больше пользы будет.
Здравствуйте, Sharov, Вы писали:
GZ>>В этом случае проще шифровать и дешифровывать код в процессе исполнения. Те же яйца — но покруче. В managed такое невозможно.
S>Почему? Если есть соотв. поддержка со стороны jit(clr).
Хочется самомодифицирующего кода — всегда можно написать виртуальную машину форта, на форте самомодифицирующуюся виртуальную машину брейнфака, на брейнфаке переписать части алгоритма (типа, полиморфный компилятор си в брейнфак), и угорать. Проверенный годами надежный способ. Если не хочется ходить неделю с головой задом наперед, можно поменять форт на мадлен или ассемблер м20.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Sharov, Вы писали:
S>>Так я все это прекрасно понимаю и полностью согласен. Я не понял в чем фишка обфусцировать unmanagend код, по сравнению с managed? Мож как фундаментальная разница есть, и деобфусцировать managed проще. Вот и спросил. GZ>Обсфукация unmanaged — это нонсенс.
Нет, это прекрасная штука тоже.
Берем исходники на С, запихиваем в них в сто раз больше по объему, чем было, автогенерированного когда, который ничего не делает, и компилируем. Добавляет массу удовольствия дизассемблирующему. Строки шифровать, опять же, полезно независимо от языка и среды.
Здравствуйте, α, Вы писали:
α>Что бы еще такое придумать, чтобы сборка .NET прям вот жить не могла без нативной защищёной DLL и чтобы работа по эмулированию функционала из нативной DLL под .NET оказалась максимально трудоёмкой?
Ключевые функции бизнес-логики.
α>функции работы со строками, константы, перечисления
Думаю все это легко отлавливается в полной версии и при желании легко эмулируется. А вот переписать BL это по сути что и переписать половину приложения.
Здравствуйте, Sharov, Вы писали:
S>Так я все это прекрасно понимаю и полностью согласен. Я не понял в чем фишка обфусцировать unmanagend код, по сравнению с managed? Мож как фундаментальная разница есть, и деобфусцировать managed проще. Вот и спросил.
Обсфукация unmanaged — это нонсенс. Это как мужика обследовать на беременность. Обсфукация — это запутываи имен и метаданных. В unmanaged все хуже, потому что имен и метаданных нет (ну по крайней мере человекочитабельных). Обсфуцировать нечего.
Про обфускацию я в курсе, а других способов защиты вроде бы и нет?
Думаю вынести определенный функционал в C++ DLL, защитить ее VMProtect-ом и наладить общение с ней через pinvoke.
Какой функционал можно переложить с .NET на С++? Навскидку: функции работы со строками, константы, перечисления, определения интерфейсов. Что бы еще такое придумать, чтобы сборка .NET прям вот жить не могла без нативной защищёной DLL и чтобы работа по эмулированию функционала из нативной DLL под .NET оказалась максимально трудоёмкой?
Здравствуйте, Sinix, Вы писали:
S>Во-первых, в 99% случаев идеально работает защита неуловимого Джо.
S>В общем, лучше потратить время на то, что реально нужно клиентам — всяко больше пользы будет.
Так я все это прекрасно понимаю и полностью согласен. Я не понял в чем фишка обфусцировать unmanagend код, по сравнению с managed? Мож как фундаментальная разница есть, и деобфусцировать managed проще. Вот и спросил.
Здравствуйте, Sharov, Вы писали:
S>Так я все это прекрасно понимаю и полностью согласен. Я не понял в чем фишка обфусцировать unmanagend код, по сравнению с managed? Мож как фундаментальная разница есть, и деобфусцировать managed проще. Вот и спросил.
Да речь шла не об обфускации unmanaged, а об усложнении взлома выносом туда части функционала
Я бы на С++ написал не DLL, а EXE, в котором "поднял" хост .Net и загрузил нужные сборки.
EXE может предоставить сборкам при при инициализции ссылки на несколько функций, важных для программы, и реализованных на C++. К этим функциям обращаться по мере надобности из .Net.
Свою .Net сборку можно вообще в ресурсы EXE положить в "зашифрованном" виде, потом загрузить из памяти.
Для недалеких хакеров этого будет достаточно, а профессионалы сломают что угодно.
Здравствуйте, α, Вы писали:
α>Про обфускацию я в курсе, а других способов защиты вроде бы и нет? α>Думаю вынести определенный функционал в C++ DLL, защитить ее VMProtect-ом и наладить общение с ней через pinvoke. α>Какой функционал можно переложить с .NET на С++? Навскидку: функции работы со строками, константы, перечисления, определения интерфейсов. Что бы еще такое придумать, чтобы сборка .NET прям вот жить не могла без нативной защищёной DLL и чтобы работа по эмулированию функционала из нативной DLL под .NET оказалась максимально трудоёмкой?
Неплохо бы узнать цель. Например: я хочу чтобы мою библиотеку никто не мог использовать. Или хочу чтобы программу не могли нелицензионно использовать. Или не хочу чтобы поняли какой алгоритм заложен в программу.
По конкретному, не использование библиотеки, двойной xor возвращает то же значение. Берешь хеш сборки, ксоришь с определенным числом, получаешь ключ. А затем по алгоритмам некоторые числа получаешь другим ксором с полученным ключом. Если сборка была изменена — то работать будет не так.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Sharov, Вы писали:
S>>Так я все это прекрасно понимаю и полностью согласен. Я не понял в чем фишка обфусцировать unmanagend код, по сравнению с managed? Мож как фундаментальная разница есть, и деобфусцировать managed проще. Вот и спросил. GZ>Обсфукация unmanaged — это нонсенс. Это как мужика обследовать на беременность. Обсфукация — это запутываи имен и метаданных. В unmanaged все хуже, потому что имен и метаданных нет (ну по крайней мере человекочитабельных). Обсфуцировать нечего.
Да, это я маху дал... Для unmanaged есть всяческие PE-упаковщики заголовков и т.д., вот их я имел в виду.
Здравствуйте, Sharowarsheg, Вы писали:
S>Берем исходники на С, запихиваем в них в сто раз больше по объему, чем было, автогенерированного когда, который ничего не делает, и компилируем. Добавляет массу удовольствия дизассемблирующему. Строки шифровать, опять же, полезно независимо от языка и среды.
В этом случае проще шифровать и дешифровывать код в процессе исполнения. Те же яйца — но покруче. В managed такое невозможно.
S>>Берем исходники на С, запихиваем в них в сто раз больше по объему, чем было, автогенерированного когда, который ничего не делает, и компилируем. Добавляет массу удовольствия дизассемблирующему. Строки шифровать, опять же, полезно независимо от языка и среды. GZ>В этом случае проще шифровать и дешифровывать код в процессе исполнения. Те же яйца — но покруче.
Здравствуйте, GlebZ, Вы писали:
GZ>В этом случае проще шифровать и дешифровывать код в процессе исполнения. Те же яйца — но покруче. В managed такое невозможно.
Почему? Если есть соотв. поддержка со стороны jit(clr).
Здравствуйте, Sinix, Вы писали:
S>В третьих, как показывает практика, те, кто готовы использовать взломанный вариант, покупать не будут всё равно.
Знаю несколько не самых бедных компаний, если долгосрочный постоянно используемый софт ещё купят, опасаясь проверок, то редко используемый, при наличии кряка ... хотя деньги есть.
Здравствуйте, GlebZ, Вы писали:
GZ>Обсфукация unmanaged — это нонсенс.
Под обфускацией unmanaged обычно понимают модификацию CFG/DFG, а не просто переименование. Также не стоит сбрасывать со счетов полезность оставленной в бинарях метаинформации.
Многие техники для unmanaged кода работают и на managed. В частности, виртуализация кода.
Шифрование строк и прочие глупости работают только против совсем уж детей.
.jpg)
... хотя деньги есть.
