[VORON]

{Устанавливаем отладочные привилегии для своего(этого) процесса САР, т.к. без данных
привилегий код внедрения работать не будет.
я не смогу это прокоментировать так как нихрена это не понимаю ну смысл понятен там и так.
код самодостаточен и вродебы переносим копипастом.
пусть работает главное не трогать руками}
szPrivilege:='SeDebugPrivilege';
fEnable:=true;//вкл или выкл отладочные привы, это если в функцию собрать этот код удобно

OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES, hToken);
LookupPrivilegeValue(nil, szPrivilege, luid);
NewState.PrivilegeCount := 1;
NewState.Privileges[0].Luid := luid;

if (fEnable) then
  begin
    NewState.Privileges[0].Attributes := SE_PRIVILEGE_ENABLED
  end
  else
  begin
    NewState.Privileges[0].Attributes := 0;
  end;

AdjustTokenPrivileges(hToken, False, NewState, SizeOf(NewState), nil, ReturnLength);
CloseHandle(hToken);

// Открываем процесс жертвы. чтобы это не значило... но знайте что это не то что вы знаете или подумали..
{цель получить хэндл на процесс с помощью которого можно манипулировать процессом}
hProc := OpenProcess(PROCESS_ALL_ACCESS, false, ProcPID);

{сохраним в глобальную переменную этот хэндл, потом он пригодится чтобы создать локальную копию Хэндла
для чтения из пайпа}
g_DllHandle:=hProc;

memo1.Lines.Add('открываем процесс получаем его ХЭНДЛ=' + inttostr(cardinal(hProc)));

{Выделяем память внутри чужого процесса, в которую запишем какие-либо данные.
в нашем случае мы запишем туда строку- путь к длл. которую потом будем использовать
в качестве аргумента для запуска LoadLibraryA(путь к длл) }
pMyMemAdr := VirtualAllocEx(hProc, nil, Length(DllNamePAnsiChar), MEM_COMMIT or MEM_RESERVE,PAGE_EXECUTE_READWRITE);
memo1.Lines.Add('выделяем память в чужом процессе, получаем pointer=' + inttostr(cardinal(pMyMemAdr)));

//Пишем данные в выделенную память
WriteProcessMemory(hProc,  pMyMemAdr, DllNamePAnsiChar, Length(DllNamePAnsiChar), BytesWriten);
memo1.Lines.Add('пишем данные в выделенную память, записано байт=' + inttostr(cardinal(BytesWriten)));
{когда нам эта память не нужна то надо ее освободить! а мы этого тут не делаем!
протекли. если мы так бездумно будем выделять память и писать туда чтото каждый раз
то ничем хорошим это не закончится. вопщем за памятью следить надо. чтото создали-
если лишнее то освободить.}

{ищем адрес функции LoadLybraryA в памяти текущего (этого, нашего) процесса.
логика такая, КЕРНЕЛ32.ДЛЛ загружается ко всем вапще процессам и к чужому и к нашему(этому)
и располагает свои функции по одним и темже адресам, поэтому узнав адрес функции в нашем приложении
он будет таким же как и в чужом приложении. LoadLibraryA и LoadLibraryW отличаются кодировкой
Ansi и Юникод для аргумента. в какойто статье прочел что версии функций с индексом А на конце возвращают
адрес ,а с индексом W возвращают хендл}
{про память и адреса скажу так.. загружаясь процесс погружается в виртуальный мир адресного пространства,
который любезно предоставляет ему система. большой мир адресов 4х байтный (32 бит) . и там и живет какбудто он один
во всем мире. но этот мир памяти процесса виртуален. т.е. например 2 процесса могут по одному адресу внутри себя
иметь совершенно разные данные. потому что их виртальные адресные пространства не пересекаются никак. у каждого
процесса свой персональный виртуальный адресный мир-адресное пространство. длл туда подселяется располагает
свои функции внутри этого виртуального мира. и по какойто причине КЕРНЕЛ32.ДЛЛ всегда располагает свои
функции по одним и темже виртуальным адресам внутри виртуального адресного пространства приложения.
взаимодействие приложухи с внешним миром (за пределами виртуального адресного пространства) происходит через
апи. мы просим систему чегото сделать за пределами нашего виртуального мира с помощью апи.}
pLoadLibAdr := GetProcAddress(GetModuleHandle('KERNEL32.DLL'), PAnsiChar('LoadLibraryA'));
memo1.Lines.Add('ищем адрес функции LoadLybraryA, pointer=' + inttostr(cardinal(pLoadLibAdr)));

// Запускаем удаленный поток
{CreateRemoteThread может завершиться успешно даже если начальный адрес старта- белеберда
тем не менее это наверняка приведет к краху чужого приложения,
запускать удаленный поток нужно с какогото работоспособного кода (его адреса) который может выполниться.
часто таким началом старта является начало какойто функции, процедуры, подпрограммы. но это может быть и иначе.
мы можем и сами в какуюто область памяти что угодно понаписать байты, и запустить эти байты на выполнение начиная например
с 5-го байта от начала области памяти.. ну это к примеру. нам удобно указывать в качестве начала выполнения кода(потока)
адрес какойто функции.
вот функция LoadLibraryA которую предоставила (загрузила в адресное пространство процесса) дллка КЕРНЕЛ32.ДЛЛ
это подходящее место для старта потока в чужом процессе. аргумент для этой функции в виде строки (путь к длл)
мы уже записали в выделенную память в виртуальное адресное пространство чужого процесса. осталось запустить поток.
эта апи CreateRemoteThread ,зная о поводках пользователей в том что они любят стартовать с начала какойто функции,
любезно предоставляет нам сервис чтобы еще и аргумент подсунуть для этой стартовой функции. без такой фишечки
поток мы бы стартонули с начала какойто функции но как туда аргумент подсунуть была бы проблема.
однако если мы захотим стартонуть функцию которая требует например 2 аргумента для своей работы. вот так вот нельзя.
прототип стартовой функции потока должен быть таким чтоб тока 1 аргумент был и этот аргумент есть указатель на чтото.
хотя он может быть весьма длинным аргументом. строкой. мне тут самому не ясно вот мы указатель на область памяти
указываем которую нужно воспринимать как аргумент для стартовой функции, а где окончание области памяти этой, размер?
видимо используется ноль терминатор #0 для окончания.}
hRemoteThread  := CreateRemoteThread(hProc, nil, 0, pLoadLibAdr, pMyMemAdr, 0, pRemoteThread);
memo1.Lines.Add('запуск удаленного потока, Хэндл=' + inttostr(cardinal(hRemoteThread)) + ' Pointer=' + inttostr(cardinal(pRemoteThread)));

{можно конечно подождать завершения инъекции.. но тогда код отправки сообщений из главной функции длл
отправит данные а тут они не обработаются.. потомучто мы ждем.. получатся взаимождущие петли происходящие.
и поэтому я код оставлю но закоменчу.
типа вот так можно ожидать когда удаленный поток завершит свою работу и можно сразу получить какойто
результат его работы, в виде кода возврата. который сюда както вернет отработавший удаленный поток.}
// Ждем пока удаленный поток отработает...
//WaitForSingleObject(hRemoteThread, INFINITE);
//получаем код возврата удаленного потока. который по задумке должен содержать адрес загрузки длл
//RemoteThreadResult := 0;
//GetExitCodeThread(hRemoteThread, &RemoteThreadResult);
//memo1.Lines.Add('код возврата =' + inttostr(cardinal(RemoteThreadResult)));}

Closehandle(hRemoteThread);

//освобождаем хэндл открытого процесса
//Closehandle(hProc);//подержим хэндл открытым он нам нужен чтобы дубликат хэндла для пайпа сделать. закроем при выходе.
end;