Yoa2n

T'as beau être persuadé... Ce que ton imagination développe n'as aucun moyen d'être le sujet d'une preuve. Quand tu contredis quelqu'un ne soit pas contradictoire dans tes propos et appuis les d'un motif valable. J'croit en toi moi Ac_K . Jolie Jolie =P Sinon. A ceux qui demande une version sans .NET... Certe, .NET est lourd, lent et question gestion de la mémoire, ça n'as rien avoir à un C / C++ pur. Mais le .NET offre une vrai opportunité de portabilité vers n'importe quel système étant donné qu'il existe des Framework .NET pour Unix (Linux & Mac). Merci.

Wouah. J'voit que le premier post n'aura pas servi à rien =)). Sinon merci Pour votre support à tous. Faut que je me remette au boulot moi

Salut à toi Ac_K. J'vais droit au but. L'individu qui a crée ce fameux NandPro semble utiliser les MFC pour se "facilité" la tache dans sa programmation au détriment de l'optimisation du code par derrière. Cette MFC propose donc au programmeur différents Objet qui lui permette une gestion simple d'un peu pres tout, comme la librairie Qt tres connu pour Linux. Il l'initialise donc au début de son code dans la fonction Main, ce que tu as découvert n'est donc pas étrange mais tout naturel =P Je me suis un peu penché sur le Sujet. Et en effet, il semble utiliser la MFC à grande échelle. Pour la manipulation de ses fichiers par exemple. Bout de Code : .text:004043ED call sub_412DC6.text:004043F2 add eax, 40h.text:004043F5 push eax ; FILE *.text:004043F6 call _fprintf Avant chaque utilisation du fichier de log, il semble appeler une fonction, la sub_412DC6, qui lui retourne un résultat dans le registre eax auquel on ajoute 0x40 pour en obtenir un pointeur vers un type qu'on connais bien, le FILE. Donc ce que nous retourne cette Fonction (sub_412DC6) doit etre une Struct ou une Class qui s'apparenterait à ceci : struct myFile{ BYTE m_Padding01[ 0x40 ]; FILE* m_FileHandle;}; Un peu plus de recherche s'impose donc sur cette fonction, sub_412DC6... .text:00412DC6 sub_412DC6 proc near.text:00412DC6 mov eax, offset off_439D10.text:00412DCB retn.text:00412DCB sub_412DC6 endp Elle nous retourne bel et bien un pointeur vers un espace mémoire, qui semble lui même être un pointeur d'après le nom que lui alloue notre cher IDA. Dirigeons nous vers cet espace mémoire... .data:00439D10 off_439D10 dd offset unk_476240 Et la ont peut confirmer le tout, off_439D10 est bien un pointeur vers un espace de mémoire alloué dynamiquement (unk_476240). On va s'en sortir. Donc apres quelque recherche sur la MFC et les Fichiers... (http://www.cppdoc.com/example/mfc/classdoc/MFC/AFX.H.html) class CStdioFile : public CFile{ DECLARE_DYNAMIC(CStdioFile)public:// Constructors CStdioFile(); CStdioFile(FILE* pOpenStream); CStdioFile(LPCTSTR lpszFileName, UINT nOpenFlags);// Attributes FILE* m_pStream; // stdio FILE // m_hFile from base class is _fileno(m_pStream) On découvre ceci, notre FILE*. Il se trouve dans CStdioFile qui herite de CFile qui lui meme herite de CObject. Malheureusement je n'ai pas Visual Studio pour tester ceci par la programmation mais on pourrait en déduire que en accumulant les différent membres de chaques classes et en ajoutant un pointeur vers une VTABLE on doit tomber sur nos 0x40 du tout début ce qui expliquerai notre padding et le fait que le compilateur ajoute 0x40 au pointeur de notre structure pour y lire le FILE*. Ca démontre une utilisation des MFC qui d'ailleur n'apporte pas grand chose si ce n'est de l'inutilité dans le code compilé... Cya.