Как прыгнуть на [GetProcAddress]?

[FaKk2]

Предлагаю запретить слова .NET, дотнет, native, ассемблер, с++, delphi в форуме по VB6. А то право же, чуть ли не каждый топик противники дотнета разводят фарс и флейм.

[Хакер]

Глупое предложение.

[Twister]

А то право же, чуть ли не каждый топик противники дотнета разводят фарс и флейм.

Ну почему фарс? Просто хотелось услышать что-то новое о сей технологии. И почему противники? Просто интересующиеся... Странно, но в сети довольно редко встречаются палемики на тему "а нафига нам ассемблер?". А вот о .NET'е спорят намного чаще. С чего бы?

[alibek]

Странно, но в сети довольно редко встречаются палемики на тему "а нафига нам ассемблер?". А вот о .NET'е спорят намного чаще. С чего бы?

И что с того?
Обсуждения на тему "нафига нам фокал" встречаются еще реже.

[Twister]

Ну Алибек, не надо утрировать.
Еще раз: флуд разводить не хочется, хочется конкретики с той и с другой стороны.

[Хакер]

Конкретика или флуд — в другом месте. С этого момента любые сообщения не по сабжу в этой теме тру, как только замечаю.

[arthur2]

Кроме упомянутой статьи от GSerg-a есть ещё два довольно пространных, очень интересных и очень непонятных обсуждения на ту же тему с ним же:
Полноценный вызов функций по указателю
Полноценный вызов функций по указателю и препроцессор

[Хакер]

Ну по поводу первой статьи: я так сделал, например, в FNDLL, но для режима отладки использовался не медленный способ, а специальная DLL-шка-времянка.

А по-второму, сложно сказать, это что-то закрытое. (Ага, там эддины. Эддины многих не устраивают.)

[0xy]

Сказали б хоть пару слов

[arthur2]

По первой ссылке - не только статья, но и очень интересное обсуждение между GSerg-ом, tyomitch-ем и Approximator-ом (как раз с тем самым комментарием, который на сайте лежит вместе со статьёй, кстати). Там есть и про вызов по указателю через отдельную маленькую длл и сама эта длл выложена (я, кстати, ей даже пользуюсь)

это что-то закрытое

По второй ссылке ниже в теме лежат и исходники

[Хакер]

По первой ссылке - не только статья, но и очень интересное обсуждение между GSerg-ом, tyomitch-ем и Approximator-ом (как раз с тем самым комментарием, который на сайте лежит вместе со статьёй, кстати). Там есть и про вызов по указателю через отдельную маленькую длл и сама эта длл выложена (я, кстати, ей даже пользуюсь)

Понятно. Мне это мало интересно, к тому же у меня своя маленькая DLL есть для вызовов в режиме отладки.

Так вопрос по кирпичу: как мне сделать словарь ИмяУказателя→{Адрес+Флаг}? Т.е. каким мне его сделать, чтобы вы не испугались кода. Будь мне самому лично это надо, я бы заюзал свою «технологию» Krm. В но в данном случае, отсутствие дополнительных библиотек и ассемблерных вставок — вся суть.

За исключением этого момента кирпич готов.

И ещё момент:

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

MagicPointer("Example") = ...
Example 1, 2, 3

А могу ещё сделать так:

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

MagicPointers!Example = ...
Example 1, 2, 3

Но будем два модуля (класса и обычный). Ага или не ага?

[arthur2]

как мне сделать словарь ИмяУказателя→{Адрес+Флаг}? Т.е. каким мне его сделать, чтобы вы не испугались кода.

Вопроса не понял, кода, скорее всего, всё равно испугаюсь...

Но будем два модуля (класса и обычный). Ага или не ага?

А в первом варианте - один модуль? Тогда так легче не испугаться кода...

MagicPointers!Example = ...

С такой конструкцией я не знаком То есть, я знаю, что в языке что-то такое есть, но не понимаю, ни как использовать, ни что это вообще... Так что голосую за этот вариант - чтобы за одно и с этим разобраться

[Хакер]

Так и не понял, какой из вариантов ты выбрал.

