begin process at 2012 05 27 15:14:22
  Trouver un code source :
 
dans
 
[ Dernières recherches ]
Accueil > 

Code

 > 

Jeux

 > CRÉATION D'UN TRAINER POUR CHEATER : ECRITURE DANS UN PROCESS.

CRÉATION D'UN TRAINER POUR CHEATER : ECRITURE DANS UN PROCESS.


 Information sur la source

Note :
8 / 10 - par 9 personnes
8,00 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10
Catégorie :Jeux Niveau :Initié Date de création :26/06/2004 Date de mise à jour :26/06/2004 14:10:56 Vu / téléchargé :25 550 / 1 200
Auteur : krust

Ecrire un message privé
Site perso
Ce membre participe au partage de revenus publicitaires
Commentaire sur cette source (20)
Ajouter un commentaire et/ou une note

 Description

Cliquez pour voir la capture en taille normale
Voici mon premier tutorial sur le GameHacking,
Il est très simple mais il introduit les bases.

Le tutorial est scindé en trois parties :
1) Création d'un FakeGame.
2) Désasemblage.
3) Création du trainer.

Bonne lecture ! ;)

Source

  • Trainer et Fake Game créer par Krust
  • ====================================
  • Les trainers sont des programmes qui "Hack" les jeux essentielement afin d'avoir vie infinies, munitions, etc.
  • Voici un exemple de comment créer votre propre Cheat (Cheat = trainer).
  • 1)Création du Fake Game (émulation d'un jeu).
  • ---------------------------------------------
  • NE dite pas, ouais il sert à rien ton jeu car Oui effectivement il sert à rien.
  • Le but est d'arrêter le decende des points de vies, imaginons que les ennemis tirent toutes les 300ms sur notre héro...
  • Donc voilà c'est un simple programme qui affiche les pv qui diminue jusqu'à arrivé à Zero, le moment ou le hero meurt.
  • Si vous ne comprenez pas sa conception, il n'est pas nécéssaire de continuer à lire cette exemple.
  • 2)Désasemblage du Fake Game.
  • ----------------------------
  • Voilà, nous sommes devant un jeu où on ne sait pas gagné, voilà qui est embêtant,...
  • Mais nous sommes assez malin que pour réussir ce jeu.
  • Premièrement on désasemble le programme avec un désasembleur (n'importe lequel fera l'affaire).
  • Prenez par exemple Windasm 9 qui est bien pour débuter.
  • On ouvre l'exe et on attend qu'il génere le code en assembleur.
  • Voilà le listing est affiché (voir Fake_Game-DASM.txt qui est le fichier Désasembler sauver en fichier texte)
  • Le code est maintenant lisible !
  • J'expliquerais les étapes du débugage plus tard, dans un autre tutorial.
  • Mais si on se débrouille on tombe sur ces lignes de code :
  • :00401079 837DFC00 cmp dword ptr [ebp-04], 00000000 // On compare l'address pointer par Ebp+4 à zero (notre int i) -notre while()
  • :0040107D 765C jbe 004010DB // Si i <=0 alors on saute vers 004010DB -
  • :0040107F 8B4DFC mov ecx, dword ptr [ebp-04] // Aussi non, on met dans le regsitre ecx le contenu de notre i
  • :00401082 83E901 sub ecx, 00000001 // On soustrait 1 à ecx
  • :00401085 894DFC mov dword ptr [ebp-04], ecx // On met ecx à la place de la valeur actuelle de i. (i=i-1)
  • Il y a maintenant plusieurs possibilitées pour éviter de perdre des vies (i).
  • LA plus simple est sans doute de NOPer l'instruction "sub ecx,00000001" qui est codé sur 3 Bytes.
  • C-a-d, de mettre l'instruction NUL (NOP, 0x90) à la place.
  • Comme elle est codé sur 1byte, il va faloir en mettre 3 (NOP NOP NOP) :p.
  • le code patché sera alors :
  • :00401079 837DFC00 cmp dword ptr [ebp-04], 00000000 // On compare l'address pointer par Ebp+4 à zero (notre int i)
  • :0040107D 765C jbe 004010DB // Si i <=0 alors on saute vers 004010DB
  • :0040107F 8B4DFC mov ecx, dword ptr [ebp-04] // Aussi non, on met dans le regsitre ecx le contenu de notre i
  • :00401082 90 NOP // On fait rien
  • :00401083 90 NOP // On fait rien
  • :00401084 90 NOP // On fait rien
  • :00401085 894DFC mov dword ptr [ebp-04], ecx // On met ecx à la place de la valeur actuelle de i. (i=i)
  • Et voilà i ne sera plus désacrémenté ! et donc nous aurons toujours le même nombre de vies ;).
  • Avant de faire un trainer, il est préférable de tester notre patch, pour ça on met un BreakPoint sur notre ligne 00401082.
  • On lance le processus dans le debuger et quand il pop, on patch notre code en insérant les 3 NOPs.
  • Victoire ça marche !
  • On va pouvoir passer à la programmation de notre trainer.
  • 3)Création du trainer.
  • ----------------------
  • Les étapes:
  • 1) Trouver notre handle de fenêtre. FindWindow(ClassName,WindowsText)
  • 2) Chercher son process ID par son handle. GetWindowThreadProcessId(Handle,&ProcessID)
  • 3) Ouvire le process OpenProcess(AccessType,NULL,ProcessID)
  • 4) écrire dans la mémoire WriteProcessMemory (ProcessID, AddresToModify, PATCH, NbByteToWrite ,&NbWrittenByte)
  • Regardez dans la source, elle est très bien commentée.
  • 4)The End.
  • ----------
  • Voilà, c'est fini, le trainer a été créer et il marche !
  • Si le trainer fonctionne correctement, vous devriez avoir ceci qui s'affiche :
  • Game Hack V1.0 By Krust
  • -----------------------
  • Appuyez sur une touche pour continuer...
  • [+] Game Found ! :)
  • -->Finding Process ID...
  • [+] Process Id found : 0x000009CC On Thread ID : 5960
  • -->Opening Process...
  • [+] Process successfuly opened!
  • -->Writting Process...
  • [+] Game Patched!
  • -->You should Have Unlimited Live now !
  • Appuyez sur une touche pour continuer...
  • Krust, le 25 juin 2004.
