[C++] Funzione per digest MD5 da restituire a VB.NET

[Antonyy74]

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 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]

cancellato

[Antonyy74]

Originariamente inviato da MacApp
cancellato

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]

Ma perché non puoi fare il confronto direttamente dentro all'applicazione VB.NET? O è un progetto "di prova"?

[Antonyy74]

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]

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]

Allora maschero il mio digest, metto tra i caratteri altri caratteri che non fanno parte del digest e poi estraggo la stringa corretta ?????

[MItaly]

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 ?????

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]

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]

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...