Mit einem vorhandenen TCP Socket verbinden

Bake

Richtig, es wäre eigentlich möglich einfach einen Socket zu erstellen und Daten zu versenden. Trotzdem: Ich muss dies über einen vorhandenen Socket tun, indem ich mich "einklinke".

Die ganze Geschichte war nicht meine Idee und ich darf direkt über das Projekt nicht viel sagen
Es würde auch lange dauern das alles zu erklären.

Zurück zur Frage: Weiß jemand wie dies möglich ist (falls es überhaupt geht)?

lol das geht nich lol

devkid

Bake schrieb:

Die ganze Geschichte war nicht meine Idee und ich darf direkt über das Projekt nicht viel sagen

Dann darfst du auch nicht erwarten, dass du Antworten bekommst, wenn du nicht einmal genau erläutern kannst, was du eigentlich willst...

du willst dich also (so hab ichs verstanden) in einen verbundenen TCP socket
einklicken, also daten senden die so aussehen, als kämen sie von dem anderen
socket?

nun dann würde ich RAW-sockets empfehlen, du kannst den ip-header ändern, sodass
der port auf den des anderen sockets zeigt, oder du nimmst SO_REUSEADDR um
einen socket nocheinmal an diese addresse zu binden.

ohne viele informationen wird das aber schwer dir zu helfen

devkid

Unter POSIX könntest du den File-Descriptor des Sockets mittels dup () replizieren, keine Ahnung ob es so etwas ähnliches auch unter Windows gibt.

Bake

Dann darfst du auch nicht erwarten, dass du Antworten bekommst, wenn du nicht einmal genau erläutern kannst, was du eigentlich willst...

Ich habe erklärt was ich gerne wissen möchte. Oder hast du Probleme mich zu verstehen? Also ich finde die Frage ist klar formuliert. Und woher weißt du was ich erwarte? Ich erwarte keine Antworten... ich hoffe darauf HILFREICHE Antworten zu bekommen. Es sollte klar sein was ich machen möchte (muss). Wenn du keine Ahnung hast dann lass mich doch ohne Antworten stehen. Wäre mir jedenfalls lieber.

du willst dich also (so hab ichs verstanden) in einen verbundenen TCP socket
einklicken, also daten senden die so aussehen, als kämen sie von dem anderen
socket?

nun dann würde ich RAW-sockets empfehlen, du kannst den ip-header ändern, sodass
der port auf den des anderen sockets zeigt, oder du nimmst SO_REUSEADDR um
einen socket nocheinmal an diese addresse zu binden.

Das ist doch schon hilfreich

Ich verstehe ja, dass ich genügend Informationen mitliefern sollte. Also etwas mehr Details: Ich muss eine Anwendung gegen Angriffe (besonders Eingriffe) schützen. Diese Anwedung ist selber ein TCP Client. Um einen Ansatzpunkt zu finden, habe ich mich mal in abenteuerlichen Foren schlau gemacht um zu erfahren wie bei verschiedenen Eingriffen vorgegangen wird (wohl von irgendwelchen "Crackern"). Wenn ein fremder Client Informationen an den Server schickt können wir das relativ leicht erkennen. Probleme würden aber Leute machen die sich irgendwie "einklinken". Mir selber ist so eine Technik nie begegnet, darum habe ich ein "Tool" getestet... es funktioniert leider bestens. Ich kann so Pakete an unseren Server senden ohne das es auffällt. Um das zu verstehen habe ich versucht den Server selber "auszutricksen". Ohne Erfolg. Im Tool muss man nur statt "new Socket" "open Socket" wählen. Darum die Frage. Ich dachte mir, dass die sich doch irgendwie in meinen Client einklinken müssen. Mit dem Programm lassen sich dann beliebige Pakete einschleusen.

devkid

Bake schrieb:

Oder hast du Probleme mich zu verstehen?

Richtig erkannt!

Bake schrieb:

Ich erwarte keine Antworten... ich hoffe darauf HILFREICHE Antworten zu bekommen.

Widerspruch in sich.

Bake schrieb:

Es sollte klar sein was ich machen möchte (muss).

Ist dir noch nicht aufgefallen, dass bis jetzt keiner richtig verstanden hat, was du genau willst?

Es sollte jedenfalls nicht möglich sein an die File-Descriptoren der Sockets (oder wie das unter Windows gemanaged wird) fremder Prozesse zu gelangen. Wenn dein "Tool" das irgendwie schafft, vermute ich einfach mal einen Bug in Windows (gibts ja zum Glück nicht viele...). Die einzige Möglichkeit wäre, dass der Prozess, der den Socket erstellt hat, einem anderen Prozess diesen "freiwillig" übergibt. Aber ich vermute einfach mal nicht, dass dein Client das macht ... ?

Bake

Widerspruch in sich.

Nein? Ich kann doch schlecht hier hinkommen und Antworten auf alle Fragen erwarten. Ich freue mich wenn jemand versucht mir zu helfen... aber erwarten tue ich nichts.

Richtig erkannt!

Ich möchte Pakete an einen Server senden ohne einen Socket erstellen zu müssen. Was ist daran jetzt so schwer zu verstehen?

Ist dir noch nicht aufgefallen, dass bis jetzt keiner richtig verstanden hat, was du genau willst?

Bei dir ist das mehr als offensichtlich. Aber vielleicht ist dir entgangen, dass helferlein schon gut verstanden hat was ich machen will.

du willst dich also (so hab ichs verstanden) in einen verbundenen TCP socket
einklicken, also daten senden die so aussehen, als kämen sie von dem anderen
socket?

Ja. So lässt sich unser Server austricksen. Das darf nicht so sein und ich möchte verstehen wie das funktioniert.

Wenn dein "Tool" das irgendwie schafft

Ein Paket Editor mit "netten" Funktionen.

Die einzige Möglichkeit wäre, dass der Prozess, der den Socket erstellt hat, einem anderen Prozess diesen "freiwillig" übergibt.

Selbstmord? Nein.

einen Bug in Windows

Wie schon gesagt, ich weiß es noch nicht. Es geht aber unter Vista und XP.

nun leider kann man das nicht verhindern, das auf diese weise gefälschte
pakete gesendet werden.

das programm erzeugt vmtl einen raw-socket (socket(AF_INET, SOCK_RAW, 0))
schreibt sich seinen eigenen ip-header, in dem alle informationen
außer der portnummer und der Sequenznummer (für tcp) richtig sind.

port wird auf den port des anzugreifenden sockets gesetzt. wenn man dann das
packet sendet, hat es für den server den anschein, das das packet ganz normal
von deiner anwendung kommt. natürlich gibt es da probleme, da die sequenznummer
jetzt eine andere ist. wie man das löst kann ich dir leider nicht sagen, aber
das ist die "gängige" vorgehensweise.

um dich dagegen zu schützen, musst du

a) jeden anderen prozess / service des systems überwachen, hooken und auf
socketaufrufe warten. (fast unmöglich)
b) deine packete verschlüsseln

wenn der "angreifer" von außen kommt also z.b. ins netz eingeklinkt ist oder
einfach nur die serveraddresse kennt kann er theroetisch im auch gefälschte
daten senden (seit XP sp2 nichtmersoleicht). das kannst du nicht verhindern
außer die daten zu verschlüsseln.

MfG helferlein

devkid

helferlein schrieb:

wenn man dann das
packet sendet, hat es für den server den anschein, das das packet ganz normal
von deiner anwendung kommt. natürlich gibt es da probleme, da die sequenznummer
jetzt eine andere ist. wie man das löst kann ich dir leider nicht sagen, aber
das ist die "gängige" vorgehensweise.

Nunja, für die Sequenz-Nummer könnte man den TCP-Output dumpen. Selbst wenn man keinen Zugriff auf die "echten" Sequenz-Nummern hat, könnte man die sich ausrechnen. Problematisch wirds nur, wenn der Client danach Pakete mit den selben Sequenz-Nummern schickt.

helferlein schrieb:

wenn der "angreifer" von außen kommt also z.b. ins netz eingeklinkt ist oder
einfach nur die serveraddresse kennt kann er theroetisch im auch gefälschte
daten senden (seit XP sp2 nichtmersoleicht). das kannst du nicht verhindern
außer die daten zu verschlüsseln.

Naja, erstmal bräuchte man eine direkte PPP-Verbindung o.ä. (jedenfalls irgendwas, was den Datenverkehr lokal NICHT routet, sondern direkt an den ISP sendet). Und außerdem muss (soweit ich weiß) da der ISP selbst mitspielen. Der könnte ja auch noch prüfen, ob die Absender-IP mit der der IP, die momentan dem Anschluss zugeordnet ist, übereinstimmt.