Autoit TCP server aus Linux heraus erreichen

markplus

Hallo zusammen,

auf meinem Desktop PC läuft folgendes Server Script:

Code

Func Server()
	While 1
			$msg = TCPRecv($Socket_Data[$x], 1000000)
			If $msg Then
				Call(Remote)
			EndIf
	WEnd
EndFunc   ;==>Server


Func Remote() 
	Select ;If we receive a message
		Case $msg = "start"
			Run("C:\Program Files (x86)\Test\test.exe")
	EndSelect
EndFunc   ;==>Remote

Alles anzeigen

Auf meinem Laptop läuft folgendes Client Script:

Code

Remoote()
Func Remoote()
	TCPStartup()
	$ipAddress = "192.168.0.105"
	$portAddress = 666
	$connectedSocket = TCPConnect($ipAddress, $portAddress) 
	While 1
		$msg = GUIGetMsg()
		Select
			Case $msg = $cb_start
				$message = "start"
				TCPSend($connectedSocket, $message)
		EndSelect
	WEnd
	TCPShutdown()
EndFunc   ;==>Remoote

Alles anzeigen

Nun möchte ich von einer Linux shell heraus Befehle an den Server schicken. Eigentlich müssten dafür nur drei Parameter von Nöten sein:
- IP
- Port
- Text

Ich habe es per folgendem Scapy Kommando erfolglos probiert:

Code

p=sr(IP(dst="192.168.0.105")/TCP(dport=666)/"start")

Kann mir jemand sagen, warum das nicht funktioniert bzw. wie man aus Linux heraus ein funktionsfähiges Kommando schicken könnte?

Hoffe, jemand kann hier helfen.

**alpines**

Du solltest beim TCPRecv unbedingt die Nachrichten in einer Schleife empfangen und abspeichern, es kann sein das "sta" gesendet wird und dann durch "rt" überschribene wird - nur mal so am Rande.

markplus

$msg ist eine globale Variable und die befindet sich doch immer in der while Schleife.

Eine Idee, warum das mit der TCP Nachricht von Linux aus nicht funktioniert?

**alpines**

Zitat von markplus

$msg ist eine globale Variable und die befindet sich doch immer in der while Schleife.

Lies nochmal was ich geschrieben hab.

markplus

Habe ich nicht ganz verstanden. Kannst Du mir ein Beispiel geben?

**alpines**

Ganz einfach:

AutoIt

While <Server-Schleife>
	Local $sReceived = ""


	Do
		$sReceived &= TCPRecv($hClientSocket)
	Until StringInStr($sReceived, "keyword")
WEnd

Du kannst entweder an das Ende jedes Paketes ein String hängen der anzeigt das das Paket vollständig übermittelt ist oder du wartest so lange bis es angekommen ist.
Wenn du nur in die $sReceived Variable schreibst(überschreibst) dann kann es sein das ein Teil des keywords das ankommen soll verschluckt wird.

So kommt nicht "keyword" an, sondern "key" und bei der nächsten Schleifeniteration (bei deiner Variante) "word" und dann hast du als Nachricht nur "word" bekommen aber nicht "keyword".

Eventuell kannst du so deine TCP Daten senden: $ echo "start" > /dev/tcp/192.168.2.5/80

markplus

Vielen Dank für die Antwort!

Jetzt habe ich es verstanden. Wenn, dann wäre das mit dem String am Schluss relevant, denn es sind viele verschiedene Keywords. Allerdings nutze ich dieses Client-Server-System schon seit langer Zeit und es hatte bisher nie den Anschein gemacht, dass Keywprd-Teile verschluckt oder überschrieben wurden. Sobald eine Connection da war, wurden alle Befehle immer korrekt ausgeführt.

Danke für den Vorschag zum Senden der TCP-Daten. Leider das gleiche Resultat. Der Server reagiert nicht auf das Paket. Irgend etwas muss hier fehlen oder falsch sein. Habe per Wireshark geschaut. Das Keyword wird korrekt gesendet. Leider kann ich das Autoit-Client-Paket nicht per Wireshark zum Vergleich anschauen, da der in Windows kein network adapter interface findet.

**alpines**

Isolier den Server mal und lad ihn hier hoch, außerdem brauchst du die Funktion "Call" nicht. Ruf die Funktion doch einfach direkt auf mit () dahinter.
Bei kurzen Keywords taucht das auch praktisch gar nicht auf, aber sobalds länger wird ist sowas Pflicht.

markplus

Also, ich habe jetzt Wireshark auch auf Windows zum Laufen gebracht und den Unterschied festgestellt:

Beim Verschicken aus der Linux Shell heraus, wird nur das Keyword verschickt. Wohingegen beim Verschicken durch den Autoit Client, ein riesiger Header mit verschickt wird:

Linux command shell:
[Blockierte Grafik: https://anonmgur.com/up/9e3d63b0cbb7c9d77807c261598b65db.jpg]

Autoit Client:
[Blockierte Grafik: https://anonmgur.com/up/c260f739fbc213124ce1386d5f2de667.jpg]

Offenbar wäre die Lösung aus Linux heraus irgendwie den gesamten Header nachzubilden. Wie das zu bewerkstelligen ist, dazu habe ich allerdings (noch) keine Ahnung.

**alpines**

Du hast glaube ich das falsche Paket erwischt denn HTTP/1.1 und Content-Length: 5813 weißen daraufhin das es sich hierbei um HTTP-Traffic von deinem Browser handeln muss.
Außerdem produziert AutoIt keinen so großen Header der über 5800 Bytes groß ist nur für ein paar Buchstaben.

markplus

Tatsächlich. Vielen Dank für den Hinweis. Der Header sieht dann doch ähnlich aus, wenn ich das korrekte Paket heraussuche.

Wenn ich nach der Ziel-IP-Adresse filtere kommen trotzdem in Windows all diese anderen Pakete noch vor. Obwohl der Browser gar nichts macht, geschweige denn an eine andere lokale IP-Adresse sendet.

In Windows mache ich Folgendes:
- state Autoit client und lasse ihn sich verbinden mit dem Server
- starte Wireshark
- schicke Kommando vom Client aus ab
- stoppe Wireshark
- filtere in den Paketen nach der Ziel-IP-Adresse des Desktops

=> es kommt ein riesen Haufen an Paketen zusammen inklusive solcher mit dem vorhin geposteten riesigen Header. Wobei der eigentliche Text-Befehl, wie Du richtig geschrieben hast, nur in einem kleinen Paket ohne Header enthalten ist.

**alpines**

Setz noch den srcPort / dstPort Filter, dann hast du praktisch nur noch deine Anwendung. Oder du nimmst Microsoft Net Monitor, das filtert Traffic nach Anwendungen.

markplus

Das ergibt das gleiche Ergebnis, da sonst kein traffic stattfand.

misterspeed

Vielleicht versendet dein Linux Client die Daten Binär und dein Windows Client als String?

markplus

Beide versenden als string. Allerdings habe ich jetzt festgestellt, dass mit

$ echo "start" > /dev/tcp/192.168.2.5/80

ein "0A" am Schluss mitgeschickt wird. Jetzt frage ich mich, wie man verhindern kann, dass dieser carriage return mitgeschickt wird.

markplus

Vielen, vielen Dank. Mit StringStripWS wurde das Problem gelöst!!!

**Bitnugger**

In Linux kannst du dem Echo-Befehl sagen, dass er kein LF ans Zeilenende anhängen soll.

-n Keine Ausgabe des am Zeilenende stehenden Zeilentrenners

$ echo -n 'Dies ist ein Text ohne LF (0A)...'

Alternativ ginge auch dies...

$ echo -e 'Dies ist ein Text mit CRLF (0D0A)...\r\n'

markplus

Zitat von Bitnugger

In Linux kannst du dem Echo-Befehl sagen, dass er kein LF ans Zeilenende anhängen soll.

-n Keine Ausgabe des am Zeilenende stehenden Zeilentrenners

$ echo -n 'Dies ist ein Text ohne LF (0A)...'

Alternativ ginge auch dies...

$ echo -e 'Dies ist ein Text mit CRLF (0D0A)...\r\n'

Alles anzeigen

Vielen Dank! Nützlicher Tipp für das nächste Mal!