Seite 2 von 3

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 13:54
von Manfred
na da bin ich ja mal gespannt.

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 14:03
von brandelh
Martin Altmann hat geschrieben:da sind Steuerzeichen drin, die in einem Datenbankfeld vom Typ Zeichen nicht dargestellt werden können (uns somit nicht gespeichert werden).
das habe ich mal nachgeprüft:

Code: Alles auswählen

PROCEDURE Main
   LOCAL x, nAnz := 256
   LOCAL cBuffer := space(256)
   /* we use the ansi charset by default */
   SET CHARSET TO OEM
   ? "Starte Umwandlung"
   FOR x := 1 to nAnz
       cBuffer[x] := chr(x-1) // 0 bis 255
       IF cBuffer[x] # chr(x-1)
          ? "Fehler bei Byte",x-1
       ENDIF
   NEXT
   ? "Ende Umwandlung, nun speichern"
   ? "-----------------"
   ? cBuffer
   ? "-----------------"
   dbcreate("test", {{ "TxtVar", "C", 500, 0 }} )
   use test exclusive
   dbAppend()
   replace FIELD->TxtVar with cBuffer
   close // alle Buffer schreiben
   use test exclusive
   cBuffer := rtrim(FIELD->TxtVar) // rtrim() ist wichtig !!!
   ? "Teste Feldinhalt in Variable"
   FOR x := 1 to len(cBuffer)
       cBuffer[x] := chr(x-1) // 0 bis 255
       IF cBuffer[x] # chr(x-1)
          ? "Fehler bei Byte",x-1
       ENDIF
   NEXT
   ? "sind hier Fehler aufgelistet ?"
   ? "-----------------"
   ? cBuffer
   ? "-----------------"
   inkey(0)
   /* $TODO: place your application code here */
RETURN
Wer es probieren will nur zu, das Beispiel zeigt, dass eine DBF mit OEM Zeichensatz und OEM EXE zumindest mit der DBFDBE immer genau das Byte speichert, das der String übergibt !
Sowohl chr(0) als auch jedes andere Steuerzeichen können in so einem Feld gespeichert werden.

Sobald aber eine der genannten Voraussetzungen weg fällt, z.B. OEM / ANSI Konvertierung zum Zuge kommt, oder andere Sprachübersetzungen (schon bei ANSI über 128 gilt eine geänderte Zuordnung je nach Windows / Land / etc.)
werden Zeichen verändert, die dann einen binären Inhalt zerstören (Bitmap, Crypt-Text, etc.)

Unter DOS und Clipper haben wir uns daran gewöhnt, dass man Texte und Binärdaten gleichsetzen kann.

Das stimmt einfach nicht mehr: Unicode, Ansi/Oem, Länder-Code-Tabellen etc.

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 14:05
von brandelh
Manfred hat geschrieben:siehste und deshalb machen wir jetzt hier Schkuß und ich bringe das ganze Gedöns am Samstag mit nach OS zum XUG Treffen und wir fetzen uns da weiter.
Auch DU solltest einfach mal lesen was geschrieben wird ;-)

Binär-Memo-Feld oder Str2Hex() ... die Lösungen wurden genannt !
Die Ursachen erklärt :D

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 14:10
von Manfred
Hi Hubert,
meine Eingangsfrage war anderer Natur. Ich wollte wissen, was bei meiner Version falsch läuft (weil sie ja in einem anderen Programm klappt) und nicht, wie ich es anders machen soll oder muß. (zumal das Problem damit ja nicht behoben ist) Ich kann nicht einfach mal alles umstricken nur um das zu verschlüsseln. Ich bin gerade dabei Schritt für Schritt das andere Program zu durchlaufen um zu sehen, ob ich irgendwas übersehe.

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 14:14
von brandelh
OK,

laufen beide Programme unter ANSI EXE ? - das macht einen Unterschied.

hast du beim anderen Programm die Stringlänge mit cVar := alltrim(FeldVariable) auf den ursprünglichen Wert verkürzt ?

