Entschlüsselung von D7 auf D10.2 Tokyo portieren

[Poelser]

Moin zusammen!

Ich habe einen Teil einer alten Anwendung in D7 auf D10.2 Tokyo zu portieren. Dabei geht es, den alten Sourcen nach, um eine AES-Verschlüsselung nach Rijndael. Genaueres steht da leider nicht drin, der ursprüngliche Entwickler kann nicht mehr befragt werden.
Diesen Teil habe ich erfolgreich nach Lazarus 2.0.10 portiert. Damit kann ich Strings, die aus einer DB kommen, entschlüsseln. Aber dieser Mechanismus von Lazarus nach Tokyo portiert funzt nicht .

Das ist gegeben:

Delphi-Quellcode:

const
  LocalCryptval=12345;
type
  Str2=String[2];

Jetzt kommt hier noch einiges an Funktionen, u.a. auch Assembler-Code. Wie gesagt - mit Lazarus funktioniert es, aber

Delphi-Quellcode:

class function TTools_Crypt.HexToByte(b: Str2): Byte;
begin
  while Length(b)<2 do b:='0'+b;
  Result:=HexToNibble(b[1]) shl 4 + HexToNibble(b[2]);
end;

class function TTools_Crypt.HexToNibble(n: Char): Byte;
const
  HexNib: Array[0..$F] of Char=
    ('0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F');
var
  i: Byte;
begin
 Result:=0;
 for i:=0 to $F do
   if UpCase(n)=HexNib[i] then Result:=i;
end;

compiliert und funktioniert in Lazarus einwandfrei. Delphi aber meckert hier

[dcc32 Fehler] Tools.pas(281): E2010 Inkompatible Typen: 'Char' und 'AnsiChar'

für b[1] und b[2]. Mache ich einen Typecast
  Result:=HexToNibble(char(b[1])) shl 4 + HexToNibble(Char(b[2])); compiliert das zwar, die Entschlüsselung liefert dann aber ein falsches Ergebnis (irgendwelche chinesischen Zeichen) zurück.

Wie setze ich das dann richtig um, damit auch Delphi das korrekt macht?

LG aus dem Norden, Edmund

[mkinzler]

Shortstrings sind AnsiChar.

Delphi-Quellcode:

class function TTools_Crypt.HexToNibble(n: AnsiChar): Byte;
const
  HexNib: Array[0..$F] of AnsiChar=...

[himitsu]

Jupp, mit Delphi 2009 wurden Char, PChar und String aus Unicode geändert.
Der Typ String[x] und ShortString war und ist weiterhin ein ShortString (ein Record aus AnsiChars mit Längenbyte im Char[0]) ... im/bis Delphi 1 war das mal der Typ "String".

Bei Lazarus/FreePascal mußt du dagegen aufpassen, denn dort sind die verwendeten String-Typen teilweise UTF-8.
Mit AnsiChar/PAnsiChar/AnsiString sollte aber in Lararus und Delphi hier kein Problem geben.


PS: Sowas ist auch der Grund, warum man keine dynamischen Typen und Funktionen verwenden sollte, wenn es um "externe" Daten geht.
Char/PChar/String hängen vom Compiler ab. Früher hing auch mal Integer/Cardinal davon ab, aber bei 64 Bit wurden die eingefroren und jetzt heißt der compilerabhängige Typ im Delphi NativeInt und NativeUInt.


Ach ja, das Suchen in HexToNibble ist etwas ... naja.
Das kann man auch ohne Schleife machen, entweder matematisch (Zuffern und Buchstaben sind jeweils in fortlaufenden Bereichen)
oder über Maps. (siehe B2HConvert und H2BConvert in System.Classes)

[Poelser]

Danke,

Zitat von mkinzler:

Shortstrings sind AnsiChar.

Delphi-Quellcode:

class function TTools_Crypt.HexToNibble(n: AnsiChar): Byte;
const
  HexNib: Array[0..$F] of AnsiChar=...

das compiliert jetzt mit Tokyo und Lazarus identisch, allerdings ist die Entschlüsselung mit Tokyo noch nicht korrekt. Aber das kann durchaus noch eine andere Ursache haben, schau'n mer mal...

LG aus dem Norden, Edmund

[Poelser]

Funktioniert zwar immer noch nicht, aber ich bin ja nun einen Schritt weiter. Die Umstellung auf AnsiChar funktioniert jetzt mit Tokyo und Lazarus identisch.

Was nicht funktioniert, ist diese Funktion:

Delphi-Quellcode:

class procedure TTools_Crypt.CryptByte(var aByte: Byte; var CV: Word);
var
  rBX, rDX: Word;
  i: Byte;
  rBL: Byte absolute rBX;
begin
  rBX:=CV;
  for i:=1 to 8 do
  begin
    rDX:=rBX;
    rDX:=rDX shl 1;
    asm
      mov AX, rDX
      shr AL, 1
      xor AL, AH
      mov rDX, AX
    end;
    rBX:=rBX shl 1;
    asm
      mov AX, rDX
      rcr AX, 1
      mov rDX, AX
      mov AX, rBX
      rcr AX, 1
      mov rBX, AX
    end;
    rBX:=rBX shr 1;
  end;
  aByte:=aByte xor rBL;
  CV:=rBX;
end;

Vorher wird mit all den anderen Funktionen ein (verschlüsselter) String in einen Puffer geschrieben. In diesem Puffer wird Byte für Byte entschlüsselt, in CV kommt der Schlüssel rein (das was in Const Cryptval steht). Dieser Puffer wird anschliessend in den String zurückgeschrieben.

Nur zur Erinnerung: Ursprünglich funktioniert das mit D7, und auch im aktuellen Lazarus kein Problem (Lazarus braucht zusätzlich nur {$ASMMODE intel}).

Aber in Tokyo kann ich im Debugger sehen, dass im Puffer was anderes erzeugt wird, und dieser falsche Kram landet im String.

Damit ergibt sich die Frage, warum verhält sich Tokyo hier anders als Lazarus und D7?
Was muss ich ändern, gibt es hier vielleicht noch einen Compilerschalter, den mir Google nicht rausrückt? Ich verstehe von Intel-Assembler leider zu wenig
Oder gibt's in Tokyo hier 'nen Bug?

[Klaus01]

.. hast Du Deine String Parameter auch in AnsiString umbenamst?

Grüße
Klaus

[Poelser]

Zitat von Klaus01:

.. hast Du Deine String Parameter auch in AnsiString umbenamst?

Danke, das war der entscheidende Hinweis!

Die Firebird-DB ist mit ISO 8859-1 kodiert, nicht mit UTF8 oder so. Die gecrypteten Felder lese ich nun mit Ansistring(myCryptedFieldStr), und schon geht's!

LG aus dem Norden, Edmund