Cependant, suite à un plongeon fou dans les jeux ce week-end, je me suis pris à rêver mes jeux préférés passer aux mains du Libre. Cependant, question technique, cela semble être moins évident qu'il n'y paraît.
Je vous invite à lire mon article ci-joint... Suite à une réflexion qui a suivie une "grosse" LAN de ce week-end (où j'étais le seul à jouer à Counter-Strike (modification d'Half-Life, win32 "only") sur un GNU/Linux (Gentoo powaaaa), je crois avoir trouvé une limite à l'open source (au sens large) que je chérie tant.
Arrivé à un certain niveau de jeu, il est important de vérifier l'intégrité du rendu de l'ensemble des clients afin que la triche (cheats) soit réduite à sa plus simple expression. Or comme dans tous les cas où l'on fait confiance au client, la "sécurité" est significativement réduite (voire rendue inexistante : peut-on faire confiance à ce que l'on ne peut maîtriser que partiellement ?).
Maintenant, imaginons un client open source (ne lançons pas de débat de licence, la question n'est pas là). Malgré toutes les astuces que l'on puisse mettre en oeuvre (genre vérifications MD5 des binaires et des fichiers du jeu, délégation importante des traitements au serveur, etc...), il existera toujours un moyen de les contourner, cela grâce à la disponibilité des sources.
Je lance cette réflexion ici car je pense que les jeux et les Logiciels Libres est un sujet qui intéresse et que c'est un passage qui permettra au grand public d'y adhérer beaucoup plus facilement. Malheureusement, dans certains cas, il est possible que l'on touche les limites de ce système, aussi séduisant soit-il...
[AzF]BeTa-CornichonHaaaa
-Just For Fun-
nb: ne nous lançons pas non plus dans un débat, pour peu que certains s'y mettent, sur la sécurité "anti-cheats" du duo Half-Life / Counter-Strike... la conclusion pourrait vite arriver... ;c)
Aller plus loin
- Linux Half-Life (5 clics)
- LinuxGames (7 clics)
# Re: Une limite de l'OpenSource ?
Posté par Bruno (site web personnel) . Évalué à 10.
Sans source, c'est pareil, ça prend juste un peu plus de temps ...
[^] # Re: Une limite de l'OpenSource ?
Posté par free2.org . Évalué à 7.
Sans commentaires et parfois sans noms de fichiers, il faut bien-sûr + de temps pour comprendre les sources décompilés.
Bref, soit on fait confiance aux utilisateurs des clients (des réseaux de confiances à la gpg peuvent être utiles)
Soit on fait un serveur qui ne communique aux clients que les informations que le joueur a le droit de connaitre (mais les performances d'affichage du client peuvent être ralenties par un réseau congestionné).
Cette dernière solution est à mon avis une solution d'avenir aussi pour les joueurs qui aiment la programmation: ils peuvent alors modifier le client à leur goût, automatiser toutes les phases de jeux répétitives de leur stratégie, etc... Cela peut permettre à chaque joueur de développer ses propres AIs en local et de confronter ces AIs à d'autres joueurs ou à d'autres AIs.
Des solutions hybrides AI/joueur ("cyberjoueurs") sont assez excitantes. Il est clair que les clients opensource sont avantageux pour ce type de solution. C'est la direction qui est prévue pour le projet Civilization freeciv.org
PS: outre freshmeat.net et linuxgames je signale aussi le "linux game tome": http://www.happypenguin.org/list?sort=avg_rating(...)
[^] # Re: Une limite de l'OpenSource ?
Posté par Salica . Évalué à 2.
> aiment la programmation: ils peuvent alors modifier le client à leur goût, automatiser
> toutes les phases de jeux répétitives de leur stratégie, etc...
Mhhhh... je ne suis pas trop d'accord avec ce point. Si tu prends le cas des jeux de rôle "à la RPG sur console", par exemple Ragnarok Online, la principale difficulté du jeu vient du fait qu'il faut être assez motivé pour passer son temps à "gonfler son perso" (faire du build-up).
On a malheureusement vu apparaître des bots qui dirigaient les persos et qui les faisaient attaquer tout ce qui passaient à leur portée. De cette manière, le joueur peu scrupuleux laissait tourner son bot la nuit et se réveillait avec un perso boosté.
Persos boostés, qui étaient capable de se faire n'importe quel ennemi et qui, avec le temps, ont considérablement déséquilibré le jeu.
Mais bon, on ne peut rien y faire : on ne sait pas garantir que c'est vraiment l'utilisateur qui a déplacé son perso et non pas un programme qui a généré les infos de déplacement de ce perso.
[^] # Re: Une limite de l'OpenSource ?
Posté par Moby-Dik . Évalué à 3.
On peut périodiquement lui faire passer un test de Turing ;-))
[^] # Re: Une limite de l'OpenSource ?
Posté par Jak . Évalué à 1.
:)
[^] # Re: Une limite de l'OpenSource ?
Posté par Alan_T . Évalué à 1.
Réfléchis un peu voyons !!!!! :o)
Allez hop --> -1 (Ah bah non, pas -1, zut alors!)
[^] # Re: Une limite de l'OpenSource ?
Posté par imr . Évalué à 2.
Tout systéme basé sur ca, "tend" à ce que les joueurs se focalisent sur les combats POUR gagner de l'expérience.
Même si tu supprimes les bots, tu auras des joueurs qui vont passer des nuits entiére à se comporter comme ton bot et finiront par déstabiliser le jeu. Ca prendra un peu plus de temps.
C'est à tel point indépendant de la technique que ca existe aussi dans les JdR-papier-crayon-imagination-etres humains véritables; le spectre (hilarant) du Gros Bill flotte sur les systémes de jeu "moi voie moi tue".
[^] # Re: Une limite de l'OpenSource ?
Posté par doublehp (site web personnel) . Évalué à 4.
Dans le bon vieux temps ou je passait le plus clair de mes récrés sur ma HP48 ... j'utilisais le MetaKernel, un programme tres complet , mais quelque peu bridé dans sa version demo. Il y avait une specificite sur les librairies hp48 : elle se finissent par un CRC... et les mecs du MK vérifiaient si cette valeur etait bien celle prévue ... pour ce faire, ils avaient reussi à stoquer la valeur du CRC à l'interieur même du code de la librarie!
Il m'a suffit de scanner toute la librarie en cherchant la valeur magique; il n'y avait qu'une seul occurence ... j'ai donc modifie l'instruction assembleur equivalente a
if ( CRC == 12345 ) ... ELSE ERROR
en
if ( CRC != 12345 ) ... ELSE ERROR
le fait meme de modifier la lib fesait que le CRC globale etait différent, donc la condition etait quand même vérifiée : le simple fait de changer une instruction et de recalculer le vrai nouveau CRC de la lib laissait croire à l OS que la lib était non-corrompue ( CRC finale bon ), et le MK croyait qu'il etait intègre ... c'était évidement la porte ouverte à plein de choses plus droles ... comme la supression de toutes les autres limitations de la ddémo ...
ca m'a pris 4h ... c'etait la premiere fois que je touchais à un binaire ...
alors oui je confirme que si on a les sources d'un programme qui délègue la sécurite au client, ca doit etre super simple de dire au serveur : " oui t inquiete , je suis intègre ; la preuve voila mon MD5 XXXXX ... tu voit c'est le meme que tout le monde ;) "
En ce sens je suis oblige de considerer que dans un monde ou l'argent existe, et où les travailleurs veulent être payés de leur labeur, le TOUT-OPEN-SOURCE ne me parait pas viable ! ( merci Aldouse Huxley ...)
[^] # Re: Une limite de l'OpenSource ?
Posté par franck villaume (site web personnel) . Évalué à 2.
voir les commentaires un peu plus haut.
Bref, sources disponibles ou pas cela ne change rien au problème de sécurité.
--
C01N C01N
# Re: Une limite de l'OpenSource ?
Posté par Fabimaru (site web personnel) . Évalué à 9.
Il disait que fait un jeu securise (enti-cheat) est possible, mais que ca consommerait beaucoup de ressources:
- le serveur doit faire beaucoup plus de verifs
- beaucoup plus d'informations doivent transiter par le reseau (adieu jeu sur le net)
Mais bon. Meme sans les sources, il y a des tricheurs. La meilleure chose a faire est de choisir des serveurs ou tu connais les gens, et ou des admins virent les gens trop trop suspects.
[^] # Re: Une limite de l'OpenSource ?
Posté par Baptiste SIMON (site web personnel) . Évalué à 2.
Cela dit, ce n'est toujours pas une solution parfaite... mais existe-t-il une "solution parfaite" ? La pratique nous apprend tous les jours que non :c).
[^] # Re: Une limite de l'OpenSource ?
Posté par schyzomarijks . Évalué à 8.
On pourrait alors avoir un ensemble de joueurs reconnus comme "honnêtes" qui auraient la possibilité d'inclure dans le cercle d'autres joueurs de confiance. Cette possibilité permettrait d'exclure (temporairement ?) les joueurs indélicats.
[^] # Re: Une limite de l'OpenSource ?
Posté par Baptiste SIMON (site web personnel) . Évalué à 2.
Mais bon, c'est le risque... je pense que c'est une alternative valable... Et ça permet de réintroduire du Libre dans tout ça... :c)
Pour partir dans le délire... on peut imaginer un cercle de connaissances qui se valide et qui élargit ce dernier à d'autres personnes rencontrées en LAN, en soirée ou autre. Jusque là, c'est du réchauffé à la GnuPG... Là où ça deviendrait intéressant ça serait une notion d'expiration de la confiance dans le temps. Genre à chaque rencontre avec d'autres joueurs, on devrait se refaire valider. Cela permettrait de gravir des niveaux de confiance de plus en plus haut, en gagnant du coup, de plus en plus la confiance de la communauté.
Bref, il y a en effet peut-être un truc à creuser de ce côté là.
Sans oublier que cela reste un chateau de cartes... :c)
[^] # Re: Une limite de l'OpenSource ?
Posté par Jean-Yves B. . Évalué à 3.
Il est possible de limiter les attaques et les dégâts avec un gestion de trustweb à la advogato.
La vraie difficulté c'est d'identifier la triche. J'ai souvent cru que certaines personnes trichaient à tetrinet et un jour je les ai vu jouer en vrai, j'ai été bluffé, c'était le genre de personnes qui joue en regardant uniquement la pièce suivante, tout le reste dans la tête.
[^] # Re: Une limite de l'OpenSource ?
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
[^] # Re: Une limite de l'OpenSource ?
Posté par fabien . Évalué à 2.
Ceux qui ne frequentent pas les LAN ou qui ne connaissent pas les bonnes personnes sont condamnées ?
on devrait se refaire valider
<humour>; le code barre est prevu pour quand ? oui, avec ca sur le front son se fait revalider plus vite que palladium, hop comme à la caisse ... bip bip</humour>
Serieusement, le coups du cercle qui s'agrandis, c'est risqué quand le cercle deviens trop grand, et qu'on ne connais plus grand monde.. du coups on n'a plus confience au cercle en lui même.
gravir des niveaux de confiance
la vie n'est pas un RPG, laissons un espace de liberté, ou il n'y a pas d'echelon a gravir. quel plaisir de se mesurer a des experimentés sans se faire validé pendant 6 mois avant..
Cela me parrait assez difficile en pratique, quelques idées a creuser en effet, mais ne fermons pas trop le systeme non plus.
bye
[^] # Re: Une limite de l'OpenSource ?
Posté par Baptiste SIMON (site web personnel) . Évalué à 0.
[^] # Re: Une limite de l'OpenSource ?
Posté par doublehp (site web personnel) . Évalué à 2.
c est pas le but des XP ???
[^] # Re: Une limite de l'OpenSource ?
Posté par Edouard Gomez (site web personnel) . Évalué à 8.
Petit bemol cependant, il semblerait que PunkBuster soit aussi utilise pour de toutes autres choses. J'ai ainsi ete surpris de voir quelqu'un etre banni d'un serveur urban terror 2.6 car il y avait sur le reseau un GUID/CdKey en double. Le probleme de cdkeys partagees entre utilisateurs honnetes et mechants gamerz est un probleme connu et jusqu'a maintenant seul le premier utilisateur de la clef connecte au serveur central pouvait jouer. Mais ca n'allait pas plus loin et tant mieux, car comment savoir qui est le detenteur legitime de la clef ? Bannir les gamerz OUI, mais comment les reconnaitre ?
Pour en revenir au "libre vs triche", comme il a ete dis plus tot, le proprio ne fait que retarder l'apparition de la triche mais une fois qu'elle est la... La seule vrai solution est et sera toujours de jouer sur des serveurs clean geres par de bon admins.
--
Edouard Gomez
[^] # Re: Une limite de l'OpenSource ?
Posté par Wi][ish . Évalué à 0.
Je pense que c'est normal. Lorsque tu achetes le jeux, la clef, tu dois la garder pour toi. Si tu la donnes à quelqu'un, il ne faut pas s'attendre à ce que tout ce passe bien par la suite.
Cepandant, au niveau des bemols à apporter au niveau de PB, il y a aussi un grosse perte au niveau du framerate... ça conssome beaucoup en CPU. Sans compter que parfois, tu te fais kické parce que ton PB à pas réussi à se mettre à jour (dans ce cas là, il faut le maj à la main).
On peut aussi noter qu'il existe une version de PB pour les Q3 Linux (closed source).
[^] # Re: Une limite de l'OpenSource ?
Posté par Philippe Sarazin . Évalué à 2.
Enfin, si il est que kické du serveur et pas banni, ça va encore ;) au pire si ça le gène vraiment, y a peut-etre moyen de contacter activision en fournissant une preuve d'achat pour savoir quoi faire... En tout cas c'est ce que j'essaierais...
[^] # Re: Une limite de l'OpenSource ?
Posté par Fabimaru (site web personnel) . Évalué à 2.
[^] # Re: Une limite de l'OpenSource ?
Posté par jojolapin . Évalué à 1.
[^] # Re: Une limite de l'OpenSource ?
Posté par Guillaume Morin . Évalué à 1.
Cependant, c'est tout à fait envisageable pour les MMORPG comme Ryzom (voir http://www.ryzom.com/(...) ) construit sur la bibliothèque libre NeL (http://www.nevrax.org/(...) ). Vu que par exemple le résultat d'une attaque ne dépend pas directement d'une action du joueur mais des caractéristiques du personnage, du hasard etc., il est possible pour le serveur de tout contrôler et donc d'éviter la triche.
[^] # Re: Une limite de l'OpenSource ?
Posté par Philippe F (site web personnel) . Évalué à 7.
ESR avait repondu et John Carmak avait reconnu qu'il avait raison. En gros, les arguments avaient ete les memes que ce qui se dit ici:
- il est possible de tricher sans les sources, ca prend juste plus de temps a mettre en place
- certains ont l'illusion que ne pas distribuer les sources rend impossible de tricher, et font donc des programmes beaucoup moins resistants a la triche. C'est l'eternel 'security through obscurity'. Les jeux open-source, conscients de la facilite avec laquelle on peut les patcher, sont donc en general penses pour diminuer la casse au maximum.
- finalement, il faut faire confiance au serveur et aux utilisateurs. On ne peut pas s'en passer.
C'est ce qu'avait dit John en releasant les sources de quake.
[^] # Re: Une limite de l'OpenSource ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
# Re: Une limite de l'OpenSource ?
Posté par Erwan . Évalué à 2.
http://arianne.info/(...)
[^] # Re: Une limite de l'OpenSource ?
Posté par champi . Évalué à 1.
En fait la barrière des sources n'empêche absolument en rien la tricherie. Du moins si c'est ce que croient les éditeurs, les faits prouvent bien qu'il est relativement simple de tricher sans avoir les sources.
Tout est une question de programmer correctement pour sécirusier son jeu : faire confiance à la compilation pour empêcher la tricherie, c'est etre bien naïf :-D
[^] # Re: Une limite de l'OpenSource ?
Posté par Baptiste SIMON (site web personnel) . Évalué à 4.
[^] # Re: Une limite de l'OpenSource ?
Posté par Fabimaru (site web personnel) . Évalué à 3.
Dans les jeux comme Counter Strike:
- on peut eventuellement avoir des drivers hackes qui affichent derriere les murs. Comment le programme peut-il savoir ce qui n'est pas de son ressort ?
- avoir un patch qui corrigent les tirs. Quand un joueur clique pour tirer, le tir est recentre vers l'adversaire le plus proche (et sa tete par exemple). Cela pourrais-etre sous la forme d'un programme qui va modifier l'original au chargement (comme pour le debug) ou alors un proxy.
Comment connaitre la difference entre un tir normal et un tir corrige ? Ajoutez a ca la possibilite d'avoir une correction de tir configurable ("rapprocher aleatoirement les tirs de 0 a 10% de la tete"), et ca devient tres dur a un admin de voir qui a ameliore son niveau artificiellement...
[^] # Re: Une limite de l'OpenSource ?
Posté par N-Mi . Évalué à 2.
Ce genre de fonctionnalités des pilotes sont en effet indétectables que le jeu soit open-source ou non...
De toute façon un joueur qui triche, souvent ça se voit aussitôt (en général un simple coup d'oeil au score suffit, c'est rare qu'un très bon joueur reste sur une partie avec des personnes de niveau inférieur.
[^] # Re: Une limite de l'OpenSource ?
Posté par Fabimaru (site web personnel) . Évalué à 2.
De plus, si le driver est Open Source, c'est encore plus facile a faire qu'avec des drivers aux sources fermees.
[^] # Re: Une limite de l'OpenSource ?
Posté par Jean-Yves B. . Évalué à 1.
Ça c'est un problème pénible pour les gars d'XFree86, notamment le gag de la sortie TV des radéon que l'on sait activer mais ce code ne peut pas être intégré à XFree86 à cause de Macrovision qui « protège » la sortie vidéo de DVD (et une violation de contrat ATI/Macrovision/MPAA(DVD-consortium) c'est pas rentable pour ATI) ...
[^] # ATI Radeon
Posté par snurpsss . Évalué à 1.
Il y a une magouille a faire ? cela a t il un rapport avec le driver ati 2 ?
Merci
[^] # Re: ATI Radeon
Posté par Jean-Yves B. . Évalué à 2.
[^] # Re: Une limite de l'OpenSource ?
Posté par Erwan . Évalué à 1.
Resultat: on trouve tout un tas de patchs pour tricher en mode "open battle net" ou sur reseau local, mais sur battle.net il c'est le serveur qui s'occupe de tout, la triche est impossible.
C'est vrai, il reste possible de changer le client pour qu'il aient un affichage plus sympa, pour des jeux genre Half-life ca peut beaucoup aider. Mais ce n'est pas un probleme specifique a l'Open Source !
[^] # Re: Une limite de l'OpenSource ?
Posté par Colaur . Évalué à -3.
Je trouve que sur linuxfr il y a un peu d'hypocrisie générale sur ce sujet. On passe son temps à vanter la facilité de l'open source, ça permet d'améliorer/comprendre/partager le code, ce qui est régulièrement donné comme impossible dans un logiciel propriétaire.
Mais quand ça ne nous arrange plus (jeu en ligne), on se met à dire que finalement closed ou open source ça change rien...
Tous les systemes de sécurité genre gpg, ssh et autres ne marchent que parce que le proprio de la machine sur lequel ces progs tournent le veut bien. S'il veut s'amuser à corrompre ses programmes il est libre de le faire.
Il en possède les sources et le mot de passe root.
[^] # Re: Une limite de l'OpenSource ?
Posté par Erwan . Évalué à 2.
Tous les systemes de sécurité genre gpg, ssh et autres ne marchent que parce que le proprio de la machine sur lequel ces progs tournent le veut bien. S'il veut s'amuser à corrompre ses programmes il est libre de le faire.
"battle.net ne marchent que parce que le proprio de la machine sur lequel ce prog tournent le veut bien. S'il veut s'amuser à corrompre son programme il est libre de le faire."
Si battle.net etait Open Source, on pourrait monter des serveurs qui autorisent la triche. Et alors ? Les gens honnetes resteraient sur des serveurs honnetes.
Non, vraiment il n'y a pas de difference fondamentale entre les jeux en ligne et un autre protocole client/serveur. Les avantages de l'Open Source sont les memes et croire que devoiler les source est mauvais pour la securite est une grosse connerie. Je ne detaillerait pas, ca a deja ete fait par des gens bien plus competents que moi (STFW).
[^] # Re: Une limite de l'OpenSource ?
Posté par Colaur . Évalué à 2.
Ben si. Dans le cas d'un jeu l'essentiel du travail est effectué sur le client et pas sur le serveur. Donc beaucoup plus difficile à controler.
Et la finalité de la triche est très différente. Le but n'est pas de pirater/détruire/corrompre le serveur, mais juste d'empecher le serveur de se rendre compte du fonctionnement modifié du client (visée automatique, murs transparents,etc).
[^] # Re: Une limite de l'OpenSource ?
Posté par Toufou (site web personnel) . Évalué à 3.
Ca peut tout à fait être pareil dans une appli qui n'est pas un jeu: par exemple, dans un systeme d'échange p2p avec un serveur central, tu peux très bien fausser la BD de fichiers que tu partages. Le travail est fait au niveau client.
> ... empecher le serveur de se rendre compte du fonctionnement modifié du client
Tout comme dans une autre style de piratage qui n'a rien a voir avec le jeu: le coup d'Humpish est de feinter le système d'authentification de la CB (en local), pas de trucider le serveur et encore moins de se faire repérer.
Je pense aussi que quel que soit le protocole, tu ne peux pas faire confiance au soft client, jeu ou pas. Si tu déporte une partie du travail sur le client, tu risques une triche sur cette partie du travail. Le problème c'est que même un terminal passif prend en charge une partie du travail de l'application (ne serait-ce que la gestion de la console) et donc tu risques une triche (un robot qui simule un être humain derriere le clavier par ex: le sendkeys est bien connu par les martyrs du VB)
En fin de compte, tu ne fais confiance qu'à l'utilisateur.
[^] # Re: Une limite de l'OpenSource ?
Posté par Erwan . Évalué à 2.
Autre exemple: ICQ. Je peux exiger que les autres utilisateurs aient a me demander l'autorisation pour m'ajouter... Mais c'est gere sur le client ! Resultat: avec le transport ICQ de Jabber ou avec Licq (ou tout client libre qui n'a pas envie d'implementer le systeme d'autorisation...) on peut ajouter qui on veut, et savoir si ils sont en ligne ou pas sans rien demander a personne.
Bien sur, jabber gere l'autorisation sur le serveur. Mais ca, c'est une autre histoire...
[^] # Re: Une limite de l'OpenSource ?
Posté par Beretta_Vexee . Évalué à 1.
Les tricheurs vont la ou il y a des joueurs et si possible de bon niveau histoire de se faire mousser a par mettre en place des mesure drastiques de restrictions d'acces je vois pas comment filtrer les gens honnetes sur un serveur honnetes. Ce qui de plus diminue l'interet du jeu, si je joue sur battle.net c'est pas pour jouer sur un serveur privé avec les méme 5 personnes, qui ne sont presente que 3 heures par jours.
Non, vraiment il n'y a pas de difference fondamentale entre les jeux en ligne et un autre protocole client/serveur. Les avantages de l'Open Source sont les memes et croire que devoiler les source est mauvais pour la securite est une grosse connerie. Je ne detaillerait pas, ca a deja ete fait par des gens bien plus competents que moi (STFW).
Bas si il y a une difference l'ouverture des source facilite des triches et trucages en tous genres et tu le fair play, qui est indispencable pour un jeu. De plus pour en revenir a Battle.net le protocole client/server ne sert qu'a la mise en relations des joueurs et aux serveurs de discutions, tous le reste du systéme et decentralisé et repartie entre les joueurs, ce qui est normale on ne peut pas imaginé un serveur qui verifierais toutes les actions entreprise par 3 millions de joueurs autour de la planette et tous ceci avec un latence faible, oui cinon ce ne serait pas un service compris dans le prix du jeu. Un jeu comme warcarft integre pourtant different systéme de protections ( CRC de l'exe, de l'exe en mémoire, du CD, contre expertise des deplacemant par un joueur adverse, etc etc ..) et pourtant des triches assez evolués existe ( maphack moneyhack etc etc ...). La securitée d'un jeu peut difficilemant étre delegué a un serveur pour des raisons techniques et n'est pas satifesante quand elle est fondé sur les clients et ce opensource ou pas, le systéme de jeu parfait reste a inventer.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
# Re: Une limite de l'OpenSource ?
Posté par Aurelien . Évalué à 3.
je sais c'est bas: je sors.
# rigolo comme remarque
Posté par Le_Maudit Aime . Évalué à 7.
1) Le problème s'était déjà posé avec les drivers asus qui pouvaient tout rendre visible (y compris les joueurs adverses).
Mais là où c'est vraiment rigolo c'est quand la niouze est titrée <<Une>> et que sur linuxfr on passe son temps à dire que les protections anti-copies sont illusoires alors que c'est exactement le même problème : contrôler les programmes qui s'exécutent sur une machine : autoriser le lecteur CD mais pas l'extraction des CD etc.
Non, ce n'est pas un pb lié à l'open source, ni au closed source, ni au propriétaire, parce que quelque soit le soft on peut toujours passer outre soit les protections, soit les vérifications (ce qui revient d'ailleurs au même).
C'est juste un problème de confiance et la confiance ça ne se propage pas au travers du net aussi facilement qu'une clé cryptographique.
[^] # Re: rigolo comme remarque
Posté par Gruik Man . Évalué à 1.
Pas du tout, c'est plus une question de sécurité côté serveur. La « sécurité » côté client est illusoire; open-source ou pas, il est impossible pour le serveur de s'assurer que le client exécute bien le « bon » binaire, là est tout le problème de la protection contre la copie. Par contre, le serveur peut très bien faire tout le travail, et ne déléguer au client que la partie affichage (et notamment, éviter de fournir à la machine de l'utilisateur des informations que l'utilisateur lui-même n'a pas à savoir).
Par contre, ce que le serveur n'aura jamais aucun moyen de savoir[1], c'est si les actions du client sont liées à la manipulation directe par une personne ou à un bot (ou une combinaison, par exemple une personne assistée d'un bot, comme avec les programmes pour viser précisément).
En bref, quand on parle de sécurité, il faut considérer l'utilisateur, son poste, et les logiciels qui tournent dessus comme une seule entité. On ne peut pas cacher à un utilisateur ce que l'on indique à sa machine, et on ne peut pas empêcher l'utilisateur de faire faire une partie du travail par sa machine.
Après, c'est vrai, l'open-source facilite cette symbiose :)
[1] Sauf méthodes heuristiques, contournables avec des bots un peu plus évolués
# MLdonkey
Posté par farib . Évalué à 0.
de même, eMule (win) est open source donc customisable. dans les deux cas, jeux ou p2p ( pas au sens warez, mais utilisateurs et respect des principes du logiciel) , il y a des tricheurs...... et MLdonkey commence à se faire bannir....
moralité, pas sur que les manchots soient les plus honnetes :/
[^] # Re: MLdonkey
Posté par mathieu mathieu (site web personnel) . Évalué à 0.
# Re: Une limite de l'OpenSource ?
Posté par Space_e_man (site web personnel) . Évalué à 3.
En effet, tu passe à côté de choses très importantes. Lorsqu'il s'agit de jeux, la sécurité est moins importante et cela permet de se baser sur la confiance pour favoriser les performances.
En effet, si la gestion des comptes bancaires était gérée de la même qu'une partie de CS, chaque utilisateur aurais, sur son disque dur, les soldes de tous les comptes "parteniaires" comme tous les joueurs de CS possède sur leur machine, les coordonnées des autres joueurs. Seulement, pour ce qui est des jeux, cela permet d'utiliser les capacités du moteur graphique de chaque client, y compris les processeurs graphiques.
A l'heure actuelle, je n'imagine pas que quelques driver de CG ou autre logiciel permette de tricher au terrible jeu du home-banking, même si cela tourne avec des logiciels libres. Quoique, avec les nouvelles technologies "révolutionnaires" de Microsoft, on n'est pas toujours sûr de la localisation des informations...
Si l'enjeu en vaut vraiment la chandelle (war game ;), rien n'empêche de limiter le client à afficher des images calculées partiellement (3D -> 2D) sur le serveur, de même pour les sons (3D -> 5.1).
Si tu dois jouer pour sauver ta vie dans un système juridique farfelu, tu peux être sûr qu'un tel système serait utilisé. Le problème est de faire croire au gens qu'un système Paladium est donc nécessaire. C'est un problème car ce système revient à imposer une sécurité maximum pour toute choses et à tout moment. C'est du tout blanc mis en opposition à du stéréotypé tout noire alors que la logique veut une juste mesure à toute choses (notamment la liberté d'expression).
[^] # Re: Une limite de l'OpenSource ?
Posté par Bruno (site web personnel) . Évalué à 0.
Euh, c'est complètement HS, mais le son 5.1 est en 2D, pas en 3D (il n'y a pas de haut-bas pour le moment)
hop, [-1] ... ben c'est où ? ;)
[^] # Re: Je n'apprécie pas ton article.
Posté par Baptiste SIMON (site web personnel) . Évalué à 1.
J'aime bien les commentaires qui commencent comme ça ;c)
Nan, plus sérieusement... je ne vois pas comment tu peux ne pas apprécier un "article" formulé sous la forme d'une question. N'aurais-tu pas l'habitude d'effacer les gêneurs (émetteurs de questions gênantes à tes yeux) de ton chemin d'habitude ?
Je rigole...
Tout ça pour dire que je suis tout à fait d'accord avec toi sur le "la sécurité est moins importante et cela permet de se baser sur la confiance pour favoriser les performances" c'est la raison de l'ensemble de mes gillemets autour du mot sécurité dans l'article en question.
Cela dit, "tous les joueurs de CS possède sur leur machine, les coordonnées des autres joueurs" soulève bien la question des fondements même du mode réseau d'Half-Life... Ce qui m'amène à ressortir le nota bene de l'article en question : "ne nous lançons pas non plus dans un débat, pour peu que certains s'y mettent, sur la sécurité *anti-cheats* du duo Half-Life / Counter-Strike... la conclusion pourrait vite arriver... ;c)". Merci d'avoir foutu le pied dedans...
Pour ce qui est de l'idée du passage par un calcul total sur le serveur jusqu'à pousser la réflexion d'envoyer carément les images que le client doit afficher... je pense en effet que c'est la seule solution de sécurité _totale_ (quoique).
C'est du tout blanc mis en opposition à du stéréotypé tout noire alors que la logique veut une juste mesure à toute choses (notamment la liberté d'expression).
J'hésite entre une expression écrite brouillant complètement la compréhension et une volonté de récupérer des votes (eh oui, c'est revenu !! :c) en notant par exemple "(notamment la liberté d'expression)" sur un site comme DLFP.....
Un petit coup pour finir :
cela permet de se baser sur la confiance pour favoriser les performances.
Tu n'aurais pas lu les autres commentaires ??
En tout cas, merci de ta riche contribution... je retiendrais l'histoire du calcul 3D sur le serveur. Je pense que c'est ce qui est ressorti de meilleur de ta contribution. :c)
[^] # Re: Je n'apprécie pas ton article.
Posté par Space_e_man (site web personnel) . Évalué à 2.
Je suis peut-être un drôle, mais voila, je suis devenu très sensible dès que l'on oppose liberté à sécurité.
Je n'aime pas ton article car il n'apporte aucune information nouvelle et pertinente. Par contre, il oppose bien liberté à sécurité par quelque signe de ..."maladresse".
Non, lorsque l'on parle communément de sécurité et des logiciels libres ou pas libres, il s'agit de choses bien plus importantes que de jeux. Bah..., et on est sensé ne pas "troller" ici...
J'ai indiqué mainte fois à mon entourage, linuxfr.org comme étant l'un des meilleurs lieux de rencontre intellectuel démocratique sur le net, mais c'était du temps de l'auto-modération et je dois dire que le niveau a sacrément baissé pour plus d'esthétique. Maintenant, les XP sont de retour, hé bien tant mieux ! Est-ce actif pour les articles aussi ?
Un bon conseil, si vous vous faites trop souvent fraggé à votre goût, changer de serveur d'OS ;-)
Bon pour me faire pardonner de tant d'énervement et pour vous montrer que je suis aussi un gamin, voila ce qu'il convient de faire avec les tricheurs :-)
http://www.sesa.ucl.ac.be/serge/video/cheaterlow.wmv(...) (2Mo)
ou
http://www.sesa.ucl.ac.be/serge/video/cheater-high.wmv(...) (25Mo)
PS: Si quelqu'un sais m'aider à convertir ces wmv en mpg ou autres format moins proprio, ce serait bien :-(
PS: Je dois à nouveau changer de machine(IP fix) pour poster, est-ce bien normal?
[^] # Re: Je n'apprécie pas ton article.
Posté par Space_e_man (site web personnel) . Évalué à 1.
A l'origine, je voulais écrire "changez de serveur, pas d'OS" mais après je croyais avoir corrigé pour "changez de serveur." tout cours, vous aurez compris je pense, sorry pour les fautes en générals :-(
# Netrek
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
[^] # Re: Netrek
Posté par Maurice Rosenfelder (site web personnel) . Évalué à 3.
C'est la conception du jeu qu'il faut changer. Si effectivement quelque chose ne doit pas être vu, la seule méthode de le cacher est de ne pas la transmettre à la machine cliente. Evidement, la disparition et l'apparition des pieces du jeu, que cela soit la description des locaux, ou la position des autres joueurs doit alors être gérée par le serveur. Et alors là, bonjour la charge, autant pour le serveur que pour le réseau.
Sans compter les différences de vitesse de transmission, qu'il faudra gérer.
C'est pourtant, à moins d'imaginer quelque chose d'entièrement nouveau la seule solution vraiment efficace que je puis voir.
[^] # Re: Netrek
Posté par doublehp (site web personnel) . Évalué à 1.
Moi je trouve ce systeme pas si bète: il est basé sur le même principe que le RSA : tu construit un system tellement complexe qu'il faut statistiquement "beaucoup" plus de temps pour le casser que sa propre espérance de vie.
Ca doit pas si mal marcher vu que le RSA ( basé sur ce principe ) est "largement" répandu ...
[^] # Re: Netrek
Posté par Gruik Man . Évalué à 1.
Sauf que dans le cas de la crypto (dont RSA), c'est un « beaucoup » mathématique, c'est-à-dire un 10^ avec un gros nombre derrière.
Dans le cas que tu présentes, ton beaucoup, c'est dans le sens « Ah ouais c'est vachement compliqué ». Comme il est sans doute vachement plus compliqué de cracker le système d'activation de Windows XP que d'acheter Windows à la FNAC. Celà ne prouve pas que c'est impossible.
[^] # Re: Netrek
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Si (MD5sum).
et surtout pas non plus de manipuler l'affichage hors binaire
Dans le cas de Netrek, si :-). Après pour un jeu utilisant massivement des drivers externes, c'est sur que tu n'y peux pas grand chose.
bref probablement un coup dépée dans l'eau.
Pas complètement, dans le cas de Netrek ça marche depuis 10 ans. Ça devrait pouvoir être adaptable aux jeux actuels.
[^] # Re: Netrek
Posté par Erwan . Évalué à 2.
* Tu demande au client c'est quoi son MD5 ? Faut avoir confiance...
* Le mec upload son binaire a chaque fois pour que le serveur fasse le MD5 lui-meme ? Meme chose, comment tu sais que c'est le meme binaire qui est execute et qui est uploade ?
[^] # Re: Netrek
Posté par Bruno (site web personnel) . Évalué à 1.
Pour appuyer ce point, il suffit de regarder le workaround utilisé pour faire fonctionner warcraft3 sous wine sur Battle.net (cf http://appdb.winehq.org/noteview.php?noteId=76&appId=897&ve(...)). Apparemment le client calcule une signature de l'exécutable et l'envoie au serveur. Le problème est que sous wine la protection du CD ne passe pas et le client refuse de se lancer. La solution : appliquer un patch noCD sur l'exécutable, lancer ce dernier, et une fois ce dernier lancé, remplacer le fichier exécutable par l'ancien non patché. La signature sera alors effectuée sur le vrai exécutable et la connexion passera ... cqfd
[^] # Re: Netrek
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
[^] # Re: Netrek
Posté par Gruik Man . Évalué à 1.
# Re: Une limite de l'OpenSource ?
Posté par pasPierre pasTramo . Évalué à 3.
Je vous invite a allez voir des interview dont celle la.
http://www.countercheat.com/vassily.htm(...)
On vois que ces gens qui crée le cheat le font par challenge ,et essayent souvent de contacter les societes qui fabriquent les jeux pour corriger les defaillances. Or ils ne sont pas ecouté .
Dans un modéle de devellopement OpenSource les erreurs et les portes ouvertes niveau sécurité serais eliminé au fur et a mesure et ceci trés vite. Comme exactement quand quelqu'un trouve une faille dans apache par ex.
Ironie du sort le cheat le plus utilisé (OGC) est "open source", et ceci n'ameliore en rien la capacité d'action des anti cheat comme on l'apprend ici ---> http://www.countercheat.com/system.htm(...)
[^] # Re: Une limite de l'OpenSource ?
Posté par Erwan . Évalué à 3.
Tres interessante, mais visiblement il n'a jamais distribue son cheat. Mauvais exemple...
Ironie du sort le cheat le plus utilisé (OGC) est "open source", et ceci n'ameliore en rien la capacité d'action des anti cheat comme on l'apprend ici ---> http://www.countercheat.com/system.htm(...)
Ouais, on apprends surtout que les auteurs de cheat insultent tous les softs (ca c'est de la merde, et ca c'est pourri. Ca je crois que personne ne l'utilise). Au fait, les fautes d'orthographes, elles ont ete ajoutees par le traducteur ou elles sont d'origines ?
Enfin, a lire tout ca ceux qui ecrivent (et distribuent) les cheats n'ont pas l'air bien malin. En fait, un mec qui ecrit un cheat c'est comme un cracker mais en plus con: le cracker il fait ca pour rentrer dans des systemes informatiques (pour diverses raisons), le mec qui ecrit le cheat c'est juste pour se sentir lui plus fort quand ils joue sur internet.
A quand la fausse zigounette a air comprime pour tricher a qui pisse le plus loin ?
# Triche ???? Ou ca ???
Posté par Alan_T . Évalué à 1.
Pourquoi ne pas définir un jeu dans lequel, par exemple, on pourrait disposer d'un language (le langage C ?) qui permettrai de décrire ses armes, ses véhicules, etc... Une sorte de 'Matrix' où tous les bons programmeurs pourraient débarquer avec leur code et s'affronter ou coopérer pour atteindre des buts....
En faisant cela, non seulement on résoud le problème de la 'triche' (en l'intégrant au jeu), mais en plus on ouvre les portes de la créativité.
La programmation d'un tel jeu serait plus liée à la programmation de l'environnement dans lequel joue les participants (c'est à dire le code qui tourne sur le serveur), après, c'est aux participants de tirer avantage de toutes les informations que l'on leur envoi pour visualiser ce monde. :-)
[^] # Re: Triche ???? Ou ca ???
Posté par Erwan . Évalué à 1.
[^] # Re: Triche ???? Ou ca ???
Posté par Alan_T . Évalué à 1.
Des noms, des URL !!!!! Viiite. :-)
[^] # Re: Triche ???? Ou ca ???
Posté par MagicNinja . Évalué à 2.
[^] # Re: Triche ???? Ou ca ???
Posté par Benoît Bailleux (Mastodon) . Évalué à 2.
Par contre, dans le cas des jeux ou cette approche est proposée, tu trouveras de toute façon toujours des joueurs qui ne sont pas intéressés par le développement mais par le jeux lui même, et qui se procurerons les évolutions développées par d'autre pour juste jouer en étant plus fort que l'autre (et on retombe sur le problème des "tricheurs).
# Hors sujet : et la qualité ?
Posté par boubou (site web personnel) . Évalué à 3.
[^] # Re: Hors sujet : et la qualité ?
Posté par Erwan . Évalué à 2.
Mais il y a une possibilite.
- moteur Open Source
- jeux commercial a partir du moteur, incluant des donnees copyrightees
Ca reste de l'Open Source, cad si tu veux le porter pour une autre plate-forme tu as le source, si tu veux corriger un bug tu peux le faire... Je crois que c'est ce que fait Ryzom.
[^] # Re: Hors sujet : et la qualité ?
Posté par boubou (site web personnel) . Évalué à 2.
Il y a quand même deux gros problèmes pour les jeux : 1) le gros marché, c'est les consoles et là, vu les problèmes de royalties, pas d'open source 2) un vieux jeu est un jeu mort, or l'open source capitalise à fond sur l'accumulation...
[^] # Re: Hors sujet : et la qualité ?
Posté par #3588 . Évalué à 1.
Il n'y a aucune différence, c'est juste que c'est moins bien défini : les licences libres parlent de code source, ce qui est explicite. Pour les données il y a souvent plusieurs formes possibles qu'on pourrait considérer comme sources. Une licence adaptée est préférable, mais les principales licences libres peuvent être utilisées pour ces données. C'est comparable aux programmes interprétés.
[^] # Re: Hors sujet : et la qualité ?
Posté par jojolapin . Évalué à 1.
Malheureusement le nom m'échappe, mais une bonne âme sera sûrement en mesure de nous le rappeller.
[^] # Re: Hors sujet : et la qualité ?
Posté par Arachne . Évalué à 1.
Ryzom : http://213.130.34.178/(...)
Nevrax.org : http://www.nevrax.org/(...)
[^] # Re: Hors sujet : et la qualité ?
Posté par Mathieu Pillard (site web personnel) . Évalué à 1.
http://www.nekeme.net/fr/(...)
http://arkhart.nekeme.net/fr/(...)
[^] # Re: Hors sujet : et la qualité ?
Posté par Serge Rossi (site web personnel) . Évalué à 2.
En fait, c'est pas du GPL mais c'est tout de même de l'Open Source, même si l'auteur conserve les droits :
Racer : http://www.racer.nl/(...)
Et pour une petite gallerie d'images :
http://www.racer.nl/gallery.htm(...)
C'est plus une simulation qu'un jeu, c'est super agréable à conduire, c'est le meilleur des rarissimes jeux de voitures sous Linux et les graphismes sont à tomber par terre !
Conseils pour Linux : se limiter à la 0.4.9 et récupérer d'autres pistes et voitures que celles du package de base.
[^] # Re: Hors sujet : et la qualité ?
Posté par Jar Jar Binks (site web personnel) . Évalué à 0.
La licence est comme celle de qmail, le logiciel n'est donc pas Open Source.
[^] # Re: Hors sujet : et la qualité ?
Posté par boubou (site web personnel) . Évalué à 1.
This is NOT an Open Source project, although many people think so. You CAN contribute to the source if you want (or cannot resist), but all changes will go through me to the master source code. This is done to ensure quality and consistent style for instance. Also, parts of Racer (the QLib/D3 libraries) are used in other projects, and changing the source code of this would be counterproductive for the other products that use these libraries. Therefore, the decision has been made not to OpenSource the source code.
Ceci étant, ça semble vraiment très très impressionnant pour un projet non commercial. En vraiment open source et très ambitieux, il y a flightgear qui semble aussi très bon (http://www.flightgear.org/(...) ). Cependant, et sans faire ma tête de con, au niveau gameplay, tout ça est plus que pompé.
[^] # Re: Hors sujet : et la qualité ?
Posté par Serge Rossi (site web personnel) . Évalué à 1.
[^] # Re: Hors sujet : et la qualité ?
Posté par boubou (site web personnel) . Évalué à 1.
# Sécurité vs. Open Source
Posté par Moby-Dik . Évalué à 3.
Un bon Google valant mieux qu'un long discours, si fait :
http://www.google.com/search?hl=fr&ie=ISO-8859-1&q=%22secur(...)
[^] # Re: Sécurité vs. Open Source
Posté par Pierre Tramo . Évalué à 1.
http://www.google.com/search?hl=fr&ie=ISO-8859-1&q=%22je+ne(...)
[^] # Re: Sécurité vs. Open Source
Posté par Benoît Bailleux (Mastodon) . Évalué à 1.
J'en profite pour remarquer deux choses :
- DLFP apparaît en 5 ème position dans les réponses à ta requête Google. Pas mal.
- J'ai découvert à cette occasion que Google limitait les requêtes à 10 mots (en essayant d'ajouter "site:.org" à ta requête).
J'ai donc appris qque chose : merci 8-)
[^] # Re: Sécurité vs. Open Source
Posté par Pierre Tramo . Évalué à 1.
[^] # Re: Sécurité vs. Open Source
Posté par jojolapin . Évalué à 1.
En général quand on parle de sécurité par l'obscurité, on fait allusion à des _serveurs_: il est illusoire de vouloir protéger des serveurs foireux en cachant leur source, les piratins finissant toujours par trouver les failles. Le serveur open source est protégé par les mots de passe que le piratin ne connait pas, et par sa conception robuste qui le rend insensible à toute attaque.
Ici, le problème, c'est de protéger des _clients_: par définition, le piratin a accés au client et lui fait subir ce qu'il désire, y compris son remplacement. La seule "sécurité" possible reste la façon dont le client est censé réagir face à ce que lui raconte le serveur: une fois que tu peux voir les entrailles du client, tu peux faire ce que tu veux, et ce quelle que soit la façon dont le client est conçu.
De toute façon il n'y a _pas de solution_. Dans les jeux d'action, il y a certains trucs qui sont complétement imparables, comme les aimbots (programmes qui visent à ta place): tu as de toute façon les informations afférentes (infos visuelles de position des ennemis), et tu peux de toute façon contrôler les informations efférentes (déplacement de la souris). Aprés, tu n'as absolument aucun moyen de savoir que c'est bien l'humain qui regarde l'écran et qui bouge la souris. Même si le client est hypra-méga vérouillé, il est toujours obligé d'avoir une interface avec l'humain, donc un point d'accés.
Alors à moins que l'os voire le hardware contrôle les programmes qui ont le droit de tourner (argh! qui a dit palladium ?), je ne vois pas comment on peut résoudre ce problème.
# mouarf !
Posté par Ramso . Évalué à 1.
1/ parce que c'est bien architecturé / codé
2/ parce que les autres clients et les serveurs contrôlent sans accepter bêtement
3/ parce qu'il y a toujours cette part de confiance.
Ces bonnes habitudes sont aussi vieilles que l'informatique (prévoir quelles conneries peut faire l'utilisateur). Reste à les prendre en compte dans le développement d'un jeu, qu'il soit open source ou pas.
[^] # Naze
Posté par boubou (site web personnel) . Évalué à 3.
Bref arrête de prendre les développeurs de jeux pour des cons.
[^] # Re: Naze
Posté par phq . Évalué à 1.
ça c'est de la bonne grosse psychologie de tricheur de merde.
"Je suis une sombre merde à ce jeu, mais en trichant je passe pour un pro. Comme ça j'inspire un respect que je ne mérite pas."
tricher une fois pour voir, c'est marrant. Mais tricher constamment, surtout quand il n'y a aucun intérêt final, ça reste un mystère pour moi, où est le plaisir ?
[^] # Re: Naze
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: Naze
Posté par rgardon . Évalué à 1.
# Ca ne concerne que les jeux ?
Posté par doublehp (site web personnel) . Évalué à 2.
Pour ce qui est des moyens de communications, il est normale que l'utilisateur veuille sécuriser les informations ( GPG ... )
Mais à part le jeu, quel type de programmes pose le même genre de problemes ?
C'est pour moi le seul cas ou le fait de déléguer une partie de la sécurite ( ie : faire confiance à l'utilisateur ) pose un problème !
J'ai faux ?
( je ne parle pas de l'aspect "attaque" d'autruis vers un service, mais seulement de la nécéssité que l'utilisateur ne puisse pas modifier le programme )
[^] # Re: Ca ne concerne que les jeux ?
Posté par Jonathan ILIAS-PILLET (site web personnel) . Évalué à 2.
Je pense aux réseau P2P (freenet utilise d'ailleurs une protection pour conserver son intégrité), aux calculs distribués tels que celui lancé récemment par le Téléthon...
Petite réflexion personnelle : la confiance nous permet de faire des économies (en temps, en complexité, en performances, en argent, ...), même au delà des logiciels. En effet, quel commerçant appelle la banque de son client lorsque celui-ci fait un chèque, qui fait examiner pointilleusement son contrat de travail et sa convention collective par un juriste, ... ?
En ce qui concerne les jeux, je rejoindrai l'avis d'Emmanuel Fleury : la tricherie n'a rien de nouveau. Selon les joueurs et les jeux, elles est acceptée, tolérée ou bannie mais est par définition difficile à déceler... Prenons un peu de recul sur la technique pour mieux identifier les besoins réels de sécurité...
# Re: Une limite de l'OpenSource ?
Posté par Julien Duponchelle (site web personnel) . Évalué à 1.
Les mods Open-Source (je parle des mods car c'est encore les jeux les plussérieux dévellopé) n'existe pas..... Et pourtant certains projets pourrait peut être rédemarrer en passant open-source. Botman a crée des bots open-source mais malheuresement à peu prêt tous les projets qui en on dérivé sont devenu closed-source (comme les POD bot).
Les dévellopeurs de jeux ont peur pour leur code source... alors que au final c'est généralement le moins facile à réutiliser puisque trés complexe.
Ce qui manque c'est un vrais moteur Open-Source avec un support de mod trés puissant et simple.
# Efficacité vs Sécurité
Posté par Alan_T . Évalué à 1.
Arretez-moi si je me trompe, mais, je crois avoir compris que dans des jeux comme Quake, le nombre d'informations qui sont envoyées à chaque client est beaucoup plus importante que ce que le joueur peut voir/entendre dans son environement proche.
Peut-être est-ce là une erreur de la part des concepteurs des jeux. Après tout, les "tricheurs" ne font que tirer partie de toutes les informations dont dispose leur client. Vouloir cacher des informations après les avoir envoyées au client me semble un peu utopique.
Pourquoi ne pas faire des protocoles qui n'enverraient au client que les informations nécessaires et rien de plus ?
Évidemment, il y a des moyens d'obtenir des informations supplémentaires, par exemple en connectant des joueurs fantômes et en les plaçant judicieusement sur la map. Mais cela se verrait assez facilement.
Reste le problème de la gestion de la position du personnage. J'avais entendu parler d'un programme qui changait la coordonnée Z (altitude) de tous les shoots. Ce qui faisait que le joueur apparaissait "invulnérable". Il faudrait trouver un méchanisme (rapide si possible) pour empecher le joueur de modifier des données qui viennent du serveur. La signature par clef privé du message est un solution qui requière vraiment beaucoup de CPU et un simple CRC est trop facile à craquer... Quant à gérer tous les mouvements du joueur sur le serveur même (et non plus sur le client), on perd l'aspect distribué du logiciel (et le serveur doit avoir une puissance de calcul importante).
Bref, c'est une question intéressante.
Quelqu'un connait-il les différentes méthodes qu'emploient les jeux en réseau actuellement pour résoudre ce genre de problème ?
[^] # Re: Efficacité vs Sécurité
Posté par Gruik Man . Évalué à 1.
Lorsque tu dis
Ne réponds-tu pas à ta question? Il me semble largement aussi utopique de forcer le client à prendre en compte les données venant du serveur, que de forcer le client à ne pas prendre en compte des données venant du serveur... A vrai dire, il est utopique de forcer le client à quoi que ce soit, point.
N'oublie pas, logiciel proprio ou pas, à la base, c'est celui qui possède la station qui est maître de toutes les opérations qu'elle effectuera.
La solution? Elle est simple. C'est de ne pas laisser aux joueurs (ou à leurs machines, mais c'est pareil) le choix de décider si un perso meurt ou pas. C'est au serveur de déterminer ça.
Après, si le joueur décide d'ignorer le paquet qui dit « Vous êtes mort », grand bien lui fasse. Il pourra toujours continuer à envoyer des ordres de déplacement pour un corps marqué « mort » (même s'il a décidé que chez lui, le corps était vivant), et se prendre en retour des messages « pas possible » du serveur.
[^] # Re: Efficacité vs Sécurité
Posté par Alan_T . Évalué à 1.
En fait, si j'essaye de faire une synthèse, les hypothèses de base sont:
1) Le client ne peut être digne de confiance.
2) Le serveur est considéré comme un tier de confiance par tous les clients.
Et pour l'instant, la triche se fait par:
1) Une main mise complète sur les choix qui sont laissés au client.
La solution pour contrer cela étant de diviser en deux catégories claire, les évènements qui peuvent être décidés par le client et ceux qui doivent être décidé par le serveur.
2) L'utilisation d'information envoyée au client mais pas visualisées par celui-ci.
La solution pour contrer cela étant de n'envoyer au client que les informations minimum car on ne peut pas faire confiance au client.
Évidemment, nous avons exclu ici toute idée de performance. Ce qui simplifie considérablement les données du problème. D'un autre coté, si la triche détruit le jeu, il serait bon de diminuer ces performances et de respecter un peu plus les règles citées ci-dessus.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.