Посоветуйте дизассемблер длин для х86

Да, не заметил, что "интел 386". Тогда твой подойдёт.
С оговоркой, что нет никаких гарантий, что он работает корректно, потому что понять, как он работает, решительно невозможно.

А зачем Sleep(1) - не угадаю. Скорей всего, просто так.
Видимо, ты что-то там дебажил и забыл убрать (о чём свидетельствует и закомментированный try..except).

--- Сообщение объединено, 7 сен 2020 ---

Тора нет, а две васмовских ссылки никуда не ведут.
Если вкратце, что там за статьи?

 

Существует такой вариант https://github.com/vol4ok/libsplice
Дизассемблер длин находится в файлах ldasm.h и ldasm.c

На FASM-версию этого дизассемблера можно посмотреть в https://maalchemist.ru/SICx/SICx06.01.01.zip
Файлы SICIDA.ASH и SIC64IDA.ASM (SIC32IDA.ASM)

 

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

 

В качестве дизасма или дизасма длин можно IDebugClient/IDebugControl3 COM-интерфейсы использовать.

Код (C++):

1.  
2. //----------------------------------------------//
3. // Глобальные указатели на интерфейсы отладчика //
4. //----------------------------------------------//
5. static IDebugClient*   DebugClient  = NULL;
6. static IDebugControl3* DebugControl = NULL;
7.  
8. //----------------------------------------//
9. // Подцепить отладчик к текущему процессу //
10. //----------------------------------------//
11. bool DebuggerAttachSelf() {
12.     // Инициализация COM
13.     CoInitialize(NULL);
14.  
15.     // Объявление переменных интерфейсов
16.     auto control = (IDebugControl3*)NULL;
17.     auto client = (IDebugClient*)NULL;
18.  
19.     // Создание интерфейса клиента отладчика
20.     auto hres = DebugCreate(IID_IDebugClient, (LPVOID*)&client);
21.     if(FAILED(hres)) { ERR_HRES; return false; }
22.  
23.     // Создание интерфейса контроллера клиента отладчика
24.     hres = client->QueryInterface(IID_IDebugControl3, (LPVOID*)&control);
25.     if(FAILED(hres)) { ERR_HRES; return false; }
26.  
27.     auto pid = GetCurrentProcessId(); // Подключение к текущему процессу
28.     hres = client->AttachProcess(0, pid, DEBUG_ATTACH_NONINVASIVE | DEBUG_ATTACH_NONINVASIVE_NO_SUSPEND);
29.     if(FAILED(hres)) { ERR_HRES; return false; }
30.  
31.     // Запуск ожидание событий отладки
32.     hres = control->WaitForEvent(DEBUG_WAIT_DEFAULT, INFINITE);
33.     if(FAILED(hres)) { ERR_HRES; return false; }
34.  
35.     // Сохраняем интерфейсы в
36.     // глобальные переменные
37.     DebugControl = control;
38.     DebugClient = client;
39.     return true;
40. }
41.  
42. //----------------------------------------------------//
43. // Дизассемблировать инструкцию по переданному адресу //
44. //----------------------------------------------------//
45. DWORD DebuggerDisassemble(LPVOID address, LPSTR string, DWORD slen) {
46.     ULONG64 prev = (ULONG64)address;
47.     ULONG64 next = 0;  
48.     DWORD len = 0;
49.  
50.     // Вызов отладчика для дизассемблирования инструкции
51.     auto hres = DebugControl->Disassemble((ULONG64)address, 0, string, slen, &len, &next);
52.     if(FAILED(hres)) { ERR_HRES; return 0; }
53.  
54.     // Возврат длины инструкции
55.     return (DWORD)(next - prev);
56. }
57.  
58. //----------------------//
59. // Отключение отладчика //
60. //----------------------//
61. void DebuggerDetachSelf() {
62.     // Освобождение контрола
63.     if(DebugControl != NULL) {
64.         DebugControl->Release();
65.         DebugControl = NULL;
66.     }
67.  
68.     // Освобождение клиента
69.     if(DebugClient != NULL) {
70.         DebugClient->DetachProcesses();
71.         DebugClient->Release();
72.         DebugClient = NULL;
73.     }
74.  
75.     // Освобождение COM
76.     CoUninitialize();
77. }
78.  
79.  

 

Посоветуйте пожалуста юному падавану как разобраться, что такое com интерфейсы и как их юзать. Более-менее знаю, что такое win-api, но com интерфейсы кажутся абра-кадаброй. Каждый раз чувствую себя полным ослом когда читаю про ето. Может книги какие-то есть, которые облегчают понимание всево етово? Интуиция подсказывает мне, что это невероятно полезная вещь. З.Ы. с джавой не знаком от слова совсем, может быть сложности вызваны этим. Интерфейс - именованный набор абстрактных членов! Каждый раз когда читаю что-то подобное, не понимаю вообще ничево

 

