DCPCrypt in RAD Studio 10.3/10.4

[amigage]

Hallo,

ich verwendete bisher in RAD Studio 10.1 zum Verschlüsseln von Daten in Dateien die DCPCrypt Komponente V2.0 von David Barton.
Dabei nutzte ich die Funktionen EncryptCFB8Bit() zum Verschlüsseln von Informationen und Base64EncodeStr() um die Daten im Base64-Format zu schreiben.
Zum Auslesen nutzte ich Base64DecodeStr() und DecryptCFB8Bit() .
Kompiliert wurde eine 32 und eine 64 Bit Version meines Programms.

Nun wollte ich dieses Projekt auf 10.4 bringen und erhalte beim Kompilieren einen Debugger-Fehler.
Daraufhin habe ich die DCPCrypt Komponente V2.1 installiert, die bereits schon seit Jahren auf Unicode umgestellt wurde.
Der Debugger steigt auch nicht mehr aus.

Aber hier habe ich das Problem, dass ich die "alten" Dateien nicht mehr lesen kann, da Sie falsch entschüsselt werden.
Ich vermute, weil jetzt die bedingte Kompilierung {$IFDEF UNICODE} automatisch aktiviert ist und das Programm in die Dekodierung des Unicodeformats springt.

Delphi-Quellcode:

function Base64DecodeStr(const Value: AnsiString): AnsiString;
begin
{$IFDEF NEXTGEN}
  Result.SetLength((AnsiLength(Value) div 4) * 3);
  Result.SetLength(Base64Decode(@Value.GetBuffer[0],@Result.GetBuffer[0],AnsiLength(Value)));
{$ELSE}
  SetLength(Result,(Length(Value) div 4) * 3);
  SetLength(Result,Base64Decode(@Value[1],@Result[1],Length(Value)));
{$ENDIF}
end;

{$IFDEF UNICODE}
function Base64DecodeStr(const Value: UnicodeString): UnicodeString;
var
  temp: AnsiString;
begin
  temp:= AnsiString(Value);
{$IFDEF NEXTGEN}
  SetLength(Result,(AnsiLength(temp) div 4) * 3);
  SetLength(Result,Base64Decode(@temp.GetBuffer[0],@Result[1],AnsiLength(temp)) div SizeOf(Result[1]));
{$ELSE}
  SetLength(Result,(Length(temp) div 4) * 3);
  SetLength(Result,Base64Decode(@temp[1],@Result[1],Length(temp)) div SizeOf(Result[1]));
{$ENDIF}
end;
{$ENDIF}

Kann man diese UNICODE Standardeinstellung temporär umgehen, so dass ich die alten Daten noch entsprechend ausgelesen bekomme?

Vielen Dank für eure Bemühungen und Tipps.

[hoika]

Hallo,
ich sehe ja den Interface-Teil nicht, aber

function Base64DecodeStr(const Value: AnsiString): AnsiString;
function Base64DecodeStr(const Value: UnicodeString): UnicodeString;

Kann es sein, dass die Methode überladen ist?
Dann solltest Du als Parameter einen AnsiString und nicht einen normalen String übergeben.

[amigage]

Danke für die schnelle Antwort.
Hier ist der interface Teil.

Delphi-Quellcode:

uses
  {$ifdef NEXTGEN_FIXES}
    ORawByteString,
  {$endif}
     Sysutils;

function Base64EncodeStr(const Value: AnsiString): AnsiString; overload;
  { Encode a string into Base64 format }
function Base64DecodeStr(const Value: AnsiString): AnsiString; overload;
  { Decode a Base64 format string }
{$IFDEF UNICODE}
function Base64EncodeStr(const Value: UnicodeString): UnicodeString; overload;
  { Encode a Unicode string into Base64 format }
function Base64DecodeStr(const Value: UnicodeString): UnicodeString; overload;
  { Decode a Base64 format Unicode string }
{$ENDIF}
function Base64Encode(pInput: pointer; pOutput: pointer; Size: longint): longint;
  { Encode a lump of raw data (output is (4/3) times bigger than input) }
function Base64Decode(pInput: pointer; pOutput: pointer; Size: longint): longint;
  { Decode a lump of raw data }

[hoika]

Hallo,
dann siehe mein Post davor. (AnsiString benutzen)

[Codehunter]

Und eine Form von Versionskennung in deinem Dateiformat kann auch nicht schaden. Damit du in Zukunft unterscheiden kannst ob du es mit neuerem Unicode zu tun hast oder nicht.

[amigage]

Leider hilft auch der Typecast nicht. Das Programm ruft dann zwar die korrekte Base64 Dekodierung auf. Aber die zurückgegebene Zeichenkette ist nur halb korrekt.

