продизассемблировать уж точно
насчет трассировки...в принципе с правами администратора чего-нибудь сделать можно
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Asm для Windows/Dos > защита от трассировки |
| Автор: _El_ 22.11.2007, 21:53 |
| Как лучше всего защитить программу от дизассемблирования и трассировки? |
| Автор: MAKCim 22.11.2007, 22:31 |
| если кто-то действительно захочет дизассемблировать и протрассировать твою программу, то он это в любом случае сможет сделать продизассемблировать уж точно насчет трассировки...в принципе с правами администратора чего-нибудь сделать можно |
| Автор: Akina 22.11.2007, 22:43 |
| Есть только один способ "защитить программу от дизассемблирования и трассировки" - административно-физический. Т.е. не допустить попадание копии туда, где ее могут трассировать или дизассемблировать. Однако эти процессы можно сильно ЗАТРУДНИТЬ. Вплоть до того, что эти процессы станут нецелесообразными - стоимость или время работы превысят все допустимые пределы. Тогда программу просто никто не станет ломать - как того неуловимого Джо, которого никто не может поймать, ибо нахрен никому не надо.  А самый простой способ - вообще ее не писАть.  |
| Автор: MAKCim 22.11.2007, 22:59 | ||
дизассемблирование да можно сделать код очень трудным для понимания а с трассировкой... против DR3-DR0 + защиты по GD спасения, имхо, нет |
| Автор: dumb 23.11.2007, 01:55 |
| при такой постановке вопроса, лучшее, что можно посоветовать - навесной протектор. |
| Автор: Akina 27.11.2007, 23:52 | ||
Угу... ты "бешеный код" трассировать пробовал? |
| Автор: MAKCim 28.11.2007, 13:59 | ||
что есть "бешеный код"? я такую формулировку нигде не встречал?  |
| Автор: Akina 28.11.2007, 14:27 | ||
Это код, который сам выполняется в режиме отладки, причем обработчик постоянно модифицирует как исполняемый код, так и точку возврата. Количество вызовов отладчика (и модификаций кода) составляет десятки и сотни тысяч. Это приводит к необходимости при трассировке на каждом шаге сохранять среду исполнения и восстанавливать либо эмулировать модификацию среды, что увеличивает время исполнения при трассировке на 4-5 порядков. Впрочем, это не защищает от трассировки методом контроля шин - однако таких станков промышленно не делают. |
| Автор: MAKCim 28.11.2007, 16:22 | ||
обработчик чего? |
| Автор: Akina 28.11.2007, 16:40 | ||
В самой программе (не трассировщике!) ставится обработчик пошагового исполнения. Т.е. фактически программа трассирует саму себя. Этот процесс трассировать архи-непросто. |
| Автор: MAKCim 28.11.2007, 16:45 | ||
ну так можно поставить свой обработчик на #DB перед трассировкой в итоге до обработчика в самой программе дело не дойдет |
| Автор: Akina 28.11.2007, 16:49 | ||
Ты не забывай, что этот обработчик модифицирует и код, и точку возврата программы... к тому же пользуя для этого как данные содержимое стека... как ты его собрался объезжать? |
| Автор: MAKCim 28.11.2007, 16:59 |
| Akina, пошаговая трассировка включается либо через TF, либо через int3 после каждой инструкции при этом генерируется либо #DB, либо #BP пишем драйвер заменяем адреса обработчиков в соответствующих дескрипторах IDT на свои в них при возникновении исключения проверяем, в контексте какого процесса оно произошло если в контексте трассируемого, то просто выходим из обработчика (через iretd на следующую после int3 (или TF) инструкцию) иначе - передаем управление на оригинальный обработчик #DB или #BP в итоге обработчик в самой программе не будет вызываться, а значит и не будет самомодификации кода и пр. |
| Автор: Akina 28.11.2007, 18:33 | ||
И после отработки вместо окончательного, рабочего, кода, который должен получиться в результате модификаций, получаем черт знает что. |
| Автор: dumb 28.11.2007, 18:33 |
MAKCim, не, ты не допонял - если ты отрубишь обработчик, то и программа работать не будет.  смысл такой, что обработчик трассировочного прерывания является неким "клубком Ариадны". т.е. кусок кода зашифрован и перемешан - при входе в него включаем трассировку, и после выполнения каждой инструкции обработчик "вытаскивает" следущую и раскриптовывает ее. при этом во избежание дампа предыдущая инструкция может быть обратно зашифрована.вообще, это трассировать тяжеловато, а снимается довольно элементарно... ВМы тут же надо упомянуть... а вообще, все это - "суета сует и томление духа" (с) |
| Автор: MAKCim 28.11.2007, 18:40 |
| dumb, Akina, все, я понял что вы имеете в виду тогда будет сложновато |
| Автор: mb78 12.7.2008, 00:13 |
| Чтобы код трудно было понять можно его зашифровать(часть кода),а затем программно расшифровать и перейти по нему,правда в ассемблере это сделать не так просто,лучше использовать тот же самый отладчик.Чем больше раз вы его зашифруете,тем больше шансов,что тому,кто его будет расшифровывать это надоест. Освободиться от трассировки так: 1)CLI -ЗАПРЕЩАЕМ ВСЕ ПРЕРЫВАНИЯ,В ТОМ ЧИСЛЕ И ТРАССИРОВКУ 2)Делаем перехват прерывания трассировки(вписываем переход на адрес,который будет например зависать программу или выходить из нее). 3)STI -возобновляем нормальную работу компьютера. |
| Автор: dumb 22.7.2008, 20:39 | ||
afair soft-ice на это лОжил. |
| Автор: CrackMe 12.1.2009, 04:29 |
| по сабжу, из актуального на сегодня, перевод x86 (ну или во что код компилируется) в p-code+выполнение на своём интерпретаторе. совместимо с мутациями как интерпретатора так и самого псевдокода. сложно реализуемо. всякая самотрассировка, самомодифицирующийся код, левые байты после безусловных переходов (jmp @F/db 68h/@@:) как концепт и прочее отпугнёт либо остановит только начинающего взломщика. |
