[WIN32]OpenProcess detecteren.

[H!GHGuY]

Ik zou graag het volgende doen:

1) EnumProcesses
2) OpenProcess
3) GetProcessImageFileName
controle op het juiste proces
4) EnumProcessModules
controle of ongewenste modules aanwezig zijn

Nu heb ik 3 vragen:
- als code geinjecteerd werd, ziet men deze dan met de EnumProcessModules ?
(alsook hooks)
(mijn gok: ja aangezien hiervoor een LoadLibrary call nodig is, hoewel ik ergens iets tegenkwam
dat er een methode was om code te injecteren die niet uit een DLL kwam)
- kan een proces zien of ik deze operaties uitvoer ? Vooral de EnumProcessModules
en OpenProcess functies.
(mijn gok: nee)

Maar is dit correct?

[H!GHGuY]

bumpje

[TheBlasphemer]

Nee, niet alle geinjecteerde code kun je zien met GetProcessImageFileName. Je kan wel degelijk code injecteren zonder LoadLibrary, het is alleen een stuk ingewikkelder.
En ja, een proces kan makkelijk zien wat voor operaties te uitvoert. Dr zijn verschillende methoden om simpelweg een hook op die APIs te zetten Het zou zelfs zo kunnen zijn dat hij gewoon EnumProcessModules hooked en zorgt dat zn eigen module niet wordt meegegeven...

[.oisyn]

TheBlasphemer schreef op donderdag 18 mei 2006 @ 08:10:
Het zou zelfs zo kunnen zijn dat hij gewoon EnumProcessModules hooked en zorgt dat zn eigen module niet wordt meegegeven...

Dat is wel te detecteren, als je zorgt dat je een eigen hook op die functie zet vóór die andere app dat kan doen, dan krijg je gewoon de onaangepaste lijst, en als hij jouw hook replaced weet je dat ook meteen (een call naar EnumProcessModules gaat dan immers niet meer via jouw functie).

Maar als het echt van belang is kun je denk ik beter een eigen dll loader maken die z'n calls niet doet via de import address table.

[ Voor 12% gewijzigd door .oisyn op 18-05-2006 10:52 ]

[H!GHGuY]

Wel het is vooral als idee voor een anti-cheat scan.

neem nou bvb HL/CS. Als een cheat daarin code injecteert dan zou het wel handig zijn dat te kunnen detecteren zonder dat de anti-cheat als cheat aanzien wordt.

Maar ik bedenk net: als het programma jou anti-cheat controle als cheat detecteert dan moet ie de cheat zeker detecteren...

misschien moet ik toch nog maar wat meer lezen over de onderwerpen en de werking van cheats. Als ze namelijk de UDP pakketten zouden wijzigen dan ben ik er ook helemaal nix mee.

De MSDN is echter redelijk onduidelijk over hooks imo.
daar gaat het vooral over keyboard en mouse hooks, en weinig over het vervangen van functies door eigen brouwsels. Maar zoals je zegt: blijkbaar kunnen de API functies ook vervangen worden...

[TheBlasphemer]

.oisyn schreef op donderdag 18 mei 2006 @ 10:50:
[...]

Dat is wel te detecteren, als je zorgt dat je een eigen hook op die functie zet vóór die andere app dat kan doen, dan krijg je gewoon de onaangepaste lijst, en als hij jouw hook replaced weet je dat ook meteen (een call naar EnumProcessModules gaat dan immers niet meer via jouw functie).

De meeste goed geschreven hooks redirecten gewoon naar de functie die er eerst stond. dus dan wordt wel gewoon je eigen functie gecalled...

Maar als het echt van belang is kun je denk ik beter een eigen dll loader maken die z'n calls niet doet via de import address table.

GetProcAddress hooken en je bent binnen

Anyway, je zou evt wel een hook op EnumProcessModules kunnen detecteren, op een soortgelijke manier als oisyn zei
Ipv hem zelf te hooken, sla je gewoon voordat je programma laad op wat er in de import table zit. Als je dan EnumProcessModules aanroept check je gewoon eerst even of die waarde nog hetzelfde is. Alsie veranderd is, dan heeft iemand aan je import-table gesleuteld

Evt zou je dit nog een stapje verder kunnen doen, wat dacht je bijvoorbeeld van gewoon een kleine CRC-achtige check op je import-table zetten? en dan elke keer voor je belangrijke functies aanroept die CRC opnieuw berekenen en checken met oude waarde
Dit beschermt echter alleen tegen import-table hooks (en dus niet tegen bijv. gewoon een JMP over de functie heenschrijven)

Maarja, eigenlijk is alles wel te kraken... Als een cracker gemotiveerd genoeg is komt ie er vanzelf wel door...

EDIT:

HIGHGuY schreef op donderdag 18 mei 2006 @ 15:10:
De MSDN is echter redelijk onduidelijk over hooks imo.
daar gaat het vooral over keyboard en mouse hooks, en weinig over het vervangen van functies door eigen brouwsels. Maar zoals je zegt: blijkbaar kunnen de API functies ook vervangen worden...

Komt omdat dit ook niet echt iets met de Win32 API heeft te maken. Het is een kwestie van weten hoe windows intern met executables omgaat, en daarmee lekker gaan prutsen

[ Voor 15% gewijzigd door TheBlasphemer op 19-05-2006 01:26 ]

[H!GHGuY]

ik wil niet mijn eigen software gaan beschermen..

ik wil alleen zien of de ene software in de andere heeft ingebroken... en daarbij wil ik zelf niet aanzien worden als inbreker.

Ik denk echter dat GetProcessModules en OpenProcess methodes zijn die niet als inbraak pogingen aanzien kunnen worden aangezien de TaskManager of bvb sisoft sandra dit ook gebruiken om opsommingen te maken...

Verder ga ik me nog verdiepen in hooken etc en evt opsporingsmethodes...

[.oisyn]

TheBlasphemer schreef op vrijdag 19 mei 2006 @ 01:24:
[...]

De meeste goed geschreven hooks redirecten gewoon naar de functie die er eerst stond. dus dan wordt wel gewoon je eigen functie gecalled...

[...]

GetProcAddress hooken en je bent binnen

Euh, het idee van een eigen dll loader is dat je niet gebruik maakt van LoadLibrary en GetProcAddress, maar dat je de dll file opent en die naar mem kopiëert, de relocations resolved en dan vervolgens de entry point aanroept