Beiträge von James

Bei Version 3.3.9.5 auch.

Ich denke nicht, dass sich in den letzten paar AutoIt Versionen so viel geändert hat. Und am Betriebssystem sollte es ja eigentlich auch nicht liegen können.

Zitat von Mortal

Ich schaffe es nicht eine Schleife zu erstellen, da ich den Hex-Code in dieser Form brauche: 0x%%
Ich wollte für jeden lauf durch die Schleife den Hex-Code um eins erhöhen.

So sollte es aussehen: 0xB0, 0xB1, 0xB2...
So sieht es aus: B0, B1, B2 ...

"0x" vor die Hex-Zahl zu setzen nützt natürlich auch nichts, da es dadurch ein String wird.
Nett wäre ein Befehl, wie _HexTo0xHex()

Dafür gibt es Dec. Du kannst in deiner Schleife aber auch gleich Dezimalzahlen benutzen, das sollte leichter sein.

Zitat von Trubadour

hast du es auch unter XP versucht?

Nur unter Windows 7, für eine virtuelle Maschine habe ich momentan nicht genug Speicherplatz.

Ich habe allerdings gerade mein altes Windows 2000 Laptop wieder vom Schrank geholt, und auch dort verhält es sich wie bereits vermutet.

Die verwendete Dateiauswahl würde in AutoIt etwa so aussehen:

FileOpenDialog("Open", @UserProfileDir, "All Files (*.*)")

Es ist nicht möglich, dass dort Dateien nicht angezeigt werden. Selbst bei einem anderen Filter würde sowas nur nach der Dateiendung entschieden werden, nicht nach 32 oder 64 Bit, da die Dateiauswahl den Inhalt der Dateien komplett ignoriert.

Du könntest .+? durch [^,]+? ersetzen, da in den Parametern sowieso kein Komma vorkommen darf. (Sollte funktionieren, ist ungetestet.)

Zitat von Trubadour

Ich arbeite sonst auch mit Iexpress. Einen Anwendungsfehler meinerseits schließe ich aus. Das Dateifenster enthält die 64bit exe einfach gar nicht erst????

Wenn wir so weitermachen hast du dein Problem auch in zehn Jahren noch.
Ich habe ja vorhin schon versucht zu erklären, dass dein Problem eigentlich nicht möglich ist, und zwar wirklich unmöglich und nicht wie in "so schlecht kann Windows doch eigentlich gar nicht programmiert sein, aber irgendwie tritt das Problem trotzdem auf." Du schließt aus, dass der Fehler bei dir liegt: ok, bei der Bedienung von IExpress kann man ja auch nicht so viel falsch machen. Was allerdings ein Problem ist, ist deine Fehlerbeschreibung. Wie schon gesagt, das Problem sollte in dieser Form eigentlich nicht auftreten können; getestet habe ich das Ganze vor dem Schreiben meines ersten Kommentars auch. Also entweder machst du einen Fehler, oder deine Version von IExpress ist (trotz gleicher Versionsnummern) komplett anders. Statt also nur "Das Dateifenster enthält die 64bit exe einfach gar nicht erst????" zu schreiben, wäre eine genaue Beschreibung oder ein Screenshot vielleicht angebrachter.

MfG James

Edit: Eine Alternative (neben dem schon erwähnten selbst geschriebenen Installer) wäre zum Beispiel WinRAR (oder jedes andere Programm mit ähnlichen Features).

Es taucht nicht auf?
Du bist doch irgendwann im Bereich "Packaged files," oder? Dort klickst du dann auf "Add" und erhälst ein normales Dateiauswahlfenster, in diesem muss dein Programm angezeigt werden, da dort alle Dateien angezeigt werden. Oder hast du eine andere Version von IExpress als 2.0?

Und wieso sollte das nicht mit IExpress funktionieren? Du erstellst ein Programm um Dateien zu packen / extrahieren, da besteht überhaupt kein Zusammenhang zu dem Typ / Format der ausführbaren Datei.

Edit: Und sollte das bei dir wirklich nicht funktionieren kannst du den Installer ja immer noch mit AutoIt erstellen, das ist auch nicht sehr schwer.

Zitat von minx

[Blockierte Grafik: http://1.2.3.12/bmi/f56.img-up.net/shirtentwu957a.png]

Bist du mit dem Handy online? T-Mobile (falls du das überhaupt benutzt) scheint nämlich dauernd die URLs der Bilder zu ändern, sodass die von uns niemand sieht (oder zumindest ich nicht, sollte bei den anderen aber auch nicht gehen).

Nicht nur einen.
1) Dein Button sollte vielleicht vor GUISetState (ist rein kosmetisch).
2) Die Variablen solltest du einmal am Anfang des Skriptes deklarieren.
3) Du solltest vielleicht das Anklicken des Buttons abfragen.

Do
Switch GUIGetMsg()
Case $GUI_EVENT_CLOSE
Exitloop
Case $Weiter
$Dux = GUICtrlRead($DuxFile)
If (StringLen($Dux) < 6) Then
MsgBox(16, "Fehler", "Der Dateiname muss mindestens 6 Zeichen lang sein.")
Else
; dein Code hier
EndIf
EndSwitch
Until False

Zitat von Commander21

Leider kann man ein fertiges Script immer noch dekompilieren, die Passwortabfrage raus schneiden und neu kompilieren...

Eben. Ich zitiere an dieser Stelle einfach mal Andy:

Zitat von Andy

Jeder Anfänger im Knacken von Programmen per Passwortabfrage lernt in der ersten Viertelstunde, wie man per Debugger einen Haltepunkt an der Passwortabfrage setzt, und diese dann einfach überspringt oder auskommentiert.
Für absolute Vollidioten ohne jegliche Ahnung gibt es Youtube-Tutorials, die diese Vorgehensweisen bis ins allerkleinste Vorführen...
Soviel zum "Sinn" einer Passwortabfrage in einem Programm!

Nun dazu, dass man das Passwort (wie auch immer) verschlüsselt im Zugriff des Programms ablegt. Ob das Passwort im Klartext in einer Textdatei, oder nach (wieauchimmer)-Verschlüsselung irgendwoanders abgespeichert ( was unterscheidet eine dll von einer anderen Datei? ) ist, spielt keine Rolle. Vorhanden ist vorhanden und somit "knackbar" oder zumindest verwendbar.

Du kannst das Programm durch Verschlüsseln und andere Methoden natürlich schwerer "hackbar" machen, aber es ist trotzdem möglich und wird auch immer möglich sein.
Zu 1) Du kannst die Datei verschlüsseln und ein Programm zum entschlüsseln mitliefern (oder sie sich selbst entschlüsseln lassen im Falle eines Programmes). Aber was bringt dir das? Wenn das Programm nur mit dem Passwort gestartet werden kann, wieso willst du es dann überhaupt veröffentlichen? Und wenn du es nicht veröffentlichst, dann brauchst du es auch nicht vor "Hackern" zu schützen.

(All diese Methoden sind mit AutoIt sowieso nur schwer bzw. gar nicht umsetzbar.)

Hier mal meine Lösung. Ich habe zwar nicht deine Funktionen verwendet, hoffe aber, dass es trotzdem verständlich ist. Negative Zahlen als Ergebnis sind noch ein Problem, ansonsten funktioniert es.

Func _Add($A, $B)
Local $C = 0, $i, $bitA, $bitB, $result, $carry = 0
For $i = 0 To 30
; Bit an Position $i
$bitA = Int(BitAND($A, 2^$i) <> 0)
$bitB = Int(BitAND($B, 2^$i) <> 0)
; Berechnung
$result = BitXOR($bitA, $bitB, $carry)
$carry = BitOR(BitAND($bitA, $bitB), BitAND($bitA, $carry), BitAND($bitB, $carry))
; Ergebnis speichern
$C = BitOR($C, $result * 2^$i)
Next
Return $C
EndFunc

MfG James

