Kleiner und schneller Portscanner (nonVCL) mit EXE!

[Assarbad]

So, hier die Version 1.00.

Der hauptsächliche Vorteil liegt in der Benutzung vieler Threads.

Als Download ACE, RAR, ZIP

Es sollten insgesamt weniger Probleme (auch auf Windows 9x) auftreten. Source ist dabei.

[Assarbad]

Mir ist bewußt, was du meinst, aber ich verstehe noch immer nicht, wie du mit meinem Code Probleme hast? Bei mir tauchen die derzeit einfach nicht auf. Außerdem ist das minimale Verhältnis von Ports zu Threads Ports/NumThreads.
Einzig, deine Scheduling-Logik kann auch verschmerzen, wenn keine Threads mehr erstellt werden konnten. Das bietet meiner nicht. Also warts mal ab, bis ich mir selber was mit Hilfe deiner Hinweise ausgedacht hab

Daß IP global ist, hat den Grund, daß ich sonst Numthreads mal Speicher allozieren müsste um ihn an den einzelnen Thread zu übergeben. Ist auch ne Variante und hat sicher auch seine Vorteile, aber naja

[negaH]

Nee ich habe keine Probleme mit deinem Code und wollte eigentlich nur auf eine kleine "Schwachstelle" hinweisen. Normalerweise wende ich bei meinem Portscanner den Trick an so viele Threads wie möglich zu erzeugen. Es zeigte sich das auch unter Win2k die Anzahl der Threads pro Prozess unterschiedlich sein kann. Manchmal bekomme ich 2004 oder auch nur 129 Threads zum laufen. Deshalb dachte ich das es wichtig wäre darauf hinzuweisen das wenn man versucht z.b. 256 Threads zu erzeugen, eben dies fehlschlagen kann. Durch die Logik deines Algos. könnten dadurch Lücken entstehen. Aber was soll's, es ist dein Source und du must wissen wie es richtig für dich ist. Ich wollte eigentlich nur nett zu dir sein, heul

Gruß Hagen

[Assarbad]

Danke Hagen

Keine Angst, mir ist inzwischen bewußt, worauf du hinaus willst. Vorher dachte ich, du meintest einen Fehler im Code (den ich partout nicht gesehen hab) ... inzwischen weiß ich, du meinst einen Fehler in der "Logik". Und das werde ich natürlich ausbügeln

Also keinen Grund zu verzweifeln. Mir war bloß weiter oben nicht klar, worauf du hinaus willst

[Assarbad]

@Hagen: InterLockedExchangeAdd() gibts auf 9x nicht (lt. PSDK). Nimm einfach XADD. In der BASM-Newsgroup haben sie gemeint JEDE CPU-Operation ist atomic!

Hier nun die geupdatete Version. Downloadlink siehe oben.

[Assarbad]

Kleines Update. Es sind jetzt mind. 110 kB Daten dazugekommen!
Dafür zeigt der Scanner jetzt die Kurznamen der Ports an.

Bitte keine Vorschläge für ne extra Datei mit den Portbeschreibungen! Kenn ich, mag ich nicht.

Downloadlinks bleiben wie gehabt.

[negaH]

Zitat:

@Hagen: InterLockedExchangeAdd() gibts auf 9x nicht (lt. PSDK).
Nimm einfach XADD. In der BASM-Newsgroup haben sie gemeint JEDE CPU-Operation ist atomic!

Jop, das ist richtig bezogen auf Single Processor Systemen. Ich will auch garnicht darüber diskutieren denn die Konstrukteure der CPU's müssen sich was beim LOCK Prefix gedacht haben. Da es mir aber zu mühsig ist das alles exakt zu ermitteln nehme ich XADD das einen implizites LOCK Prefix hat.

Zitat:

Bitte keine Vorschläge für ne extra Datei mit den Portbeschreibungen! Kenn ich, mag ich nicht.

Schade eigentlich, da ich gerade heute ermittelt habe was auf Port 4662, 4242 und 1126 los ist und wer mich da permanent mit geblockten Packets überflutet. Echte Kotzsoftware dies.

Die Beschreibungen der Ports wäre dann erweiterbar und durch verstänliche Zusatzinfo ergänzbar. Zb. Port 135 ist auf Windowssystemen der böse DCOM Port. Die IANA Definitionen interessieren in weiten Teilen keinen so richtig und schon garnicht MS.

Gruß Hagen

[negaH]

Zitat:

gemeint JEDE CPU-Operation ist atomic!

Sorry sehe jetzt erst das "JEDE", was natürlich nicht besonders für das Wissen der BASM Leute spricht. Natürlich kann garnicht jede COPU Operation atomic sein. Z.b. ENTER,LEAVE,SYSENTER,CPUID sind extrem aufwenige und hochkomlexe Operationenm, die können garnicht atomic sein.
Selbst das Laden eines Integers in EAX mit MOV EAX,[Adresse] ist nur zu 1/4 atomic. Dazu muß nmlich der 4 byte Wert auch an einer 4 Bytes Adresse stehen. Sollte dies nicht der Fall sein so ist dies nicht mehr Atomic und somit nicht mehr Threadsafe.

Gruß Hagen

[Assarbad]

Okay ... überzeugt. Ich werde es als Option mit einbauen

Kann aber noch etwas dauern. Sitze grade wieder an etwas anderem.

[Assarbad]

Zitat von Hagen:

Natürlich kann garnicht jede CPU Operation atomic sein.

Falsch, sie muß es sogar sein! Du kannst die auf dem Level der Maschinensprache nicht weiter aufspalten! Wie komplex der darunterliegende Microcode ist, ist komplett irrelevant (, denn in der CPU wird jeder Opcode quasi wie eine Funktion behandelt ... bevor diese nicht zurückkehrt, gehts auch nicht weiter (1))!

Zitat von Hagen:

Selbst das Laden eines Integers in EAX mit MOV EAX,[Adresse] ist nur zu 1/4 atomic.

Sorry, sehe ich nicht so! EAX ist 4 Byte breit, also werden 4 Byte von dieser Adresse gelesen, komme was da wolle! Das hat was mit der Breite der Operanden zu tun. Der Assembler wird sich zB weigern sowas zu machen:

Code:

mov EAX, BYTE PTR [Adresse]
mov EAX, WORD PTR [Adresse]

Und dies aus gutem Grunde. Sollte ich was übersehen haben, kannst du gern nochmal ins Detail geben.

Hier noch die Unterstützung meiner Argumentation:

Code:

88 / r    MOV r/m8,r8       Move r8 to r/m8
89 / r    MOV r/m16,r16       Move r16 to r/m16
89 / r    MOV r/m32,r32       Move r32 to r/m32
8A / r    MOV r8,r/m8       Move r/m8 to r8
8B / r    MOV r16,r/m16       Move r/m16 to r16
8B / r    MOV r32,r/m32       Move r/m32 to r32
8C / r    MOV r/m16,Sreg**    Move segment register to r/m16
8E / r    MOV Sreg,r/m16**    Move r/m16 to segment register
A0    MOV AL, moffs8*    Move byte at ( seg:offset) to AL
A1    MOV AX, moffs16*    Move word at ( seg:offset) to AX
A1    MOV EAX, moffs32*    Move doubleword at ( seg:offset) to EAX
A2    MOV moffs8*,AL       Move AL to ( seg:offset)
A3    MOV moffs16*,AX    Move AX to ( seg:offset)
A3    MOV moffs32*,EAX    Move EAX to ( seg:offset)
B0+ rb    MOV r8,imm8       Move imm8 to r8
B8+ rw   MOV r16,imm16       Move imm16 to r16
B8+ rd    MOV r32,imm32       Move imm32 to r32
C6 / 0    MOV r/m8,imm8       Move imm8 to r/m8
C7 / 0    MOV r/m16,imm16    Move imm16 to r/m16
C7 / 0    MOV r/m32,imm32    Move imm32 to r/m32

Verschiedene Operandenbreiten und -Kombinationen führen zu verschiedenen Opcodes.

(1): Hyperthreading schaltet nur unabhängige Befehle parallel ... und beim Itanium das Ausführen aufs Gratewohl (also sozusagen nach vorbeugend) ändert auch an oben geschildertem nix!

[negaH]

Jey, jay ich wusste es, wir beginnen uns zu streiten !

Zitat:

Natürlich kann garnicht jede CPU Operation atomic sein.

