Protéger un exécutable en l'encapsulant et en vérifiant l'adresse mac

Version imprimable

27/05/2008, 11h56
benj63

Protéger un exécutable en l'encapsulant et en vérifiant l'adresse mac

Bonjour,

Je cherche à faire une application me permettant :
1. De récupérer l'adresse MAC d'un ordinateur (j'ai déjà trouvé quelques threads à ce sujet, même si je ne maîtrise pas encore tout à fait le système !)
2. D'encapsuler un exécutable existant (qui n'est pas compilé avec C++ Builder).

L'idée serait de réaliser un programme qui n'exécute un exécutable (lui-même stocké en tant que ressource dans mon programme) que si l'adresse MAC correspond à celle qui est autorisée (système de licence logicielle du même type que flexlm).

Pourriez-vous m'aider, en particulier pour l'"encapsulation" (ou encore le "rajout d'une couche") à un exécutable existant ?

Merci par avance !
30/05/2008, 09h16
sat83

Je n'ai jamais joint en ressource un exécutable, mais ça dois pas être différents d'un fichier X ou Y.

Mais pour infos, ce n'est pas très compliqué de récupéré les fichiers ressources joint a un exécutable, donc dans ton cas, je pense qu'il ne sera pas trop compliqué de récupéré l'exécutable "encapsuler".
30/05/2008, 09h59
benj63

Merci pour cette réponse ; je connaissais cette méthode et je l'ai déjà employée pour un bitmap.

Cependant, mon problème est que je ne souhaite pas extraire l'exécutable (stocké dans la ressource) dans un fichier .exe puis l'exécuter, je souhaite l'exécuter directement depuis la mémoire...

J'utilise actuellement un logiciel qui permet d'ajouter une couche supplémentaire à un exécutable choisi par l'utilisateur, afin de contrôler si un dongle (clé USB de protection logicielle) est présent ou non (le contrôle s'effectue toutes les 30 secondes). Si le dongle n'est pas présent, l'exécutable est stoppé et un message d'erreur apparaît.

Je souhaiterais réaliser la même chose, sauf qu'au lieu de contrôler toutes les 30 secondes si une clé USB de protection est présente ou non, je souhaiterais simplement contrôler au démarrage de l'exécutable que l'adresse MAC est celle autorisée.

Pas simple ! Peut-être faut-il que je m'oriente dans une section parent du forum (genre assembleur !) ?
31/05/2008, 02h05
Patrick Seuret

Si j'ai bien compris, ton problème vient du fait que l'exécutable peut être arbitrairement choisi par l'utilisateur et que tu ne veux pas de version enregistrée sur le disque.

Si c'était ton programme, tu pourrais juste faire une comparaison de la MAC address et ne continuer que si elle est juste. Si tu acceptais une version sous la forme d'un fichier temporaire sur le disque, il suffirait de sauvegarder le fichier, de l'exécuter avec un CreateProcess() et de l'effacer.

Je n'ai pas d'idée pour l'instant, mais j'aimerais être sûr de tes contraintes.

pour lire une adresse mac il faut que la carte réseau soie actif !!

je te conseil de lire le nr de serie du disque dur : c'est plus simple
avec lpVolumeSerialNumber

mais sache qu'ont peux simuler une adresse physique, que cela soie pour
un disque ou une carte réseau ou un cd/dvd

disque dure : il y a une fonction setvolume ou un simple ghost du disque
ver un autre copiera tt mais aussi les nr de série.

idem pour une copie cd/dvd avec clone dvd ou même nero

pour la carte réseau dans les propriété de la carte simplement,
selon les services pack installés

voici comment je fais pour récupérer l'adresse mac des cartes réseau

. H

Code:

1
2
3
4
5
6
7
8
9
10
 
#include <windows.h>
#include <stdlib.h>
#include <iostream>
 
 bool GetAdapterInfo(int,String &);
 
 String sMAC;
 
 String oMAC;

