Как запретить чужой программе закрыться?

[Хакер]

но как быть с глобальной внедряемой переменной в VB я не знаю

Никак не быть, потому что она не нужна. Выделили память под глобальный кусочек, передали на него указатель функцие-установщику. У той параметр объявлен как ByRef As UDT, и она его кушает, как родной.

[Хакер]

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

Кому это рискованное дело нужно, если можно сделать CreateRemoteThread?

[Twister]

Хакер

Кому это рискованное дело нужно, если можно сделать CreateRemoteThread?

Кому нужно создавать поток, если мы имеем возможность выполнить наш код в уже имеющемся потоке? При этом наш код гарантированно самый первый и вызов LoadLibrary ничего не затрёт и не испортит. Какое же оно рискованное?

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

Я же говорю - костыли. Нафиг они нужны, если самый разумный в данном случае вариант это внедрение целой dll?

arthur2

Что такое EIP?

Это регистр, указывающий на инструкцию, которая будет выполнена следующей.

Как получить корректный адрес возврата?

Адрес возврата из LoadLibrary должен быть установлен в оригинальный EIP, который мы имеем при старте главного потока процесса.

и как положить на стек нужный адрес?

Расширяем стек (уменьшая регистр ESP, т.к. стек растёт вниз) на 8 байт. Новый_esp + 0 - адрес возврата, новый_esp + 4 - адрес строки с путём к dll. Подробнее расписано здесь, хотя есть куча ошибок и конкретно этого способа внедрения dll вроде как нет.

Манипулирование регистрами чужих потоков осуществляется с помощью Get/SetThreadContext.

[Хакер]

Кому нужно создавать поток, если мы имеем возможность выполнить наш код в уже имеющемся потоке? При этом наш код гарантированно самый первый и вызов LoadLibrary ничего не затрёт и не испортит. Какое же оно рискованное?

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

Я же говорю - костыли. Нафиг они нужны, если самый разумный в данном случае вариант это внедрение целой dll?

Наоборот, не костыли, а очень изящно. Никаких тебе недокументированных и грязных трюков. А вот с DLL — проблем целое море, если писать эту DLL на VB, а это так в рамках данного форума.

[Twister]

Где ты увидел что-то недокументированное? SetThreadContext чтоли?

[Хакер]

Где ты увидел что-то недокументированное?

Состояние регистра ESP на момент проведения подсечки — недокументировано.

[Twister]

Где ты увидел что-то недокументированное?

Состояние регистра ESP на момент проведения подсечки — недокументировано.

А оно нам нафиг не нужно. Мы увеличиваем esp на 8, после возврата из LoadLibrary значение встанет на место и станет таким же, каким было бы без нашего вмешательства.

[arthur2]

Мне бы хотелось чего-то как можно более законного и без асма, так что

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

это мне как-то больше нравится. И куда дальше?

[Хакер]

А оно нам нафиг не нужно.

Там может быть, например, 0 или, например, минус 8. Результат фатален.

И даже не говори мне, что на практике это маловероятно. Никто не гарантирует, что такого не может не быть.

[Хакер]

И куда дальше?

Это было предложено в качестве решения, в котором предполагается подгрузка DLL в АП чужого процесса. Я, честно говоря, не знаю, как это решает проблему невозможности сделать SetWindowLong чужому окну.

[Twister]

А оно нам нафиг не нужно.

Там может быть, например, 0 или, например, минус 8. Результат фатален.

И даже не говори мне, что на практике это маловероятно. Никто не гарантирует, что такого не может не быть.

Что за бред? Поток прервётся на EP модуля, в этот момент стек подготовлен к работе и esp содержит валидный указатель.

Я, честно говоря, не знаю, как это решает проблему невозможности сделать SetWindowLong чужому окну.

Что значит не знаю? Это даст нам возможность вызова любых функций без написания базонезависимого кода.

[Хакер]

Что за бред? Поток прервётся на EP модуля, в этот момент стек подготовлен к работе и esp содержит валидный указатель.

Где в описании флага «CREATE_SUSPENDED» написано, что это действительно так, что он прервётся именно в этом месте и esp вправду будет содержать валидный указатель?

