[..] Memory read etc . . .

[legend]

Bonjour,
je viens de découvrir et de commencer les fonctions memoryread/write etc . . .
bref, le "help" dans l'udf <NomadMemory.au3> n'est pas trop clair et je bloque sur un petit truc.
l'adresse de mémoire -_-", comment obtenir l'adresse de mémoire que je cherche (le truc de hex 0x000000 . . .)
quand je la trouve c'est sur quelle forme?
merci et bonne journée.

[overflow]

et bien les adresses elles ne sont pas sous le sabot d un cheval

se sont les adresses memoire ou ton prog stock des infos
ou alors meme des adresse qui pointes sur le prog lui meme pour modifier
le deroulement du code

donc je te conseille fortement de trouver un forum qui traite du sujet
car ici les bot ou autre prog qui modifie l utilisation original d un programme
tiers ne sont pas supporté par le reglement du fofo ^^

[legend]

Je pense pas que j'ai proposé un sujet qui traite les bots.
J'ai fait des questions sur une fonction de base. un UDF que plusieurs utilisent compris quelques admins du forum!!!
PS : je joue aucun jeux pour le moment pas la peine de s’inquiéter.
merci et bonne journée.

[sylvanie]

Je présume que tu as déjà lu dans la partie tuto celui que j'avais fait sur le partage de variable depuis un accès direct en ram ( http://www.autoitscript.fr/forum/viewto ... f=11&t=846 )
Pour obtenir une adresse depuis un script Autoit, il faut impérativement passer par un Dllstructcreate pour en extraire l'adresse des éléments. c'est un des seuls moyens dont on dispose en Autoit.
Ce cas d'usage était exposé pour palier au manque de notion de thread dans Autoit.
Maintenant si il s'agit d'un exe externe, c'est beaucoup plus compliqué, car il te faudra utiliser un debuger pour au mieux avoir connaissance des plage d'allocation (et non l'adresse directe de la variable $toto). Après si le programme est compilé en mode debug et que tu possède le fichier de résolution de symboles, c'est plus simple, car tu auras cette fois l'information toute cuite dans ce fichier.
Après ça n'est pas pour autant que tu puisse écrire dans cette adresse, car même si Windows est assez permissif en matière d'accès, il a tout de même des mécanismes d'accès pour protéger certaines zones en écriture (voir même en lecture vis àvis des autres process).
En tout cas une tentative d'écriture en ram sur process externe est assez souvent voué à un échec quand ce dernier n'est pas compilé en mode deug (voir parfois un joli redémarrage). Ensuite si tu n'as pas de chance malgré les protections OS, et bien tu jardines dans une zone du genre dédiée à être recopiée à l'extinction sur disque dire dans un fichier system et là on ressort les gosts et autre backup de restauration.
Les méthodes d'accès par ram sont souvent faites par des process de "connivence" dont un exporte généralement un moyen de faire connaître à l'autre son adresse, après pour le reste ça relève du petit chimiste : ça peut marcher comme ça peut péter. gros conseil mieux vaut se limiter à la lecture.

Quant à la finalité de pourquoi c'est utilisé, c'est comme pour beaucoup de choses : il y a du blanc, du noir et pleins de nuances de gris

[legend]

Merci pour cette réponse qui m'aidera énormément (mais je manque trop d’expérience)
Perso je voulais l'utiliser pour avoir plus d'info sur ce que fait un processus.
C'est comme si tu ouvre une IE et que tu veut faire un read ou des read sur des controls ou des fenêtres sauf que je pensait que un read sur le processus donnera des résultats plus précis surtout sur les applications/controls non reconnus par AutoIt.
Pour le memorywrite ça me rapelle d'un petit logiciel de cheat que j'utilisait il y a 2ans (quand je jouait a métin2 ) du nom "cheat engine" qui fait des read et permet de changer des valeurs d'adresses de n'importe quel processus (je suis pas sur mais j'ai essayé sur des processus du fonctionnement du système sur un publinet et le pc a failli exploser . . .)
tout ce que je me rapelle, ce sont les codes hexa a dé-coder après des centaines d'essais
bonne journée