Diese beiden Möglichkeiten sind am wahrscheinlichsten.

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 14:15
von Martin Altmann
Wahrscheinlich ist genau das ANSI/OEM-Problem die Ursache!
Wie sehen die diesbezüglichen Schalter in den xpj-Dateien aus?
Was steht in dem Header der jeweiligen DBF-Dateien dazu?

Viele Grüße,
Martin

Hubert war schneller...

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 14:23
von Manfred
Damit ich das jetzt richtig verstehe, es ist ein Unterschied ob ich alle in OEM mache oder alles in ANSI? Bei OEM klappt es, aber bei ANSI muß es nicht unbedingt klappen?

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 14:59
von brandelh
Solange man Crypt nicht nutzt, bringt mein Beispiel von oben die korrekten Werte, mit Crypt() und ANSI / OEM Konvertierung sieht es so aus:

Code: Alles auswählen

Starte Umwandlung
Ende Umwandlung, nun speichern
-----------------
 ☺☻♥♦♣♠
♫☼►◄↕‼¶§▬↨↑↓→←∟↔▲▼ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]
^_`abcdefghijklmnopqrstuvwxyz{|}~⌂ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø׃áíóúñѪº¿®¬½¼¡
«»░▒▓│┤ÁÂÀ©╣║╗╝¢¥┐└┴┬├─┼ãÃ╚╔╩╦╠═╬¤ðÐÊËÈıÍÎÏ┘┌█▄¦Ì▀ÓßÔÒõÕµþÞÚÛÙýݯ´­±‗¾¶§÷¸°¨·¹³²
■ 
-----------------
Fehler, nach Rückübersetzung !
ORIGINAL:
 ☺☻♥♦♣♠
♫☼►◄↕‼¶§▬↨↑↓→←∟↔▲▼ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]
^_`abcdefghijklmnopqrstuvwxyz{|}~⌂ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø׃áíóúñѪº¿®¬½¼¡
«»░▒▓│┤ÁÂÀ©╣║╗╝¢¥┐└┴┬├─┼ãÃ╚╔╩╦╠═╬¤ðÐÊËÈıÍÎÏ┘┌█▄¦Ì▀ÓßÔÒõÕµþÞÚÛÙýݯ´­±‗¾¶§÷¸°¨·¹³²
■ 
------------------
NEU:
 ☺±Û♦♣♠¼
