Hey,
ich versuche die Funktion recv zu hooken ohne das der hook entdeckt wird. Kurzsichtig wie ich bin hab ich bei send nen midfunction hook gemacht nur bei recv muss sich der buffer ja erstmal füllen also kann ich erst fast am ende der Funktion hooken. Das hab ich auch probiert nur irgendwie funktioniert das nicht.
76AA4883 |. 8B45 08 MOV EAX,DWORD PTR SS:[EBP+8]
76AA4886 |> 5E POP ESI
76AA4887 |. 5B POP EBX
nur fürhte das zu problem und irgendwie krieg ich das mit dem ollydbg debuggen unter 64bit(was ich seit 3tagen habe) nicht auf die kette. Also hab ich aus verzweiflung hier versucht zu hooken
Code:
76AA4868 |. E8 E3E7FFFF CALL 76AA3050
jedoch mit dem Hintergedanken könnte mehrfach aufgerufen werden und somit zu problemen führen und das passierte dann auch.
Weiss vlt jemand von euch wie ich mein denken in die Tat umsetzen kann und recv undetected hooke.
das spiel ist mit hackshield versehen, hwbp waren auf 32bit ohne einen hook auf kernelebene nicht möglich und auf 64bit hab ichs noch nicht probiert und mich auch noch nicht mit der Treiberprogrammierung beschäftigt. Man könnte bestimmt NtReadProcessMemory hooken um den buffer zu manipulieren nur wollte ich das ja eben vermeiden indem ich einfach in der mitte oder irgendwo in der funktion hooke. So wie ich bis jetzt hooke kommt es zu keiner detection oder so(vermute ich weil das game einfach abschmiert).
Kurzsichtig wie ich bin hab ich bei send nen midfunction hook gemacht nur bei recv muss sich der buffer ja erstmal füllen also kann ich erst fast am ende der Funktion hooken.
Den Gedankengang kann ich nicht nachvollziehen, wo ist das Problem?
ja ich weiss net wieso aber es kackt einfach ab xD nachdem nen paar packet gesnifft worden sind das heisst ja dann eig. das am hook was failed nur kann ich das ganze ne debuggen. Eig. wäre auch ne frage wie ich das mit dem debuggen auf 64bit windows 7 mache um dann das ganze mir anzugucken xD hab wohl zum teil bisschen die überschrift gestern nacht vefehlt.
in deiner midfunction:
-rücksprungadresse über stackpointer auslesen und speichern.
-rücksprungadresse auf eigene adresse manipulieren.
-Bufferptr/length abspeichern.
-normale funktion weiterlaufen lassen.
in der funktion die jetzt als rücksprung definiert ist:
-register/eax speichern.
-buffer ist nun gefüllt, tu was du nicht lassen kannst.
-zu gespeicherter originalrücksprungadresse springen.
Was machst du denn dann, wenn du direkt am Anfang mit nem konventionellen Detour hookst?
Du machst doch in deinem Hook etwa sowas, wenn du die Bytes nach dem Empfangen manipulieren willst
Code:
int hkRecv(SOCKET s, char *buf, int len, int flags)
{
int result = recv_orig(s, buf, len, flags);
*((short*)buf) = 0x1337:
//whatever
return result;
}
Wo ist dann nun dein Problem?
Wenn du kurz nach Anfang hookst, wie du es auch bei send tust, rufst du halt erst dein Trampolin auf, welches mit dem orginalen Funktionsfluss weitermacht und bearbeitest den Buffer danach.
Es ändert sich doch nicht wirklich was, du musst halt nur auf den Stack besonders aufpassen, da lokale Variablen etc. schon alloziert sein könnten.
Kommt halt drauf an, wo du genau hookst.
es ist um einiges schwieriger inmitten der funktion ein funktionierendes trampolin zu basteln.
am anfang zu hooken gibt einem den vorteil, dass man das trampolin CALLen kann und er nach ausführung der originalen funktion zurückkommt.
Mit dem trampolin mitten in der funktion, wo die hälfte der funktion schon abgelaufen ist, geht das idr. nicht mehr und wirst dir im zweifelsfall den stack kaputthauen.
wenn man nur jumpt, muss man ohnehin die rücksprungadresse aufm stack umbauen.
Es ist schwerer, aber nicht unmöglich oO
Es ist außerdem nicht mitten drin, sondern um solche grundlegenden Checks zu umgehen reicht schon ein Offset größer 5, um halt nicht den Standard Detour zu haben.
Dann wird manchmal noch das Ende der Funktion kontrolliert und alles andere ist eh außerhalb jeglicher Checks, die man mit Offsets umgehen kann.
Wenn dazwischen der Hook noch detected wird, wird wohl ziemlich wahrscheinlich ein Hash der ganzen Funktion berechnet.
Man muss jedenfalls nicht mitten drin hooken, will ich damit sagen.
Was übrigens den Stack angeht:
Mitten drin kannst du zwar nicht callen, aber jumpen und dann halt die Return Adresse so manipulieren, dass der Flow danach wieder zu deiner Routine geht, bevor du dann returnst.
Aber im Grunde ist es doch genau das, was du geschrieben hast, seh ich gerade.
hey,
also ich hab das ganze jetzt mal so versucht wie ihr das gesagt habt.
Hier erstmal meine Funktion die ein Detour schreiben soll und durch das Trampolin erst die orig_funktion aufruft(will da vlt noch was mit disasm librrary einbringen um den size parameter zu entfernen).
so das funktioniert soweit auch ganz gut wenn ich normal bei recv hooke. Versuche ich 5 opcodes später zu hooken funktioniert das auch noch bis die die orig_recv returned. Der return führt irgendwo ins nirgendwo lol.
Code:
int hkRecv(SOCKET s, char * buf, int len, int flags)
{
//__asm sub esp,4
int i = orecv(s,buf,len,flags);
return i;
}
DeourWithTampoline((unsigned char*)GetProcAddress(GetModuleHandle("Ws2_32.dll"), "recv")+5, (unsigned char*)&hkRecv, (void**)&orecv, 6);
Aber das kann doch so auch gar nicht gehen weil auf dem Stack ja schon einmal gepushed wurde und zwar "push ebp". Wenn ich vorher den stack um 4 verringer returned nach dem orig_recv zum orginalen rücksprungs punkt und nicht zurück zu meiner hkRecv. Den Stack einfach um 4 verringern ist glaube auch keine gute idee das haut ja alles kaputt .
machs doch einfach so wie ich gesagt habe, mit 2 funktionen, von der die erste die midfunctionhook ist, die nichts anderes macht als die rücksprungadresse auf die 2. funktion zu korrigieren und die parameter sichert, und die 2. die dann nachher die parameter auswertet.
dann brauchste dich bis auf um an die parameter und an die rücksprungadresse ranzukommen überhaupt nicht um den stackkram zu kümmern.
Die disasm lib wird dir kaum helfen, da der stack bei jeder Funktion anders beschaffen sein kann, wo du deinen hook platzierst. Was genau du sichern und was du korrigieren musst, musst du dir also eh immer selbst ansehen.
btw. Das was du da in deiner Detour Function schreibst kannst du auch gleich mit Ms Detours machen, das ist wesentlich besser als so eine selbstgebaute Funktion und hat auch noch besagte disasm Lib direkt intern.
ales das funktioniert auch soweit returned zu meiner funktion ich führe meine funktion aus und springe zum orginalen punkt und dann ka wieso crashed es danach irgendwie. Hab zum testen die parameter einfach mal raus gelassen
[Recv] Send Self 10/31/2011 - Nostale - 4 Replies Ich wollte fragen ob hier noch irgendwer erfahrungen in ASM hat.
Suche nämlich die Sendself Funktion aber weiß ned wie ich weiter suchen soll habs schon rückwerts über die Sockte Funktionen versucht aber kein wirklicher Erfolg.
Brauche die Send Self Funktion um nach Sendpackets zu suchen.
Falls mir wer Helfen kann aber ned offen osten will geht auch per PN.
Send Recv 08/18/2009 - Kal Online - 0 Replies Hey;)
I start checking this code http://www.elitepvpers.com/forum/kal-hacks-bots-che ats-exploits/189618-release-kalhackzz-v0-3-v0-4-so urces.html but i cant still send a packet of move just to see my player moving.Maybe this code is obsolete i dont know if there are better send and rev codes just tell me
When dll process attach happens i call my function _beginthread(f,0,NULL);
void f(void* start_parameter){
Console(); //Get the console
printf("DLL loaded");
[help] recv 08/02/2009 - Kal Online - 3 Replies Soo,
man man behinderter tag.
naja wayne.
bin grad dabei mich etwas mehr mit den recv packets außeinander zu setzen.
unter anderem mit den zahlen dahinter.
Borsti sagte das ist die größe (size)
naja also ich hab mir das mal als hex ausgeben lassen (das packet für empfangene nachrichten im chat )
ich hab mir das folgendermaßen "notiziert"
0c 00 3c //size
44 65 6e 4a 61 73//name
[Question] Hooking send() & recv() works, but recv hiding data for co??? 05/06/2009 - CO2 Programming - 2 Replies Hey guys, I've been making a DLL to allow another program to intercept the packets of conquer using windows pipes. (Then its the job of the main program to decrypt the packets, the DLL only gives a communication channel for the main program)
(winsock functions btw)
- hooking send() works fine for my internet browser
- hooking recv() works fine for my internet browser
- hooking send() works fine for conquer online
NP recv 1226 help 02/26/2009 - General Coding - 0 Replies I am trying to bypass np rev 1226.
I recovered R3 API in kernel mode in the earlier rev.
but this time, I do it in same way, it can not work! It seems the access to the hooked R3 API addr is forbidden in this rev:mad:.
Anybody can help on this? How to recover it?:(
Thx a lot! :)