Крах системы (Проблема с ХУК'ом )

[Antonariy]

Открываешь скомпиленную прогу в любом HEX-едакторе (я предпочитаю HIEW), ищешь то место, где расположился VarPtr и вместо его вызова (там будет call) забиваешь опкод 0xCC (int 3), а остальные байты call'a забиваешь нопами (0x90), чтоб код не превратился в кашу. Все. Теперь в отладчике ты остановишься там, где тебе нужно.

Ясно, как осеннее лондонское утро
Напиши хотя бы как выглядит сall в хексе. И где он кончается, чтобы не забить лишнее.

[Хакер]

Antonariy
А зачем ему их (хекс представления call-а) знать?

Gemini
Не пропусти этот пост:
http://bbs.vbstreets.ru/viewtopic.php?p=6691110#6691110

Последнее сообщение страницы обычно не замечают.

[Antonariy]

Эээ... Twister написал, что нужно править компиленный файл hex-редактором, а я так понимаю, что у asm'овского call есть свой hex-код, как у nop. Или я чего-то не то понимаю?

[Хакер]

Разумеется есть. Причём не один, а множество вариаций (far/near, abs/rel и т.д.)

Дело в том что Gemini даже если и придётся что-то править, то знать (именно знать заведомо заранее) код башки инструкции call не нужно. Он ведь будет не по коду её искать (ибо не найдёт он её по первому байту) - а смотреть в отладчике. А отлачик показывает (во-первых) VA/RVA/оффсет инструкции и (во-вторых) - хекс-дамп инструкции. OllyDbg показывает. Ну, собственно, про неё и речь шла.

[Gemini]

Хакер

2) Нет, я не имею ввиду это.

Я имею ввиду:

Да, я это и имел ввиду кроме "bRuntimeStarted".

Сейчас я пробую ещё оди метод.... Уже основываясь на ваших подсказках...
Дело в том что я заметил такую вещь:
Есть программа которая делает LoadLibrary что в свою очередь вызывает в VBHook.dll функцию DllEntryPoint с lReason =DLL_PROCESS_ATTACH
Вот а здесь начинаеться самое интересное:
Допустим что мы для проверки поставили в DLL_PROCESS_ATTACH мессадж "ляляляля"...
Так вот этот мессадж выскакивает 2 раза.
1)когда происходи LoadLibrary
2)Когда окно калька обрабатывает какое либо (первое) сообщение...
Т.е. у нас vbhook.dll загружаеться 2 раза один в память программы с вызовом loadlibrary а второй в кальк (с реакцией на сообщения)..
После чего можно спокойно сделать FreeLibrary а хук останеться все равно в кальке....
Глобальный вывод...
Первая загрузка должна быть такой:
ПРИ: MELOAD (или bRuntimeStarted) =False

Код: Выделить всё

Public Function HookProcName(ByVal nCode As Long, ByVal wParam As Long, lParam As tagMSG) As Long
if MELOAD (или bRuntimeStarted) = ture then
If lParam.message <> WM_NULL Then

        Select Case nCode
            Case HC_ACTION
             If lParam.message = WM_KEYDOWN Then

  Если здесь написать какой нибудь код то калькулятор вылетает!!!


             End If
            Case Else
        End Select
    End If
   
HookProcName = CallNextHookEx(hHook, nCode, wParam, lParam)
end if
End Function

Вторая соответственно:
ПРИ: MELOAD (или bRuntimeStarted) =True

Код: Выделить всё

Public Function HookProcName(ByVal nCode As Long, ByVal wParam As Long, lParam As tagMSG) As Long
if MELOAD (или bRuntimeStarted) = ture then
If lParam.message <> WM_NULL Then

        Select Case nCode
            Case HC_ACTION
             If lParam.message = WM_KEYDOWN Then

  Если здесь написать какой нибудь код то калькулятор вылетает!!!


             End If
            Case Else
        End Select
    End If
   
HookProcName = CallNextHookEx(hHook, nCode, wParam, lParam)
end if
End Function

Проверять это можно способом:
CreateToolhelpSnapshot
Process32First
Module32First
если мы узнаем что нашу VBHOOK.dll использует кальк то можно сделать FreeLibrary (В программе) и ловить хуки в кальке...
(Правда метод какой то корявый но иного метода кроме отлова от куда vbhook.dll была вызвана я не знаю)
(Даже не понадобилась TLB)

Вы в этом лучше понимаете. Возможно у вас будут лучше идеи.

[Хакер]

Вот а здесь начинаеться самое интересное:
Допустим что мы для проверки поставили в DLL_PROCESS_ATTACH мессадж "ляляляля"...
Так вот этот мессадж выскакивает 2 раза.
1)когда происходи LoadLibrary
2)Когда окно калька обрабатывает какое либо (первое) сообщение...
Т.е. у нас vbhook.dll загружаеться 2 раза один в память программы с вызовом loadlibrary а второй в кальк (с реакцией на сообщения)..

