Variable als INI behandeln?

  • Ich hab eine, per Crypt.au3 verschlüsselte, INI Datei per FileRead eingelesen und entschlüsselt. Als ich den Inhalt in einer MsgBox aufrief, sah es wie eine richtige INI aus.
    Aktuell erstelle ich zur Programmlaufzeit daraus eine temporäre Datei, die ich bei Programmbeendigung automatisch löschen lasse.

    Gibt es eine Möglichkeit, dies zu umgehen, indem ich die FileRead-Variable als INI behandeln und daraus Daten abfragen kann?
    Mit den herkömmlichen INI Befehlen klappt das natürlich nicht, weil die Datei nicht gefunden werden kann.

    MfG Lo..

  • Hab mal ne kleine Funktionssammlung mit Beispiel geschrieben. Die kannst du benutzen.
    Es darf nur kein = vorkommen (außer bei der key->schlüssel zuweisung) und es darf kein schlüssel mit "[" beginnen und dessen value auf "]" enden.
    (Könnte man aber bestimmt auch noch ausbügeln ;))

  • Moin!

    Wie chesstiger schon sagte, ist RegEx der "Schlüssel" :rolleyes:
    Kann man sehr kompakt mit nem Ein-Zeiler lösen.
    Gibt bestimmt schönere Pattern, aber meiner funktioniert soweit gut:

    [autoit]

    ;~ $sIni = FileRead("C:\beliebigeDatei.beliebigerSuffix");solange die Datei Text nach "Ini-Standard" enthält funktionierts

    [/autoit][autoit][/autoit][autoit]

    ;nur eine Demo-INI ==> kann weg
    $sIni = "[Sektion1]" & @CRLF & _
    "Key1=1234" & @CRLF & _
    "Schlüssel1=Hallo, ich bin ein Schlüssel aus Sektion 1!" & @CRLF & _
    "CaseSense=Gross-/Kleinschreibung ist nicht relevant" & @CRLF & _
    "[Sektion2]" & @CRLF & _
    "Schlüssel1=Hallo, ich bin ein Schlüssel aus Sektion 2!" & @CRLF & _
    "Schluessel2=Ich auch!"
    ;nur eine Demo-INI ==> kann weg

    [/autoit][autoit][/autoit][autoit]

    $sIni &= @CRLF ;ohne abschliessenden Zeilenumbruch wird die letzte Zeile nicht gefunden

    [/autoit][autoit][/autoit][autoit]

    $sIniRead = _IniRead($sIni, "Sektion1", "Schlüssel1", "Standard")
    MsgBox(0, "", $sIniRead)
    $sIniRead = _IniRead($sIni, "Sektion2", "Schlüssel1", "Standard")
    MsgBox(0, "", $sIniRead)
    $sIniRead = _IniRead($sIni, "Sektion2", "Schluessel2", "Standard")
    MsgBox(0, "", $sIniRead)
    $sIniRead = _IniRead($sIni, "seKtion1", "cASEsENSE", "Standard")
    MsgBox(0, "", $sIniRead)
    $sIniRead = _IniRead($sIni, "Sektion2", "Streuselkuchen", "kuchen")
    MsgBox(0, "", "Streusel" & $sIniRead)

    [/autoit][autoit][/autoit][autoit]

    Func _IniRead($sText, $sSection, $sKey, $sDefault)
    $aHits = StringRegExp($sText, "(?i)(?s)\[" & $sSection & "\].+?" & $sKey & "=(.+?)\r\n", 3)
    If IsArray($aHits) Then Return $aHits[0]
    Return $sDefault
    EndFunc

    [/autoit]

    Xorianator: Weder "STRG-T" noch sonstiges Hexenwerk helfen bei der neuen Boardsoftware. Sämtliche Formatierung wird gnadenlos zerschossen...

  • Hi zusammen,

    bei dieser Art Fragestellung wird mir immer übel, bei den Antworten auch.
    Eine INI-Datei zu verschlüsseln und per AutoIt einzulesen macht genau in EINER Konfiguration Sinn, und zwar dann, wenn die INI-Datei selbst erstellt und somit auch verschlüsselt wird.

    Die Frage stellt sich, wieso überhaupt eine INI (steht übrigens für Initialisierung, da steht grundsätzlich NICHTS drin, was verschlüsselt werden muss! ) verwendet wird, und nicht einfach eine "normale" Textdatei. Wobei eine INI-Datei natürlich auch nichts weiter wie eine stinknormale Textdatei ist...

    Diese Textdatei kann man (genau wie die INI übrigens) einfach bereits verschlüsselt auf den Datenträger schreiben und beim Einlesen in den SPEICHER entschlüsseln.
    Die Schattenkopie einer auf den Datenträger entschlüsselten und nachher gelöschten Textdatei ist mit Windows Bordmitteln übrigens simpelst auszulesen!

    Und wer jetzt argumentieren sollte, dass
    - INI-Dateigedöns mit den entsprechenden AutoIt-Befehlen einfach abzuwickeln ist,
    - INI-Dateien einfach zu verschlüsseln sind,
    - INI-Dateien soooo wichtige Daten eigentlich garnicht enthalten, dass man gelöschte Dateien nicht explizit erasen muss,
    dem entgegne ich:
    Lernt "richtig" programmieren, damit diese pseudo-einfachen Krücken wie INI genau da bleiben wo sie hingehören, nämlich um beim Programmstart bestimmte und ggf. per jedem Texteditor bearbeitbare Parameter bereitzustellen.

    Wer "Verschlüsselung" und *.INI in einem Zusammenhang verwendet, sollte sich fragen, ob es nicht besser ist, die Einträge in der INI-Datei zu verschlüsseln (Base64 bspw.) statt die komplette Datei!

  • Andy:
    Ob dir beim Lesen meiner Frage schlecht wird oder nicht, ist mir ziemlich egal. Ich nutze für mich die INI Funktionen tatsächlich, weil sich mein Tool damit am einfachsten umsetzen lässt! Es ist ein eigener, nur für mich zugänglicher Passwortspeicher. Die Ini hab ich umbenannt in eine DLL. Hab hier mal irgendwo gelesen, dass ein User das auch so macht, damit unbefugte nicht so einfach an die Daten kommen. Leider kann man eine so erstellte Pseudo-DLL trotzdem einfach mit einem herkömmlichen Texteditor öffnen und die Daten sehen, weshalb ich das Ganze noch verschlüsselt hab. Es gibt GARANTIERT bessere Möglichkeiten um dieses Passworttool umzusetzen damit auch ein Profi wie du nichts daran auszusetzen hat. Aber warum sollte ich das tun? Es ist nur für mich. Und ich "baue" für mich so, dass mein Zweck erfüllt wird. Mir ist es egal, ob sich andere darüber aufregen ( ha, scheinbar doch nicht, sonst würde ich mich nicht rechtfertigen ^^).
    Und ganz davon abgesehen: vielleicht bin ich ja nicht der einzige, dem sowas wie _MEM_IniReadSectionNames() als nützlich erscheint?!

    Aber nun zurück zum Thema.

    Hallo, danke für eure Hilfe. Nach mehrfachen rumprobieren stellt sich heraus, dass die von Kanashius geschriebenen Funktionen am effektivsten sind.
    Leider funktionieren einige Funktionen noch nicht ( _MemIni_getKey(), _MemIni_iniWrite() und _MemIni_getStringData() ).

    Warum Friesels Beispiel nicht funktioniert ist mir noch unklar, denn sein Inibeispiel wird (natürlich) fehlerfrei abgewickelt.
    Ich hab in meinem Script beide Varianten durchprobiert. Mit den jeweiligen Beispielen und mit meiner eingelesenen Datei.

    [autoit]

    Global $sIni = BinaryToString(_Crypt_DecryptData(FileRead("als DLL getarnte INI"), "irgendeinText", $CALG_AES_256))

    [/autoit]


    Das gibt mir, zumindest rein optisch, den INI Inhalt wieder und ist auch so aufgebaut wie das IniBeispiel von Friesel.

    Kanashius: Ich hab deine Funktionen, bei denen ich die Sektionsnamen sowie die den Sektionsinhalt zurück bekomme so abgeändert, dass ich in $array[0] den Index stehen habe. Schade, dass die bereits oben erwähnten Funktionen nicht klappen, wäre schön, wenn wir das gemeinsam noch zurechtbiegen könnten.

  • Friede Lottich,
    der Andy ist in seiner Art einfach sehr ruppig, wenn ihm etwas nicht passt. Ich habe da auch schon mehrfach zu Antworten angesetzt (auch wenn ich nicht direkt betroffen war), aber am Ende doch nichts geschrieben. Denn auch wenn er nicht immer nett ist, pöbelt er auch nicht. Selbst aus den Kommentaren, die man ärgerlich findet, kann man sich nützliche Informationen ziehen.
    Bleib ruhig bei deinem Weg, der für deine Situation passt. Im Kopf hast du jetzt einfach auch Schwachstellen der Vorgehensweise an sich und weitere Optionen. Das ist eigentlich gut :)

    Grüße autoiter

  • Selbst aus den Kommentaren, die man ärgerlich findet, kann man sich nützliche Informationen ziehen.

    Bleib ruhig bei deinem Weg, der für deine Situation passt. Im Kopf hast du jetzt einfach auch Schwachstellen der Vorgehensweise an sich und weitere Optionen. Das ist eigentlich gut

    ...eigentlich gut. Und uneigentlich?

    @Lottich
    du hast selbst gemerkt, dass dein Ansatz gelinde gesagt problematisch ist und nicht wie gedacht funktioniert. Ansonsten wäre der Startpost überflüssig!
    Hier (und mir) geht´s nicht darum, irgendwen runterzumachen und den "Profi" raushängen zu lassen, der ich btw. auch garnicht bin!
    Es geht darum, dass offensichtliche Schei*** NIE, und auch wirklich NIE, zu Gold gemacht werden kann.
    Du kannst das gerne versuchen, und auch gerne davon überzeugt sein, aber es funktioniert trotzdem nicht.
    Jeder von uns "älteren Autodidakten" ist an diesem Punkt irgendwann schon angekommen und glaub mir, wir haben ALLE dabei schon gekotzt.
    Die Kunst ist, über seinen eigenen Schatten zu springen und diese Tatsache zu akzeptieren und dann einen anderen Weg zu wählen. Ob diese Alternative nun besser ist oder nicht, ist zunächst völlig zweitrangig. dafür muss man ausprobieren und ggf. wieder auf die Schnauze fallen. Und das so lange, bis man sich selbst auf die Schulter hauen kann, weil man KEINEN MURKS vorliegen hat!
    DAS ist die persönliche Entwicklung, die dich vorwärts bringt. Und nicht nur beim Programmieren. Denk mal drüber nach ob du als Firmeninhaber lieber einen klugscheißenden, aber immer wieder an falschen Konzepten hinterherrennenden Mitarbeiter haben willst, oder einen Klugscheißer, der, nachdem er auf das falsche Konzept aufmerksam gemacht wurde, am nächsten Tag eine geänderte Lösung vorlegt....


    Autodidakten sind per se ja nichts schlechtes ^^
    Man kann auch, was wesentlich einfacher ist, in einem Forum wie diesem sein Vorhaben darstellen und die möglichen Lösungen diskutieren.
    Dafür ist imho ein Forum da! Und nicht dafür, einen an die Wand gefahrenen Karren schönzureden und bissl Blech auszubeulen. Der grundlegende Schrott bleibt dabei erhalten und hilft ehrlich gesagt niemandem anderen, der diese Threads später bei einer Suche findet....

    Schade, dass die bereits oben erwähnten Funktionen nicht klappen ^^

    Diese Funktionen doktern auch nur an den Symptomen rum. Wieso versuchst du nicht, direkt das Problem zu lösen? ?(

  • Es ist ja eigentlich gar kein Problem. Zumindest sehe ich es nicht als ein solches an. Aktuell funktioniert mein Tool ja reibungslos.
    Ich möchte ja nur verhindern, dass andere Nutzer meines PCs nicht an die Daten in der INI kommen. deshalb das (vielleicht überflüssige) umbenennen in eine DLL und das anschliessende verschlüsseln.

    Zur Zeit kann man aber immer noch an die Daten gelangen wenn das Programm ausgeführt wird. Denn DANN liegt diese INI lesbar vor.
    Gut, sie ist als DLL getarnt, die man mit einfachem Doppelklick nicht öffnen kann, aber sobald sie in einem Texteditor öffnet, kann man alles in Klarsicht lesen.
    Das gilt für mich zu verhindern. Darum dachte ich mir, mit der eingelesenen verschlüsselten Datei weiter zu arbeiten.
    Für mich scheint es die optimalste Lösung zu sein, wenn man die herkömmlichen INI Funktionen so abändern könnte, dass eben auch solche per FileRead eingelesenen Daten verarbeitet werden können.

    BTW: Für mich bist du sehrwohl ein Profi und nein, das ist kein rumgeschleime, nur eine (seit Ewigkeiten bestehende) Feststellung.
    Ich hoffe, morgen gehts weiter, muss jetzt zur Nachtschicht. Bis dann.

  • ...eigentlich gut. Und uneigentlich?

    OT: Eigentlich wollte ich Lottich beruhigen. Eigentlich kann man das verstehen, wenn man möchte. Ein uneigentlich muss es dabei nicht geben. Dabei können wir es doch sicher bewenden lassen Andy.

    Grüße autoiter

  • autoiter: Danke fürs Schlichten, ist aber nicht nötig. Hab mir schon vor Monaten ein dickes Fell bei eBay ersteigert :D

    also hier das Script. Es enthält eine Beispiel ini, so wie sie bei mir aufgebaut ist. unverschlüsselt, aber als DLL getarnt.
    Sie wird bei Scriptausführung im @ScriptDir unter dem Namen test.dll via Base64 erstellt. Wer sich den Code ansieht, wird feststellen, dass KEINE DLL Calls oder ähnliches
    durchgeführt werden. Sie enthält definitiv keine Schadfunktionen. Nach durchlauf des Scripts, wird diese wieder gelöscht, damit kein Datenmüll bei euch bleibt, sofern ihr es testen wollt.

    Hier also das Script:

    Edit 1: Mein Aufbau der INI war fehlerhaft. Deshalb haben einige Funktionen nicht geklappt. Ich hatte, der Optik wegen, die = Zeichen so gesetzt, dass sie eine gerade Linie nach unten bildeten. Deshalb waren offenbar zuviele Leerzeichen oder @TAB zwischen dem Schlüssel und dem = Zeichen. Nachdem ich das geändert hab funktioniert nun fast alles.
    Die letzte Funktion _MemIni_getStringData() wird nicht beendet bzw scheint zu hängen und _MemIni_iniWrite() ändert den Wert nicht.

    Edit 2: Nach gut 190 Sekunden bricht AutoIt das Script ab mit der Fehlermeldung: "Error allocating memory", da hängt es dann in der Funktion _MemIni_getStringData() fest.

  • Im _MemIni_iniWrite() die for-variable in der zweiten schleife auf $l oder so ändern :whistling:

    Inder _MemIni_write hab ich nur nen fehler gefunden, wenn der Wert neu in die Kategorie muss. Dort könntest du, falls der Fehler mit der Änderung immernoch vorhanden ist mal debuggen :)
    Mit meinem Funktionierts...

    Spoiler anzeigen


    Werds auch oben ändern.

  • hi Kanashius

    Hab in der letzten Funktion $i zu $k geändert und nun klappts. Da hätt ich aber auch selber drauf kommen können/müssen.
    Leider besteht das Problem bei _MemIni_iniWrite noch immer.
    Nachdem ich auf Fehlersuche ging, stellte sich heraus, dass es eigentlich funktionieren sollte.
    Die Funktion findet die Sektion, den Schlüssel und den Wert. Der Wert wird auch innerhalb der Funktion geändert.
    2MsgBoxen und 1 _ArrayDisplay() innerhalb besagter Funktion beweisen das.

    Aber im Gegensatz zur von dir im Script erstellten Beispiel INI, wo es natürlich reibungslos klappt, wird es bei mir nicht übernommen,
    obwohl ein und die selbe Funktion zum Einsatz kommt ?(

    nochmals aktualisierter Code mit echter INI (nicht als DLL)