Как известно, многие крэк-группы не хотят делиться туториалами по снятию той или иной защиты, и сидят на закрытых IRC каналах... Нашел тутор по снятию SafeDisc 3.xx. Вещь довольно интересная, только вот я не силен в немецком... Напишите хоть что-нибудь.

4ace_CIP _ Tutorial Manual unpack NFSU2 (Safedisc v3_xx).rar

-----
MicroSoft? Is it some kind of a toilet paper?

| Сообщение посчитали полезным:

DillerInc
OR EBX, 0000000C и OR EBX, 0C это одно и то же;

Набираешь в SoftICE:
a _address_ ( _address_ - это адрес куда нужно вводить ассемблерные инструкции)
(нажать enter)
or ebx, 0c
(нажать enter)
.............................(и т. д.)
(нажать enter)
Можно также: EB _address_ _data_ (_data_ это последовательность Нех - опкодов, разделять пробелами, например:
EB F4561743 83 CB 0c) 83 cb 0c это опкоды команды OR ebx, 0c которые начнут записываться в память начиная с адреса F4561743 в данном примере.
Еще один способ: ввести db _address_ и в окне данных наведя курсор на Нех-опкод изменяешь на нужный

Поскольку IceExt не защищает от обнаружения SoftICE через DR7, то вполне возможно, именно так SafeDisk его и определяет (если еще чего-то не намутили, гады...)

-----
Research is my purpose

| Сообщение посчитали полезным:

Error_Log пишет:
это одно и то же
...кроме длины этих команд и соответственно опкодов:
81CB0C000000 OR EBX, 0000000C
83CB0C OR EBX, 0C
Error_Log пишет:
Еще один способ: ввести db _address_ и в окне данных наведя курсор на Нех-опкод изменяешь на нужный
...спасибо - этого я не знал,и это мне помогло написать команды как надо .

Теперь о грустном - игра (в данном случае Call of Duty - SD 3.10.20) у меня всё равно не запускается .
Может мы закрыли какую-то из дырок,но осталась какая-нибудь другая,так сказать,более свежая... По крайней мере мне хочется на это надеятся, т.е. надеятся на то,что мы движемся в верном направлении.

-----
the Power of Reversing team

| Сообщение посчитали полезным:

DillerInc пишет:
...кроме длины этих команд и соответственно опкодов:
81CB0C000000 OR EBX, 0000000C
83CB0C OR EBX, 0C
А это уже зависит от ассемблера, который генерирует эти опкоды, предлагаю почитать:

8047_kaspersk01.rar

-----
Research is my purpose

| Сообщение посчитали полезным:

DillerInc пишет:
По крайней мере мне хочется на это надеятся, т.е. надеятся на то,что мы движемся в верном направлении
Я нашел решение: будем использовать баг в защите для обхода антиотладки, короче:
1. Грузим защищенный SD файл в дизассемблер (это по вкусу, я использую OllyDbg, за одно там удобно ассемблировать процедуру по восстановлению импорта). Ищем там процедуру декриптования:
CALL ХХХХХХХХ ;Процедура декриптования игры
ADD ESP,8
CMP EAX,0 ;если EAX = 1,значит ошибка
JE ХХХХХХХХ ;если декриптование прошло гладко
Через несколько прыжков после нее будет прыжек в другую секцию
В переведенной статье DillerInc по SD 2.30.33 это
008CB0B9 E97645EAFF JMP 0076F634; это прыгает на ОЕР
2. Вместо jmp OEP_address вписываем туда jmp eip (опкоды EB FE). (Здесь я сразу делаю прыжек на свою процедуру восстановления импорта) Сохраняем изменения.
3. В опция загрузки SoftICE ставим "manual". После загрузки винды запускаем подопытную игрушку (не забываем вставить диск в CD-ROM). SplashPicture появится на короткое время и исчезнет. (SoftICE не загружен !!!)
4. В командной строке: NET START ICEEXT, после загрузки SoftICE жмем Ctrl-D и мы окажемся после процедуры декриптования прямо перед прыжком на OEP !!! Начиная с этого места уже никто не помешает вам отлаживать программу.
5. Пишем процедуру по восстановлению импорта и краденных байтов. Дампим, делаем Rebuild PE.
6. Если нужно выйти в Windows набираем !Suspend, вернуться назад - !Resume.

