[Anticheat] Hoe te detecteren 'hook'?

[Verwijderd]

Ik heb een vervelende bug ondekt in 1 van onze anticheat programma's, is dat een bepaalde cheat niet gelogged wordt. Zodra deze cheat gewoon actief is in het geheugen, wordt deze ook niet eens geregistreerd als 'running process', heel gek allemaal, want de cheat die ik heb bevat geen loader die zichzelf onzichtbaar maakt.

Mijn vraag is dus eigenlijk, hoe herken ik welk / wat punt deze hook 'hookt' in het huidige spel, en beter zelfs, hoe blokkeer ik 'm ? Het gaat om de Uscript code / methode.

Er wordt gerept dat ik met tools zoals PE-explorer moet achterhalen welke class deze precies 'hookt' en daarop een anti voor schrijven. Vervelende is is dat ik wel kan decompilen en alles, maar dan nog niet weet blijkbaar hoe deze wallhack precies te werk gaat.

Er wordt ook wel gezegd dat deze wallhack een verbinding met de server maakt op een bepaalde poort om zo de overige players 'locatie' te achterhalen.

Het gaat hier om het spel Unreal tournament Demo, en dus niet de full version, waar ik anders zo een werkende anticheat vandaan had kunnen halen (basicly is de engine van de demo heel erg beperkt in native).

Heeft iemand een idee hoe ik dit achterhaal en kan tegenhouden?

Tools om te kijken wat een programma precies doet is ook welkom trouwens.

[ Voor 3% gewijzigd door Verwijderd op 26-07-2007 19:40 ]

[_js_]

Maakt de cheat gebruik van dll injection?

Zonder glazen bol valt er verder heel weinig over te zeggen, misschien moet je toch maar reverse engineeren.

[Verwijderd]

Ida Pro

[Verwijderd]

_js_ schreef op donderdag 26 juli 2007 @ 21:36:
Maakt de cheat gebruik van dll injection?

Zonder glazen bol valt er verder heel weinig over te zeggen, misschien moet je toch maar reverse engineeren.

Nou ja het gewoon een Loader met daarin wat uscript. Als je 'm opstart vraagt hij ook eerst of je het desbetreffende game wilt starten, en vervolgens 'injecteert' de cheat het spel met een menu en al die troep.

Ik heb Ida geprobeerd, ik krijg een leuke stamboom, maar dan weet ik nog niet wat ik nu precies moet doen Moet ik zoeken naar een header? Moet ik zoeken naar een functie die gehooked wordt?

[ Voor 17% gewijzigd door Verwijderd op 26-07-2007 22:12 ]

[Verwijderd]

Je kunt in Ida gewoon debuggen, dus gewoon het programma doorlopen, waar mogelijk laat ie een tree zien zodat je direct de flow kunt zien.

Hij probeert ook zoveel mogelijk symbols te resolven waardoor je vrij leesbare code krijgt.

Loop even door het programma heen en je hebt in no-time door hoe het werkt.

[Verwijderd]

Ja oke, ik snap de werking van de cheat nu ook een beetje, maar als ik een anti zou schrijven, wat zouden de strings, headers of wat dan ook moeten zijn om het tegen te houden (effectief) ?

Ik zoek al een end weg naar simpele voorbeelden in Uscript over hoe je iets blocked, maar het meeste is obfuscated wat moeilijk terug te draaien valt. Hulp daarintegen is ook maar bar weinig te vinden, niet iedereen wil je opweg helpen.

[Soultaker]

Hoe detecteer je normaal cheats dan? Lijkt me dat je normaal gesproken draaiende processen identificeert; waarom is een geïnfecteerde UT binary anders dan een losstaand proces?

[Verwijderd]

Soultaker schreef op donderdag 26 juli 2007 @ 22:39:
Hoe detecteer je normaal cheats dan? Lijkt me dat je normaal gesproken draaiende processen identificeert; waarom is een geïnfecteerde UT binary anders dan een losstaand proces?

De enige Native anti die er draait is eigenlijk heel stom. Het identificeert niets meer dan draaiende processes en gebruikte modules zoals bijv Dsound.dll (directsound). Op 1 of andere vage manier logt deze anticheat dan ook niet dat iemand gebruik maakt van deze cheat, terwijl die wel gewoon in de process-list staat totdat je UT afsluit.

Ik was dus opzoek geweest en heb iets gevonden:

if (zzMyConsole.GetPropertyText("Elf") != "")
return 14; // ("(ELFBot)");

Eigenlijk heel eenvoudig dat deze anti dus ook zoekt naar termen zoals 'Elf" waarop het om een Elfbot gaat (clan elf was een dikke cheat clan overigens, maar dat even terzijde). Het gaat mij er dus om hoe vindt ik deze string in deze cheat nu ?

Het lijkt me als de game geinjecteerd wordt deze ook vast wel ergens te vinden is (deze strings). Wat ik me trouwens ook afvraag waarom ik er met Ida niet uitkom, is de broncode achterhalen, want uiteindelijk is er toch een stukje uscript nodig om de wallhack / radar te activeren.

[Verwijderd]

Met Ida moet je dat inderdaad gemakkelijk op kunnen zoeken, op een gegeven moment moet het toch in het geheugen zitten, al wordt het wellicht wel met een encryptie opgeslagen in de binary zelf.

Kun je met Ida zien wanneer de injectie plaatsvind, dan moet je ook gemakkelijk de geheugenlocatie kunnen zien waar het script staat en deze dan uitlezen met Ida. (Doet ie vaak al handig zelf)

[Verwijderd]