Click Bouton dans le .cpp

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
using namespace std;
 // Get adapter list
 LANA_ENUM AdapterList;
 NCB Ncb;
 memset(&Ncb, 0, sizeof(NCB));
 Ncb.ncb_command = NCBENUM;
 Ncb.ncb_buffer = (unsigned char *)&AdapterList;
 Ncb.ncb_length = sizeof(AdapterList);
 Netbios(&Ncb);
 
 sMAC = "0";
 String sMACint;
 
 for(int i = 0; i < AdapterList.length; ++i)
 { if(GetAdapterInfo(AdapterList.lana[i], sMAC))
   {
      sMACint = sMAC.ToDouble();
      List->Items->Add(sMACint.c_str());      
   }
 }

Methode

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
bool TForm1::GetAdapterInfo(int nAdapterNum, String & sMAC)
{

  NCB Ncb;
  memset(&Ncb, 0, sizeof(Ncb));
  Ncb.ncb_command = NCBRESET;
  Ncb.ncb_lana_num = nAdapterNum;
  if (Netbios(&Ncb) != NRC_GOODRET)
  {
   char acTemp[80];
   ostrstream outs(acTemp, sizeof(acTemp));
   sMAC = acTemp;
   return false;
  }

  memset(&Ncb, 0, sizeof(Ncb));
  Ncb.ncb_command = NCBASTAT;
  Ncb.ncb_lana_num = nAdapterNum;
  strcpy((char *) Ncb.ncb_callname, "*");

  struct ASTAT
  { ADAPTER_STATUS adapt;
    NAME_BUFFER NameBuff[30];
  }Adapter;

  memset(&Adapter, 0, sizeof(Adapter));
  Ncb.ncb_buffer = (unsigned char *)&Adapter;
  Ncb.ncb_length = sizeof(Adapter);

 if (Netbios(&Ncb) == 0)
 {char acMAC[18];

  // mode decimal
  sprintf(acMAC, "%02d%02d%02d%02d%02d%02d",
  int (Adapter.adapt.adapter_address[0]),
  int (Adapter.adapt.adapter_address[1]),
  int (Adapter.adapt.adapter_address[2]),
  int (Adapter.adapt.adapter_address[3]),
  int (Adapter.adapt.adapter_address[4]),
  int (Adapter.adapt.adapter_address[5]));
  sMAC = acMAC;

  // mode hexadecimal
  sprintf(acMAC, "%02x%02x%02x%02x%02x%02x",
  int (Adapter.adapt.adapter_address[0]),
  int (Adapter.adapt.adapter_address[1]),
  int (Adapter.adapt.adapter_address[2]),
  int (Adapter.adapt.adapter_address[3]),
  int (Adapter.adapt.adapter_address[4]),
  int (Adapter.adapt.adapter_address[5]));
  oMAC = acMAC;

  return true;
 }
 else
 {char acTemp[80];
  ostrstream outs(acTemp, sizeof(acTemp));
  sMAC = acTemp;
  return false;
 }
}

:salut:

02/06/2008, 09h23
benj63

Bily.sdi >> merci beaucoup pour ta réponse, cela me met sur la voie pour le contrôle de l'adresse MAC ! Je vais tester ton code.

Citation:

Envoyé par Patrick Seuret

Si j'ai bien compris, ton problème vient du fait que l'exécutable peut être arbitrairement choisi par l'utilisateur et que tu ne veux pas de version enregistrée sur le disque.

C'est tout à fait cela : je ne possède pas les sources de l'exécutable que je souhaite protéger. Je ne peux donc pas rajouter ma protection dans les sources de cet exécutable, je suis obligé de créer un nouveau programme autour de l'exécutable...
02/06/2008, 14h35
Bily.sdi

fait un shellExecute du prog. exec et un killProcess si l'adresse mac est différente.

interdit l'ouverture du gestionnaire de tache et cache ton exec de la liste au cas ou.

@+
03/06/2008, 13h30
dz_robotix

salut,

j'ai remarqué que c'est un bonne discussion que vous avez ouvert, mais j'ai comme meme une petite question : comment interdir l'ouverture du gestionnaire de tache et cacher l'exececutable de la liste des processus en execution.

merci pour votre aide. ;)
03/06/2008, 13h38
Aurelien.Regat-Barrel

Te rends-tu compte de ce que tu demandes?

Citation:

Envoyé par dz_robotix

comment interdir l'ouverture du gestionnaire de tache

Si une appli fait cela sur mon ordi, elle va _immediatement_ a la poubelle

Citation:

cacher l'exececutable de la liste des processus en execution.