P. S. Данная методика была проверенна на версиях SD начиная с 2.50.ХХ и заканчивая SD 3.XX.XX. Описанные в переведенной DillerInc статье методы восстановления импорта лично в моем случае потребовали доработки, т. к. SD использует там усовершенствованные приемы по затруднению восстановления импорта, подробности расскажу, когда закончу их исследование.

-----
Research is my purpose

| Сообщение посчитали полезным:

И еще, насчет антиотладочных приемов, используемых для обнаружения SoftICE. В статье (C) dragon по исследованию eXtreamProtector-a есть ссылка на небольшой архив. В этом архиве лежит утилита R0cmd. Так вот, если перед запуском SoftICE сделать дамп оригинальной IDT, а после запуска SoftICE подменить IDT с помощью той же утилиты на оригинальную, SoftICE обнаружен не будет. Выводы делайте сами.

(Кстати прием с подменой IDT полезно использовать, если прийдется несколько раз запускать игрульку защищенную SD, перед запуском игры загружаем оригинальную IDT, после того, как прога зациклиться, можно подгружать IDT, которую заделал SoftICE при своем запуске)

-----
Research is my purpose

| Сообщение посчитали полезным:

Error_Log
Я знаю,этот способ мы назовём:
"Метод Error_Log-DillerInc'а"

Просто сейчас я ковыряюсь с другим "проектом",а там мне довелось применить следующую технику:
1. CreateProcess в режиме SUSPENDED
2. Размещение опкода EB FE по определённому адресу
3. ResumeThread
4. Ну и далее...
Ну,и я решил применить данный приём на своём любимом Call of Duty - сработало.
Без присутствия загруженного отладчика игра благополучно декриптуется и...бес ей в ребро,зацикливается перед прыжком на OEP.
И далее действуем как ты и описал .
Единственный недостаток - это то,что в случае чего,придётся перезагружать систему,чтобы повторить операцию.

Error_Log пишет:
прием с подменой IDT
...объясни,пожалуйста,что за IDT...

-----
the Power of Reversing team

| Сообщение посчитали полезным:

DillerInc пишет:
...объясни,пожалуйста,что за IDT...

IDT (Interrupt Description Table). Каждое прерывание имеет свой вектор (адрес обработчика). Таблица, в которой хранятся эти вектора и есть IDT. Отладчики ring-0 типа SoftICE, TRW подменяют векторы некоторых прерываний и используют эти прерывания для своих нужд. Этим свойством пользуются большинство протекторов для обнаружения отладчика.

Утилита R0cmd (спасибо (С)dragon -у) позволяет просматривать и делать дамп этой таблицы, а также загружать сделанный дамп в память (там есть еще куча возможностей).

-----
Research is my purpose

| Сообщение посчитали полезным:

Салют,господа!
Легендарная Call of Duty, защищённая протектором SafeDisc 3.10.20, наконец-то распакована.
Если говорить вкратце о защите,то могу честно признаться,что та третья версия протектора,применявшаяся в NFSU2, - это просто цветочки по сравнению с этой.

Error_Log
Дружище,как у тебя дела ?
Ты,как я помню,тоже ковырял SD - есть ли результаты ?

-----
the Power of Reversing team

| Сообщение посчитали полезным:

Я уже давно распаковал версию 2.51 (Serious Sam II). Отличия: присутствует нечто вроде счетчика, и если процедура SD вызывается слишком часто, то сия процедура делает подставу и неправильно восстанавливает импорт. Исправляется это дело дополнительным патчем процедуры SD. Еще одна трудность, которую там встретил - при исследовании в отладчике нужно обязательно удалять бряки, поставленные на Call[ref.] потому, что в процедуре SD есть проверка первых двух байт, а при поставленном бряке вместо FF там будет СС, опять подстава будет, а не импорт, ну и еще одно - после jmp (5 байт) замененных SafeDisk-ом в тех местах, где были Call[Ref] (6 байт) никакого NOP - там мусорный байт, я писал процедуру, которая "тырила" так называемый "третий параметр" и отнимала его от адреса вызова, разность = 5 или 6 в зависимости от того, что там было на самом деле, потом переход на соотв. процедуру восстановления. Все благополучно восстановил и убрал еще одну проверку основанную на GetDriveTypeA =)). Ну а в 3 SD я мельком заглядывал, с импортом вроде попроще, но там юзаются наномиты, времени пока небыло поковырять. Ну а в твоей версии какие особенности?

-----
Research is my purpose

| Сообщение посчитали полезным:

