Il nostro caso di studio (winscard.dll) è quello del linking dinamico sopra citato. Possiamo schematizzare il nostro approccio come in figura:
La fake dll è quella che dovremo sviluppare noi, mentre la dll originale è la winscard.dll in %windows%/%system32%.
Cosa farà il programma chiamante? Per prima cosa caricherà la DLL con la funzione LoadLibrary, poi recupererà tutti i puntatori a funzione dell'interfaccia winscard che gli servono: in genere non tutti, ma solo quelli necessari.
Nell'esempio di codice riportato, il programma carica la libreria e poi recupera il puntatore a funzione della funzione SCardEstablishContext:
|
Nel framework che vi presento ho implementato tutta l'interfaccia della winscard.dll in modo che, l'utente deve solo implementare le operazioni da fare nella funzione hookata. La funzioni esportate definite in winscardbridge.def sono le seguenti:
|
Ho riportato una breve descrizione dell'interfaccia della winscard, basata sulla documentazione MSDN:
|
Quando si crea una DLL è importante definire il DLLMain (sebbene esso sia opzionale!), che viene chiamata dal sistema quando i processi ed i threads sono inizializzaati e terminati, oppure quando il thread chiamante fa LoadLibrary o FreeLibrary.
Il parametro ul_reason_for_call ci permette di capire se la DLL è caricata\scaricata da un processo\thread, essa può assumere i corrispondenti valori:DLL_PROCESS_ATTACH, DLL_PROCESS_DETACH,DLL_THREAD_ATTACH,DLL_THREAD_DETACH con gli ovvi significati.
MyDLLInit
In questa funzione inizializziamo la nostra DLL.
Costruiamo il path assoluto della dll originale del tipo c:\windows\system32\winscard.dll, facciamo il load della dll in questione,recupera tutti i puntatori a funzione dell'interfaccia ed apre un file di log. Vediamo alcune porzioni di codice relative:
|
Le signature dell'interfaccia sono state riprese dalla MSDN. Stiamo attenti a non confonderci: la nostra fake dll espone le stesse funzioni, con stesso prototipo e stessi nomi della dll originale. L'hooking si effettua all'interno della le funzioni della nostra fake dll.
Per le funzioni che non vogliamo hookare richiamiamo semplicemente la funzione della dll originale mediante i puntatori recuperati durante l'init, mentre per quelle che vogliamo hookare, prima della chiamata alla funzione originale, effettuiamo il nostro payload.
Il recupero dei puntatori avviene nel modo seguente:
|
Ecco un esempio: non vogliamo hookare la EstablishContext e ReleaseContext, mentre vogliamo hookare la SCardTransmit.
|
MyDllUnload
Questa funzione viene chiamata quando viene fatto l'unload della nostra dll. Nel nostro caso è necessario liberare a sua volta la memoria associata alla dll originale caricata in precedenza e chiudere il file di log precedentemente aperto.
|
Uso del framework
Il framework può essere usato per emulare una smartcard (quindi anche le dongle che rientrano in questa categoria).
Come si fa? Supponendo di avere la smart card, prima registriamo tutto il traffico dati tra l'host e la card, e poi scriviamo un emulatore, sempre come fake dll che alle request dell'host risponde con le answer precedentemente acquisite. Ovviamente se il software usa una smart card, con caratteristiche di crittografia, un challenge response sulle chiavi o uno scambio mediante crittografia asimettrica, manda all'aria il nostro sistema.
D'altra parte, i software visti finora usano delle dongle banali, ma questo non esclude che in futuro o tuttora si usino delle smart card più intelligenti.
Un altra cosa a cui dobbiamo stare attenti, è come viene caricata la da parte dell'eseguibile.
Infatti se esso fa una cosa del tipo: LoadLibrary("nomedll.dll"), siamo a cavallo perchè basta mettere la nostra dll nello stesso path dell'exe. Tuttavia i programmatori si sono iniziati ad infurbire ed iniziano a mettere i path assoluti nelle LoadLibrary, quindi in quel caso dobbiamo rinominare la dll originale e mettere quella fake nella cartella di system32. Poichè windows non permette questa operazione, dobbiamo usare un tool come windows replacer.