Delphi-PRAXiS
Seite 4 von 9   « Erste     234 56     Letzte »    

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Software-Projekte der Mitglieder (https://www.delphipraxis.net/26-software-projekte-der-mitglieder/)
-   -   VerschlüsselungsProgramm (https://www.delphipraxis.net/11391-verschluesselungsprogramm.html)

Luckie 21. Jul 2004 18:48

Re: VerschlüsselungsProgramm
 
Ich bekomme hier immer einen Integer Overflow:
Delphi-Quellcode:
procedure RC4Init(var RC4: TRC4Context; const Key: String);
var
  R,S,T,K: Byte;
  U,L: Integer;
begin
  L := Length(Key);
  with RC4 do
  begin
    I := 0;
    J := 0;
    for S := 0 to 255 do D[S] := S;
    R := 0;
    U := 0;
    for S := 0 to 255 do
    begin
      if U < L then K := PByteArray(Key)[U] else K := 0;
      Inc(U);
      if U >= L then U := 0;

      Inc(R, D[S] + K); // <== hier!!!
      T   := D[S];
      D[S] := D[R];
      D[R] := T;
    end;
  end;
end;
Anwendung:
Delphi-Quellcode:
var
  x: TRC4Context;
  str1, str2, str3: string;
begin
  str1 := 'unverschlüsselt';
  setLength(str2,length(str1));
  RC4Init(x,'Passwort');
  RC4Code(x, str1[1], str2[1], Length(str1)); // verschlüsseln
  setLength(str3,length(str2));
  RC4Code(x, str2[1], str3[1], Length(str2)); // entschlüsseln
  Rc4Done(x);
Delphi Version: D6 Personal.

negaH 21. Jul 2004 19:05

Re: VerschlüsselungsProgramm
 
Logisch, das ist die Funktion im RC4 Algorithmus, eben eine Modulo 256 Operation. In diesem Sinne ist in meinem Code alles in Ordnung und der Code setzt absichtlich auf das Verhalten das bei der Addition eines Bytes +x beim Überlauf eine modulo 256 Operation impliziert ausgeführt wird.
Allerdings, ich gebe dir Recht das dies einem klar definierten Verhalten eines Sources ohne Fehler widerspricht.

Man könnte es so umschreiben:

Delphi-Quellcode:
R := (R + D[S] + K) mod 256;
wobei dann aber der Compiler ineffizienteren Code erzeugen muß da er das Zwischenresultat von "R + D[S] + K" nicht mehr im Bereich Byte sondern Word oder sogar Integer durchführen muß. Desweiteren muß dann das Zwischenresultat mit $FF maskiert werden, eben modulo 256. Dies ist wiederum ein zusätzlicher Maschinenbefehl.

Sogesehen habe ich so programmiert das ohne Überlaufprüfungen der Compiler den "effizientesten" Code erzeugen muß. Der gemeldete Überlauffehler ist also für die korrekte Funktionsweise des Algorithmus irrelevant. (ein fehlerhafter Fehler :) )

Gruß hagen

Luckie 21. Jul 2004 19:17

Re: VerschlüsselungsProgramm
 
Und wie bekommt man so was dann zu laufen? :gruebel:

negaH 21. Jul 2004 19:32

Re: VerschlüsselungsProgramm
 
Compileroptionen->Bereichsüberprüfung->aus.

Oder im Source mit dedingter Compilierung.

Delphi-Quellcode:

{$IFOPT R+}
  {$DEFINE INSUFFICIENT}
{$ENDIF}

{$IFOPT Q+}
  {$DEFINE INSUFFICIENT}
{$ENDIF}

{$IFDEF INSUFFICIENT}
  {$R-, Q-}
{$ENDIF}


function RC4Code().. bla bla



{$IFDEF INSUFFICIENT}
  {$R+, Q+}
  {$UNDEF INSUFFICIENT}
{$ENDIF}

Oder direkt in der betroffenen Prozedure, da $R/$Q eben nur lokal gültig sind:

Delphi-Quellcode:
procedure RC4Code();
begin
  {$R-, Q-}
 

... bla bla.

end;
Allerdings musste ich feststellen das dies nur abhängig von der Delphi Version funktioniert !!
D.h. in bestimmten Delphi Version werden diese Compilerswitches einfach ignoriert.

Gruß Hagen

negaH 21. Jul 2004 19:37

Re: VerschlüsselungsProgramm
 
Die Bereichsüberprüfung, bzw. eben das Rangechecking, sollte man NUR zur Entwicklugszeit aktivieren. In den Finalen Versionen sollte man IMMER ohne Debug/Überlaufprüfungen etc. compilieren.

Da in den meisten Fällen der Rangcheck immer nur dort anschlägt wo man es NICHT möchte aber fast NIEMALS dort anschlägt wo es sinnvoll wäre deaktiviere ich dies Überprüfung in meinen Sourcen von vornherein.

Überläufe selber sind Designtechnische Probleme, d.h. sie können nicht entstehen wenn der Programmierer die richtigen Algorithmen und Datentypen von vornhinein korrekt wählt.

Enstehen diese in meinen Sourcen denoch dann kann ich mit 99.99%'tiger Sicherheit dafon ausgehen das sie erwünscht sind, eben Datentypenabhängige Modulo Operationen.
Bei der Entwicklung vom DEC mit seinen viele verschiedenen Algorithmen die fast ALLE mit solchen 2^(2^x) Modulo-Operationen arbeiten, hatte ich anfangs mit vielen Supportmails zu kämpfen. Ich baute dann eine eigene INCLUDE VER.INC die standardmäßig folgende Switches setzt:

Delphi-Quellcode:
{$A+,B-,E-,F-,G+,H+,I-,J+,K-,N+,P+,Q-,R-,S-,T-,V+,W-,X+,Y-,G+}

{$IFDEF VER80}  { Delphi 1.0     }
  {$DEFINE VER_D1}
  {$DEFINE VER_D1H}
{$ENDIF}

{$IFDEF VER90}  { Delphi 2.0     }
  {$DEFINE VER_D2}
  {$DEFINE VER_D2H}
  {$DEFINE VER_D1H}
{$ENDIF}

{$IFDEF VER100} {Borland Delphi 3.0 }
  {$DEFINE VER_D3}
  {$DEFINE VER_D3H}
  {$DEFINE VER_D2H}
  {$DEFINE VER_D1H}
{$ENDIF}

{$IFDEF VER120} {Borland Delphi 4.0 }
  {$DEFINE VER_D4}
  {$DEFINE VER_D4H}
  {$DEFINE VER_D3H}
  {$DEFINE VER_D2H}
  {$DEFINE VER_D1H}
{$ENDIF}

{$IFDEF VER130} {Borland Delphi 5.0 }
  {$DEFINE VER_D5}
  {$DEFINE VER_D5H}
  {$DEFINE VER_D4H}
  {$DEFINE VER_D3H}
  {$DEFINE VER_D2H}
  {$DEFINE VER_D1H}
{$ENDIF}

{$IFDEF VER140} {Borland Delphi 6.0 }
  {$DEFINE VER_D6}
  {$DEFINE VER_D6H}
  {$DEFINE VER_D5H}
  {$DEFINE VER_D4H}
  {$DEFINE VER_D3H}
  {$DEFINE VER_D2H}
  {$DEFINE VER_D1H}
{$ENDIF}

{$IFDEF VER150} {Borland Delphi 7.0 }
  {$DEFINE VER_D7}
  {$DEFINE VER_D7H}
  {$DEFINE VER_D6H}
  {$DEFINE VER_D5H}
  {$DEFINE VER_D4H}
  {$DEFINE VER_D3H}
  {$DEFINE VER_D2H}
  {$DEFINE VER_D1H}
{$ENDIF}

{$IFDEF VER93}  { Borland C++Builder 1.0 }
  {$DEFINE VER_BCB1}
  {$DEFINE VER_BCB1H}
{$ENDIF}

{$IFDEF VER110} { Borland C++Builder 3.0 }
  {$DEFINE VER_BCB3}
  {$DEFINE VER_BCB3H}
  {$DEFINE VER_BCB1H}
{$ENDIF}

{$IFDEF VER125}
  {$DEFINE VER_BCB4}
  {$DEFINE VER_BCB4H}
  {$DEFINE VER_BCB3H}
  {$DEFINE VER_BCB1H}
{$ENDIF}

{$IFNDEF VER80}           { Delphi 1.0     }
 {$IFNDEF VER90}          { Delphi 2.0     }
  {$IFNDEF VER93}         { C++Builder 1.0 }
    {$DEFINE VER_D3H}     { Delphi 3.0 or higher }
    {$IFNDEF VER100}
      {$DEFINE VER_BCB3H} { C++Builder 3.0 or higher }
      {$IFNDEF VER110}
        {$DEFINE VER_D4H} { Delphi 4.0 or higher }
        {$IFNDEF VER120}
           {$DEFINE VER_D5H}
           {$IFNDEF VER130}
              {$DEFINE VER_D6H}
              {$IFNDEF VER140}
                 {$DEFINE VER_D7H}
              {$ENDIF}
           {$ENDIF}
        {$ENDIF}
      {$ENDIF}
    {$ENDIF}
  {$ENDIF}
 {$ENDIF}
{$ENDIF}

{$IFDEF VER_D7H}
  {$A4} 
  {$WARN UNSAFE_TYPE OFF}
  {$WARN UNSAFE_CODE OFF}
  {$WARN UNSAFE_CAST OFF}
{$ENDIF}
Mit {$I VER.INC} wird dann gleich hinter UNIT XYZ; diese Versions Include eingebunden. Dies hat eben auch den Vorteil das man viel einfacher die verschiedenen Delphi/BCB Compiler erkennen kann.

Delphi-Quellcode:

unit XYZ;

{$I VER.INC}

interface

uses SysUtils;


implementation

const
{$IFDEF VER_D1}
  M1 = 'Delphi Version 1.0';
{$ENDIF}
{$IFDEF VER_D2}
  M1 = 'Delphi Version 2.0';
{$ENDIF}
{$IFDEF VER_D3}
  M1 = 'Delphi Version 3.0';
{$ENDIF}
{$IFDEF VER_D4}
  M1 = 'Delphi Version 4.0';
{$ENDIF}
{$IFDEF VER_D5}
  M1 = 'Delphi Version 5.0';
{$ENDIF}
{$IFDEF VER_D6}
  M1 = 'Delphi Version 6.0';
{$ENDIF}
{$IFDEF VER_D7}
  M1 = 'Delphi Version 7.0';
{$ENDIF}
{$IFDEF VER_D2}
  M1 = 'Delphi Version 2.0';
{$ENDIF}
{$IFDEF VER_D3}
  M1 = 'Delphi Version 3.0';
{$ENDIF}
{$IFDEF VER_D4}
  M1 = 'Delphi Version 4.0';
{$ENDIF}
{$IFDEF VER_D5}
  M1 = 'Delphi Version 5.0';
{$ENDIF}

initialization

  ShowMessage(M1);

{$IFDEF VER_D3H}
  ShowMessage('Delphi Version 3.0 oder höher');
{$ENDIF} 

{$IFNDEF VER_D6H}
  ShowMessage('mindestens Delphi 6.0 wird benötigt');
{$ENDIF}
end.
Gruß Hagen

Luckie 21. Jul 2004 19:45

Re: VerschlüsselungsProgramm
 
Hm, ach so ja gut. So ganz sauber finde ich das persönlich aber nicht, denn die Idee hatte ich auch schon gehabt.

negaH 21. Jul 2004 19:52

Re: VerschlüsselungsProgramm
 
Hm, das hängt davon ab: ist der Source nicht sauber an den Compiler angepasst oder ist der Compiler in seinen Fähigkeiten nicht korrekt an die Möglichkeiten der Hardware angepasst.

Ich persönlich habe nun seit BP 4.1 miterleben können wie unsicherer und ungenauer die Überlauf-Prüfung im Compiler wurde. Von Version zu Version entstanden in der Überlaufprüfung immer mehr Lücken und andererseits schlug diese Überprüfung immer häufiger dort an wo sie es nicht sollte.

Nungut, man kann den Source wie oben geschrieben abändern um ihn wieder 100%'tig konform zu machen, oder aber man benutzt die Compilerswitches dafür wozu sie eigentlich auch da sind, und deaktiviert die Überprüfungen, WENN man weiß was man tut :)

Gruß Hagen

Rackergen2 21. Jul 2004 23:01

Re: VerschlüsselungsProgramm
 
Zitat:

Zitat von negaH
Zitat:

Merke: Am sichersten ist es, eine Datei zwei Mal zu kodieren... Dann kommt keiner ran...
Merke: Am UN-sichersten ist es einen Text zweimal oder mehrfach zu verschlüsseln !!

Das war ein Witz, der sich speziell auf diesen "Verschlüsselungs"-Algorithmus bezogen hat...

negaH 22. Jul 2004 00:20

Re: VerschlüsselungsProgramm
 
Tja und wieder ein Witz, Joke oder so. Hier im Forum hatten wir es erst mit solchen coolen Witzen ;)

