[Hacking] Gruge de compte

Répondre
Partager Rechercher
sauf si un joueur se connecte avec une cle Ck qui n'est pas la sienne mais celle d'un joueur de ton serveur et que en plus il se connecte avec le compte du meme joueur... et voila le hacking

La dessus je vois pas ce qu'on peut faire
Mais bon faut dire que pour faire ca deja faut etre a mon avis assez bon pour avoir recuperer un compte et la cle qui va avec...

En plus si on commence a stocker les cles valides et les nom de PJ, la cela sera cool. Il suffira à un petit malin de rentrer sur ton serveur et d'aller hacker ta base de donnée
Il aura alors X cle Cd et compte pour s'amuser
Mouarf, un peu abusez le message ci dessus.

Ca nous explique en clair comment hacker des comptes quoi

Sinon pas mal le script, mais il peut y avoir mieux pour contrer les problèmes de : je joue chez un pote, ou j'ai racheté les CD avec une new key.

Quand le pj se connect, il est tp dans une zone temporaire ou un pj lui demande un login et un mot de passe (qui est écouté par un listener) Si cela correspond avec ce qui est enregistré dans la database, il téléporte le joueur sur le module, sinon il le kick.

Yaurait personne pour faire un système comme ca qui passerais avec la database de bioware ?