Интерфейс в COM - это таблица указателей на функции (называемые методами). Прототипы функций определяют уникальный интерфейс. Первым аргументом всегда передается указатель на объект который по 0-му смещению содержит уже указатель на интерфейс. Первыми 3-мя методами в COM всегда идут методы интерфейса IUnknown. В COM это называется наследование. Через IUnknown::QueryInterface (функция по смещению 0) запрашивается нужный интерфейс. Через AddRef (1) и Release (2) ведется подсчет ссылок на объект.

 

Ну еще это называется vtable (таблица виртуальных методов), и по сути такой подход к наследованию и полиморфизму применяется почти во всех языках программирование с ООП. Поэтому, если вдруг захочется писать на Плюсах, или там на Дэ, вместо Цэ и Ассемблера, то это почти прозрачно реализуется классами с наследованием от IUnknown.

 

Всех с Новым годом!

По постам Mikl___'а, Thetrik'а, Rel'а понял, что COM интерфейсы и VST-плагины - это ближайшие родственники, а то может и вовсе братья близнецы. Я прав или не совсем?

 

Не, ну суть похожа, в том плане, как и у всех архитектур плагинов на Плюсах, но все же COM настолько сильно интегрирован в Венду, что если плюнуть в рандомное место в операционной системе, то велика вероятность, что попадешь в тот или иной COM-класс. На Юниксовых системах про COM мало знают, а VST он и в африке VST. Я вон даже на Линуксах нативные Вендовые VST запускаю через Wine и это даже стабильно работает (не все, конечно, до сих пор не получилось заставить продукты iZotope под Wine'ом работать).

 

VST3. Там каждый интерфейс наследуется от FUnknown (аналоге IUnknown в COM), имеющего те же методы queryInterface(), addRef(), release(). Хост дергает GetPluginFactory получая IPluginFactory интерфейс, через который создаются объекты. Аналогично в COM дергается DllGetClassObject и извлекается IClassFactory через которую создаются объекты. Вместо IClassFactory::LockServer используются InitModule/DeinitModule. Насколько я помню там даже по-моему бинарная совместимость с COM была (если методы не thiscall были).

 

Это все особого значения не имеет, COM классы регистрируются в реестре, чтобы быть доступными любому приложению через стандартные апи, в этом их суть и принципиальное отличие.

 

Это вообще не имеет отношения к вопросу. Регистрировать COM интерфейсы как и классы в реестре во многих случаях вообще необязательно.

 

Если можно, хотелось бы пример такого случая, а лучше несколько примеров, раз их много. Именно с COM, а не просто унаследованные от IUnknown. Мне для общего развития.

 

ormoulu,
COM - это не библиотека классов как, например, MFC и QT, а архитектурная модель. Любой класс "просто унаследованный" от IUnknown - это и есть самый что ни на есть COM.
Регистрация коклассов в реестре не нужна, если ты реализуешь local server (exe), в этом случае программа при старте вызывает CoRegisterClassObject и указанный класс будет доступен глобально в системе, пока программа работает.

 

Кстати иметь двоичный интерфейс с виртуальными таблицами COM-объект как раз таки не обязан. Он может зарегистрироваться как сервер с собственным процессом и дергать RPC напрямую. А вот примеров, когда не нужно ничего регистрировать в реестре, придумать не могу. Если только внедряться во все запущенные процессы, перехватывать API создания объектов?

 

Примеры на VB6 есть, на С могу по-позже сделать. Есть такой пример, там вообще все кроссплатформенно. Могу просто сказать как легко нагуглить - Reg-Free manifest. Также функции типа Direct3DCreate9 создают объекты и не требуют регистрацию в реестре (именно что касается COM). Реестр по сути нужен чтобы по CLSID/IID найти COM сервер, опционально информацию для маршалинга + еще некоторые редкие штуки.

Вот это не понял что имеется в виду. В COM все интерфейсы унаследованы от IUnknown.

--- Сообщение объединено, 1 янв 2023 ---

Как к нему будут приходить вызовы? Маршалер как раз через proxy/stub механизм транслирует параметры методов между апартаментами и вызывает методы в твоем процессе по виртуальной таблице (в CoRegisterClassObject ты передаешь иенно ссылку на COM интерфейс).

 

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

--- Сообщение объединено, 1 янв 2023 ---

Хмм... действительно )

 

Для чего? Я просто даже в голове не представляю зачем это нужно и как это в итоге будет выглядеть. Проще создать свой маршалер и не юзать системный typelib маршалер тогда. Хотите COM без COM?

 

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

Но похоже что не стоило и начинать.