Beiträge von Andy

Zitat von AspirinJunkie

"efg" - ist doch auch korrekt oder hab ich was übersehen?

Ja, lass dir das Ergebnis von binary("0x656667") ausgeben *hust*

Die "Überraschung" war doch, dass FileRead() aus einer mit Text gefüllten Datei "automatisch" UTF8 dekodiert, auch wenn ich das garnicht haben möchte!
Meine Intention mit dem Filewrite(binarytostring("0x67520A...")) war, beim Schreiben in die Datei die eventuell auch automatisch erfolgende "Umformung" von Text in UTF8 zu vermeiden.
Ich arbeite sehr viel mit Textdateien und auch mit Binärfiles, sowohl schreibend als auch lesend, aber dieses Verhalten von Fileread ist mir noch nicht untergekommen...

Richtig übel wird das, wenn in bspw. Config/Ini-Files "zufällig" valide UTF8-Kodierungen enthalten sind, welche dann als gänzlich andere Daten gelesen werden.
Wenn ich in einer Textdatei äöü' enthalten habe, dann hat das auch von FileRead() so ausgelesen zu werden und nicht als äöü'

Zitat von nnako

- keine Notwendigkeit zur Eingabe von zusätzlichem Code um das Debugging durchzuführen

"nativ" nicht möglich

Zitat von nnako

- dynamische Unterbrechbarkeit des Programmdurchlaufs an beliebiger Stelle

überflüssig, da "beliebige" Stellen beim Debugging irrelevant sind.
Wenn du nicht weißt, nach was und wie du suchen sollst, ist "irgendwo nachschauen ob sich etwas getan hat" unsystematisches rumgestochere.

Zitat von nnako

- Einzelschritt-Modus der Programmabarbeitung sowie Breakpoints und Trigger

Funktioniert einwandfrei per Trace. Breakpoints musst du auch in einem "richtigen" Debugger setzen, und ob du jetzt dort per Tastenkombi einen Breakpoint im Code setzt, oder in Scite per Tastenkombination eine Msgbox/Consolenausgabe bleibt der gleiche Aufwand.

Zitat von nnako

- dynamische Konfigurierbarkeit der Ausgabe beliebiger Variablen und Speicherauszüge

Variablen und Arrays geht noch, aber bei Listen/Dictionarys, da werden auch "gestandene" Debugger schwach.
Speicherauszüge nützen auch nur dann, wenn man weiß, wonach man suchen muss!
Die Anzahl der Anwender eines Debuggers, welche auch noch Speicherinhalte auslesen "müssen", beziffere ich in AutoIt unter 1% !
Mit Hinblick auf die Zielrichtung von AutoIt, andere Programme "fernzusteuern", (ich gehe davon aus, dass das die Hauptanwendung von AutoIt ausmacht) sind "professionelle" Debugger schlichtweg überflüssig.

Nicht dass ich hier falsch verstanden werde:
Ein von den Entwicklern bereitgestellter Debugger ist lange fällig. Allerdings ist es auch fraglich, ob dieser überhaupt benutzt würde! Und das meine ich jetzt mit Hinblick auf die Frage

Zitat von nnako

Gibt es zur Einrichtung solcher Tasten-Shortcuts und der entsprechenden Code-Teile bereits nutzbare Anleitungen hier im Forum?

Diese "Shortcuts" sind bereits in Scite enthalten, im Reiter "Extras", wie übrigens im Startpost beschrieben. Über LUA-Scripte ist die Anpassung meist nur Fleißarbeit.
Ich lehne mich mit Sicherheit nicht weit aus dem Fenster wenn ich behaupte, dass 90% der AutoIt-Anwender nicht mal wissen, welche Befehle dort hinterlegt sind und was diese bewirken. Das sieht man anhand der Fragestellung in sämtlichen Foren, unformatierten Code zu posten, obwohl Tidy nur einen Tastenschlag entfernt ist...

@nnako, schau dir doch die AutoIt-Debugger an, ggf. sind diese für dein Vorhaben schon ausreichend!
Im "blauen" Forum wirst du fündig. Ggf. hast du selbst Intentionen an solch einem Projekt mitzumachen oder auch nur "kleine" Verbesserungen/Scripte zur Hilfe fürs Debugging zu schreiben

Zitat von supernova

FFFE fehlt.

Weil....es....nicht....da....ist!

Wie viele Bytes beinhaltet die Datei?
Und nicht mit irgendwelchen Programmen/HexEditoren auslesen (die man übrigens bedienen können sollte) sondern einfach aus dem Explorer die Dateieigenschaften.
Die beiden Dateien bestehen aus:

https://autoit.de/index.php/Atta…atei-UTF-8-txt/
0x6D757374657264617465695F5554462D382E7478740D0AC3A4C3B6C3BC270D0A 32 bytes
der erste Teil ist ANSI
0x6D757374657264617465695F5554462D382E747874 -> musterdatei_UTF-8.txt
dann folgen 0D0A -> CRLF
dann die ANSI-Zeichen C3A4C3B6C3BC27 -> äöü' , interpretierbar als UTF8 ->äöü'
gefolgt von einem weiteren 0D0A -> CRLF

https://autoit.de/index.php/Atta…datei-ANSI-txt/
0x6D757374657264617465695F414E53492E7478740D0AE4F6FC270D0A 28 bytes
0x6D757374657264617465695F414E53492E747874 -> musterdatei_ANSI.txt
dann folgen 0D0A -> CRLF
dann die ANSI-Zeichen E4F6FC27 -> äöü'
gefolgt von einem weiteren 0D0A -> CRLF