Что значит не знаю? Это даст нам возможность вызова любых функций без написания базонезависимого кода.

Если ты об этом, то да, вместо моего fixer-а внешних ссылок в таком случае сработает резолвер импорта от системы. Но это никак не избавит нас от необходимости вызывать SetWindowLong в контексте чужого процесса. Предлагаю тебе придумать, как из внедряющегося процесса узнать адрес новой оконной процедуры (и адрес функции-хукера), размещённой во внедряемой DLL. Fire NativeDLL не рассматривается, так как ищется, насколько я вижу, «чистое» решение.

[Antonariy]

А как узнать размер процедуры?

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

Sub A
   fooooo barr
End Sub:Sub End_of_A:end sub

SizeOfA = AddressOf End_of_A - AddressOf A 'по смыслу

Шайтан
А запись End Sub:Sub End_of_A:end sub именно в такой форме гарантирует, что и в памяти они окажутся по соседству?

[arthur2]

Это было предложено в качестве решения, в котором предполагается подгрузка DLL в АП чужого процесса. Я, честно говоря, не знаю, как это решает проблему невозможности сделать SetWindowLong чужому окну.

Чесно говоря, если вернуться к началу темы, проблема была в дургом.
Я так полагаю, что в поток, прицепленный к процессу, можно поставить локальный хук и выловить WM_CLOSE.

[Twister]

Что за бред? Поток прервётся на EP модуля, в этот момент стек подготовлен к работе и esp содержит валидный указатель.

Где в описании флага «CREATE_SUSPENDED» написано, что это действительно так, что он прервётся именно в этом месте и esp вправду будет содержать валидный указатель?

Ты сам задумайся. Разве может быть иначе? Где по-твоему еще может остановиться выполнение? Не в рандомном же месте. Тут написано:

The primary thread of the new process is created in a suspended state, and does not run until the ResumeThread function is called.

Чтобы возобновить поток, мы должны вызвать ResumeThread. Вызвать мы её можем хоть сразу, и поток пойдёт выполняться дальше. Следовательно esp инициализирован верно.

ЗЫ. Такое ощущение, что ты просто хочешь докопаться. Неужели вызывает сомнение моя компетентность в данном вопросе?

[Twister]

Предлагаю тебе придумать, как из внедряющегося процесса узнать адрес новой оконной процедуры (и адрес функции-хукера), размещённой во внедряемой DLL

Ничего не понял. Какой внедряющийся просесс?

Но это никак не избавит нас от необходимости вызывать SetWindowLong в контексте чужого процесса.

Кто-то говорил обратное?

[Хакер]

А запись End Sub:Sub End_of_A:end sub именно в такой форме гарантирует, что и в памяти они окажутся по соседству?

Компиляция функция осуществляется всегда в том же порядке, в котором они размещены в коде. Однако, есть один подводный момент, о котором я как раз собирался упомянуть: если компилятор найдёт ещё один пустой Sub, ничего не принимающий и ничего не возвращающий, он не будет генерировать код для двух идентичных Sub-ов, а отбросит один из них. Может отбросить и Sub, выполняющий роль маркера конца процедуры. Поэтому, надо обеспечить, чтобы Sub был уникальным в рамках проекта. Сделать это просто — Sub превратить в функцию, которая возвращает уникальное число.

Есть и другие подводные камни, но они из другой плоскости, и я жду, пока автор об них спотыкнётся.

Ты сам задумайся.

Я занимаюсь этим постоянно.

Разве может быть иначе? Где по-твоему еще может остановиться выполнение?

Может. Предположим, что он останавливается где-либо внутри kernel32!BaseProcessStart, до вызова из оной нашей EP. Теперь, не глядя (насильно!) на существующую BaseProcessStart (и на отсутствие там далее упомянутого региона), представляем себе, что в BaseProcessStart есть регион кода, в котором esp принимает невалидное значение. Мало ли, вышла новая винда с изменённым BPS или какой-то антивирус/руткит подменил BaseProcessStart на свою. Не имеет значения. Имеет значение лишь то, что MS не гарантирует и не определяет, где именно остановится базовый поток и что будут содержать регистры. А раз не гарантирует не определяет, полагаться на это нельзя, несмотря ни на что.

