Iniezione di memoria nei giochi

2

Attualmente sto effettuando ricerche su attacchi di memoria per giochi su Windows 7/10.

Dopo aver esaminato diversi thread su questo argomento, ci sono alcune domande che non sono ancora chiare.

  1. L'iniezione di DLL può essere facilmente rilevata utilizzando l'introspezione. Anche se si aggiustano e firmano una DLL esistente, SHA1 non corrisponderà e genererà bandiere rosse, supponendo che il client di gioco abbia rilevato tutto ciò. Corretto?

  2. L'iniezione di memoria può essere utilizzata per iniettare codice malevolo, tuttavia questo può essere ottenuto apparentemente solo utilizzando un modulo del kernel firmato poiché lo spazio di memoria è protetto dalla lettura / scrittura da parte di altri processi. Corretto?

  3. Se un modulo del kernel viene utilizzato per iniettare nella memoria di un processo, il processo è in grado di rilevarlo? Ad esempio, diciamo che c'è una stringa in memoria che punta a un percorso del disco ( /conf/something.cnf ), se questo è stato sovrascritto con una stringa con la stessa lunghezza esatta, il processo sarebbe in grado di rilevare che la memoria è stata sovrascritta?

posta sleepycal 27.09.2015 - 22:39
fonte

1 risposta

2

Risposta in ordine inverso, perché le tue domande successive sono basate su ipotesi imprecise nelle tue precedenti:

3: Non se il codice di iniezione è abbastanza subdolo. In teoria, un processo può, naturalmente, scansionare il proprio spazio di indirizzamento e rilevare cose che non gli appartengono. Quella procedura che richiede la scansione deve essere nel processo da qualche parte, però, e in pratica puoi semplicemente modificarla quando fai le iniezioni.

2: errato. Qualsiasi processo può essere sottoposto a debugging da un altro processo in esecuzione con lo stesso token di sicurezza del debuggee o con un superset dell'accesso del token (ovvero, un processo sandboxing dell'utente A può essere sottoposto a debug da un processo non sandboxing con lo stesso utente) , o da qualsiasi processo con privilegi elevati (SeDebugPrivilege, che normalmente è solo amministratori ma potrebbe essere altri processi). Vedi, ad esempio, WriteProcessMemory . Se si desidera rendere eseguibile la memoria, sarà probabilmente necessario aver usato / utilizzato VirtualAllocEx / VirtualProtectEx . Se si desidera avviare una discussione (nel processo di destinazione) in esecuzione sulla memoria inserita, consultare CreateRemoteThread .

1: Stai confondendo DLL injection e qualcos'altro, probabilmente accovacciata DLL ( che non sembra essere un termine ben noto, ma è ciò che uso e ho sentito usare quando metti la tua copia di una DLL prevista più in alto nel percorso di caricamento - ad esempio, nella directory del programma - rispetto al versione reale). L'iniezione di DLL (dove il processo non si aspettava di caricare quella DLL) viene eseguita in diversi modi, comunemente usando l'iniezione di memoria come sopra (iniettare il nome della DLL, usare CreateRemoteThread per avviare una discussione che chiama LoadLibrary nel processo di destinazione con il nome DLL immesso come parametro). Quella DLL potrebbe quindi, ovviamente, modificare il processo per fare cose come disabilitare o ignorare qualsiasi codice di introspezione che l'autore della DLL fosse a conoscenza.

    
risposta data 27.09.2015 - 23:57
fonte

Leggi altre domande sui tag