Discussion :

[Madmaxx18]

Bonjour,

Je lance une dll que j'ai faite en C++ avec Python.

La fonction testAppelant contenue dans la dll est déclarée comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 extern "C" __declspec(dllexport) void testAppelant()

Dans cette fonction testAppelant j'aimerai identifier le module .py qui a chargé la DLL.

J'ai essayé avec GetModuleFileName mais ça me donne juste le nom de l'interpréteur Python.exe

Est ce que vous avez déjà fait ça ? Est ce possible?

D'avance merci pour toutes pistes à suivre

[TheGzD]

J'ai peur que ça te donne les mêmes résultat que précédemment mais tu peux peut-être essayer ceci.

Sinon j'ai bien peur qu'il faille que l'information soit donné par l'appelant à ta DLL via un point d'entrée par exemple.

[Médinoc]

J'ai bien peur que ce soit impossible. Surtout pour du code interprété.

Et même pour du code compilé, on ne peut pas faire confiance à l'adresse de retour (sauf en .Net/Java).

[Mat.M]

Salut totalement impossible parce que Python c'est du code interprété...
et même en faisant une énumération des modules/dll chargés en mémoire par Windows cela n'apportera rien de plus.

Eventuellement en connaissant l'adresse mémoire de l'interpréteur Python , de cette adresse tu peux essayer de parcourir la mémoire et tenter de trouver s'il ya la chaine de caractère .py

[Madmaxx18]

Merci à tous pour vos réponses.

Merci TheGZD pour le code fourni mais j'avais fait un truc du genre mais ça ne donne pas beaucoup plus que Python.exe c'est à dire pas grand chose.

En fait c'était pour faire de l'authentification donc si c'est le programme qui donne en entrée l'info c'est pas terrible comme principe d'authentification...

J'ai trainé un peu dans les adresses mémoires mais c'est vraiment démoralisant de parcourir la mémoire à la main ! Autant trouver une aiguille dans une botte de foin.

[jblecanard]

Hello

Sécuriser un code de sorte que son appelant soit identifié est extrêmement difficile et est une problématique qui n'a pas de solution canonique. Le mieux à faire étant d'utiliser le système d'authentification fourni par l'os que tu utilises, amha.

[Médinoc]

Si c'est pour de l'authentification, en temps normal je te référerais à nouveaux à mes deux liens.

Mais comme il s'agit d'un langage interprété, je te conseille de regarder s'il n'y a pas des mécanismes dans Python même: Un langage interprété ne peut pas falsifier sa pile d'appels comme un langage natif (voir .Net). Par contre, il faudrait que toutes les DLLs puissent être bloquées par l'interpréteur, car dès qu'on permet à du code natif non-sûr de s'exécuter, la sécurité tombe à l'eau.

[koala01]

Salut,

De toutes manières, et même si cet avis m'est personnel, j'aurais tendance à dire que le but d'une dll est de fournir un certain nombre de services, et qu'il n'est donc pas de son domaine de vérifier qui fait appel à ces services.

Tu ne peux, en effet, même pas être sur que ta dll sera exclusivement utilisée avec python, car, de prime abord, il n'est pas exclu qu'elle présente suffisemment d'intérêt pour être utilisée dans un projet pour lequel tu n'aurais sans doute jamais osé imaginer qu'elle le serait

En outre, il faut garder en tête le fait que le but même des dll est... de fournir une partie "indépendante" de l'application qui l'utilisera: Qu'une dll dépende (pour la fourniture de certains services) d'autres dll n'est pas impensable, mais il ne me semble vraiment pas cohérent de forcer la dépendance de la dll avec... l'application qui l'utilise

[jblecanard]

mais il ne me semble vraiment pas cohérent de forcer la dépendance de la dll avec... l'application qui l'utilise

Ca dépend, si ton application se compose de plusieurs exécutables, il peut être intéressant de les faire se partager une DLL.

[koala01]

Ca dépend, si ton application se compose de plusieurs exécutables, il peut être intéressant de les faire se partager une DLL.

Justement...

Ce sont plusieurs exécutables qui utilisent la dll, et non la dll qui doit dépendre de plusieurs exécutables (hormis des dll de dépendance, qui, de toutes façons, sont indépendantes de la dll en question )

Encore une fois, la dll fournit un certain nombre de service, peut, pourquoi pas, utiliser des fonctions et des structures définies "en dehors", mais qui ne sont, en aucun cas, des fonctions et des structures propres à l'application (exécutable) qui fait appel à la dll

[jblecanard]

Encore une fois, la dll fournit un certain nombre de service, peut, pourquoi pas, utiliser des fonctions et des structures définies "en dehors", mais qui ne sont, en aucun cas, des fonctions et des structures propres à l'application (exécutable) qui fait appel à la dll

Ok, je suis d'accord, ce serait une erreur de design. De toute façon, ça ne compilerai même pas, puisque la dll doit être compilée et linkée avant l'exécutable.