Discussion :

[geek-59600]

Bonsoir à tous,

Du temps ou j'étais sous windows j'avais créer un trainer pour un jeu, ca m'avait servie de projet pour m'essayer à l'écriture en mémoire & co .

J'avais entre autre utilisé les fonctions OpenProcess(), GetWindowThreadProcessId(), ReadProcessMemory() et WriteProcessMemory().

J'aimerai savoir si il était possible d'effectuer les même chose sous linux ( je suis sous ubuntu 10.04 ) je ne demande pas qu'on fasse le travail a ma place mais plutot une liste de mot clé qui me mettraient dans la bonne voie.

Merci d'avance, bonne soirée.

[LittleWhite]

Bonjour,

Je ne connais pas la solution, mais je suis vraiment interessé
Le système étant plus protégé ( si j'ose dire ) cela sera peut être plus difficile.

[Obsidian]

Oui, tu peux mais pas facilement, de cette manière.

Pour faire ce que tu fais, il vaut mieux déclarer un segment de mémoire partagé avec shmget().

[LittleWhite]

Oui mais dans ce cas, c'est plus le programme lui même qui dit: "Venez acceder à ma mémoire librement"

Dans le cas geek-59600, il précise que son point de départ était un trainer. Donc, c'est acceder à la mémoire d'un programme, à un point qui ne devrais pas.

[geek-59600]

Oui voila c'est plus dans ce sens la, enfaite dans mon trainer je remplacer 3 octets dans la mémoire du processus afin d'y mettre des NOP \x90, si je me rappelle bien afin d'empêcher la décrémentation du nombre de missile dans le jeu.

J'avais rédigé un bref tuto à mes début en C++ il n'est certes pas parfait et contient quelques erreur cependant si ca t'aide à y voir plus clair je peux te fournir le lien en MP ne sachant pas si j'ai le droit de le poster directement sur le forum.

Merci de votre attention.
Bonne journée

[gangsoleil]

Bonjour,

Tu cherches à accéder à la mémoire d'un processus qui n'est pas le tien, qui plus est pour modifier des données (c'est a dire écrire).

Un OS qui te laisse faire ceci est une passoire. C'est la base même de la gestion de la mémoire : chaque processus est étanche, et ne doit pas pouvoir être accédé en écriture depuis un autre processus.

Après, rien ne t'empêche, en lançant un programme en root, d'aller écrire un segment mémoire directement, mais rien ne te garanti que le système ne va pas purement et simplement tuer le processus ... Ou les deux d'ailleurs.

[geek-59600]

Je comprends, c'est vrai que c'est plus safe ainsi mais ma vilaine curiosité m'incite à fouiner encore un peu, pourriez vous m'orienter au sujet de la lecture/écriture dans la mémoire, liste de mot clef, exemple ou autre.

Merci

[Obsidian]

Un OS qui te laisse faire ceci est une passoire. C'est la base même de la gestion de la mémoire : chaque processus est étanche, et ne doit pas pouvoir être accédé en écriture depuis un autre processus.

Cependant, ça peut être tout-à-fait légitime si on a les droits idoines. L'exemple-type est celui de gdb qui permet de rattacher un processus existant à loisir et de le monitorer. C'est d'ailleurs l'usage d'un débugueur que je conseillerais pour faire un trainer occasionnel.

Il en reste que ça doit être possible, mais que je ne connais pas les bons appels. Je vais creuser un peu.

[LittleWhite]

Oui, il faut savoir que pour faire les trainer sous windows ( et aussi autre technique de cracking ), les commandes utilisées sont les commandes de debugguage de windows.

[geek-59600]

Donc la 'voie' a suivre serait celle des appels système lors d'un débug ?

Je vais fouiner

[LittleWhite]

La voie à suivre: Le code de gdb

D'ailleurs je me demande si on peut changer les données à la volée avec gdb :s ( du moins je ne le fais jamais, ou je ne sais pas le faire :s )

[Obsidian]

Voila. L'appel en question est ptrace(), conforme à peu près à tout ce qui peut se vanter d'être un Unix de près ou de loin, à l'exception notable de POSIX, visiblement.

Le procédé est bien débroussaillé ici : http://www.alexonlinux.com/how-debugger-works