Занимался тут подбором обфускатора для нашей компании, остановился на CodeVeil, судя по всему достаточно мощная штука (хотя и дорогая), по крайней мере в сравнении с теми, что нашел
Интересует такой момент, в его документации есть такая информация:
Runtime Protection
Anti-Modification When your assembly is first loaded the executive uses the encrypted version of your assembly as a decryption key to decode key portions of itself. Any unauthorized modifications to the assembly will corrupt this process preventing the assembly from loading properly. No MSIL will ever by decrypted
Anti-Debugging
When Kill Debuggers is selected in the assembly options, CodeVeil injects additional instructions that will wreak havoc on debuggers that attempt to attach to a veiled process and perform any debugging operations. CodeVeil uses many different anti-debugging techniques — some well known, others designed by XHEO — so that overcoming one block does not expose other portions of the code.
Component developers should carefully consider the use of this option. Using Kill Debuggers will prevent developers using the components from debugging any software that uses the components.
Anti-Tracing Tracing is a debugging technique used to map execution paths and is used to isolate code involved in performing specific operations. The Anti-Debugging features will prevent tracing of the execution path of the assembly. CodeVeil adds additional code that will execute alternate instruction paths when traced so that the true execution path is not revealed.
Anti-Dumping One common technique for disassembly encrypted applications is to run the application, then save the in-memory version of the application to disk. The dumped version can then be modified by the hacker and then reloaded in its decrypted state. The CodeVeil decryption system is unique in that the in memory version of the assembly is almost identical to the encrypted on-disk version. The only changes are those to break the assembly once reloaded. The decrypted code cannot be dumped from memory
Anti-Profiling The .NET runtime has special points of entry for profilers that allow them to see and modify assemblies at runtime. When Kill Profilers is selected CodeVeil will prevent the process from loading the veiled assembly and eliminate the threat.
Anti-Reflection Not strictly a runtime feature, Anti-Reflection is added when the assembly is veiled with Kill Reflectors selected. This junk meta-data will crash or severely impair a .NET disassembly tool such as Reflector and ILDASM from accessing the good meta-data. This can cause problems with 3rd party controls that use reflection to discover properties about your assembly
т.е. и рефлекторы крушит, и дебаггеры и прочее.
Я пробовал открыть обфусцированную сборку Рефлектором (от ред гейт) — действительно рефлектор выбрасывает ошибку.
Остальные функции и другие дисассемблеры не проверял, все-таки я не хакер. Но вот что-то слабо верится, что взломать сборку не получится, наверняка есть софт, способный обходить такую защиту.
Кто-нибудь сталкивался с таким ? Насколько заявленная защита повышает уровень защищенности ? Или при использовании чуть более продвинутого хакерского софта (типа софт айс) вся эта Anti-Debugging, Anti-Reflection и Anti-Dumping защита отключается на счет раз ?
Re: Надежность Anti-Debugging, Anti-Dumping и пр. зашиты
Здравствуйте, Stalker., Вы писали:
S>Занимался тут подбором обфускатора для нашей компании, остановился на CodeVeil, судя по всему достаточно мощная штука (хотя и дорогая), по крайней мере в сравнении с теми, что нашел
S>Остальные функции и другие дисассемблеры не проверял, все-таки я не хакер. Но вот что-то слабо верится, что взломать сборку не получится, наверняка есть софт, способный обходить такую защиту. S>Кто-нибудь сталкивался с таким ? Насколько заявленная защита повышает уровень защищенности ? Или при использовании чуть более продвинутого хакерского софта (типа софт айс) вся эта Anti-Debugging, Anti-Reflection и Anti-Dumping защита отключается на счет раз ?
Возможно, скажу банальность, но все же.
К сожалению, любая программа должна быть не только закрыта так, чтобы ее код никто не смог понять, но ее потом надо еще и распаковать так, чтобы она смогла выполниться. А это значит, что если кто-то захочет эту защиту сломать — он ее сломает . По-нормальному, есть где-то три уровня защиты (я имею ввиду не защиту от пользователей, а именно защиту кода):
1. "Неуловимый Джо". Код программы реализуется за время, сопоставимое со временем, затраченным на понимание логики ее работы. Нафиг туда включать защиту, я не знаю. Под это определение, кстати, подпадает около 80% программ (понятно, что я не поделки студентов имею ввиду).
2. Средний уровень. Программу уже дешевле "хакнуть", чем написать самому, но еще не на столько, чтобы нанимать толкового хакера. В большинстве случаев защиты от просмотра кода рефлектором более чем достаточно.
3. Серьезные и дорогостоящие научные разработки, или идеи, за которыми реально будут охотиться крупные конкуренты. Не спасет ничего, кроме грамотного юридического отдела и людей, которые будут периодически отслеживать продукты конкурентов. Перемудривать с защитой здесь, как ни странно, тоже особо не стоит — по крайней мере не стоит ставить защиту, которая будет стоить больше, чем обойдется конкурентам "купить" вашего ведущего разработкика .
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете". (с) Макконнелл, "Совершенный код".
Re: Надежность Anti-Debugging, Anti-Dumping и пр. зашиты
Здравствуйте, Stalker., Вы писали:
S>Кто-нибудь сталкивался с таким ? Насколько заявленная защита повышает уровень защищенности ? Или при использовании чуть более продвинутого хакерского софта (типа софт айс) вся эта Anti-Debugging, Anti-Reflection и Anti-Dumping защита отключается на счет раз ?
Напиши простейшую прогу: окно, поле ввода, если вводишь "правильную" фразу, то вываливается мессага "Все ок". Запакуй, обфусцируй своей защитой и выложи сюда. А мы глянем
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[2]: Надежность Anti-Debugging, Anti-Dumping и пр. зашиты
Здравствуйте, HotDog, Вы писали:
HD>Напиши простейшую прогу: окно, поле ввода, если вводишь "правильную" фразу, то вываливается мессага "Все ок". Запакуй, обфусцируй своей защитой и выложи сюда. А мы глянем
.NET Reflector при попытке открыть сборку падает с исключением
А цель защиты вовсе не в бесценности идей конечно, а в попытках осложнить хак программы для доступа и порчи данных, с которыми данная программа будет работать
Re[3]: Надежность Anti-Debugging, Anti-Dumping и пр. зашиты
Здравствуйте, hi_octane, Вы писали:
_>время лома: минуты 2
Шаман? Снимаю шляпу за уважение перед таким временем (если правда, конечно), бо защита весьма не плоха. ИМХО, разумеется, и, само-собой, невскрываемых программ не бывает. Это уже без всякой ИМХи.
Re[4]: Надежность Anti-Debugging, Anti-Dumping и пр. зашиты
От:
Аноним
Дата:
25.06.09 12:43
Оценка:
Здравствуйте, hi_octane, Вы писали: _>фраза: I must be a bloody cool hacker to hack it ! _>время лома: минуты 2
_>защита codeVeil не фонтан, но если их сравнивать то только наверное с платным дотфускатором.
Давай делись как. :D А то так не интересно
Просим! Просим!
Re[5]: Надежность Anti-Debugging, Anti-Dumping и пр. зашиты
А>Давай делись как. :D А то так не интересно А>Просим! Просим!
Запустил прогу. Появилось поле ввода — нажал Test. Вылетело окно сообщения что текст неверен. Подключился студийным отладчиком, глянул в дизассемблер — в коде метода T.U.V было два невиртуальных вызова в недра .NET, поставил на них брякпойнты, сработал первый же (у меня — 00000024 call 76010BD0) — это был вызов string.Equals, в который искомая строка была передана открытым текстом.
Есть второй способ — основанный на том что известно чем защитили сборку — и CodeVeil и Dotfuscator, и многие другие — они вставляют вызовы на свои методы дешифровки. Сами методы дешифровки достаточно просты и можно пройтись по всем местам вызовов и получить все зашифрованные строки в чистом виде. Ну или брякпойнт поставить — и получить шифрованную строку во время работы приложения — зная что строка одна — это было бы ещё быстрее, но не совсем честно.
И я не крякер, а программист/пм, просто навыков хватает. В рабочее место тру-крякера включены — самособранный .NET, в котором можно любое место в коде не только подебажить но и переписать, собственный загрузчик сборок, генератор прокси-сборок — чтобы перехватывать любые вызовы между сборками, перехватчик JIT'а — чтобы получать на руки тот IL который идёт на исполнение, вместо того что лежит в сборке/ресурсах, и куча самописных аддонов к рефлектору. Лично видел — человека оснащённого таким инструментарием никакой защитой не остановить.
Поэтому если делаете продукт на продажу (шаровару там какую) — защищайте любым который прикроет алгоритмы от декомпиляции запутыванием графа вызовов, и, по-возможности, обломает рефлектор. От взлома защиты это не спасёт, но зато спасёт от индусов/китайцев которые слишком уж успешно софтины копируют передирая код целыми сборками. А ключик взломают или скардят. Скорее скардят — это легко и дёшево.
Здравствуйте, hi_octane, Вы писали:
_>И я не крякер, а программист/пм, просто навыков хватает.
В голове сразу же нарисовалась картина: подхожу я такой к ПМ-у — ну типа как обычно, деньги кончились, надо вместе придумать, как бы еще с клиента содрать — а он такой весь сидит в дотнете собственной сборки, брейкпоинтами обложился, перехватчик Джита ковыряет и, извиняюсь за выражение, хачит что-то.
Боюсь, меня бы увезли
Re[7]: Надежность Anti-Debugging, Anti-Dumping и пр. зашиты
От:
Аноним
Дата:
25.06.09 21:21
Оценка:
ВВ>В голове сразу же нарисовалась картина: подхожу я такой к ПМ-у — ну типа как обычно, деньги кончились, надо вместе придумать, как бы еще с клиента содрать — а он такой весь сидит в дотнете собственной сборки, брейкпоинтами обложился, перехватчик Джита ковыряет и, извиняюсь за выражение, хачит что-то. ВВ>Боюсь, меня бы увезли
Re[7]: Надежность Anti-Debugging, Anti-Dumping и пр. зашиты
ВВ>В голове сразу же нарисовалась картина: подхожу я такой к ПМ-у — ну типа как обычно, деньги кончились, надо вместе придумать, как бы еще с клиента содрать — а он такой весь сидит в дотнете собственной сборки, брейкпоинтами обложился, перехватчик Джита ковыряет и, извиняюсь за выражение, хачит что-то.
Так настоящего тру-крякера я описал место, не своё. Что-б люди имели представление кто сидит на той стороне баррикад и что защита проги — практически бесполезное занятие, что бы там рекламисты средств защиты не писали.
У меня всё больше как у нормальных пм — ворд, эксель, аутлук, скайп... Даже студию держу в основном из-за Nemerle.
Re[8]: Надежность Anti-Debugging, Anti-Dumping и пр. зашиты
Здравствуйте, hi_octane, Вы писали:
_>У меня всё больше как у нормальных пм — ворд, эксель, аутлук, скайп... Даже студию держу в основном из-за Nemerle.
Вот вам и Anti-Debugging Ну ладно, хоть на сколько-то осложнит взлом, и то ладно
_>Запустил прогу. Появилось поле ввода — нажал Test. Вылетело окно сообщения что текст неверен. Подключился студийным отладчиком, глянул в дизассемблер — в коде метода T.U.V было два невиртуальных вызова в недра .NET, поставил на них брякпойнты, сработал первый же (у меня — 00000024 call 76010BD0) — это был вызов string.Equals, в который искомая строка была передана открытым текстом.
а названия библиотечных функций .NET там видны ?
Re[7]: Надежность Anti-Debugging, Anti-Dumping и пр. зашиты
S>а названия библиотечных функций .NET там видны ?
В дизассемблере? У меня и других нормальных разработчиков — нет. Только переходы на физические адреса, но при определённом опыте можно на глаз отличать — это вызов в системную либку, это в том же приложении которое отлаживаем, и т.п. Кроме того при входе внутрь метода по F11 показывается call-stack в котором видно в каком методе находимся.
А вот если стоит кастомизированная реализация jit-а — то в комментах вполне можно видеть именно IL из которого генерирован ассемблерный код, а в IL все имена на месте — и типов и методов — такое читается очень легко, даже не смотря на запутывание из кучи переходов которое вставляют обфускаторы.
Re[9]: Надежность Anti-Debugging, Anti-Dumping и пр. зашиты