Trainer et Fake Game créer par Krust
====================================

Les trainers sont des programmes qui "Hack" les jeux essentielement afin d'avoir vie infinies, munitions, etc.
Voici un exemple de comment créer votre propre Cheat (Cheat = trainer).

1)Création du Fake Game (émulation d'un jeu).
---------------------------------------------

NE dite pas, ouais il sert à rien ton jeu car Oui effectivement il sert à rien.
Le but est d'arrêter le decende des points de vies, imaginons que les ennemis tirent toutes les 300ms sur notre héro...
Donc voilà c'est un simple programme qui affiche les pv qui diminue jusqu'à arrivé à Zero, le moment ou le hero meurt.
Si vous ne comprenez pas sa conception, il n'est pas nécéssaire de continuer à lire cette exemple.

2)Désasemblage du Fake Game.
----------------------------

Voilà, nous sommes devant un jeu où on ne sait pas gagné, voilà qui est embêtant,...
Mais nous sommes assez malin que pour réussir ce jeu.

Premièrement on désasemble le programme avec un désasembleur (n'importe lequel fera l'affaire).
Prenez par exemple Windasm 9 qui est bien pour débuter.
On ouvre l'exe et on attend qu'il génere le code en assembleur.

Voilà le listing est affiché (voir Fake_Game-DASM.txt qui est le fichier Désasembler sauver en fichier texte)
Le code est maintenant lisible !

J'expliquerais les étapes du débugage plus tard, dans un autre tutorial.

Mais si on se débrouille on tombe sur ces lignes de code :

:00401079 837DFC00                cmp dword ptr [ebp-04], 00000000  	// On compare l'address pointer par Ebp+4 à zero (notre int i)  -notre while()
:0040107D 765C                    jbe 004010DB				// Si i <=0 alors on saute vers 004010DB			-
:0040107F 8B4DFC                  mov ecx, dword ptr [ebp-04]		// Aussi non, on met dans le regsitre ecx le contenu de notre i
:00401082 83E901                  sub ecx, 00000001			// On soustrait 1 à ecx
:00401085 894DFC                  mov dword ptr [ebp-04], ecx		// On met ecx à la place de la valeur actuelle de i. (i=i-1)