Het rare is , en ik ook nu uitgevogeld heb waarom het niet 'opgepakt' wordt door de huidige anti, is zodra je de bot / radar en dergelijk laadt, de cheat zichzelf ook buiten UT om terminate. Ida sluit dan ook al die kleine venstertjes, maar kon niet echt achterhalen of het ook ergens opgeslagen was. Wat je zegt over dat het op ten duur ergens staan moet, klopt dan ook wel. Maar ik kan nog niet uitvogelen waar. Onthou, dat dit puur gebaseerd is op Uscript, en dingen zoals Geheugen-adressen controleren Native is en ik daar geen broncode van heb (die ik wel overigens krijg binnenkort).

Dus vraag ik me af of mijn methode van een string opzoeken wel daadwerkelijk wil gaan werken.

[Verwijderd]

Lijkt me niet zo'n probleem toch?

Gewoon op het moment dat je een call tegenkomt die te ver gaat voor je een breakpoint setten, dan laten runnen tot het breakpoint en in de call stappen. Vervolgens herhalen totdat je gevonden hebt wat je zocht.

[Verwijderd]

Nou ja. Even een update.

Ik heb de broncode ontvangen van de enige stukje native anticheat die er is. Als ik de broncode bekijk dan is de code eigenlijk heel simpel opgebouwd. Mijn idee om nog iets verder te doen in uscript vervalt dan ook bijna, omdat ik bijna klaar ben met een mod dat 'tweaking' tegen moet gaan, en met success.

Mijn volgende stap is dan ook extra functionaliteit implementeren in het huidige van ophalen van de actieve processen. Ik dacht aan de volgende functies zoals Filesize, Locatie van het actieve bestand, en eventueel een filecheck op bekende folders zoals in \windows\prefetch.

Waar moet ik hier nu precies op letten? De omgeving van de gebruikers bestaat uit windows 98 t/m Windows XP, dus ik zou iets moeten samenvouwen dat op beide platformen werkt. Ik wil niet al te veel ingaan op details van de huidige, maar er zijn wat bugs die ik nog even liever niet vertel maar er wel wil uitwerken. Ik heb de hulp van een andere vrij ervaren coder, dus ik heb gelukkig niet alle taken op me. Het andere belangrijke aspect is het beschermen van de code. Er zijn voldoende tools om een .dll te beveiligen, maar er zijn ook voldoende tools om de zooi te reverse-engineeren. Heeft iemand een goede tip mbt beveiliging van ?

Tevens zal ik de komende tijd veel moeten investeren in de werking van het progsel zelf. Het moeilijkste schijnt te zijn het combineren van Uscript in de .dll, omdat er bepaalde headers nodig zijn. Laat ik die nu ook toevallig hebben.

Laatste vraag is, hoe ziet bijv een goede C++ eruit over hoe je processes ophaalt bij een gebruiker inclusief de locatie ervan? Hoe voer ik een filecheck bij een client uit ?

[Sponge]

Hey lism, beetje off-topic, maar als je eens zin hebt moet je eens in #ut komen van tweakers IRC . Creativiteit is ons tweede naam . We hebben zelfs bijna eens een compleet gesharede anti cheat systeem opgezet, helaas kwam het er niet meer van omdat het net na de UT 'peak' was (2005). De interesse was er niet meer, het was namelijk al grotendeels functioneel, zelfs inclusief een echte 'nickserv'

[ Voor 16% gewijzigd door Sponge op 28-07-2007 10:48 ]

[Radiant]

Zou je niet gewoon beter het geheugen kunnen gaan scannen naar bekende locaties die gewijzigd worden door cheat tools?
Er zijn meer manieren om code te injecteren dan een DLL'tje te vervangen. Zet je cheat met een loadertje (CreateRemoteThread + LoadLibrary) op een USB stick, run hem en trek de stick eruit en je kan hem al niet meer vinden..
Je komt al ver als je bijvoorbeeld adressen van OpenGL/DirectX functies gaat beveiligen (en de functies zelf natuurlijk ook), aangezien die vaak overschreven worden met een functie in de cheat zelf, om zo aan spelinfo te komen, of om wat extra parameters zoals transparantie voor muren (wallhack) mee te geven.

Info over hoe je processen ophaalt kan je op MSDN vinden.

[Verwijderd]

Zou je niet gewoon beter het geheugen kunnen gaan scannen naar bekende locaties die gewijzigd worden door cheat tools?

Hiervoor heb je de desbetreffende cheat voor nodig, om uberhaubt iets te beginnen. Als je namelijk geen voorbeeld hebt hoe wil je het dan tegengaan? Gelukkig ontvang ik zo nu en dan ook een cheat, waarvan ik de headers eruit kan slopen en blacklisten.

Voor je tweede heb je headers nodig van het spel zelf, die normaal heel moeilijk te verkrijgen zijn, maar ik ze gelukkig wel heb Wat je zegt is wel een goed idee, maar dat is eigenlijk van latere zorg. Op het moment zijn we ook aan het uitvogelen hoe we uscript in een DLL verwerkt krijgen, en dat nog eens te laten werken ook. Dus in feite met een native anticheat het spel zelf weer 'hooken'

En je laatste daar heb ik ondertussen al genoeg leesvoor voor gevonden: http://msdn2.microsoft.com/en-us/library/aa915058.aspx

Op het moment wordt er dus nu ook aan gewerkt om het aantal processes dat opgehaald wordt, gedetailleerd te weergeven, locatie, filesize, eventueel hash op de file erbij, het terugsturen van de gegevens wordt wel weer een probleem, dat gaat zo niet 1-2-3. Mogelijk moet er iets gebeuren icm het bestaande logfile, en de anti de info daaruit laten halen.

Tevens heb ik ook een zeer gewilde tool om uscript te obfuscaten. Eigenlijk vereist het dat je al je classes, properties en values met zz / ss / xx tagged, wat een behoorlijk rot-werk kan zijn, de vraag is of het dan nog wel wil doen na obfuscate.