Spazio indirizzo
I processi hanno una quantità limitata di spazio indirizzo. Quando si esegue 32 bit, un processo ha circa 2 GB ( <0x7fffffff) of process address space to play with, and 2 GB (> 0x8000000) di kernel modalità. Tutte le allocazioni di memoria, le mappature DLLs dei file e altre cose che si caricano si verificano nella finestra applicazioni 2-GB.
Ribasamento
Una DLL specifica dove desidera essere caricato. Se si tenta di caricare una DLL il cui indirizzo di base è già in uso, il carico non riesce o DLL deve essere ribasato.
Funzionamento
Si dispone di due DLLs ( x.DLL e y.DLL ). Entrambi sono stati compilati in Visual Studio .NET . In Visual Studio, il valore predefinito "indirizzo di base" preferito (la posizione di memoria a cui è stato caricato) è 0x10000000.
- Esegui MyTestApp.exe .
- LoadLibrary ( x.DLL );
- LoadLibrary ( y.DLL );
Il viene caricato in 0x10000000;
y.DLL tenta di eseguire il caricamento in 0x10000000, ma non è possibile perché
x.DLL lo spazio degli
x.DLL indirizzi è già in uso. Quindi,
y.DLL è "ribasato." Il sistema operativo sceglie un nuovo percorso per caricare il
DLL . Parte del processo di caricamento richiede che il sistema operativo applichi "correzioni" in modo che
y.DLL venga eseguito correttamente in una posizione diversa da 0x10000000.
DLL A è ottimizzato per il caricamento al suo "indirizzo di base"
preferito. L'applicazione di "
correzioni" ha un sovraccarico. Il
DLLs carico è più veloce se si configura un "indirizzo di base" preferito. Non deve collidere con un "indirizzo di base" preferito di un altro
DLL carico del processo. In altre parole, MACC inietta nel processo e se qualcos'altro sta già iniettando in esso, il processo si blocca. Per evitare che si verifichi questa situazione, il
DLL viene ribasato (iniettato in un altro processo).
Nota: La modifica del
DLL MACC ribasamento da non significa che non viene iniettato. L'iniezione è necessaria affinché
SAU/MP/Execution il controllo ottenga gli argomenti della riga di comando quando viene avviato un script interprete. È necessario anche quando si esegue in modalità interattiva.
Se si desidera ignorare in modo esplicito l'inserimento in un determinato processo, è possibile aggiungere una
attr -w regola o rimuoverla dall'elenco
script di script interprete.
Con la riassegnazione definita, la modifica della
DisableDeviceGuardCompat configurazione potrebbe sembrare una soluzione alternativa. Non lo è. Tutto ciò che stiamo facendo è ribasare un altro
DLL (agganciando il
LdrLoadDLL più in profondità o più in alto nel Stack –
kernel32.DLL termina la chiamata
NTDLL.DLL ).
Se
DeviceGuardCompat è disattivato nel host e
DeviceGuard è attivato sull'endpoint, il sistema operativo non consente l'iniezione. Blocca l'esecuzione del file binario.
DeviceGuard è una funzionalità del sistema operativo (hardware e software) che impedisce ai dispositivi di eseguire app non autorizzate. Consente alle app autorizzate di essere eseguite utilizzando una funzionalità denominata
integrità del codice configurabile.
"DeviceGuardCompat"
non ha nulla a che fare con "Microsoft DeviceGuard".
Il meccanismo di iniezione rileva quando un processo sta caricando una libreria (DLL). Questo rilevamento viene ottenuto conoscendo l'indirizzo virtuale relativo (RVA) della funzione LoadLibrary. Quando DisableDeviceGuardCompat è attivato, l'RVA cercato è
LdrLoadDLL ma in
NTDLL.DLL . Viceversa, con
DisableDeviceGuardCompat disattivato (per impostazione predefinita), si cerca
LoadLibraryW in
Kernel32.DLL . Dopo aver specificato tale indirizzo, è possibile consentire al processo iniettato di comunicare con il driver, quando vengono richiamate determinate funzioni.
DisableDeviceGuardCompat non disattiva o ignora il
scinject.DLL da iniettare. Modifica la funzione agganciata. Non vi è alcun rischio associato alla modifica dell'iniezione
DLL poiché stiamo ancora proteggendo il sistema.
