DEC 5.2 Fehler unter Delphi 2009 (?)

[ULIK]

Hallo,

ich bin gerade auf das folgende Problem gestoßen: Eine Logik, die unter Delphi 2007 funktioniert liefert unter Delphi 2009 falsche Ergebnisse. Hier der Code der Unit-Tests (DEC5_xyz bezeichnet die Unit xyz aus DEC 5.2)

Delphi-Quellcode:

procedure TTestgoDecUnitHashes.TestHashHEX;
var
  strResultV3: ANSIString;
  strResultV5: ANSIString;
  cResult: Cardinal;
begin
  // FText (:ANSIString) := 'This is a confidential ANSI Text';
  strResultV3 := '03BEBC72'; //Hash.THash_CRC32.CalcString(FText, nil, fmtHEX);

  cResult := DEC5_CRC.CRCCalc(CRC_32CCITT, PAnsiChar(FText)^, Length(FText));
  strResultV5 := DEC5_DECFmt.TFormat_HEX.Encode(cResult, 4);

  CheckEqualsString(strResultV3, strResultV5);
end;

procedure TTestgoDecUnitHashes.TestHashHEX_new;
var
  strResultV3: ANSIString;
  strResultV5: ANSIString;
  cResult: Cardinal;
  objCRCDef: DEC5_CRC.TCRCDef;
  strKey: ANSIString;
  cVector: Cardinal;
begin
  // FText (:ANSIString) := 'This is a confidential ANSI Text';
  strResultV3 := '03BEBC72'; //Hash.THash_CRC32.CalcString(FText, nil, fmtHEX);

  DEC5_CRC.CRCSetup(objCRCDef, $04C11DB7, 32, $FFFFFFFF, $FFFFFFFF, True);
  DEC5_CRC.CRCCode(objCRCDef, PAnsiCHar(FText)^, Length(FText));
  cResult := DEC5_CRC.CRCDone(objCRCDef);

  strResultV5 := DEC5_DECFmt.TFormat_HEX.Encode(cResult, 4);

  CheckEqualsString(strResultV3, strResultV5);
end;

Die beiden obigen Unit-Tests laufen durch, wenn sie unter Delphi 2007 kompiliert werden. Unter Delphi 2009 jedoch schlägt der erste Test fehl. Das Problem dürfte darin liegen, daß der Hash im ersten Fall mit CRCInit initialisiert wird (aufgerufen von CRCCalc), was bei mir unter Delphi 2009 komische Werte liefert. Bug oder Feature?

Grüße,
Uli

[Assertor]

Hi Uli,

bei mir liefert TestHashHEX 03BEBC72 mit DEC 5.2 und D2009.

Übrigens: Glückwunsch zum "Lösen" der Probleme im anderen Thread.

Vielleicht ein Problem mit CheckEqual?

Getestet per

Delphi-Quellcode:

procedure TestHashHEX;
  var
    strResultV3: ANSIString;
    strResultV5: ANSIString;
    cResult: Cardinal;
    FText: AnsiString;
  begin
    FText := 'This is a confidential ANSI Text';
    strResultV3 := '03BEBC72'; //Hash.THash_CRC32.CalcString(FText, nil, fmtHEX);

    cResult := CRCCalc(CRC_32CCITT, PAnsiChar(FText)^, Length(FText));
    strResultV5 := TFormat_HEX.Encode(cResult, 4);

    Memo1.Lines.Add(strResultV3);
    Memo1.Lines.Add(strResultV5);
  end;

und einem einfachen Memo.

Nachtrag: CheckEqualsString hat keine überladene Funktion für AnsiString. Vielleicht liegt hier irgendwo das Problem. Schreibt Dir selbst mal ein Overload dafür.

Ein einfaches

Delphi-Quellcode:

  if strResultv3 = strResultV5 then
      Memo1.Lines.Add('jup');

gibt mir jedenfalls in obigem Testcase ebenfalls das gewünschte "jup" aus.

