Problem mit StringInStr() --- BINÄR- bzw. HEX-Vergleich funktioniert nicht --- Projektausschnitt [EnAndDeCrypt.au3]

  • Hallo Community ;) ,

    mein Problem liegt bei der Auswertung bzw. bei der Rückgabe von StringInStr(), welche Binär- bzw. (bei AutoIt) Hex-Werte (StringInStr() | BIN | HEX) vergleichen soll.

    Um es schlüssig zu machen muss ich ein klein wenig ausholen, damit ihr Gelegenheit habt mir zu helfen --- dies ist es was ich mir erhoffe, da ich kein Einsteiger in AutoIt oder der Programmierung generell bin und trotzdem hierbei ein wenig ratlos bin :huh: . Also folgendes:

    In der Abbildung (siehe Anhang unten) ist der gesamte Quellcode des Skriptes enthalten (welcher jedoch nur ein Ausschnitt eines größeren Projekts ist). In erster Linie erstelle ich eine tmp-Datei, die mir als Zwischenspeicher dient. Danach lese ich im @ScriptDir alle *.jpg-Dateien ein und möchte diese per CMD > copy /B Befehl, in eine Datei (binär aneinandergehängt) umleiten bzw. kopieren lassen. Vor dem copy /B Befehl lese ich die ersten 50 Zeilen der Bilder ein (also bei 4 Bildern, jeweils 50 Zeilen pro Bild). Diese Information soll dann in die angelegte tmp-Datei, welche bei 4 Bildern, 4 Zeilen am Ende haben soll (mit dem Inhalt pro Zeile: 50 Fragmente des jeweiligen Bildes (in BIN bzw. HEX-Form)). Bisher alles kein Problem.

    Eingelesen in den Zwischenspeicher (4 Bilder a' die ersten 50 Zeilen daraus, in tmp-Datei 4 Zeilen insgesamt) wird ausgeführt. Nun folgt der copy /B Befehl und der entstandene Container (im Bsp. hier, container.jpg) wird ebenfalls eingelesen (bei den FileRead()-Varianten wechsel ich immer beide Stellen, doch dies folgt unterhalb noch näher erläutert). Das Einlesen des Containers nutze ich, damit ich nach noch folgenden Aktionen (Implementierung folgt), den Container wieder binär auf die Fragmente im Zwischenspeicher prüfen kann bzw. den compare (Vergleich) durchführen kann.

    Den Vergleich habe ich mal simuliert über eine Do-Until-Schleife, die mir die Container-Datei (die Zusammenfassung der 4 Bilder, binär aneinandergehängt) mit den Fragmenten im Zwischenspeicher (tmp-Datei) vergleicht. Nun folgt endlich die Frage bzw. der Fehler oder auch das WIESO ...

    ... in den Zeilen 41 und 42 (sowie 78 und 79) habe ich die Einlesevarianten über FileOpen() --- default: 0 (normaler read mode), binär: 16 (binary mode) gegengetestet! Dabei kann ich mit StringInStr() und der Variante "0" in der Do-Until-Schleife eine positive Meldung "Ist enthalten in Container-Datei." verzeichnen und mit Variante "16" nur die andere Meldung der Bedingungsklausel (das der String nicht enthalten ist). Also der Vergleich ob eine der Zeilen der Fragment-Datei (tmp-Datei) im Container enthalten ist, läuft schief, obwohl ich manuell alles genauso nachvollziehen kann und über Notepad++ bspw. der Vergleich funktioniert!

    Gibt es bekannte Probleme beim Vergleich bzw. beim "contain in" | "contains" von HEX-Dateien bei AutoIt? Gibt es sinnvolle alternativen die mit HEX, was ja eigentlich BIN sein sollte jedoch AutoIt nicht so macht, umgehen können? Wie könnte ich noch verfahren?

    Ich bin über jede Anregung und Hilfe sehr dankbar und hoffe das es nachvollziehbar ankommt. Ansonsten kann gern einfach selbst das Skript ausprobiert werden. Dazu einfach ein Verzeichnis mit *.jpg-Dateien (es reichen ja kleine Bilder, vielleicht so 3 - 4 Stück sowie das Skript ablegen und mit den ganzen debug()-Funktionen ausführen. Empfehlung, damit die Übersicht gewahrt bleibt. Der Quellcode sollte auch recht selbsterklärend sein, hoffe ich.

    ANHANG
    1. EnAndDeCrpyt.au3.txt >>> ist eine HTML Datei (ein Export des Skriptes per SciTE) >>> bitte in *.html umbenennen!
    2. EnAndDeCrypt.au3.png

    3. der LINK zum Skript hier: LINK

    Danke für eure Hilfe --- UserIsGrateful :D

  • Dein Fehler könnte evtl. dadurch kommen, dass das "0x" das bei Binary mit generiert wird, nicht mit im Vergleich berücksichtigst. Einmal liest du wahrscheinlich sogar binär ein, aber den Vergleichspartner nicht, soweit ich das richtig sehe. Du solltest also aufpassen, dass die immer binär ausgewählt hast und die nochmal die Funktionshilfen zu FileRead(line) durchlesen). Zum Test kannst du dir die beiden Strings die verglichen werden, ja einfach mal anzeigen lassen.

    • Offizieller Beitrag

    Hallo,

    Erstmal: Warum hast du dein Scriptcode als Screenshot gespeichert? :D Eher nicht hilfreich, da wenn man dir helfen soll, man das Problem ja nachvollziehen können muss, und das geht am besten durchs testen.

    Wenn du eine Datei Binär einließt, gibt AutoIt ein Binären wert aus. Wenn du dann allerdings diesen Binären wert mit den String... funktionen benutzt, wandelt AutoIt diese Binäre zeichenfolge einfach in ein String um, also aus 0x414243 wird "0x414243" und nicht "ABC". (41 ist der ASCII code für A, 42 für B, 43 für C) Wenn du allerdings Binär einlesen willst und dann damit ein String vergleichen willst hilft dir BinaryToString weiter ;)

    Gruß,
    Spider

  • Hallo und danke für die Antworten bisher ;) ,

    @TheShadowAE --- Ich lese mit FileRead() entweder in 0 (default mode) oder mit 16 (binary mode) ein. Und zwar auch an den entscheidenden Stellen! Mir die Dateien anzeigen lassen habe ich natülich beim debugging bereits getan, doch 0x wird ebenfalls angezeigt und als String interpretiert, soweit ich das feststellen konnte. Beim manuellen Test(s), ging es ja auch (was den Vergleich angeht, nur StringInStr() scheint es nicht so zu machen, wie Notepad++ oder Ultraedit etc. Danke dir trotzdem für die Hinweise :) .

    @GtaSpider oder einfach Spider --- Der Quellcode ist zum einen als *.png und als *.html (als *.txt maskiert) vorhanden. Im Edit habe ich nun noch einen Download hinzugefügt, falls dir dies lieber ist. Doch aus der *.html hättest du ja sicher einen Test machen können ;) . Aber ja, der Quellcode ohne hin-und-her ist sicherlich besser. Desweiteren hab' vielen Dank für BinaryToString(), ich werde es mal so umformulieren. Jedoch lese ich ja die Container-Datei sowie die Fragmente (also vorher die Bilder) gleich ein. Wenn nun also der binäre Code nicht richtig sondern als String interpretiert wird, dann doch aber an beiden Stellen bzw. Dateien und dann müsste es wieder egal sein. D. h.: der String wird mit String verglichen und nicht mit String Vs. HEX (BIN) oder umgekehrt.

    Genau dies ist ja der Knackpunkt, der mir nicht logisch erscheint. Danke, ich schau mal weiter u. bin für weitere Ideen, Vorschläge dankbar. Merci :) .

  • Ich habe mal in einer DLL nach binären Daten gesucht. Das hat hervorragend geklappt mit StringInStr ohne binarytostring. ich hatte also 0xabcdefg.. als dll und "cd" als Suchstring beispielsweise. Es müsste also eigentlich funktionieren.

  • Hallo und danke für die Antworten bisher, Teil 2 ;) ,

    nun ist es geschafft! Zunächst @TheShadowAE: Ja es geht, wenn man es richtig macht (Dankeschön), was mich gleich zu @Oscar bringt! Danke dir Oscar, ich sah den Wald vor ... und so weiter nicht. Da FileRead() keine Zeilen liest bzw. FileReadLine() bei BINÄR nicht das zurückgibt, was ich mir erhoffte und ich die Hilfe einfach mit FileReadLine() Vs. FileRead() verwechselte, hat die Suche mit StringInStr() nicht korrekt funktionieren können.

    Nun habe ich es umgebaut, danke so funktioniert es :) . Ihr seid einfach super! Lob an die Community!
    Danke und ciao, bis demnächst!

    UserIsGrateful :) ... bitte als GELÖST einstufen, danke!

    Btw.: Falls ich den Quellcode abgeändert hier zu Verfügung stellen soll, dann bitte einfach hier nachfragen oder Bescheid geben, denn eigentlich denke ich, dass der Part des Skriptes eher weniger aufregend ist ;) .

  • Du musst den Thread selber auf gelöst stellen. Dazu eifnach deinen ersten Post in diesem Thread bearbeiten und den Tag in der ComboBox auf gelöst umstellen. :)
    Um Leuten zu helfen, die durch Google in diesen Thread finden und selber ein solches Problem haben, ist es sicher hilfreich, wenn sie auch noch den funktionierenden Code sehen. (Ich mags jedenfalls nicht, wenn ich nen passenden Thread finde und dann steht die Lösung da nicht drin ^^)