Domanda source dll

Stato
Discussione chiusa ad ulteriori risposte.

P4SS4

Utente Silver
11 Giugno 2010
44
18
0
68
Ultima modifica:
Ciao a tutti come da titolo avrei bisogno del sorgente di una semplice .dll che che una volta iniettata nel processo faccia apparire un messaggio qualsiasi. Questo mi serve giusto per capire il meccanismo perche io non ho mai scritto una dll e quindi non riesco ad entrare bene nell'ottica di come si scriva una dll;
Premetto che uso devc++ e quando creo il progetto mi compare il codice qui sotto apparte qualche modifica che ci ho fatto per stampare un messaggio ma quando inietto la dll nn stampa nessun messaggio :(
Grazie in anticipo

Codice:
#include <windows.h>




BOOL APIENTRY DllMain (HINSTANCE hInst     /* Library instance handle. */ ,
                       DWORD reason        /* Reason this function is being called. */ ,
                       LPVOID reserved     /* Not used. */ )
{
    switch (reason)
    {
      case DLL_PROCESS_ATTACH:
           {
           MessageBox(NULL, "A", "MessageBox", MB_OK);             
            break;
           }

      case DLL_PROCESS_DETACH:
         {
           MessageBox(NULL, "B", "MessageBox caption", MB_OK);             
            break;
           }

      case DLL_THREAD_ATTACH:
         {
           MessageBox(NULL, "C", "MessageBox caption", MB_OK);             
            break;
           }

      case DLL_THREAD_DETACH:
         {
           MessageBox(NULL, "D", "MessageBox caption", MB_OK);             
            break;
           }
    }

    /* Returns TRUE on success, FALSE on failure */
    return TRUE;
}
 
Non puoi usare MessageBox all'interno di quella procedura ( DllMain ). Ci sono molte cose che non puoi fare in esso.
Che ne dici di usare OutputDebugString (in kernel32) ?
 
ho provato
sia: OutputDebugString("prova");
che:
system("MSG * CIAOOOO");
Non mi va nessuno delle due mi sa che il problema è qualcosaltro boh
 
Non puoi usare MessageBox all'interno di quella procedura

Questo non è vero. Non tutto si può fare nella DllMain ma una MessageBox si. Ne ho scritte decine di Dll che lo fanno.
Sei proprio sicuro che la dll venga effettivamente caricata nel progetto? Hai creato una testApp che carica la dll? Prova a creare un piccolo exe che chiama la dll e dovresti vedere il messaggio. Se lo vedi è perchè l'inject non va a buon fine, come è molto probabile che sia.
 
il problema è della messagebox perche ho provato a metterci un codice assembler e funge cm injector uso questo:
Codice:
#include <iostream.h>
#include <string.h>
#include <windows.h>
#include <tlhelp32.h>

using namespace std;

//========Dichiarazione funzioni========
DWORD GetProcID(string ProcName);
DWORD WINAPI GetCurrentProcessId(void);
BOOL ProcessExists(string process);
//======================================

int main() {
    char* coder_name = "passa1248"; //Nome del creatore dell'injector
    char* DLLName = "prova.dll"; //Nome della DLL
    char* GameName = "prova"; //Nome del gioco
    char* ProcessName = "prova.exe"; //Nome del processo (in questo caso ho messo il nome del processo del gioco Combat arms)
    bool CloseAfterCorrectInjection = false; //Se si imposta il valore true, l'injector esce in automatico dopo la corretta iniezione ma se l'iniezione dovesse fallire, non esce.

    DWORD procID = 0;
    cout << "=====================\n";
    cout << " new DLL Injector \n";
    cout << "=====================\n";
    cout << "Coded by " << coder_name << "\n\n";
    cout << "Library name: " << DLLName << "\n";
    cout << "Game name: " << GameName << "\n";
    cout << "Process name to inject: " << ProcessName << "\n\n";
  
    cout << "---------------------------------\n\n";
   
    int nBufferLength = 100;
    CHAR awBuffer[100];
    GetCurrentDirectory(nBufferLength, awBuffer) ;
    strcat(awBuffer,"\\");
    strcat(awBuffer,DLLName);
    string dll = awBuffer;
    HMODULE hLocKernel32 = GetModuleHandle("Kernel32");
    FARPROC hLocLoadLibrary = GetProcAddress(hLocKernel32, "LoadLibraryA");
    HANDLE hToken;
    TOKEN_PRIVILEGES tkp;
    if(OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, &hToken))
    {
        LookupPrivilegeValue(NULL, SE_DEBUG_NAME, &tkp.Privileges[0].Luid);
        tkp.PrivilegeCount = 1;
        tkp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
        AdjustTokenPrivileges(hToken, 0, &tkp, sizeof(tkp), NULL, NULL);
    }
    HANDLE hProc = INVALID_HANDLE_VALUE ;
    cout << "Waiting for the opening of the process " << ProcessName << "...\n";
    while (!ProcessExists(ProcessName)){ //Il ciclo continuer? finch? il processo non verr? aperto
    }
    //Appena il processo viene rilevato, l'injector comincia a iniettarsi in questo modo:
    cout << "Process detected !\n\n";
    procID = GetProcID(ProcessName);
    hProc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, procID);
    cout << "PID:       " << procID << "\n\n"; //Mostra il PID del processo
    cout << "Injecting " << DLLName << "...\n\n";
    dll += '\0';
    LPVOID hRemoteMem = VirtualAllocEx(hProc, NULL, dll.size(), MEM_COMMIT, PAGE_READWRITE);
    DWORD numBytesWritten;
    WriteProcessMemory(hProc, hRemoteMem, dll.c_str(), dll.size(), &numBytesWritten);
    HANDLE hRemoteThread = CreateRemoteThread(hProc, NULL, 0, (LPTHREAD_START_ROUTINE)hLocLoadLibrary, hRemoteMem, 0, NULL);
    bool res = false;
    if (hRemoteThread){
        res = (bool)WaitForSingleObject(hRemoteThread, 10000) != WAIT_TIMEOUT;
        if (res){
            cout << "Dll succesfully injected !\n"; //Se si ? iniettato correttamente
        }else{
            cout << "[ERROR]: Injection failed\n"; //Se non si ? riuscito ad iniettarsi
        }
    VirtualFreeEx(hProc, hRemoteMem, dll.size(), MEM_RELEASE);
    CloseHandle(hProc);
    }else{
    cout << "[ERROR]: Injection failed\n";
    system("PAUSE"); //Pausa l'injector dopo che non ? riuscito ad iniettarsi
    return 0;
    }
    if (!CloseAfterCorrectInjection){system("PAUSE");} // Mette in pausa dopo che l'injector si ? iniettato correttamente sul processo
    return 0;
}
   