@AspirinJunkie,
*whispermode ON* schau mal geschwind nach, was binarytostring($text) aus $text="0x656667" macht *whispermode OFF*

Man sollte den DEV´s mal auf den Hut hauen....

Wäre echt mal interessant zu wissen, auf welcher Grundlage ein UTF8 innerhalb einer Datei "konvertiert" wird!

$text="0x6D757374657264617465695F5554462D382E7478740D0AC3A4C3B6C3BC270D0A"
;~ $text="0x6D757374657264617465695F5554462D382E747874C3A4C3B6C3BC270D0A"


;$text="0xA4C3B6C3BC270D0A" ;utf-8


;1.Versuch textdatei mit UTF8-Anteil
filedelete("utf8test.txt")
filewrite("utf8test.txt",$text)


$a=fileread("utf8test.txt")
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $a = ' & binarytostring($a) & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console




;2. Versuch
$text2=binarytostring($text) ;utf-8


filedelete("utf8test.txt")
filewrite("utf8test.txt",$text2)


$a=fileread("utf8test.txt")
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $a = ' & $a & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console




;3.versuch nur die letzten 5 Zeichen in UTF8
$text3=binarytostring("0x"&stringright($text,20)) ;utf-8


filedelete("utf8test.txt")
filewrite("utf8test.txt",$text3)


$a=fileread("utf8test.txt")
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $a = ' & $a & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console




;4.versuch nur die letzten 4 Zeichen in UTF8
$text4=binarytostring("0x"&stringright($text,16)) ;utf-8


filedelete("utf8test.txt")
filewrite("utf8test.txt",$text4)


$a=fileread("utf8test.txt")
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $a = ' & $a & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

//EDIT
Wenn ein LF (0x0A) vor dem UTF-Code steht, wird "transmutiert"^^
//EDIT2 wenn der Code "valide" UTF-Texte (als Kodierung) beinhaltet, wird automatisch dekodiert

Zitat von gango

irgendwie müsste man doch ohne wenn und aber eine Datei 1:1 einlesen können!

Funktioniert einwandfrei mit FileOpen() im Binary-Modus 16!

Übrigens liest auch FileRead("Datei.exe") ein EXE-File problemlos mit allen Bytes ein!
Das "UTF-Textdatei-Syndrom" tritt auf, weil AutoIt´s FileRead() den Dateiinhalt analysiert und "automatisch" konvertiert!
s.Testscript in Post 9

Zitat von AspirinJunkie

Eigentlich nicht ganz...

nimm mal die 3.3.6.1....man sollte bei aktuellen Diskussionen die aktuellen Versionen nutzen!
Habe meinen Post editiert, incl. Testscript.

AspirinJunkie hat (wie immer) Recht!

Fileread("dateiname.bla") ist es herzlich egal, in welchem Format eine Datei vorliegt, es werden BYTES eingelesen!
//EDIT falsch, Fileread(Dateiname) konvertiert beim Einlesen!, daher sollte FileOpen(Dateiname,16) zum Einlesen in Binary genutzt werden.

Wer mag, kann erst FileOpen() nutzen, sollte dann aber tunlichst auf den Modus achten, ansonsten passieren nämlich die vom TE festgestellten "Fehler".

Zitat von AspirinJunkie

Im UltraEdit muss man übrigens aufpassen bei der HEX-Ansicht nicht "HEX Edit/EBCDIC" zu verwenden sondern nur den normalen Hex-Edit.

was der Grund ist, wieso ich seit Jahrzehnten nur "einfachste" Hexeditoren nutze! Nichts ist schlimmer, als von unrichtigen Vorgaben auszugehen!

//EDIT2
Testscript

$ansifile="Musterdatei-ANSI.bin"
$utf8file="Musterdatei-UTF-8.bin"




filedelete($ansifile)
filedelete($utf8file)


$a=inetget("https://autoit.de/index.php/Attachment/83223-musterdatei-ANSI-txt/",$ansifile,1)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $a = ' & $a & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
$b=inetget("https://autoit.de/index.php/Attachment/83224-musterdatei-UTF-8-txt/",$utf8file,1)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $b = ' & $b & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console




$m=inetread("https://autoit.de/index.php/Attachment/83223-musterdatei-ANSI-txt/",1)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $m = ' & binarytostring($m) & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
MsgBox(262144, 'Debug line ~' & @ScriptLineNumber, 'Selection:' & @CRLF & '$m' & @CRLF & @CRLF & 'Return:' & @CRLF & binarytostring($m)) ;### Debug MSGBOX




$n=inetread("https://autoit.de/index.php/Attachment/83224-musterdatei-UTF-8-txt/",1)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $n = ' & binarytostring($n) & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
MsgBox(262144, 'Debug line ~' & @ScriptLineNumber, 'Selection:' & @CRLF & '$n' & @CRLF & @CRLF & 'Return:' & @CRLF & binarytostring($n)) ;### Debug MSGBOX






$x=Fileread($ansifile)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $x = ' & stringlen($x) & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
msgbox(0,"ANSI "&$a&" Bytes",$x&@crlf&@crlf&binarytostring($x))




$y=Fileread($utf8file)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber &') : $y = ' & $y & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
msgbox(0,"UTF-8 "&stringlen($y)&" Bytes","FEHLER! Nur 29 Bytes statt 32 eingelesen!" & @crlf &$y&@crlf&@crlf&binarytostring($y))




$handle=fileopen($utf8file,16)
$y=Fileread($handle)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $y = ' & $y & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
fileclose($handle)
msgbox(0,"UTF-8 "&stringlen($y)/2-1&" Bytes","RICHTIG! 32 Bytes eingelesen!"&@crlf&$y&@crlf&@crlf&binarytostring($y))

