Sujet n°14368
Posté par Gareal le 17 Jan - 18:53 (2015)
Titre : Protéger mon projet des gens malhonnêtes
Bonjour à tous !

Je souhaite protéger mon projet c'est-à-dire que je ne veux pas que les gens puissent ouvrir le dossier source et modifier mon projet ou pire se l'attribuer.
Je sais que POKEMON GEMME utilise un logiciel pour le protéger et je veux faire de même pour mon projet.

Pouvez-vous m'aider, me conseiller un logiciel de ce type ?
Car oui, j'ai trouvé un logiciel qui permet d'ouvrir le fichier RXPROJ et je voudrais donc éviter cela...
Merci d'avance.
Gareal

Posté par Schneitizel le 17 Jan - 19:01 (2015)
Gareal cherche le Saint Graal...
Tu sais même Gemme n'est pas inviolable, toute a l'heure, quelqu'un a eu acces aux fichiers ^^'
Rien ne protegera jamais a 100% ton jeu, c'impossible

Posté par Nuri Yuri le 17 Jan - 19:52 (2015)
C'est un truc que j'ai codé à la main en fait, je crypte Pokémon Gemme avec un projet RPG Maker XP en utilisant un encodeur qui a été codé en C++
Le truc c'est qu'il y a des failles de sécurités partout, par exemple j'ai oublié d'enlever une petite ligne de code à la con, ça fait que Gemme est vulnérable à des attaques d'injections de données. (Qui peuvent potentiellement permettre à l'attaquant de décrypter Gemme).

Après, un projet RPG Maker XP ne sera jamais protégé pour des raisons toute bêtes :
La sécurité en Ruby n'existe pas, Ruby est un langage de programmation interprété et non compilé nécessitant la compilation des scripts. Si tu veux avoir un projet safe qui ne se fait pas voler ses scripts ou ton travail, il faut au minimum que le projet soit entièrement codé en C/C++ ou dans d'autres langages de bas niveau non interprétés. (Java, C#, lua, Ruby, JS, etc.. t'oublies.)

Bref, c'est la chose la plus problématique :p

Posté par Gareal le 17 Jan - 20:33 (2015)
Ah ! Bon et bien tant pis ^^

Merci pour vos réponses rapides !!

Posté par Girakoth le 18 Jan - 00:54 (2015)
Et puis bon, je doute que ça intéresse beaucoup de monde de s'approprier un projet de fangame Pokémon. En tout cas ça reste des cas très isolés.

Posté par Nuri Yuri le 18 Jan - 11:14 (2015)
Doute beaucoup alors :p
Quand un projet a des scripts intéressants qui fonctionnent mieux que ce qui traine dans la section Scripts ça intéresse. Après tu ne dois probablement pas te rendre compte du nombre de projets qui commence à partir d'un autre projet décompilé à coup de RGSSAD_WX ou RGSSAD Decrypt puis qui se sont rangés sur un starter kit plus classique (parce qu'à l'origine ils ne savaient pas spécialement que c'était fait à l'aide d'un SK, pourtant c'est écrit dans le fichier crédits.txt ou au lancement du jeu.)

Bref. La peur du Hack c'est tout à fait normal, cela dit Gareal, tu ne peux pas empêcher le viole de ton projet mais tu peux le ralentir avec divers systèmes et divers méthodes, si tu veux que ton projet soit légèrement plus safe tu dois respecter ces points là :
  1. La variable $RGSS_SCRIPTS doit être effacé une fois que tous les scripts sont chargés en mémoire. Il faut aussi faire un GC.start derrière pour bien désallouer les strings et permettre à Ruby d'écrire par dessus les scripts lisible en mémoire. C'est pas toujours efficace car il y a des traces un peu partout mais ça évite déjà l'extraction des scripts complet par la lecture bête et méchante de la mémoire. (Faites le test, vous ouvrez Cheat Engine, par exemple sur Pokémon Origins, vous cherchez "class Pokemon" et vous ouvrez le memory viewer à ce pointeur, le script est entièrement lisible.)
  2. Ton projet ne dois jamais utiliser la commande eval. C'est la commande qui est appelée à chaque fois que tu utilises la commande "insérer un script".
    Tu vas me dire, sous PSP c'est pas possible, pour ajouter un Pokémon il faut utiliser un script !
    Je vais te répondre, en effet, il faut utiliser un script, cela dit, tu peux modifier le comportement de tes évents avant la compilation avec RMXP de ton projet pour que toute les commandes de scripts soient remplacés par un pointeur de fonction qui va contenir le corps du script qui sera évalué au lancement du projet. Ca évite l'injection de script In Game. Mais si tu fais une erreur comme moi : t'oublies l'une des deux commandes et tu permet de charger du data modifié, ça n'empêche pas l'injection avant jeu.
  3. Ne fais pas confiance à l'archive RGSSAD. Ne fais pas confiance à Game.exe.
    L'archive RGSSAD c'est juste une archive, elle ne protège en aucun cas tes données alors ne crois pas qu'elle va te les protéger, même si t'utilise DRGSS qui change la clef de cryptage, ça change la clef, c'est tout.
    Game.exe lui injecte du code via RGSSEval (fonction de RGSS10XY.dll) qui peut être modifié donc à partir de là il y a de forte chances que tu aies des problèmes d'injection de code. C'est ce qu'utilise RMXP Ressource Dumper pour violer la protection de DRGSS. Si tu veux une réelle protection faut que tes datas ne soient pas dans les même formats de base que n'importe quel projet RMXP et il faut que ton projet ne se charge qu'avec ton Game.exe à toi qui n'injecte pas de script par la commande RGSSEval.
  4. Ne pas faire comme tout le monde. L'une des raisons qui fait que je ne fournis pas mes systèmes de protection c'est ralentir le processus. Si tout le monde utilise mon système, à partir du moment où mon système est cracké, tous les projets utilisant mon système sont vulnérable à un exécutable du genre RGSSAD_WX qui décrypterait les données. Si un projet A procède d'une manière, un projet B d'un autre, un projet C encore d'une autre. Le hacker craquera le projet A, mais le projet B et C resteront légèrement protégé jusqu'au moment que le hacker s'y penche, pendant ce temps, le projet A peut changer de système de protection, balancer une mise à jour et rouler jeunesse.

    Si linux et Mac n'ont que très peu de virus (mais des virus hyper virulents), c'est parce qu'il n'y a personne qui n'utilise ces systèmes alors ça n'intéresse pas les Hackers donc si personne n'utilise la protection (hormis ton projet), le hacker risque d'en avoir un peu rien à secouer car ça ne lui apportera rien contrairement à celui qui a cracké la protection du fichier RGSSAD.


Ces points sont essentiels mais saches que ça sert juste à protéger ton projet contre le Hack rapide, ça ne le protège en rien, je connais la faille ultime du RGSS et j'ai un code binaire en i386 qui me permet d'injecter du script dans n'importe quel projet RGSS 1, 2 ou 3, j'ai juste à changer les pointeurs (car je l'injecte par allocation dynamique) et hop ton projet est brisé même avec les trois points du dessus respecté.

Voilà, voilà.