seuls les virus et autres cochonneries essayent de faire cela :roll:
03/06/2008, 14h28
dz_robotix

salut,

je n'ai rien demandé de nouveau sauf se qu'a cité bili.sdy :

""interdit l'ouverture du gestionnaire de tache et cache ton exec de la liste au cas ou.""

je ne vois pas enquoi sa te dérrange .
03/06/2008, 17h05
benj63

Personnellement, ce que propose Billy est une solution, mais je ne pourrais pas l'appliquer :

- le fait que l'exécutable soit extrait puis exécuté est réalisable, mais l'exécutable va se retrouver "déprotégé" des yeux de l'utilisateur qui pourra copier le fichier pour l'exécuter n'importe où sans que les contrôles de protection soient nécessaires...

- il m'est absolument exclu d'empêcher aux utilisateurs d'accéder au gestionnaire des tâches. Comme le dit Aurelien.Regat-Barrel, seuls les virus et autres saloperies bloquent cet élément.

Je cherche toujours une solution pour enrober l'exécutable dans un programme de protection...
03/06/2008, 19h57
pottiez

Pas forcement que les virus,
lors de mais étude j'avais en projet donnée par un prof à faire une appli qui permette aux élèves de remplir leurs questionnaires d'examen, et il fallait donc verrouiller tout le poste, y compris le gestionnaire de tache, ce qui n'est d'ailleurs pas très compliqué. Enfin il est vrai que la plupart du temps ce sont les virus qui le font et ce n'ai pas très bien vu.

coucou , me revoila,

benj63, moi j'ai fais mon propre gestionnaire de tache et j'ai bloqué celui de windows. tu peux lancer ton gestionnaire de tache via le ctrl + alt + del !
grace a cela tu cache ton propre exécutable et d'autre que tu souhaite.
tu peux le aussi le rendre invisible sur la barre de tache

Code:

1
2
 
le fait que l'exécutable soit extrait puis exécuté est réalisable, mais l'exécutable va se retrouver "déprotégé" des yeux de l'utilisateur qui pourra copier le fichier pour l'exécuter n'importe où sans que les contrôles de protection soient nécessaires...

pour cela tu fais un exec qui demande un passage de paramètre que personne ne sera et donc ne sera pas l'utiliser

Ne pas afficher son programme sur la barre des tâches

Code:

1
2
3
4
5
 
 
   HWND Owner;
   Owner = GetWindow(Form1->Handle,GW_OWNER);   
   ShowWindow(Owner,SW_HIDE);

INTERDIRE L'OUVERTURE du gestionnaire des taches

Code:

1
2
3
4
5
6
7
8
9
10
11
 
1er manière
 
a) tuer les processus taskmanager.exe  et taskmgr.exe
 
OU 
int valeur : 1 bloquer ; 0 non bloqué
 
b)reg->OpenKey("\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\System",true);
    reg->WriteInteger( AnsiString("DisableTaskMgr"),valeur);
    reg->WriteInteger( AnsiString("DisableTaskManager"),valeur);

SOUS WIN9X (plus d'actualité)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
 // Empêche CTRL + ALT + DEL sous win9x UNIQUEMENT
 
  DWORD dwNotUsedForAnything;
 SystemParametersInfo(SPI_SCREENSAVERRUNNING, TRUE, &dwNotUsedForAnything, 0);
 
//cacher son programme de la liste des tache  sous win9x UNIQUEMENT
//------------------------------------------------------------------
typedef DWORD (__stdcall *pRegFunction)(DWORD, DWORD);
HINSTANCE hKernelLib;
pRegFunction RegisterServiceProcess;
 
hKernelLib = LoadLibrary("kernel32.dll");
if (hKernelLib)
{
RegisterServiceProcess = (pRegFunction)GetProcAddress(hKernelLib, "RegisterServiceProcess");
if (RegisterServiceProcess)
RegisterServiceProcess(GetCurrentProcessId(), 1);
}

:salut:

06/06/2008, 16h00
bandit boy

Salut,
Perso je la jouerais sur 2 fronts ;).
J'enregistrerai dès la première utilisation l'adresse MAC en ressource (voir la FAQ) un code permettant l'enregistrement de variable devrait arriver.
Et j'ajouterais aussi dans la base de registre une petite annotation pour qu'il n'ai pas autant de copie avant la première execution pour palier le problème.
Voilà l'idée
06/06/2008, 16h25
Patrick Seuret

