Reverse S4 League

Hey Com ;)
Ich habe langsam keine Ideen mehr...
Ich sitze jetzt schon seit 4Tagen am Clienten aber finden denn Call zu einer bestimmten Funktion nicht. Diese Funk. ruft eine Ingame MsgBox auf & schliest entweder nach einer bestimmten Zeit oder nach betätigen des "Bestätigen" Buttons das Game.

Mehr Info's...
Es ist keine API func.
Sie wird nur 1 mal gecallt.

Meine Vermutung :
Es ist ein jne Jump, mit einem Sleep & einer Exit func.
(Die Exit func ist weder CloseHandle noch Exit noch ProcessClose.)

Hat jemand ne Idee wie ich suchen könnte?

PS. @ MrSm!th pls nicht auslachen ;D

Ty ~Kau~

Was genau hat das nun hier verloren? :O Naja...

Dass es keine API Func ist, ist wohl klar, da es keine gibt, die soetwas bewerkstelligt, zumal die Ingame Messageboxen ja über D3D gezeichnet werden und demnach gar nicht der WinApi bekannt sind.

Sleep halte ich für unwahrscheinlich.
Sleep blockiert nämlich den Thread, es müsste also in einem seperaten Thread laufen der dann halt nach der entsprechenden Zeit den Prozess beendet.

Ich denke eher, es läuft in einem einzelnen Thread und die MessageBox hat genau wie die WinApi MessageBox einen Timeout Parameter, der halt dafür genutzt wird.
Dann wird sicherlich nur in der Event Loop regelmäßig die Zeit per timeGetTime abgefragt und mit dem Timeout Wert verglichen.

ProcessClose existiert nicht in der WinApi, höchstens ExitProcess o.O
CloseHandle schließt überhaupt nichts, bis auf den Handle.

Das schließen läuft übrigens ganz sicher über ExitProcess, nämlich folgendermaßen:

Funktion für die Detection-Benachrichtigung zeigt eine MessageBox.
Bei Bestätigung oder Timeout wird PostQuitMessage aufgerufen, die Windows Message Loop wird verlassen und danach folgt normalerweise nur noch die Freigabe von Resourcen und ein return der WinMain, welches dann in den System Dlls landet, wo dann irgendwo am Ende automatisch ExitProcess (oder die NT Variante; weiß ich nicht genau) gecalled wird.

Was ich für unwahrscheinlich halte ist TerminateProcess, da so Resourcen nicht ordentlich freigegeben werden.

Übrigens bist du falsch: Es macht keinen Sinn, nur die Benachrichtigung zu fixen. Das ließe sich einfach durch einen Statuscheck via Server unterbinden.
Du musst schon an der Stelle angreifen, wo überhaupt entschieden wird, dass die Nachricht angezeigt werden soll, also bei der Hack Detection, XTrap Inaktiv Detection oder whatever und sie entsprechend bearbeiten.
Du killst nur die Folge.

Übrigens, falls du einen Bypass machst, das ist sinnlos, die Verbindung wird trotzdem gekillt, kassierst dann halt nen DC irgendwann und der Client schließt sich nicht.
Du musst schon die XTrap Keep Alives emulieren.
Falls es übrigens wirklich einer wird, kannst du dich zur Übung an Selmans orientieren: Der hat genau das gemacht (auch den PostQuitMessage Hook), nur wie du siehst, ist das mittlerweile durch bessere Server Checks gefixt. Du musst eben nicht das visuelle eleminieren, sondern den Grund, warum es überhaupt erscheint.

Quote:

Originally Posted by MrSm!th Was genau hat das nun hier verloren? :O Naja... Dass es keine API Func ist, ist wohl klar, da es keine gibt, die soetwas bewerkstelligt, zumal die Ingame Messageboxen ja über D3D gezeichnet werden und demnach gar nicht der WinApi bekannt sind. Sleep halte ich für unwahrscheinlich. Sleep blockiert nämlich den Thread, es müsste also in einem seperaten Thread laufen der dann halt nach der entsprechenden Zeit den Prozess beendet. Ich denke eher, es läuft in einem einzelnen Thread und die MessageBox hat genau wie die WinApi MessageBox einen Timeout Parameter, der halt dafür genutzt wird. Dann wird sicherlich nur in der Event Loop regelmäßig die Zeit per timeGetTime abgefragt und mit dem Timeout Wert verglichen. ProcessClose existiert nicht in der WinApi, höchstens ExitProcess o.O CloseHandle schließt überhaupt nichts, bis auf den Handle. Das schließen läuft übrigens ganz sicher über ExitProcess, nämlich folgendermaßen: Funktion für die Detection-Benachrichtigung zeigt eine MessageBox. Bei Bestätigung oder Timeout wird PostQuitMessage aufgerufen, die Windows Message Loop wird verlassen und danach folgt normalerweise nur noch die Freigabe von Resourcen und ein return der WinMain, welches dann in den System Dlls landet, wo dann irgendwo am Ende automatisch ExitProcess (oder die NT Variante; weiß ich nicht genau) gecalled wird. Was ich für unwahrscheinlich halte ist TerminateProcess, da so Resourcen nicht ordentlich freigegeben werden. Übrigens bist du falsch: Es macht keinen Sinn, nur die Benachrichtigung zu fixen. Das ließe sich einfach durch einen Statuscheck via Server unterbinden. Du musst schon an der Stelle angreifen, wo überhaupt entschieden wird, dass die Nachricht angezeigt werden soll, also bei der Hack Detection, XTrap Inaktiv Detection oder whatever und sie entsprechend bearbeiten. Du killst nur die Folge. Übrigens, falls du einen Bypass machst, das ist sinnlos, die Verbindung wird trotzdem gekillt, kassierst dann halt nen DC irgendwann und der Client schließt sich nicht. Du musst schon die XTrap Keep Alives emulieren. Falls es übrigens wirklich einer wird, kannst du dich zur Übung an Selmans orientieren: Der hat genau das gemacht (auch den PostQuitMessage Hook), nur wie du siehst, ist das mittlerweile durch bessere Server Checks gefixt. Du musst eben nicht das visuelle eleminieren, sondern den Grund, warum es überhaupt erscheint.

Danke!
Das ich in der "falschen" Sek bin hab ich zuspäht bemerkt... sry
Die keep Alives werden doch trotzdem gesendet oder nicht? ;O Wozu dann emulieren? und sel hat kein PQM gehook ;) BR & HTD bzw Hackversuch werden ja per jne abgefragt, das habe ich schon gefunden~ aber wie soll ich die stelle finden wo xtrap rum heult? ;O kannst du mir pls nen Tip geben....
~Kau~

du suchst zb die msg, bei der xtrap rum meckert(zb: "Trolo hack detected" oder halt die msg die du suchst..), und dann suchst du den anfang von dem, sprich du suchst und suchst, bis du zum anfang gelangst wo die ganze überprüfung startet für diese msg.

so sollte es auch gehen bei xtrap denk ich mal..

XTrap hat doch eine Themida mit Runtime Encryption + VM oder?

Quote:

Originally Posted by Headpuster XTrap hat doch eine Themida mit Runtime Encryption + VM oder?

naja s4 ist mit themida gepackt, was du mit "XTrap hat doch Themida" meinst kp.
und eine runtime encryption hat es. bzw s4 wird runtime enyrptet

Quote:

Originally Posted by ~kau~ Danke! Das ich in der "falschen" Sek bin hab ich zuspäht bemerkt... sry Die keep Alives werden doch trotzdem gesendet oder nicht? ;O Wozu dann emulieren?

Weil sie eben nicht gesendet werden, wenn ein Hack detected wird oder XTrap ganz fehlt.
Also musst du sie emulieren und wenn du das tust, kannst du XTrap btw. auch gleich ganz raushauen.

Quote:

und sel hat kein PQM gehook ;)

Doch, unter anderem auch. Als dieser Fix kam, dass man die Meldung nicht mehr skippen konnte, musste er halt verhindern, dass sich nach Bestätigen der Client nicht schließt. Kann auch sein, dass er es etwas anders gemacht hat, aber im Prinzip gehts so und freehuntx hat die Methode verwendet.

Quote:

BR & HTD bzw Hackversuch werden ja per jne abgefragt, das habe ich schon gefunden~

Die Art das Jumps ist doch völlig irrelevant. Du sollst nicht die Stelle finden, ob diese Message angezeigt werden bzw. der GameState auf diesen Status gesetzt werden soll, sondern die Stelle, bei der überhaupt entschieden wird, DASS das alles passieren soll, also dort, wo der Hack eigentlich detected wird.
Du bist an der völlig falschen Stelle :P

Quote:

aber wie soll ich die stelle finden wo xtrap rum heult? ;O kannst du mir pls nen Tip geben.... ~Kau~

Meinst du wirklich XTrap oder die Message im Client? Letzteres ist total einfach, aber bringt dich keinen Schritt weiter.
Ersteres, also die Hack Detected Message von XTrap selbst, wird im Prozess XTrap.xt generiert und bringt dich genau so wenig weiter ;O

Quote:

du suchst zb die msg, bei der xtrap rum meckert(zb: "Trolo hack detected" oder halt die msg die du suchst..), und dann suchst du den anfang von dem, sprich du suchst und suchst, bis du zum anfang gelangst wo die ganze überprüfung startet für diese msg.

Nein, du wirst höchstens den String im Speicher finden, aber nicht die Stelle, wo er gepusht wird, da das dynamisch passiert und nicht als String Reference von Olly erkannt wird.
(Außerdem passiert das "Program XXX detected" sowieso nicht in S4Client, wie gesagt)

Quote:

XTrap hat doch eine Themida mit Runtime Encryption + VM oder?

XTrap ist mit Themida gepackt, ja. Zur Laufzeit wirds doch entschlüsselt, nicht verschlüsselt :P Oder was meinst du?

Bei VM bin ich mir nicht mehr ganz sicher, soweit ich weiß aber nicht.

Quote:

naja s4 ist mit themida gepackt, was du mit "XTrap hat doch Themida" meinst kp. und eine runtime encryption hat es. bzw s4 wird runtime enyrptet

Es wird runtime decrypted.

uff,ja decryptet, denk fehler beim schreiben D:

und ich sagte doch nicht das, bla program erkannt wird, im S4Client zu finden ist :p

und sicher das man an den string kommt anstatt den push ? man sucht doch nicht nach dem string.. oder hab ich deinen satz falsch verstanden?^^

Ich dachte, du meinst, er soll nach dem String suchen.
So oder so, du findest nicht zu jedem String eine Push Reference, da sehr viele dynamisch übergeben werden und nicht hardcoded sind.

Es gibt doch sicherlich Wege von den dynamischen Adressen noch zu den hardcoded String zu kommen ;O?

weil hardcoded strings in ner languagefile.dat auch so leicht zu finden sind.

oh...

Quote:

Originally Posted by Omdihar Es gibt doch sicherlich Wege von den dynamischen Adressen noch zu den hardcoded String zu kommen ;O?

Irgendwie verstehst du nicht, worum es geht.

1. Geht es hier nicht um den String selbst, sondern die Referenz, dort, wo er gepusht wird. Und das sind nunmal keine hardcoded Adressen, sondern Dinge wie push [eax+5]. Das kann Olly nicht finden.

2. Die Strings werden dynamisch zusammengesetzt, schließlich ist die Meldung immer anders..

Stringsearch sollte verständlicherweise immer der letzte Ansatz sein.