Hi!
Also ich wollte meine Dll in mein Programm mit einkompilieren.
Ich habe dies letzendlich als Ressource gelöst, allerdings wollte ich sie ursprünglich so mit einkompilieren, dass man es auf den ersten Blick mit Reshack etc. nicht sehen kann.
Meine Idee dabei war folgende: Die Dll in einen langen Hexcode umwandeln und diesen langen String in meinen Quellcode kopieren.
Zur Laufzeit sollte dann dieser Hexcode per Memorystream auf die Festplatte geschrieben werden und da wäre meine Dll wieder.
Irgendwie reizt es mich jetzt doch noch das ganze mal hinzubekommen
Ich habe mir dafür den HexLoader Code von Michael Puff angesehen, allerdings habe ich es nicht hinbekommen den Hexcode wieder zurück in eine Binärdatei umzuwandeln
Ich habe es nicht hinbekommen, aber wäre dies theoretisch möglich, oder habe ich da schon vom Ansatz her einen Denkfehler?

Hex, Binär, Dual, Dezimal, ... , alles liegt im Grunde im selben Format vor, nämlich als Nullen und Einsen (also Binär). Es kommt halt nur darauf an, wie diese Informationen interpretiert werden.

Was Du benötigst wäre eine Verschlüsselung.

Das Problem ist ja nur, dass der String oder in welchem Typ das ganze auch immer vorliegt Binär ja viel länger ist als z.B. in Hex.
Die Verschlüsselung könnte man ja leicht umsetzen, einfach den String bevor man ihn in den Quellcode einfügt mit rc4 oder xor verschlüsseln.
Vermute ich zumindest mal
Mir geht es mehr darum ob dies überhaupt möglich ist, weil es mir nicht gelungen ist und es wäre für mich ärgerlich stundenlang daran zu arbeiten um dann festzustellen, dass ich einen Denkfehler hatte

Hat wirklich niemand eine Ahnung ob das funktionieren würde?
Ich meine einen String wie "4D5A90000300000004004D5A9000030000000400000000004 000000000000" in den Quellcode einfügen und später wieder in eine funktionierende Dll umzuwandeln?

Du kannst auch einfach die DLL so wie sie ist als Ressource mit einkompilieren und dann zur Runtime wieder in eine Datei streamen. Wenn es dir zusätzlich auch darum geht den Teil nicht (auf den ersten Blick) als DLL erkennbar zu machen, dann wie schon erwähnt verschlüsseln. Aber je nach dem wie offensichtlich du den Verschlüssler implementierst, ist auch das dann mit ein wenig Disassemblierung zu machen. Als Hex-String wäre es ja noch viel viel einfacher.

Wenn es unbedingt ein String sein soll, wie wäre es mit Base64? Aber achtung: Das Literal dass du bekämst ist wahrscheinlich sehr lang - zu lang um es am Stück hinzuschreiben, da hat der Delphi-Compiler ne Grenze. Du musst dann im Source mehrere Stringliterale aneinanderketten ('bla' + 'blubb' + 'moah' ...).

Ja, ich habe es letztendlich ja als Ressource gelöst
Allerdings würde es mich schon reizen meine Idee mal in die Tat umzusetzen.
Das sollte ja, wenn ich das ganze richtig verstanden habe möglich sein!
Oder würde es Probleme geben bezüglich der "#0" beim auslesen in Hexcode?

Zitat von Aljoscha:

Probleme geben bezüglich der "#0"

Als Hex oder Base64 nicht, da hier ein Byte mit Wert 0 ja in darstellbare Zeichen gecoded wird. Bei Hex halt in '00', und '0' ist ungleich chr(0). (Es ist chr(48).)

Also irgendwie komme ich nicht weiter...
Der Stream ist nach dem Codieren und Dekodieren mit den Funktionen der Base64.pas von Daniel Wischnewski 4 Bytes größer als vorher und die Datei entsprechend unbrauchbar.
Ich habe zu testzwecken den Windows-Taschenrechner calc.exe verwendet.
Größe vor dem Codieren: 114688 Byte, Größe nach dem Dekodieren: 114692 Byte.
Das Problem habe ich mit jeder Datei...

zusammenfalten · markieren

Delphi-Quellcode:

function MemoryStreamToStr(const MemoryStream: TMemoryStream): string;
var
  StringStream: TStringStream;
begin
  StringStream := TStringStream.Create('');
  try
    StringStream.CopyFrom(MemoryStream, MemoryStream.Size);
    Result := StringStream.DataString;
  finally
    StringStream.Free;
  end;
end;

procedure StringToStream(aStr : String; MemoryStream: TMemoryStream);
var
   aStrLen : Integer;
begin
  aStrLen:=Length(aStr);
  MemoryStream.WriteBuffer(aStrLen,SizeOf(Integer));
  MemoryStream.WriteBuffer(Pointer(aStr)^,aStrLen);
end;

procedure TForm1.Button1Click(Sender: TObject);
var
ms:TMemoryStream;
temp: AnsiString;
begin
//MemoryStream erstellen
ms:=TMemoryStream.Create;
ms.LoadFromFile('./calc.exe');

//Größe des Streams ausgeben
ShowMessage( IntToStr(ms.Size) );

//Stream in String speichern
temp:=MemoryStreamToStr(ms);

//Stream freigeben
ms.Free;

//String Codieren
temp:=Base64Encode(temp);

//Testweise String ausgeben
Memo1.Text:=temp;

//String Decodieren
temp:=Base64Decode(temp);

//MemoryStream erstellen
ms:=TMemoryStream.Create;

//String in Stream speichern
StringToStream(temp,ms);

//Ausgeben Streamgröße nach Codieren und Decodieren
ShowMessage( IntToStr(ms.Size) );

//Stream in Datei speichern
ms.SaveToFile('./calc2.exe');
end;

Ich habe sowas noch nicht probiert, aber es klingt eigentlich nicht sehr schwierig.

Wie würde ich es machen?

Die DLL in einen Stream laden. Diesen Stream byteweise auslesen und jedes Byte (das ja eine Wert zwischen 0 und 255 annehmen kann) in die zwei Zeichen von "00" bis "FF" umkodieren (Wie das am einfachsten geht findet sich sicher hier im Forum). Das führt letztendlich dazu, dass der String doppelt so lang ist wie die ursprüngliche DLL (Bytelänge). Umgekehrt gehts genauso. Den String vom Anfang an, immer zwei Zeichen, wieder in einen Wert umwandeln und byteweise in der Stream schreiben.

edit: Habs in den Indys gefunden..

markieren

Delphi-Quellcode:

IdHexDigits: array [0..15] of AnsiChar = '0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F');

function ByteToHex(const AByte: Byte): string;
begin
  Result := IdHexDigits[AByte shr 4] + IdHexDigits[AByte and $F];
end;

Vielen Dank für die Antwort!
Das werde ich auch noch probieren, aber jetzt würde ich gerne erstmal den Fehler bei der Base64-codierung finden
Ich habe immernoch nicht herausgefunden, warum es am Ende 4 Bytes mehr sind