♫☼╬◄↕‼¶┌▬↨↑↓→←∟↔▲▼ !"#$×&'()*+,-³/0ö2à456789:;<=>?@ABCDEFGHIJKLéNOPQRSTUVWXYZ[\]
^_`abcdefghÀjklënopqrstuvwxyz{|}~⌂ÇüéâäàåçnëèïîìÄÅÉæÆôöòûùLÖÜø£Ø׃á
óúñѪº¿®¬½¼¡|»░▒▓│┤ÁÂÀ©+║}l¢¥┐└┴┬├─┼▼Ã╚╔╩╦╠═╬¤ðÐÊËÈıÍÎÏ┘┌█▄¦Ì▀ÓßÔÒõÕµþÞÚÛÙýݯ´­±
‗¾X§S¸°¨·¹³²8 
Nun hast du sicher nicht so viele Sonderzeichen wie dieser String, aber schau mal bei den kleinen Buchstaben ... da stimmt es auch nicht.

Bleibt zu prüfen, was passiert, wenn ich statt dessen eine FOXDBE nutze ...

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 15:02
von Manfred
Hubert, ich verstehe nur Bahnhof. Was soll mir Dein Beispiel sagen?

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 15:10
von brandelh
Hallo Manfred,

wenn ich mein Testprogramm von eben mit FOXDBE UND NEUER DBF ( = ANSI DBF ) und ANSI EXE laufen lasse, passt es auch wieder.
Sogar mit "C" als Feldtyp, obwohl "V" sicher besser wäre.

PS: bei der FOXDBE steht als maximale Feldlänge:

Code: Alles auswählen

Character (text) *) C 1-254 C C 
Character (binary) C 1-254 X C 
das stimmt doch nicht mehr oder ?

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 15:13
von brandelh
Manfred hat geschrieben:Hubert, ich verstehe nur Bahnhof. Was soll mir Dein Beispiel sagen?
Mein Beispiel erstellt einen String mit allen Zeichen (0 bis 255) speichert diesen und liest es wieder ein:

1. Alles in OEM mit und ohne Crypt() kein Problem.
2. OEM DBF und ANSI EXE - ohne Crypt() kein Problem, aber mit Crypt() stimmen die Strings nicht mehr.
3. Alles in ANSI mit und ohne Crypt() kein Problem.

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 15:21
von Manfred
ah ok.
Ich habe mir gerade das andere Programm angesehen. Es ist SET CHARSET OEM. Die DBF waren mal DBFNTX. Die waren auch mit Crypt Feldern versehen. Dann habe ich sie nach FOXCDX umgewandelt durch DbImport() der Daten. Aber trotzdem kann ich sie jetzt noch encrypten.

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 15:24
von brandelh
Solange die EXE OEM ist, bleiben auch die DBFs (egal ob DBFDBE oder FOXDBE) auf OEM, als wieder keine Umwandlung !

Umwandlung vermeiden und durch Feldlänge angehängte Blanks vermeiden und es sollte gehen.

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 15:59
von Tom
So oder so, Ursache ist der (unterschiedliche) Zeichensatz. Das Problem muss übrigens nicht immer auftreten, aber es ist meistens sehr wahrscheinlich. Es lässt sich leider nicht heilen, weil die ANSI-OEM-Konvertierung (und zurück) für bestimmte Zeichen nicht eindeutig ist. Wenn man schon mit Crypt() arbeitet, dann 1. im Speicher (nicht direkt auf Tabellendaten) und 2. mit zusätzlicher Umwandlung in Hex-Daten (die bei ANSI und OEM gleich sind).

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 16:02
von Manfred
Hm,
ich verstehe das jetzt nicht. Ich mache doch keine Konvertierung hin und zurück. Oder was meinst Du Tom?

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 16:29
von Tom
Du nicht. Aber die DBE nimmt u.U. eine vor, Deine EXE möglicherweise auch (wenn sie ANSI-Daten bekommt/hält und auf OEM steht). Es gibt irgendwo in der Doku ein schönes Schaubild, das zeigt, wann und unter welchen Bedingungen Zeichensatzkonvertierungen vorgenommen werden. Irgendeine davon traf oder trifft bei Dir zu.

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 16:45
von Manfred
ach das meinst Du. Das wäre aber extrem ärgerlich, wenn im Hintergrund was passiert und ich mir einen Wolf suche.

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 18:10
von Wolfgang Ciriack
Da hast du wahrscheinlich dasselbe Problem, das ich auch bei meiner Umstellung nach Foxdbe hatte. Ich habe damals auch die crypt Funktion entfernt, aber auch, weil das im Zusammenspiel mit dem ADS nicht mehr funktionierte. Irgendeine automatische Konvertierung ANSI OEM oder umgekehrt ließ auch mich damals verzweifeln.
Nimm etwas anderes, so wie es die Fachleute hier vorschlagen.

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 18:50
von Manfred
ich bin heute nicht nur auf dem falschen Dampfer, ich glaube auch auf dem falschen Gewässer. Welche Alternative wurde vorgeschlagen, die ich nehmen soll?

Re: Crypt() aus den Tools3

Verfasst: Di, 07. Feb 2017 20:03
von georg
Hallo, Manfred -


verschlüsselte Felder in der Länge verdoppeln, und nicht das Ergebnis von crypt() speichern, sondern StrToHex(crypt(cMeinFeld, cPasswort)) speichern, und beim Lesen eben mit HexToStr() arbeiten.

Re: Crypt() aus den Tools3

Verfasst: Mi, 08. Feb 2017 0:18
von AUGE_OHR
Manfred hat geschrieben:2) Ungecryptete DBF wird nach FOXCDX exportiert
ich "denke" das hier das Problem liegt. das "exportieren" mittels VIA ist IMHO nicht "sicher".

ich würde die FOX DBF "neu" aufbauen und Satzweise eine "manuelle" ConvToAnsiCP() vornehmen und das Ganze unter OEM.
dann deine ANSI App starten und mit Crypt() auf die neue FOX DBF gehen.

Re: Crypt() aus den Tools3

Verfasst: Mi, 08. Feb 2017 7:31
von brandelh
Ich denke, wenn du bei FOXDBE den verschlüsselten String im Feldtyp BINÄR MEMO speicherst ( V ) sollte alles automatisch stimmen, da die DBE KEIN Konvertierung vornimmt.

Re: Crypt() aus den Tools3

Verfasst: Mi, 08. Feb 2017 10:18
von Tom
Noch einmal zur Erläuterung. Crypt verwendet den gesamten 8-Bit-Bereich, um einen String zu verschlüsseln (0 ... 255). Dabei gibt es einen Teilbereich, der für OEM- und ANSI-Zeichensatz übereinstimmt (einfache Sonderzeichen, Ziffern, Alphabetzeichen usw.), andere jedoch nicht. Einige Zeichen sind überhaupt nicht besetzt. Die Hin- und Rückumwandlung ist nicht nur deshalb nicht immer eindeutig. Wenn also ein gecrypteter String noch zweimal durch die Konvertierung geht, weil z.B. die DBE eine solche vornimmt, dann kann und wird es passieren, dass die Daten nicht mehr stimmen. Meistens betrifft das einzelne Zeichen.

Abhilfe schafft man, indem man den gecrypteten String sofort nach Hex konvertiert

Code: Alles auswählen

cMyEncodedString := StrToHex(Crypt(Trim(db->text),cSchluessel))
und erst dann speichert. Hex ist zwar doppelt so lang, bewegt sich aber in einem stark begrenzten Zeichenbereich (A ... F, 0 ... 9), der für alle Zeichensätze gleich ist.

Beim Entschlüsseln verfährt man umgekehrt:

Code: Alles auswählen

cMyDecodedString := Crypt(Trim(HexTroStr(db->encodedtext)),cSchluessel)
Damit erspart man sich allen Stress mit Engines und Zeichensätzen - und auch DB-Viewer schmieren nicht mehr ab, wenn sie auf solche Felder treten. Nachteil: In Hex sind die verschlüsselten Werte doppelt so lang, da zwei Byte je Zeichen benötigt werden.

Wenn es z.B. um Passwortsicherheit geht, würde ich generell von Crypt() abraten, da es sich um eine Verschlüsselungssystematik handelt, die Zugriff auf den Originalwert erlaubt - der verschlüsselte String enthält sozusagen das Original. Bei Passwörter oder ähnlichem fährt man mit Hashes besser. Die bilden sozusagen einen Kontrollwert. Ein Passwort ergibt immer den gleichen Hash (der z.B. bei SHA1, das in Xbase++ enthalten ist (Char2Hash) ein Hex-String ist), aber aus dem Hash kann man das Passwort nicht restaurieren.

Re: Crypt() aus den Tools3

Verfasst: Mi, 08. Feb 2017 17:35
von Manfred
es geht gar nicht um Passwortsicherheit. Nur darum, das die DBF nicht sofort und ohne tiefere Kenntnisse nicht so einfach auszulesen ist. Aber Crypt() fiel mir halt ad hoc ein. Aber das es so schwierig wird hätte ich auch nicht gedacht. Aber in der Hinsicht habe ich ja eh immer den Joker gezogen....

Re: Crypt() aus den Tools3

Verfasst: Do, 09. Feb 2017 8:30
von brandelh
Sorry. crypt() ist nicht schwierig, es gibt nur 2 Dinge zu beachten (Keine automatische ANSI/OEM Konvertierung und Stringlänge muss beim beiden Aufrufen identisch sein).
Um die Konvertierung zu umgehen, gibt es verschiedene (hier genannte) Möglichkeiten.

Die AES Verschlüsselung von DBEs fand ich schwierig und hab es gleich bleiben lassen.