Обфускация на уровне исходного кода более эффективна, чем обфускаторы? - PullRequest
4 голосов
/ 05 января 2009

Извлеченные из моего последнего вопроса , большинство имен участников , похоже, включены в выходные данные проекта.

Глядя на некоторые декомпиляторы, такие как 9 лучей , Саламандра , Джунгли , многие методы запутывания, похоже, уже побеждены, есть одно особенно страшное утверждение:

Автоматически удаляет строковое шифрование, введенное обфускатором ~ Salamander

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

Ответы [ 8 ]

21 голосов
/ 05 января 2009

Запутывание исходного кода будет самоубийством в плане обслуживания.

Если ваш проект настолько «секретный», я думаю, у вас есть два варианта:

  • Поместите «секретный» код собственности за службой на сервере, которым вы управляете

  • Кодируйте его на языке, который не так легко декомпилировать, как C / C ++

11 голосов
/ 05 января 2009

Может быть, спорный, но вы будете уничтожать ремонтопригодность, чтобы сделать это.

Это действительно того стоит?

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

9 голосов
/ 05 января 2009

Как говорили люди, запутывание - это поднятие планки. Если вы запутаете свою сборку, вы остановите случайного разработчика, который просто любопытен, но вы не остановите слегка мотивированного человека от реверс-инжиниринга.

Если вы хотите поднять планку немного дальше, многие инструменты запутывания позволяют использовать непечатаемые символы в качестве имен элементов. использовать отражатель на себя, чтобы посмотреть. Это остановит гораздо больше людей, я мог бы взглянуть на запутанный код, чтобы понять его, но если я не смогу прочитать его, я не собираюсь испытывать боль от сброса его в IL и переименования всех членов вручную, у меня нет мотивации тратить столько времени.

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

Есть также некоторые приемы, которые вы можете использовать для разрушения отражателя (в некоторых случаях Obfuscator из PreEmptive ломает отражатель, но, конечно, вы все равно можете прочитать IL). Однажды у меня был интересный разговор с разработчиком инструмента для запутывания, и я не смогу сделать это правильно, но у него был способ полностью сломать рефлектор, динамически перемещая код. Например, один момент в вашей функции а затем вы перейдете к середине функции б. Создайте эту причину, чтобы PEVerify вызывал ошибки, чтобы они никогда не реализовывали это, но это была хорошая идея.

3 голосов
/ 05 января 2009

Аннаката верна. На самом деле все, что вы можете сделать, - это сделать его более трудным (и дорогостоящим) для обратного инжиниринга программного обеспечения.

Моя компания определила несколько областей, в которых мы хотели максимально усложнить реверс-инжиниринг. Например, наши файлы представляют собой двоичный формат, который каждый объект в нашей иерархии отвечает за сохранение себя и считывание правильной версии. Это означает, что для человека, который будет читать наши файлы, он будет копировать всю нашу иерархию в коде, который он создает для чтения наших файлов. Кроме того, большая часть информации в файле Job полезна без соответствующего бита в файлах стандартов магазина. Таким образом, они должны выполнить работу дважды, чтобы понять, что говорится в файле задания.

Несколько критических областей (защита ключа, связь с нашими металлорежущими станками) находятся в Win32DLL. Это означает, что они должны знать сборку и как сделать DLL, которая реплицирует другие сигнатуры DLL, чтобы перепроектировать наше программное обеспечение. Плюс наш дизайн с нашим программным обеспечением CAM заключается в том, что он очень интерактивен с режущим станком (обмен информацией происходит постоянно)

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

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

В вашем случае вам нужно будет спросить себя, какая часть вашего программного обеспечения будет интересна вашим конкурентам, и действовать дальше. Если вы являетесь разработчиком вертикального рынка (управление машиной, специализированный учет и т. Д.), Я предлагаю использовать USB-ключ для управления программным обеспечением.

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

2 голосов
/ 05 января 2009

Я встревожен, что вы даже рассматриваете запутывание на уровне кода. Разве вы не будете запутывать код для себя тоже? Как вы намереваетесь когда-нибудь снова поработать над этим? Ради ремонтопригодности этого делать не следует.

Но учтите это: -

Предположим, что есть сценарий / приложение, которое вы можете запустить, которое откроет ваш проект и хитро запутает каждую строку / имя переменной в вашем проекте, и вы скомпилировали его позже, пока ваш исходный код надежно не тронут в отдельном месте.

Теперь это какая-то идея.

2 голосов
/ 05 января 2009

Проблема в том, что вы будете жертвовать читабельностью, чтобы сделать это. Если ваш проект является священным для защиты, я считаю, что можно предположить две вещи:

  1. Проект настолько велик, что хит читаемости вернется, чтобы укусить вас за задницу.
  2. Люди, которые хотят перепроектировать это, сделают это так или иначе. Для того, чтобы определить, что нужно делать, потребуется немного больший интеллект (вместо того, чтобы просто читать имена членов).
1 голос
/ 04 января 2011

вы можете использовать такую ​​технику: http://g.palem.in/SecureAssembly.html используя это, вы пишете в .net, но встраиваете в исполняемый файл c ++ свой исполняемый файл .net,

1 голос
/ 18 апреля 2009

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

...