Gruß hagen

dizzy 22. Jul 2004 04:06

Re: VerschlüsselungsProgramm
 
[ot]muss ich jetzt mal los werden...
Ich finds immer wieder zum schießen mit euch! So im Umgang sind hier wirklich alle immer sehr nett und die meisten haben auch ganz schön den Schalk im Nacken :thuimb:. Eine richtig schön lockere Schmunzel-Atmosphäre!
Postet aber jemand mal ein scherzhaft gemeintes Programm, so hagelt es ernsthafte Verbesserungsvorschläge noch und nöcher :lol: --- die Helf-Disziplin hier ist einfach die beste *g*. Sehr löblich an sich, nur geht so einem scherzhaften Proggie da gewaltig der Witz verloren... was irgendwie ja auch schon wieder spassig ist.
Informatiker haben halt sehr viel Humor, aber der erstreckt sich wohl oft nicht bis in ihr Fachgebiet :)
[/ot]

ps: Das ist keine Kritik, sondern eine mich amüsierende Feststellung. (Ist ja auch nicht immer leicht ein so gemeintes Scherzprogramm von Programmen die ein schlechter Scherz sind zu unterscheiden ;))

n8i,
dizzy


Alle Zeitangaben in WEZ +1. Es ist jetzt 14:44 Uhr.
Seite 4 von 9   « Erste     234 56     Letzte »    

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz