Beiträge von Andy

so?

Klassiker...

$ping = Ping("192.168.30.3",50000)
MsgBox(-1,"PING BEFORE IF",$ping)
$err = @error
MsgBox(-1,"ERROR",$err)

ich gehe davon aus, daß du den @error vom Ping haben wolltest und nicht den der Msgbox, aber den fragst du ab^^

AutoBerts Lösung erschlägt in einer Zeile alles, hast du das mal getestet?

Die Frage ist so alt wie die Programmiererei :
Arbeitet man den "Fehler" in der Funktion ab, oder unterbricht die Funktion und gibt einen Fehlercode zurück?
Die meisten werden wohl mittlerweile Fehlercodes zurückgeben, auf die man dann aussserhalb der Funktion reagiert.

return seterror(15,33,"Drecksfehlerverdammtergrmblfx##") ;gibt an den Aufrufer der Funktion den Sting zurück, setzt @error=15 und @extended=33

GdI+ braucht man keinesfalls....
Schau mal das Beispiel in der Hilfe zu _winapi_drawline()

Am allerschlimmsten ist übrigens, daß deathweavle gestern abend in der SB zwar eine Frage (zum Thema) gestellt hatte, aber die reichlichen Antworten offensichtlich geflissentlich ignoriert hat. Von einer Rückmeldung ganz zu schweigen...

Naja, wieder einer mehr, an den man keine Antworten mehr verschwenden muss!

Zitat

Naja andy dan machs besser und zeig mir deine lösung

Naja, ums mal passend für deinen geistigen Horizont auszudrücken.
Wenn ich einem Dreijährigen im Sandkasten sage, er soll mir mal den Sandkuchen bringen, und er braucht dafür 5 Stunden, weil er jedes Sandkörnchen einzeln holt, dann ist das weder besonders witzig noch hat das was mit Anfänger zu tun, das ist einfach SCHWACHSINNIG!

Wenn du statt dumme Sprüche zu machen mal die Suche bemüht hättest, dann wären dir komplette Sudoku-LÖSER hier im Forum aufgefallen. Ja, die lösen das Sudoku auch noch in einigen Millisekunden komplett! Btw. ja, ich habe auch einen davon "fabriziert".

Und weil ich gerade so gut drauf bin , mit deiner Einstellung wirst du hoffentlich viele Freunde finden, ggf. sagt dir dann einer mal, wie man WIRKLICH weiterkommt. Scheiße zu fabrizieren und dann zu erwarten, daß man auf die Schulter geklopft bekommt, ist der falsche Weg....

Das ist eins der abschreckensten Beispiele, die ich je gesehen habe....

Anfänger hin oder her, der Sinn und Zweck einer Programmiersprache ist es ja nicht, sinnlos tausende Zeilen Code zu fabrizieren, sondern ein Programm zu erstellen, dessen Code LESBAR ist.
Daher macht man sich im Vorfeld Gedanken über das "Problem". Und auch über die Lösung. Unter anderem gibt es dazu ein Forum, um (sinnvolle) Fragen zu stellen.

Eine sinnvolle Frage wäre z.B. gewesen, wie man hunderte Variablennamen vermeidet.
Die zweite Frage wäre gewesen, wie man 4000 Zeilen IF/Then Abfragen vermeidet.

Die Bemessung der Intelligenz, 4800 Zeilen C&P abzuliefern und das auch noch als "Script" abzuliefern, erspare ich mir :pinch:

Beispiel Stringbehandlung und Pointer auf AutoIt-Variablen siehe auch einen Post obendrüber!

Im folgenden Beispiel stelle ich rudimentäre Stringbearbeitung vor.
An den Assemblercode soll ein String übergeben werden. Man kann den String nicht direkt übergeben, denn es sind nur maximal 4 Bytes als Parameter erlaubt. Also macht das mit einem Umweg über die Anfangsadresse des Strings, den sogenannten Pointer. Man übergibt also nicht den String, sondern die Adresse, an der der String im Speicher liegt. Bei Dll-Aufrufen wird dazu an den Datentyp ein Asterix * angehängt.
Um also den String zu übergeben, benutzt man

"str*","Hallo!" oder "str*",$string

Nun ist es aber nicht so, daß dieser Pointer direkt auf die Anfangsadresse der Variablen (oder des Strings) zeigt, sondern auf eine Adresse, an deren Stelle der eigentliche Pointer abgelegt ist...Warum das so ist, führt zu weit, ihr wisst schon, damit werden Bücher gefüllt

Im folgenden Beispiel kopiere ich einen String aus einer AutoIt-Variablen in eine Struct und lese diesen String auch wieder aus. Nebenbei erfährt man noch etwas über Ansi bzw UTF-Kodierung^^
Ändert mal den Typ im Dll-Aufruf von "str*" in "wstr*", das "verwandelt" den String in einen Unicodestring...

Hmmm, man erhält also einen Pointer auf die AutoIt-Variablen....na, wenn das nicht interessant ist
Damit kann man nun ALLE möglichen AutoIt-Variablen direkt an den Assembler übergeben!
Testet das mal z.B. mit Arrays^^

//EDIT//
Man kann natürlich direkt Strings vom Assemblercode zurückgeben lassen, ohne eine Struct
Wenn der Pointer auf den String im EAX register steht vor der Rückgabe zu AutoIt, dann erhält man, wenn man als Rückgabetyp "str" oder "wstr" in der Dll wählt, den String direkt in $ret[0]

;Assemblercode...
mov eax,Adresse_an_der_der_String_im_Speicher_steht ;z.B. eine Variable
ret
;Ende Assemblercode

$ret = DllCall("user32.dll", "str", "CallWindowProcW", ;oder "wstr" für Unicodestrings
Msgbox(0,0,$ret[0]) ;zeigt den String

Zitat

Was genau ist REPNE SCASD und wann springt es wohin

Das ist eine sehr mächtige Kombination zweier Befehle.
REP (die Postfixe entsprechen denen der Sprungbefehle und beziehen sich auf die Flags) heisst Repeat also "Wiederholen". Und zwar so lange, bis ein bestimmter Zustand eines Prozessor(status-)flags erreicht ist. REP kann auf einige Befehle angewendet werden.
SCAS vergleicht zwei Speicherstellen bestimmter Größe und setzt anhand des Ergebnisses die Statusflags.

Ich hole etwas aus um zwei wichtige Register vorzustellen (E)DI und (E)SI. D steht für Destination (Ziel), und S für Source (Quelle)
In 8- Bzw. 16-Bitumgebungen treten diese (Offset-) Register immer in Verbindung mit den sogenannten Segmentregistern auf, ES : DI und DS : SI. Wen es interessiert, dafür gibt es ganze Bücher^^, und ist auch für uns kein Thema.
Nur soviel, Segmente brauchen uns nicht mehr zu kümmern, der Speicher ist linear angeordnet (intern schaufelt Windows den zwar um, aber das juckt uns nicht...). Uns interessiert nur noch die "reine" Speicherstelle.

Also eigentlich nur noch die beiden Register ESI und EDI. Mit Quelle und Ziel kann man verschiedenste Sachen machen.
Man kann z.B. Daten von der Quelle zum Ziel transferieren oder Quelle und Ziel vergleichen. Um jetzt längere Datensequenzen zu bearbeiten, werden die "Stringbefehle" CMPS (CoMPare String (vergleichen)) und MOVS (verschieben/kopieren) verwendet. Das Präfix bestimmt dabei die Größe B=Byte W=Word D=Doubleword
Beispiel MOVSB kopiert ein Byte von der Adresse ESI nach der Adresse EDI. Nach dieser Operation wird (je nachdem wie das DF-Flag gesetzt ist) sowohl ESI als auch EDI incrementiert oder decrementiert. Und zwar abhängig von der Größe der transportierten Daten. Wird also per MOVS ein Byte kopiert, dann wird ESI und EDI um ein Byte (also um eine Speicherstelle) erhöht. Wird mit MOVSD ein Doubleword kopiert, erhöhen sich ESI und EDI um 4 Byte...
Das heisst, sowohl für die Quelle als auch für das Ziel sind die Adressen für die folgende Opreation bereits geladen! Für CMPS gilt selbiges...

SCAS vergleicht nun die Daten von EAX und Ziel, und erhöht danach automatisch das Register EDI. Bei jedem Mal, bei dem SCAS aufgerufen wird, erhöht sich also EDI. Ist jetzt der INHALT der Speicheradresse von EDI gleich EAX, dann wird u.a. das ZF (Zeroflag) gesetzt. Dieses kann nun wiederum von z.B. REP abgefragt werden.

REPNE SCASD bedeutet also, REPeat if Not Equal StringCompare of Doubleword also ungefähr wiederhole den Stringvergleich des Doubleword an EDI so lange, wie dieses nicht gleich EAX ist. Da Not Equal eigentlich das ZeroFlag abfragt, könnte auch der Fall eintreten, dass ECX=0 ist, denn REP decrementiert ja gleichzeitig ECX! Kompliziert?^^

Wenn nun das ZF gesetzt ist, also entweder ECX=0 oder EAX=[EDI] dann wird der nächste Befehl im Assembler ausgeführt

Zitat

Welche Größe brauche ich um einen String zurückzugeben? (mov eax,byte[string] klappt nicht...)

Sobald der "String" größer als 4 Byte (=1 Dword=maximale Größe eines Registers) ist, kannst du den nicht "direkt" zurückgeben! Was du aber zurückgeben kannst, ist die Adresse zu diesem String! Da "Strings" im Sinne von Zeichenketten, also z.B. $a="Hallo, ich bin ein String!" in der Regel Nullterminiert sind, musst du einfach nur die Anfangsadresse haben und so lange Buchstaben einlesen, bis eine NULL kommt, dann ist ENDE!
Genau aus diesem Grund Bekommt man auch nicht viel zu sehen, wenn man in AutoIt z.B. den Inhalt einer EXE-Datei in einen String liest und diese dann per MsgBox() ausgeben will. Irgendwo steht ein Nullbyte und die MsgBox-Funktion stellt nur die Zeichen bis zu diesem Nullbyte dar! Der "String" hat aber trotzdem die Länge der EXE-Datei!

Zitat

Kann man mit Assembler String codieren?

Verstehe ich nicht ganz^^. Der "Assembler" bzw. die von ihm erstellten Mnemonics machen all das, was auf dem Computer abläuft. Er übersetzt die Assemblerbefehle 1:1 mit Maschinencode! Etwas anderes versteht der Prozessor nicht...
Ein Compiler macht das etwas anders. Er "versucht" (mehr oder weniger erfolgreich), die Befehle des Programmierers so in Maschinensprache umzusetzen, daß das passiert, was der Programmierer erreichen möchte. Das ist ungleich schwieriger! Daher fabrizieren alle Compiler wesentlich mehr Maschinencode, als "eigentlich" nötig wäre.
Die "Strings" erstellst du entweder direkt im Assembler mit z.B.
string db 'Hallo, ich bin ein String!',0 ;die 0 ist wichtig!!^^
oder du erstellst den String mit AutoIt und kopierst ihn mit dllstructsetdata in eine Struct. Dann kannst du den Zeiger (Pointer) auf diesen Speicherbereich mit dllstructgetptr() an den Assembler übergeben. Denn leider erlaubt AutoIt nicht, direkt die Adresse auf eine Variable zu ermitteln.

Zitat

Gibt es in FASM soetwas:
PROC WriteX
...
ret
ENDP WriteX

Ja, klar, aber nicht in dem "Embedded" Modell in der FASM.AU3. Die ist bis auf das allernötigste abgespeckt. schau mal auf der HP vom FASM nach, dort ist ein sehr schönes Dokument.

Zitat

Hab ein Primzahlfinder gebaut

GEIL!

Zitat

Ich weiß der ist sehr unübersichtlich, aber er klappt und für meine erste Assemblerfunktion finde ich es nicht schlecht (ich wette ein besserer als ich hätte das mit der Hälfte an Zeilen geschafft)

Das ist egal...Hauptsache, es funktioniert erstmal! Optimieren kann man dann immer noch!
Aber ich würde dir raten, (ohne dass ich mich durch den Code gekämpft hätte), die Kommentare zu benutzen! Ansonsten blickst du nach 2 Wochen absolut nicht mehr durch^^
Dabei sollte im Kommentar stehen, was du ERREICHEN WILLST!
mov ECX,13 ;13 nach ECX
Ist überflüssig, aber bei
mov ECX,13 ;Zähler für die Länge des Strings für REPNZ
versteht jeder sofort um was es geht!

OT:
Das geht ja schon in die Richtung der Beeinflussung des Unterbewusstseins. Dazu werden in Videos "Botschaften" zwischen die Frames gepackt. Ich habe von einem Experiment einer Hochschule in England gehört, die einen Kinofilm so präpariert hatten, daß sie ein Standbild einer Cola-Werbung bei jedem x.Frame einblendeten. Das war natürlich bewusst nicht zu merken, aber der Cola-Konsum der Zuschauer in der Pause war ca. 20% höher! Das Unterbewusstsein hatte die "fremden" Bilder wohl doch bemerkt, und dementsprechend gehandelt. Aber einige Zuschauer hatten das Kino auch wegen Kopfschmerzen verlassen^^. Vielleicht mochten die keine Cola

Hi,
Ich hätte da einige Verbesserungsvorschläge:
1.Ersetzen des Screenshots durch Blitten (_WinApi_Bitblt()) des DeviceContext des Desktops(oder eines Fensters) in eine Bitmap. Das blitten dauert bei 1650x1080 nicht mal eine halbe Millisekunde.
2.Nochmaliges Blitten, allerdings werden die beiden Bilder nun mit XOR verknüpft. Das führt dazu, daß jedes Pixel, das seine Farbe in der Zwischenzeit NICHT geändert hat, schwarz wird.
3.Jedes Pixel, das nun nicht schwarz ist, hat also seine Farbe geändert. Die Position dieses Pixels innerhab der Bitmap wird gemerkt.
4.Es muss also nur die Position des Pixels in der Bitmap und die Farbe übertragen werden. String=pos&farbe&pos&farbe&pos&farbe....
5.Auf Empfängerseite wird jetzt die Farbe per dllstructsetdata(struct,1,farbe, position) in die Bitmap übertragen.(sehr schnell!)

Die Schwelle ist erreicht, wenn mehr als die Hälfte der Pixel die Farbe geändert haben, denn dann kann man auch gleich ein komplettes Bild übertragen

Im Prinzip gehts nur um Punkt 3. Aber genau dieses Beispiel, ein Pixel zu finden, habe ich im Assemblertut in einer Handvoll Befehlen erledigt. Ich vermute, daß man noch wesentlich weiter optimieren kann, indem man z.B. Zeilen, in denen sehr wenige geänderte Pixel vorkommen, weglässt.
Oder das Bild in 100x100 Blöcke unterteilt und nur Blöcke mit geändertem Inhalt überträgt(Blocknummer&Block). Jedenfalls wäre das eine sehr schöne Assemblerübung^^. 90% ist ja bereits im Tut abgehandelt...

;Pseudocode:
while
Einen Screenshot machen, per TCPIP übertragen,
For $i=1 to beliebige Anzahl
weiteren Screenshot machen, nur die Anderungen zum vorangegangenen Shot übertragen
next
wend

Wie man Screenshots macht und Bilder miteinander vergleicht, findet man in der AutoIt-Hilfe, vollständige TCP-Übertragung auch

Zitat

Weil man davon ausgehen muss, dass dem "Feind" der Algorithmus in die Hände fällt.

Damit braucht der "Feind" schon 2 Informationen, er muss das Steganographierte Bild haben und er muss den Algorithmus haben. Der Sinn an der Steganographie ist es aber, jedes mögliche Opjekt als Träger von Informationen nutzen zu können.
Ich spinne mal etwas:
Der Angreifer weiß, das Geheimnisse über steganographierte Videos im WWW übertragen werden. der Angreifer nimmt an, daß ausschließlich Videos auf Youtube verwendet werden.
Der Angreifer hat als Information, daß in einem Bild eines Youtube-Videos per Steganografie geheime Informationen enthalten sind. Nützt das etwas?
Weiterhin weiß er nicht, in welchem Format das "Geheimnis" im Videobild vorliegt. Ist es eine EXE-datei, ein Text oder ein MP3?
Er müsste jedes einzelne Frame eines jeden Videos mit bekanntem Algorithmus entsteganographieren und jedes Ergebnis nach einem bekannten Dateiformat untersuchen..., viel Spass dabei...und wer sagt, daß nicht jedes Byte des Geheimnisses mit einem dem Empfänger unbekannten zufälligen Wert von 1-255 XOR-Verknüpft ist?
Für den rechtmäßigen Empfänger ist das kein Thema, er weiß ja in der Regel, in welchem Format der Sender sendet, er könnte einfach alle 255 Möglichkeiten "ausprobieren", bis das passende Format gefunden ist...

Zitat

Damit würde die Sicherheit des Verfahrens allein davon abhängen ob der Algo bekannt ist.

Ja, deshalb mein Tip, das Verfahren auf eigene Bedürfnisse anzupassen.

Man könnte natürlich auch einen "Schlüssel" d.h. eine Orginaldatei dazu benutzen, das steganographierte Bild abzugleichen. Ich stelle mir das so vor, wie eine "Lochkarte", die nur bestimmte Bereiche des Bildes "durchsichtig" macht.
Verknüpft man nun Orginal mit steganografiertem Bild (XOR), dann bleiben nur diejenigen Pixel sichtbar, die "hinter den Löchern" sind. Wenn nun aber das gesamte Bild steganografiert wird (bei den unwichtigen Pixeln wird zufälliger "Müll" eingetragen) dann sieht der Angreifer zwar, daß das gesamte Bild stehganografiert ist, aber welche Pixel in der Nachricht enthalten sind, sieht er nicht. Das lässt sich natürlich noch auf die Spitze treiben, indem für jede Farbe eine eigene Maske verwendet wird.
Derjenige, der die Nachricht entschlüsseln möchte, ist ohne das "Orginal" (dieses "Bild" hat natürlich keinen optischen Bezug mehr, es ist ein Schlüssel) aufgeschmissen. Er müsste bei jedem Pixel entscheiden, ob der Blau/Grün/Rotanteil "durchsichtig" ist, und dann für jede dieser Farben getrennt entsteganographieren. Ob die enthaltenen Bits in der Nachricht verwendet werden, weiss er nicht, er hätte also bei 3 Pixeln (72 Byte) nur eine Wahrscheinlichkeit von der Summe der Permutationen von 9 "bits", das richtige "Bit" zu erhalten. Allein die Permutationen liegen bei 4 Pixeln = 12 Byte bei irgendwas mit > 40 Millionen (mal drei, da wir für jede Farbe eine eigene Maske haben).
Das ist im Prinzip ähnlich wie beim TSP (Travelling Salesman Problem). Für einige wenige Städte (bis zu 20) ist die Route noch zu Brouteforcen, danach ist Ende. Wir reden hier aber von Bildern mit weit mehr als 20 Byte. Wer Lust hat, kann ja mal die Permutationen für das 32x32x4 Bit AutoIt-Logo aus dem Beispiel ausrechnen. Wenn jede Farbe ihre eigene Maske hat natürlich^^

Da nur die untersten 2 Bit jeder Farbe verwendet werden, können bei den Masken natürlich die oberen 6 Bit beliebig sein. Man könnte somit auch die Maske bei irgendeinem Freehoster abspeichern. Das muss nicht mal ein Bild sein, jede andere Datei ist als Schlüssel verwendbar.

Damit man versteht was ich meine, werde ich ein neues Beispiel machen, gute Idee

Zitat

Okay, so kann ich ja jetzt ganze codes verstecken, doch wie mache ich es ausführbar?

;Beispiel: extrahieren und ausführen einer geheimen Datei aus einem Bild

;Inhalt(e) aus dem Bild extrahieren
$inhalt=_Extract_Secret_from_Pic("beispiel.bmp") ;diese Funktion gehört in die Steganographie-UDF^^

;Inhalt in Datei schreiben
filewrite($inhalt[0],binarytostring($inhalt[1]))
;Datei ausführen
shellexecute($inhalt[0])

Func _Extract_Secret_from_Pic($file)
;Hier sollte der Code hin, um die "geheime" Datei aus dem Bild zu extrahieren
;mal angenommen, wir hätten den Namen einer EXE-Datei (Hello.exe) und auch die EXE-Datei
;in dem Bild versteckt, z.B. mit:
;$Zu_versteckender_String="hello.exe"+chr(0)+(fileread("hello.exe")
;
;dann hätten wir nach dem Extrahieren wieder den Namen
;und auch die EXE-Datei
dim $inhalt[2]
$inhalt[0]="Hello.exe"
$inhalt[1]="0x4D5A80000100000004001000FFFF00004001000000000000400000000000000000000000000000000000000000000000000000000000000000000000800000000E1FBA0E00B409CD21B8014CCD21546869732070726F6772616D2063616E6E6F742062652072756E20696E20444F53206D6F64652E0D0A240000000000000000504500004C010200F0A3824A0000000000000000E0000E010B010144000200000002000000000000001000000010000000200000000040000010000000020000010000000000000004000000000000000030000000020000C232000002000000001000000010000000000100000000000000000010000000000000000000000000200000AC000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002E746578740000003B000000001000000002000000020000000000000000000000000000200000602E69646174610000AC000000002000000002000000040000000000000000000000000000400000C000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006A00FF156620400050E81D0000004869212049276D20746865206578616D706C652070726F6772616D21006A00FF15962040006A00FF15622040000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005620000000000000000000003C200000622000008E20000000000000000000004A2000009620000000000000000000000000000000000000000000004B45524E454C33322E444C4C00005553455233322E444C4C00006E2000007C200000000000006E2000007C2000000000000000004578697450726F63657373000000476574436F6D6D616E644C696E6541009E200000000000009E2000000000000000004D657373616765426F78410000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
return $inhalt
endfunc

Zeile 86-102 extrahiert aus jedem Farbanteil eines Pixels (also B G + R) die untersten beiden Bits, diese werden im $char_array[] gespeichert
In Zeile 104-111 werden aus jeweils 4 der aufeinanderfolgenden, im $char_array[] gespeicherten beiden Bits ein Byte. 2+2+2+2=8

Vom Wert dieses Bytes wird der Ascii-Code des Buchstabens bestimmt.

Guck mal im 1. Post (habe ab "Aufgabe" versucht das besser zu erklären), wie aus dem 8 Bit großen M die 4 Zweiergruppen Bits werden.
Genau dasselbe machen wir jetzt Rückwärts, also aus den 2er-Gruppen wieder ein Byte

Zitat

Wenn es keinen Compiler gibt, wie kommt man dann an die Exe Dateien

Diese Frage verstehe ich ehrlich gesagt nicht.Was hat das eine denn mit dem anderen zu tun?

Zitat

Und könntest du mir vllt. mal einen Link zu einem deutschen, gutem Asm Tut geben?

http://www.gidf.de

Eins möchte ich in aller Deutlichkeit nochmal klarstellen:
Meiner Meinung nach sind heutige C++-Compiler in 99% aller Fälle so schnell wie ein guter Assemblercode. Unter der Vorraussetzung, daß der C++-Programmierer weiß, was er da tut! Kein Compiler kann langsamen Code in schnellen Code verwandeln! Für Assemblerprogrammierer gilt das gleiche!
Andererseits haben reichlich 08/15 C++-Programmierer seitens Geschwindigkeit nicht den Hauch einer Chance! Compileroptionen hin oder her! Ein Bekannter programmierte viele Jahre bei/für SUN, was der an Java-Code abliefert, das putzt die meisten C++-Programmierer von der Platte. Mal davon abgesehen, daß Java im gegensatz zu Assembler auf jede Plattform ohne Aufwand portierbar ist, sind auch dort Prozessor/Plattformspezifische Libraries in (schnellem) Maschinencode immer gern gesehen!
Einer meiner Kunden ist Spezialist für Cobol. Über Verdienst redet man nicht, aber er hat sich zu einer Aussage "Faktor 4" zu guten (!) C++-Programmierern hinreissen lassen. Soll ich jetzt empfehlen Cobol als Programmiersprache zu lernen?

Macht das, was euch Spass macht! Das ist das wichtigste! Und macht es richtig.

Ich habe nie programmieren gelernt, und will es auch garnicht mehr "richtig" lernen, dazu bin ich zu alt^^- Ich mache das, was mir Spass macht!
Und wenn mein AutoIt-Programm tut was es soll, dann bin ich Happy. Und wenn es mit der Geschwindigkeit etwas hapert, dann schreib ich in 08/15-8088-Assembler eine Dll oder "Embedded Code", damit es auch "fluppt". C++ jedenfalls fange ich dafür jedenfalls nicht mehr an zu lernen^^ , auch wenn die C++-Dll 3x schneller als mein Assemblercode wäre. Man hat ja auch seinen Stolz

@leviathan, eigentlich hast du ja Recht, genau deswegen predige ich schon seit Jahrzehnten die Verwendung LANGER Schlüssel und nicht immer nur diese Drecks-Kleinkram "In den nächsten Jahren unknackbar"-Scheiße!
Nimm einen 10 MB großen Zufallsschlüssel, brenn den in ein ROM und lass damit einige Runden Bits rotieren. In Hardware gegossen, fertig.
Warum das niemand macht? Na, weil die Forschung im Bereich Verschlüsselung ursprünglich hauptsächlich von Militärs gefordert und auch finanziert wurde (und immer noch wird). Wenn dann aber hochbrisante Dokumente mit den Namen der Kinder oder der Ehefrau (Nancy und Anna) "verschlüsselt" werden müssen, weil der Herr General sich kein längeres Passwort merken kann, dann weisst du woher der Wind weht.
Traurig, aber wahr...Der Algorithmus MUSS zwangsläufig umkehrbar d.h. "knackbar" sein, ansonsten könnte man die verschlüsselten Daten niemals wiederherstellen. Wenn die Hälfte des "Passwortes" bekannt ist, ("...Ich glaube es war Carol-Ann...oder Caroline...aber bestimmt irgendwas mit Carol....") dann haben es die Dechiffrierer leichter^^

Aber in Zeiten, in denen Telefongespräche abgehört, sämtliche Telekommunikation aufgezeichnet und gescannt wird, und der "Apparat" immer undurchsichtiger wird, mache ich mir wenig Gedanken über die "Knackbarkeit" einer Verschlüsselung. Ich habe noch nie den Inhalt einer Mail verschlüsselt, was wohl daran liegt, dass ich weder korrupt bin, noch permanent irgendwelche krummen Dinger drehe. Meine "Geheimnisse" bleiben bei mir und bei dem, den sie was angehen! Jeder kann mich gerne alles fragen, ich werde dann je nach Sympathie lügen wie gedruckt oder die Wahrheit sagen, aber das bestimme ICH! Ich weiss auch, das ich mit dieser Einstellung ganz oben auf der Liste der Schäubles dieser Welt stehe, so jemanden, der sich im Ernstfall mit ALLEN Mitteln wehrt, können die überhaupt nicht gebrauchen.
Daher gefällt mir der "Spirit" der Steganografie, es ist wesentlich spannender, ein "Geheimnis" in einem öffentlich zugänglichen Bereich für jedermann "herausfindbar" zu haben, als abzuwarten, bis ein Computer eine "verschlüsselte" Mail knackt. Kinder spielen auch viel lieber "verstecken" als "verschlüsseln"

Zitat

Und welchen Compiler benutzt du?

Compiler gibts nicht^^ Das Ding, welches die Befehle in Mnemonics (Maschinensprache) übersetzt (im Prinzip wird nur 1:1 übersetzt) nennt man Assembler. Richtige Hardcore-coder coden in Mnemonics....Trancexx aus dem engl. Forum ist so eine(r), da zieh ich tief den Hut!RESPECT

Assembler such man sich den passenden...ob MASM (Microsoft) oder TASM ist egal, es gibt reihenweise Assembler. Das wichtigste ist der Macro-Befehlssatz, richtig angewendet, musst du kein eines Register "anfassen", dann ist der Assembler ähnlich wie eine Hochsprache. Bis vor einigen Jahren habe ich die Inline-Assembler meiner Basic-Compiler benutzt. für schnelle Standalone-*.COM-Dateien hatte ich den A86, heute finde ich den FASM sehr gelungen, da es auch eine Version "für Mausschubser" gibt. Will heissen, eine (sehr simple) IDE mit Fensterchen, Code reinschreiben, F5 drücken, Dll oder EXE fertig....kein Makefile und kein Gelinke und den anderen unnötigen Krempel, den keiner wirklich braucht....

Zitat

Wie hast du dir denn diese Asm Kentnisse verschafft?

Ich zitiere mich mal selbst aus einem Posting:

Zitat

Learning by doing wars wohl, ein Buch hatte ich damals auch, allerdings sind die Anfänge schon ziemlich genau 30 Jahre her. Ich hatte damals fürs Abi einen PC1401, das ist ein mit Basic und Maschinensprache programmierbarer "Taschenrechner" von Sharp, den ich heute noch benutze! In den Speicher von immerhin 3534 (manche Zahlen vergisst man nie ) BYTE, passten mehrere kleine Basic-Programme, die durch den Interpreter im ROM ausgeführt wurden. Allerdings konnte man dieses Gerät auch mit Maschinensprache füttern. Der serielle Port nach "draussen" konnte mit Maschinensprache wesentlich schneller angesprochen werden, mit ein bissl löten und Bauteilen für ein paar Pfennige hatten wir (einige in meiner Klasse hatten so einen Rechner) schon 1985 ein Infrarot-"Netzwerk" gebastelt, welches sich bei der Physik-und E-Technik-Abschlussklausur in der Aula (nur an jedem 3. Tisch durfte ein Schüler sitzen) extrem positiv für mein Bestehen des ABI´s auswirkte.
Dann bekam ich irgendwann einen IBM-PC, 8088 mit 4,77 Mhz, aufgerüstet mit einem Coprozessor für mathematische Berechnungen. Auch dort hatte ich die Benutzerschnittstelle (GUI wäre wohl etwas übertrieben) mit Basic erstellt und alles, was "Speed" brauchte, mit Assembler. Später dann Turbo-Basic (gibts heute noch) mit intergriertem Assembler. Pascal hatte ich nur kurz gestreift, und den "Hype" darum belächelt.
Während meiner Lehre als Maschinenbauer hatte ich mit meinen "Taschenrechner" aus einer 3-Achsen-Fräsmaschine eine NC-Maschine gebaut, man beachte, Steuerung und Programm zusammen in 3534 BYTE.
Dann hab ich Maschinenbau studiert und bei den "Freaks" den C-Hype belächelt. Spaghetticode in C ist unendlich mal schlimmer als in Basic, aber naja...erklär das mal einem Programmierer. Hab dann nur zum Spass die (natürlich in C geschriebenen Grafik-Treiber) für die CAD-Workstations in der FH mal durch welche in Assembler ersetzt und eine 15-fache Geschwindigkeitssteigerung rausgeholt. Das sind 1500% Mehrleistung. Heute braucht man für 15% Mehrleistung eine komplett neue Prozessorgeneration....

Dann habe ich, durch berufliche Entwicklung, nur noch wenig mit Assembler zu tun gehabt. Die von mir gegründete Firma hatte mit EDV nichts zu tun. In den letzten Jahren habe ich ein bisschen Zeit für mein "Hobby" Computer gefunden und AutoIt als würdigen Basic-Nachfolger kennengelernt. Da das Internet extrem viel Informationen bereitstellt, ist nur noch die Suche nach den "guten" Seiten eine Herausforderung. Für Assembler gilt das auch, Bücher habe ich mir in den letztenn Jahren keine mehr gekauft, ich verwende eigentlich immer noch (bis auf einige Ausnahmen) den Uralt-8088-Code. Der reicht für 99% immer noch aus...
Also stöbere einfach ein bisschen im Netz, Tutorials gibt es sehr gute, und fang einfach mit leichten Sachen an.
Ward aus dem engl. Forum hat die FASM.AU3 bereitgestellt, hast du sicher schon gefunden.
Wenn du Lust hast, können wir eine FUN-"Assembler" Abteilung bei AutoIt aufbauen. Der FASM eignet sich hervoragend dafür. Assembler ist wesentlich einfacher als man denkt, und wie gesagt, 99% aller Programme kann man mit 20 Befehlen schreiben, mehr braucht idR kein Mensch
Das "Verständnis", was, warum und wie in einem Computer abläuft, erhält man mit Assembler jedenfalls sofort. Bei einem Fehler schmiert die Kiste ab, hehe^, das war schon vor 30 Jahren nicht anders

Alles anzeigen

Zitat

Assembler ist ansich die "leichteste" Sprache die es gibt

yepp....

Zitat

, Hat nur Knapp 30 Befehle

Mitnichten ^^
Aber du hast fast Recht, in der Regel braucht man höchstens 30 davon, wobei die MMX/SSE/2/3-Befehle teilweise derart mächtig sind, daß man eine halbe Seite AutoIt-Code bräuchte, um nur einen davon nachzubilden.

LeseTip für Interessierte