Garder un programme en memoire en permanence

Bonjour,

Je ne suis pas sur si ce sujet a sa place ici ou alors plus dans le sous forum threads et processus.
Si je me trompe, je m'en excuse d'avance.

Alors voila mon probleme.
J'ai developpe en c++/opencv un programme qui extrait des signatures d'images.
Ce programme est plutot sensible, et on voudrait eviter un maximum le reverse ingeneering.

Mon boss a dans l'idee de telecharger via VPN la dll principale a chaque redemarage de l'ordinateur, la garder en memoire et la supprimer du disque dur aussitot.
Comme il faut traiter un nombre consequent d'images, on ne peut pas la telecharger pour chacune des images. Mais plutot une fois par session ou dans le genre.
Il est aussi necessaire de pouvoir traiter plusieurs images en meme temps (plusieurs copies du soft en memoire).

Si je touche ma bille en algorithmes de vision. En c++ et processus, ce n'est pas trop le cas.
Ma question est donc de savoir ce que je dois apprendre pour regler mon probleme :
Lancer le code et le garder en memoire en permanence.
Avoir plusieurs copies qui permettent de traitrer plusieurs image en meme temps (une copie par coeur -1).

Si certains points ne sont pas clair, je preciserais.

Je ne demande pas vraiment une solution toute faite, mais plus une aide pour savoir ou regarder.

Merci d'avance.

Bonjour !

Etes-vous sur que quelqu'un aura un intérêt à essayer de faire du reverse engineering sur votre DLL pour essayer de cracker votre algorithme ? Parce que si une personne a envie de savoir comment il marche, vous pourrez faire ce que vous voulez, elle y arrivera.

Hello

En effet, ne pas garder la DLL sur la machine ne suffit pas pour la protéger.

Ceci étant dit, il est possible de réaliser cela en utilisant un modèle client/serveur : le serveur, lancé localement, charge la DLL et peut être contacté via un protocole simple (écrire un JSON sur une socket par exemple, ou un fichier "pipe"). Ensuite, il forke ou lance un thread pour traiter l'image. Il suffit de laisser le processus serveur démarré. Un logiciel client, qui ne contient pas le code métier mais juste le code pour contacter le serveur, peut être distribué et utilisé comme un soft classique.

Bonjour,

ALors moi, je n'en suis pas sur.
Mon patron par contre a vraiment peur de ca.
Pour faire cours, nous sommes une petite compagnie. Ce genre de signature d'image est utile pour de grosses grosses compagnies.
Nous avons un brevet sur cet algorithme. Mais si du reverse engineering etait fait, il serait illusoire de defendre notre brevet devant les tribunaux.

Je sais bien qu'il est en theorie impossible d'empecher ce genre de chose. Le but est ici de le rendre le plus difficile possible.

Petite precision, les machines qui lanceront notre algo sont en petit nombre (on va dire une centaine, un peu plus avec le temps eventuellement).
Chaque machine est unique, et leur access est restreint. Voler une machine chez le client est mission impossible.

Citation:

---

Envoyé par jblecanard

Hello

En effet, ne pas garder la DLL sur la machine ne suffit pas pour la protéger.

Ceci étant dit, il est possible de réaliser cela en utilisant un modèle client/serveur : le serveur, lancé localement, charge la DLL et peut être contacté via un protocole simple (écrire un JSON sur une socket par exemple, ou un fichier "pipe"). Ensuite, il forke ou lance un thread pour traiter l'image. Il suffit de laisser le processus serveur démarré. Un logiciel client, qui ne contient pas le code métier mais juste le code pour contacter le serveur, peut être distribué et utilisé comme un soft classique.

---

Je ne suis pas sur de comprendre votre proposition.
Je ne suis pas non plus familier de Json.
Vous avez par hasard un lien decrivant ce genre de process ?

Merci d'avance.

En gros, c'est un "web-service".

Tu envoies une requete (avec le protocole qui te plait) au serveur, qui renvoie la réponse.

Par exemple, tu envoie une requete http avec l'image (comme un formulaire html avec un fichier le ferait), et le serveur répond avec l'image signée.

Si le serveur n'est pas installé chez le client, c'est gagné, il n'a aucun moyen de recevoir l'algo
Ce procédé est doublé d'un autre avantage: vous pourrez mettre en place un système de licences renforcé.

Merci l'eternel pour la reponse.

Comme dit precedement, envoyer l'image sur un serveur distant est hors de question. Trop d'images, trop de bande passante.
Nous avions pense a cela, mais c'est impossible en pratique.
De plus les 200 images/minute sont par machine chez le client. On peut avoir 3 ou 4 machines en // chez le client.

Sinon, je viens de decouvrir les ram-disk et le protocol tmpfs sur linux.
Je n'ai pas encore trop lu, mais cela semble une bonne alternative. Si vous avez des experiences avec ca, je suis aussi prenneur.

Merci.

Il se peut que je me trompe, mais sous windows, tu peux pas effacer/modifier une dll à chaud. Par contre sous linux tu peux effacer un .so ou même un executable pendant l'execution le process s'en fout
Il y a des logiciels qui permettent d'offuscer le code en renommant les variables et fonctions avec des noms qui ne veulent rien dire.
Si le mec voit dans la dll qu'il y a une fonction ComputeGradient qui est appelé il devine ce que tu fais avec (c'est plus simple que lire l'assembleur) si il voit une fonction AAAAAA(aa, a, aaa) qui est appellé ce sera plus simple de ré-implémenter un nouvel algo qui fait la mêne chose plutôt que d'essayer de comprendre l'assembleur.

En fait, tu n'as que deux solutions.
Ou bien le code est présent à un moment donné sur la machine client, ou il ne l'est pas.
S'il ne l'est pas, il faut bien que tu aille le faire exécuter ailleurs.

S'il l'est, tu ne peux pas empècher qu'on le trouve.
Comment?

En utilisant un traceur qui te dis quelle dll est chargée, mettre en pause le processus l'appelant, et inspecter la RAM.
C'est raisonnablement facile à faire, et ce, avec des applications utilisées depuis plus de 20 ans pour modifier des jeux.

Il existe notamment une application dédiée à la modification de texture directx (texmod si mon souvenir est bon)

Et tu ne peux rien faire pour l'empêcher, parce que le code doit être à la disposition du processeur, qui ne connait que la RAM.

@ __zzxy__
l'obfuscation n'existe pas en C++, le code compilé ne contient déjà pas les noms de variables, quand il n'est pas compilé avec les informations de debug.
Et si tu rajoutes les options d'optimisations, c'est suffisant pour tout pourrir.

L'assembleur est terriblement incompréhensible.

Merci l'eternel.

Je comprends bien la problematique.
En fait les pc clients, sont dans un environnement securise. Il s'agit de lignes de productions hautement reglementees.
Les reseaux sont en principe securise, donc pas d'access a craindre de l'exterieur.
Il est impossible (en principe du moins) d'ouvrir les armoires ou se trouvent les machines pour avoir un access physique a la machine : brancher un clavier, faire une copie du disque dur ...

Il serait eventuellement possible de voler la machine pour avoir une copie de la DLL/.so. Notre but etait donc de ne pas avoir la DLL sur un disque dur/sdd, mais uniquement en RAM afin que chaque coupure de courant la fasse "disparaitre".

Plus je regarde ramfs, plus je me dit que c'est ce qu'il nous faut.

En effet, ca peut.

ramfs est totalement transparent au programme en lui même.

Pourquoi se prendre la tête ?
Il suffit de bitlocker les disques, point bar.

http://windows.microsoft.com/fr-fr/w...ures/bitlocker

Merci a tous pour vos reponses.