Warden Frage

Heyho,

ich habe mich jetzt mal etwas über Warden informiert, aber nicht wirklich viel herausgefunden, und wie es mir scheint wissen doch noch einige mehr als Google einem ausspuckt.

Das, angeblich, niemand genau weiß was und wie Warden detected habe ich begriffen.
Das solange mann nur vom Speicher ausliest Warden nichts tut, auch!

Allerdings würde mich jetzt eben intressieren von welchen Adressen man sicher weiß das Warden diese überpfrüft, usw.

Vielen Dank

LG


BTW: Wie wärs mit nem WoW Codingbereich?

Quote:

Originally Posted by deestruct BTW: Wie wärs mit nem WoW Codingbereich?

Habe ich auch schon drüber nachgedacht, ich werd mal Salo anhauen.

Quote:

und wie es mir scheint wissen doch noch einige mehr als Google einem ausspuckt.

Nun, das hat durchaus auch noch andere Gründe. Niemand will genau verraten was er weiß. Das ist ähnlich wie mit den wirklich guten Farm/Grind-Plätzen oder Gold-Tipps. Du erfährst auf ganz klare Anfragen i.d.R nur Dinge, die sowieso schon lange jeder weiß, oder subtile Antworten ohne Hintergrund. Wenn Du Glück hast kommt mal was von jemanden, der mit WoW aufhört oder selbst genug Gold gesammelt hat. Dann verrät er seine Tricks.

Aber nochmal zu Deiner Frage. Bei Warden ist es aber durchaus nicht leicht genau herraufzufinden, was genau gescannt wird, da Warden an sich verschlüsselt ist und auch verschlüsselt kommuniziert. Allein die (Klartext -)Kommunikation Warden <=> Server muss interpretiert werden und ist ganz sicher nicht selbsterklärend. Die allermeisten Hobby-Programmierer scheitern daran Warden im Debugger laufen zu lassen, weil es sehr sehr viele Möglichkeiten gibt ein Debuggen zu verhindern. Im gleichen Zug gibts aber auch genausoviele Tricks es doch zu tun. Nur trennt sich genau hier die Spreu vom Weizen. Und was ist wenn Warden detected, dass Du versuchst den Code zu debuggen ? Das ist mit einer Operation am offenen Herzen vergleichbar...
Und Multithreaded Applikationen zu debuggen ist auch nicht jedermanns Sache.

Ein weiterer Punkt ist, dass Warden generische Scanmethoden nutzt. D.h. die Region, die gescannt wird, wird z.B. als Argument für eine generische Scanmethode dem Client zur Laufzeit übergeben. Dafür gibts dann wieder Memory Monitore, die mit Hooks arbeiten, um dies herrauszufinden. Diese Hooks wiederum sind auch detectbar....so geht dieses Ping-Pong immer wieder hin und her.
Dabei sind Scans, die Veränderungen an den MPQ-Dateien suchen noch die einfachsten.
Du siehst es gehört schon etwas Know-How dazu und die Zahl derer sind wesentlich dünner als die, welche ein Auto-It Script coden und eine paar Speicherbereiche aus WoW.exe auslesen, was bitte wertungsfrei zu verstehen ist.

Besser hätte ich das auch nicht formulieren können, sehr gut geschrieben.

BTT: Wenn du wissen möchtest, ob eine spezielle Adresse gescannt wird, gebe ich dir einen Tipp. Lad dir OllyDBG, mach ein Breakpoint auf die Adresse und wenn dann nach 15 Minuten nichts passiert, weißt du, dass Warden sie nicht scannt.

Das ist so ziemlich die einfachste Methode, herauszufinden, ob eine Adresse gescannt wird.
Ich denke nämlich nicht, dass dir irgendwer mehr Informationen gibt, die für jeden nachlesbar wären. ;-)

Öhm...
Ich glaube [Only registered and activated users can see links. Click Here To Register...] bekommt man relativ gute informationen zu dem thema ^^

kann mir jemand sagen ob Warden auch Fenster Detected? also z.B. wenn ein Programm in WoW ein Fenster Zeichnet?

