Актуальные ссылки:

sourceforge.net
http://x64dbg.com
https://github.com/x64dbg/x64dbg
scyllahide

Документациия по отладчику - --> Link <--

Новый проект от Mr.eXoDia и др.

Features:

Open-source
Intuitive and familiar, yet new user interface
C-like expression parser
Full-featured debugging of DLL and EXE files (TitanEngine)
IDA-like sidebar with jump arrows
IDA-like instruction token highlighter (highlight registers etc.)
Memory map
Symbol view
Thread view
Content-sensitive register view
Fully customizable color scheme
Dynamically recognize modules and strings
Import reconstructor integrated (Scylla)
Fast disassembler (BeaEngine)
User database (JSON) for comments, labels, bookmarks etc.
Plugin support with growing API
Extendable, debuggable scripting language for automation
Multi-datatype memory dump
Basic debug symbol (PDB) support
Dynamic stack view
Built-in assembler (XEDParse)
View your patches and save them to disk
Built-in hex editor
Find patterns in memory






| Сообщение посчитали полезным: ff0h, Gideon Vi, nick8606, Artem_N, JKornev, DimitarSerg, daFix, Rio, n0x90, DenCoder, Maximus, ELF_7719116, exprxp, Error13Tracer, Gerpes, SDFnik, VanHelsing, marius, jangle, hello, Bronco, mushr00m, HandMill, Johnatalbi, kassane, BAHEK, zNob, mkdev, Haoose-GP, HAOSov, mr qubo, Tyrus, kurorolucifer, Relax_, esa_r, Styx, Creckerhack, RootKey, RoKZaR, CKAP, Cigan, tRuNKator, Wargrinder, morgot, BiteMoon, mak, Illuzion

Но а причём тогда отладчик
А отладчик только для того чтобы увидеть тело виртуализованной функи и сами внутренности вм, он ничего не исполняет, только показывает, ещё я из него юзаю дизасм и асм

-----
Everything is relative...

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

rmn пишет:
Потому что он пилит не статический анализатор, а на трейсах.
Видимо это трейсы Шрёдингера, в файл не сохраняются.

-----
2 оттенка серого

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

Потому что он пилит не статический анализатор, а на трейсах.
Неправда, анализатор полностью статический, трейсы не юзаю, ни одной строки кода ни декомпилятор ни отладчик не исполняют

-----
Everything is relative...

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

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

-----
2 оттенка серого

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

Если кому-то интересно, то здесь можно увидеть весь выхлоп по декомпиляции одной маленькой функи

76ca_08.12.2018_EXELAB.rU.tgz - 1D4ABD8+.rar

-----
Everything is relative...

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

Vamit

Суть понятна.

> Неправда, анализатор полностью статический, трейсы не юзаю, ни одной строки кода ни декомпилятор ни отладчик не исполняют

А как тогда снимается трасса ?

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

-----
vx

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

А как тогда снимается трасса ?
в статике дизасмом с учетом всех ветвлений, как явных, так и скрытых, trc файл, в начале трасса всех примитивов вм, вернее уже их логическая подмена, очищенных от мусора

-----
Everything is relative...

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

Vamit

А если вы встречаете функцию от произвольных данных, то что делаете ?
Разум отказывается это принимать, для этого нужно эмулировать всю ос. Тоесть например происходит вызов апи, далее результат использует вм.. это вообще в принципе возможно решить статически ?

-----
vx

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

Разум отказывается это принимать, для этого нужно эмулировать всю ос.
Не нужно тут ос эмулировать, нафига, любой код засунутый и исполняемый под вм о ней ничего не знает, но работает логически верно. И при виртуализации кода вм ничего не знает об обрабатываемых кодом данных, вот и я делаю всё это аналогично только следуя логике и в обратном порядке. Мне о вызываемой функции, будь то апи или любая другая ничего не нужно знать, ни аргументов, ни какие регистры она юзает, и пофиг что она возвращает, если вм об этом не знает, то и декомпилятору это не нужно.

Добавлено спустя 3 минуты
Но зато я должен знать всю структуру и действия вм, без этого её логику не развернуть в обратную сторону.

-----
Everything is relative...

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

Vamit

Так а как тогда декомпилировать ?

Эта задача для пе не разрешима. Я много тем поднимал на форумах по задаче отделения кода от данных. По этой причине нельзя реализовать норм защиту от OP. Вы в статике найдёте указатель(а его не отличить от данных, если нет релока), а без исполнения по нему нельзя узнать, что это текстовая строка например или колбек. Или например узнать лимиты в case-ветвлении. Такое нельзя провернуть, только если вручную и в динамике.

-----
vx

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

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

