Реверс-инжиниринг приложений Защита/упрочнение

Я хочу защитить свои приложения от обратной разработки.

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

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

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

Язык разработки — C++, но я бы с удовольствием взял примеры из любого языка.

Спасибо заранее за любую помощь.


person Cno0b    schedule 30.06.2010    source источник
comment
Что вы защищаете и от кого?   -  person jk.    schedule 30.06.2010


Ответы (5)


Боюсь, это не так просто.

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

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


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

person JoeG    schedule 30.06.2010

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

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

Взывайте к честности людей, это проще для вас и, наверное, так же эффективно!

person Peter    schedule 30.06.2010

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

Упаковщики используются коммерческим программным обеспечением для максимального запутывания и уменьшения размера двоичного файла за счет его возможностей сжатия. Они также используются (в основном) примитивными вредоносными программами. Будьте осторожны, так как многие AV пометят ваш двоичный файл как вредоносное ПО только для того, чтобы распознать наличие упаковщиков и самомодифицирующегося/запутанного кода.

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

Единственный правильный/непреодолимый (без ускорения) способ сделать это — зашифровать код с помощью надежного алгоритма, такого как AES, а затем расшифровать его с помощью ключа во время выполнения, но то пользователю нужен ключ для его запуска. Предварительно общий ключ/парольная фраза или коммерчески популярный ключ являются наиболее распространенными, как упоминалось ранее.)

EDIT: большинство упаковщиков и крипторов после компиляции по большей части не зависят от языка.

person adam    schedule 09.04.2017

Единственное решение, которое действительно предотвращает подделку вашего программного обеспечения, - это шифрование исполняемого файла и расшифровка только тех его частей, которые выполняются в данный момент, и только если расшифровка выполняется на «доверенном устройстве», например. USB-ключ.

Есть некоторые продукты, которые довольно хороши, например. продукт моего работодателя.

Все программные схемы защиты можно более или менее легко обмануть.

person ur.    schedule 30.06.2010
comment
Это не особо защищает. Такие схемы защиты были взломаны путем простого извлечения кода во время его расшифровки и восстановления расшифрованной версии. Если бы часть кода выполнялась на самом ключе, это была бы другая ситуация. Эмпирическое правило: если он когда-нибудь запустится на моем процессоре, я смогу его украсть. - person Vladimir Panteleev; 30.06.2010
comment
@CyberShadow: Вообще говоря, вы правы, но можно сделать это слишком сложным, чтобы быть экономически обоснованным. Есть контрмеры, и одну я уже упоминал: никогда не расшифровывать весь двоичный файл сразу. Используйте более одного ключа для разных частей исполняемого файла. Сражайтесь с известными отладчиками. ... - person ur.; 01.07.2010

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

person Frank R.    schedule 02.07.2010