Il y a maintenant plusieurs possibilitées pour éviter de perdre des vies (i).
LA plus simple est sans doute de NOPer l'instruction "sub ecx,00000001" qui est codé sur 3 Bytes.
C-a-d, de mettre l'instruction NUL (NOP, 0x90) à la place.
Comme elle est codé sur 1byte, il va faloir en mettre 3 (NOP NOP NOP) :p.
le code patché sera alors :

:00401079 837DFC00                cmp dword ptr [ebp-04], 00000000  	// On compare l'address pointer par Ebp+4 à zero (notre int i)
:0040107D 765C                    jbe 004010DB				// Si i <=0 alors on saute vers 004010DB
:0040107F 8B4DFC                  mov ecx, dword ptr [ebp-04]		// Aussi non, on met dans le regsitre ecx le contenu de notre i
:00401082 90	                  NOP					// On fait rien
:00401083 90	                  NOP					// On fait rien
:00401084 90	                  NOP					// On fait rien
:00401085 894DFC                  mov dword ptr [ebp-04], ecx		// On met ecx à la place de la valeur actuelle de i. (i=i)

Et voilà i ne sera plus désacrémenté ! et donc nous aurons toujours le même nombre de vies ;).
Avant de faire un trainer, il est préférable de tester notre patch, pour ça on met un BreakPoint sur notre ligne 00401082.
On lance le processus dans le debuger et quand il pop, on patch notre code en insérant les 3 NOPs.
Victoire ça marche !

On va pouvoir passer à la programmation de notre trainer.

3)Création du trainer.
----------------------

Les étapes:

1) Trouver notre handle de fenêtre. FindWindow(ClassName,WindowsText)
2) Chercher son process ID par son handle. GetWindowThreadProcessId(Handle,&ProcessID)
3) Ouvire le process OpenProcess(AccessType,NULL,ProcessID)
4) écrire dans la mémoire WriteProcessMemory (ProcessID, AddresToModify, PATCH, NbByteToWrite ,&NbWrittenByte)

Regardez dans la source, elle est très bien commentée.


4)The End.
----------

Voilà, c'est fini, le trainer a été créer et il marche !


Si le trainer fonctionne correctement, vous devriez avoir ceci qui s'affiche :

Game Hack V1.0 By Krust
-----------------------

Appuyez sur une touche pour continuer...

[+] Game Found ! :)
-->Finding Process ID...
[+] Process Id found : 0x000009CC On Thread ID : 5960
-->Opening Process...
[+] Process successfuly opened!
-->Writting Process...
[+] Game Patched!
-->You should Have Unlimited Live now !

Appuyez sur une touche pour continuer...


Krust, le 25 juin 2004.

 Conclusion

Voilà j'esper que ça vous aura plus,
j'ai compilé tout ça avec VC++ 6 sans problème.
je pense que c'est un tutorial de qualité même si il est assez superficiel sur la 2ème étape (debug).

 Fichier Zip

Les Membres Club peuvent télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

Télécharger le zip


 Sources du même auteur

Source avec Zip Source avec une capture INJECTION DE DLL DANS N'IMPORTE QUEL PROCESS
Source avec Zip Source avec une capture LIRE LES INFOS DES HEADERS D'UN FICHIER BITMAP ET TARGA
Source avec Zip Source avec une capture CHEAT POUR PINBALL DE WINDOWS
Toutes les sources de krust

 Sources de la même categorie

Source avec Zip Source avec une capture JEU DES CARTES par eapaceinfo
PROGRAMME DE JEU DE MPT par KerizGarmm
Source avec Zip Source avec une capture JEUX SERPENT par antho974
Source avec Zip Source avec une capture PENDU EN SDL par Damsou91
Source avec Zip STATE MACHINE MODIFICATION MATH BUCKHAM par billybones79
Toutes les sources de la catégorie Jeux

Commentaires et avis

Commentaire de albert0 le 26/06/2004 10:28:39

VIve T-Search  ;)

Commentaire de oBsEC le 26/06/2004 10:48:35

aucune critique particulière, tu montres en gros le principe, je trouve que c'est plutot interessant comme post.

mais quand meme, ce n'est pas selon moi a classer en niveau expert.

Commentaire de MoDDiB le 26/06/2004 13:08:32