-----
Everything is relative...

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

difexacaw
он в x86-асм декомпилит, а не в hll. Какие текстовые строки? Какие свитчи?

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

Например встречаем инструкцию mov r,N. Что есть N - константа, указатель; если указатель то куда - на код или данные ?
И на этом анализ заканчивается. Если есть релок для N, либо в пе использованы таблицы cfg, то можно определить что это указатель, во втором случае что на код. Но а без этого - облом.

-----
vx

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

difexacaw пишет:
Что есть N - константа, указатель; если указатель то куда - на код или данные ?
Да похер. Цель декомпиля - из килобайт вмп-кода получить mov r, N. Это конечный результат.

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

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

Для х86 кода, без перемещения, т.е. загруженного по адресу 401000 релок на вход вм всегда идет 0, если обрах з грузится на другие адреса, то на вход вм подается соответствующее смещение, которое во время исполнения применяется ко всем нужным данным и переходам.

-----
Everything is relative...

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

rmn

Так в том и проблема, что когда декомпиль сталкивается с константой, то дальше может работать только эвристически. А это почти всегда ошибка, особенно на процедурах малого размера. Данная задача не разрешима. Просто Vamit всё это делает вручную и с трассировкой.

Добавлено спустя 1 минуту
Vamit

> Внутри вм все данные находятся в чистом виде без релоков

Если это так допустим, то как тогда вы получили тело вм без трассировки, оно ведь запаковано ?

-----
vx

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

Если это так допустим, то как тогда вы получили тело вм без трассировки, оно ведь запаковано ?


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

Что-то мы плавно в другую тему переехали...

А чтобы снять дамп нужно победить антиотладку - что тут ещё не ясно

-----
Everything is relative...

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

Vamit
Так, бросай все, чем ты там занимаешься. Без визора на разрушенных указателях ты ничего не сделаешь

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

вот что поступает на вход вм в приведенном порядке
pic dum esi efl edx ebx ecx edi ebp eax off

pic - шифрованное смещение ленты пикода
dum - константа антидампа
далее содержимое всех регистров, на каждом входе в вм их порядок может произвольно изменяться
off - смещение для релоцируемых данных

-----
Everything is relative...

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

Vamit

Не буду спрашивать как находится оеп.

Всё же мне не понятно как выполняется декомпиляция. Точнее вопрос выше - как данные отличаются от кода. Если вы встречаете константу, то если её обработать как константу - будет утеря части кода(вм в данном случае). Если её обработать как указатель на код, то начнётся декомпиляция данных. Мы это уже обсуждали давно. Как это вы решаете, я вижу лишь один возможный вариант - ручной разбор в отладчике ?

-----
vx

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

--> Link <--

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

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

ClockMan
Этот же xed и используется в х64dbg, только переименовали в XEDParse, добавив общий интерфес вызова для всех 3х ассемблеров. Например, вот строка из XEDParse
#include "..\xed2\include\xed-interface.h"
которая указывает на интерфейс оригинального xeda
Но его беду я описал выше, строит неоптимально длинный код, но понимает все инструкции, может причина этого в интерфейсе вызова, надо будет как нибудь поразбираться конкретнее...

Не буду спрашивать как находится оеп.
Практически элементарно, есть куча разных способов, я юзаю в основном два: через дно стека, там всегда найдется что-то полезное, и через инициализацию статических классов, которые всегда имеют конструкторы, которые вызываются из таблицы. В любом случае если знаешь crtstartup код (определяется по типу компилятора), то найти ОЕП не составляет труда. Даже если ОЕП пожран вм, то всё равно находится точка близкая к нему.

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

-----
Everything is relative...

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

Vamit

С вм всё понятно, вопрос был про другое. Это ведь не чистый дамп вм в памяти, а полноценный исполняемый модуль. Он должен исполниться, что бы появилось тело вм. По этому и не понятно как это чисто в статике вы делаете, без запуска приложения. Потом вы говорите что запускается в отладчике, те динамика, а декомпилится именно вм.. Я имел ввиду именно статический анализ машинного кода, до формирования тела вм, которые вы разбираете не важно как. У вас такое описание, что можно только предполагать как и что вы делаете

Добавлено спустя 32 минуты
> строит неоптимально длинный код, но понимает все инструкции, может причина этого в интерфейсе вызова

Енкодер кседа собирает инструкцию по её описанию, тоесть это проблема интерфейса, а не кседа.

-----
vx

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

