Lire des données d'un processus ? - Page 1

Voila, ca fait pas mal de temps que ca me tracasse ces histoires, et vu que je n'ai toujours pas trouvé la solution, je me vois dans l'obligation de poster sur yN

Imaginons que j'ouvre le wordpad, je tape "kikoo c moi" de dans. Y'a t il un moyen de récuperer ce que j'ai tapé "kikoo c moi" ?

Ca dépend, tu veux accéder à l'ensembles des données (brutes) de tout un processus pour voir à quoi ça ressemble ? Ou tu veux communiquer avec un type de prog particulier ?

Ou comment espionner Win32 : http://www.codeproject.com/threads/winspy.asp (Pollux devrait aimer l'article) !

Kochise

Je souhaite juste lire les donnée de ce processus, c'est a dire les variables qu'il traitent. Elles doivent bien etre stocké qq part, et j'arrive pas a trouver ou :I
Je vais lire ton link Kochise.

@pollux oui, jveux lire tout le processus en fait, pr finalement trouver ce que je cherche

Kochise
: (Pollux devrait aimer l'article)

(en tout cas le lien marche pas, pour l'instant)

p_y_a> hmm je connais pas, dsl...

Finalement le link de Kochise est exactement ce que je cherchais merci !
Et oui, le link marche

c bon en fait ! j'ai rien dit

Bon ben comme j'ai trouvé ma réponse, je post, ca peut interesser du monde. En gros y'a trois moyens de lire la mémoire utilisée par un prog:

La premiere, d'apres moi la plus facile à mettre en oeuvre et à comprendre, c'est d'utiliser les fonctions de l'api windows: OpenProcess, ReadProcessMemory. On récupere l'ID et l'Handle de du processus, on l'ouvre et on lit a l'adresse qu'on veut, facile .

La seconde est le hooking des messages qui circule entre windows et le processus. Malheuresement, ca ne permet pas de récupere d'info réellement interessante...mais ca peut servir, cf winspy .

La troisieme, et surement la plus difficile à comprendre, c'est le hooking en injectant du code dans le processus. En gros, on rajoute du code afin de récuperer ce qui nous interesse qd le processus va executer notre code. Ceci est tres pratique pour les logiciels qui recevoient et emettent constamment des données sur un reseau: Ca permet d'obtenir directement toutes les infos voulus, sans pour autant s'embeter a chercher les adresses ( qui peuvent variées ou etre tres difficile à trouver). Pouruqoi ne pas utilisé un sniff en réseau local si finalement c'est pour avoir des packet non formaté ? Parce que souvent ils sont cryptés Donc les prendre juste apres le décryptage du processus, c'est moins fatiguant

Pour avoir testé les trois, je trouve que la premiere est pas mal, pourquoi:
- Facile a mettre en place
- Pas de modif du code du proc ( indetectable, enfin *presque*, par le processus "scanné" )

Le seul probleme, c'est d'obetnir les adresses mémoires de ce qui nous interesse, pour cela on peut utiliser Tsearch ( super logiciel soit dit en passant ). Cependant parfois,ces adresses peuvent etre "crypté" ( des simples rédirection d'adresses, mais bon, ca peut devenir tres vite impossible a décrypter...) et tout le jeu est de lire le code asm pour comprendre comment ca marche
Utilité ? Pas grande chose, si ce n'est faire des petits logiciels sympa pour les jeux, comme des radars, du macroing évolué, et j'en passe.

(Pour trouver des renseignements sur ca: msdn.com, http://www.codeproject.com/threads/winspy.asp, et un article de developpez.com qui en parle, et moi seulement si tu es blonde a forte poitrine .)

Bonjour la securite de Windows...

Je connais pas du tout la prog sous Linux, mais je suppose que ca doit etre récuperable aussi ce genre d'info, du moment que c'est inscrit quelque part dans la ram, y'a toujours moyen de le lire...

Edit: enfin pas du tout, c'est relatif !

./10> seulement qd le processus qui veut lire ça a assez de droits pour aller lire l'autre processus... (mais je sais pas si un process d'un utilisateur non-admin peut aller lire les données d'un process ouvert par ce même utilisateur...)

De toute façon, sous Unix, strace ou gdb doivent faire des choses un peu similaires, hein...

> strace ou gdb
Ben non car c'est eux qui lancent le processus.

Ben non parce que tu peux aussi les attacher à un processus déjà existant... (comme Visual Studio sous Windows)

(mais je sais pas si un process d'un utilisateur non-admin peut aller lire les données d'un process ouvert par ce même utilisateur...)

Oui.

Ben non parce que tu peux aussi les attacher à un processus déjà existant... (comme Visual Studio sous Windows)

La totalité des fonctions de debugging passent par un point d'entrée unique, ptrace.
Il est possible de désactiver ce point d'entrée, ou de limiter son champ d'action (de nombreux patchs font ça, certains permettant de définir avec précision quel processus peut débugger quel autre, doivent-ils être parents, quelles doivent être les privilèges de chaque processus, etc)

Sur mon système, il est impossible d'attacher le débugger à un processus existant, ça répond EPERM. Il est également impossible de débugger un processus qui tourne en root (même si on lance le débugger depuis le compte root).

spectras
:

Ben non parce que tu peux aussi les attacher à un processus déjà existant... (comme Visual Studio sous Windows)

La totalité des fonctions de debugging passent par un point d'entrée unique, ptrace. Il est possible de désactiver ce point d'entrée, ou de limiter son champ d'action (de nombreux patchs font ça, certains permettant de définir avec précision quel processus peut débugger quel autre, doivent-ils être parents, quelles doivent être les privilèges de chaque processus, etc)

OK, je sais pas si y a ça ou pas sous Win...

Il est également impossible de débugger un processus qui tourne en root (même si on lance le débugger depuis le compte root).

Là par contre c complètement inutile En principe root peut accéder à la RAM et/ou () désactiver ton patch ^^ Y a que pour un utilisateur non-root que ça fait la moindre différence...

Root peut accéder à la ram seulement si le noyau veut bien. Et pour désactiver le patch, il faut qu'il arrive à remplacer le noyau par un autre. Sachant que tu peux empècher le chargement de modules et avoir ton noyau sur un medium en lecture seule, ça limite.

Bon après faut voir quel niveau de sécurité tu veux avoir.

Oué, tu peux faire en sorte que root ne soit plus un vrai root mais un utilisateur normal, mais c pas très malin... La vraie solution, c de pas faire tourner les processus qui sont critiques en tant que root, mais sous un utilisateur bidon avec juste les droits qu'il faut

Pollux a compris la vie

Oué, tu peux faire en sorte que root ne soit plus un vrai root mais un utilisateur normal, mais c pas très malin...

C'était pas à ça que je pensais. Root n'a que les droits que le noyau veut bien lui accorder. Tu peux tout à fait éditer le code qui gère le périphérique représentant la mémoire pour qu'il réponde systématiquement EPERM. Et root ou pas root, ça répondra permission refusée.

La vraie solution, c de pas faire tourner les processus qui sont critiques en tant que root, mais sous un utilisateur bidon avec juste les droits qu'il faut

La vraie solution c'est le Hurd. Les techniques emplyées pour gérer ce genre de choses sont nickel. C'est juste dommage qu'il n'y ait pas de release prévue avant 2042.

spectras
:

Oué, tu peux faire en sorte que root ne soit plus un vrai root mais un utilisateur normal, mais c pas très malin...

C'était pas à ça que je pensais. Root n'a que les droits que le noyau veut bien lui accorder. Tu peux tout à fait éditer le code qui gère le périphérique représentant la mémoire pour qu'il réponde systématiquement EPERM. Et root ou pas root, ça répondra permission refusée.

Nan mais d'accord mais soit tu fais en sorte que root *ne puisse jamais* accéder à la mémoire directement, à ce moment-là tu lui as retiré une grande partie des droits qui font qu'il est root (et évidemment que c pas non plus un utilisateur totalement non-privilégié ), par exemple il n'aura pas le droit de charger des modules dans le noyau, même pas le droit de changer de noyau sauf si tu trouves acceptable que qqun qui a les droits de root puisse accéder à la mémoire au prochain reboot...

La vraie solution, c de pas faire tourner les processus qui sont critiques en tant que root, mais sous un utilisateur bidon avec juste les droits qu'il faut

La vraie solution c'est le Hurd. Les techniques emplyées pour gérer ce genre de choses sont nickel. C'est juste dommage qu'il n'y ait pas de release prévue avant 2042.

Non, la vraie de vraie solution, c'est Tunes, mais c'est dommage qu'il n'y ait pas de release prévue avant ω
Donc je reformule, la vraie solution, *sous Linux/BSD/...*, c'est de blabla ^^

même pas le droit de changer de noyau sauf si tu trouves acceptable que qqun qui a les droits de root puisse accéder à la mémoire au prochain reboot...

Si, si, même le droit. Mais désolé pour root, faut un accès physique pour changer le noyau, pour peu que tu bootes sur disquette. C'est tout bête de booter sur une disquette, mais au niveau sécurité, t'élimines pas mal de problèmes. Tu peux aussi t'amuser à coller les modules éventuels sur un ramdisk ainsi que les commandes les plus sensibles, et tu limites énormément la casse.

Je sais pas si c fait pour ou pas, mais si c pas fait pour, il y a probablement pleins d'autres moyens de faire des choses pas gentilles en root...

Et ça peut être contraignant de ne pas pouvoir mettre à jour ton noyau à distance (bon, d'accord, c un peu du chipotage, mais si t parano au point de ne pas faire confiance à root, alors tu devrais être au moins autant parano pour ce qui est de mettre à jour ton noyau qd une faille de sécurité est découverte...)