WSARecv Hook: Paket blockieren

[napsterxx]

Peace, ich hoffe diesmal kann mir jemand helfen.
Ich habe eine DLL in eine Applikation injiziert. Die DLL Hook nun WSARecv und soll die ankommenden Pakete verwalten. Bestimmte Pakete sollen geblockt werden sprich die Anwendung darf sie nicht erhalten.Ich dachte es funktioniert indem ich von der Callback funktion den Rückgabewert auf -1 setze.

Pseudocode

Delphi-Quellcode:

function Callback(...): Int;stdcall;
begin
// ...
if Paket = böse then
Result := -1;
end;

Aber das Paket kommt dennoch an, jemand einen Vorschlag?

[Luckie]

Zitat von napsterxx:

Aber das Paket kommt dennoch an, jemand einen Vorschlag?

Netzwerkkartentreiber.

[wicht]

Ist die Callback-Funktion quasi "dein" WSARecv? Naja, MSDN lesen sollte da helfen. Rückgabewert könnte man SOCKET_ERROR probieren, dazu noch ein WSASetLastError(WSAEWOULDBLOCK). Und eventuell ein Hook auf select() wenn, das Programm so arbeitet (mit Hilfe von select() wird ermittelt, ob ein Socket Daten im Puffer hat, die abrufbar sind, meine ich). Wäre interessant zu wissen, was du genau vorhast

[napsterxx]

Zitat:

Netzwerkkartentreiber.

Ich habe das ganze schonmal auf PCap laufen gehabt, habe es dann aber doch geändert, da ich es besser finde wenn man nicht so viel unnutzes Zeug mitsnifft, zudem gibt es dem Benutzer die Sicherheit, das ich nicht irgendwelche Passwörter mit aufzeichne.

Zitat:

Ist die Callback-Funktion quasi "dein" WSARecv?

Jop

Zitat:

Naja, MSDN lesen sollte da helfen. Rückgabewert könnte man SOCKET_ERROR probieren

Ich dachte Result := -1; ist genau SOCKET_ERROR?!

dazu noch ein WSASetLastError(WSAEWOULDBLOCK) Probiere ich gleich einmeal

Und eventuell ein Hook auf select() wenn, das Programm so arbeitet (mit Hilfe von select() wird ermittelt, ob ein Socket Daten im Puffer hat, die abrufbar sind, meine ich) Wird auch gleich probiert

[Zacherl]

Das wirst du so nicht in den Griff bekommen. Wie gesagt arbeiten die Sockets in deiner Anwendung overlapped. In deiner Callback musst du zuerst die ungehookte Originalfunktion WSARecv aufrufen, damit überhaupt Daten in den Buffer eingelesen werden, die du auf "böse" prüfen kannst.

Das eigentliche Problem ist hier, dass der WSARecv Aufruf bereits eine Callback Routine aufruft, in der die Daten dem Programm zur Verfügung gestellt und weiterverarbeitet werden.

Ein Lösungsansatz, den wir ja schon, wenn auch nicht ganz zufriedenstellend, probiert haben, wäre es die Callback Funktion temporär umzubiegen. Dann könntest du die Daten im Paket ohne Weiteres modifizieren oder das Paket komplett blocken. Je nachdem musst du die Callback Funktion dann am Ende der Hook Callback von Hand neu aufrufen.

Zitat:

lpNumberOfBytesRecvd [out]
A pointer to the number, in bytes, of data received by this call if the receive operation completes immediately. If the lpOverlapped parameter is non-NULL, this parameter is optional and can be set to NULL.

lpFlags [in, out]
A pointer to flags used to modify the behavior of the WSARecv function call. For more information, see the Remarks section.

lpOverlapped [in]
A pointer to a WSAOVERLAPPED structure (ignored for nonoverlapped sockets).

lpCompletionRoutine [in]
A pointer to the completion routine called when the receive operation has been completed (ignored for nonoverlapped sockets).

Fangen wir an: lpNumberOfBytesRecvd war bei dir immer 0, da overlapped Sockets verwendet werden. lpCompletionRoutine ist (leider) ebenfalls nil. Laut MSDN bedeutet dies:

Zitat:

hEvent
If an overlapped I/O operation is issued without an I/O completion routine (the operation's lpCompletionRoutine parameter is set to null), then this parameter should either contain a valid handle to a WSAEVENT object or be null. If the lpCompletionRoutine parameter of the call is non-null then applications are free to use this parameter as necessary.

(Auszug aus der WSAOVERLAPPED STRUCT Beschreibung)

Meine Vermutung war es, dass ein Thread darauf wartet, dass das Event aktiviert wird und dann eine Art Datenverarbeitungsroutine aufruft. Deshalb setzten wir hEvent auf ein von uns erstelltes, irrelevantes Eventhandle befor die Original WSARecv Funktion aufgerufen wird.
Am Ende der Hook Callback Funktion wurde SetEvent() auf das Original Eventhandle angewendet. Es war mehr eine Vermutung, dass es so funktionieren könnte, die gehookte Anwendung allerdings beendete sich unmittelbar mit einem "Critical Error".

[wicht]

Ich dachte Callback() wäre die Gehookte WSARecv() Funktion. Von Overlapped stand hier doch noch gar nix? Aber wenn das so ist, muss man das Problem wohl anders angehen...

[TurboMartin]

Du solltest wirklich mal damit rausrücken, was genau Du mit den ganzen Hooks und co was Du hier nachfragst machen willst. Ggf. gibt es eine einfachere Methode.

Außerdem könntest Du deinen alten Thread weiterverwenden...


[edit]Kann es sein, dass Du bei der Angabe gegen den Verhaltenskodex 2.2 verstößt?[/edit]

[wicht]

Zitat:

Kann es sein, dass Du bei der Angabe gegen den Verhaltenskodex 2.2 verstößt?

Warez und Serials?

[napsterxx]

Warez und Serials?

Also ich sehe weder einen Downloadlink noch eine Serial ......
Aber hier im Board ist ja eh alles womit man etwas "böses" machen könnte extrem negativ und verbote.

Sorry ich vergaß!
Aber das man mit sockets trojaner bauen kann interessiert ja keinen.

Übrigens meine Hochkriminelle-Anwendung ist eine Banlist gegen Cheater!

[Zacherl]

Leute Also seine Callback ist eine gehookte WSARecv() API. Allerdings stellt der Parameter lpCompletionRoutine ja z.b. auch eine Callback Funktion da. War wohl nur eine missverständliche Ausdrucksweise.

Er will eine "Banlist" für WC3 programmieren. So ein Programm gibt es bereits und das Ganze dient auch nicht dazu das Spiel zu manipulieren um Vorteile zu erlangen.