Глава 57

Файлы к статье

UNPACKME C:

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

Поскольку я не использовал мониторинг файлов или реестра, достаточно выполнить те же действия что и в 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, после запуска он покажет нам защиту, которую имеет:

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

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

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

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

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

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

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

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 и смотрим, функционирует ли скрипт.

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

UNPACKME E:

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

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

UNPACKME G:

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

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

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

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

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

И

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

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

Мы здесь.

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

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

00491E65 8B45 F4 MOV EAX,DWORD PTR SS:[EBP-C] ; kernel32.GetVersion

00491E68 8BE5 MOV ESP,EBP

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

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

Мы заменяем в скрипте адрес, где размещается 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 и запустил скрипт и он отремонтировал всю таблицу

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

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

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

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

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

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

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

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

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

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

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

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

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

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