Попробовал сделать дамп процессу чей запускаемый файл зашифрованн криптором и скормить его в IDA. В результате получаем код на ассемблере ненамного хуже чем код получаемый из некриптованного запускаемого файла. Какие есть способы улучшить защиту от дампа? Первое, что приходит в голову - "окно" в исполняемом коде которое декриптуется/криптуется паралельно с исполнением кода. Но для большого приложения это слишком сложно.
Испортить хидер, так как дамперы считывают откуда-то структуру файла. Можно обнулить imagebase некоторые дамперы считывают ее из из PEB, некоторые из PE - заголовка. Обнуление imagebase в PEB черевато косяками, после этого некоторые апи функции могут возвращать некорректные результаты. Обнуление imagebase в PE заголовке не слишком надежно, но траблов будет меньше. Можно полностью стереть структуру секций в PE. Можно в PE заголовке или PEB_LDR_DATA обнулить size of image. Наконец можно сделать огромный виртуальный размер последней секции. Короче вариантов масса.
Порча заголовка толком ничем не поможет, т.к. можно из файла зачитать, что не представляет больших технических трудностей
TbI_TyT можно добавить еще слой, в котором для раскриптовки будут юзаться те самые значения из хидера, которые мы "испортили" , мм..?
Flint_ta Все ваши методы только для тулз подходят, если дампить вручную, то на это даже внимания никто обращать не будет. Защита от дампа может выполняться двумя способами. Это запрет чтения памяти и сокрытие адреса. Запрет чтения памяти - с этим проблемы, так как если дампер ядереный, то можно напрямую к физической памяти обратится или свопу и считать данные. Второй способ эффективнее, как частный случай трассировка, эмуляция и тп. Эффективна замена селекторов, при которой смещение в сегменте отлично от нуля.
Clerk Зачем все на блюдечке с голубой каемочкой подносить, может ты еще код за них писать будешь ? Хоть бы для приличия пару багов в изложении мыслей сделал, пусть проверяют и учатся
