RÉCUPÉRER LES VARIABLES D'ENVIRONNEMENT DE N'IMPORTE QUEL PROCESSUS
violent_ken
Messages postés
1812
Date d'inscription
mardi 31 mai 2005
Statut
Membre
Dernière intervention
26 octobre 2010
-
14 févr. 2009 à 19:21
violent_ken Messages postés 1812 Date d'inscription mardi 31 mai 2005 Statut Membre Dernière intervention 26 octobre 2010 - 16 févr. 2009 à 19:48
violent_ken Messages postés 1812 Date d'inscription mardi 31 mai 2005 Statut Membre Dernière intervention 26 octobre 2010 - 16 févr. 2009 à 19:48
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/49264-recuperer-les-variables-d-environnement-de-n-importe-quel-processus
https://codes-sources.commentcamarche.net/source/49264-recuperer-les-variables-d-environnement-de-n-importe-quel-processus
16 févr. 2009 à 19:48
Par contre, pour les droits, administrateur ne suffit pas pour accéder à tout : contrairement à ce que j'ai dit dans la description par rapport à l'injection, il faut également le droit DebugPrivilege pour accéder au processus système pour faire un ReadProcessMemory.
@+
16 févr. 2009 à 19:25
Pour info, je suis administrateur de mon propre PC.
@+
16 févr. 2009 à 18:33
Sinon pour le processus ou il n'y a pas de données, _size = 2 indique que le bloc mémoire contenant la liste des variables est vide (du coup c'est normal qu'il retrouve rien).
Plusieurs raisons :
- soit le processus n'a pas de variables (très peu probable)
- soit l'accès est refusé (processus système et droits non suffisants ?)
- soit je sais pas ??
@+
16 févr. 2009 à 18:00
J'ai toujours 1 ou 2 lignes vides à la fin.
Et pour les processus où il n'y a pas de données (sauf 2 lignes vides) :
_size = 2
16 févr. 2009 à 16:47
Avec la nouvelle fonction çà marche, mais çà reste franchement étrange que j'ai du apporter la modification du dessus.
Je vais mettre à jour le zip.
Alors sinon pour les lignes vides, effectivement j'ai fait une erreur d'index, il faut lire :
sBuf2.CopyTo(sBuf, CInt(size / 2)) (pas de -1) ^^
Pour =::=::\, ben honnêtement c'est pas de ma faute :-)
En mémoire il y a une chaine de ce type (vérifié avec un editeur hexa) :
::=::\@ (ou @ est un nullchar). Du coup lors du parsing, je prend ce qui est à gauche du premier '=' (c'est à dire rien) et c'est le nom de la variable.
Sa valeur est à droite du premier '=', c'est donc =::=::\.
Bref, du coup c'est "un bug de Windows" (une variable d'environnement qui n'a pas de nom et qui a une valeur pourrie). Le plus simple est de les filtrer en n'affichant que celles dont NomVariable.Length > 0 (nom de variable non nul).
Pour les processus sans données, tu pourrais s'il te plait juste mettre un point d'arrêt dans le code et me donner la valeur de _size juste avant ReadBytesAS ?
Ainsi que le nom du process, parce qu'un process avec plus de 4K de variables d'environnement... OUCH !!
Merci
@+
16 févr. 2009 à 16:27
Merci pour la nouvelle fonction, c'est beaucoup mieux !
Il y a toujours des processus sans données : essaie de découper autant de fois que de tranche de 2048 octets.
Ensuite, quelques bizarreries :
Quand il y a des données, la 1ère ligne est :
::::\
Sur quelques processus, j'ai :
C:C:\UnChemin
où UnChemin est un chemin complet
Il y a également souvent 2 lignes vides en fin de liste (desfois 1, desfois 0) selon le processus.
En tout cas, j'ai pu tester mes applis : 10/10
(Et ça ne retourne rien de plus que explorer !)
16 févr. 2009 à 11:57
Au delà de cette taille, il faut fractionner la lecture en deux fois (et là encore c'est dans l'espoir que la taille totale soit inférieure à 4096 bytes) et fusionner les deux buffers.
Bref çà marche, MAIS :
"pourquoi ne peut t-on pas lire d'un seul bloc 2124 bytes ?"
Je vais regarder sur le net avant de poster la MAJ
(sinon juste remplacer la fonction ReadBytesAS par çà :
Public Function ReadBytesAS(ByVal offset As Integer, ByVal size As Integer) As Short()
Dim sBuf() As Short
Dim _si As Integer = size
Dim lByte As Integer
ReDim sBuf(size - 1)
' Short array -> size*2 to get bytes count
Dim ret As Integer = ReadProcessMemory(_handle, offset, sBuf, size * 2, lByte)
' If ret 0 and err ERROR_PARTIAL_COPY, reduce block size
Do While ((ret 0) And (Err.LastDllError 299))
size -= 2 ' Short <-> 2 bytes
ret = ReadProcessMemory(_handle, offset, sBuf, size * 2, lByte)
Loop
If size < _si Then
' Got an error before, now we have to read part which was unreadable
Dim sBuf2() As Short
ReDim sBuf2(_si - size - 1)
ret = ReadProcessMemory(_handle, offset + size, sBuf2, (_si - size) * 2, lByte)
' Copy buf2 to buf
sBuf2.CopyTo(sBuf, CInt(size / 2 - 1))
End If
Return sBuf
End Function
)
@+
16 févr. 2009 à 11:35
- l'adresse du PEB est bonne
- l'adresse du ProcessParameter block est bonne
- l'adresse des variables d'environnement est bonne (apparement toujours 65536 sous XP)
- la taille du bloc à lire est bonne.
C'est lors de l'appel à ReadProcessMemory que çà foire (retourne l'erreur ERROR_PARTIAL_COPY, cad seule une partie de la mémoire a pu être lue).
C'est super étrange, la memory region size est largement supérieure à la taille du bloc à lire (region size 4k, block 2114 octets).
Tu n'aurais pas un OS 64 bits par hasard ?
@+
16 févr. 2009 à 11:04
Je vais essayer de voir pourquoi çà bug
Merci
@+
16 févr. 2009 à 10:52
Mais après conversion vers VB .Net 2008 (Framework 3.5), même si aucun erreur n'apparaît et que la compilation se fait sans soucis, je ne vois que la liste des processus à gauche, et à droite, 1 liste plus ou moins longue (en fonction du process) de données vides (et pourtant aucun msgbox n'apparait)...
PS : je suis sur XP SP3
15 févr. 2009 à 18:17
15 févr. 2009 à 12:37
Sinon d'un point de vue "utilité" des variables d'environnement, ben effectivement c'est pas évident :-)
Si on veut trouver une utilité, parmi toutes les variables dispos, je dirais :
- on peut trouver utile de connaitre la valeur TEMP ou TMP des variables d'environnement, dans le cas on le programme les utilise pour stocker ses fichiers temporaires
- peut être aussi USERNAME et USERDOMAIN pour des applications réseau ?
- l'emplacement de stockage des fichiers utilisateur (APPDATA) ?
Bref, je sais pas trop ^^ A part les variables citées, le reste apparait pas franchement intéressant, d'autant que tous les processus ont à peu près les mêmes... :)
@+
15 févr. 2009 à 12:03
15 févr. 2009 à 11:54
Bah personnellement, dans l'immédiat, c'est une fonction que je vais ajouter dans cette source : http://www.vbfrance.com/codes/YET-ANOTHER-PROCESS-MONITOR_48860.aspx
J'avais pas trouvé comment faire autrement, ben du coup j'ai proposé çà.
M'enfin, je viens de voir (juste au dessus, dans la liste des "Source en rapport avec celle ci") que ShareVB est passé bien avant moi :-)
http://www.vbfrance.com/codes/INFORMATIONS-SUR-PROCESSUS-LEUR-PEB-PARAMETRE-LIGNE-COMMANDE_38976.aspx
Mince !
Sinon bah du coup je vais travailler du côté de PEB_LDR_DATA (http://msdn.microsoft.com/en-us/library/aa813708.aspx) afin de proposer de pouvoir récupérer de manière originale (et rapide j'espère ! C'est le but recherché...) la liste des modules chargés par un processus, autrement que par toolhelp.
@+
15 févr. 2009 à 10:08
14 févr. 2009 à 19:21
@+