staging.inyokaproject.org

juribel schrieb:

...Die Hexcodes, die du mit Sternchen unlesbar gemacht hast, sind nichts weiter als die hexadezimale Darstellung der Zeichen wie "example...", also wirklich kein schützenswertes Geheimnis. ...

Wenn der String nicht veröffentlich werden soll, ich nicht weiß, ob der Hexcode Reverse engineering gemacht werden kann? Was machen?

User shiro sieht am Hexcode "Der erste Buchstabe (6d) ist ein "m" und kein "e"."

Richtig.

1

00000000  6d ** ** ** ** ** ** **  6c ** ** ** ** ** ** **  |example.com|

Das "example.com" war ein Dummy für den echten String, der mit m******** beginnt.

-

shiro's Vorschlag, hoffe richtig ausgeführt und gekürzt mit Dummy 123@example.com:

1
2
3
4
5

$ cat example.txt | xxd ; sed 's/[[:print:]]/X/g' example.txt | xxd
00000000: 3132 3340 6578 616d 706c 652e 636f 6d0a  123@example.com.
00000010: 3132 3340 6578 616d 706c 652e 636f 6d0a  123@example.com.
00000000: 5858 5858 5858 5858 5858 5858 5858 580a  XXXXXXXXXXXXXXX.
00000010: 5858 5858 5858 5858 5858 5858 5858 580a  XXXXXXXXXXXXXXX.

Die Dummy 123@example.com Mail-Strings sehen für den Hexcode-Laien gleich aus.

Bsp. mit den "echten Daten" die zwei Strings sehen für den Hexcode-Laien ungleich aus, richtig?

1
2
3
4
5
6
7

$ cat example2.txt | xxd ; sed 's/[[:print:]]/X/g' example2.txt | xxd
*
*
*
00000000: 5858 5858 5858 5858 5858 5858 5858 5858  XXXXXXXXXXXXXXXX
00000010: 0a58 5858 5858 5858 5858 5858 5858 5858  .XXXXXXXXXXXXXXX
00000020: 5858 0a                                  XX.

GPT-4o mini sagt: "hex code 0a58 represents a newline character followed by the letter X" Wie shiro https://forum.ubuntuusers.de/post/9474157/

Wird das hier bestätigt? Ist das ein versteckter Zeilenumbruch am Anfang des String?

1
2
3

~$ echo -n 00000010: 0a58 5858 5858 5858 5858 5858 5858 5858 | xxd -r -p

XXXXXXXXXXXXXXXuser@pc:~$ 

Und das, ein Leerzeichen vor XX?

1
2
3

~$ echo -n 00000020: 5858 0a | xxd -r -p
 XX
user@pc:~$ 

Danke.

Ich wäre da etwas anders vorgegangen.

Erstmal mit einem möglichst einfachen Editor, wie Nano oder Mousepad, eine neue (leere) Datei erstellen und dann, wie der TE am Anfang erwähnte, die Strings mit "Copy" und "Paste" in je eine Zeile einfügen.

Nach dem Abspeichern dann die Datei einfach mit

hd datei.txt

ansehen.

Im Hexdump sind dann vorwiegend die Zeichen interessant, die größer als 0x7F oder kleiner als 0x20 sind.

Wichtig ist, dass man die einzelnen Bytes sieht wegen einer eventuellen UTF-8 Codierung. Ich habe da schon abenteuerliche Zeichen gesehen u.a. auch Modifizierer, die die Farbe des vorherigen Zeichens verändern wollen. Ich würde also erst mal noch solchen Dingen suchen.

Was ich aber auch schon öfters festgestellt habe, ist dass beim Kopieren von Strings aus Webseiten oft ein Zeilenwechsel am Anfang mit kommt oder am Ende noch ein Leerzeichen.

p.s.:

Wenn der String nicht veröffentlich werden soll, ich nicht weiß, ob der Hexcode Reverse engineering gemacht werden kann?

Das ist fast schon trivial. Beim nächsten Versuch darfst du nur die Bytes unkenntlich machen, denen auf der rechten Seite "normalene" Buchstaben zugeordnet sind (abzählen).

Dakuan schrieb:

Ich wäre da etwas anders vorgegangen.

Erstmal mit einem möglichst einfachen Editor, wie Nano oder Mousepad, eine neue (leere) Datei erstellen und dann, wie der TE am Anfang erwähnte, die Strings mit "Copy" und "Paste" in je eine Zeile einfügen.

Das hatte ich auf dem Android Gerät gemacht mit Markor Editor. Und dann rüberkopiert zu Ubuntu nach Mousepad, Kate, Geany. (man sieht nirgends etwas Auffälliges kein leeres Charakterfeld...)

Nach dem Abspeichern dann die Datei einfach mit

hd datei.txt

