C/C++ - Lettura dell'intera memoria di un processo

Forum - C/C++ - Lettura dell'intera memoria di un processo - Pagina 2

Pagine: [ 1 2 ]

TheDarkJuster (Member)
Guru^2

Messaggi: 1620
Iscritto: 27/09/2013

Postato alle 11:44
Martedì, 19/01/2016

Voglio fare la stessa identica cosa, senza passare per cheatengine, perché non lo posso distribuire insieme alla libreria.

TheDarkJuster (Member)
Guru^2

Messaggi: 1620
Iscritto: 27/09/2013

Postato alle 13:42
Martedì, 19/01/2016

In pratica il garbage collector funziona così: al momento dell'allocazione viene aggiunto l'indirizzo di base della memoria allocata a una lista.

Il GC controlla che lindirizzo di base (o indirizzo di base + x appatenente alla memoria allocata) appaia più di una volta. Se appare una sola volta ibera la memoria, poichè l'unica referenza rimasta è quella interna al garbage collector

In questo modo non c'è bisogno di chiamare free (anche se è necessario aspettare un tempo indefinito prima di vedere la memoria rimossa)

Thejuster (Admin)
Guru^2

Messaggi: 2305
Iscritto: 04/05/2008

Postato alle 16:08
Martedì, 19/01/2016

Non so se può esserti utile.

Ma qui puoi trovare il sorgente di Cheat Engine

https://github.com/cheat-engine/cheat-engine

e' scritto in pascal ma è molto comprensibile.
Almeno ci si può fare un idea di come funziona il controllo sulla gestione degli indirizzi.

https://mire.forumfree.it/ - Mire Engine
C# UI Designer

TheDarkJuster (Member)
Guru^2

Messaggi: 1620
Iscritto: 27/09/2013

Postato alle 19:08
Martedì, 19/01/2016

Non riesco a trovare ciò che mi interessa....

Thejuster (Admin)
Guru^2

Messaggi: 2305
Iscritto: 04/05/2008

Postato alle 8:23
Mercoledì, 20/01/2016

Ho.dato.un occhiata.
Ho trovato il sorgente della scansione.
Ma hanno usato cuda.
Per questo e veloce la ricerca...
Il computing di nvidia e velocissimo, credo che con il
Normalissimo uso dalla cpu implicherebbe 10 o 20 volte di più
Il tempo di ricerca che effettua cuda.

Ultima modifica effettuata da Thejuster il 20/01/2016 alle 8:27

https://mire.forumfree.it/ - Mire Engine
C# UI Designer

TheDarkJuster (Member)
Guru^2

Messaggi: 1620
Iscritto: 27/09/2013

Postato alle 15:21
Mercoledì, 20/01/2016

Il tempo non è un problema, il gc serve per trovare memoria dimenticata li, non per sostituire free.

TheDarkJuster (Member)
Guru^2

Messaggi: 1620
Iscritto: 27/09/2013

Postato alle 21:34
Giovedì, 21/01/2016

Buona sera,
ci sto lavorando da un po' e faccio dei passi avanti..... Ma ora sono bloccato in una situazione "imbarazzante".....

Prima di procedere voglio puntualizzare che il codice trae ispirazione da questo articolo: http://www.codeproject.com/Articles/716227/Csharp-How-to-S ..., le modifiche apportate all' "algoritmo" si basano sul fatto che voglio la memoria accessibile del solo processo corrente, quindi, invece di usare VirtualQueryEx uso VirtualQuery.

Codice sorgente - presumibilmente C#

int64_t GetActiveReferences(void* ptr) noexcept(true) {
                //setup the counter
                int64_t referencesNumber = -1;
 
                //check if the memory is valid
                if (ptr != NULL) {
                        //retrive the memory descriptor
                        MappedMemoryDescriptor* memoryDescriptor = getMappedMemoryDescriptor(ptr);
 
                        //check if the memory is mapped by the garbage collector
                        if (memoryDescriptor != (MappedMemoryDescriptor*)NULL) {   //la parte interessante comincia qui!!!
                                
                                //perform the memory check
                                //this struct will hold details about the system
                                _SYSTEM_INFO info;
 
                                //use the proper way of getting info about the current environment
                                BOOL bIsWow64 = FALSE;
                                if (IsWow64Process(GetCurrentProcess(), &bIsWow64)) {
                                        if (bIsWow64) {
                                                GetNativeSystemInfo(&info);
                                        }
                                        else {
                                                GetSystemInfo(&info);
                                        }
                                } else {
                                        GetSystemInfo(&info);
                                }
 
                                //this is what will hold info about a portion of memory that will be read (if it is the program memory)
                                MEMORY_BASIC_INFORMATION mem_basic_info;
 
                                //read EVERY chunk of memory that may be used by application!!!!
                                uint64_t currentMemoryRegion = (uint64_t)((intptr_t)info.lpMinimumApplicationAddress);
                                while (currentMemoryRegion < (uint64_t)((intptr_t)info.lpMaximumApplicationAddress)) {
                                        //query informations about the current memory region
                                        VirtualQuery((LPVOID)((intptr_t)currentMemoryRegion), &mem_basic_info, 28);
 
                                        //read the memory if it can be read
                                        if ((mem_basic_info.Protect == PAGE_READWRITE) && (mem_basic_info.State &= MEM_COMMIT)) {
                                                printf_s("\nbase memory region: %llx\n\nregion size: %llu\n", (uint64_t)((intptr_t)mem_basic_info.BaseAddress), (uint64_t)(mem_basic_info.RegionSize));
                                        }
 
                                        //head to the next memory to be read
                                        currentMemoryRegion += mem_basic_info.RegionSize;
                                }
                        }
                }
 
                //return the result
                return referencesNumber;

Ora.... memoryDescriptor è diverso da NULL, e può cominciare l'esecuzione della parte interessante.

Mi ritrovo in output diversi indirizzi di memoria con dimensioni multiple di 4096 (che suppongo essere la dimensione minima di memoria che un processo più ottenere dal S.O.)

Niente si sbagliato fin qui.... Ma il programma continua a ciclare......

Mi insospettisce il tempo che ci mette a portare a termine il suo compito, quindi metto il debugger in pausa e me lo ritrovo fermo all'esecuzione di VirtualQuery. Ok, nulla di strano, se non fosse che currentMemoryRegion ha valore 0x0213069e7fff0962 e la massima area di memoria utilizzabile dalle applicazione è 0xfffeffff.

0x0213069e7fff0962 è decisamente maggiore di 0xfffeffff e sto trattando ambedue i numeri come interi senza segno di 64 bit, quindi non mi spiego perchè il while fallisca così miseramente e la cpu stabilisca che 0x0213069e7fff0962 è minore di 0xfffeffff !!!

Ciò che viene compilato è questo: while (currentMemoryRegion < (uint64_t)((intptr_t)info.lpMaximumApplicationAddress))

perchè ho un comportamento così bizzarro da parte dell'applicazione?!?!?

Pagine: [ 1 2 ]