# протестируйте plz app.exe под вислой и прочими осями

Да, работает - просто надо было под рутом запускать
[root@qwqw ~]# wine '/tmp/app-dll.rar_FILES/app.exe'
hello, hacker![root@qwqw ~]#

 

x0man, есле найдешь все адреса сразу и кинешь их в таблицу к премеру, то вызов функи будет call [someaddr]....
есле же последовать примеру криса, то у тебя будет чтото типа

Код (Text):

1. invoke GetModuleHandle...
2. mov ebx,eax
3. lea eax,[ebx+some_constant]
4. call eax
5. lea eax,[ebx+some_constant2]
6. call eax

причем константы известны при написании исходного кода и определяют ту или иную функцию

 

Novi4ek
давай не будем цепляться к словам. "моя идея" != "я первооткрыватель", скажем так: "у меня есть мысль и я ее думаю". кстати, программы от ms вызывают API по фиксированным адресам, заранее прописанным в таблице импорта и это знают все нормальные реверсеры, так что на новизну в самом деле претендовать трудно.

отказ от импорта на стадии загрузки и определение адресов на стадии компиляции - реально ускоряет старт exe файла, т.к. в реал-тайме совершается меньше действий.

зачем тогда нужна dll? а чтобы не тормозило как горящий лис. метровые exe - уж точно не гуд. exe должен быть маленьким и обеспечивать номинальный функционал, а все остальное подгружать уже когда появилось главное окно с которым юзер может работать, более того, если программа содержит редко используемые функции (классический пример - печать), то имеет смысл вынести их в dll.

изменение в dll потребуют перекомпиляции программы?! кто это сказал?! лишний jmp не такой уж оверхидный оверхид. можно даже и без jmp'а. достаточно создать в dll таблицу адресов функций. это будет двойной косвенный вызов, ну и что? даже при фаст-калл конверсии им все еще можно пренебречь. главное, что мы переносим работу импортера из реал тайма на стадию компиляции программы.

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

 

kaspersky
А как тебе это?Забыл дописать это под XP SP2

 

а вот так. W2K SP4

 

Можно просто юзать prebound imports (editbin /bind).

 

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

Хотя использовать DLL с фикс. адресом загрузки в коммерческом продукте я бы не рискнул.

 

Freeman
я канеш не знаю какая скорость у
call [imm32]
и у
lea eax, [ebx + imm32]
call eax
но доверия вторая конструкция не внушает...

 

green
> Хотя использовать DLL с фикс. адресом загрузки в коммерческом продукте я бы не рискнул.
конечно, тут должна быть обработка ошибок. если загрузить dll по тому адресу, которому хотим мы не можем, то либо:
а) тупо кладем в дистр несколько одинаковых dll, но с разными адресами
б) если обломались с загрузкой по фикс. адресу - выгружаем оттуда, что там есть.

собс-но проблема только в KERNEL32.DLL/NTDLL.DLL, которые выгружать никак не получится, и которые в висле с ее рандомизацией могут быть загружены... я даже не знаю по каким адресам, но изучение кода показывает, что вроде бы в первые 16 метров они не полезут. хотя в следующей версии все может измениться ;(

 

Таблицу импорта чего? проги что запакованна, или самого пакера?

ну сдамплю я её на диск... а смысл то в том что импорта ведь нет, и на кой чорт его восстанавливать...
прога ваша будет работать как работала раньше... =\
грубо выражаясь - это походу тоже самое что сдампить какой либо базонезависимый кодес...

P.S. мб я апять чото недопонимаю :-\

 

x0man
это просто у меня мысли скачут табуном. короче, мы имеем несколько обычных библиотек с фиксапами с одинаковым базовым адресом и при запуске программы загружаем их в случайном порядке, в результате чего системный загрузчик их как-то растасует по памяти (как загружаем - это отдельный вопрос).

теперь мы дампим процесс на диск. чтобы получить нормальный exe нужно восстановить импорт, для чего обычно импорт-ребилдер загружает библиотеки повторно, а потом ищет адреса, совпадающие с адресами функций в dll, неявно полагая, что они при повторном запуске не изменятся. а если же они изменяться (как в нашем случае), то...

 

kaspersky
одну вещь разъяснить хочу для себя...
эм... значит в моей проге будет эта фишка с адресами импортов и в моей же проге будет сложно восстановить импорты после дампа???

 

Win98SE 4.10.2222A - ок.
хелло хакер

А вот 185-байтным мега каркасом винда увы подавилась... Выдала "Файл неверно скомпонован - граница выравнивания меньше 0х1000. Повторите компоновку"

 

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

 

Это может быть превозможено ребилдером путём чтения памяти процесса, с которого только что был снят дамп же. И, хм, я проверил - Import Reconstructor v1.7 успешно правил дамп - в независимости от того, в каком порядке я грузил 3 дллки, имеющие одинаковую базу (могу показать выкладки). Вот если загрузить dll вручную - не через LoadLibrary - и поправить ей релоки и всё такое, то тут ImpRec обломается (разумеется). Но это имхо уже другая история.

Взгляд со стороны: не, слишком много телодвижений, нафиг.

А вот эта мысль

нам очень понравилась. А что? Просто прямые вызовы функций. Никаких релокаций ни в exe, ни в dll'ях; С тех пор как это можно использовать только со своими dll - нет никакой проблемы с перекомпиляцией exe (долго что ли?)). Единственное - правильно выбрать базу для dll и в самом начале инициализации экзешника зарезервировать память по этому адресу размером с DLL::ImageSize. Когда потребуется использовать функции из dll, просто освободить зарезервированный блок и помапить туда dll. Всё достаточно прозрачно и очень быстро.

 

kaspersky
Вообщем делайте пакер, а мы поковыряем