запрет в приложенни remotethread, openprocess

RET
Сейчас посмотрю что там, ну думаю что останов на дитспетчер апк позволит обойти всяко защиту. Про ядро речи небыло.

 

...кстати ты прав.

 

хе-хе... я вот был уверен, что сейчас придет Клерк и скажет что-то в этом духе))))

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

 

Rel
Это RIT(поток сырого ввода) с высоким приоритетом.

 

Прально этож сервер всей подсистемы. Он кстати постоянно создает удаленные потоки во всех процессах, получает уведомления о их создании, закрытии и т.п. Если его отлаживать, то уж наверное с другой машины.

 

..или ядерным отладчиком

 

RET
Посмотрел, классический способ использовать проверку при нотификации модулей.
Первое что приходит на ум это подменить кодовый сегмент для диспетчера апк. Но селектор загружает в контекст ядро и изменить его нельзя. Но мы можем удалённо установить сех, а флажки, в частности TF передаются в диспетчер пользовательские, вот и решение.

 

RET
Потестите эту либу на следующем коде:

Код (Text):

1. SEH_FRAME struct
2. pLink       PVOID ?
3. pSeh        PVOID ?
4. pSafe       PVOID ?
5. rEbp        PVOID ?
6. SEH_FRAME ends
7. PSEH_FRAME typedef ptr SEH_FRAME
8.  
9. STACK_FRAME struct
10. Seh     SEH_FRAME <>
11. pRet        PVOID ?
12. Data        PVOID ?
13. STACK_FRAME ends
14. PSTACK_FRAME typedef ptr STACK_FRAME
15.  
16. REMOTE_SEH macro
17.     assume fs:nothing
18.     mov esp,dword ptr [esp + 2*4]   ; ExceptionList
19.     mov fs:[TEB.Tib.ExceptionList],NULL
20.     push STACK_FRAME.Seh.pSafe[esp]
21.     xor ebp,ebp
22.     ret sizeof(SEH_FRAME)
23. endm
24.  
25. ; +
26. ; ExceptionHandler:PREMOTE_SEH
27. ;
28. CreateHiddenThread proc ProcessHandle:HANDLE, ExceptionHandler:PVOID, StartupRoutine:PVOID, StartupParameter:PVOID
29. Local ThreadHandle:HANDLE, ClientId:CLIENT_ID
30. Local ThreadInformation:THREAD_BASIC_INFORMATION
31. Local Context:CONTEXT, Buffer:STACK_FRAME
32.     invoke RtlCreateUserThread, ProcessHandle, NULL, TRUE, 0, 0, 0, 0, 0, addr ThreadHandle, addr ClientId
33.     test eax,eax
34.     jnz Exit
35.     invoke ZwQueryInformationThread, ThreadHandle, ThreadBasicInformation, addr ThreadInformation, sizeof(THREAD_BASIC_INFORMATION), NULL
36.     test eax,eax
37.     mov Context.ContextFlags,CONTEXT_CONTROL
38.     jnz Kill
39.     invoke ZwGetContextThread, ThreadHandle, addr Context
40.     test eax,eax
41.     mov ecx,ExceptionHandler
42.     mov edx,StartupRoutine
43.     jnz Kill
44.     mov Buffer.Seh.pLink,-1
45.     sub Context.regEsp,sizeof(SEH_FRAME)
46.     mov Buffer.Seh.pSeh,ecx
47.     mov Buffer.Seh.pSafe,edx
48.     mov ecx,StartupParameter
49.     mov Buffer.Seh.rEbp,eax
50.     mov Buffer.pRet,eax
51.     mov Buffer.Data,ecx
52.     invoke ZwWriteVirtualMemory, ProcessHandle, ThreadInformation.TebBaseAddress, addr Context.regEsp, 4, eax   ; TEB.Tib.ExceptionList
53.     test eax,eax
54.     jnz Kill
55.     invoke ZwWriteVirtualMemory, ProcessHandle, Context.regEsp, addr Buffer, sizeof(STACK_FRAME), eax
56.     test eax,eax
57.     jnz Kill
58.     or Context.regEFlags,EFLAGS_TF
59.     invoke ZwSetContextThread, ThreadHandle, addr Context
60.     test eax,eax
61.     jnz Kill
62.     invoke ZwResumeThread, ThreadHandle, eax
63.     test eax,eax
64.     jz Exit
65. Kill:
66.     push eax
67.     invoke ZwTerminateThread, ThreadHandle, Eax
68. ;   invoke RtlFreeUserThreadStack, ProcessHandle, ThreadHandle  ; or TEB.FreeStackOnTermination
69.     pop eax
70. Exit:
71.     ret
72. CreateHiddenThread endp

Насчёт VEH - благо чтоб цепочку завершить хэши не нужны.

 

(не дописал возврат хэндла, но для теста пойдёт )

 

окей... спасибо за наводку... приду на работу - погуглю об этом))

 

Clerk я не понял - разве я где то сказал что это не так?

Clerk ведь не хотел оскорбить, правда? А то мало ли, как можно интерпретировать (люди ведь разные бывают).
Отвечаю на ваш вопрос:
1) Я - Воин Дзена
2) Моя фамилия слишком известна, чтобы ее называть
Это я так - шучу. А на самом деле, кем нужно быть чтобы знать? Вот вы видимо тем и являетесь, я прав?

В общем Clerk ничего дельного тоже не посоветовал. Я только понял одно: метод существует, но ни в одном программном обеспечении его не использует - видимо этот метод слишком крут, чтобы его использовать! ну-ну...

 

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

 

так и ещё... а чем вас не устраивает периодичный мониторинг собственных потоков (от CreateRemoteThread) и мониторинг|шифрование памяти?

 

Давайте обсудим один пример:
У нас есть программа, которая хранит все важные документы юзера в шифрованном zip файле (на пример в 7Zip).
Далее, юзер открывает в нашей программе из этого zip файла документы (word, text, images или еще чего). Так вот перед тем как открыть эти файлы, их конечно же нужно расшифровать и выделить для этих данных память. Теперь когда юзер наслаждается открытыми данными (к примеру там лежат пароли на почту\web\кредитная карта юзера) - эти данные так же погут поиметь и другие программы паралельно запущенные с нами. Например это мог бы сделать winamp или winrar (если бы у них была такая фича ))) ) - зачем другим приложениям нужно иметь возможность читать мою память? Да мало ли что там в моей памяти - это моё личное (думает юзер... )) )!

А проверить это оч. легко:
1) Откройте notepad и запишите туда строку которая нигде не повторяется: CHUPAKARABRA_KTULKHU_2010
2) Теперь открываем утиль кто может делать поиск по памяти (любую от Winhex - до Process Hacker)
3) Открываем наш процесс notepad.exe и ищем в памяти строку: CHUPAKARABRA_KTULKHU_2010

Нашли?
Так вот можно таким образом делать dump программы каждую секунду (указать просто пара регионов где теоритически могут находиться данные - пусть это будет 10-20 регионов User allocated memories). А после ручной поиск глазками по dump'ам и вот ОНА! Заветная информация! )) В общем извращаться можно как угодно главное прочитать нужный\предполагаемый участок памяти чужого процесса - а это дело не сложное. Здесь еще важен один момент юзер - так же может запустить нашу программу под user mode и вирус (короче плохая программа) - уже может находиться в системе (уже установлена из под admin mode).

Вот поэтому и стоит такая задача и именно под таким углом!

 

что-то изначально про чтение памяти речи не шло...

каким образом злоумышленник должен понять, что ему искать?

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

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

 

Хорошо, пусть это будет writeprocessmemory, дело в то... ))

Мы сейчас обсуждаем логику\возможности чтобы понять поведение злоумышленника?
Какая разница как он поймет!?
Не менее глупый ответ: Вычислит.

Нуу может быть и глупый, ну может быть и шифровщик (а такие разве существуют?) - но все таки сделал бы!

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

Жаль!
Но на самом деле это и пытаюсь сказать что от этого нельзя защититься! Но мало ли... может у кого то есть идеи - и на самом деле можно ))


p.s. Блин истина, 100 пудов, где то рядом.

 

я привел пример, как дешифровать данные, не расшифровывая их в виртуальной памяти...

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

 

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

 

Идеология виндовс... блин....
Меж процессорная защита памяти, я считаю, должна быть на уровне винды! Видимо пиндосы не правильно понимают: "Компьютер должен быть персональным" или как там они бакланят... Вот вам сразу же и пример: У меня на работе стоит комп, это не мой комп, его купила моя организация - соответсвенно он принадлежит им, я же выхожу в интернет, использую свои личные данные и храню это все на писюке, который принадлежит не мне - мне так удобно, я же не параноик ))! В любое время организация может забрать этот комп у меня и я ничего не смогу сделать - все мои данные окажутся в чужих руках. Это был пример того что комп которому вы доверяете может быть не персональным. К чему я все это завел?!?! Думаю этот слоган нужно было бы сменить на: "Процесс должен быть персональным!!!"
Лааадно все это мысли вслух...

Вот на пример от inject dll можно защититься имея Ring3. И в этом случае мне пофиг откуда ко мне инжектяться (Admin или Ring0) - просто есть один минус - WriteProcessMemory\ReadProcessMemory. Не хочу даже думать как злоумышленник, используя эти ф-ии против моего процесса, сможет ими воспользоваться. Просто эта дырка существует, а ее хотелось бы прикрыть

 

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

По мне так не фига не дырка, а особенность. Да есть доступ к процессам на одном уровне, не смертельно имхо. Конечно если бы была защита или хотя-бы можно было правами выставлять, то было бы лучше, но вот "бы" мешается