"Очередной" декомпилятор?!..

zag2art
Все довожу до уровня, когда не будет очень стыдно за свое творение...

 

mrhx
по-поводу конктретно аспра - почитай давнюю статью Crusader'a про аспр или статью seeq, в них подробно описано, как работает аспр.
должно помочь в эмуляции.
если в импорте твоего HelloWord изначально не было wsock32, значит аспр импортирует её для своей встроенной dll, которую он сначала два раза распаковывает (aPlib -> VirtualAlloc -> ASPack), а потом запускает

 

Jupiter
Спасибо.
Пока, к сожалению, не было времени достаточно, чтобы работу продолжить.
Сейчас пока все заткнулось на RtlUnwind
То есть поддерживаю исключения (SEH) в какойто мере, достаточной для исполнения.
Но вот пока у меня RtlUnwind лажается -- я эту функцию пытаюсь сам выполнить покомандно.
Дохожу до syscall, и тут начинается самый прикол, потомучто это уже, насколько понимаю, очень системная вещь, которую мне не исполнить в рамках той системы, что у меня получается.
Так что надо RtlUnwind самому исполнять, но там, короче, нужен новый механизм специальный.
В общем, я уже близко к решению, хотя движок уже несколько раз переделывал :-D

 

zag2art
Я свое обещание выполнил, смотри мой сабж в Research.

 

Народ, короче вот уже прошло куча времени, а у меня так и не дошли руки, чтобы развить проект и преодолеть кое какие непонятки в win32 (застопорилось все на одной фигне с которой я мало знаком - SEH - а точнее, RtlUnwind, мне ее нужно самому реализовать, чтобы вызвать пользовательский обработчик из распаковываемой программы).

Есть желающие развить тему вместе со мной и другими, кто захочет?
Одному, чем дальше, тем тянуть будет сложнее... и дольше)..

Исходники планирую выложить в открытый доступ.

От версии, которая тут лежит, я не так далеко ушел.
Больше инструкций понимаю, больше API поддерживаю.

Объем исходника: 168КБ (на сях) + еще 27КБ дополнительного исходника (специальная asm_engine, чтобы команды ассемблера выполнять самому). В целом, в исходниках ничего сложного нет, кроме их объема.

Кого заинтересовало пишите тут .... .. .

 

у меня аналогичная наработка есть - правда не generic, а под StarForce заточенная (то есть, грузит в своем АП программу с навешенной StarForce, затем грузит protect.dll, инициализирует импорты и экспорты, а также контролирует АПИ из импортов).

 

Самое сложное написать анализатор кода, а дизассемблирование не так сложно сделать.
Вот сорцы рекогнизера VCL по сигнатурам (не такого как в DeDe, а с документацией и с саппортом) я бы прикупил.

 

Пвттерн матчинг - прощлый век.

 

Не спорю, но 5399 функций VCL матчить не простая задача. Нужно в секунду сравнить с паттернами сотню другую функций, то есть выходит 100 * 5399 = 539 900 тысяч итераций сравнения. Даже если индексировать то что уже сравнено все равно медленно получается. Нужен оптимальный алго, который способен работать со скоростью как в DeDe.

 

Нафига все матчить, декомпиялция, как я понимаю, подразумевает генерация качественного исходника ( иначе я бы например ИДУ или что-нить в етом роде ). Потому анализ начинется осюда и до обеда, то есть с точки входа и анализ всех веток на выполняемость, и только по адресам вызовов функций пробуем применить избирательное сравнение.
Паттерн матчинг не справляется с данной задачей потому, почему не работает лексический анализ при парсинге выражений с рекурсивной структурой.

 

Исходник это второй этап Для начала надо получить то что дает DeDe. А свернуть это в сорс - дело проще, так как я уже написал отлаженный код, который успешно применяю в своем декомпиляторе VB. То есть из результата DeDe вполне реально сворачивать в сорс, сложность написать генератор листинга как в деде. А все упирается в VCL. Надо быстро сравнивать, для этого нужно придумать формат сигнатур и алго сравнения и оптимизировать его чтобы на VB работал также как неоптимизированный на Delphi.

 

Для дельфи проще некуда.
1. Берем список модулей из PACKAGEINFO ( находится в ресурсах
).
2. Узнаем какие модули из RTL были использованы.
3. Исходя из этой информации сравниваем с сигнатурами тех функций, которые находятся в данных модулях.

 

GPcH

А что мешает налобать алго на C++, и подключить как библу?
Или вообще вынести ядро в отдельную библу и писать его с помощью более подходящего инструмента, а интерфейс на VB.

 

Дык речь о коде а не об остальном, остальное уже написано (не все, но большая часть):

http://www.vb-decompiler.org/temp/vb_or_delphi_heh_its_very_cool1.png

http://www.vb-decompiler.org/temp/vb_or_delphi_heh_its_very_cool2.png

Осталось только сделать детектирование VCL

 

А вот кстати работа моего обфускатора имен объектов и событий:

http://www.vb-decompiler.org/temp/vb_or_delphi_heh_its_very_cool4.png

 

=)

А обфускатор в курсе того, что в Delphi есть оператор is ( аналог dynamic_cast в С++ )?

 

А ты часто им пользуешься?

PS: все это будет либо отслеживаться либо добавляться в доку как ограничения обфускации.

 

Я когда-то делал так:

Код (Text):

1. typedef std::string pattern_t;
2.  
3. // сигнатура отдельного объекта
4. class signature_t
5. {
6.     friend bool operator < (const signature_t &x, const signature_t &y );
7.  
8.     pattern_t pattern;
9.     // полезная нагрузка
10.     ....
11. protected:
12.     pattern_t &Pattern() const { return pattern; }
13. public:
14. };
15.  
16. inline friend bool operator < (const signature_t &x, const signature_t &y )
17. {
18.    return x.Pattern() < y.Pattern();
19. }
20.  
21.  
22.  
23. typedef std::set<signature_t> sigset_t;

 

Я не пользуюсь, но в VCL такое встречается.

 

Просто надо писать обфускатор так, чтобы одинаковые имена заменял на одинаковые по всей программе. Тогда и is, и as будут работать как надо.