Зачем нужны протекторы ?

Booster

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

 

Clerk

Ясно. А зря не используют, было бы значительно интереснее В исполнении должно быть по идее не сильно сложнее.

 

Stiver
Постоянно перезагружать кэш, не очень разумно, работать будет очень медленно.

 

Clerk, это не теория, чистА практика )

 

Booster

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

 

К тому же элементы VM всё равно придётся делать, иначе программа улетит в космос.

 

Попадёшь в середину цикла и будешь гонять туда-сюда. И как разруливать переходы совсем не понятно.

 

Booster
ладно. паковать отдельные ветви кода программы вместе.

main >proc1>proc2>proc3
>proc4>proc5>proc3
>proc4>proc5>proc3


отдельно упаковать proc3, proc1+proc2, proc4+proc5

 

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


PS хотя GTA V| ломали достаточно долго, хотя все были согласны и на лоадер, там просто еще хитрость с привязкой к железу была

 

Booster
Кстате строка которая вешает эмулятор/трасер:

Код (Text):

1. 0xDB, 0xE2, 0x9B, 0x0F, 0x01, 0xE0, 0xA8, 0x08, 0x75, 0xF9, 0x0F, 0x01, 0xE0, 0xA8, 0x08, 0x74, 0xF9

SPA

У меня немного не такой взгляд на это. Данные в процессе ниоткуда появиться не могут, чтото является их источником. Есть три способа передать данные в приложение так, чтобы никакие вызовы ядра не произошли, это:
- Непосредственно запись в память. Система не использует это.
- Изменение контекста потока. Также не используется ядром.
- Разделяемая память. Активно используется, например ядерные проекции секций из шадова(GUI).
Во всех остальных случаях данные доставляются сервисами или калбэками, это просто контролировать. Если получается инфа о железе, будет сделан запрос к ядру и сервисы эти известны. Если приложение ожидает ввод данных в консоли, их получит поток на порт. Если ожидается ввод данных в текстбокс, они возвратяться в шадов калбэках, либо в проекцию..
Если известен способ получения инфы, нет никаких припятствий для получения адреса откуда происходит вызов.

 

Clerk
Вашу мысль я понял прекрасно, но скажем так оно очень даже хороша и работоспособна пока против нее специально не начали работать.
Например добыть рандомное значение не так тяжело, в обход методов слежения не так сложно (не весь же код вы будете трейсить) а как следствие рандомыне переходы ,вызовы апи (да алгоритм составления таких лжи путей не из простых, но явно задачу можно решить) ДА и только на первый взгляд кажется что можно все отледить да заэмулить/подменить вот к примеру с гта, она взависимости от железа вызывала не вызывала определенные защитные функции (как вы от 3д приложения спрячете инфу о железе ) а внутри она может ее не тривиально копировать лже использовать ) так получалось пишем кряк на одном компе работает на другом нет, да еще и рандом был. Те вы хотите основываться (грубо говоря на перехвате апи) и там уже дальше копать легко, но ведь это все работает пока инфу получают явно, можно просто получать много фековой инфы, внутри нетривиально копировать, фейково использовать + рандом +привязка, и получиться без иследования защиты опять не обойтись.

 

max7C4
В proc2 цикл с вызовом proc3. Гуанище.

 

Booster
а вы не подумали о том, то расшифровывать надо не перед вызовом, а перед участком, который использует.
т.е. 1 раз расшифровывается proc1+proc2, вызывается, proc2 расшифровывает proc3 (в самом начале, зашифровывает по выходу), а потом использует, хоть в циклах. если уровней больше и что-то вызывается в цикле, то это стоит расшифровать перед циклом и зашифровать после.

 

Кто-нибудь понял, что max7C4 написал? Я нет. ^) Что-то стоит расшифровать, что-то не стоит, как это определить то?

 

Booster
это называется ленивые функции

 

GoldFinch
Про ленивое программирование и вычисления в курсе. Но это совсем другое. Тут весь вопрос как не убить производительность.

 

Clerk

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

А конкретно по топику - мое мнение, протекторы нужны. Одно дело - что на данный момент их (весьма)просто снять, другое дело - что вопрос только в нормальной реализации, понапхать можно много всего. Но надо ведь хоть как то софт защитить?

 

Killer
Вопрос в том, зачем пытаться распаковывать, если модуль сам себя распаковывает.

 

Clerk
+1. В точку. И если уж вешать, то мак-либо усложнить расшифровку/распаковку, а то большая часть упаковщиков/крипторов сама себя и снимает же. Надо только этого дождаться и снять дамп памяти или перепаковать секции обратно в exe.

 

max7C4
к чему тут крипторы вообще? )