Espaço de endereço
Os processos têm uma quantidade limitada de espaço de endereço. Durante a execução de 32 bits, um processo tem aproximadamente 2 GB ( <0x7fffffff) of process address space to play with, and 2 GB (> 0x8000000) de coisas no modo kernel. Todas as alocações de memória, mapeamentos de arquivo, DLLs e outras coisas que você carrega ocorrem na janela de 2 GB do aplicativo.
Alteração de base
Uma DLL especifica onde deseja ser carregado. Se você tentar carregar uma DLL cujo endereço base já está em uso, ocorrerá uma falha na carga ou ela DLL terá de ser reutilizada.
Como funciona
Você tem dois DLLs ( x.DLL and y.DLL ). Ambos foram compilados no Visual Studio .NET . No Visual Studio, o padrão que o "" preferencial endereço base (local da memória para o qual é carregado) é 0x10000000.
- Executado MyTestApp.exe .
- LoadLibrary ( x.DLL );
- LoadLibrary ( y.DLL );
O
x.DLL é carregado em 0x10000000;
y.DLL tenta carregar até 0x10000000, mas não é possível usá-lo porque
x.DLL ele já está usando esse espaço de endereço. Portanto,
y.DLL o "foi refeito com base." O sistema operacional escolhe um novo local para carregar o
DLL . Parte do processo de carregamento requer que o sistema operacional aplique "correções", de forma que sejam executadas corretamente em um local que
y.DLL não seja o 0x10000000.
A
DLL é otimizada para carregar até seu endereço base de ""
preferencial. A aplicação de
correçõesde "" tem alguma sobrecarga para ela. A
DLLs carga mais rápida se você configurar um endereço base de "" preferencial. Ele não deve colidir com um "" endereço base preferencial de outro
DLL processo é carregado. Em outras palavras, MACC injeta-se no processo e se alguma outra pessoa já estiver injetando nela, o processo falha. Para evitar que essa situação ocorra, o
DLL é baseado em base (injetada em outro processo).
Nota: A
DLL MACC alteração da troca de base não significa que ela não será injetada. A injeção é necessária para
SAU/MP/Execution que o controle obtenha os argumentos da linha de comando quando um interpretador de script for iniciado. Ele também é necessário durante a execução no modo interativo.
Se desejar ignorar explicitamente a injeção em um determinado processo, você poderá adicionar uma
attr -w regra ou remover esse interpretador de script da lista de
scripts .
Com a alteração da base definida, a alteração da
DisableDeviceGuardCompat configuração pode parecer uma solução alternativa. Não é. Tudo o que estamos fazendo é a rebase de outro
DLL (interceptando o mais profundo ou mais alto na pilha) –
kernel32.DLL termina a
LdrLoadDLL chamada
NTDLL.DLL ).
Se o
DeviceGuardCompat estiver desativado no host e o
DeviceGuard estiver ativado no seu ponto de extremidade, o sistema operacional não permitirá injeção. Ele bloqueia a execução do binário.
O
DeviceGuard é um recurso do sistema operacional (hardware e software) que restringe os dispositivos de execução de aplicativos não autorizados. Ele permite que aplicativos autorizados sejam executados usando um recurso chamado
integridade de código configurável.
"DeviceGuardCompat"
não tem nada a ver com "Microsoft DeviceGuard".
Nosso mecanismo de injeção detecta quando um processo está carregando uma biblioteca (DLL). Essa detecção é obtida sabendo-se o endereço virtual relativo (RVA) da função LoadLibrary. Quando o DisableDeviceGuardCompat está ativado, o RVA que está sendo procurado é
LdrLoadDLL , mas no
NTDLL.DLL . Por outro lado, com o
DisableDeviceGuardCompat desativado (por padrão), procuramos
LoadLibraryW no
Kernel32.DLL . Depois de termos esse endereço, permitimos que o processo injetado se comunique com nosso Driver, quando determinadas funções são chamadas.
O DisableDeviceGuardCompat não desativa nem ignora o
scinject.DLL para ser injetado. Ele altera a função que foi interceptada. Não há riscos associados à alteração da injeção
DLL , já que ainda estamos protegendo o sistema.
