Sujet Précédent Sujet Suivant

PSEUDO EMULATEUR D'EXE

Utilisateur anonyme - 6 juin 2009 à 20:40
mayner Messages postés 4 Date d'inscription dimanche 5 juillet 2009 Statut Membre Dernière intervention 5 juillet 2009 - 5 juil. 2009 à 09:03

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/50124-pseudo-emulateur-d-exe

mayner Messages postés 4 Date d'inscription dimanche 5 juillet 2009 Statut Membre Dernière intervention 5 juillet 2009
5 juil. 2009 à 09:03

hola y gracias

Utilisateur anonyme
16 juin 2009 à 12:06

J'en prends note. Et en effet comme tu l'as suggéré, je voulais que mon projet s'oriente plutôt vers un debugger. Le genre de debugger ou les Hardware breakpoints (ex.) ne risquent pas de se faire détecter et encore moins effacer par un quelconque SEH. J'avais aussi prévu un ordonnancement de taches (threads, essentiels en appli windows). Mais bon, c'est vraiment beaucoup de boulot.
Pas de problème, je te tiendrai au courant, mais j'avoue que ce ne sera pas pour tout de suite (beaucoup de boulot)...

sdcoder Messages postés 16 Date d'inscription jeudi 4 novembre 2004 Statut Membre Dernière intervention 18 décembre 2009
15 juin 2009 à 11:34

Pour un message box, en décompilant du code VB (vbdecompiler), tu verras que l'affichage d'une message box se fait uniquement en chargeant la DLL et faisant un simple call à la fonction msgbox, avec l'adresse de la chaine en argument. tu as déjà presque fait le décompiler, peut-être peux-tu lister tous les appels (call) à des api (user32.dll, kernel32.dll, ...) dans l'assembleur d'un programme Windows et faire une petite interface VB qui charge le programme,le décompile, l'éxécute et appelle ces DLL, tu pourras ainsi simuler et contrôler le programme peut-être à la WinICE/SoftIce, c'est juste une première étape, ensuite faudra regrouper les autres bouts de code ASM en "fonctions" que tu appelera aussi comme pour les DLL. tu devrais avoir ainsi un système proche de ton but que tu pourras porter sur d'autres OS en portant les DLL windows, ou prendre celles de wine ou faire les tiennes pour changer le look, tu pourras aussi développer un soft comme citrix ou tse pour piloter ton appli à distance.
Ton programme devrait fonctionner avec les applis XP,vista et seven (32 bits bien sur). En tout cas, tiens moi informé lorsque tu as une version qui tourne.

Utilisateur anonyme
15 juin 2009 à 11:02

Oui, à la base c'est comme cela que je l'avais vu. Je voulais émuler les programmes windows seulement. J'avais pensé à faire une sorte d'hyperviseur et n'émuler que le user land. Pour la partie kernel land, je pensais récupérer tous les syscall et y mettre mon code. Mais ça fait un sacré boulot. Je n'ai pas abandonné, je regarde un peu de tout, les sources Wine, QEMU, JPC (Pc émulé en java - très intéressant), les source d'un windows-like libre dont je ne me souviens plus du nom. Évidemment, ce serait pour émuler de petits programmes, genre qui affiche une MessageBox,... Ce serait un début, et je serai assez content si j'arrivai jusque là.

sdcoder Messages postés 16 Date d'inscription jeudi 4 novembre 2004 Statut Membre Dernière intervention 18 décembre 2009
13 juin 2009 à 19:59

oui tu as raison, l'emulation d'une machine nécessite d'emuler aussi toutes les autres parties hardware, pas que le processeur. Maintenant tu peux te fixer uniquement un processeur pentium 4 32 bits avec un programme et de la RAM qui ne fait pas d'accès au hardware ou éventuellement à chaque "out" ou "intr", tu retoute vers des fonctions de ton programme (affichage, clavier,...) mais tout dépend de ce que tu voulais faire, si c'est exécuter des programmes DOS c + simple, si ce sont des programmes windows, il vaut mieux voir le code de Wine (linux) car toutes les bibliothèques (dll win32) sont déjà codées et compilées, il restera alors à comprendre les entêtes des EXE win32 (MS) et suivre les instructions du processeur qui font la plupart du temps que des appels aux bibliothèques. En effet c un défi auquel il faut compétence et résistance. bon courage.

Utilisateur anonyme
13 juin 2009 à 16:53

Salut, J'ai pensé à QEMU, mais lorsque j'ai regardé le code, j'avoue que je n'ai pas vraiment réussi à le déchiffrer. Si je me rappelle bien (du moins la dernière fois que j'ai regardé), la complexité du code mise à part, ils ont fait un code générique pour plusieurs architectures. Et là j'ai du mal. Merci quand même.

sdcoder Messages postés 16 Date d'inscription jeudi 4 novembre 2004 Statut Membre Dernière intervention 18 décembre 2009
12 juin 2009 à 11:16

Salut Frelon, tu trouveras le code des principaux processeurs sur le site de QEMU.
C'est pas du VB mais en tout cas ça fera avancer ton projet à grande vitesse. Bonne continuation.

Utilisateur anonyme
8 juin 2009 à 11:48

Bonjour, j'aimerai avoir si possible des retours sur le codage du projet. Merci.

Utilisateur anonyme
6 juin 2009 à 20:53

Non, je pense que le VB n'est pas très adapté pour ce genre de programme (absence de pointeurs,...) enfin c'est ce que je pense.

cs_ghuysmans99 Messages postés 3982 Date d'inscription jeudi 14 juillet 2005 Statut Membre Dernière intervention 30 juin 2013 16
6 juin 2009 à 20:45

"et je n'est pas les connaissances requises" => "... je n'ai pas ..."
Sinon je ne comprends pas trop ce que tu voulais dire par là : VB ne savait pas le faire, ou tu ne le connaissais pas assez ?

Utilisateur anonyme
6 juin 2009 à 20:40

Des commentaire, critiques constructifs seraient sympa, svp.

Discussions similaires

Compiler/décompiler un .exe

generateur de pseudo

remote pseudo verticale

Decompiler un .exe

DéCompiler un exe

Votre réponse

Discussions similaires