и поток пойдёт выполняться дальше. Следовательно esp инициализирован верно.

Неследовательно. Вот как раз, может быть, дальше-то esp и исправится на валидное значение. А вот конкретно сейчас там может быть вовсе невалидное значение.

ЗЫ. Такое ощущение, что ты просто хочешь докопаться. Неужели вызывает сомнение моя компетентность в данном вопросе?

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

[arthur2]

Есть и другие подводные камни, но они из другой плоскости, и я жду, пока автор об них спотыкнётся.

Я ж говорю - садистский кайф

[Twister]

Мне бы хотелось чего-то как можно более законного и без асма, так что

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

это мне как-то больше нравится. И куда дальше?

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

Давай еще раз, подведём итог.
Чтобы внедрить одну процедуру, тебе нужно вызвать всего пару функций. Это легче. Однако код такой процедуры, которая будет корректно вызывать SetWindowLong в чужом процессе, на VB будет написать ОЧЕНЬ проблематично. Тут придётся осваивать вызов функций по указателю.
Мой же способ сложен только тем, что ты не очень хорошо разбираешься в теме. Т.е. он сложен для тебя. Однако он тут мы избавляемся от нужды писать базонезависимый код или еще как-то изгаляться. Мы внедрим dll написанную на любом языке и она будет прекрасно работать.

[Twister]

Вызывает не сомнение, а вызывает опасение твой подход, заключающийся в полагании на авось.

Никакого авося тут нет. Это аксиома. Так было есть и будет просто потому, что ему негде больше останавливаться. Точка.

[arthur2]

Twister Убедительно А то, что я не очень хорошо разбираюсь в теме - вообще-то, мягко сказано. Я в ней вообще никак не резбираюсь. Ковыряю методом тыка, опираясь на подсказки, которые понимаю не до конца

[Хакер]

на VB будет написать ОЧЕНЬ проблематично. Тут придётся осваивать вызов функций по указателю.

Не правда. Не правда.

Однако он тут мы избавляемся от нужды писать базонезависимый код или еще как-то изгаляться.

Кому нужна базонезависимость? Чем код функции вообще, по твоему, зависит от базы? Тем, что в него вшиты абслютные адреса ячеек IAT? Так он не от базы зависит, а от наличия этих самых ячеек, которых заведомо не будет.

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

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

[Antonariy]

Есть и другие подводные камни, но они из другой плоскости, и я жду, пока автор об них спотыкнётся.

Я ж говорю - садистский кайф

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

[Хакер]

на VB будет написать ОЧЕНЬ проблематично. Тут придётся осваивать вызов функций по указателю.

Твистеру ещё раз.

Вот код функции из этого проекта. Она внедряется в чужой процесс тем же методом (VirtualAllocEx + WriteProcessMemory), но как видишь, при её написании меня совершенно не волнует, что она будет выполняться в чужом АП, я спокойно использую вызовы API-функций.

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

Private Sub InterruptPreparation(ByRef id As HANDMADE_INTERRUPT_DATA)
    '
    ' Эта функция вызывается ДО вызова обработчика прерывания в кон-
    ' тексте процесса и потока, в котором инициируется прерывание.
    ' Всё, что должна сделать эта функция: сохранить значение потоко-
    ' специфичной переменной LastErrorValue (хранится в TEB), чтобы
    ' восстановить после завершения работы обработчика прерывания.
    '
   
    id.SoftwareContext.SavedLastError = GetLastError()
End Sub