Да, именно так и должно быть. Но хуки в контексте калк'а начинают обрабатываться ещё до того, как пункт 2 произойдёт. Отсюда и падает всё.

(Дальше идут в противопоставление два куска кода, причём фишка в том, что куски ничем не отличаются... )

Проверять это можно способом:
CreateToolhelpSnapshot
Process32First
Module32First
если мы узнаем что нашу VBHOOK.dll использует кальк то можно сделать FreeLibrary (В программе) и ловить хуки в кальке...
(Правда метод какой то корявый но иного метода кроме отлова от куда vbhook.dll была вызвана я не знаю)

Проверять что? Что библа в контексте калка? А зачем это проверять?
Это не имеет никакого отношения к причине падения.

Сам по себе код HookProcName (который существуют в двух одинаковых экземплярах) кривой. По следующим причинам:

1) Если флаг не установлен, код CallNextHookEx вообще не вызывается. Это катастрофическая ошибка.

2) Если исправить пункт 1. - венести вызов CallNextHookEx из If-блока, то это не спасёт ситуацию, т.к. добавится обработка ошибок + вызов через Declare использует TLS (не путать с TLB!).

Поэтому за пределами If-блока надо использовать вызов CallNextHookEx, объявленной именно в TLB. Потому как это превратится в обычный вызов через таблицу импорта.

(Даже не понадобилась TLB)

Как видишь - всё-таки она понадобится.

Возможно у вас будут лучше идеи.

Скорее, у меня есть правильные идеи. Потому как твоя идея просто-напросто нерабочая.

[Twister]

Хакер
Ну, считай, что я предложил реализовать DebugBreak() ручками... Просто если там трабла с вызовом АПИ, то DebugBreak() имеет все шансы не быть вызванным.

и вроде как даже документированный способ

А вставка 0xCC как буд-то не документирована...

[Хакер]

Twister
Так я уже который раз твержу о TLB. С вызовом API через TLB никаких проблем быть не может по определению.

VB для Declare-функций имеет свою таблицу импорта, и свой загрузчик для неё (DllCallFunction, которая нифига не call, которая по праву должна называться DllGetProcAddress). Эта DllGetProcAddress использует TLS. TLS инициализируется в процессе инициализации рантайма.

Вывод: использовать DllCallFunction (т.е. вызывать Declare Api) функции в процессе инициализации библиотеки нельзя.

Хотя я помню, у ГСерга в его NativeDLL было можно, а там вообще никакой инициализации не было.

А вставка 0xCC как буд-то не документирована...

Конечно. Где ты в MSDN увидал призывы использовать хекс-редакторы для расстановки бреков?

[Twister]

Где ты в MSDN увидал призывы использовать хекс-редакторы для расстановки бреков?

Я увидел это в коде функции DebugBreak(). Чем IDA хуже MSDN?

... Впрочем, не будем разводить флуд...

[Gemini]

Хакер

Да, именно так и должно быть. Но хуки в контексте калк'а начинают обрабатываться ещё до того, как пункт 2 произойдёт. Отсюда и падает всё.

Возможно это можно как-то определить и не обрабатывать до появления певого сообщения, или вообще самому послать кальку сообщения до того как он вылетит....
А я раньше думал что всё падает из-за того что хук сначала ставится
на vb'шную программу...

Точно баз тлб не разобаться...

Я нашел исходник одной тлб, но туда надо загнать ещё одну структуру.

Код: Выделить всё

Public Type tagMSG
    hwnd As Long   
    message As Long 
    wParam As Long
    lParam As Long
    time As Long   
    pt As POINTAPI       
End Type


вот код idl:

Код: Выделить всё

[uuid(5080FEFB-E810-4502-8884-2BDA3563E10B), version(1.0),
helpstring("Declarations]

library HookDeclares
{
    importlib("stdole2.tlb");
    typedef struct
    {
      long Data1;
      short Data2;
      short Data3;
      unsigned char Data4[8];
    } VBGUID;
    typedef [public] VBGUID CLSID;
    typedef [public] VBGUID IID;
    typedef VBGUID* REFGUID;
    typedef VBGUID* REFIID;
    typedef VBGUID* REFCLSID;
    typedef enum
    {
      CLSCTX_INPROC_SERVER   = 1,
      CLSCTX_INPROC_HANDLER  = 2,     
      CLSCTX_LOCAL_SERVER    = 4,
      CLSCTX_REMOTE_SERVER   = 16
    } CLSCTX;

[dllname("user32.dll")]
module user32 {
[entry("CallNextHookEx")] long stdcall CallNextHookEx ([in] long hHook, [in] long nCode, [in] long wParam, [in] long lParam);
}
Где lParam должен стать tagMSG типом.


Будьте так добры... Сделайте пожалуйста из этого кода - тлб и idl (для изучения).