[C] Comment protéger la mémoire ???

[Sh4dows]

io,

Récemment (hier), j'ai joué à Dead Island 2 et je me suis dis pourquoi ne pas essayé d'ajouter de la money, de l'xp, des munitions etc..

J'ai alors pris "Cheat Engine" puis bien entendu, avec 2 petites recherches je me suis retrouvé avec full level, argent etc.. avant même d'avoir terminé le prologue Bref de l'édition mémoire pour ceux qui ne l'avaient pas encore compris.

J'ai fais quelques tests, par exemple celui ci :

Code C :


#include <stdio.h>
#include <stdlib.h>

int main()
{
    int i;

    i = 0;
    while(i < 10){
        i += 1;
        printf("Vous gagnez 1 point ! (%d/10)\n", i);
        system("Pause");
    }
    return 0;
}
 

Résultat :


On remarque que ma variable est supérieur à 10 logique puisque je viens de l'éditer 42 => +1, le problème est que mon programme fais comme si cela n'était pas le cas ! J'me retrouvre avec un genre de while(1) au lieu du "i<10" ..

Du coup, savez vous-pourquoi cela fais ça ?
Et ensuite est il possible de bloquer l'édition mémoire (windows/linux) sans avoir recours un un truc du genre "tuer le processus cheat engine"

Merci d'avance

[b0fh]

Hello,

Pour être certain il faudrait regarder la sortie asm du compilo, il y a toutes sortes d'optimisations qui pourraient causer un problème comme ça.

Pour se protéger de l'édition mémoire, ça dépend qui est l'adversaire. Tu peux essayer d'empêcher les debuggers de s'attacher a ton processus, mais il restera toujours possible de tricher, par exemple en faisant tourner le programme dans une VM avec un debugger attaché sur la VM.

En théorie, avec les puces TCPA présentes dans les machines récentes, il est possible de stocker des clefs de chiffrement dedans, et d'avoir un mécanisme de DRM avec lequel le programme sera chiffré, et qui ne pourra être déchiffré que si l'OS et le bootloader sont d'origine. Evidemment c'est supposer que l'OS et le bootloader sont exempts de bugs, ce qui est complètement irréaliste. Mais ça permettrait quand même de s'assurer que le programme ne tourne pas dans une VM et qu'il n'y a pas eu d'attaque low-level sur l'intégrité de l'OS pour contourner sa sécurité.

PS y'a pas besoin de cheater à Dead Island, il est déja assez facile comme ça vous les jeunes vous savez pas ce qu'est un jeu réellement difficile </troll>

[sakiir]

Je e suis mis pas mal a l'edition memoire , au cheating etc ..
Et pour ca , c'es le programme qui peut verifier la memoire de lui meme.
En Jeu video c'est anti-cheat , qui vérifie les nom de processus etc ..
Il y a plusieurs sécurité differente

[OverDreams]

Cheat Engine modifie les adresses de la mémoire tu peux pas protéger parfaitement comme ça il me semble

[supersnail]

Ben si, tu peux par exemple foutre les variables d'état du jeu dans une structure, calculer un checksum de ce qui est contenu dans la structure à chaque "tour", et si le checksum diffère de celui de la fin du tour précédent, on détecte un cheat

(Bon la protection n'est pas parfaite, étant donné qu'on peut aussi modifier le checksum, mais bon faut avoir des compétences en RE pour comprendre comment est foutu l'algo de calcul du checksum). Ensuite on peut toujours coupler ça à des anti-debug/recherche de process, ou pour les plus hardcore, aller directement hooker les APIs de debug au niveau du kernel (même si ça devient de plus en plus difficile avec PatchGuard/les drivers qui doivent être signés sous win7 x64).

Anyway, comme le dit b0fh y'a toujours la possibilité de faire tourner le bordel dans une VM & de manipuler la mémoire de la VM directement (ou d'agir au kernel debugger, mais là c'est sortir la bombe atomique pour tuer une mouche)

[Sh4dows]

Merci pour vous réponses, c'est très intéressant par contre un problème se pose !

...si le checksum diffère de celui de la fin du tour précédent, on détecte un cheat..

Cela fonctionne il en pratique car déjà en faisant un truc du genre :

Code C :


while (i < 10)
{
     i ++;
}
 

Puis en modifiant ma variable i (Cheat Engine > on lui attribut 42 comme valeur par exemple), et bien je ne peux plus sortir de ma boucle !!!

Le programme fais comme si j'avais ceci :

Code C :


while (1){
     i ++;
}
 

Pourtant i (vaut 42) et est bien plus grand que 10 ...
Et là je me demande pourquoi cela fais ça ?

@supersnail : Ce que je veux dire, c'est comment tu veux faire un checksum d'une variable qui dit toujours "Cey bon" et ceci peut importe les opérateurs de comparaison ??

Je vous invite à essayé pour vous rendre compte de la chose ><

[Yttrium]

Si tu regarde le code en assembleur avec ollydbg ou autre tu comprendra surement pourquoi

[Machin]

Oui moi je pense que ton compilo a put, par exemple, déplier ta boucle. Du coup meme en mettant 42 à un moment, il va faire le contenu de la boucle 10 fois tout de même (tu as testé pour vérifier si c'etait equivlant à un while(1) ou juste un nombre de boucle fixe ?)

[Sh4dows]

C'est équivalent à un while(1) !!!

[Machin]

bah alors faut regarder le code ASM pour comprendre pourquoi.

[Sh4dows]

Si tu regarde le code en assembleur avec ollydbg ou autre tu comprendra surement pourquoi Wink

bah alors faut regarder le code ASM pour comprendre pourquoi.

J'vais fais ça alors

---

J'ai compris du coup

Voici le code ASM de la boucle :

00401B9C |> 895C24 04 /MOV DWORD PTR SS:[ESP+4],EBX ; |||
00401BA0 |. C70424 7430400>|MOV DWORD PTR SS:[ESP],test.00403074 ; |||ASCII "Vous gagnez 1 point ! (%d/10)
"
00401BA7 |. E8 44FFFFFF |CALL <JMP.&msvcrt.printf> ; ||\printf
00401BAC |. C70424 9330400>|MOV DWORD PTR SS:[ESP],test.00403093 ; ||ASCII "Pause"
00401BB3 |. E8 40FFFFFF |CALL <JMP.&msvcrt.system> ; |\system
00401BB8 |. 43 |INC EBX ; |
00401BB9 |. 83FB 0A |CMP EBX,0A ; |
00401BBC |.^75 DE \JNZ SHORT test.00401B9C ; |

Quand on dit, "tant que i < 10", le compilo lui traduit ça en : tant que ma variable (ici registre EBX) n'est pas égale à 10, je dois reboucler.

Code ASM :


CMP EBX,0A ; On compare EBX avec 10
JNZ SHORT test.00401B9C ; Si comparaison diffère on reboucle
 

Du coup, si par malheur, notre variable passe a une valeur supérieur à 10 (0A ou A), la condition ne pourra jamais être remplie et le programme continuera à jump indéfiniement. D'ou le while (1) ..

Merci à tous pour vos réponses