[Edit: Ouais je suis un bon moi, c'est marqué en moins clair un peu plus haut ]
le plus dangereux n'est pas le hacking mais la FAUSSE impression de sécurité (ce qui est bien plus grave...) de certaine situation et donc eviter d'utiliser son nom de compte bio comme nom d'utilisateur forum et aux admins de faire gaffe quand le master server est HS....

pour le reste, faut etre stupide et/ou débile pour fournir sa clef CD complete à un serveur pour y jouer..même si ce sont des amis...

ceci dit, la seul solution viable qui sort des forums bio pour l'instant, est effectivement la zone tampon avec un mot de passe géré en local...
Citation :
Provient du message de Dalfy De Cayley
Le problème principal de la zone tampon est d'être seule dans cette dernière. Il ne faudrait pas qu'un autre joueurs puisse entendre le mot de passe spécifique a un compte bien précis.
Un sémaphore à l'entrée de la zone tampon bloquant l'accès si elle est déjà occupée.
Euh.... la clef de CD n'est pas donnée par le joueur....

Elle est chopée par la fonction :

Code PHP:

GetPCPublicCDKey(oPC); 

Cette fonction existe, elle a donc été concue pour que l'on s'en serve. La donnée qu'elle stoque est cryptée... Pour éviter de recuperer des clefs valides qui permettraient un piratage de NWN avec des clefs recuperees.

Donc aucun risque de pirater une base de données contenant ces clefs.
Toute vérification ou le joueur interagit avec le module n'est pas sure.

Le principe du script est qu'il est declenché en dehors du controle du joueur et ne lui laisse aucune possibilité de gruger.
Citation :
Provient du message de mayk
Euh.... la clef de CD n'est pas donnée par le joueur....

Elle est chopée par la fonction :

Code PHP:

GetPCPublicCDKey(oPC); 

Cette fonction existe, elle a donc été concue pour que l'on s'en serve. La donnée qu'elle stoque est cryptée... Pour éviter de recuperer des clefs valides qui permettraient un piratage de NWN avec des clefs recuperees.

Donc aucun risque de pirater une base de données contenant ces clefs.
Ben justement, le souci c'est que certains joueurs ont réussi à changer leur clé CD non ? Et donc à pouvoir faire foirer la vérification avec la clé publique.
J'ai ptêt pas tout compris
Il y a deux gruges possibles :

1 - le joueur profite d'une panne du serveur de Bioware, qui vérifie les comptes et leur mot de passe.

2 - le joueur gruge une clef CD a un autre joueur.

A notre niveau en tant qu'admin, on a une responsabilité de sécurisation des personnages des joueurs. Donc c'est le premier point qui nous concerne.

Imaginons un scénario bidon :

Joueur1 s'engueule avec Joueur2. Joueur1 recupere le nom de compte de Joueur2. Il attend patiemment une panne de Serveur de bioware (celui qui verifie les comptes des joueurs), change son nom de compte en celui du Joueur2 et se conecte au serveur ou il a rencontré Joueur2.

Les serveurs ne vérifiant pas le compte des joueurs (ceci etant le role du Serveur de Bioware) il donne automatiquement acces au dossier nommé Joueur2 à Joueur1, qui peut disposer librement des personnages de Joueur2.

Joueur1 arrive donc sur le serveur avec le personnage de Joueur2, et le lui "abime", en foutant ses objets dans une poubelle, ou en lui faisant perdre de l'xp, en lui faisant attaquer la garde de la ville...

Puis sagement, Joueur1 deconnecte (de l'identité de Joueur2) et reprend son identité de Joueur1.

Quand joueur2 revient sur le serveur, son personnage fétiche est détruit, et aucun moyen de connaitre l'identité de Joueur1.

Mon script associe un personnage (PAS UN COMPTE) à une clef CD (une clef CD par version CD-ROM, donc par joueur) en sachant que les joueurs ne vont pas acheter un jeu a chaque fois qu'ils se connectent.

A sa premiere connection avec un personnage, la clef CD est stoquée dans une base de données avec en plus une deuxieme base de données qui stoque le fait qu'il est deja venu.

A chaque connection de ce PERSONNAGE (et non COMPTE), le serveur va comparer la clef CD enregistrée à la premier connection de ce personnage, avec celle de la connection actuelle.

Si les clefs sont différentes, le joueur controlant le personnage est ejecté. Pas besoin de bannir... Il sera ejecté à chaque connection, tant que la clef CD ne correspond pas.

Donc ceci rend impossible l'usurpation de compte.

Si toutefois un joueur change de clef CD, et qu'il apprécie le serveur où il joue, il peut contacter l'admin, qui rectifie le probleme, et garde ainsi un controle sur ce qui se produit sur le serveur.

Dans le deuxieme cas de figure, celui de l'usurpation d'une clef CD générée par exemple par un KeyGen. Le seul moyen est de contacter Bioware, et de fourni une preuve d'achat du jeu avec une photocopie de la clef de CD correspondant à cette facture.

Je pense qu'ils se bougeront les fesses pour rétablir la situation, étant doné qu'ils ont la responsabilité de resultat à partir du moment où un jeu a été acheté légalement.
Je pense que ce serait plutôt à Atari de s'adresser, et je pense également que les résultats risquent de se faire attendre, mais bon

Au final donc, on se retrouve un peu désemparé face au problème de gruge de clé CD.

En attendant un geste de Bioware, la solution d'une antichambre pour donner un mdp reste la seule valable apparemment.
Par contre vous prenez pas la tête avec des trucs que le PJ doit prononcer : pourquoi ne pas plutôt devoir utiliser plusieurs items dans le bonne ordre ?
Par exemple on donne au PJ un code : 35215, ensuite lorsque le PJ se connecte il reçoit dans son inventaire des items nommés "1", "2", ..., "5". Suite à quoi il doit activer les items dans l'ordre de son code pour pouvoir rentrer. Comme ça tout le monde fait son petit code dans son coin, et y'a pas moyen de se faire gruger.
Hum mouais, ca a pas l'air si simple que ca à scripter.

Je suis d'un niveau moyen et je me vois mal faire ca.

On serait obliger de stocker dans une base de donnée non ?

Yaurait pas un courageux pour faire un p'tit exemple que je m'en inspire ?
Voilà un premier jet : module de test

Le principe :
- en arrivant dans le module, on se trouve dans une petit salle sans issue
- les objets "mot de passe : X" ou X est une lettre de A à F, qui servent à rentrer le mdp
- un objet "mot de passe : RESET" qui sert à recommencer si on s'est planté dans la saisie
- en cliquant sur la statue, on obtiens un mot de passe (sauf si on en a déjà un)
- puis, on compose le mot de passe en activant les objets "mot de passe : X"
- si le mot de passe est bon, on est envoyé à un autre wp, sinon on reste sur place

Le mot de passe fait actuellement 8 lettres. C'est un peu beaucoup, surtout que c'est long à rentrer. Peut être que 5 ou 6 lettres suffiraient.
Les mots de passe sont enregistrés dans une base de donnée "passwords", avec comme nom de variable le nom du PJ. L'idéal serait d'avoir un mot de passe en fonction du nom de perso et du nom de compte, mais bon.

Il doit sûrement y avoir une solution plus efficace, mais moi je vois pas trop.
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés