Impedir o Início de Um Processo
Bru++
Sou novo programando em Win32, mas estou precisando fazer algumas
coisas para Windows agora... Não sei nem aonde buscar maiores
informações, mas eis minha necessidade:
1) Impedir a execução de um processo(meu programa precisa receber um
evento antes dele ser executado, que me permita decidir se vou ou não
permitir a execução do processo)
2) Receber um evento a cada vez que um processo abrir, remover ou
modificar um arquivo.
3) Fazer tudo isso de modo que não prejudique o performance
significativamente.
4) Desejavelmente preciso receber um evento a cada edição, adição e/ou
remoção de entrada no registro do sistema e a cada socket aberto ou
fechado.
Basicamente preciso fazer algo similar ao que alguns anti-vírus
fazem...
Alguém sabe me dar um caminho e me dizer por onde começar??
Abraços!!
Bruno M. Guedes
Emerson de Freitas Barcelos
De: Bru++ <thbm...@gmail.com>
Para: ccppbrasil <ccppb...@googlegroups.com>
Enviadas: Quarta-feira, 24 de Março de 2010 16:10:41
Assunto: [ccppbrasil] Impedir o Início de Um Processo
Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] Colabore com a Pesquisa de Preferência de Conteúdo
para Eventos do Grupo C & C++ Brasil:
http://www.surveymonkey.com/s/GBBGTXN
------~----~-------~---~---~---~---~----------------~------------~---------~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira: vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en
To unsubscribe from this group, send email to ccppbrasil+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Veja quais são os assuntos do momento no Yahoo! + Buscados: Top 10 - Celebridades - Música - Esportes
Pedro d'Aquino
Jardel Weyrich
Emerson de Freitas Barcelos
De: Jardel Weyrich <jwey...@gmail.com>
Para: ccppb...@googlegroups.com
Enviadas: Quarta-feira, 24 de Março de 2010 16:52:38
Assunto: Re: [ccppbrasil] Impedir o Início de Um Processo
Pedro d'Aquino
processos, creio. Nesse caso, pesquise sobre a biblioteca Detours, da
MS Research. Há alguns artigos sobre o assunto no CodeProject, também.
On Wednesday, March 24, 2010, Emerson de Freitas Barcelos
<emerson...@yahoo.com.br> wrote:
> Existe uma classe de aplicativos que nós "adoramos" que fazem sistematicamente essas coisas...Esse projeto não seria um novo worm, trojan, virus ou outra dessas coisinhas "amáveis" ? Seria ?
> Ah!... um software "Big Brother" também faz isso.
> Veja quais são os assuntos do momento no Yahoo! + Buscados: Top 10 <http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/> - Celebridades <http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/celebridades/> - Música <http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/m%C3%BAsica/> - Esportes <http://br.rd.yahoo.com/mail/taglines/mail/*http://br.maisbuscados.yahoo.com/esportes/>
Jardel Weyrich
Samuel Feitosa
este tópico foi criado pelo usuário "Bru++", porém, eu irei conversar
com vocês sobre este assunto.
Respondendo a pergunta do Emerson Barcelos, não estamos querendo
desenvolver nenhum tipo de vírus, worm, trojan, etc.
Desde já agradeço a todas as respostas.
Seria possível eu identificar a abertura de um executável através de
um mini-filter driver?
On 24 mar, 17:26, Jardel Weyrich <jweyr...@gmail.com> wrote:
> Ok, estava relembrando como as coisas funcionam no windows.
>
> Respondendo a questão 1: Utilizando a PSAPI e ToolHelp (ou o já citado WMI)
> é possível consultar os processos ativos, e várias outras informações que
> dizem respeito aos mesmos. Porém, está longe de ser um mecanismo de
> notificação, e muito menos seria possível bloquear a execução de um
> processo.
>
> O mecanismo de notificação sobre processos do windows
> (PsSetCreateProcessNotifyRoutine) é kernel-mode, e seria necessário criar um
> driver/service para usá-lo. Basicamente, você passa uma callback para a
> função, e a callback é invocada toda vez que um processo inicia, termina,
> etc. Mas continuamos sem poder de decisão sobre a execução do processo.
>
> Sem tempo para pesquisar, eu faria um hook na ZwCreateProcess.
>
> Porém, nos windows Vista & 7, acredito que seja possível fazer isso em
> user-mode utilizando a API do UAC. Apesar de considerar o UAC uma grande
> farsa :)
>
> 2010/3/24 Jardel Weyrich <jweyr...@gmail.com>
>
> > 1) Preciso pesquisar :)
>
> > 2) Para ser notificado sobre a alterações no filesystem, você pode usar
> > FindFirstChangeNotification ou ReadDirectoryChangesW.
> > Se você precisa controlar o acesso aos arquivos, o ideal é criar um
> > filesystem filter driver (ver link abaixo).
> > Outra alternativa seria utilizar hooks de API. Seja via DLL injection
> > (CreateRemoteThread, etc) ou outra técnica.
>
> > 3) Apesar de nunca ter feito profiling, acredito que as opcões que citei
> > não causam qualquer impacto significativo na performance.
>
> > 4) Para o registro, use RegNotifyChangeKeyValue. Para os sockets, eu
> > aconselharia usar o WFP (windows filter platform), mas acredito que haja API
> > user-mode para isso.
>
> > Links:
> > - filesystem filter -
> >http://www.microsoft.com/whdc/driver/filterdrv/default.mspx
>
> > hth
> > --
> > jardel
>
> > 2010/3/24 Bru++ <thbmat...@gmail.com>
> >> [&] C & C++ Brasil -http://www.ccppbrasil.org/
> >> Para sair dessa lista, envie um e-mail para
> >> ccppbrasil-...@googlegroups.com
> >> Para mais opções, visitehttp://groups.google.com/group/ccppbrasil
> >> --~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
> >> Emprego & carreira: vaga...@ccppbrasil.org
DriverEntry
Estou vendo que determinação é o seu ponto forte. Apesar de ser novo
em Win32 já saiu pegando logo as coisas mais fáceis de se fazer,
incluindo filtro de file system.
Bom, vamos lá respire fundo e nada de desânimo. As respostas seguem os
números das perguntas.
1) Para Windows Vista e posteriores, você pode desenvolver um driver
que receba notificações sobre a criação e destruição de processos. Eu
sei que isso também é possível desde o Windows NT 4.0 (quando o arco-
iris ainda era em preto e branco) utilizando a API
PsCreateProcessNotifyRoutine(), mas a partir do Windows Vista uma nova
versão desta mesma rotina, a PsCreateProcessNotifyRoutineEx(), traz o
maravilhoso recurso de interromper a criação do processo que está
prestes a ser iniciado. Veja os detalhas na estrutura
PS_CREATE_NOTIFY_INFO que vêm como parâmetro a cada novo evento.
http://msdn.microsoft.com/en-us/library/bb679945.aspx
http://msdn.microsoft.com/en-us/library/dd852103.aspx
Para Windows XP e anteriores, a coisa fica bem mais... digamos
desafiadora. Já implementei isso em outras empresas onde trabalhei e
posso dizer que você vai se divertir muito com isso (espero que
aproveite). Nestas versões não existe a opção de interromper a criação
do processo e você terá que fazer malabarismo com o Kernel-Mode e User-
Mode aproveitando de alguns recursos não documentados para fazer
injeção de código e dar o resultado satisfatório. Bom, quando eu fiz
isso a plataforma x64 não era prioridade. Muitos dos recursos que
utilizei não funcionariam a partir do Windows XP x64 e posteriores.
Sistemas x64 implemantam o Patch Guard, o que faz do hook de API
nativa um grande problema a ser resolvido. Não sei como isso está hoje
em dia.
http://www.microsoft.com/whdc/driver/kernel/64bitpatching.mspx
2) Um filtro de file system resolve isso fácil. O problema mesmo é
desenvolver o filtro de file system. Você pode dar uma olhada num
exemplo implementado em Minifilter que se assemelha à um antivirus,
assim como você queria.
http://msdn.microsoft.com/en-us/library/dd163282.aspx
3) Acredite, você só vai se preocupar com performance quando o
problema da estabilidade for resolvido. De qual estabilidade estou
falando? Você vai acabar descobrindo. :-)
4) Já que você vai ficar craque em Kernel, você poderá implementar um
filtro de registro utilizando uma API do Windows XP. Se Windows 2000
ainda significa algo para você, então terá que fazer o Hook de API
nativa.
http://msdn.microsoft.com/en-us/library/aa906577.aspx
http://msdn.microsoft.com/en-us/library/ee220655.aspx
Quanto a monitoria de sockets, você terá de fazer um Transport Driver
Interface Filter, ou filtro de TDI. Isso era o mais fácil a ser seito
pelo menos até o Windows XP. No Vista a coisa muda de figura e o TDI
terá seu suporte removido do Windows 7. Na verdade o driver ainda está
lá, só não sabemos até quando. Depois disso você terá que lidar com a
nova interface, mas esse blog abaixo faz uma introdução ao assunto
além de ser um excelente blog a respeito de rede no Windows.
http://blogs.msdn.com/wndp/archive/2006/02/24/538746.aspx
Bom, quanto ao caminho a ser seguido, se você é novo em Win32 imagino
que você nunca tenha brincado de fazer telas azuis. Não se preocupe,
fazer telas azuis é facil, difícil é evitá-las.
Para um quick start eu sempre recomendo este livro abaixo. Apesar de
não ser uma referência completa, ele dá passos pequenos para o leitor
não desistir antes do primeiro exemplo. Ele ainda é baseado em WDM,
que não é a última palavra em desenvolvimento de drivers, mas pelo
menos é de mais fácil compreensão.
Depois da parte fácil você poderá encarar o famoso livro da galinha
preta. Não é o que você está pensando, esse é apenas o apelido do
livro. Você não terá que repensar suas crenças para aprender a base do
desenvolvimento de drivers de File System. Mas de qualquer forma
haverá algum sacrifício. Esta é a única publicação respeitável sobre o
assunto e não caia nessa de "vou dar um tapa no exemplo e tudo bem"
que normalmente não funciona. Na verdade até funciona, mas demoooora.
Se bateu aquela preguicinha de ler o livro, você pode fazer como eu,
que apesar de ter lido este livro pelo menos três vezes, ainda fui
fazer o curso na OSR. Muito bom por sinal.
Aquele exemplo de Scanner que falei anteriormente é feito sobre em um
modelo chamado Minifilter. Ainda não existe livro pra ele, mas o curso
também está disponível na OSR. Vale lembrar que pra evitar as pessoas
de fazerem o curso e se darem conta de que jogaram seu dinheiro fora
por não entenderem nada, este curso pede o curso de File Systems (esse
logo acima) como requisito.
http://www.osr.com/filters.html
Com o resto acho que não vai ter muito jeito, você vai ter que enfiar
a cara no MSDN e aprender na raça.
Ah! Quase ia me esquecendo. Meu blog fala sobre desenvolvimento de
drivers. Separei alguns links úteis para quem quer começar.
Criando um driver do zero: http://www.driverentry.com.br/blog/2006/09/getting-started.html
Depurando um driver: http://www.driverentry.com.br/blog/2006/12/step-into-kernel-serial.html
O resto você encontra na busca do blog.
Espero ter ajudado.
Um abraço.
--
Fernando Roberto da Silva
DriverEntry Kernel Development
http://www.driverentry.com.br
Samuel Feitosa
obrigado pela ajuda!
Então é possível a partir de um mini filter driver eu detectar a
execução de um aplicativo?
Caso eu deseje bloqueá-lo, basta negar o acesso a chamada ao file
system?
On 24 mar, 23:13, DriverEntry <fernando.rsi...@gmail.com> wrote:
> Olá Bruno,
>
> Estou vendo que determinação é o seu ponto forte. Apesar de ser novo
> em Win32 já saiu pegando logo as coisas mais fáceis de se fazer,
> incluindo filtro de file system.
>
> Bom, vamos lá respire fundo e nada de desânimo. As respostas seguem os
> números das perguntas.
>
> 1) Para Windows Vista e posteriores, você pode desenvolver um driver
> que receba notificações sobre a criação e destruição de processos. Eu
> sei que isso também é possível desde o Windows NT 4.0 (quando o arco-
> iris ainda era em preto e branco) utilizando a API
> PsCreateProcessNotifyRoutine(), mas a partir do Windows Vista uma nova
> versão desta mesma rotina, a PsCreateProcessNotifyRoutineEx(), traz o
> maravilhoso recurso de interromper a criação do processo que está
> prestes a ser iniciado. Veja os detalhas na estrutura
> PS_CREATE_NOTIFY_INFO que vêm como parâmetro a cada novo evento.
>
>
> Quanto a monitoria de sockets, você terá de fazer um Transport Driver
> Interface Filter, ou filtro de TDI. Isso era o mais fácil a ser seito
> pelo menos até o Windows XP. No Vista a coisa muda de figura e o TDI
> terá seu suporte removido do Windows 7. Na verdade o driver ainda está
> lá, só não sabemos até quando. Depois disso você terá que lidar com a
> nova interface, mas esse blog abaixo faz uma introdução ao assunto
> além de ser um excelente blog a respeito de rede no Windows.
>
> http://blogs.msdn.com/wndp/archive/2006/02/24/538746.aspx
>
> Bom, quanto ao caminho a ser seguido, se você é novo em Win32 imagino
> que você nunca tenha brincado de fazer telas azuis. Não se preocupe,
> fazer telas azuis é facil, difícil é evitá-las.
>
> Para um quick start eu sempre recomendo este livro abaixo. Apesar de
> não ser uma referência completa, ele dá passos pequenos para o leitor
> não desistir antes do primeiro exemplo. Ele ainda é baseado em WDM,
> que não é a última palavra em desenvolvimento de drivers, mas pelo
> menos é de mais fácil compreensão.
>
> http://www.amazon.com/Windows-2000-Device-Driver-Book/dp/0130204315/r...
>
> Depois da parte fácil você poderá encarar o famoso livro da galinha
> preta. Não é o que você está pensando, esse é apenas o apelido do
> livro. Você não terá que repensar suas crenças para aprender a base do
> desenvolvimento de drivers de File System. Mas de qualquer forma
> haverá algum sacrifício. Esta é a única publicação respeitável sobre o
> assunto e não caia nessa de "vou dar um tapa no exemplo e tudo bem"
> que normalmente não funciona. Na verdade até funciona, mas demoooora.
>
> http://www.amazon.com/Windows-System-Internals-Classic-Reprints/dp/09...
>
> Se bateu aquela preguicinha de ler o livro, você pode fazer como eu,
> que apesar de ter lido este livro pelo menos três vezes, ainda fui
> fazer o curso na OSR. Muito bom por sinal.
>
> http://www.osr.com/fsd.html
>
> Aquele exemplo de Scanner que falei anteriormente é feito sobre em um
> modelo chamado Minifilter. Ainda não existe livro pra ele, mas o curso
> também está disponível na OSR. Vale lembrar que pra evitar as pessoas
> de fazerem o curso e se darem conta de que jogaram seu dinheiro fora
> por não entenderem nada, este curso pede o curso de File Systems (esse
> logo acima) como requisito.
>
> http://www.osr.com/filters.html
>
> Com o resto acho que não vai ter muito jeito, você vai ter que enfiar
> a cara no MSDN e aprender na raça.
>
> Ah! Quase ia me esquecendo. Meu blog fala sobre desenvolvimento de
> drivers. Separei alguns links úteis para quem quer começar.
>
> Criando um driver do zero:http://www.driverentry.com.br/blog/2006/09/getting-started.html
> Depurando um driver:http://www.driverentry.com.br/blog/2006/12/step-into-kernel-serial.html
>
> O resto você encontra na busca do blog.
>
> Espero ter ajudado.
> Um abraço.
> --
> Fernando Roberto da Silva
> DriverEntry Kernel Developmenthttp://www.driverentry.com.br
DriverEntry
A API PsCreateProcessNotifyRoutineEx() pode ser chamada por qualquer
módulo em System Space. Não necessáriamente ser um Minifilter, mas
como você também precisa desenvolver um filtro de file system, então
nada impede de se ter um único driver para ambos os serviços.
[],
Fernando.
On Mar 25, 2:00 pm, Samuel Feitosa <samuca...@gmail.com> wrote:
> Olá Fernando,
>
> obrigado pela ajuda!
>
> Então é possível a partir de um mini filter driver eu detectar a
> execução de um aplicativo?
> Caso eu deseje bloqueá-lo, basta negar o acesso a chamada ao file
> system?
>
> On 24 mar, 23:13, DriverEntry <fernando.rsi...@gmail.com> wrote:
>
> > Olá Bruno,
>
> > Estou vendo que determinação é o seu ponto forte. Apesar de ser novo
> > em Win32 já saiu pegando logo as coisas mais fáceis de se fazer,
> > incluindo filtro de file system.
>
> > Bom, vamos lá respire fundo e nada de desânimo. As respostas seguem os
> > números das perguntas.
>
> > 1) Para Windows Vista e posteriores, você pode desenvolver um driver
> > que receba notificações sobre a criação e destruição de processos. Eu
> > sei que isso também é possível desde o Windows NT 4.0 (quando o arco-
> > iris ainda era em preto e branco) utilizando a API
> > PsCreateProcessNotifyRoutine(), mas a partir do Windows Vista uma nova
> > versão desta mesma rotina, a PsCreateProcessNotifyRoutineEx(), traz o
> > maravilhoso recurso de interromper a criação do processo que está
> > prestes a ser iniciado. Veja os detalhas na estrutura
> > PS_CREATE_NOTIFY_INFO que vêm como parâmetro a cada novo evento.
>
> >http://msdn.microsoft.com/en-us/library/bb679945.aspxhttp://msdn.micr...
> >http://msdn.microsoft.com/en-us/library/aa906577.aspxhttp://msdn.micr...
Samuel Feitosa
(PsCreateProcessNotifyRoutineEx()) irá funcionar apenas para versões
acima do Windows Vista. Porém, eu preciso que funcione também para o
Windows XP.
Então, estou pesquisando uma alternativa para somente através do Mini
Filter detectar se está sendo iniciada a execução de um aplicativo.
Nesse momento, estou verificando através das flags de abertura do
arquivo, interceptando a chamada IRP_MJ_CREATE. (estou editando um
exemplo do WinDDK e submetendo os testes).
Pois, se através dessa chamada eu conseguir perceber se é uma execução
de programa, eu posso "falhar" a requisição.
Será que isto é possível?
DriverEntry
Dê uma olhada nos direitos de abertura a presença do bit FILE_EXECUTE,
isso vai sinalizar o Memory Manager para mapear esse arquivo seguindo
o alinhamento de execução na hora de criar a section do arquivo, que é
diferente de uma simples abertura de arquivo binário.
Mas existem os falsos positivos como por exemplo: Este bit de abertura
em execução também é setado por depuradores, disassemblers e sabe lá
Deus quem mais. Sem falar nos fulanos que abrem o arquivo com
GENERIC_ALL. Cuidado com isso. :-)
Não me lembro agora como esse bit vem para aplicações de 16 bits
(algumas instalações são feitas em 16 bits), e portando rodam no
contexto do NTVDM.exe.
[]s,
Fernando.
Bruno Moreira Guedes
Nós não estamos acostumados com tantos detalhes de um software presos
na versão do Windows. Só me diz uma coisa por curiosidade... Se tu
tivesse que fazer um software assim que rodasse no Windows XP ou todos
os superiores, tu encontrarias o modo "mais compatível possível" ou
procurarias fazer uma versão diferente para cada um??
Grato,
Bruno Moreira Guedes
> --
> Antes de enviar um e-mail para o grupo leia:
> http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
> --~--~---------~--~----~---------------------------------~----------~--~----~
> [&] Colabore com a Pesquisa de Preferência de Conteúdo
> para Eventos do Grupo C & C++ Brasil:
> http://www.surveymonkey.com/s/GBBGTXN
> ------~----~-------~---~---~---~---~----------------~------------~---------~
> [&] C & C++ Brasil - http://www.ccppbrasil.org/
> Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
> Para mais opções, visite http://groups.google.com/group/ccppbrasil
> --~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
> Emprego & carreira: vag...@ccppbrasil.org
> http://groups.google.com/group/dev-guys?hl=en
>
> To unsubscribe from this group, send email to ccppbrasil+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
>
DriverEntry
Depende do que esse seu driver se propôe a fazer. Se ele tiver que
rodar na maior quantidade de plataformas possíveis, então devemos
implementar para todas.
Outro detalhe é o seguinte: Cada nova versão de kernel traz rotinas
mais destinadas à certas necessidades. Essa mesmo sobre execução de
processos é um bom exemplo. Neste caso vale a pena ter dois drivers
distintos. Um para XP usando macetes para conseguir o que quer,
enquanto o outro usa uma rotina documentada e bem comportada (isso é
um grande atrativo nas rotinas de Kernel).
Na verdade dá pra fazer o mesmo driver rodar em ambos os sistemas, mas
se comportando diferente em cada um deles.
Utilizando a rotina MmGetSystemRoutineAddress() (disponível a partir
do Windows 2000) você pode fazer com que o driver carregue
dinamicamente o endereço de uma rotina sem ter que fazer um link
estático com sua lib, exatamente como a GetProcAddress() em user-mode.
Desta forma você trata as diferenças dos sistemas em uma parte
específica do seu driver enquanto aproveita a parte em comum entre
eles em um só driver.
http://msdn.microsoft.com/en-us/library/ms801995.aspx
[]s,
Fernando.
On Mar 25, 5:37 pm, Bruno Moreira Guedes <thbmat...@gmail.com> wrote:
> Olá DriverEntry!
>
> Nós não estamos acostumados com tantos detalhes de um software presos
> na versão do Windows. Só me diz uma coisa por curiosidade... Se tu
> tivesse que fazer um software assim que rodasse no Windows XP ou todos
> os superiores, tu encontrarias o modo "mais compatível possível" ou
> procurarias fazer uma versão diferente para cada um??
>
> Grato,
> Bruno Moreira Guedes
>
> ...
>
> read more »
Samuel Feitosa
desculpe insistir na questão. Mas o que vc me aconselha fazer para
desenvolver um app blocker?
Basicamente gostaria de impedir a execução de programas de acordo com
regras estabelecidas em banco de dados.
E preciso que rode em todas as versões do windows superiores ao
Windows XP inclusive.
Obrigado.
Samuel Feitosa
> ...
>
> mais »
DriverEntry
Eu aconcelharia ter um driver que no Windows XP ainda utilizasse o
método de interceptação de API nativa para monitorar a criação de
processos e assim impedi-los com base nas suas regras. Não temos
muitas alternativas em Windows XP. Você terá que dar uma estudada nos
passos que o sistema realiza para criar um processo novo. Embora esta
seja uma técnica não oficial e duramente criticada pelos gurus da
lista da OSR, foi o método que algumas conhecidas aplicações de
segurança de mercado encontraram para atingir seus objetivos. Apesar
de não documentada, essa interface é tão popular que existe até livro
sobre ela. Este livro abaixo é uma super mão na roda para fazer uso
destas interfaces não documentadas do Windows.
Página com tabela de indices de rotinas. Você vai acabar entendendo
pra quê serve.
http://www.metasploit.com/users/opcode/syscalls.html
Este livro fala a respeito da Native API Hooking
http://www.amazon.com/Undocumented-Windows-2000-Secrets-Programmers/dp/0201721872/ref=sr_1_2?ie=UTF8&s=books&qid=1270044821&sr=1-2
Fazer hook de API nativa é algo que parece fácil, mas não é.
http://www.nynaeve.net/?p=210
Você ainda terá diferenças de implementação deste mesmo método em
variantes do Windows XP, Windows 2003 Server e seus respectivos
service packs.
Né mole não...
Para Windows Vista e posteriores eu usaria o método suportado pela
nova API, que é documentada e conta com o apoio dos gurus da lista da
OSR.
Listas da OSR:
http://www.osronline.com/page.cfm?name=ListServer
Dê uma estudada sobre o formato PE, ordem de carga de DLLs e ponto de
entrada do processo.
Esse artigo do Matt Pietrek é ótimo:
http://msdn.microsoft.com/en-us/magazine/cc301805.aspx
Espero ter ajudado,
--
Fernando Roberto da Silva
DriverEntry Kernel Development
http://www.driverentry.com.br
> ...
>
> read more »
Samuel Feitosa
obrigado pela sua ajuda por enquanto.
Vou estudar as técnicas citadas.
Att.
Samuel Feitosa
On 31 mar, 11:36, DriverEntry <fernando.rsi...@gmail.com> wrote:
> Olá Samuel,
>
> Eu aconcelharia ter um driver que no Windows XP ainda utilizasse o
> método de interceptação de API nativa para monitorar a criação de
> processos e assim impedi-los com base nas suas regras. Não temos
> muitas alternativas em Windows XP. Você terá que dar uma estudada nos
> passos que o sistema realiza para criar um processo novo. Embora esta
> seja uma técnica não oficial e duramente criticada pelos gurus da
> lista da OSR, foi o método que algumas conhecidas aplicações de
> segurança de mercado encontraram para atingir seus objetivos. Apesar
> de não documentada, essa interface é tão popular que existe até livro
> sobre ela. Este livro abaixo é uma super mão na roda para fazer uso
> destas interfaces não documentadas do Windows.
>
> Livro:http://www.amazon.com/Windows-2000-Native-API-Reference/dp/1578701996...
>
> Página com tabela de indices de rotinas. Você vai acabar entendendo
> pra quê serve.http://www.metasploit.com/users/opcode/syscalls.html
>
> Este livro fala a respeito da Native API Hookinghttp://www.amazon.com/Undocumented-Windows-2000-Secrets-Programmers/d...
>
> Fazer hook de API nativa é algo que parece fácil, mas não é.http://www.nynaeve.net/?p=210
>
> Você ainda terá diferenças de implementação deste mesmo método em
> variantes do Windows XP, Windows 2003 Server e seus respectivos
> service packs.
> Né mole não...
>
> Para Windows Vista e posteriores eu usaria o método suportado pela
> nova API, que é documentada e conta com o apoio dos gurus da lista da
> OSR.
> Listas da OSR:http://www.osronline.com/page.cfm?name=ListServer
>
> Dê uma estudada sobre o formato PE, ordem de carga de DLLs e ponto de
> entrada do processo.
> Esse artigo do Matt Pietrek é ótimo:http://msdn.microsoft.com/en-us/magazine/cc301805.aspx
>
> Espero ter ajudado,
> --
> Fernando Roberto da Silva
> DriverEntry Kernel Developmenthttp://www.driverentry.com.br
> ...
>
> mais »
Rodrigo Canellas
No código abaixo:
1 #include <iostream>
2 #include <string>
3 using namespace std;
4 // ------ some types to make code easier to read
5 typedef unsigned int event_id;
6 typedef unsigned int state_id;
7 // ------ transition template class
8 template <state_id tv_begin,
9 event_id tv_event>
10 class transition;
11 // ------ a transition class
12 template <>
13 class transition<0, 100> ;
14 // ------ transition handler template class
15 template <typename t_transition>
16 class handler;
17 // ------ a transition handler class
18 template<>
19 class handler <transition<0, 100> > {
20 public:
21
22 state_id operator ( ) ( const string & p_data ) {
23 cout << "0-100: p_data = '" << p_data << "'" << endl;
24 return 1;
25 }
26 };
27 int main ( ) {
28 // ------ this works fine
29 handler<transition<0, 100> > ha;
30 ha ( "hi" ) ;
31 // ------ this also works fine
32 const state_id l_s1 ( 0 ) ;
33 const event_id l_e1 ( 100 ) ;
34 handler<transition<l_s1, l_e1> > hc;
35 hc ( "how are you?" ) ;
36 // ------ WHY doesn't this work?
37 // 'g++ -Wall -g file.cpp -o file' reports:
38 // file.cpp: In function ‘int main()’:
39 // file.cpp:62: error: ‘l_s3’ cannot appear in a constant-expression
40 // file.cpp:62: error: ‘l_e3’ cannot appear in a constant-expression
41 // file.cpp:62: error: template argument 1 is invalid
42 // file.cpp:62: error: template argument 2 is invalid
43 // file.cpp:62: error: template argument 1 is invalid
44 // file.cpp:62: error: invalid type in declaration before ‘;’ token
45 // file.cpp:63: error: ‘hd’ cannot be used as a function
46 state_id l_s2 ( 0 ) ;
47 event_id l_e2 ( 100 ) ;
48 const state_id l_s3 ( l_s2 ) ;
49 const event_id l_e3 ( l_e2 ) ;
50 handler<transition<l_s3, l_e3> > hd;
51 hd ( "bye" ) ;
52 return 0;
53 }
Alguém sabe explicar porque o código entre as linhas 32 a 35 funciona,
e porque o 'g++' reporta o erro mostrado nas linhas 39 a 45 para o
código entre as linhas 46 e 51?
Obrigado!!!
--
Rodrigo Canellas
-----------
Programador C++ (http://code.google.com/p/tenacitas/)
Fotógrafo amador (http://photo.net/photos/RodrigoCanellas)
Murilo Adriano Vasconcelos
47 event_id l_e2 ( 100 ) ;
47 const event_id l_e2 ( 100 ) ;
--
Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] Colabore com a Pesquisa de Preferência de Conteúdo
para Eventos do Grupo C & C++ Brasil:
http://www.surveymonkey.com/s/GBBGTXN
------~----~-------~---~---~---~---~----------------~------------~---------~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira: vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en
To unsubscribe, reply using "remove me" as the subject.
--
Murilo Adriano Vasconcelos
Ciência da Computação INF-UFG
Universidade Federal de Goiás
http://murilo.wordpress.com
Vinicius Jarina
Olá Rodrigo. Acredito que você tenha "atravessado" o tópico "Impedir o Início de Um Processo".
O mais coerente para não misturar os assuntos, já que se trata de um assunto não relacionado a este tópico, seria mandar para lista, como um novo tópico.
Imagine no futuro alguém que esteja pesquisando sobre o assunto do tópico e ler o seu assunto não relacionado, irá poder acabar não entendendo.
Vinicius Jarina
--
Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] Colabore com a Pesquisa de Preferência de Conteúdo
para Eventos do Grupo C & C++ Brasil:
http://www.surveymonkey.com/s/GBBGTXN
------~----~-------~---~---~---~---~----------------~------------~---------~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira: vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en
Rodrigo Canellas
A situação mais parecida com a real é:
state_id function ( state_id p_s, event_id p_e, const string p_data ) {
handler <transition<p_s, p_e> > l_handler;
return l_handler ( p_data ) ;
}
.
.
.
.
function ( 0, 100, "ola" );
// e tb
state_id l_s ( 0 ) ;
event_id l_e ( 100 ) ;
function ( l_s, l_e, "tchau" ) ;
E em qualquer da duas, o 'g++' acusa o mesmo erro na 1ª linha de
'function' : ' handler <transition<p_s, p_e> > l_handler;'
Obrigado!
Em 31 de março de 2010 16:35, Murilo Adriano Vasconcelos
<muri...@gmail.com> escreveu:
Adriano dos Santos Fernandes
> Ol�!
>
> No c�digo abaixo:
>
>
>
> 1 #include<iostream>
> 2 #include<string>
>
> 3 using namespace std;
>
>
> 4 // ------ some types to make code easier to read
> 5 typedef unsigned int event_id;
> 6 typedef unsigned int state_id;
>
> 7 // ------ transition template class
> 8 template<state_id tv_begin,
> 9 event_id tv_event>
> 10 class transition;
>
> 11 // ------ a transition class
> 12 template<>
> 13 class transition<0, 100> ;
>
> 14 // ------ transition handler template class
> 15 template<typename t_transition>
> 16 class handler;
>
> 17 // ------ a transition handler class
> 18 template<>
> 19 class handler<transition<0, 100> > {
> 20 public:
> 21
> 23 cout<< "0-100: p_data = '"<< p_data<< "'"<< endl;
> 24 return 1;
> 25 }
>
> 26 };
>
>
> 27 int main ( ) {
>
> 28 // ------ this works fine
> 29 handler<transition<0, 100> > ha;
> 30 ha ( "hi" ) ;
>
> 31 // ------ this also works fine
> 32 const state_id l_s1 ( 0 ) ;
> 33 const event_id l_e1 ( 100 ) ;
>
> 34 handler<transition<l_s1, l_e1> > hc;
> 35 hc ( "how are you?" ) ;
>
>
> 36 // ------ WHY doesn't this work?
> 37 // 'g++ -Wall -g file.cpp -o file' reports:
> 39 // file.cpp:62: error: �l_s3� cannot appear in a constant-expression
> 40 // file.cpp:62: error: �l_e3� cannot appear in a constant-expression
> 41 // file.cpp:62: error: template argument 1 is invalid
> 42 // file.cpp:62: error: template argument 2 is invalid
> 43 // file.cpp:62: error: template argument 1 is invalid
> 45 // file.cpp:63: error: �hd� cannot be used as a function
>
> 46 state_id l_s2 ( 0 ) ;
> 47 event_id l_e2 ( 100 ) ;
>
> 48 const state_id l_s3 ( l_s2 ) ;
> 49 const event_id l_e3 ( l_e2 ) ;
>
>
constantes. Isso � v�lido.
> 50 handler<transition<l_s3, l_e3> > hd;
>
Mas templates precisam de constantes com valor em tempo de compila��o.
Adriano
André Pfitzner
Porque se for bloquear pelo nome o usuário pode renomear e rodar.
Se for permitir só executáveis com checksums cadastrados o usuário pode
injetar uma dll para fazer o que ele quiser...
Enfim, para cada técnica de bloqueio de usuário existe uma contra técnica.
Então poderia ser economizado esse esforço de programação para criar um programa
que será obviamente burlável por usuários avançados e usar recursos do próprio
SO para limitar o que o usuário pode fazer.
Assim seria mais fácil simplesmente desativar as permissões de execução
de todos os executáveis e dlls, não permitir que o usuário altere essas permissões
e habilitar somente os executáveis e dlls autorizados, um simples trabalho administrativo.
Agora, essa técnica é burlável por usuários avançados?
Claro que sim, como qualquer outra! Ainda mais considerando que os
usuários terão acesso físico à maquina. Poderiam dar boot via USB com
outro SO, alterar o filesystem e invadir... enfim, sempre será possível.
Então qual a vantagem? Simples, economiza tempo.
Ao invés de criar um sistema de controle de acesso burlável, é melhor
usar outro sistema de controle de acesso (burlável também, como eu disse)
que já existe e já vem de graça junto com o SO.
Com o tempo economizado pode-se criar sistemas mais úteis do
que fazer mais um sistema de controle de acesso burlável.
Desculpe, mas considero desnecessário criar sistemas de controle de acesso
para uso em Sistemas Operacionais modernos que já oferecem essa funcionalidade.
--
André Pfitzner
--
Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] Colabore com a Pesquisa de Preferência de Conteúdo
para Eventos do Grupo C & C++ Brasil:
http://www.surveymonkey.com/s/GBBGTXN
------~----~-------~---~---~---~---~----------------~------------~---------~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira: vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en
DriverEntry
Trabalhei numa empresa que implementa esse recurso de bloquear
execução de aplicações.
Obviamente que o evento de rename e outras brechas devem der
monitoradas, tais como acesso pela rede de um compartilhamento local.
Uma facilidade deste controle é criar regras tais como:
Impedir a execução de aplicações cujos paths sejam C:\Program Files\*
\*.exe
ou
Apenas permitir execução de aplicações do C:\Windows\*.*
Grupos de regras podem ser bem eficientes.
Você não precisa cadastrar cada aplicação individualmente.
Concordo com você que o simples bloqueio de execução não é suficiente,
e que isso requer controles adicionais, mas este modelo proteção
funciona e ainda é empregada em muitos clientes com sistemas modernos.
Outra utilidade seria a de scanear aplicações antes de executá-las
procurando virus por exemplo. Caso algo seja encontrado, é possível
impedir sua execução.
Tudo depende do que a ferramenta se propõe a fazer.
De qualquer forma imagino que este assunto seja um excelente tema para
ser discutido num forum de segurança, e não de programação.
[]s,
Fernando.
> 2010/3/31 Samuel Feitosa <samuca...@gmail.com>
> ...
>
> read more »
Bruno Moreira Guedes
Humildemente discordo de tua opinião sobre a "burlabilidade" do
sistema. Ok, se monitorarmos o fato do usuário renomear o arquivo não
resolveremos o problema que tu apontastes: ele pode inicializar outro
SO e fazer a modificação.
Mas, ainda podemos armazenar hashes md5 ou outro tipo de assinatura
dos executáveis anteriormente a suas respectivas alterações, fazendo
com que renomear ou substituir arquivos fora do SO não seja uma
alternativa tão eficiente para burlar o software. Claro que para fazer
isso, ainda teremos que arrumar um modo de saber quando foram
efetuadas atualizações de programas, mas isso podemos criar um
mecanismo que deixe isso a encargo do administrador da rede.
E, para o caso do usuário descarregar o driver ou até removê-lo, os
relatórios de atividades da máquina dirão que o software está
desativado para o administrador do software. Já pensamos em inúmeros
casos, e claro, que se alguém pensar em mais algum, por favor nos
avise rsrsrs.
Claro, não estou dizendo que isso deixaria o sistema "impossível de
burlar", pois na computação é impossível tornar algo impossível. Mas,
partindo deste estágio, o perigo subiria do nível de "usuários
avançados" para "usuários que programam e conhecem Windows a fundo",
reduzindo o potencial de encontrarmos pessoas com o conhecimento
necessário para isso de uns 10% para uns 0,1% (estatísticas baseadas
em chute, rsrsrs).
E obviamente, estas medidas preventivas terão que evoluir
constantemente, além de contarmos com medidas físicas(senha na BIOS e
boot apenas pelo disco, usuário sem privilégios de administrador no
sistema, computadores lacrados para evitar abertura, etc). Agradeço,
inclusive, quem tiver medidas preventivas para nos sugerir.
Att,
Bruno Moreira Guedes
André Pfitzner
Mas como você mesmo disse sempre é possível burlar, claro que
se os usuários da empresa que for usar o software não forem
programadores é mais improvável que algum usuário consigar burlar o sistema.
Mas o que acontece é que eu acho que os mecanismos do Windows
já são suficientes para isso, bastando apenas algumas configurações.
[]'s
--
André Pfitzner
zimbrao
de impedir.
Se a meta é impedir que usuários de uma rede interna de uma empresa
usem determinados programas, melhor seria divulgar quais os programas
permitidos e proibidos (ou classe de programas) e monitorar quais os
programas sendo executados e por quem. Depois, varrer os logs gerados
e chamar o usuário infrator para uma conversa "amigável"...
em um esquema desses é importante que o usuário não saiba que está
sendo monitorado, mas de qq forma, mesmo que ele saiba disso ele vai
demorar muito para descobrir como o monitoramento é feito já que se
ele tentar executar o programa proibido ele vai conseguir - mas não
vai saber se está ou não enganando o monitor.
[]s
On 12 abr, 16:47, André Pfitzner <andrepfitz...@gmail.com> wrote:
> Certo, quanto mais mecanismos tiver o sistema mais difícil será burlar.
> Mas como você mesmo disse sempre é possível burlar, claro que
> se os usuários da empresa que for usar o software não forem
> programadores é mais improvável que algum usuário consigar burlar o sistema.
>
> Mas o que acontece é que eu acho que os mecanismos do Windows
> já são suficientes para isso, bastando apenas algumas configurações.
>
> []'s
> --
> André Pfitzner
>
> 2010/4/12 Bruno Moreira Guedes <thbmat...@gmail.com>
> > Em 1 de abril de 2010 00:05, DriverEntry <fernando.rsi...@gmail.com>
> > >> > > > >> Pois, se através dessa chamada...
>
> mais »
Bruno Moreira Guedes
A política que tu demonstrastes, ao meu ver, é a ideal(tirando a parte
do usuário não saber que está sendo monitorado, o que talvez possa ser
interpretado juridicamente como violação da privacidade). Mas, apesar
de sempre darmos sugestões, quem dita as regras de como as coisas
devem ser é o mercado, e os nossos clientes preferem ser um pouco mais
radicais.
Mesmo assim obrigado pela sugestão. Se um dia mudarmos a opinião de
nossos clientes venderemos a eles algo com uma política mais amigável,
com toda certeza.
Zerdt
>
> Mas, ainda podemos armazenar hashes md5 ou outro tipo de assinatura
> dos executáveis anteriormente a suas respectivas alterações, fazendo
> com que renomear ou substituir arquivos fora do SO não seja uma
> alternativa tão eficiente para burlar o software. Claro que para fazer
> isso, ainda teremos que arrumar um modo de saber quando foram
> efetuadas atualizações de programas, mas isso podemos criar um
> mecanismo que deixe isso a encargo do administrador da rede.
>
>
Só tome cuidado com os ServicePacks e coisas do tipo. Quando fomos
implementar a regra de verificação de hashes em algumas aplicações que
bloqueamos num sistema similar que desenvolvemos, o mais trabalhoso
foi ter que montar VM's como Win2000 SP1, SP2, SP3, Win XP, XP SP1, XP
SP2 etc para pegar os aplicativos de cada versão que tinham sido
modificados pela MS. Além disso, fizemos uma pesquisa de versões dos
aplicativos feitas pela comunidade livre para tirar o hash tbm
(supondo aquela possibilidade do usuário substituir por algum
equivalente encontrado na net), o que rendeu pra cada aplicativo uma
lista de 5 a 10 hashes possíveis. Agora como vocês querem generalizar
todas versões de Windows, a lista pode crescer tanto que a busca nesta
lista teria que ser eficiente o suficiente. Outro porém seria como
efetuar a atualização desta lista de forma eficiente e sem comprometer
os procedimentos de segurança.
Só pra comentar sobre o ponto de vista do Sr. Pfitzner, normalmente
quando implementamos regras de segurança vale a máxima de "será que o
valor pago pela medida de segurança compensa? ". Por isso não
encontramos sistemas de segurança de última geração numa sorveteria.
Entretanto, qdo o ativo a ser protegido tem um valor agregado
representativo, normalmente vale a pena criar defesas complementares
em diversas frentes. Dessa forma, se o cliente quer uma atuação mais
"agressiva", a sugestão dada caberia como uma contramedida
complementar às técnicas de monitoramento e bloqueio, que funcionaria
no caso de uma eventual "falha" desta abordagem.
Att.,
Bruno Moreira Guedes
também, projetando um mecanismo para o administrador da rede possuir
meios de informar novas versões de determinados aplicativos. Temos
ciência de que só os aplicativos e demais executáveis do Windows nos
tomariam um baita tempo, ainda mais se considerarmos todas as versões
e service packs, e que a maioria dos softwares nos daria este
trabalho(afinal, todo software profissional está em constante
atualização). Mas posso dizer que a estrutura da nossa plataforma de
produtos torna isso muito fácil de contornar, e não causa nenhum
inconveniente para o administrador da rede, até porque a própria
atualização do executável não será permitida se o hash do executável
não for reconhecido como confiável por nosso controle.
Agradeço por mais este levantamento de potencial ameaça, e peço
novamente para quem tiver outros apontamentos sugerir, pois assim
consigo tornar o produto mais eficiente, além de favorecer a discussão
como referência mais confiável para pesquisas posteriores.
Abraços,
Bruno Moreira Guedes
Mesmo assim, agradeço por ter apontado mais um possível problema.