@autoiter,

du zitierst mich mit einem BERECHNUNGSFEHLER und gibst Beispiele eines Überlauf/Syntax/Compilerfehler/Exception-Fehlers!
Das eine hat mit dem anderen nichts zu tun!
In anderen Programmiersprachen gibt es glücklicherweise das "On Error Goto" (ja, auch in C(++) !! ), welches bei einem Ausnahmefehler in entsprechende Routinen springt und dort abgewickelt werden kann. Das ist der von mir beschriebene "Traum", da der "Fehler" bereits lokalisiert ist und man einen Anfangspunkt fürs Debugging hat!

Ein BERECHNUNGSFEHLER wird dort niemals detektiert!
Den findet man nur durch systematisches Ausgeben von Zwischenergebnissen. Man fragt sich:" Der Inhalt von $var sollte hier 1234 sein, ist aber 678, der "Fehler" muss vorher liegen!"
Und das nimmt einem kein Debugger der Welt ab...
Natürlich erlauben "richtige" Debugger die Eingabe von "Überwachungsparametern", aber was bringt mir das?
Ich muss sowieso Breakpoints setzen, von Hand "tracen", uswusf.
Da kann ich in AutoIt auch DebugMsgboxen oder Consolenausgaben per Tastaturshortcut in den Code eingeben, den Fehler finden und per Shortcut alle wieder loswerden!

Im Prinzip ist "Debugging" eine Erfahrungssache, sichtbar hier im Forum. 99% der hier mit "funktioniert nicht" geposteten Scripte sind durch simpelstes Debugging, wie im Startpost schon erwähnt, auch von Anfängern lös- und somit vermeidbar! Die "Cracks" machen definitiv nichts anderes, kaum jemand "fliegt die Lösung einfach so zu".
Man muss es einfach machen!
Manche "Fehler" sind echt tricky, aber was solls, da kniet man sich halt rein und nimmt Zeile für Zeile und Befehl für Befehl auseinander....learning by doing!

Hi,

Debugging von "großen" Projekten (bei mir teilweise mehrere zehntausend Zeilen Code) funktioniert wie oben angegeben!
Mittlerweile debugge ich zwangsweise auch Code von anderen in diversen Programmier/Scriptsprachen. Ohne deren explizite "Debugger".
Die anderen Programmierer sind immer erstaunt, wie schnell jemand in "fremdem" Code Fehler findet.

Was erwartest du? Ein Programm, welches du aufrufst und dass du parallel zu deinem Script laufen lässt, welches bei einem Berechnungsfehler ein Fenster öffnet "In Zeile 24761 wird ein nullbasiertes Array erst von vom Item 1 aus ausgelesen!" ?

Debuggen/Fehler suchen läuft darauf hinaus den Fehler zu analysieren, dessen Ursache zu finden und diese zu beseitigen.
Dazu muss man sich intensiv mit dem Code auseinandersetzen, diesen verstehen und die erwarteten Ergebnisse verifizieren.

Aber zu deinen Fragen zum AutoIt-Debugger:
Ich hatte diese Programme schon benutzt, allerdings waren die selbst massiv verbugged. Ich kann kein "Hilfsprogramm" brauchen, welches mich bei meiner Arbeit ausbremst. Debuggen ist eine Arbeit, für welche man hochkonzentriert sein muss. Da muss ein schnellstmöglich ein Ergebnis her, und nicht ein weiterer Grund sich aufzuregen....

Meistens läuft es doch darauf hinaus, fehlerhafte Berechnungen finden zu müssen. Da ist die schrittweise Ausgabe von Variablen zur Überprüfung imho der schnellste/einfachste Weg!
Ein Fehler, welcher schon vom Compiler/Interpreter geworfen wird ist doch der Traum! Da muss man sich um die Lokalisation keinerlei Gedanken mehr machen!

Beschreibe deine Fehler, ggf. kann dir jemand konkrete Tips zum "debuggen" geben!

Zitat von AspirinJunkie

Aber die Aussage, dass der wahre Wert z.B. mit 99% zwischen 0,68 und 0,7 V liegt kann dir erstmal keiner nehmen.

Und genau das ist mein Problem! Der "wahre Wert" einer einzelnen Messung ist eben NICHT 0,69 (auch wenn zu 99%) sondern eben 0,68734521.
Natürlich könntest du jetzt, mit statistischen Mitteln die Messungenauigkeit eliminierend, davon ausgehen, dass dieser Wert auch nicht "genau" ist, sondern nur zu einem gewissen Anteil, da auch die Messergebnisse statistischen Einflüssen unterliegen.....

Das Rauschen hat nur deswegen ein Muster mit einer bestimmten Verteilung, weil vorher die

Zitat von AspirinJunkie

begründete Eliminierung von unerwünschten Seiteneffekten,

vorgenommen wurde. Denn genau diese Ausreißer sind doch zufällig?!
Ich habe mit der Statistik dasselbe Problem wie der Mann, der aus dem 10. Stock gefallen ist. Bei jedem Stockwerk, an dem er vorbeigeflogen kam hat er gesagt: "Bis jetzt ging´s gut!"

Zitat von AspirinJunkie

Im Falle einer Dunkelaufnahme weiß man eindeutig, dass die Werte keine Nutzinformationen sind.
Es handelt sich um einen systematischen Anteil der die späteren Nutzdaten überlagert.