Zitat:

Falsch, sie muß es sogar sein! Du kannst die auf dem Level der Maschinensprache nicht weiter aufspalten! Wie komplex der darunterliegende Microcode ist, ist komplett irrelevant (, denn in der CPU wird jeder Opcode quasi wie eine Funktion behandelt ... bevor diese nicht zurückkehrt, gehts auch nicht weiter (1))!

Eben nicht. Komplexe Befehle beeinflussen durch den Microcode interne Statusregister und externe Addressleitung sequentiuell. D.h. innerhalb mehrer Taktzyklen ändern sich Register und Addressleitungen. Die Maschinensprache ist somit irrelevant und der Microcode ist das Argument das eine CPU eben nur sehr wenige atomare Operationen beherrscht. Betrachtet man dies unter dem Gesichtspunkt der Multiprozessorenfähigkeiten das kann es auch nicht mehr Threadsafe sein. Bei solchen Konstellationen wird durch das LOCK Prefix alle parallelen CPU's angewiesen zu schlafen, damit eben der EINE OpCode der intern aus vielen sequentiellen OpCodes im MicroCode ausgeführt wird nicht dazu fürht das sich z.b. Überschneidungen auf den Adressleitungen zum Speicher auftreten.

Zitat:

Selbst das Laden eines Integers in EAX mit MOV EAX,[Adresse] ist nur zu 1/4 atomic.

Zitat:

Sorry, sehe ich nicht so! EAX ist 4 Byte breit, also werden 4 Byte von dieser Adresse gelesen, komme was da wolle! Das hat was mit der Breite der Operanden zu tun. Der Assembler wird sich zB weigern sowas zu machen:

Auch hier stimmt deine Annahme nicht. Wird über MOV EAX,[Address] auf Speicher zugegriffen der nicht an 4 Byte Grenzen ausgerichtet ist so entstehen durch Cachemisses zusätzliche Micro Ops. Diese wiederrum führen dazu das der Cache eventuell reorganisiert wird und da der cache eine shared Resource in einer Multiprocessor plattform ist würde das ohne LOCK zu Problemen führen.

Sogesehn sind deine Argumente genau die nötigen Argumente um meine Argumentation zu unternaumern

ABER! bevor es mit unserer Diskussion weitergeht müssen wir klären was Multithreading des Operationssystemes ist und was Multiprocessing auf Mehrprocessorensystemen bedeutet. Das eine hat mit dem anderen NICHTS zu tun solange das Threading auf Single Prozessoren Systemen läuft.
Nur auf Single Prozessoren wäre deine Annahme richtig, da dort keine andere CPU konkurrent zu aktuellen CPU an den Addressleitungen rumpfuscht. Denn dann kann innerhalb eines externen OpCodes der durch den MicroCode ausgeführt wird kein Taskswitch durchgeführt werden. Somit kann auf einem Single Prozessoren System die eine CPU nicht zur gleichen Zeit auf die gleiche Adresse zugreifen so daß es zu einer NICHT-atomaren Operation käme. D.h. eine CPU = ein Atom = alle Operationen atomar. Dies betrachtet aber nur die CPU und nicht die CPU einer Grafikkarte, nicht einen DMA Chip oder nicth einen IDE Controller, die alle ebenfalls in den Speicher reinschreiben können. So, wird ein OpCode wie MOV EAX,[Address] durch den CPU MicroCode in mehrere Zugriffsoperationen zerlegt, da die Adresse nicht an 4 Bytes ausgerichtet wurde, dann heist das das diese 4 Bytes durch 2 gesplittete Leseoperation gelesen werden müssen. Genau dazwischen kann aber die Grafikkarte, der DMA Chip oder der IDE Controller den noch fehlenden Speicherbereich aktualisieren. Die CPU würde im nächsten Zyklus somit in EAX einen falschen Wert zusammenbauen. Deshalb kann eine Single CPU eben nicht atomar sein.

Da ich aber NICHT der absolute Experte auf diesem Gebiet bin, interessiert mich dieser Fakt nicht. Ich gehe deterministisch vor und nehme an das das LOCK Prefix für Multiprozessoren wichtig ist, und auf Single Prozessoren kann es nicht schaden.


Gruß Hagen