Y a t-il un moyen de r=E9cup=E9rer dans un programme java, la taille
m=E9moire utilis=E9e par son byte code.
Le but serait de constituer une signature du programme (j'ai pens=E9 =E0
sa taille) qui ne pourait =EAtre obtenue que par le programme lui-m=EAme
lors de son ex=E9cution.
La cerise serait que cette signature soit modifi=E9e si on essaye de le
debugger...
Le programme pourrait mettre =E0 jour une base distante lors de sa
premi=E8re connexion. Et par la suite, ne serait autoris=E9 =E0 se
connecter =E0 cette base qu'en pr=E9sentant sa sigature initiale.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fabien Bergeret
Oz wrote:
Bonjour,
Y a t-il un moyen de récupérer dans un programme java, la taille mémoire utilisée par son byte code.
Le but serait de constituer une signature du programme (j'ai pensé à sa taille) qui ne pourait être obtenue que par le programme lui-même lors de son exécution. La cerise serait que cette signature soit modifiée si on essaye de le debugger...
Le programme pourrait mettre à jour une base distante lors de sa première connexion. Et par la suite, ne serait autorisé à se connecter à cette base qu'en présentant sa sigature initiale.
Il suffit de signer le jar qui contient le programme.
La signature est automatiquement vérifiée par la jvm au moment du lancement ; elle est stockée dans le manifeste du jar. Pas de modif de la signature en cas de debut. Si c'est pour interdire le debug, il suffit de ne pas mettre l'option -g de compil
Oz wrote:
Bonjour,
Y a t-il un moyen de récupérer dans un programme java, la taille
mémoire utilisée par son byte code.
Le but serait de constituer une signature du programme (j'ai pensé à
sa taille) qui ne pourait être obtenue que par le programme lui-même
lors de son exécution.
La cerise serait que cette signature soit modifiée si on essaye de le
debugger...
Le programme pourrait mettre à jour une base distante lors de sa
première connexion. Et par la suite, ne serait autorisé à se
connecter à cette base qu'en présentant sa sigature initiale.
Il suffit de signer le jar qui contient le programme.
La signature est automatiquement vérifiée par la jvm au moment du
lancement ; elle est stockée dans le manifeste du jar.
Pas de modif de la signature en cas de debut.
Si c'est pour interdire le debug, il suffit de ne pas mettre l'option -g
de compil
Y a t-il un moyen de récupérer dans un programme java, la taille mémoire utilisée par son byte code.
Le but serait de constituer une signature du programme (j'ai pensé à sa taille) qui ne pourait être obtenue que par le programme lui-même lors de son exécution. La cerise serait que cette signature soit modifiée si on essaye de le debugger...
Le programme pourrait mettre à jour une base distante lors de sa première connexion. Et par la suite, ne serait autorisé à se connecter à cette base qu'en présentant sa sigature initiale.
Il suffit de signer le jar qui contient le programme.
La signature est automatiquement vérifiée par la jvm au moment du lancement ; elle est stockée dans le manifeste du jar. Pas de modif de la signature en cas de debut. Si c'est pour interdire le debug, il suffit de ne pas mettre l'option -g de compil
Oz
En fait le but est d'authentifier simplement au niveau d'un serveur (une base de donnée + PLSQL) le client java qui se connecte pour être sûr qu'il ne sagit pas d'un client pirate.
Le moyen (trop simpliste) utilisé actuellement pour le client est de fournir une clé au serveur qui l'authentifie. Mais il suffit de décompiler le programme pour connaître cette clé.
Je cherche un moyen simple qui permette de cacher cette clé au sein du client (l'idéal serait que cela soit une signature qui ne puisse être calculée que par le programme exécuté) et qui ne soit pas trop facile à trouver en décompilant le code. Je ne veux pas non plus mettre en place les systèmes de sécurisation par certificat (lourd à mettre en place au niveau du serveur...)
Pour ce qui est du débug je ne peut pas empêcher un développeur de prendre le code décompilé et de le debugger avec l'option -g
En fait le but est d'authentifier simplement au niveau d'un serveur
(une base de donnée + PLSQL) le client java qui se connecte pour être
sûr qu'il ne sagit pas d'un client pirate.
Le moyen (trop simpliste) utilisé actuellement pour le client est de
fournir une clé au serveur qui l'authentifie. Mais il suffit de
décompiler le programme pour connaître cette clé.
Je cherche un moyen simple qui permette de cacher cette clé au sein du
client (l'idéal serait que cela soit une signature qui ne puisse être
calculée que par le programme exécuté) et qui ne soit pas trop
facile à trouver en décompilant le code.
Je ne veux pas non plus mettre en place les systèmes de sécurisation
par certificat (lourd à mettre en place au niveau du serveur...)
Pour ce qui est du débug je ne peut pas empêcher un développeur de
prendre le code décompilé et de le debugger avec l'option -g
En fait le but est d'authentifier simplement au niveau d'un serveur (une base de donnée + PLSQL) le client java qui se connecte pour être sûr qu'il ne sagit pas d'un client pirate.
Le moyen (trop simpliste) utilisé actuellement pour le client est de fournir une clé au serveur qui l'authentifie. Mais il suffit de décompiler le programme pour connaître cette clé.
Je cherche un moyen simple qui permette de cacher cette clé au sein du client (l'idéal serait que cela soit une signature qui ne puisse être calculée que par le programme exécuté) et qui ne soit pas trop facile à trouver en décompilant le code. Je ne veux pas non plus mettre en place les systèmes de sécurisation par certificat (lourd à mettre en place au niveau du serveur...)
Pour ce qui est du débug je ne peut pas empêcher un développeur de prendre le code décompilé et de le debugger avec l'option -g
Fabien Bergeret
Oz wrote:
En fait le but est d'authentifier simplement au niveau d'un serveur (une base de donnée + PLSQL) le client java qui se connecte pour être sûr qu'il ne sagit pas d'un client pirate.
Le moyen (trop simpliste) utilisé actuellement pour le client est de fournir une clé au serveur qui l'authentifie. Mais il suffit de décompiler le programme pour connaître cette clé.
Je cherche un moyen simple qui permette de cacher cette clé au sein du client (l'idéal serait que cela soit une signature qui ne puisse être calculée que par le programme exécuté) et qui ne soit pas trop facile à trouver en décompilant le code. Je ne veux pas non plus mettre en place les systèmes de sécurisation par certificat (lourd à mettre en place au niveau du serveur...)
Pour ce qui est du débug je ne peut pas empêcher un développeur de prendre le code décompilé et de le debugger avec l'option -g
Il n'a aucun moyen fiable d'authentifier une application.
Meme la signature de jar ne convient pas car il suffit de decompiler le jar, le modifier et l'executer non pas en jar, mais en .class, et zou, le tour est joue. La seule chose que l'on puisse authentifier, c'est un utilisateur
Oz wrote:
En fait le but est d'authentifier simplement au niveau d'un serveur
(une base de donnée + PLSQL) le client java qui se connecte pour être
sûr qu'il ne sagit pas d'un client pirate.
Le moyen (trop simpliste) utilisé actuellement pour le client est de
fournir une clé au serveur qui l'authentifie. Mais il suffit de
décompiler le programme pour connaître cette clé.
Je cherche un moyen simple qui permette de cacher cette clé au sein du
client (l'idéal serait que cela soit une signature qui ne puisse être
calculée que par le programme exécuté) et qui ne soit pas trop
facile à trouver en décompilant le code.
Je ne veux pas non plus mettre en place les systèmes de sécurisation
par certificat (lourd à mettre en place au niveau du serveur...)
Pour ce qui est du débug je ne peut pas empêcher un développeur de
prendre le code décompilé et de le debugger avec l'option -g
Il n'a aucun moyen fiable d'authentifier une application.
Meme la signature de jar ne convient pas car il suffit de decompiler le
jar, le modifier et l'executer non pas en jar, mais en .class, et zou,
le tour est joue.
La seule chose que l'on puisse authentifier, c'est un utilisateur
En fait le but est d'authentifier simplement au niveau d'un serveur (une base de donnée + PLSQL) le client java qui se connecte pour être sûr qu'il ne sagit pas d'un client pirate.
Le moyen (trop simpliste) utilisé actuellement pour le client est de fournir une clé au serveur qui l'authentifie. Mais il suffit de décompiler le programme pour connaître cette clé.
Je cherche un moyen simple qui permette de cacher cette clé au sein du client (l'idéal serait que cela soit une signature qui ne puisse être calculée que par le programme exécuté) et qui ne soit pas trop facile à trouver en décompilant le code. Je ne veux pas non plus mettre en place les systèmes de sécurisation par certificat (lourd à mettre en place au niveau du serveur...)
Pour ce qui est du débug je ne peut pas empêcher un développeur de prendre le code décompilé et de le debugger avec l'option -g
Il n'a aucun moyen fiable d'authentifier une application.
Meme la signature de jar ne convient pas car il suffit de decompiler le jar, le modifier et l'executer non pas en jar, mais en .class, et zou, le tour est joue. La seule chose que l'on puisse authentifier, c'est un utilisateur
barilla
c'est possible de controler quel code est execute avec JAAS, mais il faut avoir le controle de la machine cliente pour changer les parametres de la JVM, et rendre impossible l'install de jvm parasites ... c'est la reponse officielle java/jdk sun je crois.
une autres solution, mais pas standard : avoir un classloader customize qui charge les classes depuis le serveur apres s'etre logge, en memoire seulement.
et la ca va etre plus complique de recuperer les class pour les changer ! (mais possible). et c'est pas tres complique a faire ...
paul.
c'est possible de controler quel code est execute avec JAAS,
mais il faut avoir le controle de la machine cliente
pour changer les parametres de la JVM,
et rendre impossible l'install de jvm parasites ...
c'est la reponse officielle java/jdk sun je crois.
une autres solution, mais pas standard :
avoir un classloader customize qui charge les classes depuis
le serveur apres s'etre logge, en memoire seulement.
et la ca va etre plus complique de recuperer les class
pour les changer ! (mais possible).
et c'est pas tres complique a faire ...
c'est possible de controler quel code est execute avec JAAS, mais il faut avoir le controle de la machine cliente pour changer les parametres de la JVM, et rendre impossible l'install de jvm parasites ... c'est la reponse officielle java/jdk sun je crois.
une autres solution, mais pas standard : avoir un classloader customize qui charge les classes depuis le serveur apres s'etre logge, en memoire seulement.
et la ca va etre plus complique de recuperer les class pour les changer ! (mais possible). et c'est pas tres complique a faire ...
paul.
Oz
Cette solution me plait bien.
Si quelqu'un touve des examples pour transferer un jar depuis une base de donnée et le charger en mémoire .... je suis preneur
Cette solution me plait bien.
Si quelqu'un touve des examples pour transferer un jar depuis une base
de donnée et le charger en mémoire .... je suis preneur