Кстати, ещё родился третий вопрос: есть у меня тьма, просто тьма идей насчёт решения «страшной проблемы». Разные варианты имеет разные преимущества и недостатки. В частности, наиболее желаемые, по моей оценке:

• Без ассемблерных вставок, но включенную фичу надо обязательно выключать (по аналогии с сабклассингом, который надо снимать в IDE, иначе скорее всего беда). А всегда выключать — довольно сложное требование, потому что кнопкой «Стоп» придётся пользоваться часто.
• Можно не отключать, но используется ассемблерная вставка (собственно, чтобы беда не настала)
• Пропатченная vba6.dll, и отсутствие отдельного кода для поддержки техники под IDE
• Патчер, который делает из любой dll (vba5, vba6) пропатченную.

Ну как-то так. Чего желаете?

[Хакер]

С такой конструкцией я не знаком То есть, я знаю, что в языке что-то такое есть, но не понимаю, ни как использовать, ни что это вообще... Так что голосую за этот вариант - чтобы за одно и с этим разобраться

aaa!bbb эквивалентно aaa("bbb"), и не более того.

[arthur2]

Так и не понял, какой из вариантов ты выбрал.

Второй вариант в плане "испугаться кода" кажется страшней, но, наверное, удобней? И - раз такой вопрос у тебя возник, наверное, интересней?

Так что голосую за этот вариант

Кстати, ещё родился третий вопрос:

Я - за без ассемблерных вставок

Патчер, который делает из любой dll (vba5, vba6) пропатченную.

С исходником? Тоже интересно А его можно будет приладить только к твоему кирпичу, или и к тому же субклассингу, чтобы стало возможно стопом пользоваться?

[Хакер]

Второй вариант в плане "испугаться кода" кажется страшней, но, наверное, удобней? И - раз такой вопрос у тебя возник, наверное, интересней?

Да нет, он не страшнее, от первого он отличается только наличием строк, число которых наверное меньше десятка.

Я - за без ассемблерных вставок

Без ассемблерных вставок только один вариант: с самостоятельным отключением. Всё остальное — ассемблерные вставки, разница лишь в том где и как они вставляются. Пропатченный вариант, например, это вариант, где «вставка» сделана сразу в функцию из vba6.dll, которую я про себя назвал клонировщиком динамического кода.

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

С исходником? Тоже интересно А его можно будет приладить только к твоему кирпичу, или и к тому же субклассингу, чтобы стало возможно стопом пользоваться?

Для сабклассинга разумнее и проще пользоваться другим методом, который не лезет в кишки компилятора своими кирпичными щупальцами.

Да и исходник, будет написан скорее всего на С. Зачем мне с костылями мучиться...

[arthur2]

Без ассемблерных вставок только один вариант: с самостоятельным отключением.

Вот я за этот вариант.

Вариант кирпича без вставок - это "бери и разбирайся сам"
Вариант со вставками - это "бери и пользуйся", так что мне интересней первое

Для сабклассинга разумнее и проще пользоваться другим методом

А я и пользуюсь другим Просто в том другом методе, если помнишь, осталось одно маленькое но. Вот я и подумал, что подобным патчем можно было бы от "но" избавится

[Хакер]

Вариант кирпича без вставок - это "бери и разбирайся сам"
Вариант со вставками - это "бери и пользуйся", так что мне интересней первое

А почему ассемблерные вставки переводят вариант из категори «разбирайся сам» в категорию, не допускающую разбирания?

[arthur2]

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

Впрочем, это просто мои проблемы. Со вставками, наверное, лучше, и в любом случае, ты уже наверное решил, как будет

[Хакер]

Нет, я ещё не решил, я сейчас неработоспособен, а кирпич так и не дописан в плане нерешённых вопросов.

Просто я к чему хотел тебя подвести: кирпич полагается на особенности функционирования msvbvmXX или (vbaX), которые были выявлены мною в течение продолжительных реверс-инжениринг-сессий. Это, по-моему мнению, помощнее чем ассемблер. Например, достаточным условием понимания вставок является знание ассемблера. А для повторения моих исследований внутренностей VB это является лишь необходимым условием.