Private Sub InterruptPostProcessing(ByRef id As HANDMADE_INTERRUPT_DATA)
    '
    ' Эта функция вызывается ПОСЛЕ вызова обработчика прерывания в кон-
    ' тексте процесса и потока, в котором инициируется прерывание.
    ' Она должна вернуть старое значение переменой LastErrorValue, про-
    ' верить работоспособность хост-процесса, если он жив — установить
    ' объект событие и ждать, пока хост-процесс исправит контекст
    ' потока. Если хост-процесс мёртв, эта функция попробует самостоя-
    ' тельно исправить свой поток через выброс исключения и его обработ-
    ' ку.
    '
   
   
    '
    ' Проверяем, жив ли процесс (вернее поток, который всё вернёт
    ' на свои места). Если нет, имеет смысл решить проблему своими сила-
    ' ми, попутно закрыв хендлы. Если жив, он сам закроет эти хендлы
    ' в конце процесса восстановления состояния прерванного потока.
    '
       
    Select Case WaitForSingleObject(id.hHostThread, 0)
        Case WAIT_TIMEOUT
            '
            ' Поток работает. Возвращаем старое значение LastErroValue и
            ' сигнализируем ему (потоку), что обработчик прерывания за-
            ' вершил свою работу.
            '
           
            SetLastError id.SoftwareContext.SavedLastError
           
            If SetEvent(id.hCompletionEvent) Then
                Do
                    '
                    ' Беспечно циклически отдаём квант процессорного
                    ' времени другим потокам, в ожидании того, что
                    ' этот поток будет заморожен (SuspendThread) и
                    ' восстанволен в исходное состояние, а затем
                    ' разморожен (ResumeThread).
                    '
                   
                    SwitchToThread
                   
                    If WaitForSingleObject(id.hHostThread, _
                                           0) <> WAIT_TIMEOUT Then
                        '
                        ' Пока мы ждали, что хост-процесс нас починит,
                        ' хост-поток умер, так что никто (кроме нас
                        ' самих) нас уже не починит. Выходим их цикла
                        ' ожидания.
                        '
                       
                        id.hHostThread = 0&
                        Exit Do
                    End If
                Loop
            End If
           
            '
            ' В норме выполнение не должно дойти до сюда. Но если это
            ' произошло, значит либо хост-поток умер уже после выста-
            ' вления события, либо само событие выставить не удалось.
            '
           
            GoTo AbnormalSelfRecovery ' а как иначе, если сишный break
                                      ' «ставится» по умолчанию? ;(
        Case WAIT_OBJECT_0
            '
            ' Поток мёртв (завершил свою работу), поэтому закрываем
            ' хендлы и зануляем их в структуре, чтобы обработчик
            ' прерывания понял, что прерывания вызвано по случаю
            ' плачевного состояния хост-процесса/хост-потока.
            '
           
AbnormalSelfRecovery:
            If id.hHostThread <> 0& Then
                CloseHandle id.hHostThread
                id.hHostThread = 0&
            End If
           
            CloseHandle id.hHostProcess
            id.hHostProcess = 0&
           
           
            '
            ' Всю остальную работу выполнит обработчик (наш же) исключе-
            ' ния. Инициируем исключение.
            '
           
            ' RaiseException FIX IT!
       
           
        Case WAIT_FAILED
            '
            ' Получить состояние объекта-потока не получилось. Интересно,
            ' что надо делать в этом случае?..
           
    End Select
   
   
   
End Sub


Мы внедрим dll написанную на любом языке и она будет прекрасно работать.

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

[Twister]

я спокойно использую вызовы API-функций

Блин. Я что, утверждаю что этого нельзя сделать? Я говорю что никакой код нельзя просто скопировать в том виде, в каком он есть по умолчанию, если он использует специфический RTL или вызовы статически импортированных функций. И ты это сам прекрасно знаешь. Ну привёл ты кусок текста и что? Он никак не раскрывает суть того, какие машинные команды соответствуют вызову той же WaitForSingleObject, к примеру. Тут ты скорее всего обрабатываешь код перед внедрением и call либо направляется на специальный переходник, либо использует абсолютный адрес.

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

Что? С каких это пор библиотека, загруженная цивилизованно с помощью LoadLibrary, не знает что и где у неё находится? Раскрой свою мысль, а то создаётся впечатление, что ты не спал пару суток Еще раз повторю - мы грузим dll и она сама всё делает, сама ставит все перехваты. Нам после её подгрузки вообще ничего не надо делать.

[arthur2]

Antonariy Ага, экономия времени, денег и нервов - на лицо...

[Хакер]

Я что, утверждаю что этого нельзя сделать? Я

Ты сказал, что написание внедряемой процедуры само по себе сложно и что требуется шайтанить вызов функции по указателю. Я продемонстрировал обратное: написание самой внедряемой процедуры — прозрачный процесс. Вызывать что-то по указателю нужды нет.