Das hängt davon ab was Du genau meinst. Wenn Du addons wie AVR meinst, die dies über Lua-Funktionen tun, dann ist es solange erlaubt wie es die Lua-API zulässt.
Wenn Du damit meinst, dass Du eine Dll-Injektest, um damit Funktionen im WoW-Kontext aufzurufen, dann würde ich das als sehr gefährlich betrachten.
Grundsätzlich ist es sehr einfach dies zu detecten, aber soweit ich weiß wird nichts generisches erkannt, sondern ganz gezielt gescant.

um es genauer zu Erklären, es wäre halt ein Fenster wo man ein Radar sieht.

Wenn Du nur Memory-Reads nutzt um an die verfügbaren Objekte zu kommen und das Programm selbst eigenständig laufen lässt ==> unwahrscheinlich.... Nachteil, Du musst es entweder auf 2ten Monitor setzten, oder immer ALT-TABBEN, bzw mit transparenten Fenstern arbeiten.

Wenn Du eine DLL-Injektest, um WoW-interne Funktionen aufzurufen, um an die Daten zu kommen, oder um ein Fenster im WoW-Kontekt zu erzeugen, z.B. so das es direkt in WoW sichtbar ist ==> gefährlich

Werde mich dort gleich mal rein Arbeiten, wenn dann sollte es eher ein Gatherer Bot werden als nur ein Popeliges Radar, danke für die Infos.

Ich hab übrigens einen kompletten Source Code eines Gatherer Bots released, im WoW Bots Forum. Könnte dir bestimmt auch helfen ;)

Danke, wäre nur noch das Problem das ich bei C++ Brechreitze bekomme.

Brechreize? Ist doch eine wunderschöne Sprache oO

kann nur AS3,Java,VB6 und C#

Ich möchte mich mehr auf die abstrakte, erklärende Weise äußern. Den Code daraus zu bauen überlass ich jedem selbst, das ist letztendlich das kleinere Problem.

Und @TE, wenn Du doch alles googeln kannst stellt sich sicherlich die berechtigte Frage, warum Du überhaupt postest....

Wäre es Dir lieber gewesen, hier hätten 10 Personen geantwortet:

"Google is Dein Freund.." oder ähnliche Flames ?

Ich habe auf Deine Frage geantwortet, weil ich Dir in Deinem Verständnis helfen wollte.

Nun ( auch auf abstrakte Weise ) zu dem schönen INT3 "Attach to Process" mit OllyDb .... Eine Detection dazu zu schreiben ist in weniger als 3 Zeilen Source-Code getan, somit würde ich noch mehr davon abraten ...

Warum ? Nun...

Ein Breakpoint wird definiert mit dem Überschreiben des ersten Opcodes nach der Breakpointadresse mit INT3 (0xcc). Somit haben wir hier schon mal einen WriteProcessMemory. Wenn ein laufender Prozess auf eine solche Anweisung stößt, löst die CPU den Interupt 3 aus, welcher nun vom Debugger abgefangen wird und somit der "Einhakepunkt" erfolgreich war. Dies geht über die IDT.

Ich glaube, dass nun jeder ganz einfach erkennen kann wie man sowas detected.... jips...genau ... man prüft einfach ob an der Ersten Stelle NACH einer Funktionsadresse der Opcode 0xcc steht....

Pseudo-Code: ( nicht lauffähig .... soll der Erklärung dienen )

int fang_mich ()
{
printf("Buh\n");
}

int detect_int3()
{
if ("OPcode bei adresse von fang_mich" +3 ) == 0xcc) {
printf("Hab dich\n");
}

Erläuterung:
Das ist ein selbstprüfender Code..... Sollte jemand im ersten Byte nach
der Funktionsadresse von fang_mich einen INT3 ( 0xcc ) eingebaut haben wird das sofort entdeckt....

Als "Pong" zu diesem "Ping" schreiben einige Debugger unmittelbar nach Auslösen des INT3 den ursprünglichen Opcode wieder zurück. Also somit WriteProcessMemory Nr.2

Ein schönes Beispiel für die Ping-Pong Problematik.... Diese Beispiele kann man noch wesentlich länger fortführen..