Кстати, для оценки общей понятности, вот код, «включающий фичу»:

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

Public Sub MagicPointersOnOff(ByVal bEngage As Boolean)
    Static bEngaged         As Boolean
    Static lpIATEntry       As Long
    Static lIATOrigValue    As Long
   
    If bEngage Then
        If bEngaged Then Exit Sub
       
        If lpIATEntry = 0 Then
            Dim hMyModule           As Long
            Dim vaPEHeader          As Long
            Dim vaImportTable       As Long
            Dim i                   As Long
            Dim ImportTable()       As IMAGE_IMPORT_DESCRIPTOR
            Dim saImportTable       As SA_DESCRIPTOR_FOR_VECTOR
            Dim nRelRtlDescriptor   As Long
            Dim nDbgRtlDescriptor   As Long
           
            hMyModule = App.hInstance
            GetMem4 hMyModule + Offs_e_lfanew, vaPEHeader: vaPEHeader = vaPEHeader + hMyModule
           
            With saImportTable
                .cDimensions = 1
                .cbItemSize = Sz_ImportDescriptor
                GetMem4 vaPEHeader + Offs_ImportTableRVA, .pData: .pData = .pData + hMyModule
                GetMem4 vaPEHeader + Offs_ImportTableSize, .cL1Elements
            End With
           
            PutMem4 AryPtr(ImportTable), VarPtr(saImportTable)
           
            nRelRtlDescriptor = -1
            nDbgRtlDescriptor = -1
           
            For i = 0 To saImportTable.cL1Elements - 1
                If ImportTable(i).rvaLookupTable = 0 Then Exit For
                Dim vaModuleName As Long
                vaModuleName = ImportTable(i).rvaModuleName + hMyModule
                Select Case 0
                    Case lstrcmpiA(vaModuleName, Nm_DbgRtlModuleName & Nm_DllExtension), _
                         lstrcmpiA(vaModuleName, Nm_DbgRtlModuleName)
                       
                        nDbgRtlDescriptor = i
                   
                    Case lstrcmpiA(vaModuleName, Nm_RelRtlModuleName & Nm_DllExtension), _
                         lstrcmpiA(vaModuleName, Nm_RelRtlModuleName)
                         
                        nRelRtlDescriptor = i
                        Exit For
                End Select
            Next i
           
            If nRelRtlDescriptor = nDbgRtlDescriptor Then
                PutMem4 AryPtr(ImportTable), 0&
                Err.Raise 5, , "Runtime library have not been found in module imports!"
                Exit Sub
            End If
               
            If nRelRtlDescriptor <> -1 Then
                Dim lpLookupCursor  As Long
                Dim lpszProcName    As Long
               
                With ImportTable(nRelRtlDescriptor)
                    lpLookupCursor = .rvaLookupTable + hMyModule
               
                    Do
                        GetMem4 lpLookupCursor, lpszProcName
                        If lpszProcName = 0& Then Exit Do
                        If lpszProcName > 0& Then
                            lpszProcName = lpszProcName + hMyModule + 2&
                            If lstrcmpiA(lpszProcName, "DllFunctionCall") = 0& Then Exit Do
                        End If
                        lpLookupCursor = lpLookupCursor + 4&
                    Loop
                   
                    If lpszProcName = 0 Then
                        PutMem4 AryPtr(ImportTable), 0&
                        Err.Raise 5, , "This module does not import DllFunctionCall."
                        Exit Sub
                    End If
                   
                    lpIATEntry = .rvaFirstThunk + (lpLookupCursor - .rvaLookupTable)
                End With
               
                Dim DFCDiscoveryBuffer(0 To 3)  As Long
                Dim DFCDiscoveryLookup          As EB_DELAYED_IMPORT_LOOKUP_ENTRY
               
                DFCDiscoveryLookup.lpszModuleName = StrPtr(StrConv(Nm_RelRtlModuleName, vbFromUnicode))
                DFCDiscoveryLookup.lpszFunctionName = StrPtr(StrConv("DllFunctionCall", vbFromUnicode))
                DFCDiscoveryLookup.sImportFlags = EB_DELAYED_IMPORT_FLAG_BY_NAME
                DFCDiscoveryLookup.lpImportEntryAddresses = VarPtr(DFCDiscoveryBuffer(0))
   
                lIATOrigValue = DllFunctionCall(DFCDiscoveryLookup)
            Else
                ' код, включающий фичу под IDE. Зависит от выбранного способа
            End If
           
            PutMem4 AryPtr(ImportTable), 0&
        End If
       
        VirtualProtect lpIATEntry, 4, PAGE_EXECUTE_READWRITE, i
        PutMem4 lpIATEntry, AddressOf LocalResolver
        VirtualProtect lpIATEntry, 4, i, i
        bEngaged = True
       
    Else