Error_Log пишет:
в тех местах, где были Call[Ref] (6 байт) никакого NOP - там мусорный байт
...по-видимому,этот NOP присутствовал только в Max Payne ну или ещё в каких-то ранних версиях протектора,т.к. и в NFSU2, и Call of Duty этот байт всегда мусорный.
В версии 3.10.20 использовался способ вызова импорта через регистры,о котором упоминалось во мною переведённой статье.
Далее,что оказалось весьма сложным для меня - процедура SD № 2 (я так назвал для удобства).
К примеру,имеется команда call XXXXXXXX, которая ведёт в область протектора и совершаются определённые действия.
Так вот если в NFSU2 этот механизм вызывал импорт и затем сам восстанавливал вышеприведённую команду:
call XXXXXXXX -> call [_CreateToolhelp32Snapshot] ; для примера
...в этой же версии мало того,что этот механизм ничего сам не восстанавливает,так от ещё и не всегда вызывает импорт.Вместо этого он выполняет в теле протектора оригинальные команды,стоявшие когда-то на месте этого вызова и по возвращению из этого вызова просто вписывает нужные значения в нужные регистры.
Ну и конечно наномиты - куда же теперь без них .
И если в NFSU2 использовались,как я понимаю,классические наномиты - команды INT 3, то здесь можно было наблюдать также команды:
MWAIT
MONITOR
SDGT ESI
UD2
...и тому подобные.

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

-----
the Power of Reversing team

| Сообщение посчитали полезным:

...Вот только понту с этих защитных механизмов - сделать жуткое тормозилово из игрушки, которую все равно от этого SafeDisk-a отломают, получив более оптимизированный код. Куча лишних процедур, на которое тратится драгоценное процессорное время!!! В обшем полная деградация...
ЗЫ: можем даже FAQ по снятию SafeDisk-a делать )))

-----
Research is my purpose

| Сообщение посчитали полезным:

Error_Log пишет:
можем даже FAQ по снятию SafeDisk-a делать )))
Было бы здорово!

-----
TBR

| Сообщение посчитали полезным:

Error_Log
Вот мысль из книги Дмитрия Склярова:
"Разработчики всячески стремятся хотя бы максимально усложнить процесс восстановления и, самое главное, предотвратить его полную автоматизацию..." .
В принципе с этим они вполне справляются.

Error_Log пишет:
ЗЫ: можем даже FAQ по снятию SafeDisk-a делать
...ну,не знаю...уж лучше пускай народ читает доступные здесь статьи,пробует и если что,тут спрашивает...

...хотя если народ хочет,то можно подумать...

-----
the Power of Reversing team

| Сообщение посчитали полезным:

DillerInc пишет:
...хотя если народ хочет,то можно подумать...
народ очень хочет

| Сообщение посчитали полезным:

DillerInc
Конечно нужно!

-----
Подписи - ЗЛО! Нужно убирать!

| Сообщение посчитали полезным:

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

-----
Research is my purpose

| Сообщение посчитали полезным:

DillerInc пишет:
и, самое главное, предотвратить его полную автоматизацию...
А почему бы и нет Ведь пользуються Стрипером

| Сообщение посчитали полезным:

crio пишет:
народ очень хочет
nice пишет:
Конечно нужно!
...можно конечно,только я немного не представляю,как всё это будет выглядеть.
Предложите,пожалуйста,возможные варианты.

-----
the Power of Reversing team

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

Кто там интересовался анти-дебагом для сосульки? Вот драйвер от 4 версии, по адресу 0001158D начинается табличка, ОЧЕНЬ интересная табличка, в ней лежат адреса каких-то функций, эту табличку юзает переход по адресу 00011427. Мне почему-то это напомнило вызов анти-дебага, точнее процедур анти-дебага, по таблице, а таблица сделана для облегчения работы разработчиков из макровюжон, т.е. достаточно добавить в таблицу адреса анти-дебажных процедур и всё, больше не надо добовлять
код для из вызова Всё очень просто, но я не уверен, что это процедуры для отлова дебаггеров, хотя ОЧЕНЬ похоже...

b673_SECDRV.rar

| Сообщение посчитали полезным:

Bit-hack
Спасибо,когда время будет - посмотрю.
Хотя я этот Call of Duty с его мощной антиотладочной защитой распаковывал с помощью своей утилитки,которая запускает игру и тормозит её перед прыжком на OEP,когда отладчик ещё не загружен.
Единственно неудобно каждый раз перезагружать систему перед повторным "погружением во внутренности исследуемого EXE" .

-----
the Power of Reversing team

| Сообщение посчитали полезным:

DillerInc пишет:
Единственно неудобно каждый раз перезагружать систему перед повторным "погружением во внутренности исследуемого EXE"

а почему необходимо перезагружаться после обнаружения отладчика????

| Сообщение посчитали полезным:

crio
Потому-что защита,определив,что в системе запущен отладчик,просто отказывается декриптовать защищённый исполняемый файл.Иными словами - не удаётся запустить этот файл.
А когда ты перезагружаешься,то отладчик само собой выгружается,тогда защита может спокойно декриптовать защищённое приложение.

-----
the Power of Reversing team

| Сообщение посчитали полезным:

DillerInc , Bit-hack
Кстати эксперементировал с IDT, точнее с ее подменой. Если грузить отладчик, а потом оригинальную IDT, то исполняемый файл первый раз благополучно декриптуется. После того, как прога зациклилась, грузил пропатченную IDT (которую заделывает SoftICE). Если просто трейсить не ставя бряки, то фокус проходит и второй раз, т.е систему можно не перегружать, просто загрузить оригинальную IDT перед запуском игрушки; а вот если ставить бряки, то даже если все потом удалить, то фокус с подменой не канает, и все равно ребутиться надо. Такое чувство, что эта сволочь SD где-то сохраняет инфу, что его отлаживали. Так же у меня не канало BPM _______ X, да и вообще с бряками туговато было, приходилось изощряться, чтоб они срабатывали.

-----
Research is my purpose

| Сообщение посчитали полезным:

Народ, дайте кто-нибудь полную цепочку функций для ContinueDebugActiveProcess (или как-то так, юзается для аттача). С виду похукана NoOpenProcess, но я хука не нашёл

| Сообщение посчитали полезным:

Bit-hack
Ты имеешь в виду это:

var
 dEvent : _DEBUG_EVENT;
 sInfo : TStartupInfo;
 pInfo : TProcessInformation;
 OpenDlgBox : TOpenFileName;
begin
 CreateProcess(OpenDlgBox.lpstrFile, NIL, NIL, NIL, False,
                  DEBUG_ONLY_THIS_PROCESS, NIL, NIL, sInfo, pInfo);
repeat
 WaitForDebugEvent(dEvent, INFINITE);
// к примеру,если была загружена библиотека
if dEvent.dwDebugEventCode = LOAD_DLL_DEBUG_EVENT then
begin
// что-то делаем и...
Break; // ...выходим из бесконечного цикла
end;
ContinueDebugEvent(dEvent.dwProcessId, dEvent.dwThreadId, DBG_CONTINUE);
until False;

-----
the Power of Reversing team

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

Вот на днях распаковал ещё одну игру,защищённую SD версии 3.10.20 :
Empires Dawn of the Modern World (стратегия реального времени, русскоязычная версия от 1С) .
Это называется версия на версию не приходится...
Очень многое реализовано совсем не так,как было в Call of Duty,к примеру:
тут выше мы писали о том,что байт после т.н. longjump'а в новых версиях протектора всегда является мусорным.А вот и ничего подобного.В данном случае примерно 2/3 всех longjmp'ов имеют нормальный шестой байт,т.е. являются командами Call смещение_Jmp[ref], и лишь оставшаяся часть содержит мусорный шестой байт.
Среди наномитов встретился следующий прикол от Macrovision:

CC int 3
CC int 3
59 pop ecx
59 pop ecx 

Команды POP ECX никак не восстанавливаются,а теперь подумайте,что будет,если при восстановлении наномитов (на основе метода из статьи про третий SD) не убрать эти команды POP ECX ...
Вот чего я не могу понять,должны ли эти команды вообще присутствовать в исполняемом коде?Расположены они как правило следующим образом

call [ref]
test eax, eax
pop ecx
pop ecx
jz XXXXXXXX 

...что выглядит довольно нелепо .
Пробовал распаковать,заNOPив эти команды и в другом случае сохранив эти команды, - в обоих случаях файл получается рабочий,если не считать одного глюка:
не работает перемещение по карте путём щелчка на мини-карте .
Хотя причины этого глюка могут скрываться и в чём-то другом.

-----
the Power of Reversing team

| Сообщение посчитали полезным:

