›

Accès libre à  la mémoire Vive

tomactomac Membre
21:58 modifié dans API AppKit #1
Bonjour,

J'aimerais savoir si il est possible d'avoir accès à  la mémoire vive utilisée par une autre application (ou autre processus), c'est à  dire pouvoir lire et modifier des valeurs à  certaines adresses. Bien sur tout cela en objective-c.

Merci d'avance

Réponses

  • schlumschlum Membre
    21:58 modifié #2
    Heureusement que non...
    Imagine sinon, un buffer overflow pourrait aller taper aléatoirement dans la mémoire d'une autre appli.  :o
  • tomactomac Membre
    octobre 2009 modifié #3
    Pourtant sous Windobe cela est possible donc il doit y avoir un moyen de le faire sous Mac   :p

    Edit :
    Avec un langage aussi simple que autoit il est possible de le faire ^^
    D'ailleurs iHaxGamez permet de modifier des valeurs dans la mémoire vive non ?
  • AliGatorAliGator Membre, Modérateur
    octobre 2009 modifié #4
    MacOSX utilise un système de mémoire protégée, permettant d'éviter à  tout le monde et n'importe qui d'aller pourrir et hacker la mémoire vive et le code des autres logiciels. Encore heureux en effet.
    Mais il me semble que c'est un peu aussi le cas sous Windows d'ailleurs.

    Par contre cela n'empêche pas de faire communiquer plusieurs applications entre elles, si elles ont prévu ce qu'il faut pour, et d'échanger des objets et des images entre elles.
    Je pense que c'est ta formulation "accès libre à  la mémoire vive" qui est mauvaise (genre taper dans un void* et en faire se que l'on veut n'importe comment, écrire dans un buffer quelconque de la mémoire d'une autre appli sans lui demander son avis, etc... bref faire des accès libres (sans contrôles) à  la mémoire vive (donc aux buffers quelconques de la zone mémoire, indépendamment de leur zone, type, ou des variables qui pointent sur ces zones mémoires). Si on pouvait faire ça, bonjour les corruptions mémoire dans tous les sens, et bonjour les crash assurés.

    Mais par contre dans Cocoa il y a tout ce qu'il faut pour qu'une application puisse appeler des objets d'une autre application, échanger des objets entre applications Cocoa, déclencher des événements depuis une application à  destination d'une autre application, etc...
    Tout ce qu'il te faut est expliqué dans la doc des Distributed Objects.
  • schlumschlum Membre
    21:58 modifié #5
    Je ne veux pas dire de bêtises, mais il me semble bien qu'un système UNIX cloisonne la mémoire.

    De toute manière, la gestion de la mémoire sous Windows et sous un UNIX c'est très différent et incomparable.
  • tomactomac Membre
    octobre 2009 modifié #6
    La communication inter-application je connais mais là  mon but est de hacker la mémoire.

    Edit :
    J'ai trouver mon bonheur dans les sources de iHaxGamez, qui je le rappel permet de choisir un processus et d'avoir accès à  la mémoire utilisée par celui-ci.
  • AliGatorAliGator Membre, Modérateur
    21:58 modifié #7
    Dans ce cas je ne sais pas si c'est possible. A moins d'attacher le process à  hacker à  ton process père, faire des fork() et autre, de ce côté du coup c'est peut-être possible de mettre un pied dans l'autre application "de façon brute". Voir aussi les façons de faire de gdb et des outils de profiling existants.
  • Philippe49Philippe49 Membre
    21:58 modifié #8
    Je n'y crois pas

    Description for iHaxGamez:<br />Search, Filter and Replace any kind of value in any running application on your PPC or x86 Mac (OS X 10.4). Documentation and GPL source code are included in the download.

    Euh là , y a personne qui veut d'un MBP tout neuf ,  gratos ?  :brule: :brule:



    dans 1256831286:

    Mais par contre dans Cocoa il y a tout ce qu'il faut pour qu'une application puisse appeler des objets d'une autre application, échanger des objets entre applications Cocoa, déclencher des événements depuis une application à  destination d'une autre application, etc...
    Tout ce qu'il te faut est expliqué dans la doc des Distributed Objects.


    Le C permet aussi de construire une mémoire partagée entre deux process, mais le code de chaque process doit l'avoir prévu. Voir les pages man de shmget shmat.
  • schlumschlum Membre
    octobre 2009 modifié #9
    "iHaxGamez" ne touche pas directement la mémoire... Il passe par un élément driver qui lui permet d'accéder aux fonctions de manipulation de la mémoire virtuelle de <mach/vm_map.h> (ça nécessite d'ailleurs le mot de passe administrateur).

    En passant par un driver directement lancé dans le noyau, on fait effectivement tout ce qu'on veut sur une machine.
  • tomactomac Membre
    21:58 modifié #10
    Ok merci de toutes ces informations je vais enfin pouvoir travailler sur le hack de la mémoire.
  • Philippe49Philippe49 Membre
    21:58 modifié #11
    Un petit coup de vmmap sur un exécutable :
    Comment interprétez-vous les permissions ? Par exemple, la stack en mode :  rw-/rwx SM=COW

    % vmmap pgm -interleaved<br />Virtual Memory Map of process 622 (pgm)<br />Output report format:&nbsp; 2.2&nbsp; -- 64-bit process<br /><br />==== regions for process 622&nbsp; (non-writable and writable regions are interleaved)<br />__TEXT&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  0000000100000000-0000000100001000 [&nbsp; &nbsp; 4K] r-x/rwx SM=COW&nbsp; /Users/bureau/Desktop/pgm<br />__DATA&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  0000000100001000-0000000100002000 [&nbsp; &nbsp; 4K] rw-/rwx SM=PRV&nbsp; /Users/bureau/Desktop/pgm<br />__LINKEDIT&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  0000000100002000-0000000100003000 [&nbsp; &nbsp; 4K] r--/rwx SM=COW&nbsp; /Users/bureau/Desktop/pgm<br />STACK GUARD&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 0000000100003000-0000000100004000 [&nbsp; &nbsp; 4K] ---/rwx SM=NUL&nbsp; <br />MALLOC (admin)&nbsp; &nbsp; &nbsp; &nbsp;  0000000100004000-0000000100005000 [&nbsp; &nbsp; 4K] rw-/rwx SM=COW&nbsp; <br />STACK GUARD&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 0000000100005000-0000000100007000 [&nbsp; &nbsp; 8K] ---/rwx SM=NUL&nbsp; <br />MALLOC (admin)&nbsp; &nbsp; &nbsp; &nbsp;  0000000100007000-0000000100012000 [&nbsp;  44K] rw-/rwx SM=COW&nbsp; <br />STACK GUARD&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 0000000100012000-0000000100014000 [&nbsp; &nbsp; 8K] ---/rwx SM=NUL&nbsp; <br />MALLOC (admin)&nbsp; &nbsp; &nbsp; &nbsp;  0000000100014000-000000010001f000 [&nbsp;  44K] rw-/rwx SM=COW&nbsp; <br />STACK GUARD&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 000000010001f000-0000000100020000 [&nbsp; &nbsp; 4K] ---/rwx SM=NUL&nbsp; <br />MALLOC (admin)&nbsp; &nbsp; &nbsp; &nbsp;  0000000100020000-0000000100021000 [&nbsp; &nbsp; 4K] r--/rwx SM=COW&nbsp; <br />MALLOC_TINY&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 0000000100100000-0000000100200000 [ 1024K] rw-/rwx SM=COW&nbsp; DefaultMallocZone_0x100004000<br />MALLOC_SMALL&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  0000000100800000-0000000101000000 [ 8192K] rw-/rwx SM=COW&nbsp; DefaultMallocZone_0x100004000<br />STACK GUARD&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 00007fff5bc00000-00007fff5f400000 [ 56.0M] ---/rwx SM=NUL&nbsp; <br />Stack&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 00007fff5f400000-00007fff5fc00000 [ 8192K] rw-/rwx SM=COW&nbsp; thread 0<br />__TEXT&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  00007fff5fc00000-00007fff5fc3c000 [&nbsp; 240K] r-x/rwx SM=COW&nbsp; /usr/lib/dyld<br />__DATA&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  00007fff5fc3c000-00007fff5fc7b000 [&nbsp; 252K] rw-/rwx SM=COW&nbsp; /usr/lib/dyld<br />__LINKEDIT&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  00007fff5fc7b000-00007fff5fc8f000 [&nbsp;  80K] r--/rwx SM=COW&nbsp; /usr/lib/dyld<br />__DATA&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  00007fff70999000-00007fff709bc000 [&nbsp; 140K] rw-/rwx SM=COW&nbsp; /usr/lib/libSystem.B.dylib<br />__TEXT&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  00007fff84bff000-00007fff84c04000 [&nbsp;  20K] r-x/r-x SM=COW&nbsp; ...ib/system/libmathCommon.A.dylib<br />__TEXT&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  00007fff858a8000-00007fff85a67000 [ 1788K] r-x/r-x SM=COW&nbsp; /usr/lib/libSystem.B.dylib<br />__LINKEDIT&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  00007fff88cf1000-00007fff8ab7c000 [ 30.5M] r--/r-- SM=COW&nbsp; ...ib/system/libmathCommon.A.dylib<br /><br />==== Legend<br />SM=sharing mode:&nbsp; <br />	COW=copy_on_write PRV=private NUL=empty ALI=aliased <br />	SHM=shared ZER=zero_filled S/A=shared_alias<br />


  • schlumschlum Membre
    21:58 modifié #12
    Copy-on-write (COW) pages are shared by multiple processes (or shared by a single process in multiple locations).  When the page is modified, the writing process then receives its own private copy of the page.  Empty (NUL) sharing implies that the page does not really exist in physical memory.  Aliased (ALI) and shared (SHM) memory is shared between processes.
  • Philippe49Philippe49 Membre
    21:58 modifié #13
    Oui j'ai lu la page man, mais j'ai du mal à  interpréter "shared by multiple processes" . De même pour la partie permissions rw-/rwx  : read write mais ces droits sont attribués à  qui, et comment les exercer ?
  • schlumschlum Membre
    21:58 modifié #14
    Là  pour le coup à  mon avis c'est plutôt "shared by a single process in multiple locations" (threads ?).

    Pour les permissions :
        The protection mode describes if the memory is readable, writable, or executable.  Each virtual memory region has a current permission, and a maximum permission.  In the line for a virtual memory region, the current permission is displayed first, the maximum permission second.  For example, the first page of an application (starting at address 0x00000000) permits neither reads, writes, or execution ("---"), ensuring that any reads or writes to address 0, or dereferences of a NULL pointer immediately cause a bus error.  Pages representing an executable always have the execute and read bits set "r-x").  The current permissions usually do not permit writing to the region.  However, the maximum permissions allow writing so that the debugger can request write access to a page to insert breakpoints.  Permissions for executables appear as "r-x/rwx" to indicate these permissions.


    En gros c'est current "rw-" et max "rwx" pour le processus (et le kernel qui a tous les droits bien sûr).
  • Philippe49Philippe49 Membre
    21:58 modifié #15
    Merci
  • laudemalaudema Membre
    21:58 modifié #16
    dans 1256899665:

    Merci

    En cherchant autre chose j'ai vu hier justement une petite appli qui permet ce genre de chose. Perso j'y ai pas compris grand chose mais ce n'était pas non plus l'objet de mes recherches.
    Aller dans la doc Xcode et faire une recherche sur ... SharedMemory !
    Une fois l'archive décompressée il faut renommer le dossier .pbproject en .xcodeproject, le lancer d'un double clic, le renommer pour pouvoir l'enregistrer dans son dossier d'origine et, enfin, aller dans le menu Project et faire "upgrade all targets to native". Après ça compile et se lance.
    Il faut faire des copies de l'appli de départ, les lancer, et on peut écrire dans l'une et voir le résultat dans les autres ..
    hth
  • AliGatorAliGator Membre, Modérateur
    21:58 modifié #17
    Bah oui, mais ça c'est quand on crée son appli de sorte d'utiliser de la mémoire partagée, en la déclarant accessible comme telle. La demande originelle était plutôt de hacker la mémoire d'une appli qui n'avait pas prévu qu'on y accède, si j'ai tout suivi (car bon sinon y'a plein de solutions)
Connectez-vous ou Inscrivez-vous pour répondre.