| 04-05-2010 14:29:41 | #1 | |
| okhin | (ok, le nom est foireux). Vu le nombre improbable de topic de questiosn sur la matrice, je propose à tout ceux qui ont un peu de temps (notament Blade, Valérian, Mephisto, Fantôme, chromed.cc) d'essayer de travailler ensemble pour proposer un guide de matrice révisée en essayant de répondre aux principales questions. De mon point de vue, on peut pondre carrément une Matrice v3.0 (ou 2.5) en refondant certains concepts. Dans un premier temps, merci de vous enrôler ci-dessous, on verra pour bosser soit sur un wiki (@Fourb' c'est faisable d'en installer un sur les SF?), soit directement sur le Cybi (bien que je pense que la forme ne soit aps bonne) soit sur une Wave. Déjà, on peut commencer par recenser tous les threads/posts qui serviront probableemnt par la suite, et dresser un premier sommaire. Il reste important, AMHA, de bosser d'abord sur le FLUFF (comment et à quoi ressemble la matrice, son intégration au quotidien, son architecture, etc) puis de proposer les règles (idéalement, en gardant une compatibilité SR4A). Sources internes: - Questions diverses et points de règles * Système d'authentification par clef * Cryptage et hacking * Diverses questions * IND, Datajack et connexin matricielle * Protection de comlink * Matrice et Signal * Le cybercombat * Agent et personna * Coût des utilitaires * Privilèges de comptes * Plantage et Disarm * SIN et ID * Filtre de RV * Technomanciens * Dronomancer * Recherche de données * les passes d'initiatives matricielles - Propositions de règles alternatives * Passes matricielles simplifées et ouvertes à tous - par Blade * Test matriciels sur Informatique + Logique - par Gris-Gris * Hacking alternatif - par Valérian * Hacking rapide - par Blade Voilà, je croit que j'ai tout (juste sur 3 pages de topics). Au niveau des questiosn posées (et répondues), je pense qu'on a rpesque tous les aspects de la matrice. Reste plsu qu'à trier et faire un premier sommaire avant d'attaquer la suite. So, who's in? Okhin | |
| 04-05-2010 14:32:40 | #2 | |
| Blade | Avant de partir dans tous les sens, je pense qu'il faut définir ce qu'on fait : 1. Un guide pour aider à comprendre la matrice SR4A+Unwired 2. Un guide pour aider à comprendre une matrice basée sur SR4A+Unwired mais avec des changements 3. Une refonte des règles matricielles | |
| 04-05-2010 14:38:29 | #3 | |
| okhin | Tant qu'à écrire, je pencherait pour du 2 et/ou du 3. En gros, faire un système compatible SR4A sans trop de heurts (donc, garder le comlinks, les ndoes, les agents, technomanciens et utilitaires) mais balancer toute la partie infrastructure, RA et RV trop calquée sur ce qu'on connait en essayant d'en faire quelque chose de plus global et donc utilisable simplement. Okhin | |
| 04-05-2010 14:40:35 | #4 | |
| Robin des Ombres | Pour ce qui est du support technique, oui, c'est faisable d'installer un wiki public de travail. Si il faut que le wiki soit privé, avec de la gestion de droits d'accès, c'est déjà plus contraignant. Je vais d'ailleurs en profiter pour ouvrir un topic là dessus dans la section concernée. | |
| 04-05-2010 14:42:26 | #5 | |
| Blade | Lourde tâche, notamment pour trouver une vision qui plaise à tout le monde... Mais je veux bien m'y essayer. | |
| 04-05-2010 14:47:49 | #6 | |
| okhin | Bah, je pense qu'on a une approche relativement identique. Ça coince sur des points de détails, mais comme on est entre gens civilisés, je pense que ça peut le faire. Petit détail, cette sous-section est visible par tout le monde oupas? @Robin merci pour le wiki. Pas besoin d'un truc privé avec gestion de droit, juste quelque chose qui nécessite un compte pour modifier ça pourriat le faire (masi ce n'est pas nécessaire, on peut vivre sans). Okhin | |
| 04-05-2010 14:54:40 | #7 | |
| Blade | Oui, la section projets forumiens est visible par tous. | |
| 04-05-2010 15:46:45 | #8 | |
| M. Jonson | je n'ai pas retrouvé l'article de Blade pour la matrice SR4. (y'a déjà qques années maintenant). c'est une bonne base non ? | |
| 04-05-2010 16:02:57 | #9 | |
| okhin | Ah oui, coincé dans le Cybi, faut que je fasse un datasearch (mais il y a 2-3 points qui me chagrinait un poil à l'époque). Okhin | |
| 04-05-2010 16:11:14 | #10 | |
| Robin des Ombres | http://www.shadowforums.com/wiki/pmwiki.php/MURGE/MURGE | |
| 04-05-2010 16:12:40 | #11 | |
| okhin | Merki chef. Okhin | |
| 04-05-2010 16:15:16 | #12 | |
| Blade | Il est sur Cybi, mais il est un peu vieux maintenant. Il ne prend pas en compte certaines précisions d'Unwired (et de SR4A) et est peut-être même en contradiction avec eux sur certains points. | |
| 04-05-2010 17:20:28 | #13 | |
| okhin | Bon, j'ai changé la première page du projet sur le wiki. Je pense qu'il faut qu'on parte dans une option de type 2, ie qu'on garde le système de règle en l'état dasn la mesure du possible, masi qu'il ne soit pas non plus un frein trop important. Tant que j'y pense, il faudrait mettre le tout sous licence CC by-sa, mais je ne sait pas si on peut le faire (c'ets un travail dérivé à priori, donc pas de suoci avec la licence SR4, mais sait-on jamais). Okhin | |
| 04-05-2010 18:32:38 | #14 | |
| Leoric | Si je puis me permettre, je vous suggererai de faire une aide de jeu de la maniere suivante: - Un guide pour aider à comprendre une matrice basée sur SR4A+Unwired, canon - Y inclure (de maniere visible et balisée) vos elements perso, regles alter, interpretations soumises à controverse, etc Comme ça, ça pourra interresser plus de monde. | |
| 04-05-2010 18:51:50 | #15 | |
| Gris-Gris | Je suis en train d'écrire une petite aide à ma manière (beaucoup plus modeste que ce qui est en train de se préparer). L'idée c'est de partir sur des exemples concrets et de donner une réalisation en termes de tests à effectuer (c'est un modèle qui m'a été soufflé par Valerian). J'ai aussi recensé les différents types d'actions faisables avec différents types de comptes (utilisateur / sécu / admin). C'est pas loin d'être prêt à être proposé. Dans les semaines qui arrivent, je vous enverrai le contenu sur le post que j'y avais consacré. On verra à ce moment là s'il vaut mieux séparer les deux projets ou si ce que j'ai fait peut contribuer à celui-ci. En tous cas, je salue l'idée de faire un guide, pour y participer ou en profiter ! | |
| 04-05-2010 19:47:22 | #16 | |
| Cougar | Leoric a écrit: Si je puis me permettre, je vous suggererai de faire une aide de jeu de la maniere suivante: - Un guide pour aider à comprendre une matrice basée sur SR4A+Unwired, canon - Y inclure (de maniere visible et balisée) vos elements perso, regles alter, interpretations soumises à controverse, etc Comme ça, ça pourra interresser plus de monde. En mettant les règles perso en encart, genre règle optionnelle ça serait top. Comme ça chacun prend ce qu'il veut. | |
| 04-05-2010 19:52:58 | #17 | |
| Tatourmi | Leoric a écrit: Si je puis me permettre, je vous suggererai de faire une aide de jeu de la maniere suivante: - Un guide pour aider à comprendre une matrice basée sur SR4A+Unwired, canon - Y inclure (de maniere visible et balisée) vos elements perso, regles alter, interpretations soumises à controverse, etc Comme ça, ça pourra interresser plus de monde. Tout à fait d'accord, en tant que nouveau venu en tout cas je dois avouer que j'ai la trouille dès qu'on me parle de "règles optionnelles". Je supporte aussi complètement la démarche de Gris-Gris visant à "concrétiser" la matrice à travers des exemples précis de deux trois systèmes de sécurité différents et autres. Bonne chance à tous en tout cas. | |
| 05-05-2010 09:02:43 | #18 | |
| K-ZimiR | Leoric a écrit: Si je puis me permettre, je vous suggererai de faire une aide de jeu de la maniere suivante: - Un guide pour aider à comprendre une matrice basée sur SR4A+Unwired, canon - Y inclure (de maniere visible et balisée) vos elements perso, regles alter, interpretations soumises à controverse, etc Comme ça, ça pourra interresser plus de monde. Il a de bonnes idees ce borg ... | |
| 05-05-2010 09:52:23 | #19 | |
| okhin | En fait, le principal souci qu'on a (tous, que ce soit les hackers IRL, les profanes, les débutants de la matrice ou les vétérans) c'est que la matrice de SR4 est trop calquée sur la matrice de notre monde, ce qui lui colle des limitations étrange (d'autant que c'ets callé sur les trcus à la mode ya deux ans, donc c'est complètement has been) notamment l'architecture matricielles qui est abstraite, mais pas, ou si peut-être, ça va dépendre. Du coup fournir un guide de compréhension de la matrice pour les MJs est une tâche complexe (vu qu'il n'y a pas de règles d'archi comme en SR3, masi que cela semble nécessaire sinon on résume tout à une passe, un nœud) Je voit plus le truc comme une propale de règle alternative (mais compatible SR4 cependant) avec un guide pour l'utiliser. Okhin | |
| 05-05-2010 20:51:07 | #20 | |
| Elias Mattheus Laedon | Leoric a écrit: Si je puis me permettre, je vous suggererai de faire une aide de jeu de la maniere suivante: - Un guide pour aider à comprendre une matrice basée sur SR4A+Unwired, canon - Y inclure (de maniere visible et balisée) vos elements perso, regles alter, interpretations soumises à controverse, etc Comme ça, ça pourra interresser plus de monde. au final, un gros gros bouquin avec plein de marges autour du texte, sur lequel on fondera une religion !  | |
| 05-05-2010 21:27:18 | #21 | |
| Valérian | Je veux bien participé pour le coté règles et donner mon avis sur le fluff, mais la rédaction j'ai pas trop de style donc ca le fait pas trop. Sinon pour la forme à donner au projet, je suis de l'avis de Leoric. Il vaut mieux rester proche du canon autant que possible car plus on s'éloigne, et moins ca intéresse de monde. Il faut aussi indiquer clairement quelles règles on change comme il le préconise. Faudrait aussi voir quel périmètre ont défini pour le projet : La matrice au quotidien ? L'architecture des noeuds sécurisés ? La passe matricielle du hackeur ? La guerre électronique ? Tout cela, autre chose ou simplement une partie ? | |
| 05-05-2010 21:30:52 | #22 | |
| okhin | D'accord pour les balises. Rapport à l'alter je pense que c'est surtout pour ne pas se limiter à tout faire avec le système de jeu actuel qui a certaines qualités et des faiblesses/lacunes. Quand au côté rédactionnel, déjà balanceons les idées, les orientations, on patchera/attachera ça en cours de route (quitte àd ébaucher des ressources du Cybi (Dodge attaque de Sly)). Et le wiki est ouvert à tous, donc allez-y, je vais commecner à essayer de poser quelques poinst et à syntéhtiser les threads demain. Okhin | |
| 06-05-2010 01:06:27 | #23 | |
| Valérian | Personnellement, les points qu'il me semble intéressant de développer sont les suivants : Hacking : Préciser le principe de sonder un noeud pour en déduire quels moyens un administrateur peut mettre en place pour lutter contre (par exemple en rendant le noeud accessible uniquement depuis un autre noeud, de sorte que ceux qui sondent sont repérables dans le noeud portail...). Définir le principe auquel obéit un compte hacké pour en déduire ses limitations et possibilités en terme de hacking une fois dans le noeud (voir par exemple ce que j'ai proposé dans mon topic sur le hacking dans un noeud). Rendre "visuel" une passe matriciel par le biais de la métaphore (en faisant une analogie avec le monde physique). Définir à quoi sert un programme furtivité dans ce contexte et donner un rôle prépondérant aux défenses actifs (les CI et spider) dans ce cadre. Définir les actions classiques de hacking dans un noeud (voler des données, effacer ses traces, prendre le contrôle du noeud...) ainsi que les mesures que mettent en oeuvre les experts en sécurité matricielle pour empêcher le hackeur d'arriver à ses fins. Cela nécessitera probablement de définir les données critiques de paramétrage (journal d'accès, tables des comptes utilisateurs...). Faire le tri dans les règles d'Unwired concernant le hacking pour développer ce qui le mérite (virus, troyens...) et simplifier/retirer ce qui est galère ou mal équilibré (backdoor, DOS, proxy, botnet...). Architecture d'un PAN avec exemple pour un runner type (afin de réexpliquer les caracs d'un commlink, la persona, les abonnements). Exemples de RA au quotidien. Réexepliquer les principes de la guerre électronique (notamment l'interception de signaux en vue de hacker les systèmes adverses) avec un exemple pour un gars lambda et un exemple pour faire face à un runner (lequel prend plus de précautions et cherche à se planquer). Ca doit mettre ainsi en évidence les pistes de défense que met un rigger en place pour protéger son réseau de communication et ses drones. Réexpliquer le principes de falsification, notamment à quoi cela s'applique. Donner des pistes pour classer les ordres dans une des catégories (utilisateur, sécurité, admin, refus automatique) et donner des exemples de falsification d'ordre. Exemple de cybercombat avec diverses stratégies pour pourrir l'adversaire. Ca peut être l'occasion d'expliqué le rôle des options de programme qui sont utiles pour enrichir les possibilités. Donner un mode opératoire pour définir une architecture d'un système matriciel (définir l'organisation en fonction des besoins utilisateurs et la sécurité matricielle en fonction des risques de hacking et des moyens). Vous conviendrez que cela fait déjà potentiellement beaucoup de boulot si on suit un schéma "Fluff, règles, exemples". | |
| 06-05-2010 10:08:35 | #24 | |
| Blade | Pour moi, il faut permettre aux gens de s'approprier la Matrice, en passant par des métaphores avec le monde physique (qui sont souvent plutôt efficaces, plus que de faire la comparaison avec l'informatique actuelle en tout cas) plutôt que leur balancer une liste d'actions et d'exemples de noeuds qu'ils suivraient à la lettre sans comprendre. | |
| 09-05-2010 00:34:29 | #25 | |
| Valérian | J'ai mis sur le wiki MURGE quelques considérations tactiques pour le cybercombat ainsi que 2 règles alter : la full défense en cybercombat et le programme surcharge d'Unwired qui est abusé. | |
| 11-05-2010 00:39:22 | #26 | |
| Valérian | J'ai réfléchit un peu à la partie "Guerre électronique" (scan, intercepter des communications, cryptage/décryptage et brouillage), mais il y a un certain nombre de choses à définir en amont pour donner du sens aux actions à réaliser et ainsi clarifier les règles : Un des premiers aspects de la guerre électronique c'est de scanner pour détecter un noeud en mode caché. L'intérêt d'un noeud caché en matière de défense contre le hacking est évident : pas vu = pas hacké. Toutefois la règle canon donne 2 méthodes pour détecter un noeud caché : le détecter directement, ce qui est assez chaud (jet avec seuil de 4) ou bien détecter tous les noeuds cachés (jet étendu) puis logiquement faire du tri dans les résultats. C'est là où ca mérite des éclaircissements : Quelles informations fournissent les noeuds lors d'un scan, car il faut bien pouvoir faire un tri si on veut identifier le noeud caché correspondant au commlink de la personne qu'on suspecte avoir un tel commlink ? Pour la méthode directe, en quoi le fait de suspecter une personne donnée est important pour lancer un scan qui doit être logiquement omnidirectionnel vu qu'il passe par l'antenne de votre commlink ? Vu qu'un noeud caché est censé ne pas répondre à un scan, comment on peut lui forcer la main pour récupérer son commlink ? Comme la détection de l'accessID de la "cible" est la base de tout en guerre électronique, il faut répondre à ces questions et éclaircir ce point. Passons maintenant à l'interception de communication. L'action correspondante a un pré-requis qui consiste à connaitre une accessID dont on veut espionner les communications entrantes ou sortantes. En fait, cette action consiste à examiner ce que reçoit votre commlink comme communication wifi, dans le but de détecter les références à cette accessID dans les communications (afin de ne garder que les messages qui nous préoccupent). Pour qu'une communication puisse être interceptée, il faut encore qu'on la capte, c'est pourquoi on n'intercepte que les communications émises par un noeud dont on est dans le périmètre de son Signal. Ce qui implique bien souvent des contraintes spatiales si la cible dont on veut espionner les communications utilise un signal faible (signal 1 soit 40m ou signal 2 soit 100m suffisent en ville généralement) vu qu'il va falloir s'approcher ou envoyer un drone espionner pour vous près de la cible. Il peut être nécessaire de décrypter les communications interceptées... sauf que les règles stipulent qu'il faut d'abord décrypter puis intercepter les communications, ce qui est un contre-intuitif pour beaucoup. Autre truc qui ne m'avait pas choqué sur le coup mais qui pose problème quand on se penche dessus : pour intercepter des communications, il faut soit un programme Renifleur (programme de hacking donc pas donné)... soit un scanner de fréquence radio au prix faramineux de 25Y x Indice (1-6) soit 150Y max (pour un programme à 6000Y). En fait c'est encore plus bourrin que l'émotitoy ce truc. Je serais partisan de considérer que ce senseur n'est pas livré avec un programme renifleur (qu'il faut donc l'acheter à part), mais qu'il est plus efficace qu'une antenne de commlink classique vu qu'elle permet de localiser la direction et la distance d'une émission radio. Le scanner permet aussi d'intercepter une communication utilisant des fréquences radio inhabituelle (une modification de commlink d'Unwired permet de changer de gamme de fréquence). Pour savoir comment on décrypte une communication interceptée, il faut savoir comment on crypte, donc comment fonctionne les communications matricielles. Ce que j'ai compris, c'est qu'une transmission d'info contient un accessID identifiant l'émetteur, un accessID identifiant le destinataire et un contenu (lequel peut être crypté). Ainsi, le paquet de données peut facilement être routé vu que l'émetteur et le destinataire sont définis en clair. Toutefois dans ce schéma, le cryptage doit se faire après interception (pour qu'il se fasse avant il faudrait que les infos sur l'émetteur et le destinataire soit cryptées, ce qui ne parait chiant pour le routage). Le cryptage requérant de manière canon un abonnement (Rappel de mon interprétation du cryptage de communication), on peut se poser la question si le fait d'avoir un abonnement (qui se définit comme une liaison bi-directionnelle permanente à haut débit) change quelque chose à la transmission de données par paquets telle que je l'ai évoquée ci-dessus ? Autre élément dans les règles pouvant servir à nous faire une idée (ou à préciser si cela s'avère non compatible avec des règles revues) : dans SR4A, pour l'exemple d'interception de communication wifi, il est dit qu'après avoir intercepté les communications entre un drone et un rigger, on peut réaliser un pistage matriciel pour remonter l'abonnement jusqu'au rigger et chopper ainsi son accessID. Avec une interprétation des données par paquets avec émetteur et destinataire, on récupère son accessID dès l'interception des communications du drone. Concernant le brouillage, je trouve chiant que le niveau d'un brouillage décroit de manière très rapide dans l'espace alors que ce n'est pas le cas pour les transmissions wifi qui portent plus loin à niveau constant. Du coup, les brouilleurs ont une utilité limitée si on est pas très près de la cible. Pour corriger cela, on peut envisager plein de solutions : 1) avoir un niveau de brouillage constant jusqu'à sa portée maximale (comme pour un Signal classique). 2) avoir des signaux de communication dont le niveau décroit aussi avec la distance (à distance max on émet avec une puissance apparente de 1). 3) utiliser les portées de signal classiques pour les portées de brouilleur (on peut se poser la question du pourquoi des portées aussi faibles ?). Maintenant il faut voir que ca peut être chiant d'avoir un brouilleur susceptible de brouiller une large portion de la ville : ca fou le dawa partout quand on l'utilise. Voilà c'était mes idées (et interrogations) sur le sujet guerre électronique. | |
| 14-05-2010 18:32:05 | #27 | |
| Valérian | Petite question d'organisation : Est-ce qu'il ne faudrait pas ouvrir des topics dédiés à des sous aspects du projet plutôt que de tout poster ici, car j'ai peur que ca devienne rapidement compliqué de se retrouver dans les échanges entre posteurs si tout est mélangé ? Si on part sur des topics dédiés, ont les crées dans le forum "Projets forumiens" ou dans "règles alter" ? | |
| 15-05-2010 13:25:37 | #28 | |
| Mephisto | J'ai également un point sur la matrice qui me pose problème: la localisation physique de nœuds. J'avais soulevé la question sur Dumpshock il y a un petit temps et, d'après ce qu'il en est ressorti, il semblerait effectivement qu'il y ait quelques lacunes au niveau des règles à ce sujet. Peut être que quelqu'un ici trouvera une meilleure explication, sinon c'est peut être l'occasion de proposer des règles alternatives dans le cadre de ce projet. | |
| 15-05-2010 14:35:52 | #29 | |
| Mephisto | Cougar a écrit: En mettant les règles perso en encart, genre règle optionnelle ça serait top. Comme ça chacun prend ce qu'il veut. Je suis d'accord, ce serait bien qu'on puisse facilement faire la distinction entre les règles officielles et alternatives. | |
| 18-05-2010 12:19:26 | #30 | |
| okhin | Bon, ça avance (lentement, masi sûrmeent). Un peu de strcuturation du wiki, et je commence à remplir ça avec tout ce qui a été posté. Les bonnes âmes rédactionelles sont les bienvenues. Okhin (http://www.shadowforums.com/wiki/pmwiki.php/MURGE/) | |
| 18-05-2010 23:21:12 | #31 | |
| Valérian | On ne poste sur le wiki que les trucs ficelés et on discute dans le forum des trucs pas définitifs... ou pas ? | |
| 19-05-2010 01:12:07 | #32 | |
| okhin | pas. La forme du wiki permet de discuter, éditer, modifier, récupérer les anciennes versions, toussa. Okhin | |