DillerInc пишет:
встретился следующий прикол от Macrovision:
Это похоже на команду коррекции стека. (add esp, 8) Посмотри в запротекченной проге как меняется указатель стека (esp) в этом месте.

-----
Research is my purpose

| Сообщение посчитали полезным:

Вчера решил немного поизучать работу отладчика SafeDisk-a. В общем SafeDisc 3.20.022 восстанавливает только те участки кода, которые многократно вызываются. Самое интересное происходит в ДЛЛ отладчика, я брякнулся на GetThreadContext (ставил бряк ближе к концу АПИ). Немного потрейсив попал сюда:
.txt5:6678FEC1 loc_6678FEC1: ; CODE XREF: sub_6678FE04+73j
.txt5:6678FEC1 mov eax, [ebp+var_50]
.txt5:6678FEC4 cmp eax, 80000003h ; STATUS_BREAKPOINT
.txt5:6678FEC9 jz short EXCEPTION_PROCESS
.txt5:6678FECB cmp eax, 80000004h ; STATUS SINGLE STEP
.txt5:6678FED0 jz short loc_6678FEB4
.txt5:6678FED2 cmp eax, 0C0000005h ; STATUS_ACCESS_VIOLATION
.txt5:6678FED7 jz short EXCEPTION_PROCESS
.txt5:6678FED9 cmp eax, 0C000001Dh ; STATUS_ILLEGAL_INSTRUCTION
.txt5:6678FEDE jz short EXCEPTION_PROCESS
.txt5:6678FEE0 cmp eax, 0C000001Eh ; STATUS_INVALID_LOCK_PREFIX
.txt5:6678FEE5 jz short EXCEPTION_PROCESS
.txt5:6678FEE7 cmp eax, 0C0000096h ; STATUS_PRIVILEGED_INSTRUCTION
.txt5:6678FEEC jnz short loc_6678FF12
.txt5:6678FEEE
.txt5:6678FEEE EXCEPTION_PROCESS: ; CODE XREF: sub_6678FE04+C5j
.txt5:6678FEEE ; sub_6678FE04+D3j ...
.txt5:6678FEEE mov ecx, [ebx+8]
.txt5:6678FEF1 call sub_6678E5E4
.txt5:6678FEF6 mov ecx, [ebp+var_44]
.txt5:6678FEF9 sub ecx, eax
.txt5:6678FEFB mov eax, [ebp+arg_0]
.txt5:6678FEFE shl ecx, 8
.txt5:6678FF01 imul ecx, [eax]
.txt5:6678FF04 mov [eax], ecx
.txt5:6678FF06 push eax
.txt5:6678FF07 lea eax, [ebp+var_50]
.txt5:6678FF0A mov ecx, ebx
.txt5:6678FF0C push eax
.txt5:6678FF0D call sub_6678FF4F ; СЮДА ЗАХОДИМ
Далее следует куча Call-ов и jmp-ов, которые не очень интересны, но есть среди них цепочка вложенных вызовов (около 8), которая ведет к WriteProcessMemory. Там используются вызовы типа Call [eax+8],
Call [eax]. Перед самой процедурой, в которой есть WriteProcessMemory есть о-о-о-очень интересная процедура:
.txt5:6678F553 loc_6678F553: ; CODE XREF: sub_6678E6D5+E79j
.txt5:6678F553 lea ecx, [ebp-10Ch]
.txt5:6678F559 call sub_6672DBE9 ; ОПРЕДЕЛЯЕТСЯ, НУЖНО ЛИ ВПИСЫВАТЬ ОПКОД В СЕКЦИЮ
.txt5:6678F55E cmp ax, 1 ; ИСПРАВЛЯЕМ НА MOV AX, 0001
.txt5:6678F562 jnz loc_6678F6C6 ; ВПИСЫВАЕМ MOV EAX,EAX ТРИ РАЗА
После такого патча все наномиты восстанавливаются сразу после первого их выполнения. Саму цепочку Call-ов ведущих к WriteProcessMemory проследить несложно, достаточно брякнуться на WriteProcessMemory (опять-же бряк лучше ставить не на начало или конец, а недалеко от конца АПИ). Далее потрейсить до ret до тех пор пока не выйдем к тому участку, где сравнивается EXCEPTION_CODE. Простым запуском игрушки вписалось 98 байт с пропатченной процедурой, по сравнению с непропатченной

eea8_report_restore_text.txt

-----
Research is my purpose

| Сообщение посчитали полезным: