VAC 3 / Battleeye

[The Steven]

Hi,

hat jemand eine Idee, oder vlt. etwas zum nachlesen,
was die genaue Funktion von VAC 3 & Battleeye ist?


Vac 3 + Vac 2 arbeiten (soweit ich das verstanden habe und weiß),
per Updates und muss somit immer wieder neu reversed werden.

Korrekt? Falls nicht, wäre ich schon hier dankbar für eine Korrektur.

Battleeye hingegen arbeitet (soweit ich das verstanden habe und weiß),
per Signaturencheck und arbeitet alle geloggten Summen ab,
um dann innerhalb von Minuten/Stunden Cheats und co. zu erkennen.

Nun die Frage: Bei Vac wird reversed um zu sehen was sich verändert hat,
was macht man bei Battleeye, dort weiß man ja nicht wo nun das Problem liegt, oder?
Und sollte es dort um Signaturen gehen, wie geht man dann weiter vor?

Wäre interessant, wenn ich zum Thema Battleeye Signaturen etwas dazu lernen könnte.

Danke!

[snow]

Ich kenne mich mit VAC nicht aus, aber ich kann mir nur schwer vorstellen, dass die für jedes Miniupdate eine neue Struktur schreiben. Den Großteil des Codes wirst du an anderen Adressen als in einer vorherigen Version finden, dafür reichen aber Patternscans. Dass sich beim Umstieg von VAC2 auf VAC3 einiges geändert haben dürfte, sollte klar sein, von VAC 3.1.7.4 auf 3.1.7.5 wird sich normal nicht viel ändern.

Wenn BattleEye nach Signaturen sucht, wird es die irgendwo mit vorhandenen vergleichen und da kannst du angreifen - bestehende Signatur verändern, gescannte Signatur verändern, einfach das Ergebnis verändern, da gibt es viele Möglichkeiten. Ich würde mal sagen, dass du die Funktion, die Hashes erstellt / nach Signaturen sucht, relativ schnell findest, wenn du entsprechende WinAPI Funktionen beobachtest, BattleEye kann ja nur über das Betriebssystem mit anderen Programmen kommunizieren, also wirst du da irgendwo fündig.

[burncode]

VAC 3 arbeitet eigenständig und wird gestreamed.
VAC 2 wird aber immer mitgeladen.
VAC 3 ist nicht nur ein Module, sondern mehrere Module.
Es ist nicht immer das Gleiche, was gestreamed wird.

Regards.

[The Steven]

Danke soweit!

Würde mich aufjedenfall auf weitere Antworten freuen...

[Omdi]

BattleEye arbeitet afaik so, dass bestimmte Script (die vom Server gesendet werden) geblockt werden. Außerdem gibt es dann noch die ganzen 0815 Detections, sowas wie Cheat Engine, WPE, OllyDBG usw. Soweit ich das beurteilen kann, werden alle Informationen darüber in einem sehr großen Packet gesendet. Es handlet sich bei dem Packet um eine Art Bericht von der momentanen Lage. Durch die enorme größe und der vielzahl von Informationen, die in dem Packet stecken, ist es gar nicht mal so leicht das Packet zu verstehen :-)

[The Steven]

dass bestimmte Script (die vom Server gesendet werden) geblockt werden.

Was genau versteht man unter bestimmten Scripten, welche vom Server gesendet werden?

Durch die enorme größe und der vielzahl von Informationen, die in dem Packet stecken, ist es gar nicht mal so leicht das Packet zu verstehen :-)

Ok, heißt dass also, ein bereits überprüftes und analysiertes Packet,
welches vom Battleeye Client aufgenommen wurde,
kann so einfach nicht wieder verändert werden ?

Dann interessiert mich aber dennoch, in welche Richtung man dort geht um
diesen Weg von Battleeye zu umgehen.
Möglich scheint es ja zu sein, auch wenn es nicht einfach ist, würde mich
dennoch interessieren mit was man sich dann beschäftigt.

CheatEngine und co. sind vlt. etwas extremere Beispiele,
aber im Prinzip sollte es ja mit vorhandenem Quellcode möglich sein,
eine zukünftige Analyse zu verzögern oder gar über längeren Zeitraum zu verhindern, richtig?

Danke soweit!

[Omdi]

Originally Posted by The Steven

Was genau versteht man unter bestimmten Scripten, welche vom Server gesendet werden?

Ich weiß es selber genau nicht =D
In Arma 2 konnte man halt bestimmte Scripte ausführen um sich Fahrzeuge etc. zu cheaten.

Ok, heißt dass also, ein bereits überprüftes und analysiertes Packet,
welches vom Battleeye Client aufgenommen wurde,
kann so einfach nicht wieder verändert werden ?

Das Packet nimmt der Client nicht auf, er versendet es an den Server.
Der entscheidet dann, ob irgendwas merkwürdig ist und gibt ggf. einen Kick. Verändern kann man das Packet schon, es ist nur kompliziert aufgebaut

Dann interessiert mich aber dennoch, in welche Richtung man dort geht um
diesen Weg von Battleeye zu umgehen.
Möglich scheint es ja zu sein, auch wenn es nicht einfach ist, würde mich
dennoch interessieren mit was man sich dann beschäftigt.

CheatEngine und co. sind vlt. etwas extremere Beispiele,
aber im Prinzip sollte es ja mit vorhandenem Quellcode möglich sein,
eine zukünftige Analyse zu verzögern oder gar über längeren Zeitraum zu verhindern, richtig?

Danke soweit!

Es gibt tatsächlich paar unterschiedliche Wege wie man das anstellen kann. Man kann versuchen BattleEye komplett zu emulieren, man spielt sozusagen einen funktionstüchtigen BattleEye Client nach. Oder man verändert direkt was im BattleEye Client durch Memory Modifikationen. Den letzten Teil mit dem Quellcode habe ich jetzt nicht so ganz verstanden, was meinst du jetzt genau ?

[The Steven]

Den letzten Teil mit dem Quellcode habe ich jetzt nicht so ganz verstanden, was meinst du jetzt genau ?

Angenommen man nutzt keinen Script,
sondern geht per WriteProcessMemory oder Dll Injection vor,
das ganze wird nun durch Battleeye erkannt und das Tool ist somit nicht
mehr sicher.

Nun muss es ja scheinbar eine Möglichkeit geben,
die geprüfte und aufgenommene Signatur (So macht es Battleeye ja scheinbar),
zu verändern oder am Quellcode zu basteln und genau da setzt halt meine Frage ein, wo fängt man an, um zukünftig wieder ein sicheres und unerkanntes Tool zu haben ?

Die Logik des ganzen interessiert mich, nur verstehen tu ich das System von Battleeye noch nicht ganz, da Battleeye wie schon gesagt ja wohl mit Signaturen arbeitet und man somit (wie ich das sehe) nicht viel daran ändern kann.

[MrSm!th]

Deinen Ansatz halte ich für Quatsch. Wenn das Tool schon einmal erkannt wurde, kannst du natürlich (zb durch polymorphen Code) verhindern, dass Signaturscans in Zukunft anschlagen. Aber das ändert doch nichts an der Ursache, warum dein Tool erkannt und auf die Blacklist gesetzt wurde. Da musst du ansetzen.

[The Steven]

Originally Posted by MrSm!th

... dein Tool erkannt und auf die Blacklist gesetzt wurde. Da musst du ansetzen.

Hi,

okay gut, wenn man also direkt dort ansetzen muss,
kommen wir ja trotzdem auf meine ursprüngliche Frage zurück,
wenn es kein direktes Update wie bei VAC gibt,
woher weiß man dann was genau verändert werden muss?

[MrSm!th]

Reversen. Schau halt, wie VAC auf den Speicher zugreift und Ungereimtheiten erkennt.

[The Steven]

Okay, ich hab mich mal ein wenig weiter durchs net schlau gemacht,
ich werde mich erstmal etwas intensiver mit ASM und Reversing beschäftigen,
das macht wohl am meisten Sinn.

Danke für die Antworten, kann gern geclosed werden.

[burncode]

Originally Posted by The Steven

Hi,

okay gut, wenn man also direkt dort ansetzen muss,
kommen wir ja trotzdem auf meine ursprüngliche Frage zurück,
wenn es kein direktes Update wie bei VAC gibt,
woher weiß man dann was genau verändert werden muss?

Du siehst die Updates für VAC nicht.
Man sieht immer nur die Steam Updates, die nichts mit VAC zutun haben.
Updates für VAC werden "verdeckt" gemacht.

Regards.

[Dr. Coxxy]

kannst die größen der gestreamten module angucken, sind 3-4 stück die alle immer ungefähr die gleiche größe haben - wenn sich da was größeres ändert kannste von einem update ausgehen.

[Brendan Jordan]

Als kleinen Tipp an dich: Versuch dich nicht an Battleye, ich denke du willst Arma Bypasse schreiben und als Anfänger wirfst du da nur dein Geld raus. Eine flasche Sache und dein Key ist futsch. Battleye arbeitet afaik mit:

-Checksum Scans (BEClient.dll and Arma2oa.exe)
-Internal Pattern Scans (Dll hacks)
-External Pattern Scans (Cheat Engine, WPE Pro, div. andere Sniffer und Debugger halt)
-Script Scans
-Heartbeat
etc.

Bin nicht soooo der Experte auf diesem Gebiet aber sollte im Großen und Ganzen richtig sein.