Edit2:
Bei der Umstellung war ich doch nicht nachlässig: Ich habe gegen jeden Cipher, Hash und das Text-Encoding Vergleichstests gefahren. Teilweise automatisch (aus Part_I\DECTest) und auch manuell mit Testvektoren und Monte-Carlo-Tests (z.B. bei Rijndael mit Vorgaben vom NIST).

Anbei mal die Ergebnisliste aus dem DECTest. Die ist aber auch im DEC 5.2 mit dabei und mit D2009 erstellt.

Gruß Assertor

[ULIK]

Hi Assertor,
bei mir liefert dein Code keine Gleichheit (auch nicht in der IDE beim Debuggen). Vieleicht hab ich nur nicht die aktuellste Version des DEC 5.2 (meine Units sind alle vom 02.11.08 ). Kannst Du mir dafür einen Downloadlink geben?

Ergänzung: bei wird immer 'FFFFFF1F' als Ergebnis geliefert

Grüße,
Uli

[Assertor]

Hi Uli,

das Datum stimmt, aber trotzdem hier der Download-Link (bei Luckie): dec.michael-puff.de.

Probier mal das Problem zu isolieren, Du stehst wahrscheinlich voll im Testcase. Nimm mal ein leeres Form mit den DEC Units und einem Memo und teste Dein bzw. mein obiges Beispiel.

Ich schätze da fährt irgendeine Projekt-Einstellung oder Unit dazwischen.

Nachtrag (roter Kasten):

Problem nachvollziehbar:
DEC 5.2 mit D2009 und FastMM4 4.92 als Release-Build: ok
DEC 5.2 mit D2009 und FastMM4 4.92 als Debug-Build: FFFFFF1F (nur bei CRC, nicht den eigentlichen DEC Units)

Ich isolier das mal kurz, ob es ein FastMM4 oder an den Projekt-Optionen liegt.

Kannst Du das eben mal für DEC 5.x mit D2007 gegentesten, also Debugbuild und Releasebuild?

Gruß Assertor

[ULIK]

Hi,

Stimmt, Du hast recht: Delphi 2009 und Release Build und alles ist gut, Debug Build und es geht schief. Unter Delphi 2007 macht es keinen Unterschied, da gehen beide Versionen.

Grüße,
Uli

[Assertor]

Hi,

liegt an "Optimierung" in den Projektoptionen. Wenn die aus ist, geht es nicht - also kein Problem mit FastMM4.

Das wär also das einzige, was Du mal in D2007 prüfen könntest. CRC mit Projektoption Optimierung an und aus.

Die Sache hat nichts mit den DEC Hash/Format/Cipher Units zu tun. Die CRCCalc ist aus der CRC.pas und diese nutzt keinerlei Strings. Das ist so ziemlich die einzige Datei, die ich zu 100% übernehmen konnte.

Quick-and-Dirty-Workaround ist, im Header der Unit CRC.pas Optimization anzuschalten:

Delphi-Quellcode:

unit CRC;

{$OPTIMIZATION ON}
{$I VER.INC}
...

[Assertor]

Ok,

danke fürs Testen in D2007. Damit Du auch benachrichtigt wirst ein neuer Eintrag, kein Edit :)

Es betrifft die CRC_32CCITT, nicht z.B. CRC_32.

cResult := CRCCalc(CRC_32, PAnsiChar(FText)^, Length(FText));

liefert mit/ohne Optimization immer C1271A8C.

Also schau ich mir CRC_32CCITT mal an.

Gruß Assertor

[ULIK]

Oh Mann, darauf muß man erst mal kommen! :? Unter Delphi 2007 macht's übrigens keinen Unterschied, ob die Optimierung an oder aus ist.

Vielen Dank für deine Hilfe!
Uli

[Assertor]

Zitat:

Zitat von ULIK

Oh Mann, darauf muß man erst mal kommen!

Sind wir doch :)

Zitat:

Zitat von ULIK

