Ciao a tutti,
chiunque si cimenti nella programmazione in C++ sia che si tratti di programma (.exe) sia che si tratti della solita hack (.dll) da iniettare, potrebbe incappare (come è successo) nel problema per cui sul proprio pc tutto funziona e una volta ridistribuito il proprio applicativo/hack, questo non funziona sul pc di chi lo sta provando.
Premesso che di motivi per cui questo può accadere ce ne possono essere vari, voglio porre l'attezione sul caso della mancanza del runtime di visual C++ sul pc dove si verifica l'errore.
Un tipico messaggio potrebbe essere questo:
Impossibile avviare l'applicazione specificata.MSVCR100.DLL non è stato trovato. Una nuova installazione dell'applicazione potrebbe risolvere il problema.
I modi di risolverlo che mi vengono in mente sono:
1. dire alla persona con l'errore di installarsi il visual C++ runtime scaricandolo dal sito microsoft
2. dire alla persona di scaricarsi da internet la sola msvcr100.dll e copiarla nella cartella del programma o nella cartella di sistema
3. fare in modo che il nostro programma/hack NON dipenda da quella malefica .dll!
Immaginerete che sono qui per parlare del punto 3
esatto!
Ma cominciamo dall'inizio.
Mi sono scritto una mini-dll che in pratica non fa nulla, e l'ho chiamata
MyHack e voglio iniettarla in
notepad.exe (potrebbe essere warrock o altro, non ha importanza per quello che vogliamo vedere noi).
Bene, se compilo la hack cosi com'è senza toccare nessun settaggio del mio progetto e poi simulo di stare su un pc SENZA la MSVCR100.DLL (l'ho rinominata) e la inietto in notepad utilizzando un tool generico come Winject, questo è quello che succede:
Visto? il famigerato errore!
Perchè? perchè quando inietto la dll in notepad quello che succede è che una determinata parte del codice della dll (di inizializzazione) viene eseguito in automatico, peccato che sto codice non si trovi effettivamente nella hack stessa ma si trovi di fatto all'interno della libreria dinamica MSVCR100.DLL
Questo è un comportamento giusto e voluto da microsoft, peccato che nel nostro caso ci dia fastidio perchè accadrà che chi userà la nostra hack senza aver installato il runtime del vc otterrà questo errore e non sapendo che fare probabilmente scarterà la hack.
Ma andiamo a vedere che faccia ha la lista delle dipendenze della nostra hack con un tool tipo CFF Explorer:
Come vedete la nostra hack dipende da 2 librerie esterne che DEVONO trovarsi sul pc che la eseguirà (e nei percorsi giusti) e sono
KERNEL32.dll
MSVCR100.dll
bene, della prima non ci importa nulla in quanto è una libreria standard del sistema che arriva con windows stesso e quindi non mancherà mai a nessuno.
La seconda ci dice "attenzione! se questa msvcr100.dll dovesse mancare, io non funzionerò"
Bene allora cominciamo a vedere qual è il settaggio di default in Visual C++ 2010 responsabile di questo tipo di comportamento.
Ci si arriva facendo tasto destro in Solution explorer sul nome del progetto (qui MyHack), quindi proprietà.
Espandiamo "Configuration properties"
Espandiamo "C/C++"
Andiamo in "Code Generation"
diamo un occhiata a destra alla voce "runtime library"
Qui l'immagine di cosa ci appare:
(c'entra poco con l'argomento, ma notate che sto lavorando con la configurazione RELEASE e NON debug, visto che quando si distribuisce una propria dll o programma si dovrebbe distribuire la release, inoltre se avessimo usato la debug, il nome del file sarebbe stato MSVC100D.dll dove quella d sta appunto per DEBUG)
Dall'immagine si vede che siamo settati per l'uso di un runtime "
Multi-threaded DLL"
La parola importante qui da notare è "DLL".
Bene allora cambiamo questo settaggio in quest'altro:
Ora è "
Multi-threaded" e basta SENZA "DLL"
Bene, dopo aver cambiato questo settaggio ricompiliamo il programma e andiamo a vedere cosa dice il tool CFF Explorer con cui vediamo le dipendenze della nostra hack:
Wow! non risulta piu essere dipendente da niente se non da Kernel32 che come abbiamo visto non ci interessa.
Ma sarà tutto vero?
Proviamo ad iniettare la nuova hack modificata in notepad.exe per vedere cosa succede (sempre con la msvcr100.dll rinominata in modo che non la possa trovare)
Bingo!
come si vede da WinJect l'iniezione ha avuto successo! e non è comparso nessun errore. Abbiamo risolto il problema
ciao
alla prossima
Digger