Das Kamerasystem wird aber doch genau auf diesen Fall "Dunkelaufnahme" abgestimmt! Das heißt nichts anderes, als dass bei einer Dunkelaufnahme (ein bestimmter statistischer Grenzwert wird unterschritten) ALLE, d.h. auch die Sensoren, welche ZUFÄLLIG (!!) von einem länger dauernden Photonenschauer angeregt werden, an ebendiesen Grenzwert angeglichen werden.

Natürlich gehören die Ausreißer mit in den zu betrachtenden Wertebereich. Aus demselben Grund wird Lotto/Glücksspiel gespielt und gewonnen.

Zitat von AspirinJunkie

Man könnte keine Raumfahrtmissionen planen da man nicht abschätzen kann wie nah man an den gewünschten Himmelskörper gelangt.
Geräte würden reihenweise ausfallen weil keiner wusste welche Ausfallrate die verbauten Bauteile besitzen.
Homöopathie wäre das Standardverfahren in der Medizin weil keiner ihre Wirkung und das anderer Verfahren prüfen könnte.
Und das Schlimmste von allen: Alle Vermesser wären arbeitslos!

- Mit Schätzungen befasse ich mich berufsweise, Schätzen hat aber nichts mit Wahrscheinlichkeiten zu tun, sonst bräuchte man nicht Schätzen sondern könnte sich auf Berechnungen verlassen!
- Geräte fallen reihenweise aus, weil minderwertige Bauteile verwendet werden, und nicht weil die Ausfallrate dieser Bauteile in einem bestimmten Bereich liegen.
- In der Medizin hilft ein Medikament 10000 Menschen, aber einer stirbt an der Unverträglichkeit. Für diesen einen ist es ziemlich unerheblich, ob das Medikament ein bestimmtes statistisches Verfahren erfolgreich (?!) durchlaufen hat! Aus welchem Grund sind selbst die Beipackzettel für 08/15-Medikamente seitenlang? Wieso schreibt man nicht einfach einen einzigen Satz hinein, "Machen sie sich keine Gedanken, die Möglichkeit einer Unverträglichkeit liegt statistisch nur bei 0,234 Promille".
- Vor ca. 4500 Jahren haben Vermesser die Grundlage für den Bau noch heute stehender Pyramiden gelegt. Andere Bauwerke weltweit sind fast ebenso alt. Ich ging erst letzte Woche über eine von Römern vor 2000 Jahren erbaute Brücke. Auch bei deren Bau hat sicherllich ein Vermesser die Finger im Spiel gehabt!
Es kann natürlich sein, dass heutige Vermesser ohne stochastische Mittel trotz tausendfach genauerer Meßgeräte aufgeschmissen sind!
Ich gehe bei genauerer Betrachtung allerdings davon aus, wie sonst kann es sein, dass trotz hochmodernem Equipment die Halbwertszeit von Gebäuden immer kleiner wird?
https://de.wikipedia.org/wiki/Schiersteiner_Brücke Da hat wohl die Stochastik nicht so ganz hingehauen...

Zitat von http://www.ruhr-uni-bochum.de/geodaesie/download/Skript_Teil_3-Statistik.pdf

In der Vermessung werden Messungen stets überbestimmt ermittelt, d.h. es werden mehrMessungen durchgeführt, als zur eindeutigen Bestimmung einer Lösung notwendig sind. DieÜberbestimmungen dienen sowohl der Kontrolle einer Messung als auch der Steigerung derGenauigkeit.

Zitat

SystematischeFehler sind Einflüsse, die Messergebnisse reproduzierbar in eine Richtung verfälschen. Sielassen sich deshalb nicht durch mehrfaches Messen eliminieren und müssen deshalbunbedingt vermieden oder richtig berücksichtigt werden.

Die zufälligen Fehler sollten theoretisch bei einer unendlichen Zahl von Messwiederholungendurch Mittelbildung in ihrer Auswirkung vollständig verschwinden.

Also überbestimmt Messen damit die Genauigkeit erhöht wird und gleichzeitig die systematischen Fehler unbedingt vermeiden. DAS ist ja spannend

Aber um den Bogen zum Thema zu schlagen:
Sind Bildsensoren bzw. deren Daten nicht für den von uns benötigten "Zufall" nutzbar?

Zitat von AspirinJunkie

Sensorrauschen ist ein zum größten Teil kein zufälliger sondern ein systematischer Effekt welcher lediglich stochastisch verteilt ist.

Wobei wir wieder beim Problem wären, mir plausibel den Sinn der Wahrscheinlichkeitsrechnung/Stochastik erklären zu wollen, bzw. "Wahrscheinlichkeit" zu erklären!
Fällt die Münze beim nächsten Wurf auf die Kopf- oder Zahlseite, DAS ist interessant!
Und bisher kannte ich nur sehr wenige Mathematiker, die darauf ihr Leben verwetten würden!
Ob die Münze bei den vorhergehenden 17 Würfen immer auf Zahl gelandet ist, spielt dabei nämlich überhaupt keine Rolle!
Die Wahrscheinlichkeitsrechnung verwettet ihr Leben allerdings darauf, dass beim 18. Wurf endlich "Kopf" erscheint...genauso wie darauf zu Wetten, dass man aus dem Beutel mit 100 weißen Kugeln beim einmaligen Ziehen NICHT die eine Schwarze Kugel erwischt!

Du sprichst beim Sensorrauschen von Wahrscheinlichkeitsverteilung, welche aber überhaupt nichts mit dem "Zufall" zu tun hat!
Wie äußert sich denn bei einem einzigen Sensorpixel, also einer einfachen Fotodiode, ein "systematischer Effekt, welcher lediglich stochastisch verteilt ist"?
Wie sieht die ungeglättete Ausgangsspannung dieser Diode bei Verwendung als "Solarzelle" aus? Das kann sich jeder mit einem Oszilloskop und einer unbeschalteten Fotodiode im Mikrovoltbereich anschauen! "Im statistischen Mittel" beträgt die Spannung bei entsprechendem Lichteinfall 0,68V. Schaue ich mir aber die Spannung "genau" an, dann sehe ich einen Bereich zwischen 0,68500 und 0,69500 Volt! Und das bei 10khz! Dort einen immer sich ändernden Wert abzugreifen, ist "Zufall"

Die Fotodiode ist, abhängig von ihrer Verstärkerschaltung, als Einzelstück nur dann zu gebrauchen, wenn sie auf einen bestimmten Bereich kalibriert wurde!
In einem Bildsensor ist das natürlich herstellungstechnisch nicht oder nur extrem schwer möglich, daher packt man die Dioden in ein 2D-Array und schaut sich deren Ausgabe bei "gleichmäßiger Beleuchtung" an. Und auch hier greift keinerlei Stochastik, es werden die "Hotpixel" erkannt und softwaretechnisch eliminiert/"nachkalibriert". Allen anderen Pixel geht es genauso! Dabei werden idR die benachbarten Pixel für eine Angleichung benutzt. Wenn man so will, ein "Blur" der Hardware
Entstehen aus irgendwelchen Gründen nach einigen Wochen/Monaten/Jahren weitere Hot- oder fehlerhafte Pixel, können diese nachträglich per Software angepasst werden!

Ich hatte mich dahingehend mal mit einem Mitarbeiter bei Nikon ( I am a Fanboy! ) unterhalten, und bin damals davon ausgegangen, dass bei einem (ja, es ist lange her) 5 Megapixel Sensor nur eine "Handvoll" Fehlpixel zu kompensieren sind. Tatsächlich werden TAUSENDE der Dioden "gesundgerechnet". Natürlich nicht bei einer "Knipse", da lebt man einfach damit, aber bei Kameras der obersten Leistungsklasse können einzelne Dioden "angepasst" werden. Sehr beeindruckende Technik übrigens...

siehe EDIT 2 im oberen Post

Naja, spielen wir das mal durch:

Du bekommst von mir eine verschlüsselte Nachricht. Auf deiner Festplatte hast du 1000/10000/100000 Bilder, die ich auch habe (das wäre dann der "lange" Schlüssel.)
Mal angenommen, ich würde "vergessen", dir den Schlüssel mitzuteilen, dann hättest du bei der heutigen Rechnerleistung trotzdem innerhalb weniger Sekunden den Text entschlüsselt!
Ich könnte dir auch eine SMS schicken mit "ruf Tante Agathe an unter 0171-54231499", dann müsstest du das Bild "Tante Agathe" öffnen und als Pixel-Startadresse fürs Entschlüsseln 31499 .

Ich könnte auch mit AES verschlüsseln, wie kommt der Schlüssel dann zu dir?

//EDIT
Sämtliche Verschlüsselungsverfahren sind nur dann wirksam, solange man den Schlüssel "geheim" halten muss.
Ob ich jetzt einen 64/128/256 Bit/Byte "langen" Schlüssel mit Verfahren wie AES "aufpumpe" um per XOR damit Nachrichten zu verschlüsseln, oder direkt einen entsprechend "langen" Schlüssel verwende und damit dann die Nachricht XORe, ist unerheblich.
Wieso wird heutzutage "gesalzen"? Naja, so gaaaanz sicher, dass der "kurze" Schlüssel einem Angriff standhält, ist man nicht! Also wird der Schlüssel verlängert.
Imho überflüssig, die Arbeit kann man sich sparen!

//EDIT 2
Wie macht man das mit den OTPs im realen Leben?
Dein Handy klingelt, du hast eine Minute Zeit, auf den Knopf deines OTP-Generators zu drücken und dieser gibt dir einen Zugangscode aus, welcher auch nur eine Minute gültig ist. Dieses Verfahren steht und fällt mit der Hardware. In allen Generatoren eines "Geheimbundes" ist ein irgendwie programmierter Timer enthalten, welcher zu einer bestimmten Zeit einen auf allen Generatoren identischen Zufallscode erzeugt.
Aber jetzt entsteht erst das eigentliche Problem, welches die NSA elegant gelöst hat (per Hard-und Softwareverwanzung).
Du musst diesen Zugangscode ja irgendwo eingeben....
Also wieso nicht direkt die Nachricht an die OTP- Hardware übertragen und dort entschlüsseln? DAS wäre doch die Lösung! Nur schade, dass die dafür nötigen Chips alle von Firmen kommen, denen man bedenkenlos vertrauen kann...."Alda isch schwör, NIEMAND kennt unsere Verfahren! Trust me, i don´t be evil!"

Hi,
deine Idee ist richtig, über den Weg (das Script) kann man diskutieren

Nur zur Info, die "Pixel" eines Bildes kann man einfach in eine Struct (das ist nichts anderes als ein Array) laden

#include <GDIPlus.au3>
#include <GDIPlusConstants.au3>






_GDIPlus_Startup()


$sFile = FileOpenDialog("Datei", @ScriptDir, "Bilder (*.jpg;*.bmp;*.png)");"mona-lisa.jpg"


$himage = _GDIPlus_ImageLoadFromFile($sFile)        ;Bild laden
$iHeight = _GDIPlus_ImageGetHeight($himage)         ;höhe
$iWidth = _GDIPlus_ImageGetWidth($himage)           ;breite


$tBitmapData = DllStructCreate("byte[" & 4 * $iWidth * $iHeight & "]") ;4 byte/pixel
$ptr_bitmap = DllStructGetPtr($tBitmapData)         ; pointer auf die Bitmapdaten
$hBitmap = _GDIPlus_BitmapCreateFromScan0($iWidth, $iHeight, $GDIP_PXF32ARGB, 4 * $iWidth, $ptr_bitmap)


$hCtxt = _GDIPlus_ImageGetGraphicsContext($hBitmap) ;Kontext


_GDIPlus_GraphicsDrawImage($hCtxt, $himage, 0, 0)   ;Pixel in Kontext schreiben


$Pixel = DllStructGetData($tBitmapData, 1)          ;Pixeldaten auslesen


$binary = StringToBinary($Pixel)                    ;im Binaryformat
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $binary = ' & StringLeft($binary, 100) & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

Das nützt aber nicht viel, da die oberen Bits der Farbanteile abhängig vom Bild sind, bei "bearbeiteten" Bildern natürlich noch mehr! Und alles, was Bilder komprimiert (jpg usw) filtert diese (zufälligen) Anteile gnadenlos raus!

Aber egal, soll ja nur eine Demo sein, wir "verschlüsseln" einen Text mit den Pixeln eines Bildes:

#include <GDIPlus.au3>
#include <GDIPlusConstants.au3>




$text = "Hallo dieser Text wird mit den Pixeln eines Bildes verschlüsselt!"




_GDIPlus_Startup()


$sFile = FileOpenDialog("Datei", @ScriptDir, "Bilder (*.jpg;*.bmp;*.png)");"mona-lisa.jpg"


$himage = _GDIPlus_ImageLoadFromFile($sFile)                      ;Bild laden
$iHeight = _GDIPlus_ImageGetHeight($himage)                       ;höhe
$iWidth = _GDIPlus_ImageGetWidth($himage)                         ;breite


$tBitmapData = DllStructCreate("byte[" & 4 * $iWidth * $iHeight & "]") ;4 byte/pixel
$ptr_bitmap = DllStructGetPtr($tBitmapData)                       ; pointer auf die Bitmapdaten
$hBitmap = _GDIPlus_BitmapCreateFromScan0($iWidth, $iHeight, $GDIP_PXF32ARGB, 4 * $iWidth, $ptr_bitmap)


$hCtxt = _GDIPlus_ImageGetGraphicsContext($hBitmap)               ;Kontext


_GDIPlus_GraphicsDrawImage($hCtxt, $himage, 0, 0)                 ;Pixel in Kontext schreiben


$Pixel = BinaryToString(DllStructGetData($tBitmapData, 1))        ;Pixeldaten auslesen
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $Pixel = ' & StringLeft($Pixel, 100) & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console




;verschlüsseln, in den ersten 4 byte steht die Länge des Textes, oder die startadresse innerhalb des strings ^^
$lenstruct = DllStructCreate("dword")                             ;4 bytes
DllStructSetData($lenstruct, 1, StringLen($text))                 ;länge eintragen


$verschluesselt = Hex(DllStructGetData($lenstruct, 1), 8)         ;erste 4 bytes sind die länge




For $i = 1 To StringLen($text)                                    ;alle Buchstaben
    $pixelbytes = Asc(StringMid($Pixel, $i, 1))                   ;bytes aus den Bilddaten
    $textbuchstabe = Asc(StringMid($text, $i, 1))                 ;Textbuchstaben
    $verschluesselt &= Hex(BitXOR($pixelbytes, $textbuchstabe), 2);XOR, was sonst^^, man könnte ggf. noch bits rotieren...aber wieso?
Next


MsgBox(0, "Verschlüsselt", "Bytes:" & @CRLF & $verschluesselt &@crlf&@crlf&"als Text:"&@crlf&binarytostring("0x"&stringtrimleft($verschluesselt,8)))








;entschlüsseln
$entschluesselt = ""


$lenstruct = DllStructCreate("dword")                             ;4 bytes für textlänge oder startadresse
DllStructSetData($lenstruct, 1, Dec(StringLeft($verschluesselt, 8))) ;länge(oder startadresse) auslesen


$textlen = DllStructGetData($lenstruct, 1)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $textlen = ' & $textlen & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console


$verschluesselt = StringTrimLeft($verschluesselt, 8)              ;länge abschneiden


For $i = 1 To $textlen                                            ;alle Buchstaben
    $pixelbytes = Asc(StringMid($Pixel, $i, 1))                   ;bytes aus den Bilddaten
    $textbuchstabe = Dec(StringMid($verschluesselt, $i * 2 - 1, 2)) ;Bytes aus Verschlüsselung
    $entschluesselt &= Chr(BitXOR($pixelbytes, $textbuchstabe))   ;XOR, was sonst^^, man könnte ggf. noch bits rotieren...aber wieso?
Next


MsgBox(0, "Entschlüsselt", "Text:" & @CRLF & $entschluesselt)

Zitat von Oscar

Stellt sich die Frage, ob da nicht einige "Lobbyisten" ihre Macht ausspielen, um einen sicheren Zufallsgenerator zu verhindern?

steht doch im direkten Zusammenhang mit

Zitat von Oscar

Wenn die Verschlüsselung gut genug ist, dass die Nachrichtendienste damit 10 Minuten beschäftigt sind,

Solange die Hersteller von Hard/Software (Intel/M$/Apple) pausenlos "nach Hause telefonieren" (und das verschlüsselt^^) kannst du darauf wetten, dass deine Daten übertragen werden BEVOR diese auch nur ansatzweise in irgendeinen Verschlüsselungsalgorithmus übergehen....

Wäre ehrlich gesagt reichlich schwachsinnig, das genau so NICHT zu machen. Die NSA greift imho nur die verschlüsselten Daten von den Rechnern ab, bei denen sie keinen direkten Zugriff haben. Alte Kisten also, und davon gibt es reichlich....
Sämtliche neuen Rechner sind Hard- und Softwaremäßig verwanzt!
Im Zusammenhang mit Mobiles (Smartphones/Tablets) nur an Verschlüsselung zu denken ist lächerlich. Diese Dinger übertragen selbst "ausgeschaltet" noch Daten. Nicht umsonst wird alles versucht, die "alten" Handys aus dem Verkehr zu ziehen! Angeblich um die Rohstoffe herauszulösen...

Im Prinzip müsste man zufälligen Müll in die Tastatur kloppen und diesen dann versenden....aber mach das mal in Zeiten von Youtube Da wird in einer Minute mehr Datenmüll im Videoformat gepostet als man in seinem ganzen Leben an Tastaturanschlägen zusammenbringt. Also auch keine Lösung

Aber es gibt noch Leute, die wie ich einen funktionsfähigen 8088/80286 auf dem Dachboden stehen haben. Die sind (hoffentlich) noch nicht hardwareverwanzt, und selbstgeschriebene Betriebssysteme dafür sind auch nur eine Fleißarbeit Die Renaissance dieser Kisten wird kommen!
Von wegen "Resistance is futile", da kann es nur eine Antwort geben:

|^|
    | |
|^|^| |^|^|
|         |

George Orwell´s 1984 habe ich genau in dem Jahr in der Schule gelesen. Damals hätten wir uns die Hand dafür abhacken lassen, dass es niemals so weit kommt!
Und heute ist das nicht nur Realität, sondern wesentlich perverser!
Aber was soll man machen, wenn man kein iPhone hat, hat man kein iPhone...

Zitat von Schnuffel