Ok, das ist kurz! 😀 ... gleiche wie:

1

hexdump -C datei.txt

Dakuan schrieb:

Beim nächsten Versuch darfst du nur die Bytes unkenntlich machen, denen auf der rechten Seite "normalene" Buchstaben zugeordnet sind (abzählen).

Ok, hier sind ein paar der unsichtbaren "Übeltäter", die nicht zum String gehören, aber vor dem ersten Zeichen sitzen! Und die man in den Editoren nicht sieht.

GPT-4o mini sagt:

1
2
3
4
5

hex	ASCII Character:				Decimal
0a	\n (newline)					10
ef	Not a standard printable ASCII character	239
bb	» (right-pointing double angle quotation mark)	187
bf	¿ (inverted question mark)			191

Lokal bekomme ich aus den Hexcodes nach nur:

1
2
3
4
5
6

$ printf '%b' "$(echo -n '0a' | sed 's/../\\x&/g')"

$ printf '%b' "$(echo -n 'ef' | sed 's/../\\x&/g')"
�$ printf '%b' "$(echo -n 'bb' | sed 's/../\\x&/g')"
�$ printf '%b' "$(echo -n 'bf' | sed 's/../\\x&/g')"
�$ 

Mal sehen, ob mir was auffällt woher diese unsichtbaren Zeichen kommen.

Frage: Was ich noch gar nicht verstanden habe, warum sieht man in den Editoren Mousepad, Kate, Geany, nano, gar nichts, nicht mal ein Leerzeichen?

Danke.

@Kuume: So wird das nichts.

Du hast in "example.txt" zwei mal den gleichen Text (123@example.com) gefolgt von einem <LF> (0a) eingegeben. Wie du erkennen kannst, sind alle druckbaren Zeichen in ein "X" (58) gewandelt worden.

Deine "echten Daten" in "example2.txt" können auch nicht stimmen, da beide Zeilen zwar ungleich lang sind und durch ein <LF> (0a) abgeschlossen sind und somit eine Länge von 35 Zeichen (2*16+3) aufweist.

In dem zuvor gezeigten Dump

1 2 3 4 5

$ hexdump -C datei.txt 00000000 6d ** ** ** ** ** ** ** 6c ** ** ** ** ** ** ** |example.com| 00000010 0a ** ** ** ** ** ** ** 40 ** ** ** ** ** ** ** |....example| # der String der nicht funktionert 00000020 2e 6f 72 67 0a |.com.| 00000025

sind 37 Zeichen (2*16+5) vorhanden. Offenbar ist in der zweiten Zeile ein druckbares Zeichen vorhanden, das man bei der Textausgabe nicht "sehen" kann, wie ein Blank am Ende. Bitte schicke die verwendete Datei "datei.txt" wie folgt durch "sed":

$ sed 's/[0-9A-Za-z]/X/g' datei.txt | xxd

Hierbei werden nur die Buchstaben und Ziffern in ein "X" gewandelt, alle anderen Zeichen bleiben unverändert. Diese Ausgabe solltest du veröffentlichen können.

PS: Mit den Infos aus deinem vorherigen Post:

$ echo Dies ist$'\xef'$'\xbb'$'\xbf'ein Testtext | tee x.o ; sed 's/[0-9A-Za-z]/X/g' x.o | tee x.x | xxd
Dies istein Testtext
00000000: 5858 5858 2058 5858 efbb bf58 5858 2058  XXXX XXX...XXX X
00000010: 5858 5858 5858 580a                      XXXXXXX.
$ 

Allerdings ist der text stream (0xEF, 0xBB, 0xBF) nichts anderes als die "UTF-8 BOM" Markierung am Anfang einer UTF-8 Datei.

shiro schrieb:

@Kuume: So wird das nichts.

Entschuldigung,dass es nun so ein Wirrwarr wurde mit den "DummyDaten".

Habe die datei noch mal mit

1

dh datei.txt

angesehen und diese Tabelle gemacht, mit den Übersetzungen der Hexcodes, die nicht dazugehören.

1 2 3 4 5

hex ASCII Character: Decimal 0a \n (newline) 10 ef Not a standard printable ASCII character 239 bb » (right-pointing double angle quotation mark) 187 bf ¿ (inverted question mark) 191

Siehe Screenshot: hex_terminal.png

Danke für eure Hilfe!

Frage: Warum sieht man in den Editoren Mousepad, Kate, Geany, nano, (außer line feed (LF) und an dieser Stelle (Ende erster Zeie) hatte es nicht gestört) nichts, nicht mal ein Leerzeichen? Sind es nicht vier (0a ef bb bf) unsichtbare Zeichen?

EDIT und noch ein Geany Editor Test, mit dem kaputten String: Man sieht nichts (Screenshot geany2.png) Erst wenn Enter gedrückt wird zeigt es LF.