DWORD GetProcID(string ProcName)
{
    HANDLE hProcessSnap;
    PROCESSENTRY32 pe32;
    hProcessSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
    pe32.dwSize = sizeof(PROCESSENTRY32);
    do{
        if(pe32.szExeFile == ProcName){
            DWORD ProcId = pe32.th32ProcessID;
            CloseHandle(hProcessSnap);
            return ProcId;
        }
    } while(Process32Next(hProcessSnap, &pe32));
    CloseHandle(hProcessSnap);
    return 0;
}

BOOL ProcessExists(string process)
{
    HANDLE hProcessSnap;
    PROCESSENTRY32 pe32;
    hProcessSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
    pe32.dwSize = sizeof(PROCESSENTRY32);
    do{
        if(pe32.szExeFile == process){
            CloseHandle(hProcessSnap);
            return true;
        }
    } while(Process32Next(hProcessSnap, &pe32));
    CloseHandle(hProcessSnap);
    return false;
}
 
Ultima modifica:
Questo non è vero. Non tutto si può fare nella DllMain ma una MessageBox si. Ne ho scritte decine di Dll che lo fanno.
Sei proprio sicuro che la dll venga effettivamente caricata nel progetto? Hai creato una testApp che carica la dll? Prova a creare un piccolo exe che chiama la dll e dovresti vedere il messaggio. Se lo vedi è perchè l'inject non va a buon fine, come è molto probabile che sia.
E invece sì. Non deve usare MessageBox perchè quest'ultimo richiede un message-loop. Deve usare qualcosa di meno "vulnerabile" di MessageBox. MessageBox a volte potrebbe funzionare e potrebbe non funzionare. L'incoerenza del comportamento è coerente con la documentazione (non l'hai letta? leggila).
I processi non chiamano l'entry DllMain() direttamente. Perciò, non dovresti MAI usare MessageBox per questo tipo di debugging: attiva un elemento GUI (un dialog box) che attiva un pump del messaggio ... Ci sono molti fattori che fanno fallire MessageBox. Specialmente nel loading della DLL.
 
fanti un ultima domanda a me servirebbe fare un applicazione console vera e propria solo che sto facendo tutto sto ambaradam con la dll perche in pratica mi serve per fare un bot per un giochino stupido tanto per esercitarmi e se nn utilizzo la dll non riesco a utilizzare istruzioni asm... però mi servirebbe comunque comunicare con chi sta utilizzando il bot per esempio "premi uno per avviare il bot premi 2 per stopparlo ecc..." solo che con sta dll non so come fare cioè se lo inietto in un programma console mi stampa direttamente in quella console con "cout<<blablabla;" mentre se lo inietto in un'applicazione normale non mi stampa niente. IN pratica vorrei sapere:c'è la possibilita con la dll di aprire un'altra finestra console per comunicare cn l'utente?
Grazie in anticipo
 
E invece sì. Non deve usare MessageBox perchè quest'ultimo richiede un message-loop. Deve usare qualcosa di meno "vulnerabile" di MessageBox. MessageBox a volte potrebbe funzionare e potrebbe non funzionare. L'incoerenza del comportamento è coerente con la documentazione (non l'hai letta? leggila).
I processi non chiamano l'entry DllMain() direttamente. Perciò, non dovresti MAI usare MessageBox per questo tipo di debugging: attiva un elemento GUI (un dialog box) che attiva un pump del messaggio ... Ci sono molti fattori che fanno fallire MessageBox. Specialmente nel loading della DLL.

Non mi pare di aver detto che sia corretto usare MessageBox indiscriminatamente. Io ho letto il codice postato, e in un dllmain fatto in quel modo e con una normale LoadLibrary una MessageBox funziona sempre. Il perchè a questo punto non te lo dico visto che ti senti padrone della verità...vattelo a leggere. Sono anni che tratto questi argomenti (forse da prima che tu nascessi), chi fa reverse engineering a buon livello è costretto a saperlo. Non sono certo qui a farmi insegnare cose che faccio da 20 anni.

@P4SS4 In questo caso è chiaroo per quale motivo non funziona. Ma sarebbe troppo lungo da spiegare. In ogni caso cosa intendi esattamente? Con una dll puoi fare tutto quello che fai con un qualsiasi altro eseguibile, per cui naturalmente anche aprire finestre o console. L'unica cosa a cui devi stare attento è come lo fai. Io non so come utilizzerai la tua dll per comunicare con l'utente, ma è chiaro che se questo lo vuoi fare ad esempio senza bloccare l'esecuzione del programma o in particolari condizioni, tutto dovrà essere ben studiato. Ma per fare quello che vuoi sei sicuro che convenga farlo direttamente dalla dll iniettata? Io credo che sia meglio che tu abbia un eseguibile separato e che usi la dll solo per intervenire sul processo.
Cosa intendi quando dici "se nn utilizzo la dll non riesco a utilizzare istruzioni asm"?
 
  • Mi piace
Reazioni: SpeedJack
Non mi pare di aver detto che sia corretto usare MessageBox indiscriminatamente. Io ho letto il codice postato, e in un dllmain fatto in quel modo e con una normale LoadLibrary una MessageBox funziona sempre. Il perchè a questo punto non te lo dico visto che ti senti padrone della verità...vattelo a leggere. Sono anni che tratto questi argomenti (forse da prima che tu nascessi), chi fa reverse engineering a buon livello è costretto a saperlo. Non sono certo qui a farmi insegnare cose che faccio da 20 anni.
No. Ti assicuro che non dico fesserie. Prima cosa calmati, perchè che tu faccia queste cose da 20 anni (si, ti stai vantando) non vuol dire che quello che dica tu sia infallibile: si può sempre sbagliare.
Seconda cosa, no, MessageBox() è implementato da User32.dll, questa può essere una causa che DllMain() non sembri esser invocata. Non mi credi? Come vuoi. Ti lascio dei link:
http://blogs.msdn.com/b/oldnewthing/archive/2004/01/28/63880.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2004/01/27/63401.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2007/09/04/4731478.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2010/01/15/9948740.aspx

Meno saccente, più generoso la prossima volta, mi raccomando Gohan!
NB mister sapientone: se non li leggi, non ti aspettare una mia risposta, CHIARI?
 
eh in pratica se tipo nel gioco ho un bottone che quando lo clicco il mio carrarmato si muove a sinistra e quindi va ad eseguire una serie di istruzioni asm per far si che il carrarmato si muova in una determinata posizione, e io volessi simulare l'esecuzione di questo bottone non posso semplicemente scrivere nel indirizzo della coordinata x il nuovo valore perche sarebbe una specie di teletrasporto ed nel caso di un gioco online mi disconnetterebbe quindi devo andare ad eseguire tt qlle operazioni scritte in asm che vengono eseguite durante la pressione di quel bottone, per fare ciò non posso utilizzare un normale eseguibile e dirci
mov eax,0x22ff44(indirizzo ipotetica coordinata x)
add eax,5
mov 0x22ff44,eax
perche andrebbe a scrivere su una zona di memoria in cui non puo accedere, invece con la dll iniettata si.
Quindi mi servirebbe che questa dll appena iniettata apra una console con una serie di comandi e in base al numero che acquisisce esegua una determinata funzione.
Cioè in pratica il mio obiettivo è che in sto gioco 2d che si chiama pocket tanks dove ci sono 2 carrarmati che si devono sparare
il mio carrarmato si muovi,miri e spari automaticamente e con le funzioni readprocessmemory e writeprocessmemory non credo sia possibile.
 
eh in pratica se tipo nel gioco ho un bottone che quando lo clicco il mio carrarmato si muove a sinistra e quindi va ad eseguire una serie di istruzioni asm per far si che il carrarmato si muova in una determinata posizione, e io volessi simulare l'esecuzione di questo bottone non posso semplicemente scrivere nel indirizzo della coordinata x il nuovo valore perche sarebbe una specie di teletrasporto ed nel caso di un gioco online mi disconnetterebbe quindi devo andare ad eseguire tt qlle operazioni scritte in asm che vengono eseguite durante la pressione di quel bottone, per fare ciò non posso utilizzare un normale eseguibile e dirci
mov eax,0x22ff44(indirizzo ipotetica coordinata x)
add eax,5
mov 0x22ff44,eax
perche andrebbe a scrivere su una zona di memoria in cui non puo accedere, invece con la dll iniettata si.
Quindi mi servirebbe che questa dll appena iniettata apra una console con una serie di comandi e in base al numero che acquisisce esegua una determinata funzione.
Cioè in pratica il mio obiettivo è che in sto gioco 2d che si chiama pocket tanks dove ci sono 2 carrarmati che si devono sparare
il mio carrarmato si muovi,miri e spari automaticamente e con le funzioni readprocessmemory e writeprocessmemory non credo sia possibile.
Diciamo che è fuori topic. Ti consiglio di farne un altro più attinente a questo.

Comunque, sempre per aggiungere una cosa a Gohan.
Dalla documentazione. Toh!
During initial process startup or after a call to LoadLibrary, the system scans the list of loaded DLLs for the process. For each DLL that has not already been called with the DLL_PROCESS_ATTACH value, the system calls the DLL's entry-point function. This call is made in the context of the thread that caused the process address space to change, such as the primary thread of the process or the thread that called LoadLibrary. Access to the entry point is serialized by the system on a process-wide basis. Threads in DllMain hold the loader lock so no additional DLLs can be dynamically loaded or initialized.
Oh, guarda un pò!
Non capisci? Non sai l'inglese? Bene, ti spiego in poche righe:
NON puoi chiamare qualsiasi funzione che possa chiamare loadlibrary o freelibrary o potresti creare un ciclo di dipendenza. Non avrebbe comunque senso. DllMain è solo usato per fare inizializzazioni molto limitate, è un entry point (punto di ingresso) della tua libreria, NON è un "posto" dove la logica dovrebbe essere eseguita.
MessageBox() dovrebbe essere chiamato chiamato in DllMain()? No.
 
NB mister sapientone: se non li leggi, non ti aspettare una mia risposta, CHIARI?
Non li leggo perchè so perfettamente come funzionano i moduli di windows, il loader, il kernel e tutto il resto. Grazie lo stesso. E poi non mi pare il caso di andare così off topic.


@P4SS4 Guarda non hai capito cosa volevo intendere. Non è proprio così. Intanto in realtà la cosa la puoi eseguire anche senza iniettare una dll, ma questo è un altro discorso.
Quello che volevo però intendere è che sicuramente la dll iniettata può fare molto facilmente qualcosa del genere:
mov eax, miovalore
mov ecx, x_cord
add ecx,eax
mov x_cord,ecx
E fino qua ci siamo.
Tu stai dicendo di voler impostare il tutto in modo tale da consentire alla dll di aprire anche una finestra che ti consenta di dire ad esempio "sposta la x di 5 in avanti".
Questo si può senz'altro fare, hai ragione. Ma tenendo presente che essendo una dll iniettata per logica è sempre meglio che questa sia meno invasiva possibile, allora sarebbe anche possibile inserire tutta questa parte nell'injector. Ad esempio potresti creare dei piccoli thread remoti che chiamano le funzioni della tua dll per trovare gli indirizzi di memoria, leggerli, scriverli ecc. ecc. E' molto più pulita come soluzione, perchè devi considerare che anche se mettessi tutto nella dll dovresti scrivere in ogni caso la stessa quantità di codice se non di più. Inoltre in questo modo potresti creare una libreria il più generica possibile che ti consentirebbe di utilizzarla anche in altre circostanze. L'esperienza mi dice che questa è una buona via per procedere. Ciò non toglie che puoi procedere in qualsiasi modo.
 
Non li leggo perchè so perfettamente come funzionano i moduli di windows, il loader, il kernel e tutto il resto. Grazie lo stesso. E poi non mi pare il caso di andare così off topic.
Questa è bellissima :D, comunque mi hai fatto fare una risatina, che noobie :DDDDDDDDDDD .
Dopo che hai letto quello che ho scritto ...
E' della serie "Ha ragione, ma rispondiamo solo una parte del commento, così non facciamo brutta figura"
 
Non capisci? Non sai l'inglese? Bene, ti spiego in poche righe:
NON puoi chiamare qualsiasi funzione che possa chiamare loadlibrary o freelibrary o potresti creare un ciclo di dipendenza. Non avrebbe comunque senso. DllMain è solo usato per fare inizializzazioni molto limitate, è un entry point (punto di ingresso) della tua libreria, NON è un "posto" dove la logica dovrebbe essere eseguita.
MessageBox() dovrebbe essere chiamato chiamato in DllMain()? No.

Per inciso: detengo un certificato di intemediate english, necessario per chi lavora in ambiti di sviluppo come quelli dove lavoro.
Il fatto è che non mi dici niente di nuovo, so perfettamente come funziona ti ripeto. Chiaramente l'entrypoint della dll (ma anche degli altri eseguibili tutto sommato), non è il posto adatto per infilare una MessageBox. Io stavo parlando infatti di quell'esempio specifico, anche quelli fatti da me in passato ovviamente erano tutte situazioni controllate. Stiamo parlando del nulla mischiato con niente. se tu compili il suo progetto e fai un exe che carichi la libreria, ti mostrerà la MessageBox 100 volte su 100, anche se rimane il fatto che non sia un metodo troppo ortodosso di operare.
 
Questa è bellissima :D, comunque mi hai fatto fare una risatina, che noobie :DDDDDDDDDDD .
Dopo che hai letto quello che ho scritto ...
E' della serie "Ha ragione, ma rispondiamo solo una parte del commento, così non facciamo brutta figura"
No, non hai ragione...tranquillo, quando studiavo ne ho letti migliaia di articoli simili. Non è che arriva il primo piripicchio e mi dice cosa devo leggere, semplicemente questo. Se solo fossi entrato anche solo una volta nell'assembly della user32.dll capiresti per quale motivo dico che la MessageBox l'avrebbe senz'altro mostrrata.
 
Wow, quindi mi stai dicendo che posso richiamare delle funzioni scritte dentro la dll iniettata dal injector... con l'injector stesso? omg dimmi di siiii *__*
 
No, non hai ragione...tranquillo, quando studiavo ne ho letti migliaia di articoli simili. Non è che arriva il primo piripicchio e mi dice cosa devo leggere, semplicemente questo. Se solo fossi entrato anche solo una volta nell'assembly della user32.dll capiresti per quale motivo dico che la MessageBox l'avrebbe senz'altro mostrrata.
Aspè, fermo!
Piripicchio non sbaglia mai:
MessageBox() is implemented in user32.dll: this may be a possible cause of DllMain() appearing to not be invoked.
Ok, adesso puoi cancellarti l'account Inforge.
 
Embè? Mah...mi spiace dirlo ma sei molto meno dentro il discorso di quanto immaginassi. Non so che dirti, a parte di provare personalmente con un bel debugger, così forse capirai qual è esattamente il punto della questione. Ti si apre un mondo.
 
Embè? Mah...mi spiace dirlo ma sei molto meno dentro il discorso di quanto immaginassi. Non so che dirti, a parte di provare personalmente con un bel debugger, così forse capirai qual è esattamente il punto della questione. Ti si apre un mondo.
Vuol dire che può funzionare solo se stai usando l'api thread e hai già fatto il load di tutto ciò che hai bisogno.
Studia.
 
Vuol dire che può funzionare solo se stai usando l'api thread e hai già fatto il load di tutto ciò che hai bisogno.
Studia.
Da quello che scrivi capisco che non ti sei mai messo su un debugger all'entrypoint di un eseguibile, altrimenti non staresti nemmeno a discutere. Quindi...studia tu che è meglio. Non sono interessato a discutere ancora con chi crede di avere ragione pur non avendo mai visto lo spazio di memoria standard di un eseguibile. Ciao

@P4SS4 Io ho scirtto quello che devi fare, non so in quale altro modo ti si possa aiutare, eccetto scrivere il software per te, ma questo non verrà fatto, ameno da me.
 
Si ma sembra una cosa parecchio strana e laboriosa richiamare funzioni di una DLL iniettata in un processo... E se invece dentro la DLL dichiaro per esempio una variabile x e la inizializzo a 0 e poi da un programma esterno tipo l'injector stesso quando voglio che la DLL esegua una funzione utilizzo la writeprocessmemory e vado a modificare il valore all'indirizzo di x e nella DLL faccio un while true che mi controlla se sta variabile é uguale a 1 esegue una determinata funzione oppure aspetta 1 sec e riesegue il loop,andrebbe bene o sarebbe un dispendio di risorse trpp grosso?
 
Da quello che scrivi capisco che non ti sei mai messo su un debugger all'entrypoint di un eseguibile
Hai ragione. Esatto.

Quindi...studia tu che è meglio
Bella idea. Prenderò in considerazione il tuo consiglio.

Non sono interessato a discutere ancora con chi crede di avere ragione pur non avendo mai visto lo spazio di memoria standard di un eseguibile.
Molto attinente.

Visto che pensi che quindi sia praticamente infallibile, e pensi che io non mi sia accertato di quello che dico, non si dovrebbe comunque fare, quindi dovresti pure levartelo dalla testa, ti ho già ripetuto che non è buono chiamare qualsiasi API da user32.dll in DLLMain() in quanto non è sicuro e può creare una situazione deadlock.
Statisticamente, però se farai uso di queste funzioni all'interno di DLLMain(), potrà non fare alcuna differenza se sono dichiarati come WinAPI o meno (__stdcall) ... WinAPI in particolare indica la convenzione della chiamata __stdcall.
Una particolare caratteristica della convenzione della chiamata __cdecl è che per tali funzioni, le VAL possono essere usate; questo non è possibile per le funzioni __stdcall.
 
  • Mi piace
Reazioni: CristoScesoInTerra
Si ma sembra una cosa parecchio strana e laboriosa richiamare funzioni di una DLL iniettata in un processo... E se invece dentro la DLL dichiaro per esempio una variabile x e la inizializzo a 0 e poi da un programma esterno tipo l'injector stesso quando voglio che la DLL esegua una funzione utilizzo la writeprocessmemory e vado a modificare il valore all'indirizzo di x e nella DLL faccio un while true che mi controlla se sta variabile é uguale a 1 esegue una determinata funzione oppure aspetta 1 sec e riesegue il loop,andrebbe bene o sarebbe un dispendio di risorse trpp grosso?

Non è un dispendio di risorse, ma non è nemmeno esattamente quello che intendevo.
Quello che intendo è fare in modo che la dll esporti una serie di funzioni che ti consenta di farlo, ad esempio:
FindXaddress
FindYaddress
GetX
SetX
GetY
SetY
ecc. ecc.

A questo punto non ti servirà altro che iniettare un piccolo thread nel processo che le richiami, non so se mi sono spiegato. Oppure addirittura il thread nel processo lo puoi lasciare sempre attivo in attesa di eventi da parte dell'injector, e a seconda degli eventi chiamare le funzioni, quindi di fatto non è nemeno necessario che la dll le esporti. Puoi usare eventi semplici, multipli, pipeline ecc. ecc.
E' molto stimolante perchè si impara a programmare ma anche a conoscere il funzionamento del sistema operativo, che a quanto pare non è così scontato :)

PS Fantastica la funzione del forum che permette di ignorare gli utenti dei quali non ti interessano i contenuti. Si vede tutto molto più pulito, senza ignoranza e stupidagigni inutili.
 
Stato
Discussione chiusa ad ulteriori risposte.