Re: Cheater_Lib
Publié : sam. 20/févr./2010 15:39
je viens de mettre a l'epreuve ma fonction
cheater_map("prg_cible.exe","MAP_PROCESS")
en utilisant mon prg_cible , et en comparant aux résultats de memHack
j'obtiens bien les segments du process , et plus particulièrement le segment ou se trouve ma variable de test.....
j'ai pu ensuite utiliser la meme adresse de variable (vérifié sur memHack) pour lire ou ecrire une nouvelle valeurs ....
il me semble donc que cette fonction est bonne ..
par contre je vais faire une nouvelle version de la Librairie
car actuellement la fonction cheater_map("prg_cible.exe","MAP_PROCESS")
renvoie le champ d'adresse qui par de l'entry point ( au alentour de $1000 )
alors que finalement les segments qui nous intéressent commence généralement a $400000 , ça va réduire la taille du champ mémoire pour les recherches
je prends exemple sur les prg de scan qui existent et qui commencent tous leur scan a partir de $400000 !
effectivement un prg contient plusieurs sections, je suppose que $400000 doit correspondre a l'adresse de base ou se trouve les variables....
finalement ma fonction ne sert qu'a connaitre l'adresse d'un segment mais surtout sa taille , mais mon petit doigt me dit que si on scan directement avec une boucle du genre :
ça marche tres bien !! (j'ai vérifié !! )
moralité ma fonction cheater_map("prg_cible.exe","MAP_PROCESS")
ne sert pas a grand chose , si ce n'est que comme elle renvoie les segments avec leur tailles on est sur de scanner les segments de notre process.... mais je pense que meme si on scan entre les segments ( dans les trous)
ça n'est pas grave , puisque le but du scan consiste a vérifier plusieurs fois
pour constater un changement de valeurs, qui nous indiquera a coup sur l'adresse qui nous intéresse !!
je pense que les memhack et compagnies utilisent ce systeme, qui est le seul a etre
rapide ....(un peu brutal mais sans danger, on ne fait que lire...)
le code ci dessus renvoi les adresses contenant la valeur 125
il suffirai de le relancer en comparant avec la valeur 124 , ( puisque mon prg_cible diminue cette variable )
et de regarder si l'une des adresses que nous avions, est toujours présente dans la liste, ça nous indiquerai tout de suite a qu'elle adresse correspond notre variable
( seul ceux qui on pratiqué le Hack peuvent me comprendre a ce stade
)
tout ça pour dire que finalement les fonctions de la lib telle qu'elle existent depuis le debut
avec un code comme celui que j'ai mis ci dessus
cheater_map("prg_cible.exe","MAP_PROCESS")
en utilisant mon prg_cible , et en comparant aux résultats de memHack
j'obtiens bien les segments du process , et plus particulièrement le segment ou se trouve ma variable de test.....
j'ai pu ensuite utiliser la meme adresse de variable (vérifié sur memHack) pour lire ou ecrire une nouvelle valeurs ....
il me semble donc que cette fonction est bonne ..
par contre je vais faire une nouvelle version de la Librairie
car actuellement la fonction cheater_map("prg_cible.exe","MAP_PROCESS")
renvoie le champ d'adresse qui par de l'entry point ( au alentour de $1000 )
alors que finalement les segments qui nous intéressent commence généralement a $400000 , ça va réduire la taille du champ mémoire pour les recherches
je prends exemple sur les prg de scan qui existent et qui commencent tous leur scan a partir de $400000 !
effectivement un prg contient plusieurs sections, je suppose que $400000 doit correspondre a l'adresse de base ou se trouve les variables....
finalement ma fonction ne sert qu'a connaitre l'adresse d'un segment mais surtout sa taille , mais mon petit doigt me dit que si on scan directement avec une boucle du genre :
Code : Tout sélectionner
For ad=$400000 To $800000 ;
If cheater_R_byte("prg_cible.exe" , ad) =125 ; on lit les octets
Debug "trouvé "+ Hex(ad)
EndIf
Next ad
moralité ma fonction cheater_map("prg_cible.exe","MAP_PROCESS")
ne sert pas a grand chose , si ce n'est que comme elle renvoie les segments avec leur tailles on est sur de scanner les segments de notre process.... mais je pense que meme si on scan entre les segments ( dans les trous)
ça n'est pas grave , puisque le but du scan consiste a vérifier plusieurs fois
pour constater un changement de valeurs, qui nous indiquera a coup sur l'adresse qui nous intéresse !!
je pense que les memhack et compagnies utilisent ce systeme, qui est le seul a etre
rapide ....(un peu brutal mais sans danger, on ne fait que lire...)
le code ci dessus renvoi les adresses contenant la valeur 125
il suffirai de le relancer en comparant avec la valeur 124 , ( puisque mon prg_cible diminue cette variable )
et de regarder si l'une des adresses que nous avions, est toujours présente dans la liste, ça nous indiquerai tout de suite a qu'elle adresse correspond notre variable
( seul ceux qui on pratiqué le Hack peuvent me comprendre a ce stade
)tout ça pour dire que finalement les fonctions de la lib telle qu'elle existent depuis le debut
suffisaient pour trouver une adresse de variable !**********************************************************************
Lire un octet a l'adresse (Address.l) du programme "warrock.exe" présent en mémoire
cheater_R_byte( "warock.exe" , Address.l )
**********************************************************************
Lire un Word a l'adresse (Address.l) du programme "warock.exe" présent en mémoire
cheater_R_word( "warock.exe" , Address.l )
**********************************************************************
Lire un Long a l'adresse (Address.l) du programme "warock.exe" présent en mémoire
cheater_R_long( "warock.exe" , Address.l )
**********************************************************************
Lire un Flotant a l'adresse (Address.l) du programme "warock.exe" présent en mémoire
cheater_R_float( "warock.exe" , Address.l )
avec un code comme celui que j'ai mis ci dessus
