Discussion :

[ZCode]

Quelle technique utiliser pour obfusquer une variable qui sert de compteur afin qu'elle ne soit pas facilement repérée par un hacker ?

Merci.

[Alp]

Tu pourrais détailler un peu plus le contexte ?
Parce que bon un hacker qui va juste allé incrémenter une fois de trop un compteur dans un programme...

[ZCode]

Le contexte ? Eh bien je veux que en version démo mon soft soit limité à un certain nombre d'itérations. Si je fais un simple

n++; if (n>100) {break;}

il est facile de repérer en mémoire la variable qui s'incrémente et ensuite patcher le code pour faire sauter l'incrémentation ou faire sauter le if. Bref, le b-a ba du hacking. Je veux donc compliquer un peu les choses.

[Aszarsha]

Si je cherchais à cacher le fonctionnement, j'utiliserai des appels de fonctions polymorphiques plus qu'un simple branchement. Le hacker peut toujours trouver l'emplacement mémoire qui fait l'appel par déréférencement, avant qu'il ne trouve la bonne adresse relative sur laquelle brancher, il va s'en passer du temps...

[Klaim]

Est-ce qu'utiliser plusieurs "objets" ayant différents états, avec un ensemble d'état correspondant a la fin du compte rendrais les choses plus difficile a lire aussi?

[Médinoc]

Et aussi, obfusquer le compteur en le stockant XOR quelque chose...

[ZCode]

Merci pour vos réponses.

Si je cherchais à cacher le fonctionnement, j'utiliserai des appels de fonctions polymorphiques plus qu'un simple branchement. Le hacker peut toujours trouver l'emplacement mémoire qui fait l'appel par déréférencement, avant qu'il ne trouve la bonne adresse relative sur laquelle brancher, il va s'en passer du temps...

Hum, oui, je vais y réfléchir, merci pour l'idée.

Est-ce qu'utiliser plusieurs "objets" ayant différents états, avec un ensemble d'état correspondant a la fin du compte rendrais les choses plus difficile a lire aussi?

Pas bête !

Et aussi, obfusquer le compteur en le stockant XOR quelque chose...

effectivement le résultat d'une encryption xor n'est pas linéaire.


De mon côté j'ai trouvé la bibliothèque OBCODE-1.0.5 ici : http://echelon.pl/pubs/

ou alors utiliser une fonction non linéaire.

[loufoque]

Quelle technique utiliser pour obfusquer une variable qui sert de compteur afin qu'elle ne soit pas facilement repérée par un hacker ?

Le seul moyen d'empêcher cela est d'empêcher l'exécution de programmes non signés.
C'est-à-dire faire du Trusted Computing.

[gnto]

n++; if (n>100) {break;}

Quand le cracker va désassembler ton binaire, et qu'avec quelques outils, connaitre l'endroit de la dite séquence de saut, il n'aura plus qu'a inverser le saut conditionnel

[Twindruff]

Pour moi c'est plutôt le test qu'il faut obfusquer, parce que pour cracker, le plus simple est de partir du message d'erreur et de regarder quelle en est l'origine et on va forcément tomber sur ce test (en se fichant de comment on en est arrivé là).

[ZCode]

Oui, oui, je suis bien d'accord que le 'if' est un gros point faible. Je vais essayer de mettre des instructions indispensables dedans.

[Klaim]

Dans ce cas, autant en faire une conséquence de variation d'état des données? J'imagine que c'est possible mais difficile a concevoir.

[ZCode]

Tu veux dire imbriquer le contenu du 'if' avec ce qui se trouve à l'extérieur peut être ?

Par ce que "en faire une conséquence de variation d'état des données" c'est justement le propre d'un 'if'...

[ThePiiX]

Bon je suis pas spécialiste des cracks et autres désassemblages, mais si je voulais protéger un truc, je le rendrai indispensable à l'exécution correcte du programme, si ils sont modifiés le programme tournera pas (ou mal )

en l'occurrence un truc tout con rends ton problème incraquable.

Code :

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

1
2
3
4
5
6
7
int tab[100];
 
n=-1;
i = 14064//clé aléatoire bien sur
tab[i - 14064] = true;
i++;
n++;if(tab[n] == true){break;}

Craquer n ne suffit plus, définir que i fait partie du système de sécurité devient difficile et craquer la condition du if provoque une seg fault ...

[gnto]

Craquer n ne suffit plus, définir que i fait partie du système de sécurité devient difficile et craquer la condition du if provoque une seg fault ...

seg fault et en quoi une inversion de l'égalité provoque un segfault

[ThePiiX]

Code :

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

1
2
3
4
5
6
7
n = 99;
 
n++;
 
n = 100;
 
(tab[100] != true)

index out of array bounds ... (au pire si la condition est rappelée if(1), tab[i - 14064] plantera à la place ...)

[Klaim]

ZCode> Je pensais à un moyen de faire varier des valeurs de manières a ce que la conséquence induite soit le blocage du jeu. Plus il y aurait de variables plus ça serait complexe d'arriver a ce résultat mais aussi de le cracker.


Maintenant, je vois bien le concept, mais c'est difficile d'imaginer une imlpémentation. Peut être un exemple simple serait ce qu'ont fait certains jeux par le passé : la qualitée de controle du personnage joué se dégrade avec le temps par exemple, de manière irreversible. Attention aux conséquences sur le joueur par contre - toujuors néfaste.
Si tu ajoutes à ça un message dont la valeur alpha est dépendente dans le temps d'une fonction exponentielle, tu peux rendre ce message visible au bout d'un certain temps sans if.

Je ne suis pas expert, mais pas mal de mecs expérimentés disent aussi que l'idéal d'une protection, si il doit y en avoir une, c'est d'obliger le cracker a jouer longtemps pour arriver a voir la protection. De cette manière tu te fais un client potentiel.

[nicroman]

Haaaa... donc on parle d'un jeu...
Dans ce cas, il ne sert à rien d'obfusquer la valeur (c'est se prendre le choux pour rien, et perdre son temps face à des milliers de pseudo-hackers qui eux ont tout leur temps, puisqu'il ont rien d'autre à f...re).

Par contre, avoir un système que vérifie le comportement de la valeur et adapte le jeu en conséquence (voir crashe de temps en temps), ça c'est bien plus difficile à vérifier.

Exemple: Une valeur "gold" qui, si elle augmente brusquement alors qu'aucun évenement pouvant en générer n'ai eu lieu, fait que plus aucun marchand n'accepte d'acheter/vendre... ou des ennemis plus nombreux/aggressifs...

Pour ton idée d'utilisations limitée... c'est pareil...
Stocke les valeurs à plusieurs endroits différents, avec des xor différents (par exemple avec le code lui-même), et vérifie leur cohérence.... Si pas cohérent, alors fait adopter au programme une attitude... mesquine (surtout ne dit pas tout de suite 'espece de hacker', il vaut mieux lui faire perdre 2h à comprendre que ca ne marche pas, plutôt que lui réveler tout de suite qu'on l'a repéré).