Injector for Guild Wars (Gw.exe)

[Atheuz]

Originally Posted by numbgalore

Nun zickt mal nicht gleich rum Mein voller ernst. Kommt da jetzt noch was?

Ich sag mal wenn ich den Beispielcode von hier:

leicht ändere, meinen Namen reinschreibe und kompiliere dann kommt das selbe bei raus.

Aber mal wieder konstruktiv: das ganze ist doch ausbaufähig. Vllt. gelingt es ja Key und Mouse Events einzuschmuggeln ohne dass das Fenster den Focus haben .. oder auf der gleichen Hardware laufen muss.

Das hab ich mir beim ersten mal wo ich den Thread gesehen habe auch gedacht.
Jemand versucht sich an ein Gebiet ranzutasten und postet seine ganzen Ergebnissen aus den Tutorials. Eine msgbox in den stack zu laden lernt man in jjedem Tutorial (z.B das Tutorial auf Gamehacking wo ein Injector gemacht wird der eine dll injeziert mit einer msgbox ;D ) bei denen es darum geht im stack adressen zu verschieben und routinen zu finden. wadimwadim hat sich anscheinend so darauf fixiert irgendwelche funktionen zu callen das er vergessen hat das er dazu die pointer berechnen muss, sonst ist das nutzlos. Könnte man damit vergleichen das ein Architekt ein Dach bauen muss, aber keine ahnung hat wie das Haus überhaupt aussieht. Und über WinProc Tasten an den Prozess zu schicken ist auch keine Meisterleistung, dass geht sogar in AutoIt ohne Probleme, nur frage ich mich wieso das nie benutzt wird.

Villeicht sollte man es erst bei einem billigen Spiel, oder bei einem eigenes sich daran probieren.
Imo finde ich das wenn man sich an Guild Wars versucht, die Lernfähigkeit und Motivation in den Keller rutschen. Wenn man was akzeptables bei einigen Games hinbekommen hat, kann man ja wieder zu Guild Wars zurückkehren. Erfahrung sammeln eben.

[blauwiggle]

ich finde, dass man wadi jetzt nicht deswegen fertig machen muss? er und azunai arbeiten auf nem anderen level als die meisten hier im gw forum ...

[numbgalore]

Originally Posted by Atheuz

Und über WinProc Tasten an den Prozess zu schicken ist auch keine Meisterleistung, dass geht sogar in AutoIt ohne Probleme, nur frage ich mich wieso das nie benutzt wird.

Das Problem ist ja dass das Fenster den Focus haben muss bei AutoIt und bei SendMessage/PostMessage (was autoit auch unterstüzt) braucht man das handle zum Window was die "WM_" messages für die Tastatur / Maus verarbeitet. Das handle ist mir unbekannt.

Ich selbst habe bisher nur mal einen Bot Prototypen in autoit gemacht um auszuloten was geht. Derzeit sitze ich an der Java Umsetzung mit JNA API. Das Problem ist aber nach wie vor das gleiche.

Optimal wäre für mich ein Inject einer DLL die Events von extern direkt in die Messagequeue des Hostprozesses bringt. Ich fragte vor einer Woche hier auch mal nach ob das schon einer gemacht hat weil meine Versuche immer das Feedback Fenster von ANet als Resultat hatten.

naja, schaun wir mal, vllt. entwickelt sich ja grad was.

[yesar]

ich bezweifel dass arenanet sowas zulässt. ich bin mir zwar nich sicher was schutzmassnahmen angeht, aber ich könnte mir vorstellen, dass sowas wie ein stackpointer/counter (oder war es heap auf dem die funktionsaufrufe abgelegt werden...?) existiert, der abfrägt und sichert. der netzwerktraffic wird bei gw afaik schon gehash-checkt um bots fern zu halten und zu erkennen...
nebenbei, mit java und jni (denke du meinst jni statt jna oder für was steht jna?) dürfte das n ziemliches gefummel sein, von der performance ganz zu schweigen. wenn du eh ne dll in c schreiben musst, kannst du das ganz prog doch auch in c schreiben oder warum willst du java verwenden?

[Azunai]

nicht so voralleilig alle, du kannst interne func in gw ja auch über injectend dll --> inline asm call aurufen

[Trade4Real]

jupp und falls geblockt kannste nen Hook schreiben in C das ist auch nicht die Welt, dann funktioniert inline asm auch wieder

[Atheuz]

Originally Posted by numbgalore

Das Problem ist ja dass das Fenster den Focus haben muss bei AutoIt und bei SendMessage/PostMessage (was autoit auch unterstüzt) braucht man das handle zum Window was die "WM_" messages für die Tastatur / Maus verarbeitet. Das handle ist mir unbekannt.

Das Handle sollte imo doch das leichteste übel sein, man muss ledeglich die Fenster auflisten und die prozesse vergleichen. Aber auch ein Teil wieso ich auf AutoIt verzichtet habe, in MicroMacro ist das in 2 Zeilen Lua script fertig

Originally Posted by blauwiggle

ich finde, dass man wadi jetzt nicht deswegen fertig machen muss? er und azunai arbeiten auf nem anderen level als die meisten hier im gw forum ...

Ich mach ihn doch garnicht fertig, was für Vorstellungen hast du lol.
Das einzigste was ich kritisiert habe an ihm, dass er wien blöder gegen eine Wand lauft und was entscheidendes nicht bemerkt.

Originally Posted by Azunai

nicht so voralleilig alle, du kannst interne func in gw ja auch über injectend dll --> inline asm call aurufen

Oh wow, da schreiben 2 User was von funktionen callen in GW und aufeinmal gibts Unruhe. Das Problem dabei ist das ständig sich die Positionen wechseln davon wechseln, deswegen finde ich das auch so schwachsinnig wenn er sich dauernd an Guild Wars versucht. Das ist auch das entscheidende und nervigste Problem was man an Guild Wars lösen muss bevor man überhaupt weitergehen will.

[blauwiggle]

Originally Posted by Atheuz

Das Handle sollte imo doch das leichteste übel sein, man muss ledeglich die Fenster auflisten und die prozesse vergleichen. Aber auch ein Teil wieso ich auf AutoIt verzichtet habe, in MicroMacro ist das in 2 Zeilen Lua script fertig

Ich mach ihn doch garnicht fertig, was für Vorstellungen hast du lol.
Das einzigste was ich kritisiert habe an ihm, dass er wien blöder gegen eine Wand lauft und was entscheidendes nicht bemerkt.

Ich spreche von so nem "goldigen"

[numbgalore]

Originally Posted by yesar

nebenbei, mit java und jni (denke du meinst jni statt jna oder für was steht jna?)

Der erste Eintrag in Google führt dich direkt dort hin

JNA=Java Native Access. Für die nativen Aufrufe nimt JNA selbstverständlich einen JNI Peer.

Originally Posted by yesar

dürfte das n ziemliches gefummel sein, von der performance ganz zu schweigen. wenn du eh ne dll in c schreiben musst, kannst du das ganz prog doch auch in c schreiben oder warum willst du java verwenden?

Weder gefummel noch gibt es performance Probleme mit Java. (Typisches Trollthema ) Rich Clients und Server mache ich nur noch in Java. Die DLL wird in C gemacht, das ist klar!

Originally Posted by Atheuz

Das Handle sollte imo doch das leichteste übel sein, man muss ledeglich die Fenster auflisten und die prozesse vergleichen. Aber auch ein Teil wieso ich auf AutoIt verzichtet habe, in MicroMacro ist das in 2 Zeilen Lua script fertig

Ich habe über alle Child Windows iteriert und das Window für die Eingabe nicht gefunden. Vllt. machen die das auch irgendwie anders. Jetzt bräucht man mal wieder SPY++. Hast du noch ne Idee sonst ?

[numbgalore]

Originally Posted by blauwiggle

Ich spreche von so nem "goldigen"

Da kann ich dich beruhigen, das ist nicht der Fall. Wenn es dem betroffenen so vorkam, dann: GOLDIGES SORRY

[wadimwadim]

mir machts nix aus hier seriöse kritik zu hören. das meiste stimmt ja.
nun möchte ich aber gerne wissen, was numbgalore vor hat. möchtest du tasten in gw simulieren?

[numbgalore]

Ich möchte grob gesagt Tasten und Mouse unabhängig vom Windowstate simulieren. Wenn das gut klappt dann sehe ich auch einen Fernzugriff über Netz direkt in der dll, oder wenn das nicht geht dann über einen lokalen Proxy.

        Host 1                     Host n
   Bot Steuerung      --->      [Proxy]  GW n

[yesar]

Originally Posted by numbgalore

Der erste Eintrag in Google führt dich direkt dort hin

JNA=Java Native Access. Für die nativen Aufrufe nimt JNA selbstverständlich einen JNI Peer.

davon hab ich bis jetzt noch nie was gehört. sieht aber auf den ersten blick richtig genial aus. werd ich mir bei zeiten mal genauer ansehen, das kann ich auch gut für die arbeit benutzen

Originally Posted by numbgalore

Weder gefummel noch gibt es performance Probleme mit Java. (Typisches Trollthema ) Rich Clients und Server mache ich nur noch in Java. Die DLL wird in C gemacht, das ist klar!

wow... jetz bin ich doch etwas sprachlos... da lernt man im studium alles mögliche, aber sowas wird einem dann wieder verschwiegen. noch ein grund mehr, sich mehr mit java zu beschäftigen.
hab mir hier mal das benchmark angeschaut und würde sagen, das ist in etwa ausgeglichen. aber nichts desto trotz hat bei mir java das image "langsam" damit verloren

danke für die belehrung/bereicherung, man lernt doch nie aus
nebenbei gleich die frage: hast du denn vielleicht ein paar links zu dem thema jna oder buchempfehlungen?

[numbgalore]

JNA ist nicht sehr popuär und wird auch von JInvoke verdrängt. Gibt über beide nicht sehr viel. In Zeiten wo die meisten Java Entwickler J2EE (würg) machen auch nicht weiter verwunderlich

- JNA ist nicht Ready-To-Use. Du musst dir Kernel32, User32, Win32 usw selber erst aus den Examples zusammenflicken und das ganze ist auch nur für die Examples hingecoded. Es fehlen die meisten API Calls. Was eigentlich nicht weiter schlimm ist. Winconstants musst du dir auch noch besorgen.
Java Native Access ? Wikipedia

- JInvoke ist fertig, kostet aber mind. 175$ die man aber sparen könnte. Faktor Faulheit entscheidet.




Das Image Java=Lahm kommt von schlecht gemachten Applets und unsauberen Swing-Rich-Clients. Es ist einfach in Java viel falsch zu machen.

have fun

[Atheuz]

Originally Posted by numbgalore

Ich habe über alle Child Windows iteriert und das Window für die Eingabe nicht gefunden. Vllt. machen die das auch irgendwie anders. Jetzt bräucht man mal wieder SPY++. Hast du noch ne Idee sonst ?

Das kann tatsächlich sogar an Guild Wars liegen (z.B bei Spielen die aufhören im Hintergrund weiter zu arbeiten. Hab Guild Wars nichtmehr, kann es leider nicht mir anschauen). Oder an AutoIt. Jedenfalls
musste ich nie die ganzen Child Windows Hooken.