Вот тут вставок нет, а полагание на особенности работы работы msvbvm минимально.
Получается разобраться?

[arthur2]

Конечно же, разобраться пока не получается
Хорошо бы посмотреть, что за структуры и как они объявлены:
Хорошо бы минимальные комментарии.

Из того, что я понял (если понял): ты ищешь в таблице импорта DllFunctionCall и подменяешь указатель на неё на собственную функцию LocalResolver.

а полагание на особенности работы работы msvbvm минимально

Надо бы понять, какие особенности работы DllFunctionCall Что она возвращает? Ты её вызываешь, скормив ей структуру, где в качестве имени функции указана она же Это чтобы потом вернуть всё как было?

[Хакер]

Хорошо бы посмотреть, что за структуры и как они объявлены:

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

Private Type IMAGE_IMPORT_DESCRIPTOR
    rvaLookupTable              As Long
    TimeDateStampt              As Long
    ForwarderChain              As Long
    rvaModuleName               As Long
    rvaFirstThunk               As Long
End Type

Private Type SA_DESCRIPTOR_FOR_VECTOR
    cDimensions                 As Integer
    fFeatures                   As Integer
    cbItemSize                  As Long
    cLocks                      As Long
    pData                       As Long
    cL1Elements                 As Long
    iL1LBound                   As Long
End Type

Private Type EB_DELAYED_IMPORT_LOOKUP_ENTRY
    lpszModuleName              As Long
    lpszFunctionName            As Long
    sImportFlags                As Integer
    sFunctionOrdinal            As Integer
    lpImportEntryAddresses      As Long
End Type

Хорошо бы минимальные комментарии.

Их нет.

Из того, что я понял (если понял): ты ищешь в таблице импорта DllFunctionCall и подменяешь указатель на неё на собственную функцию LocalResolver.

Грубо говоря, да. Ищу в LookupTable, а подменяю в IAT.

Что она возвращает?

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

Ты её вызываешь, скормив ей в качестве параметра структуру, где в качестве имени функции указана она же Это чтобы потом вернуть всё как было?

Ага Я понимаю, что вызов функции с параметрами, содержащими упоминание самой этой функции, это несколько странно. Я называю этот приём DllFunctionCall-Discovery. Или по-русски: прокладывание себе дороги. Дело в том, что в LocalResolver вызывается оригинальная DllFunctionCall, если идёт обычный вызов (а не использование указателя). Это вместе с методикой создаёт следующее требование: все функции, которые вызываются внутри LocalResolver для обработки обычных случаев, должны быть уже разреловены. Иными словами, все функции, которые мы должны вызывать из LocalResolver-а, должны быть первый раз вызваны где-то раньше в другом месте. Иначе получится плохо: вызываем внутри LocalResolver функцию DllFunctionCall. Но её адрес неизвестен, и чтобы его узнать, совершается вызов DllFunctionCall (опять же!). Но этот вызов придётся на LocalResolver (мы же перехватили). И опять попытка вызова из LocalResolver-а. И опять попытка резолвинга. Замкнутый круг, то есть неконтролируемая рекурсия и переполнение стека в конце.

А так адрес DllFunctionCall занесётся во внутреннюю таблицу отложенного импорта, и попытка вызова из LocalResolver пойдёт просто через эту таблицу. Всё хорошо.