Pas au niveau expert?? attends va trouver une variable i dans ce charabia qu'est l'assembleur...Parce que la je vois pas comment tu trouves le i...

Commentaire de jG le 26/06/2004 13:21:43

Bien non ,pas au niveau expert,

La partie de debugging et de recherche est une question d'habitude, mais dans le cas montré ici cela ne releve pas du niveau expert.

Que ferais tu d un prog packe par une rmp (ready made protection) et dont les adresses en memoire changent a chaque chargement, il faudrait trouvé d autre techniques d'approche, de plus, de nombreuses applications surveillent les accès en mémoire a leur segment de code ... Cela releve d un niveau expert.

Dans le cas du game hacking, le tutorial proposé reste a un stade debutant . De plus sur cppfrance, nous ne jugerons que la partie c++, qui ici n'est pas d une grande difficulté.

Je ne remet aucunement en cause l'utilité et l'originalité de cette source.

Commentaire de krust le 26/06/2004 14:00:12

j'aurais bien été plus long dans la partie patchage de code, mais ça relève plus de l'asm et donc n'a rien avoir avec cppfrance.
Mais c'est vrai qui si on évalue que le code c++, il n'est pas d'un très haut niveau, mais son utilisation demande un certain savoir faire.

Aussi non merci de vos commentaires, je vais sans doute poster d'autres trainers, mais plustot sur le réseau asm alors, où j'expliquerais mieux les étapes du debuging.

Commentaire de krust le 26/06/2004 14:12:23

Donc voilà, à votre demande j'ai changé le niveau à initié ;)

Commentaire de Gerald le 27/06/2004 13:36:13

Oui  c'est vrai que ici on a a  faire à un tout petit jeu dont on connai la conception donc c un peu plus limite à faire sur des jeu du genre starcraft; on a tout de suite besoin d'un bon debugger...
par contre la partie d'insertion de code en mémoire est toujours interessante...sauf pour les programmes packés :-(

Commentaire de krust le 28/06/2004 16:06:45

les programmes packés (UPX, ASPACK, ...) sont des executables compressés par un packer qui y ajoute une routine de décompression.
L'executable n'est donc pas visible dans un désasembleur mais il l'est bien quand il est lancé, car la routine le décompresse et puis lui donne la main, donc en mémoire, on la l'executable telle qu'il a été compilé.
Il y a ce qu'on appel des Dumper, qui charge les processus en mémoire (donc unpacké), l'executable peut alors être lu dans le d"sasembleur ! Mais, il ne peut pas être lancé (sauf si le packer n'inverse pas des segments etc) Ce genre de dumpers s'appellent les dumpers Generiques, car il permettent juste de rendre l'executable lisible mais le fichier dumper ne peut pas être executer (errers...)
Ils y a d'autres unpackers plus performant qui eux, remettent les segments à leur place. Les exe unpacké par cette méthode peuvent normalement être éxécutés!
Après, il reste l'extraction manuel, mais il est beaucoup plus lent, sont avantage c'est qu'on peut enlever les codes qui vérifie la présence du pack, ce que ne fait pas les unpackers automatique ;)

Donc un fichier packé, est tout a fait lisible en mémoire aussi non, il ne pourrait pas être éxécuté ;)

Commentaire de Gerald le 28/06/2004 16:44:43

Oui, bien heureusement! :) ou alors on est sous un nouveau type de machine!
Le problème est que si mes souvenirs sont bons un packer comme aspack nécessite un changement des droits de la zone de mémoire du prog(voir VirtualProtect) pour l'écriture. Quand à UPX, il se décompacte très facilement avec un debugger(OllyDebug)

Commentaire de jG le 28/06/2004 18:45:31

Gerald a raison, le programme a bo etre decrypte en memoire, les adresses ne sont jamais les memes. Le packer decompresse le programmes dans des adresses aleatoires, on ne peut donc pas prevoir a l avance ou l'on doit ecrire (c'est le but des packer moderne, sinon un simple loader suffirait). Il faut pour cela soit unpacker soit faire du hard patching...
Mais nous sommes ici sur un site de programmation pas de cr**ing !!

Commentaire de krust le 28/06/2004 18:51:18

