Здравствуйте, Аноним, Вы писали:

А>Пытался исползовать "Внедрение 1" под 2000-им , но на команде CreateRemoteThread
А>выдается ошибка Memory Can't be writen. В чем дело ?

Вероятно в отсутствии вот такого:

    if (VirtualProtect(pDest, dwSize, PAGE_READWRITE, &dwOldProtect))
    {
        memcpy(pDest, pSrc, dwSize);
        // Restore protection
        VirtualProtect(pDest, dwSize, dwOldProtect, &dwOldProtect);
    }

Здравствуйте, Sergey Ten, Вы писали:

ST>А какие преимущества у подхода push + ret по сравнению с jmp? Возможна ли ситуация, когда jmp не работает, а push+ret — работают? И на какие грабли здесь можно наступить?

На новых процах push + ret рассинхронизирует кеш адресов возврата со стеком. Шаманы утверждают, что потери производительности просто потрясающие.
На каждом последующем ret'е данные подчитываются из памяти.
Ну а преимущество конечно в том, что не нужно относительных адресов вычислять

Здравствуйте, В и к т о р, Вы писали:

ВИК>Здравствуйте, Sergey Ten, Вы писали:

ST>>А какие преимущества у подхода push + ret по сравнению с jmp? Возможна ли ситуация, когда jmp не работает, а push+ret — работают? И на какие грабли здесь можно наступить?

ВИК>У Рихтера прочитал, что JUMP зависит от процессора и вообще он про первый метод пишет:
ВИК>

ВИК>Этот метод был очень популярен среди программистов, создававших приложения для 16-разрядной Windows, и отлично работал в этой системе В современных системах у этого метода возникло несколько серьезных недостатков, и я настоятельно не рекомендую его применять. Во-первых, он создает зависимость от конкретного процессора из-за команды JUMP, и, кроме того, приходится вручную писать машинные коды. Во-вторых, в системе с вытесняющей многозадачностью данный метод вообще не годится. На замену кода в начале функции уходит какое-то время, а в этот момент перехватываемая функция может понадобиться другому потоку. Результаты могут быть просто катастрофическими!

Все не так страшно Главное — на время патчинга нужно остановить текущий процесс (all threads) или все процессоры (если мы в kernel mode системную ф-цию из global address space перехватываем). Так что годится. Мало того, успешно применяется

Здравствуйте, Alter_, Вы писали:

A_>Здравствуйте, Sergey Ten, Вы писали:

ST>>А какие преимущества у подхода push + ret по сравнению с jmp? Возможна ли ситуация, когда jmp не работает, а push+ret — работают? И на какие грабли здесь можно наступить?

A_>На новых процах push + ret рассинхронизирует кеш адресов возврата со стеком. Шаманы утверждают, что потери производительности просто потрясающие.
A_>На каждом последующем ret'е данные подчитываются из памяти.
A_>Ну а преимущество конечно в том, что не нужно относительных адресов вычислять

А какое же тут шаманство? Открываем толстый том Intel(r) IA-32 Optimization Reference Manual:

Inlining, Calls and Returns

The return address stack mechanism augments the static and dynamic
predictors to optimize specifically for calls and returns. It holds 16
entries, which is large enough to cover the call depth of most programs.
If there is a chain of more than 16 nested calls and more than 16 returns
in rapid succession, performance may be degraded.
The trace cache maintains branch prediction information for calls and
returns. As long as the trace with the call or return remains in the trace
cache and if the call and return targets remain unchanged, the depth
limit of the return address stack described above will not impede
performance.
To enable the use of the return stack mechanism, calls and returns must
be matched in pairs. If this is done, the likelihood of exceeding the
stack depth in a manner that will impact performance is very low.

Таким образом, при рассинхронизации внутреннего стека адресов возврата при каждом ret будет происходить branch misprediction с соответствующим сбросом конвейера. Хуже и придумать нельзя...

Здравствуйте, Тихомиров В.А., Вы писали:

ТВА>Статья:


ТВА>Авторы:
ТВА>Тихомиров В.А.

ТВА>Аннотация:
ТВА>С переходом на Windows использование системных ресурсов программистами в большом объеме стало осуществляться через функции API, и у многих «сиспрогов» стал возникать вопрос: «существуют ли в Windows технологии перехватов этих системных функций?» Особый интерес это вызывает применительно к высокозащищенным ОС, выполненным на ядре NT. Данная статья подробнейшим образом, с действующими примерами покажет практическую реализацию такой технологии (предполагается, что читатель знаком с принципами системного программирования в Windows и умеет применять в своей работе Visual C++).

Вот к этому:

Есть еще и третий способ внедрения, но он наиболее опасен, так как может привести к краху системы. При помощи данного метода ОС сама внедряет указанную dll во все без исключения процессы операционной системы, даже защищенные. Для реализации необходимо прописать в реестре по пути Hkey_local_machine\software\microsoft\windowsnt\currentversion\windows в ключе AppInit_DLLs полный путь к своей dll.

надо добавить

Кроме того, ключ AppInit_DLLs обрабатывается в коде инициализации user32.dll, так что если целевое приложение не загружает явно или неявно эту библиотеку, этот метод не сработает вовсе.

Здравствуйте, В и к т о р, Вы писали:

ВИК>Здравствуйте, Sergey Ten, Вы писали:

ST>>А какие преимущества у подхода push + ret по сравнению с jmp? Возможна ли ситуация, когда jmp не работает, а push+ret — работают? И на какие грабли здесь можно наступить?

ВИК>У Рихтера прочитал, что JUMP зависит от процессора

То есть вы хотите сказать, что jmp зависит от процессора, а push и ret — нет? Интересная точка зрения...

Здравствуйте, Alex Alexandrov, Вы писали:

AA>Здравствуйте, Alter_, Вы писали:

A_>>Здравствуйте, Sergey Ten, Вы писали:

ST>>>А какие преимущества у подхода push + ret по сравнению с jmp? Возможна ли ситуация, когда jmp не работает, а push+ret — работают? И на какие грабли здесь можно наступить?

A_>>На новых процах push + ret рассинхронизирует кеш адресов возврата со стеком. Шаманы утверждают, что потери производительности просто потрясающие.
A_>>На каждом последующем ret'е данные подчитываются из памяти.
A_>>Ну а преимущество конечно в том, что не нужно относительных адресов вычислять

AA>А какое же тут шаманство? Открываем толстый том Intel(r) IA-32 Optimization Reference Manual:
Шаманы из команды разработки intel

AA>Таким образом, при рассинхронизации внутреннего стека адресов возврата при каждом ret будет происходить branch misprediction с соответствующим сбросом конвейера. Хуже и придумать нельзя...
Ну вот и я о том же

Здравствуйте, Alter_, Вы писали:

AA>>А какое же тут шаманство? Открываем толстый том Intel(r) IA-32 Optimization Reference Manual:
A_>Шаманы из команды разработки intel

Ну надо же... Я тоже знаком с некоторыми из них...

A_>Все не так страшно Главное — на время патчинга нужно остановить текущий процесс (all threads) или все процессоры (если мы в kernel mode системную ф-цию из global address space перехватываем). Так что годится. Мало того, успешно применяется
Вы не могли бы поделиться кодом, который останавливает/запускает все потоки текущего процесса? Не хочется изобретать велосипед.

Здравствуйте, Alex Alexandrov, Вы писали:

AA>Здравствуйте, В и к т о р, Вы писали:

ВИК>>Здравствуйте, Sergey Ten, Вы писали:

ST>>>А какие преимущества у подхода push + ret по сравнению с jmp? Возможна ли ситуация, когда jmp не работает, а push+ret — работают? И на какие грабли здесь можно наступить?

ВИК>>У Рихтера прочитал, что JUMP зависит от процессора

AA>То есть вы хотите сказать, что jmp зависит от процессора, а push и ret — нет? Интересная точка зрения...

Наверное имелось ввиду что jump может иметь разный размер инструкции.

Здравствуйте, Тихомиров В.А., Вы писали:

ТВА>Статья:
ТВА>Перехват API-функций в Windows NT/2000/XP

Автор(ы): Тихомиров В.А.
Дата: 11.11.2002

Замечание по поводу метода 2: как выяснилось, компилятор Borland (возможно, не только он) может создавать несколько записей IMAGE_IMPORT_DESCRIPTOR, соответствующих одной и той же библиотеке. Поэтому, если перехватываемая функция упоминается не в первой записи, то следующий код:

 while(iid->Name)  //до тех пор пока поле структуры не содержит 0
  {
    if(strcmp((char*)(pimage + iid->Name), "USER32.dll") ==0 ) break;
    iid++;
  }

работать не будет. Пришлось заменить примерно следующим:

for (iid = (IMAGE_IMPORT_DESCRIPTOR*)(pimage + (ish +i)->VirtualAddress ); iid->Name; iid++)  //до тех пор пока поле структуры не содержит 0
    if(strcmp((char*)(pimage + iid->Name), "USER32.dll") == 0)
    {
        // Search address and intercept
        ....
    }

Здравствуйте, Тихомиров В.А., Вы писали:

ТВА>Статья:
ТВА>Перехват API-функций в Windows NT/2000/XP

Автор(ы): Тихомиров В.А.
Дата: 11.11.2002

ТВА>Авторы:
ТВА>Тихомиров В.А.

ТВА>Аннотация:
ТВА>С переходом на Windows использование системных ресурсов программистами в большом объеме стало осуществляться через функции API, и у многих «сиспрогов» стал возникать вопрос: «существуют ли в Windows технологии перехватов этих системных функций?» Особый интерес это вызывает применительно к высокозащищенным ОС, выполненным на ядре NT. Данная статья подробнейшим образом, с действующими примерами покажет практическую реализацию такой технологии (предполагается, что читатель знаком с принципами системного программирования в Windows и умеет применять в своей работе Visual C++).


Пытался использовать метод 1, приведенный в статье для перехвата функции MessageBoxA()
Скомпилировал файл method1.dll из кода, приведенного в статье для метода 1. Использовал весь код из статьи, ничего не менял
Затем написал простейшее консольное приложение:

// MyProg.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

#include <windows.h>

int _tmain(int argc, _TCHAR* argv[])
{
    LoadLibrary("method1.dll");

    MessageBox(NULL, "Something has been written here", "MessageBox", 0);

    return 0;
}

Запустил. Но, к сожалению, оно вылетает со словами:

Unhandled exception at 0x77d70510 in MyProg.exe: 0xC0000005: Access violation writing location 0x10000000.

Никто случайно не знает, почему так случилось и можно ли как-то исправить, чтобы работало?
На всякий случай, платформа — WindowsXP, среда разработки — VC2003
Заранее благодарен

Здравствуйте, Аноним, Вы писали:

[Skip]

А>Никто случайно не знает, почему так случилось и можно ли как-то исправить, чтобы работало?
А>На всякий случай, платформа — WindowsXP, среда разработки — VC2003
А>Заранее благодарен

Посмотрите на Detours

Здравствуйте, Аноним, Вы писали:

А>Пытался использовать метод 1, приведенный в статье для перехвата функции MessageBoxA()
А>Скомпилировал файл method1.dll из кода, приведенного в статье для метода 1. Использовал весь код из статьи, ничего не менял
А>Затем написал простейшее консольное приложение:
А>Запустил. Но, к сожалению, оно вылетает со словами:


В общем, разобрался я, в чем дело, может, пригодится кому...
Оказалось, проблема у меня была с выравниванием. То есть все работает, если написать так:

#pragma pack(push,1)
struct jmp_far
{
  BYTE instr_push;  //здесь будет код инструкции push
  DWORD arg;         //аргумент push
  BYTE  instr_ret;    //здесь будет код инструкции ret
};
#pragma pack(pop)

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