Это ведь не чистый дамп вм в памяти, а полноценный исполняемый модуль. Он должен исполниться, что бы появилось тело вм.
Это не так, рассмотрим другой вариант, не на виртуализованном юзер коде, а саму вм протектора - где бы вм ни встретились, они аналогичны.
Приложение грузится в отладчик и останавливается прямо на ЕП (до этой точки его код не исполнялся, если TLS обработчики отсутствуют), тут сразу находится вход в вм протектора и распаковщика, стартуем декомпилятор с этой точки и получаем код первой функи, это будет простая обертка для вызываемой пакетной функции, т.е. переход в другую вм без выхода в открытый код, да и возврата из этой первой функи при нормальном потоке исполнения тоже не будет, а вот при срабатывании защиты выход из неё может быть. Зная параметры следующей вм (получаем их на переходе из предыдущей), можно декомпилировать и её тело уже отдельно и т.д.
Как видишь тут исполнять ничего не нужно, и все нормально решается в статике, но есть одно но, хоть вм и имеет свою структуру и систему команд, но минимально исполняемой единицей у неё является команда реального асм кода, поэтому декомпилятор в своем ядре имеет программный эмулятор для каждой инструкции ассемблера со всеми возможными типами операторов и всю остальную необходимую структуру как процессора (все регистры с полной эмуляцией их пересечений (например, eax-ax-ah-al пересекаемые), так и приложения (стек и память, память отслеживается только выборочно по мере обращения к ней). Всё это эмулируется в процессе статического разбора кода и содержит или реальные данные, если это константы или цепочки передач параметров источник-приемник, в результате появляются законченные логические выражения, которые, если их разорвать в нужном месте, превращаются в псевдо код, ну а далее уже в законченные инструкции первоначального кода. Всё была тут вм и нету. Это не теория, всё это успешно работает вживую, да есть некоторые проблемы, но они не системые и решаются по мере их обнаружения.
Например, вот недавно я обнаружил новый примитив с вызовом sysenter (его тело в теме защиты), который сначала завиртуализован, а затем включен в состав вызывающей вм. Чтобы отследить поток управления после него нужно знать его параметры, но их можно получить только декомпилировав его отдельно, пока же поток исполнения у меня на нем прерывается, в итоге теряем часть важного кода. Но декомпилятор отслеживает все такие ситуации и возможно эту часть декомпилировать отдельно, в другом сеансе и затем полученный её асм код добавить в листинг вызывающей функции.

Добавлено спустя 7 минут
Енкодер кседа собирает инструкцию по её описанию, то есть это проблема интерфейса, а не кседа.
Вот смотри одна и та же инструкция через один и тот же интерфейс подана на 2 разных ассемблера, результат их работы:
01CF24D1 | FF B5 E7 FF FF FF | push dword ptr ss:[ebp-19]
01CF24D7 | FF 75 E7 | push dword ptr ss:[ebp-19]
первую строку создал XEDParse, вторую Keystone или Asmjit
текстовая строка, поданная им на вход, выглядит так
push dword ptr [ebp + 0xFFFFFFE7]
режим их работы задан как х86 код

-----
Everything is relative...

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

Vamit

> Вот смотри одна и та же инструкция через один и тот же интерфейс подана на 2 разных ассемблера

Вы это уже показывали. Кодировка modrm разная. Ксед не ассемблер, он может собирать инструкцию по её структурному описанию. Просто ему передаётся не оптимальный формат. Вы можете вызвать декодер и данные передать в энкодер и посмотреть разницу у вас с тем что он соберёт, таким образом сделать фикс.

> Приложение грузится в отладчик и останавливается прямо на ЕП

Так с этого и нужно было начинать, а не говорить что у вас ничего не исполняется, а всё только в статике. Путать людей таким описанием.

-----
vx

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

Приложение грузится в отладчик и останавливается прямо на ЕП
Ничего я не путаю, ты просто понимаешь как хочешь, до этой точки ни одна инструкция кода приложения не исполнилась. Какая же тут динамика...

-----
Everything is relative...

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

Vamit

> до этой точки ни одна инструкция кода приложения не исполнилась

Приложение запускается но вы это исполнением не считаете. Я всё понял, вопросов больше нет, спс

-----
vx

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

Аналайзер плагин не ставился, пришлось шаманить. Под 64

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

Шрифт для x64 dbg и ollydbg в стиле SofICE.
Поддерживает кириллицу.


http://rgho.st/75jz6ZnTy


353d_07.01.2019_EXELAB.rU.tgz - SoftICE.fon

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

Подскажите, имеется ли возможность быстро выделить в редакторе большой блок кода (например 200кБ)?
Кроме как Shift+Up/Down ничего не нашел, Shift+PageUp/PageDown не работают. Функции выделения кода, например Select(beginAddr, endAddr), также отсутствуют.

-----
Everything is relative...

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