Il y a beaucoup de texte ici qui me semble un peu en dehors de besoin initial. C'est intéressant, mais il me semble que ce que tu voulais c'était exécuter un programme qui se trouve par exemple dans un segment mémoire et pas sur le disque dur.

Cela se décompose en deux questions:
1) Comment / sous quelle forme charger ce programme en mémoire (en s'assurant que le code s'exécute, donc intégrité des adresses de JMP)
2) Comment exécuter ce programme (trouver l'adresse de démarrage de la fonction Main() et démarrer cette fonction)

De mes cours en assembleur, je me souviens qu'on avait essayé de faire un "virus" qui se collait avant un exécutable (mais DOS) et qui démarrait avant de transmettre la main à cette application. Malheureusement ces souvenirs sont un peu anciens et j'ai peur que la technique ne s'applique pas très bien à l'architecture des applications 32/64 bits.

Il faudrait peut-être aller voir du côté des forums sur l'assembleur...
06/06/2008, 16h41
Lucien63

Ne pas oublier qu'il est trés facile d'extraire les ressources d'un executable.
Donc si tu le mets en ressource il faudra aussi le crypter.
07/06/2008, 13h12
Aurelien.Regat-Barrel

Une appli n'a pas a m'empecher d'utiliser le gestionnaire des taches. Ce qui me gene? Mais de quel droit une appli vient m'empecher cela? Si ca se produit, je lance dans la foulee ProcessExplorer, pskill, ou je ne sais quel autre alternative au taskmgr, zigouille le processus, et desinstalle le logiciel immediatement. Et je suis pas pres de le reutiliser...

Windows NT dispose de tout un systeme de gestion des droits qui assurent un bon niveau de securite tout en te donnant le droit d'utiliser le gestionnaire des taches.

Et alors cacher son exe de la liste des processus, c'est simplement innacceptable. Tu vas te retrouver avec une superbe publicite comme celle de Sony, et personne ne voudra plus utiliser ton soft.

C'est pas ton ordi, c'est celui de l'utilisateur, alors on ne fait pas ce qu'on veut dessus. C'est du bon sens ;)

edit: concernant les options de protections, il existe plusieurs solutions commerciales de societes commercialisees (Aladdin, ...)
09/06/2008, 09h16
bandit boy

Salut,
je pense que le but est ici d'aider la personne à faire ce qu'elle désire et non lui dire que ce qu'il veut faire n'est pas bien.
Propre à lui de ce rendre compte par l'utilisation de son appli qu'il existe d'autres solutions plus adaptées ou non.

Dans le cas où une application sera distribuée en version limitée pour la tester, et débridée pour quelque poste en fonction des droits en mettant à disposition soit d'autres applications, soit d'autres fonctions et dans le droit de chacun et souvent fait dans le cadre de "gros logiciel".

Maintenant, c'est à benj63 de faire son choix.
09/06/2008, 12h59
Aurelien.Regat-Barrel

Je pense au contraire qu'il est de notre responsabilite d'informer des limites et problemes d'une solution proposee. Il n'est pas necessaire d'attendre l'accident pour informer la personne qu'elle devait porter un casque ;)

Si je suis intervenu, c'est pour essayer de faire prendre conscience qu'on ne peut pas faire ce qu'on veut sur l'ordinateur des utilisateurs de son logiciel. Quand on essaye de proteger son gagne pain on ne se rend pas forcement compte qu'il y a des limites a ne pas franchir, et le probleme, c'est que c'est toujours l'utilisateur honnete qui trinque.
10/06/2008, 13h22
benj63

Merci à tous pour vos réponses, et effectivement comme je l'ai déjà dit précédemment, je suis absolument contre le blocage du gestionnaire des tâches et je cherche une solution alternative stockant le programme en mémoire.

D'après vos réponses, il faut que je me tourne vers le forum assembleur...
27/08/2008, 11h31
Didier Derain

A tu regardé les sources d'UPX qui fait sa. Je suis dans le même genre de situation et s'est la solution que j'ai adoptée en modifiant un peut le loader.
D.d