PDA

Visualizza la versione completa : [C++] Funzione per digest MD5 da restituire a VB.NET


Antonyy74
28-12-2010, 01:05
Sto provando a realizzando una dll scritta in C++ (di cui so ben poco) in cui esiste una funzione in cui passi una stringa e restituisce il digest della stessa, ma non torna quello che mi interessa in un progetto in VB.NET
Ho preso spunto da questo articolo (http://www.codeproject.com/KB/security/cmd5.aspx) e il codice scritto fino adesso il seguente:



__declspec(dllexport) const char* Digest(const char* plainText)
{
CMD5 md5;
md5.setPlainText(plainText);
return md5.getMD5Digest();
//return "KLHKLHKL";
}

__declspec(dllexport) const char* Test(const char* plainText)
{
return plainText;
}


Ora fa funzione Test ritorna la stringa corretta nel progetto in VB:NET:



<DllImport("Permission.dll")> _
Public Function Test(ByVal s As String) As String
End Function

<DllImport("Permission.dll")> _
Public Function Digest(ByVal s As String) As String
End Function

Dim b As String = Test("hhhh1212")


cosa sbaglio ?

MacApp
28-12-2010, 02:38
cancellato

Antonyy74
01-01-2011, 22:15
Originariamente inviato da MacApp
cancellato

:confused:

Comunque sia ho per ora risolto in questo modo, trasportando la creazione del Digest sul progetto VB.NET e lasciando alla dll in C++ il confronto dei due digest, in questo modo:



#include <iostream>
#include <string>
#define MYDIGEST "8E284161AB89BFA0085F75542C07F44D"
using namespace std;

extern "C"
{

__declspec(dllexport) bool Exist(void)
{
return 1;
}

__declspec(dllexport) bool Verify(char* digest)
{
string s3 (digest);
if (s3== MYDIGEST)
{
return 1;
}
else
{
return 0;
}
}
}


in VB.Net:



<DllImport("Permission.dll")> _
Public Function Verify(ByVal md5 As String) As Boolean
End Function

MItaly
01-01-2011, 23:35
Ma perch non puoi fare il confronto direttamente dentro all'applicazione VB.NET? :confused: O un progetto "di prova"?

Antonyy74
02-01-2011, 14:21
Perch se facessi il confronto direttamente nell'applicazione VB.Net primo per cambiare la password dovrei ricompilare il progetto e anche se sono io il programmatore non sono sicuro al 100% che un domani riuscirei a ricompilare il tutto visto che ci sono molti riferimenti a librerie esterne licenziate, meglio essere previdenti. In questo modo basta solo cambiare il digest e ricompilare la .dll e sono a posto. Secondo con il digest memorizzato in VB.net tutto o quasi in chiaro anche se solo con il digest non ci posso fare un granch ma volendo.....forse fatto con C++ forse un po pi difficile ?

MItaly
02-01-2011, 14:33
Se la tua dll C++ contiene soltanto il codice per il confronto dei digest forse ancora pi facile estrarlo che dall'applicazione VB.NET. Se lo memorizzi come stringa, andr a finire nella string table dell'eseguibile, per cui basta un editor esadecimale per portarsi nella zona giusta (si capisce dal fatto che ci sono tutti i messaggi di errore della CRT), poi risulta riconoscibilissimo. Se lo memorizzi direttamente come i byte che lo compongono (invece che con la loro rappresentazione esadecimale) le cose diventano leggermente pi difficili, ma basta un disassembler per trovare il punto dove viene fatto il confronto (di nuovo, il lavoro facilitato dal fatto che la dll non conterrebbe nient'altro).

Ancora meglio: tenendo l'autenticazione separata in una dll, diventa facilissmo rimpiazzare la dll con una che restituisce true in ogni caso, rendendo possibile inserire qualunque codice nell'applicazione principale.

Antonyy74
02-01-2011, 14:44
Allora maschero il mio digest, metto tra i caratteri altri caratteri che non fanno parte del digest e poi estraggo la stringa corretta ?????

:bh:

MItaly
02-01-2011, 14:49
Originariamente inviato da Antonyy74
Allora maschero il mio digest, metto tra i caratteri altri caratteri che non fanno parte del digest e poi estraggo la stringa corretta ?????

:bh:
In linea di massima rimane inutile: sempre possibile rimpiazzare la tua dll con una che restituisce sempre true, o modificarla (anche direttamente in memoria) in maniera analoga: basta sovrascrivere il codice della funzione con dei NOP (opcode 90) lasciando giusto il codice di cleanup dello stack in fondo e mettere 1 nel registro EAX (che contiene il valore restituito); et voil, la tua funzione restituisce true per qualunque digest.

Tutto questo naturalmente possibile solo se l'utente ha accesso in scrittura alla dll o il proprietario del processo; in alternativa, avendo solo l'accesso in lettura alla dll, comunque possibile disassemblarla e cercare di capire quali caratteri vengono saltati.

Antonyy74
02-01-2011, 14:55
Originariamente inviato da MItaly
In linea di massima rimane inutile.....


Mi stai dicendo che meglio lasciare le chiavi sul cruscotto almeno non fanno danni.......???




Tutto questo naturalmente possibile solo se l'utente ha accesso in scrittura alla dll o il proprietario del processo;


Ovvero ????

MItaly
02-01-2011, 15:03
Originariamente inviato da Antonyy74
Mi stai dicendo che meglio lasciare le chiavi sul cruscotto almeno non fanno danni.......???

Ti sto dicendo che qualunque sistema di protezione sempre aggirabile se tutto il codice che lo compone viene eseguito in ambiente potenzialmente ostile. I sistemi pi sicuri sono quelli che in parte risiedono su un server remoto.


Ovvero ????
Se l'utente finale ha la possibilit di sovrascrivere la dll il sistema fallito in partenza, cos come se lui il proprietario del processo in cui viene eseguito il programma (=lo avvia lui, non un processo eseguito da un altro utente, di conseguenza ci pu attaccare un debugger con cui mettere in pausa il processo, modificare al volo il codice della dll in memoria e far ripartire il tutto). Se poi l'utente finale l'amministratore della macchina...

Loading