Unter Delphi 2007 macht's übrigens keinen Unterschied, ob die Optimierung an oder aus ist.

Ok und Danke für das Prüfen.

Zitat:

Zitat von ULIK

Vielen Dank für deine Hilfe!

Gerne!

Ich prüf gerade mal etwas rum, ich vermute die CRC Init muß genutzt werden. Sobald ich was hab, poste ich hier. Kann natürlich auch ein besonderes Compiler/Linker-Verhalten von D2009 sein (muß mal im QC schauen).

Gruß Assertor

[ULIK]

Jup, soweit ich gesehen hab unterscheiden sich die Werte vom CRC nach Aufruf CRCInit (in CRCCalc). Da wird die Lookup-Tabelle nicht gefüllt.

Grüße,
Uli

[Assertor]

Zitat:

Zitat von ULIK

Jup, soweit ich gesehen hab unterscheiden sich die Werte vom CRC nach Aufruf CRCInit (in CRCCalc). Da wird die Lookup-Tabelle nicht gefüllt.

Richtig, dabei hat Hagen da schon extra Code drin für den Optimization-Fall. :?: Mal sehen, das bekommen wir hin. Das ist dann aber eher ein D2009 Problem als ein DEC Problem (wie gesagt, die Unit ist ja hauptsächlich ASM und arbeitet ohne String und wurde nicht geändert).

Gruß Assertor

[Assertor]

Lösung ist, die gesamte CRCInit() in eine Zwang-Optimierung zu setzen, anstatt nur die CRCTab:

Delphi-Quellcode:

{$IFOPT O-}{$O+}{$DEFINE NoOpt}{$ENDIF}
function CRCInit(var CRCDef: TCRCDef; CRCType: TCRCType): Boolean; register;
type
  PCRCTab = ^TCRCTab;
  TCRCTab = array[TCRCType] of packed record
    Poly,Bits,Init,FInit: Cardinal;
    Inverse: LongBool;
  end;

  procedure CRCTab;
  asm
    //    Polynom   Bits InitVec    FinitVec   Inverse
    DD    $000000D1,  8, $00000000, $00000000, -1   // CRC_8  GSM/ERR
    DD    $00000233, 10, $00000000, $00000000, -1   // CRC_10 ATM/OAM Cell
    DD    $0000080F, 12, $00000000, $00000000, -1   // CRC_12
    DD    $00008005, 16, $00000000, $00000000, -1   // CRC_16 ARC,IBM
    DD    $00001021, 16, $00001D0F, $00000000,  0   // CRC_16 CCITT ITU
    DD    $00008408, 16, $00000000, $00000000, -1   // CRC_16 XModem
    DD    $00864CFB, 24, $00B704CE, $00000000,  0   // CRC_24
    DD    $9DB11213, 32, $FFFFFFFF, $FFFFFFFF, -1   // CRC_32
    DD    $04C11DB7, 32, $FFFFFFFF, $FFFFFFFF, -1   // CRC_32CCITT
    DD    $04C11DB7, 32, $FFFFFFFF, $00000000, -1   // CRC_32ZModem

    // some other CRC's, not all yet verfied
    // DD    $00000007,  8, $00000000, $00000000, -1   // CRC_8  ATM/HEC
    // DD    $00000007,  8, $00000000, $00000000,  0   // CRC_8 the SMBus Working Group
    // DD    $00004599, 15, $00000000, $00000000, -1   // CRC_15 CANBus
    // DD    $00001021, 16, $00000000, $00000000,  0   // CRC_16ZModem
    // DD    $00001021, 16, $0000FFFF, $00000000,  0   // CRC_16 CCITT British Aerospace
    // DD    $00004003, 16, $00000000, $00000000, -1   // CRC_16 reversed
    // DD    $00001005, 16, $00000000, $00000000, -1   // CRC_16 X25
    // DD    $00000053, 16, $00000000, $00000000, -1   // BasicCard 16Bit CRC (sparse poly for Crypto MCU)
    // DD    $000000C5, 32, $00000000, $00000000, -1   // BasicCard 32Bit CRC
  end;

