Injection de code dans le dock
AP
Membre
Bonjour,
J'écris actuellement un programme qui devra avoir accès aux fenêtres autres que les siennes.
Il doit avoir pour cela un niveau de privilèges élevé. Une technique consiste à injecter du code dans le processus du dock.
Malheureusement je n'ai pas trouvé beaucoup de littérature sur le sujet. Si vous avez un peu de documentation sur le sujet, je suis preneur
Merci
J'écris actuellement un programme qui devra avoir accès aux fenêtres autres que les siennes.
Il doit avoir pour cela un niveau de privilèges élevé. Une technique consiste à injecter du code dans le processus du dock.
Malheureusement je n'ai pas trouvé beaucoup de littérature sur le sujet. Si vous avez un peu de documentation sur le sujet, je suis preneur
Merci
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Bonjour,
Tu peux connaitre la listes des autres fenetres avec des API privées
Voir cette discussion http://forum.pommedev.com/index.php?topic=5735.msg57993;topicseen#msg57993
A mon avis c'est pas suffisant pour ce que tu veux faire, car on se "contentait" de lister les fenêtres et pour chacune d'elle de récupérer son contexte graphique. Mais ça peut être intéressant de jeter un coup à la discussion (bon ok elle fait 50 pages
Sinon pour l'injection de code, tu as regardé du côté des InputManagers ? (je sais pas si ça existe encore sous SnowLeopard tiens il me semblais vaguement avoir entendu que ça tendrait à disparaà®tre, mais j'ai p'tet rêvé) et de SIMBL qui facilite leur intégration...
http://forum.pommedev.com/index.php?board=29.0
Mais il y a une autre solution bien tordue (qui, si ma mémoire est bonne, consiste à passer par les fonctionnalités de "Scripting Additions", mais je ne sais pas si c'est applicable au Dock).
Et apparemment, la version 64 bits de SIMBL utilise cette technique, voir de ce coté.
Juste par curiosité, tu sais pourquoi ? Juste pas (encore?) porté sur 64 bits ? Ou volonté/politique d'Apple de limiter les injections de code par ce biais ? Ou abandon car ils estiment que c'était pas si utile ?
Bon en mm temps c'était surtout utile pour des cas comme créer un plugin Safari alors qu'il n'avait pas d'API officielle pour faire des plugins... mais de ce que j'ai suivi, avec Safari 5 ça va changer si j'ai tout compris...?
Et l'autre gros inconvénient des IM était que c'était systemwide et appliqué à toutes les applis, et pas ciblé pour chaque (et c'est là que SIMBL permettait de contourner ce souci et d'avoir un truc propre... mais en mm temps il faut bien que les IM existent pour que SIMBL puisse faire son boulot de surcouche...)
Je pense qu'Apple n'apprécie pas trop qu'on injecte du code dans leur application. Et puis en fait les InputManagers sont des trucs parfaits pour écrire des logiciels espions...
Sinon, oui, on peut officiellement créer des plugins pour Safari 5 (mais je n'ai pas encore regardé comment).
vm_allocate(), vm_write(), thread_create_running(), _dyld_image_count(), _dyld_get_image_header(), getsectbynamefromheader(), _dyld_get_image_vmaddr_slide() and _dyld_get_image_name()
et le principe est d'ajouter des pages mémoires au process visé, et y injecter du code sous forme d'un nouveau thread
une fois le thread démarré, les techniques habituelles d'overriding (par exemple poseAsClass:) et le chargement de vos propres bundle fonctionneront...
Inutile de vous lancez là -dedans si vous ne maitrisez pas la couche Mach-O, les formats binaires des exécutables, l'édition des liens des exécutables et le fonctionnement de l'allocation des pages mémoires des processus.
Ou alors utilisez :
http://download.github.com/rentzsch-mach_star-mach_star-1.2-0-g4fbda91.tar.gz
c'est marrant c'est l'écran de veille que j'utilise