Да, действительно, есть fixer внешних зависимостей — мой модуль с примерно 2k строчек кода, полностью на VB. Я его скоро выложу в «кирпичи». Он большой только из-за своей универсальности. К слову, в указанном коде зависимостей от RTL нет, и код приведён ещё и для того, чтобы показать, что писать независимый от RTL код довольно легко (слышишь, Артур, это же то, о чём ты мечтал когда-то?)

Что? С каких это пор библиотека, загруженная цивилизованно с помощью LoadLibrary, не знает что и где у неё находится?

Библиотека знает, а вот пользователь библиотеки (тот, кто её загрузил) — не знает.

и она сама всё делает, сама ставит все перехваты. Нам после её подгрузки вообще ничего не надо делать.

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

[Twister]

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

В DllMain, не?

В общем, я тут пошаманил со своим способом немного. Уж не знаю, то ли руки скривились, то ли что, но библиотеку загрузить сменой EIP основного потока получилось, а вот вернуться из LoadLibraryA в исходную позицию - никак. Много времени ковыряться у меня нет, поэтому оставлю реализацию метода всем желающим. Действительно, самый простой способ (и код меньше) - создать поток, стартующий на LoadLibrary.

[Twister]

Кстати я тут немного дезинформации залил
При флаге CREATE_SUSPENDED поток тормозит не на EP, а чуть ранее, в BaseProcessStart(). Впрочем, это никак не отменяет того, что ESP нормально инициализирован. Видишь ли, системный код microsoft'а не использует ESP в качестве переменной, он всегда валиден и указывает на вершину стека.

И да. Вместо создания дополнительного потока можно запускать процесс в suspended-состоянии и слать главному потоку APC (QueueUserAPC) с указателем на LoadLibrary. Всё законно, всё документировано

[Хакер]

В DllMain, не?

А теперь сюрприз: делая DLL-лку на VB, у нас нет привилегии объявить свою DllMain-функцию (Sub Main это не DllMain!). А значит нет и возможности указать свой код, который должен выполняться при загрузке библиотеки. Единственный вариант объявить DllMain в VB-шной DLL — это использовать FNDLL (ну, может быть у конкурентов что-то подобное есть).

Действительно, самый простой способ (и код меньше) - создать поток, стартующий на LoadLibrary.

Ну вот, переубедил

При флаге CREATE_SUSPENDED поток тормозит не на EP, а чуть ранее, в BaseProcessStart().

О чём я и писал.

чем, это никак не отменяет того, что ESP нормально инициализирован. Видишь ли, системный код microsoft'а не использует ESP в качестве переменной, он всегда валиден и указывает на вершину стека.

Вот этих ты плох. Тем, что смотришь конкретно в текущий код в свей версии винды и полагаешься на него. А надо смотреть в референс-документы и полагаться на написанное там. Так вот: нигде не закреплено, где именно остановится выполнение и какими будут значения регистров. Может быть через 10 лет MS изменят эти аспекты. А может быть сейчас есть вирус/антивирус, который подменяет BaseProcessStart на свою. И он имеет полное право где-то внутри использовать ESP в своих грязных целей, ведь нигде не написано, что на данном этапе ESP обязательно должно содержать что-то осмысленное.


В общем, резюмирую:
Какой бы путь не выбрал Артур, он (путь) всегда будет Хакеро-зависимым

Если внедряться через VirtualAllocEx+WriteProcessMemory, то нужен написанный мною модуль, исправляющий внешние ссылки.
Если внедряться через подгрузку DLL, то нужен написанный мною FNDLL, чтобы засунуть свой код в DllMain или экспортировать функцию (тогда процесс-пользователь сможет узнать, где именно внутри DLL находится нужный ему код).

Но я исхожу вот из какой логики: FNDLL — это Add-in, его надо устанавливаь, и без него проект невозможно будет поддерживать. А модуль — это модуль, проект с его участием будет действительными даже на чистой VBIDE. Поэтому я изначально стою на стороне первого варианта.

Вместо создания дополнительного потока можно запускать процесс в suspended-состоянии и слать главному потоку APC (QueueUserAPC) с указателем на LoadLibrary

А ты уверен, что поток в замороженном состоянии съест APC?