Hallo Community!
Ich beschäftige mich derzeitig wieder mit logischen Operatoren. Den theoretischen Teil habe ich hinter mir, aber mich würde nun einmal wirklich interessieren, wie ich dies praktisch umsetzen kann. Dazu habe ich mir einmal angesehen, wie der PC intern addiert, subtrahiert, multipliziert und dividiert. Bis auf die Division habe ich soweit alles verstanden und möchte dieses Verfahren nur mit den Bit-Befehlen und den logischen Operatoren nachprogrammieren. Allerdings hänge ich nun bei einem logischen Problem bei der Addition. Ich schaffe es einfach nicht, die Bits mithilfe der logischen Operatoren so auszuwerten, dass einmal der Überlauf in einer Variable gespeichert wird und auch das Ergebnis an der entsprechenden Stelle selber. Als Hilfe (um auf Bit Ebene besser arbeiten zu können) habe ich mir einige Funktionen dazu geschrieben.

Mit Hilfe dieser Funktionen (Welche selber die logischen Operatoren und auch Bit-Befehle verwenden) möchte ich nun eine Addition zweier Zahlen erreichen. Insgesamt gibt es dort 8 mögliche Kombinationen. Nun geht es darum das Ergebnis heraus zu bekommen und den Überlauf (als + markiert).

Zahl 1   -> 00001111
Zahl 2   -> 00110011
Überlauf -> 01010101
--------------------
Ergebnis -> 01101001
         ->    + +++

Wie man hoffentlich erkennen kann, habe ich den Überlauf in meinen Überlegungen mit einbezogen.

Hat jemand vielleicht einen Denkansatz wie ich nun dieses Problem bewältigen kann?
Nochmal zur Erinnerung: Ich möchte eine Addition nur mit Hilfe von den logischen Operatoren und auch den Bit-Befehlen erreichen.

LG. Make

Anmerkung von James: Make hat momentan anscheinend ein paar Probleme mit dem Forum, also erstelle ich den Thread für ihn.

Achso, ich dachte schon er hat einfach nur WEnd falsch geschrieben.

Zitat von Andy

Dann ist es nur eine Frage des Aufwandes und der Hartnäckigkeit, ein Programm zu knacken.

Und des Talents, und das werden 99% der Benutzer je nach den vorgenommenen Sicherheitsmaßnahmen nicht haben. Aber du hast natürlich Recht, 100% schützen kann man ein Programm nie. Reverse Engineering ist zum Glück noch ein Bereich, in dem nicht nur das Drücken eines Buttons in einem beliebigen Tool ausreicht (denke ich zumindest).

Achso, ok, jetzt habe ich verstanden, wie du das meinst. Man könnte so also das Programm mehreren Leuten mit unterschiedlichen Passwörtern geben, ohne es jedes mal neu "kompilieren" zu müssen. Da ist diese Variante natürlich besser.
Und wie du schon angedeutet hast: Wenn man sein Programm wirklich sichern will muss man eben auf eine richtige Programmiersprache umsteigen (z.B. Assembly).

MfG James

Aber wenn man das Passwort sowieso hasht, muss es dann noch extra gesichert (in diesem Fall "versteckt") werden? Mit dem Hash könnte ein potentieller Angreifer doch sowieso nichts anfangen, oder? Man könnte statt MD5 ja auch SHA-256d benutzen.

Nette Idee, auch wenn ich die Verwendung der globalen Variablen als Speicher für die Zahlensysteme und das riesige Array in der Funktion etwas eigenartig finde.

Ich hätte das so gemacht (funktioniert nur bis Basis 36):

MfG James

Am Anfang der Funktion wäre $iDecimal *= -1 oder Abs() vielleicht besser als StringTrimLeft, du willst ja nicht die Fehleranfälligkeit von AutoIt beim Umwandeln von Datentypen durch sinnloses Hin- und Herwandeln unterstützen.

Zitat von Joriktos

Also an sich ist die Idee sehr gut und du hast es auch sehr gut umgesetzt

Danke.

Zitat von Joriktos

Aber dafür muss es halt erstmal eine große Database geben.

Dazu bräuchte man auch erstmal ein geeignetes Thema. Ich glaube nicht, dass die Flugfähigkeiten von verschiedenen Vögeln hier viele Anhänger finden würden.