Почему я указываю ей в качестве параметров саму себя? Ну надо же что-то указать. С пустыми параметрами вызов не прокатит (вернее прокатит, но будет VB-шная Run-time error). Так что мы вынуждены заставить её что-то искать. Ну а раз она ещё и возвращает адрес, почему бы не попросить её вернуть адрес самой себя? Авось понадобится, да плюс освобождаемся от необходимости объявлять LoadLibrary/GetProcAddress.

Такие дела

[arthur2]

Вообще - круто!!! И не терпится продолжения

На сколько я понимаю, DllFunctionCall в бейсике ответственна за вызов продекларированных Апи... У меня тут появилась мысль: раз мы перехватываем DllFunctionCall, значит по большому счёту перехватываем все продекларированные функции. Так? Если мы поместим эту фичу в аддин, то можем делать не падающие в ИДЕ хуки, субклассинги и таймеры, просто подменяя в нужный момент в вызовах соответствующий функций адреса callback-функции на безопасные внутри аддина. При этом код самих проектов можно будет вообще не трогать

[Хакер]

На сколько я понимаю, DllFunctionCall в бейсике ответственна за вызов продекларированных Апи...

Не за вызов, а за поиск и занесение адреса в таблицу (или вывод ошибки). И для каждой функции DllFunctionCall вызывает единожды, я же сказал.

У меня тут появилась мысль: раз мы перехватываем DllFunctionCall, значит по большому счёту перехватываем все продекларированные функции. Так?

Нет, значит мы перехватываем попытки их поиска.

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

Какая связь между DllFunctionCall и callback-ами? Вообще не уловил.

[arthur2]

Не за вызов, а за поиск и занесение адреса в таблицу (или вывод ошибки). И для каждой функции DllFunctionCall вызывает единожды, я же сказал.

Почему, я понял Но раз мы перехватываем DllFunctionCall, значит мы же и решаем, какой именно адрес записать в эту таблицу. Так? То есть, если мы захотим перехватить некую продекларированную Test, то в момент, когда бейсик вызовет для неё первый и единственный раз DllFunctionCall, мы можем подменить адрес Test на адрес нашей собственной myTest. Так? Или я всё-таки неправильно понимаю?

[Хакер]

Так. Собственно, это я и делаю.

Кстати, способ заставить вызывать свою функцию постоянно, а не только в первый раз — есть. Надо просто ничего не записывать в таблицу.

Но как это связано с callback-ами? Объяснишь?

[arthur2]

Скажем, мы в аддине. Мы перехватываем вызов из кода SetWindowLong, и если вторым параметром идёт GWL_WNDPROC, то подменяем адресс callback в коде на адрес callback в аддине. И внутри аддинской винпрок делаем наш субклассинг безопасным... Как-то так

[Хакер]

Вселенская кривость.

Собираешься в Add-in-е предусматривать обработку всех возможных WinAPI? Понимаешь, что это не сработает для TLB? Понимаешь, что это не сработает, если вызывамая функция перехвачена подменой адреса в таблице экспорта?

Есть гораздо более правильные пути. «Перехватывать AddressOf» например.

[arthur2]

Есть гораздо более правильные пути. «Перехватывать AddressOf» например.

Как? И как понять, для субклассигна ли этот AddressOf, или, скажем, просто для перечисления окон?

Собираешься в Add-in-е предусматривать обработку всех возможных WinAPI?

Зачем? Субклассинг ведь ставится только SetWindowLong
и CreateWindowEx? Или есть ещё варианты? В любом случае, вариантов не так много.

Понимаешь, что это не сработает для TLB?

Ну да. Но зато необязательно будет никак менять отлаживаемый код. Собственно, никто не помешает юзеру аддина для отладки использовать продекларированные функции, а в релизе просто закомментировать декларацию. Продекларированные ведь при компиляции имеют приоритет перед объявленными в тлб?

[Хакер]

Так тебя исключительно сабклассинг волнует, который является чистейшей воды частным случаем использования callback-ов? Или все случае использования callback-ов?

Если только сабклассинг — фи, как это скучно и не интересно.

Субклассинг ведь ставится только SetWindowLong

А если через UimSetWindowSpecialOptions, которая в свою очередь вызывает SetWindowLong? А если SetWindowLong перехвачена правкой адреса в таблице экспорта user32.dll?