Je ne te suis pas bien, toutes les adresses sont alloué dynamiquement (DMA), c'est donc le code que l'on patch qui lui ne peut pas changer aussi non tout les jump sont décallés et le prog perd completement les pédales,...
Aussi non, les jeux sont rarement packé (j'ai jamais vu un jeu packé) car les packs ralentissent leur execution.

Commentaire de AlexMAN le 13/07/2004 21:00:18

Kelk chose que jne comprends pas : les adresses de l'exe non executé et executé sont totalement differente, non ? RVA (Relative Virtual Address) si jne me trompe pas, donc je ne vois pas comment tu peux recuperer l'adresse ds l'exe desassemblé et ensuite effectuer les changements a l'execution...Si tu pouvais m'eclairer !

Merci ++

Alhexman

Commentaire de AlexMAN le 13/07/2004 21:04:15

et puis pourquoi effectuer les changements a l'execution ? Ces modifications ne seront pas effectives, donc a chak chargement du prog, tu devras lancer le trainer...Donc pourquoi ne pas simplement faire un petit patch ?

Commentaire de krust le 14/07/2004 13:57:29

Lors de l'éxecution d'un programme, l'os se charge de le mettre en mémoire, et donc de lui alloué une place en mémoire.
Depuis les pc multitaches, une séparation de la mémoire a été requise pour éviter que les processus se marche dessu.
De plus sur les processeur 16bits, on ne pouvait que stocké 1mo d'address, pour remédier à ces problèmes on a utilisé les segments.
Et les segment sont divisé en Offset.
Il suffit alors pour trouvé l'address linéaire de faire Segment  + Offset
Par exemple :
08f10x0100 (Segment : 08f10 || offset : 0100)
donnera l'address linéaire : 09010h.
Donc , oui les jmp ne point pas le bonne address linéaire mais elles sont corrigé par le décalage de segment.
Car prend n'importe quelle série de nombres et ajoute x à tout ces nombres, leur décalage restera identique.

A puis, les hacks patch le jeu en mémoire car on a pas forcément envie de cheater toute sa vie ;)
Et donc si tu patch l'exe sur le disque, il sera hacké à tout les lancements et donc impossible de retrouver un jeu normal.

Voilà AlexMan ;)

Commentaire de AlexMAN le 14/07/2004 14:07:35

Ok merci krust ;)

Commentaire de Mat_72005 le 12/07/2005 16:19:31

c'est beaucoup plus rapide avec fscanf !!

Commentaire de NeoUmbrella le 23/10/2005 21:06:57

10/10 Merci à toi.

Commentaire de lapin3k le 20/03/2007 13:12:38

Ton code est bien mais tu quand tu ouvres un Handle, tu devrais le fermer par la suite sinon ça laisse des fuites de mémoire importantes.

Par exemple, avant d'exécuter WriteProcessMemory je te conseillerais avant d'exécuter SuspendThread, c'est plus sur et après avoir exécuter WriteProcessMemory, tu devrais peut-être y rajouter un FlushInstructionCache pour plus de sûreté.

Termine ensuite avec CloseHandle.

Commentaire de vazdah le 05/09/2009 18:22:04

je suis membre privé e je peux pas télécharger les fichers comment je fait?

Commentaire de jihednond le 13/09/2009 19:01:09

wow c'est génial comme tutoriel sa ressemble au cracking merci et bonne continuation  10/10      

 Ajouter un commentaire

Nos sponsors


Sondage...

CalendriCode

Mai 2012
LMMJVSD
 123456
78910111213
14151617181920
21222324252627
28293031   

Consulter la suite du CalendriCode

A découvrir
 
Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils.
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés

Google Coop CodeS-SourceS Google Coop CodeS-SourceS
Temps d'éxécution de la page : 0,920 sec (4)

Nous contacter | Annoncer sur CodeS-SourceS | Mentions légales
Outils Convertisseur VB/C# Snippets et scripts Outils en ligne La ToolBox
Communauté Programmation Photographie Technologie Newsgroups Emploi Forum Blogs
Guide d'achat Téléphonie mobile Image et son Informatique Bureautique Jeux vidéo
Logiciels Internet & Réseau Développement Market Android Jeux & Loisirs Graphisme Multimédia Sécurité Pilotes
Loisirs Cartes virtuelles Vidéos droles Jeux en ligne Géoguide AndroLib (Android Market)