> For the complete documentation index, see [llms.txt](https://backoftut.gitbook.io/intro-cracking-with-ollydbg-2/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://backoftut.gitbook.io/intro-cracking-with-ollydbg-2/ch-57.md).

# Глава 57

[Файлы к статье](https://github.com/yutewiyof/intro-cracking-with-ollydbg/tree/37614a6cb157fe18b76d7ddc29fc259e5403c1eb/.gitbook/assets/files/57/\(123\)filesToTutor.zip)

`UNPACKME C:`

Мы продолжаем изучение execryptor на основе unpackmes, unpackme c похож на b, при запуске он сообщит нам, что нейтрализует действие registry monitors и file monitors.

![](/files/-MX1Cj2fdF0f8Cpx9lDm)

Поскольку я не использовал мониторинг файлов или реестра, достаточно выполнить те же действия что и в b, инструкция, где появляется адрес api, на моей машине находится здесь.

> 00486DF7 8B45 F4 **MOV EAX,DWORD PTR SS:\[EBP-C]**
>
> **00486DFA** E8 61670100 CALL 0049D560 ; UnPackMe.0049D560
>
> 00486DFF 5B POP EBX
>
> 00486E00 8B0424 MOV EAX,DWORD PTR SS:\[ESP]
>
> 00486E03 52 PUSH EDX

Следовательно, адрес, где мы должны поместить HARDWARE BPX ON EXECUTION и соответственно изменить скрипт - **00486DFA** .

скрипт станет таким:

```
var tabla
var contenido
mov tabla,460818
start:
cmp tabla,460f28
ja final
cmp [tabla],50000000
ja saltear
mov contenido,[tabla]
cmp contenido,0
je saltear
log contenido
log tabla
mov eip,contenido
bphws 486DFA, "x"
mov [486DFA],0
mov [486DFB],0
cob reparar
run
reparar:
cmp eip,486DFA
jne saltear
log eax
mov [tabla],eax
run
saltear:
add tabla,4
jmp start
final:
ret
```

Не нужно забывать снимать BREAK ON EXECUTE, после прибытия в OEP посредством OLLYBONE, приостанавливать ненужные threads и помещать HE на ZwTerminateProcess, после чего скрипт отремонтирует таблицу и можно будет сделать dump и использовать IMP REC, аналогично b.

`UNPACKME D:`

Теперь перейдем к unpackme d, после запуска он покажет нам защиту, которую имеет:

![](/files/-MX1Cj304cOGRFwkVI-7)

Debug Message Enabled, то есть в случае обнаружения отладчика будет показано сообщение, hmm, давайте посмотрим, повлияет ли это на наш метод, давайте запустим программу в OLLYDBG, мы прибудем как обычно в SYSTEM BREAKPOINT, там мы удалим BP, которые были размещены OLLY, потом разместим BREAK ON EXECUTE и прибудем в OEP.

![](/files/-MX1Cj3E6Xq_thtjcHwS)

До сих пор отличий нет, давайте посмотрим Threads, чтобы остановить их

![](/files/-MX1Cj3aVEwT5wy4FtpC)

Пока все аналогично, мы останавливаем все потоки, кроме 2-х

![](/files/-MX1Cj3oppA4KNL4RXxM)

Как и в прошлый раз, я не трогаю поток, выделенный красным и тот, который имеет адрес 270000 на моей машине, все остальные приостанавливаются, далее я найду первый вызов api, находящийся ниже OEP и размещу BPM ON WRITE для него, после чего запущу трассировку OLLY.

![](/files/-MX1Cj41TNQKoTL9ZokL)

Происходит поимка исключения

![](/files/-MX1Cj4G9Re8jaH2hhNz)

Посмотрим строку трассировки, записывающую адрес api в EAX

![](/files/-MX1Cj4TmaRxxVqAOIDQ)

До сих пор различий нет

> 0046D8DC 8B45 F4 MOV EAX,DWORD PTR SS:\[EBP-C] ; kernel32.GetVersion
>
> **0046D8DF** 8BE5 MOV ESP,EBP

возьмем этот адрес для размещения HE в скрипте, после чего он примет вид:

```
var tabla
var contenido
mov tabla,460818
start:
cmp tabla,460f28
ja final
cmp [tabla],50000000
ja saltear
mov contenido,[tabla]
cmp contenido,0
je saltear
log contenido
log tabla
mov eip,contenido
bphws 46D8DF, "x"
mov [46D8DF],0
mov [46D8DF],0
cob reparar
run
reparar:
cmp eip,46D8DF
jne saltear
log eax
mov [tabla],eax
run
saltear:
add tabla,4
jmp start
final:
ret
```

Хорошо, снова прибываем в OEP, снимаем break on execute, размещаем HE ZwTerminateProcess и смотрим, функционирует ли скрипт.

![](/files/-MX1Cj4ip7ZQ3mW4GZV5)

Мы видим, что он исправляет всю таблицу, и она совпадает с предыдущими, так что мы переходим к unpackme "e", посмотрим, появится ли что-то новое в нем.

`UNPACKME E:`

![](/files/-MX1Cj4xE1a7X0F0gbPC)

Active Watch Enabled - это то, что нам показывает unpackme "e", когда мы его запускаем, давайте посмотрим, какие отличия он имеет по отношению к предыдущим.

Он также аналогичен предыдущим, следовательно, мы решим его таким же методом, видно, что он распаковывается верно и мы продолжим с "g", поскольку f также не содержит чего-то нового.

`UNPACKME G:`

![](/files/-MX1Cj5DjFXyT9lU8c15)

"g", после запуска мы видим что-то, что может оказать на нас воздействие, а именно он сообщает нам что у него присутствует "Anti-Trace Enabled", а мы знаем что нами используется трассировка для поиска места размещения HE ON EXECUTION, и скоро мы узнаем насколько эффективно работает эта защита.

Хорошо, первое отличие, когда я прибываю в system breakpoint и убираю BP, которые размещает OLLYDBG и размещаю BREAK ON EXECUTE, возникают 5 или 6 Single Step Exceptions перед тем, как остановиться на OEP

![](/files/-MX1Cj5UswZL456mGOg2)

![](/files/-MX1Cj5gF3ebQnSMhjrL)

Момент, на который необходимо обратить внимание, заключается в том, что мы не можем поставить опцию автоматической обработки этого типа исключения, так как это приведет к неверной работе OLLYBONE, поэтому эти случаи придется обработать вручную с помощью SHIFT+F9.

![](/files/-MX1Cj5sUrlwlovDaDg0)

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

![](/files/-MX1Cj67Uojee00qeOyE)

Мы видим только 2 потока, которые необходимы для выполнения программы, если бы их было больше, мы бы приостановили остальные, хорошо, давайте посмотрим, чем нам грозит этот anti-trace, на всякий случай используем RDTSC, не забываем о том, что в плагине OLLY ADVANCE включены опции ANTI RDTSC и GetTickCount.

![](/files/-MX1Cj6MzIX00zCZb88y)

И

![](/files/-MX1Cj6ahDlniUAp_QWM)

Хорошо, кроме того при использовании ANTI RDTSC вы должны посмотреть, когда загружаете OLLYDBG, довольно часто в нижнем углу, где обычно располагается информация о точках останова на несколько секунд показывается сообщение COULDN'T START THE DRIVER, в этом случае драйвер не был загружен правильно и не будет функционировать, часто это происходит в моем случае после определенного времени использования компьютера.

![](/files/-MX1Cj6q9_WGADwzWlx5)

Я размещаю BPM ON WRITE на адресе, который должен быть исправлен, как обычно мы убираем BREAK ON EXECUTE и запускаем трассировку.

![](/files/-MX1Cj722l1iXmRYjYj3)

Мы здесь.

Давайте посмотрим в логе трассировки, присутствует ли нужная нам инструкция чуть повыше этой.

![](/files/-MX1Cj7Hw2kei-Bp9YcX)

Так что искомая инструкция - **491E68**

> 00491E65 8B45 F4 MOV EAX,DWORD PTR SS:\[EBP-C] ; kernel32.GetVersion
>
> 00**491E68** 8BE5 MOV ESP,EBP

До сих пор не было проблем с трассировкой, по-видимому, RDTSC справился со своей задачей и threads всегда оставались в количестве 2 в моем случае.

![](/files/-MX1Cj7W2xF8E4WBZINY)

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

![](/files/-MX1Cj7kmzjnONWovhpM)

Мы заменяем в скрипте адрес, где размещается HBP ON EXECUTION

```
var tabla
var contenido
mov tabla,460818
start:
cmp tabla,460f28
ja final
cmp [tabla],50000000
ja saltear
mov contenido,[tabla]
cmp contenido,0
je saltear
log contenido
log tabla
mov eip,contenido
bphws 491E68, "x"
mov [491E68],0
mov [491E68],0
cob reparar
run
reparar:
cmp eip,491E68
jne saltear
log eax
mov [tabla],eax
run
saltear:
add tabla,4
jmp start
final:
ret
```

Хорошо, я разместил HE ZwTerminateProcess и запустил скрипт и он отремонтировал всю таблицу

![](/files/-MX1Cj7xBxMDqtWhtvcQ)

Разница состоит в том, что в этом случае мы не попадаем в ZwTerminateProcess, но так или иначе таблица исправляется, давайте посмотрим в IMP REC.

![](/files/-MX1Cj8DYo6oTP9o8jqX)

![](/files/-MX1Cj8RpjV9Ey9Dqel-)

Мы видим, что первый адрес не был отремонтирован, хотя скрипт отремонтировал остальные, давайте посмотрим, что тут происходит.

```
mov tabla,460818
start:
cmp tabla,460978
ja final
cmp [tabla],50000000
ja saltear
```

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

![](/files/-MX1Cj8fztTHduXf13BO)

Я вижу, что происходят исключения SINGLE STEP, которых раньше не было, так что я вновь перемещаюсь в OEP и повторяю процесс, но на этот раз я устанавливаю флажок SINGLE STEP, поскольку далее OLLYBONE уже не используется.

![](/files/-MX1Cj8uyYcCez1g58G5)

Я вновь размещаю HE ZwTerminateProcess и смотрю на первый адрес, с галочкой он ремонтируется верно.

![](/files/-MX1Cj96TIxq859WUxGu)

Давайте посмотрим LOG

![](/files/-MX1Cj9KlxQpuozLL9y5)

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

Посмотрим, исправляет ли он все верно.

![](/files/-MX1Cj9ZaIeWTQsewdOq)

Починка завершается верно, нажимаем FIX DUMP.

![](/files/-MX1Cj9opsvMSxLly7Sh)

Давайте посмотрим, выполняется ли программа

![](/files/-MX1CjA2v-8gmqhlVngY)

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

До следующей части, где мы увидим 3 завершающих h i и j unpackme серии execryptor и покончим с этой темой (если сможем, хе-хе)

\[C] Рикардо Нарваха, 15.11.06