killing IAT -> Original Thunks

Ещё в Упаковщиках упоминалось, что загрузчик не использует таблицу lookup (aka Original Thunks) при обработке импорта. Так оно и есть. Проверил на Windows 95 и Windows XP - Original Thunks можно спокойно удалять из импорта и на работоспособности экзешника это никак не сказывается, если не считать мелкий нюанс с утилитой bind.exe, которая отказывается байндить импорт, если в нём нет этих самых "оригинальных санков".

При удалении лишних санков получается экономия 4 * (n + 1) байт, где n - это кол-во символов в поддиректории импорта. Даже для маленьких экзешников это довольно ощутимо.

Существуют ли ещё какие-нибудь противопоказания подобной оптимизации? Существуют ли утили для удаления Original Thunks или мой будет первым?

 

Попробуй дизассемблировать Windows, и тебе всё сразу станет ясно.

 

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

 

Quantum

А если bound import и date stamp не совпадает?

 

Dimson
Ну, я же написал, что байндить такую поддиректорию нельзя. Допустим, имеем в импорте 2 поддиректории:
kernel32.dll и myprivatedll.dll. Т.к. байндиться к кернелу мало кому придёт в голову (кроме МС в её остальных системных библиотеках), мы можем спокойно удалить оригинальный санк kernel32.dll. Санки myprivatedll.dll удалять не будем. В результате этих действий, myprivatedll.dll будет байндиться, а kernel32 - нет, т.е. конфликта тут нет.

 

В аттаче несколько либ импорта: comctl32.lib, comdlg32.lib, dsound.lib, kernel32.lib, msvcrt.lib, url.lib и winmm.lib. Все они составлены таким образом, чтобы при линковке в имидж не попадали оригинальные санки. К тому же, в эти либы добавлены символы из Win 2000, XP и Vista, включая недокументированные функции. К сожалению, при совместном использовании этих либ со стандартными (в которых есть оригинальные санки) из масма, вижуала и т.д., у линкера иногда срывает крышу и это отражается на работоспособности имиджа. Причём у разных версий линкера МС крышу рвёт по разному Поэтому желательно не рисковать и использовать исключительно санковые или безсанковые версии либ.

Исходники либ и новую версию макросов, которыми эти либы созданы, я выложу на днях у себя на сайте.

Не аттачится - придётся удалить несколько либ.

 

Quantum
Не понял, у тебя что ... сайт есть?

 

EvilsInterrupt
В данном конкретном случае имелся ввиду сайт ImpLib SDK (http://implib.sf.net)

 

Выкладываю ещё немного либ: свежий shell32.lib и те, что не поместились в прошлом аттаче. Я тут уже попробовал пересобрать несколько старых вижуальных проектов с этими либами - везде получил выйгрышь 0,5-1Кб.

 

а ничего что изменится размер структуры IMAGE_IMPORT_DESCRIPTOR ?

 

Asterix
Размер IMAGE_IMPORT_DESCRIPTOR не меняется, просто вместо RVA таблицы с оригинальными санками я указываю 0 в поле IMAGE_IMPORT_DESCRIPTOR.Characteristics и саму таблицу удаляю из импорта.

 

ну тогда здесь ничего нового, так делает фасм

 

При использовании макросов library и import в фасме создаются оригинальные санки и это правильно, т.к. без спроса удалять санки - это было бы наглостью При создании импорта вручную (в смысле, без макросов) можно и не создавать санки, конечно. В частности, в примере минимального безмакросового экзешника как раз оригинальных санков нет, что и натолкнуло меня на мысль добавить такую фишку в ImpLib SDK, чтоб можно было использовать и в масме, и в вижуале и в куче других компиляторов.

 

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

Код (Text):

1. section '.idata' import data readable
2.  
3. IMAGE_IMPORT_DESCRIPTOR:
4.     dd 0
5.     dd 0
6.     dd 0
7.     dd rva kernel_name    ; DWORD   Name
8.     dd rva kernel_table   ; DWORD   FirstThunk
9.  
10.     dd 0,0,0,rva user_name,rva user_table
11.     dd 0,0,0,0,0
12.  
13. kernel_table:
14.     ExitProcess dd rva _ExitProcess
15.     GetCurrentProcess dd rva _GetCurrentProcess
16.     CheckRemoteDebuggerPresent dd rva _CheckRemoteDebuggerPresent
17.     dd 0
18. user_table:
19.     MessageBox dd rva _MessageBoxA
20.     wsprintf dd rva _wsprintfA
21.     dd 0
22.  
23. kernel_name db 'KERNEL32.DLL',0
24. user_name db 'USER32.DLL',0
25.  
26. IMAGE_IMPORT_BY_NAME:
27. _ExitProcess dw 0
28.     db 'ExitProcess',0
29. _GetCurrentProcess dw 0
30.     db 'GetCurrentProcess',0
31. _CheckRemoteDebuggerPresent dw 0
32.     db 'CheckRemoteDebuggerPresent',0
33.  
34. _MessageBoxA dw 0
35.     db 'MessageBoxA',0
36. _wsprintfA dw 0
37.     db 'wsprintfA',0

 

user32.lib

 

На фасме я тему такую давно подымал http://board.flatassembler.net/topic.php?t=6165

 

asmfan
В тему, но ничего нового я там не нашёл. В общем, я уже понял, что оригинальные санки в 99% случаев можно и нужно ликвидировать. Осталось дописать gdi32 и advapi32 для полного счастья

 

Quantum, может тулзу накалякаешь для этого дела все таки?

 

Avoidik
Так тулза у меня есть Не голыми руками же я эти либы создаю. Я их собираю фасмом с помощью новой версии ImpLib SDK, которую ещё не зарелизил.

 

релиз ожидается?