Olá a todos os leitores! Este
é o primeiro artigo que estou escrevendo para o ProjetoBMS,
pretendo falar sobre a memória compartilhada utilizada nas versões
95, 98 e ME do Windows. Este artigo não conterá nenhum
código fonte, pois veremos isso nos próximos artigos onde
falarei sobre como alocar memória nesta área, como desalocar e
como obter acesso à escrita na área do Kernel do windows (que
está alocado na memória compartilhada).
Este artigo é
essencial para aqueles que pretendem conhecer mais a fundo estas
antigas versões do sistema operacional Microsoft Windows, e para
que entendam alguns dos próximos artigos que irei escrever sobre
as falhas de segurança destas versões do Windows.
A memória compartilhada
É um espaço reservado pelo
Sistema Operacional, utilizado para armazenar códigos
executávels/legíveis por qualquer outra aplicação que esteja
sendo executada. Este espaço é compartilhado por todas as
aplicações, portanto se o conteúdo deste espaço for alterado,
todas as aplicações sofrerão alterações. Oespaço de
memória compartilhada vai do endereçamento 0x80000000
até 0xBFFFFFFF. Então tudo que estiver entre
este espaço pode-se considerar compartilhado entre todas as
aplicações.
O Windows utiliza este espaço
para carregar as DLLs compartilhadas, que são: user32.dll,
gdi32.dll e a kernel32.dll.
Isso mesmo, as DLLs mais importantes para o funcionamento do
Windows estão na área de memória compartilhada. No Windows NT
não existe mais isso, é criada uma cópia de cada uma dessas
DLLs no espaço de cada aplicativo. Observando os fatos, a
Microsoft não pensou de maneira errada em deixar essas DLLs na
área de memória compartilhada. Veja algumas vantagens:
- A aplicação deveria
carregar mais rápido, já que essas 3 DLLs já estavam
préviamente carregadas na memória;
- Sobraria mais espaço
virtual para as aplicações, já que essas DLLs não
são carregadas no espaço da aplicação;
Mas isso não ocorre como
deveria, pois a aplicação perde tempo de qualquer maneira ao
mapear as APIs que são exportadas por essas DLLs, e, digamos
que, é praticamente impossível uma aplicação realmente
necessitar deste espaço que não foi ocupado pelas DLLs.
Dúvidas
>
Ah, então quer dizer que para alterar o funcionamento do
Windows, basta alterar o conteúdo das APIs que estão neste
espaço de memória compartilhada, que todas as aplicações
sofrerão as alterações?
Correto, mas a Microsoft não
permitiria isso. É por este motivo que aplicações normais não
têm acesso à escrita na área onde estão essas DLLs
compartilhadas. Ao tentar alterar você receberia uma mensagem de
Violação de Acesso (famoso Access Violation).
Mas espere, não desanime! Do mesmo modo que o Windows pode
bloquear, porque nós não poderiamos desbloquear? É possível
obter acesso à escrita nesta área, mas não é o escopo deste
artigo. Vou ensinar a desbloquear, via programação, em um outro
artigo (creio que fica mais organizado).
>
Como saber se uma DLL ou um código está carregado na área de
memória compartilhada?
Para o caso da DLL, deve-se
verificar se o Handle dela é maior que 0x80000000, da seguinte
forma:
| Delphi: |
if GetModuleHandle( 'user32.dll' ) > $80000000 then
// A DLL user32.dll está na área
de memória compartilhada
|
Para o caso de algum ponteiro,
deve-se verificar se o local dele é maior que 0x80000000, da
seguinte forma:
| Delphi: |
if Integer( Ponteiro ) > $80000000 then
// Ponteiro está na área de
memória compartilhada
|
Finalizando
Acho que já falei o necessário
sobre a área de memória compartilhada do Windows 9x. Este é o
ensinamento básico para muito dos artigos sobre win9x que
virão.