Als Beispiel nehmen wir die Zeichenkette "Ein kleines Beispiel".
Die vor Jahren erstellte base64 Zeichenfolge lautet: wkzVX952oBvST6gg4kFA18IaSGsEjjc=
Will ich diese jetzt wieder mit dem richtigen Passwort dekodieren, erhalte ich z.B. nur: BÝ9ý–éžÏÕnes Beispiel"

Woran könnte es noch liegen?

Was ich vergaß, zu erwähnen: bei einer 32Bit Kompilierung unter 10.3/10.4 funktionierte die alte Version 2.0 noch tadellos. Nur bei einer 64 Bit Kompilierung stieg der Debugger mit einer Fehlermeldung aus. Was könnte der Grund dafür sein?

[Achim Kalwa]

Wenn ich Deinen Base64-String mit einem Online-Decoder decodiere, kommt eine Folge von Bytes heraus, die ich hier mal als Hex-Zahlen darstelle:

c2 4c d5 5f de 76 a0 1b d2 4f a8 20 e2 41 40 d7 c2 1a 48 6b 04 8e 37

Das ist also kein Klartext mit ASCII- oder ANSI-Zeichen, sondern eine Byte-Folge.
Damit es nicht zu einer ungewollten Unicode-Konvertierung der Nicht-ASCII-Zeichen kommt, musst Du einen Datentyp verwenden, der Bytes speichert und nicht (Ansi/Wide-)Char.

Versuche mal, das Ergebnis von Base64DecodeStr() in einer Variable vom Typ RawByteString zu speichern. Diesen "String" übergibst Du dann an DCPCrypt zum entschlüsseln. Falls Das von Dir gewählte Password Umlaute oder andere Nicht-ASCII-Zeichen enthält, bekommst Du aber ein weiteres Problem...

HTH
Achim

[amigage]

Vielen Dank für die Vorschläge.

Ich habe weitere Tests durchgeführt und kann sagen, dass es nicht an der Base64DecodeStr() Funktion liegt. Diese gibt bei beiden Versionen (2.0 und 2.1) den gleichen RawByteString zurück.
Es liegt also an den DecryptCFB8Bit() Funktionen der Verschlüsselungsarten, respektive EncryptECB() .

Denn hier wurden folgende Änderungen vorgenommen:

In der DCPCrypt2.pas wurden allgemein folgende Datentypen eingeführt:

Delphi-Quellcode:

type

{$IF CompilerVersion >= 23}
{$DEFINE DELPHIXE2_UP}
{$IFEND}
{$IFNDEF DELPHIXE2_UP}
   NativeInt = {$IFDEF WIN64} int64 {$ELSE} Longint {$ENDIF};
{$ENDIF}
   PointerToInt = {$IFDEF DELPHIXE2_UP} Pbyte {$ELSE} NativeInt {$ENDIF};

In den verschiedenen Verschlüsselungsarten wurden folgende Änderungen vorgenommen, z.B. TwoFish.pas:

V2.0

Delphi-Quellcode:

  x[1]:= PDWord(longword(@InData)+4)^ xor SubKeys[INPUTWHITEN+1];
  x[2]:= PDWord(longword(@InData)+8)^ xor SubKeys[INPUTWHITEN+2];
  x[3]:= PDWord(longword(@InData)+12)^ xor SubKeys[INPUTWHITEN+3];

V2.1

Delphi-Quellcode:

  x[1]:= PDWord(PointerToInt(@InData)+4)^ xor SubKeys[INPUTWHITEN+1];
  x[2]:= PDWord(PointerToInt(@InData)+8)^ xor SubKeys[INPUTWHITEN+2];
  x[3]:= PDWord(PointerToInt(@InData)+12)^ xor SubKeys[INPUTWHITEN+3];

Longword (Alias für Cardinal - ist 32 Bit auf allen 64-Bit- und 32-Bit-Plattformen.) wurde durch PointerToInt (PByte repräsentiert einen Zeiger auf Byte) ersetzt.

Es sieht wohl so aus, dass ich wohl die alten Daten nicht mehr auslesen kann. Hier scheint es wohl bei einer 64Bit Kompilierung keine Rückwärtskompatibilität zu geben, was natürlich in so einem Fall fatal ist.

[TurboMagic]

Schon Mal versucht den Verschlüsselungsalgorithmus mit DEC (Delphi Encryption Compendium) umzusetzen?

Davon den aktuellen Development Branche nutzen.
Sollte den Verschlüsselungsalgorithmus, Base64 und den angegebenen Blockverkettungsalgorithmus unterstützen.

[amigage]

Vielen Dank für den Tipp, ich werde es mir einmal anschauen.