Чёрт ребяяяяяТ!!! ВЫ ЧЁ ВИРУС ПИШИТЕ!? Ахтунг! Вопрос был как защитить прогу от выруба, а это можно использовать в широком спектре программ, а ответы вроде маскировки это точно блин под вирусы. У нас был один чувак (оффтоп: отомстил за брата), Автор, твой тёзка кстати, задал серию таких же вопросов а потом выложил "крутую прогу" гы лол повезло виря прибил сразу
на самом деле всё гладко, это со стороны вб кажеться что извращаемся... Например на си native api, перехват и внедрение, ассемблерские вставки, вполне привычные вещи...
FUNCTION EnumWindowsProc(BYVAL hwnd AS LONG, BYVAL lParam AS LONG) AS LONG
LOCAL sSave AS STRING, Ret AS LONG, itthread AS LONG,itpid AS LONG
FUNCTION = 0
Ret = GetWindowTextLength(hwnd)
sSave = SPACE$(Ret)
GetWindowText hwnd, BYVAL STRPTR(sSave), ret+1
IF TRIM$(UCASE$(ssave))=TRIM$(UCASE$($winname)) THEN
itthread = GetWindowThreadProcessId(BYVAL hwnd, itpid)
IF itpid=proctoopen THEN
thisprog=%true
END IF
END IF
FUNCTION = 1
END FUNCTION
FUNCTION SetHookProc(Op AS LONG) AS LONG
STATIC hProc AS LONG, tProc AS STRING
LOCAL hLib AS LONG
IF hProc = 0 THEN
hLib = GetModuleHandle("kernel32.dll"
hProc = GetProcAddress(hLib, "OpenProcess"
tProc = PEEK$(hProc, 7)
IF ISFALSE(VirtualProtect (BYVAL hProc, 7, BYVAL %PAGE_EXECUTE_READWRITE, BYREF hLib)) THEN _
MSGBOX "Error in VirtualProtect": hProc = 0: EXIT FUNCTION
' Under 9x VirtualProtect doesn't work in the shared virtual address space (from 0x80000000 through 0xBFFFFFFF).
' For example, for system dlls.
END IF
IF Op = 1 THEN POKE$ hProc, CHR$(&HB8) + MKL$(CODEPTR(MyOpenProcess)) + CHR$(&HFF, &HE0)
IF Op = 2 THEN POKE$ hProc, tProc
FlushInstructionCache GetCurrentProcess, BYVAL hProc, BYVAL 7
END FUNCTION
FUNCTION MyOpenProcess (BYVAL dwDesiredAccessas AS LONG, BYVAL bInheritHandle AS LONG, BYVAL dwProcId AS LONG) AS LONG
proctoopen = dwprocid
LOCAL CurrentProcess AS LONG
CurrentProcess=getcurrentprocessid
EnumWindows CODEPTR(enumwindowsproc),0
IF ISTRUE(thisprog) AND ISTRUE(currentprocess<>dwProcId) THEN
thisprog=%false
FUNCTION = 0
EXIT IF
ELSE
sethookproc 2
thisprog=%false
FUNCTION = OpenProcess dwDesiredAccessas,bInheritHandle,dwProcId
sethookproc 1
END IF
END FUNCTION
$UniqueName = $winname
GLOBAL hInstDLL AS LONG, MainDll AS LONG
FUNCTION LIBMAIN(BYVAL hInstance AS LONG, BYVAL fwdReason AS LONG, _
BYVAL lpvReserved AS LONG) EXPORT AS LONG
thisprog= %false
SELECT CASE fwdReason
CASE %DLL_PROCESS_ATTACH: hInstDLL = hInstance: LIBMAIN = 1: SetHookProc 1
CASE %DLL_PROCESS_DETACH: LIBMAIN = 1: SetHookProc 2
END SELECT
END FUNCTION
FUNCTION HookProc(BYVAL nCode AS LONG, BYVAL wParam AS LONG, BYVAL lParam AS LONG) EXPORT AS LONG
STATIC hHook AS LONG, hDlg AS LONG
hDlg = FindWindow("", $UniqueName)
IF hHook = 0 THEN IF hDlg THEN hHook = GetProp(hDlg, BYVAL 1)
IF hHook THEN FUNCTION = CallNextHookEx(BYVAL hHook, BYVAL nCode, BYVAL wParam, BYVAL lParam)
IF ISFALSE(MainDll) AND (ISFALSE(hDlg) OR ISFALSE(hHook)) THEN FreeLibrary hInstDll
END FUNCTION
FUNCTION SetHook ALIAS "SetHook" (hWnd AS LONG) EXPORT AS LONG
LOCAL hHook AS LONG
hHook = SetWindowsHookEx (%WH_CBT, CODEPTR(HookProc), BYVAL hInstDLL, BYVAL 0)
SetProp hWnd, BYVAL 1, BYVAL hHook
MainDll = 1
END FUNCTION
__________________________________________
EXE:
#COMPILE EXE
#DIM ALL
#REGISTER NONE
#INCLUDE "Win32Api.Inc"
$UniqueName = "Super-Puper"
 ECLARE FUNCTION SetHook LIB "HouseLabPROCESS.Dll" ALIAS "SetHook" (hWnd AS LONG) AS LONG
CALLBACK FUNCTION DlgProc
LOCAL hHook AS LONG
SELECT CASE CBMSG
CASE %WM_INITDIALOG: SetHook CBHNDL
CASE %WM_DESTROY : hHook = GetProp(CBHNDL, BYVAL 1): IF hHook THEN UnhookWindowsHookEx hHook
END SELECT
END FUNCTION
FUNCTION PBMAIN
LOCAL hDlg AS LONG
 IALOG NEW 0, $UniqueName, , , 100, 20, %WS_CAPTION OR %WS_SYSMENU, %WS_EX_TOPMOST TO hDlg
 IALOG SHOW MODAL hDlg CALL DlgProc
END FUNCTION
_________________________
Короче, если WindowText будет Super-Puper, то хендел этого процесса уже никто не получит (кроме драйвера),а без хендела какой TerminateProcess? ))
Конечно, надо ещё подрихтовать. Может кое - что сократить, но в принципе - работает.
Чтобы обойти этот хук, необязательно писать драйвер.
Я обходил таким способом:
Dll с хуком будет грузиться не во все процессы. Она может быть загружена только в GUI-процесс. Поэтому есть ещё и процессы, в которых OpenProcess девственно чистый, не перехваченый. Поэтому делаем такие вещи:
1. Находим такой процесс (например тот же csrss)
2. Лезем к нему в пространство и читаем первые n байт по адресу OpenProcess.
3. Копируем к себе эти байты на место похуканых dll-кой. И нет больше хука. Вызвать OpenProcess - никаких проблем
Есть ещё способ обойти такой хук. Его суть в том, что вместо похуканого kernel32, берем и маппируем к себе чистый kernel32 с диска, пересчитываем адреса функций, и получаем тот же kernel32, только загруженый по другому адресу. Вот и вызываем OpenProcess из нового кернела
А есть и ещё способ обхода хука: написать не-GUI прогу, и из неё открывать и завершать процессы. Dll с хуком такому процессу подгружаться не будет
И ещё способ завершить процесс: как известно, процесс system может открывать, читать и писать в пространство других процессов, при этом будучи неподвластным хукам на WriteProcessMemory/ReadProcessMemory. Как этим воспользоваться?
Открываем этот процесс и пишем в него код, который будет открывать процесс жертвы, и затирать адресное пространство жертвы (например нулями). Последствия: винда сама прихлопнет такой процесс, который кроме нулей ничего внутри себя не имеет.
Поэтому, чтобы мало-мальски надёжно сопротивляться закрытию процесса, надо знать очень много и написать значительно больше, чем один callback
Поэтому у вас огромное поле деятельности, дерзайте
Когда обойдёте эти способы завершения процесса, я вам ещё подкину несколько
Предложеный мною хук обойти, конечно!!!, можно.
И вообще, я где - то вычитал, что дробь, у которой в числителе количество способов защиты, а в знаменателе количество способов взлома, всегда стремится к 1
Я уверен, что эта защита будет "не по зубам" 99% юзеров, и это меня вполне устраивает. ))