also veröffentliche ich jetzt einen Schlüssel mit echter größe (einige Peta-Byte....
Diesen kann dann jeder nutzen und braucht nur das Startbyte für seine Verschlüsselung angeben....

Die Biologen haben es da einfacher, die dröseln einen DNS-Strang auf und haben eine "lange" Sequenz....

Meine persönliche Meinung zu diesem Thema ist, dass es in nicht allzu naher Zukunft den "Chip" geben wird, der bei der Geburt eines jeden Menschen in den Os temporale (hinter dem Ohr) eingepflanzt wird. Dann ist auch das Thema "Sicherheit" im Datenverkehr passé. Sämtliche Leistungen werden über diesen mit der Umwelt vernetzten Chip abgewickelt! Es gäbe keine Warteschlangen mehr auf den Ämtern, da sämtliche Papiere und deren Datenaufkommen überflüssig wären. In den Bus einsteigen, 3 Stationen fahren, es werden 1€22 vom Konto abgebucht.
Alkoholpegel > 0.1%% , das Auto fährt nicht los. Kein Betrug bei Sozial/Krankenversicherung, überhaupt würde die Gesundheit rapide verbessert werden, da sämtliche negativen Tätigkeiten sofort reportet werden.
Kriminalität wäre nur noch rudimentär vorhanden, jedenfalls beim Teil der Bevölkerung, der sich nicht in den mit massiven Restriktionen beaufschlagten Kontinenten befindet, in den die "Verbrecher" abgeschoben werden. Verbrechen überhaupt wäre sinnlos, der einzige Grund eines zu verüben ist doch, einen Vorteil gegenüber anderen zu erzielen. Sobald jedem alle Daten offen vorliegen, sind Verbrecher sofort entlarvt.
Somit gäbe es auch keinen Grund mehr für Überwachung, die Leute hätten mit ihrer Selbstkontrolle genug zu tun, überwachen tun schliesslich "alle" anderen...

Zusammengefasst und weitergedacht eine ideale Gesellschaft....oder hat ein vernünftig denkendes Lebewesen etwa Vorbehalte gegen....die Borg.

"Resistance is futile"
Das wird doch heute schon von Milliarden Benutzern von Social-Media tagtäglich gelebt!

Und uns andere, ohne facebook/twitter/google+/youtube/linkedin/bla/blub-Account, uns kriegen sie letztendlich auch noch! Im Zweifelsfall mit Danone-Joghurt!

bin gerade unterwegs, der Arduino liegt zuhause, wenn das mit der Fotodiode/anderen Sensoren klappt, gäbe es einen OTP

@minx, radioaktiv erinnert mich an meine Armbanduhr aus den 70ern mit "Leuchtzeigern", die habe ich in den 80ern entsorgt, nachdem ich zufällig in einem Atomreaktor mit der Uhr in die Nähe eines Detektors kam....

@Schnuffel, im Grunde hast du Recht, das Problem bei sämtlichen "Verschlüsselungsgeschichten" ist doch, dass der Schlüssel möglichst kurz sein soll, aber die zu verschlüsselnde Nachricht beliebig lang. Daher wird ein irrsinniger mathematischer aufwand getrieben, um auch mit kurzen Schlüsseln arbeiten zu können. Da diese Verfahren aufgrund ihrer "Besonderheiten" angreifbar sind, wird nun der Schlüssel künstlich "aufgepumpt", auf neudeutsch "gesalzen". Das "Salt" erweitert gewissermassen den Schlüssel.

Sicher, und unknackbar, ist eine XOR-Verknüpfung mit einem "zufälligen" Schlüssel, der aber so groß wie die Nachricht sein muss. Oder hundertmal größer, dann hat man sich die Mühe gespart, jedes Mal einen neuen Schlüssel zu generieren. Man muss zur Nachricht nur den Startwert im Schlüssel dazugeben.
Und spätestens jetzt ist auch klar, wieso dieses Verfahren niemals Einzug in "öffentliche" Systeme findet. Es ist....sicher, und damit für sämtliche "Entschlüssler" uninteressant!

Sensorrauschen (Dunkelrauschen/Photonenrauschen), hat immer den gleichen Grund, physikalische Beeinträchtigung vom Sensor(Material) und dem unbeeinflussbaren "Beschuss" mit Photonen. Und ein Photonenstrom ist zufällig. Wo/wann eins eingeschlagen hat, weiß man immer erst nachher.

Und der Unterschied von einem RAW-Bild und einem RAW-Bild besteht in dem, was der Kameraprozessor dir als "RAW" rauswirft! RAW<>RAW!
Wenn du glaubst, dass RAW "Sensor-Rohdaten" heißt, dann frag dich mal, wieso du die Hälfte des Kamerapreises für einen Prozessor bezahlen musst, der ein Bild "schönrechnet"!
Selbstverständlich werden auch RAW-Daten vor dem herausgeben bearbeitet, um zigtausende Hotpixel uvam, wegzubügeln! Vom Filtern bevor überhaupt Lichtpartikel auf den Sensor fallen garnicht zu reden. Der "Zufall" in Form des Photonenstroms wird demnach nicht in Form eines Bildes wiedergegeben. Wäre ja auch zu einfach/schön, einen "sicheren" Zufallsgenerator zu haben

Mach mal Bilder mit geschlossener Blende, einmal mit im Ofen auf 60°C vorgewärmter Kamera, einmal Kamera im Eisfach runtergekühlt auf -10°C.
Dann siehst du deutlich, dass schwarz (geschlossene Blende) <> schwarz (geschlossene Blende) ist!
Und dann weißt du auch, wieso ich Langzeitbelichtungen vom Sternenhimmel nur noch im Winter mache
Im heißen Sommer hab ich schon Bilder von der Milchstraße trotz draufgelassenem Objektivdeckel gemacht

Ich schau mal, was man an "rohen" Daten (Rauschen) aus einigen Fotodioden mit Hilfe des Arduino rausholen kann. Zufall kann man immer gut gebrauchen!

Hi,

Zitat von minx

Wichtig für diese Kategorisierung ist eine hohe Entropie, Seed-Sensibilität und natürlich eine objektiv hohe Zufälligkeit.

Stimmt!

Zitat von minx

Sobald ein einfacher Kompressionsalgorithmus das Bild verkleinern kann (z.B. PNG > JPEG), ist der bitstream nicht zufällig. Ein zufälliger bitstream kann nicht komprimiert werden.

Selfowned
Damit Bilder (wir reden hier über Sensor-Kamera erzeugte Digitalbilder) überhaupt komprimiert werden können, werden GENAU DIE ZUFÄLLIGEN Anteile der Sensordaten abgeschnitten! Es gibt kaum etwas zufälligeres wie die unterstersten Bits von Bildsensoren, denn diese basieren auf physikalisch bedingtes "Rauschen"! Die Frage ist nur, was macht der Prozessor in der Kamera damit?!
Da natürlich der Kamerahersteller davon weiß, wird er alles dafür tun auch die "RAW"-Bilder (ich sags mal SEHR vorsichtig) "anzupassen".
Alles andere wäre kontraproduktiv, denn man kann keinem Kunden plausibel erklären warum er mehrere hundert Euro für ein neueres Kameramodell mit x Millionen Pixeln ausgeben soll, wenn ein nicht unerheblicher Teil des "Bildes" zufällig ist! Bei einem Bit "Rauschen" pro Farbe immerhin 12,5%, bei 10 Bit/Farbe immer noch 10%!
Und wir reden hier von einem Bit! Rechnet euch das für zwei Bit aus, und es wird klar, dass NIEMAND auf der Welt viel Geld für 1/4 "zufällige" Bilddaten ausgibt...

Wer das selbst mal testen möchte schiesst ein Bild in einem völlig dunklen Raum und schaut sich die "Raw"-Daten an. Kommt dort "nichts" an, d.h. die untersten Bits der Pixel sind alle (!) null und nicht zufällig verteilt, dann rechnet der Kamera-Prozessor das Bild "schön".
Das ist aber relativ unwahrscheinlich, denn selbst die besten Rauschunterdrückungsalgorithmen geben irgendwann auf

Wäre mal interessant, diesen Ansatz weiter zu verfolgen, denn wenn die Sensordaten "zufällig" sind, wäre mit simpelstem XOR ein sicheres Verschlüsseln möglich!
Für gängige Verfahren ist das, wie von mir bereits ausführlich behandelt, uninteressant, denn gängige Verfahren MÜSSEN umkehrbar sein, damit die verschlüsselten Daten mit heutiger Rechnertechnologie wiederherstellbar sind!
Es soll immer noch Leute geben, die daran glauben, dass öffentlich zugängliche Verschlüsselungsverfahren "sicher" sind....
Diese Menschen sind auch in der Lage, Millionen Zeilen Quellcode eines "offenen" Betriebssystems auf Sicherheitslücken zu analysieren bzw. Prozessoren/Microcontroller aufzuschleifen und die darin implementierten Algorithmen abzugleichen. Daher hat es auch "nur" einige Jahre gedauert, OpenSSL zu fixen!

Aber wieso ein Kamerabild zur Verschlüsselung benutzen, wenn man die zu versteckenden Daten so schön Steganografieren kann...
Steganographie....Verstecken statt Verschlüsseln
Steganografie für Bild- und Sounddateien