begin
  with PCRCTab(@CRCTab)[CRCType] do
    Result := CRCSetup(CRCDef, Poly, Bits, Init, FInit, Inverse);
end;
{$IFDEF NoOpt}{$O-}{$ENDIF}

Dann geht es immmer. Sehr gediegenes Verhalten der Optimization, aber naja...

Gruß Assertor

[ULIK]

Super! Funktioniert und es gibt einen glücklichen Menschen mehr! :xmas:

Grüße,
Uli

[Assertor]

Zitat:

Zitat von ULIK

Super! Funktioniert und es gibt einen glücklichen Menschen mehr! :xmas:

Super! Dann nehm ich das gleich in das Package auf und mail es Luckie :)

:xmas: Und falls man vorher nicht mehr von einander liest: Ich wünsche ein frohes Weihnachtsfest und erholsame Feiertage! :xmas:

Gruß Assertor

[ULIK]

Wünsch ich ebenso!

Uli :xmas:

[negaH]

Jaja, so ist das mit den krummen Tricks der Programmierer. Die "Procedure" CRCTab ist ja nichts anderes als eine Datentabelle die im Codesegment der Anwendung liegen soll (Zugriffsrechte etc.pp). Normalerweise hätte man auch ein normales konstantes Array[] im Datensegment ablegen können und diese Probleme mit der unvorhersagberen Resultaten der Optimierungen des Compilers hätten keinerlei Auswirkungen gehabt.

Es scheint also so zu sein das lokale Compilerswitches je nach Delphi Version unterschiedlich behandelt werden, was ja auch nicht so sein sollte, wegens Abwärtskompatibilität.

Gruß Hagen

[Luckie]

Die aktuelle Version mit dem Bugfix ist auch auf meiner Seite zu haben: http://dec.michael-puff.de

[Assertor]

Hi,

@Luckie: Danke :)

Zitat:

Zitat von negaH

Jaja, so ist das mit den krummen Tricks der Programmierer. Die "Procedure" CRCTab ist ja nichts anderes als eine Datentabelle die im Codesegment der Anwendung liegen soll (Zugriffsrechte etc.pp). Normalerweise hätte man auch ein normales konstantes Array[] im Datensegment ablegen können und diese Probleme mit der unvorhersagberen Resultaten der Optimierungen des Compilers hätten keinerlei Auswirkungen gehabt.

Es scheint also so zu sein das lokale Compilerswitches je nach Delphi Version unterschiedlich behandelt werden, was ja auch nicht so sein sollte, wegens Abwärtskompatibilität.

Richtig, Du *Trickser* ;) Wär es jetzt in einem ASM inline passiert, wo irgendwo mit Chars bzw. einer festen Länge für selbige hantiert wird, hätte ich es ja noch verstanden, aber bei einem einfachen Befüllen per DD ist das schon merkwürdig. Das mit dem Array hatte ich mir gestern auch überlegt.

Ein neues D2009 Feature: Code wird wegoptimiert, wenn die Optimierung aus ist.

Gruß Assertor

[negaH]

naja der Grundgedanke dabei war ja alles im CS abzulegen. Und benutzt man die zwei preinitialisierenden CRC Funktionen nicht so benötigt die gesammte CRC Unit ausschließlich nur das Codesegement. Da das CS unter Win strengeren Zugriffsrechten unterliegt und die CRC.pas im kryptographischen Kontext eine wichtige Unit zur Überprüfung der anderen Units darstellt, dachte ich mir das diese wichtigen Initialisierungsdaten im CS am besten aufgehoben wären. Ich weiß das dies nur eine kleine Hürde für einen gewillten Angreifer darstellt. Fazit: Aufwand & Nutzen stimmt nicht mehr wenn man die inkompatibilitäten durch Borland mit berücksichtigt.

Gruß Hagen

PS: aus dieser Sicht ärgere ich mich ja über mich selbst.