Kuume schrieb:

Frage: Warum sieht man in den Editoren Mousepad, Kate, Geany, nano, (außer line feed (LF) und an dieser Stelle (Ende erster Zeie) hatte es nicht gestört) nichts, nicht mal ein Leerzeichen?

Also Geany und SciTE können dies. Lade die Datei mal mit Geany. Da sie als UTF-8 erkannt wurde, siehst du den BOM nicht. Mach mal im Menue "Dokument" → "Zeichencodierung festlegen" → "Westeuropäisch" → "Westlich (ISO-8859-1)" und dann ein Neuladen des Dokuments über "Strg-R" oder "Datei" → "Neu laden". Und dann wirst du die 3 BOM Zeichen sehen, die im UTF-8 nicht angezeigt werden. Soweit verstanden?

Sind es nicht vier (0a ef bb bf) unsichtbare Zeichen?

Nein, die BOM ist ein UTF-8 Zeichen, das aus 3 Bytes besteht. Das <LF> (0a) ist das Zeilenende von der vorherigen Zeile.

Das BOM Zeichen kannst du auch mit "sed" eliminieren:

$ sed 's/\xef\xbb\xbf//' x.o | xxd
00000000: 4469 6573 2069 7374 6569 6e20 5465 7374  Dies istein Test
00000010: 7465 7874 0a                             text.
$ 

Warum machst du nicht einfach was man dir sagt? Du machst es hilfwilligen nur schwer.

Und warum glauben eigentlich (fast) alle, dass KI die Lösung ist? Du solltest wirklich das zeigen, was gefragt wurde.

Die von dir andeutungsweise gezeigten Bytes (0xef, 0xbb, 0xbf) sind decodiert das Unicode Zeichen u+FEFF (Byte order mark). Ist nichts ungewöhnliches, hat aber in URL's nichts zu suchen.

shiro schrieb:

Kuume schrieb:

Frage: Warum sieht man in den Editoren Mousepad, Kate, Geany, nano, (außer line feed (LF) und an dieser Stelle (Ende erster Zeile) hatte es nicht gestört) nichts, nicht mal ein Leerzeichen?

Also Geany ...Mach mal im Menue "Dokument" → "Zeichencodierung festlegen" → "Westeuropäisch" → "Westlich (ISO-8859-1)" und dann ein Neuladen des Dokuments über "Strg-R" oder "Datei" → "Neu laden". Und dann wirst du die 3 BOM Zeichen sehen, die im UTF-8 nicht angezeigt werden. Soweit verstanden?

Ok! Dann sind die Zeichen zu sehen beim betroffene String vor dem ersten Zeichen.

1

String

Dakuan schrieb:

Warum machst du nicht einfach was man dir sagt? Du machst es hilfwilligen nur schwer.

Die von dir andeutungsweise gezeigten Bytes (0xef, 0xbb, 0xbf) sind decodiert das Unicode Zeichen u+FEFF (Byte order mark). Ist nichts ungewöhnliches, hat aber in URL's nichts zu suchen.

In Post https://forum.ubuntuusers.de/post/9474231/ habe ich gemacht was du beschrieben hast.

Habe alle Hexcodes nach ASCII übersetzt und diese

1 2 3 4 5

hex ASCII Character: Decimal 0a \n (newline) 10 ef Not a standard printable ASCII character 239 bb » (right-pointing double angle quotation mark) 187 bf ¿ (inverted question mark) 191

gehörten nicht zu meinem String.

Für mich ist damit

1
2

String
String

beantwortet, warum dieser zweite String nicht funktioniert, obwohl er in sämtlichen Editoren gleich aussieht wie der erste String. Wenn nicht z.B. in Geany ""Dokument" → "Zeichencodierung festlegen" → "Westeuropäisch" → "Westlich (ISO-8859-1)""

Vielen Dank für die Hilfe, es hat mir sehr viel beigebracht!

PS: es ging um einen Teil von Zugangsdaten...

@Kuume: Naja, nicht Du hast die Zeichen ”nach ASCII übersetzt”, sondern ChatGPT. Und konnte das natürlich nicht richtig, denn wenn man die vier Bytewerte als einzelne Zeichen sieht, dann ist nur ein einziges davon überhaupt ASCII und nur bei einem der anderen hat es das auch erkannt. » und ¿ sind keine ASCII-Zeichen. Die Beschreibung die ChatGPT da gegeben hat, stimmt beispielsweise für die ISO-8859-1 Kodierung, aber das hat ChatGPT nicht gesagt. Ebenso wenig konnte es schlussfolgern oder wusste nicht, dass die Folge dieser drei Bytewerte in UTF-8 ein breitenloses geschütztes Leerzeichen ist, das am Dateianfang als Erkennung für die Bytereihenfolge, zum Beispiel bei UTF-16 oder UTF-32 verwendet wird. Das darf durchaus in Text vorkommen, und normalerweise sieht man es dort nicht, weil eben breitenlos ist, und es sollte von Software als (geschütztes) Leerzeichen behandelt werden. In Textverarbeitungen oder auf HTML-Seiten kann man das beispielsweise gegen automatische Silbentrennung einsetzen.

Das 0A Byte ist übrigens nicht Bestandteil des Problems: das ist das Zeilenende-Zeichen von der Zeile davor.

Ich verwende einen käuflichen Editor, der zeigt mir das Zeichen an, als <0xfeff> in einer anderen Farbe als der normale Text, und es wird als ein einziges Zeichen behandelt. Kann mir aber nicht vorstellen, dass es keine freien Editoren gibt, die das nicht auch tun würden. Bei Geany kann man zumindest beim Bewegen des Cursors und bei der Anzeige Länge der Auswahl in der Statuszeile das unsichtbare Zeichen wahrnehmen.

Bei Midnightcommanders integriertem Editor (mcedit) kann man leicht vom Textmodus in den Hexadezimalmodus umschalten - das ist auch ein praktisches Tool für solche Sachen und mir deutlich zugänglicher als od oder hexdump.

Frage: Warum sieht man in den Editoren Mousepad, Kate, Geany, nano, (außer line feed (LF) und an dieser Stelle (Ende erster Zeie) hatte es nicht gestört) nichts, nicht mal ein Leerzeichen? Sind es nicht vier (0a ef bb bf) unsichtbare Zeichen?

Tja - die Antwort ist 2stufig: Wieso sieht man die Zeichen nicht? Weil es nicht-sichtbare Zeichen sind. Sie nicht sichtbar zu machen ist die naheliegende und oft eine korrekte Darstellung. Aber wieso heißen sie "nicht-druckbar"? Weil in den Urzeiten von Unix die Leute keine Bildschirme hatten (ja, ja, isso), sondern so etwas zwischen Drucker und Fernschreiber (alias Teletype, kurz: tty). Wenn man ls eingegeben hat, wurde die Antwort auf einen Papierstreifen gedruckt. Und daher heißt es in unzähligen Programmiersprachen (f)print(f), System.out.println (...) o.s.ä. - obwohl längst 99,99% der Ausgaben auf Bildschirme gedruckt werden, nicht auf Papier.

Besser wäre natürlich ioo für IO-output und ioi für IO-Input. ☺

Übrigens: Nicht vergessen, den Editor nachher wieder auf UTF-8 zurückzustellen, sonst wird der Frust groß.

Und: Ein Glück, dass diese BOMs sich nicht durchgesetzt haben.

BOMs haben sich nicht durchgesetzt? Meiner Erfahrung nach schon. Was sich nicht durchgesetzt hat, ist der Unsinn das bei UTF-8 zu verwenden. Microsoft war da ja gross dabei, mit der Begründung, dass man das als Kodierungserkennung missbrauchen könnte. Bei UTF-16+ macht ein BOM ja durchaus Sinn.

Edit: Und ich denke Du vermischst hier gerade „breitenlos“ und „nicht druckbar“. Ob ein breitenloses Zeichen druckbar ist oder nicht, ist ja eher eine philosophische Frage.

Marc_BlackJack_Rintsch schrieb:

@Kuume: Naja, nicht Du hast die Zeichen ”nach ASCII übersetzt”, sondern ChatGPT. ...

Jein, als Hexcode Laie, hatte ich auch selber die Zeichen übersetzt, aber das von ChatGPT sah professioneller aus. 🤓 Keine Sorge, werde die Welt nicht mit Vibe Coding beglücken... https://de.wikipedia.org/wiki/Vibe_Coding

Frage an die Fachleute:

Das Thema Zeichencodierung/Zeichensatz und Editoren ist ein Thema, hierbei ging es ja aber um Zugangsdaten, die handhabt man normalerweise nicht im Editor sondern in Eingabefeldern von Passwortmanagern, Zugangs-Webseiten und z.B. Mail-Programmen! Da wäre es vielleicht durchaus gewollt, "unsichtbare Zeichen" sehen zu können, bevor man tagelang sich selbst und diverse Admins zu Verzweiflung bringt? Könnten Passwortmanager so programmiert werden, dass eine Warnung bei "unsichtbare Zeichen" ausgegeben wird?

Copypaste von "irgendwo" aus dem Internet in Passwort- oder Datenbankfelder ist IMMER ein Sicherheitsrisiko und sollte man tunlichst vermeiden. Da muss man schon GANZ genau wissen, was man tut und wem man vertrauen kann.