| 02-09-2011 00:37:04 | #1 | |
| Valérian | On a souvent évoqué sur le forum le manque de vision pour la matrice qui a coté « internet en 2070 » très marqué et Unwired n'a rien arrangé en introduisant des tas de notions qui ressemble plus à l'état de l'art 2001 (attaque DOS, botnet, VPN...) que 2070. En plus de cela, les règles matricielles ne sont pas vraiment simples et surtout ne sont pas très bien équilibrées. Je m'explique : pour hacker un noeud, vous avez le choix entre le hack à la volée et le hack par repérage. Vu les jets à faire pour hacker le noeud (jet étendu contre Firewall avec +3 ou +6 éventuel) et le jet de détection en opposition (Firewall+analyse en étendu avec un seuil égal à Furtivité), ca devient très vite impossible de rentrer dans un noeud sauf à obtenir tous ses succès en 1 seul jet (le firewall met assez facilement 2 tours pour obtenir ses Furtivité succès). A coté de cela, le hack avec repérage permet à n'importe quel newbee du hacking avec un bon programme Furtivité (indice 5) de craquer le pire noeud de la ZurichOrb (noeud à 6 partout) sans même une goutte de sueur car le noeud n'a droit qu'à un seul jet de détection et que sauf glitch, le newbee pourra cumuler ses 18 succès (Firewall+système+6 pour avoir un compte admin). Du coup, j'ai commencé à réfléchir à une autre manière de concevoir la matrice (plus abstraite) avec des règles essayant d'être plus équilibrées, plus simples mais en gardant un potentiel de complexité pour les MJ qui veulent allez plus loin pour offrir un challenge à un joueur hacker.... rien que cela. Comme j'ai une bonne base mais que je me pose encore des questions sur certains points, je compte vous faire partager mes réflexions pour recueillir vos avis et remarques. Tout d'abord, une première remarque : s'il y a une grosse demande de certains pour des règles matricielles ultra light afin d'être très rapides (ce qui est ressorti dans plusieurs discussions ces derniers temps), j'aborde ici des règles qui correspondent à une passe matricielle complète (donc beaucoup plus long, vous voilà prévenus) car j'ai abandonné rapidement l'idée d'une règle unique couvrant simplement les 2 aspects. Toutefois, par certains mécanismes de règles utilisés, j'ai gardé à l'esprit ce besoin de simplicité. Voilà pour l'intro, maintenant passons aux choses sérieuses... Pour avoir une matrice restant le plus possible abstraite et simple à comprendre pour le joueur, ce qui me paraît le mieux c'est de procéder par analogie avec quelque chose de plus facile à appréhender et en l'occurrence, je vois une passe matricielle comme une tentative d'infiltration d'un lieu plus ou moins protégé (en plus, cela facilite aussi la vie au MJ dans la description de la métaphore du noeud). D'emblée, cela a un gros impact sur les règles car on sort du principe où tout se joue sur l'introduction du hacker dans le noeud (si vous obtenez un compte bidon avec un droit d'admin c'est « game over » pour la défense matricielle pour reprendre une expression d'Okhin), pour rentrer dans un principe où c'est seulement la première barrière et que le problème est plus d''arriver à rester dans le noeud si le propriétaire a eu la riche idée d'y mettre des CI, un spider, des bombes matricielles... Du coup, le degré de sécurité matricielle d'un noeud sera moins une question d'attribut du noeud (même si ca joue aussi) que de défenses actives (avec la part belle données aux CI qui ne servent pas à grand chose dans les règles officielles) dans le noeud. Cela se traduit au niveau de l'analogie avec une infiltration classique par pénétrer dans un jardin en sautant un muret, fracturer le cadenas sur la porte de l'abri de jardin et prendre les outils que vous voulez (pour un noeud sans véritable défense, genre le commlink de monsieur tout le monde) ou bien vous vous infiltrez dans une forteresse située sur un piton rocheux avec des patrouilles sur le chemin de ronde et dans la cour intérieure, des pièges à chaque porte et enfin quand vous trouvez le chemin qui mène à la salle du trésor, il faut encore vaincre le gardien qui campe devant la porte (fallait pas venir dans un noeud corporatiste ultra protégé). Règles – Partie 1 : Infiltrer un noeud par hacking Pour rentrer dans un noeud par hacking, le hackeur doit faire un test étendu de Hacking+Exploitation pour atteindre un seuil égal à Système+Firewall du noeud visé, l'intervalle du test étendu est de 1 Passe d'Initiative. A chaque fois que le hackeur fait un jet pour son test étendu, le noeud fait un test étendu de Système+Firewall pour atteindre un seuil égal à Réponse+Furtivité du hackeur. Si le noeud atteint ce seuil, la tentative de hacking échoue. J'ai fait quelques estimations rapidement (en comptant 1 succès pour 3 dés), et grosso modo, un hackeur moyen a intérêt à avoir un commlink de puissance similaire au noeud visé (en terme d'attribut) pour avoir une bonne chance de réussir sa tentative. Autrement dit, il faut être sacrément doué pour espérer infiltrer un noeud d'indice élevé (5 ou 6) avec un commlink de base (indice 3). D'autre part, un agent de hacking d'indice 3 aura a peu près une chance sur deux de réussir à hacker automatiquement un commlink d'indice 3 mais servira a rien contre un commlink ne serais-ce que d'indice 4 (une commlink plutôt haut de gamme pour le grand public). Bref, ca me paraît plus équilibré que les 2 méthodes proposées dans les règles officielles. Pour info, j'ai choisi de virer le programme Analyse de l'équation (en le remplaçant par Système) dans un but de simplification. J'ai aussi préféré donner un seuil pour la détection de Réponse+Furtivité car Furtivité tout seul, ce n'est pas assez et Furtivité x2, ca donnait trop d'importance à ce programme. Réponse a aussi un avantage à mes yeux, c'est d'offrir le choix au hackeur : soit il tente de rentrer dans le noeud avec plein de programmes déjà actif (ce qui baisse la réponse comme dans les règles officielles) au risque de se faire chopper. Soit il rentrer avec le strict minimum (Furtivité, Exploitation et Analyse) et donc sa réponse max, mais dans ce cas, il risque de ne pas avoir le temps de faire ce qu'il veut dans le noeud (je reviendrai plus loin sur cette notion de temps limité). Enfin, la Réponse est l'équivalent matriciel de la Réaction, aussi sa traduit au niveau de la métaphore d'infiltration, le fait de se planquer rapidement dans l'ombre quand une caméra ou un projecteur est à votre recherche. Comme je l'ai déjà dit plus haut, j'ai viré la notion de compte sécurité ou admin dans ce jet pour s'infiltrer dans le noeud. J'ai aussi viré le fait de prendre son temps (hacking par repérage) car les règles officielles étaient beaucoup trop faciles par cette méthode. A la place, je verrais plutôt une démarche d'analyse de la part du hackeur et d'utilisation de ses relations. En gros, il peut chercher à obtenir des infos sur le système visé (puissance, type et marque, degré de mise à jour de l'OS et du Firewall en gros), par exemple en faisant une première tentative de hacking, puis après il peut prendre des contacts parmi la communauté des hackeurs pour obtenir des astuces de piratage de ce type de matos, ce qui se traduira au niveau règles par des bonus au jet de Hacking+Exploitation ou des bonus au seuil de Réponse+furtivité. En effet, je trouve cet aspect relationnel bien plus intéressant à développer par le joueur et le MJ que simplement réduire cela à une question de temps. Donc par les règles ci-dessus, il est possible de s'introduire dans un noeud. Reste maintenant à voir ce que l'on peut y faire en tant qu'intrus et comment essayer de se prémunir de ce genre d'intrusion (quand c'est vous qui êtes la cible d'un hacking). L'idée c'est que la sécurité matricielle peut être décomposée en trois morceaux : - La gestion des droits utilisateurs que le hackeur va devoir contourner plus ou moins facilement. - Des défenses passives (cryptage, bombes matricielles, données cachées) qui servent plutôt à ralentir un hackeur doué et qui ne peuvent vraiment gêner qu'un hackeur newbee ou imprudent. - Des défenses actives (CI en patrouille, CI gardienne, spider) qui vont sérieusement compliquer la vie du hackeur et qui seront aussi charger de lui botter le cul une fois qu'il sera repérer. En dosant savamment tout cela, il est possible d'offrir à un joueur hackeur un certain challenge dans sa passe matricielle, et de varier les passes d'un scénar à un autre en jouant sur la métaphore et des variantes de schéma défensif. Notamment, je trouve intéressant la notion d'options de programme introduite dans Unwired car en l'adaptant un peu, elle permet au joueur de se tailler un commlink et des programmes customisés (il n'y a pas de raison que seul les streetsams puissent faire de la customisation de leurs armes), mais aussi au MJ de surprendre son joueur, éventuellement avec des options exotiques (par exemple avec des CI loup-garou... qui ont un autosoft régénérant leur blessure matricielle, lequel peut être contré par un programme d'attaque avec une option « en argent »). Avant de détailler les règles pour les différents niveaux de sécurité matricielle, je voulais dire qu'un des buts recherchés était de créer une situation où le hackeur peut être pris par le temps s'il veut faire des choses dans un noeud avant qu'une alarme soit déclenchée et que la situation se corse, enfin s'il y a un minimum de sécurité matricielle dans le noeud car sinon c'est une formalité pour un hackeur confirmé de faire ce qu'il veut (par exemple un fois rentré dans le commlink bas de gamme d'un esclave corpo). Règles – Partie 2 : contourner les droits utilisateurs Un hackeur peut chercher à accéder à des données ou des fonctionnalités du noeud. Le mécanisme pour contourner les droits utilisateurs repose sur un test simple de Hacking+Exploitation avec un seuil dépendant de ce que l'on cherche à faire ainsi que des circonstances. Si le test est réussi, le hackeur arrive à faire ce qu'il voulait mais en cas contraire, une alerte est déclenchée. Chaque action pour contourner les droits prend une action complexe, mais parfois cela peut être plus long en cas de reprogrammation ou d'édition. Seuils de base : Faire planter une fonctionnalité : 1 Utiliser une fonctionnalité : 2 Reprogrammer une fonctionnalité : 3 Lire/copier un fichier de données : 1 Editer/supprimer un fichier de données : 2 Modificateurs au seuil : Fonctionnalité/données nécessitant des droits de niveau sécurité : +1 Fonctionnalité/données nécessitant des droits de niveau admin : +2 Réaliser un hacking sans lancer de traces : +1 Alerte active dans le noeud : +1 Spider gérant la sécurité du noeud en permanence : +1 Une fonctionnalité ou une donnée peut être destinée à des utilisateurs (+0), un compte sécurité (+1) ou un compte admin (+2), aussi le modificateur de sécurité et d'admin ne se cumulent pas. C'est au MJ de déterminer le niveau de droit d'une fonctionnalité ou d'une donnée. Toute modification d'une donnée ou un accès à une fonctionnalité laisse une trace dans le système, sauf si le hackeur décide d'augmenter le seuil de un point pour réaliser son action sans laisser de trace. Dès qu'une alerte est déclenchée, le seuil de toutes les actions augmentent de un. Pour qu'un spider procure une augmentation du seuil de un point, il faut qu'il gère la sécurité matricielle du noeud à plein temps et ne peut se contenter de passer de temps à autre. Par exemple, si un hackeur veut accéder à la fonctionnalité de gestion des comptes utilisateurs pour se créer un compte administrateur, il lui faudra utiliser une fonctionnalité (Seuil de 2) de niveau admin (+2) soit un seuil de 4. A noter que dans un noeud qui ne comporte pas de défenses passives ou actives, ce mécanisme de test simple peut vous permettre de ne pas faire de jets de dés lors d'un hacking, grâce au mécanisme d'achat de succès, ce qui permet au MJ et à un joueur hackeur de ne pas à avoir à tester par les dés un hacking d'un noeud simple. Vous noterez que les seuils ne sont pas très élevés car le mécanisme de droits utilisateurs est plutôt destinés à gérer les utilisateurs officiels et pas arrêter un hackeur un tant soit peu compétent. Règles – Partie 3 : défenses actives Les défenses passives servent plutôt à compliquer la tâche d'un hackeur afin de le ralentir et de laisser les défenses actives le trouver et résoudre le problème, aussi étudions d'abord ces dernières en premier. Les défenses actives reposent essentiellement sur des CI car tout le monde ne peut pas avoir des spiders pour sécuriser un noeud. Les CI peuvent être utilisées dans 3 rôles différents : - Une CI de patrouille sert à détecter un hackeur infiltré dans le noeud. - Une CI gardienne sert à protéger l'accès à une fonctionnalité ou à un fichier de données. - Une CI de combat sert à botter le cul du hackeur hors du noeud, une fois l'alerte donnée. Une CI de patrouille va agir comme un compte à rebours avant que le hackeur soit détecté (dans le but d'obliger le joueur à adopter une stratégie de gestion de son temps et éventuellement de prendre des risques). Au niveau règle, à la fin de chaque tour de jeu après l'intrusion du hackeur dans le noeud, une CI de patrouille fait un jet de Pilote+Analyse et ajoute ses succès à ceux qu'avait obtenu le Firewall lors de l'infiltration du hackeur dans le noeud. Le seuil déclenchant la détection du hackeur (et donc une alerte) reste inchangé (Réponse+Furtivité), mais si le hackeur lance des programmes une fois dans le noeud, cela peut faire baisser sa Réponse et il peut même se griller tout seul par ce biais. S'il y a plusieurs CI de patrouille dans un noeud, utilisez les règles de travail en équipe (ou si vous voulez gagner du temps, donnez un bonus de +2 à une CI pour chaque CI supplémentaire). Une CI gardienne est une CI qui n'a pas pour but de détecter le hackeur mais de lui barrer le passage. En effet, pour accéder à la fonctionnalité ou à la donnée protégée par la CI gardienne, le hackeur va devoir la battre en cybercombat, or dès la première attaque, une alarme est déclenchée (et généralement la CI va recevoir des renforts). Une CI de combat est rarement active en permanence dans le noeud, et va plutôt être activée au moment où le noeud déclenche une alerte. L'attaque matricielle n'est pas la seule stratégie d'une CI de combat. Elle peut tout aussi bien chercher à planter les programmes du hackeur ou bien s'en prendre directement à lui par le biais de programmes noirs (un hackeur lobotomisé est un hackeur qui ne vous pose plus de problème). Si un spider gère la sécurité du noeud de manière permanente, en plus d'augmenter le seuil des actions de hacking (voir les règles de la partie 2), il va pouvoir réagir plus finement que les CI à une intrusion. Par exemple, certain spider retour préfère avoir recourt à des alarmes silencieuses, quitte à laisser un hackeur accéder à une fonctionnalité ou une donnée qui aurait du lui être refusée pour avoir le temps de tenter un piège au hackeur (par exemple à grand coup de programme noir). Règles – Partie 4 : défenses passives Comme dit plus haut, les défenses passives servent à ralentir un hackeur pour éviter qu'il puisse faire ce qu'il a faire et quitte le noeud avant que la CI de patrouille ne le repère. La première des défenses passives consiste à crypter les données stockées dans le noeud. Un fichier de données archivé peut être crypté par un utilisateur et laissé tel quel dans le noeud, mais il est possible aussi de confier la tâche de cryptage au système lui-même pour qu'il crypte automatiquement tous les fichiers de données. Pour ce faire, il faut confier au système un programme Cryptage qui devra être lancé sur le noeud. Un cryptage est caractérisé par un niveau correspondant à l'indice du programme de cryptage utilisé. Pour passer outre un cryptage, un hackeur va avoir besoin d'un programme de decryptage qui doit être à minima du même indice que le niveau du cryptage. Si ce n'est pas le cas, le décryptage est impossible. Une opération de décryptage a une durée fixe (en action complexe) qui est égal au niveau du cryptage. Sinon toute fonctionnalité ou donnée peut être protégée par une bombe matricielle en plus de la gestion par droit d'accès. La mise en place d'une bombe matricielle obéit au même principe que pour un cryptage. Une bombe est dissimulée dans le code/les données aussi un hackeur va devoir la repérer par le biais d'un jet en opposition entre Informatique+Analyse et deux fois l'indice de la bombe matricielle. Une fois repérée, il faut ensuite tenter de désactiver la bombe par le biais d'un jet en opposition entre Hacking+Désarmement contre deux fois l'indice de la bombe[B/]. Pour les deux jets, le hackeur doit obtenir plus de succès que la bombe pour réussir son action. Si le jet de hacking est loupé ou si le hackeur n'a pas vu le piège... kaboum. Dernière méthode de défense passive, dissimuler des fonctionnalités ou des fichiers de données en faisant tourner un programme Furtivité au niveau du système du noeud. Généralement, en plus de la dissimulation, l'admin va laisser une fonctionnalité ou des données leurres qui peuvent servir de piège (via une bombe matricielle). Pour éventer la supercherie, le hackeur doit réussir un test en opposition entre Informatique+Analyse contre Système+Furtivité. Je reviens à mon analogie entre la passe matricielle et une infiltration dans le monde réel. Si le MJ le souhaite, il peut décrire les interactions entre le hackeur et le noeud dans une métaphore donnée avec quelques correspondances simples à comprendre. Par exemple, dans une métaphore médievale, un fichier de données peut être un livre à la couverture reliée fermée par un verrou (droit utilisateur), verrou qui peut en plus contenir une pointe empoisonnée (une bombe matricielle), et le livre une fois ouvert est écrit dans une langue incompréhensible (cryptage). Mais le hackeur doit faire vite pourtant car un garde rode dans les couloirs (une CI de patrouille). J'espère que pour l'instant ca vous botte bien, car il y a encore pas mal de chose à voir et à paufiner. Discussion à venir : Le pistage matriciel : comment le concevoir afin qu'il ait de l'intérêt pour le jeu. La réalité virtuelle : qu'est ce qui fait que ca accélère les pensées d'un humain et quelles conséquences niveau règles. Les programmes noires : quel est leur fonctionnement (découle de la discussion précédente). Fonctionnement des agents dans la matrice : comment éviter les effets de masse. Recherche d'info matricielle : ce serait pas mieux d'impliquer tout le groupe de PJ ? Hacking à l'aide de « virus » : principe, intérêt et limite de la méthode. Hacking à partir d'un espace public d'un noeud : principe et impact sur la méthode de hacking standard. Cadavres matriciels : principe et intérêt pour une éventuelle « autopsie ». | |
| 02-09-2011 10:07:08 | #2 | |
| okhin | Bon, supprimer les seuils pour admin et sécu est une bonne chose. j'aime pas mal ton approche, mais un bon hacker reste à priori un mec avec 1 en Logique et le dernier Comlink avec les derniers Softs. Et ça me chagrines pas mal. Okhin | |
| 02-09-2011 12:27:37 | #3 | |
| alt-F4 | Ca, c'est un des soucis du système de jeu quand on utilise un équipement à niveaux : on ne lance que Compétence + Niveau d'équipement (programme dans le cas de la Matrice). L'Attribut n'intervient pas du tout  Personnellement, je gère le truc en alter. Au départ, je faisais "moyenne entre l'attribut et la compétence (arrondi supérieur si comp > attribut) + niveau équipement". Par la suite, je me suis demandé ce qui importait le plus pour moi dans ces trois facteurs, et c'est clairement la compétence. Donc, je fais "moyenne entre l'attribut et le nievau de l'équipement (arrondi supérieur si niveau > attribut) + compétence". Ou peut-être limiter le nombre de succès à la value de l'attribut ? | |
| 02-09-2011 12:46:30 | #4 | |
| okhin | En fait, quand tu regarde l'équipement, ce n'est pas comme ça que ça fonctionne. Le cyber donne des bonus. Le médikit aussi, l'autocrocheteur aussi. Les focus itou. Les rares cas où ils remplacent la comp, c'est lorsque c'est un système 'autonome' ou qu'il fournit une compétence indépendante de l'utilisateur. On pourrait très bien faire Attribut + Compétence + Programme, les indices du comlink servent déjà ailleurs (comme armure, comme limiteur sur le nombre de soft, etc). Ou se servir des attributs du comlink comme limiteur du nombre de succès (comme pour les sorts limités par la Puissance par exemple), avec des programmes beaucoup plus cher (donc avec des indices plus bas). Ça permet également, pour un bon hacker, de se passer de certains programmes. Il n'a pas besoin d'un Edit, vu qu'il a 7 en Logique, il improvisera une routine d'édition à la volée. Et d 'ailleurs, ça pourrait être sympa d'avoir une possibilité de coder un utilitaire temproaire à la volée (genre Logique + Software, le nombre de hits donne le niveau du programme, pour une action complexe). Okhihn | |
| 02-09-2011 13:01:02 | #5 | |
| Fantome | Ca fait longtemps que je me fais la même réflexion qu'Okhin. Maintenant, à mon avis, si au lieu de jeter Compétence + Soft, on lance Logique + Compétence + Soft, il faut revoir à la hausse en conséquence tous les seuils si on veut maintenir un certain équilibre. Autrement, on va juste donner un cadeau gratuit aux hackers. | |
| 02-09-2011 13:05:08 | #6 | |
| JoKeR | Non mais aussi vous cherchez des règles équilibrées avec le système et les échelles de Shadowrun, faut pas s'étonner si ça passe pas ^^; ... | |
| 02-09-2011 14:36:05 | #7 | |
| alt-F4 | Bah ... c'est déjà plus facile qu'avec l'ancien système et la courbe de réussite qui plongeait à partir des seuils supérieurs à 8  | |
| 02-09-2011 14:45:55 | #8 | |
| okhin | @Fantome pas forcément, si tu considère un programme comme un outil de hacker, un vrai, et que, du coup, la plupart du temps tu as un software de 0, tu multiplie le prix des suites logivcielles par 100 et de suite, ton programme Indice 3 à 10000 Y (soit 20 PC) (par rapport à une comp à 3 qui te coute 12 PC) ça a plsu de guele. Ça laisse aussi de la place pour améliorer le hacker (au lieu de partir avec tous tes softs à 6 à la création). En plus, les non-hackers ne prendrosn aps d'utilitaire, ce qui ne les empêchera pas de faire quand même des jets. Okhin | |
| 02-09-2011 15:10:55 | #9 | |
| alt-F4 | okhin a écrit: En fait, quand tu regarde l'équipement, ce n'est pas comme ça que ça fonctionne. Le cyber donne des bonus. Le médikit aussi, l'autocrocheteur aussi. Les focus itou. Les rares cas où ils remplacent la comp, c'est lorsque c'est un système 'autonome' ou qu'il fournit une compétence indépendante de l'utilisateur. Juste ... je les ai toujours géré de la même manière que les softs matriciels. On en apprend tous les jours (même si ça faisait une règle cohérente pour tout). Sinon, pour revenir au sujet, j'aime bien le concept de Valérian. Ca se rapproche plus de ma vision du réseau ... | |
| 02-09-2011 16:26:59 | #10 | |
| Carmody | Salut Valérian, globalement j'aime beaucoup ton approche, je vais en parler avec mon hacker pour voir si ça l'intéresse de l'utiliser. J'ai cependant quelques remarques et questions : - Quand tu parles de "fonctionnalité", je ne suis pas sur de comprendre exactement à quoi tu fais référence. Quelques exemples seraient bienvenus. Observer les caméras de surveillance, les faire regarder ailleurs, modifier ce qu'elles renvoient (pour cacher une intrusion physique), déplacer un ascenceur ou bien le bloquer. Est-ce planter, utiliser ou reprogrammer une fonctionnalité pour toi ? - Pour la détection par une CI patrouille, j'ai le sentiment que si on ajoute ses succès avec ceux déjà obtenus lors de l'intrusion ça ne laisse vraiment que très peu de temps au hacker. En fait je proposerai plutôt un fonctionnement comme suit : - la CI patrouille fait un jet à chaque action du hacker qui nécessite de contourner les droits - les succès de la CI patrouille se cumulent dans le temps, avec le seuil que tu indique, mais sans s'ajouter aux résultats du firewall lors de l'intrusion - le nombre de succès nets du hacker dans sa tentative pour contourner les droits est un malus à la CI patrouille, voici quelques exemples : (CI patrouille 3 / Analyse 3) - si le hacker réussit son jet sans aucun succès excédentaires : la CI jette 6 dés - si le hacker réussit sont jet avec 3 succès excédentaires : la CI jette 3 dés (le hacker utilisé une méthode très élaborée, fine ... qui est donc peut détectable) - si le hacker manque son jet (il lui manque 2 succès) : la CI jette 8 dés (un échec ne signifie pas forcément une alerte, si je fait un rm d'un fichier sur lequel je n'ai pas les droits, ça ne marche pas, mais je n'ai pas le service informatique en alerte sur le dos pour autant ^^.) Pour répondre à Okhin : je pense que ton approche pour les programmes est très bien aussi, avec là encore quelques remarques : - je pense que pour faire une action donnée il faut obligatoirement un programme, par contre on peut créer un programme de niveau 0, qui permet de faire l'action, ne coûte que très peu, mais nécessite d'être chargé. | |
| 03-09-2011 09:27:08 | #11 | |
| Le Dieu Fred | J'aime bien, j'ai une vision assez similaire du hacking quand je masterise. @Okhin : * créer des programmes à la volée c'est les technomanciens qui font ça pour le moment. je ne crois pas vraiment qu'un hackeur même très doué puisse faire surgir du néant un programme d’édition d'indice 3 en quelques secondes à partir de rien. * J'aimerais ausi faire du caracs + compétence + programme, mais ça implique que pour équilibrer, en face la machine aient aussi 3 choses à additionner. System + Firewall + analyse pour le nœud, Pilot + réponse + programme pour les CI par exemple. Je suis assez d'accord avec Carmody au sujet des CI Patrouille sur le fait que la détection va être très (trop?) rapide. Par contre c'est à tester. Un bon hackeur devrais arriver à gérer la crise : il entre dans le nœud, balayage des icônes pour identifier les CI et les spiders éventuels, là il peux toujours tenter de les aveugler (y a des programmes pour ça). Par contre il devrais y avoir moyen de "faire baisser l'alerte" éventuellement en utilisant furtivité ou édition sur les logs de sécurité? | |
| 03-09-2011 16:44:34 | #12 | |
| Carmody | Ah oui, j'avais pensé aussi à des actions pour faire baisser l'alerte, mais j'ai oublié d'en parler dans mon poste ... Pour le fait que le hacker lance attribut+competence+programme, il n'y a pas forcément de problème si on revoie l'échelle et le prix des programmes (de 0 à 3 au lieu de 1 à 6) et augmentation non linéaire des prix (genre 1000¥ pour le niveau 0, puis 4000¥, 16000¥ et enfin 64000¥ pour le niveau 3, à diviser par 2 pour les programmes non-hacking) | |
| 03-09-2011 17:57:38 | #13 | |
| Murmure | okhin a écrit: Ça permet également, pour un bon hacker, de se passer de certains programmes. Il n'a pas besoin d'un Edit, vu qu'il a 7 en Logique, il improvisera une routine d'édition à la volée. Et d 'ailleurs, ça pourrait être sympa d'avoir une possibilité de coder un utilitaire temproaire à la volée (genre Logique + Software, le nombre de hits donne le niveau du programme, pour une action complexe). En SR2, c'etait pas possible ça avec le supplément "Virtual reality" ou un truc du genre ? Ce principe est effectivement bien | |
| 03-09-2011 23:18:28 | #14 | |
| Valérian | Si le but recherché est juste unifié le mécanisme sur Attribut+compétence+bonus d'équipement, ca n'a rien d'obligatoire car les règles matricielles peuvent très bien avoir un mécanisme de base différent, après tout, on trouve aussi des mécanismes spécifiques à la magie (choix d'une puissance, drain...). Et de plus, revoir complètement l'échelle des programmes n'est pas neutre car il faut revoir les TM et leur formes complexes. Si le but c'est d'enquiquiner les joueurs qui pondent un hacker avec 1 en logique, c'est au MJ d'interdire un perso avec un minimaxage aussi fourbe Si le but c'est d'utiliser Logique, on va se retrouver avec des Hacker avec 5 ou 6 en logique, +2 de booster cérébral et +3 de nanoware, une compétence de 1 et un programme d'indice 0 et on retombera sur un autre travers de Shadowrun à savoir la prédominance des attributs et de leur modificateur sur les compétences. En plus, la Réalité Virtuelle est basée sur un flux simsens d'info qui arrive au hackeur, flux auquel il doit réagir le plus vite possible. Là on est plus dans le domaine de l'intuition (sens de la perception et vitesse de réaction) que de la Logique pure (ou tout du moins c'est un mix des deux), donc du coup le fait de ne garder que la compétence associée au niveau du programme (car la puissance brute de calcul et les fonctionnalités pré-codées sont importantes aussi) a du sens. Ceci dit, il y a des domaines où la Logique doit être prise en compte car ils font appel à l'intelligence et le sens de la stratégie du personnage : Pour la recherche d'information dans la matrice, mieux vaut avoir l'intelligence de savoir où chercher plutôt qu'un programme puissant, donc ca doit faire appel à un test de Logique+Recherche matricielle plutôt que Recherche matricielle+Catalogue. Pour tout ce qui touche à la programmation, l'intelligence du personnage est un facteur très important donc c'est basé sur des jets de Logique+Software. Dans ma matrice revisitée, ca aura de l'importance pour les hackeurs par le biais de "code corrompu" à coder puis à implanter dans les programmes adverses (je n'ai pas encore réfléchi à tous les détails, mais ca remplacera les règles de virus/troyen d'Unwired). Dans mon premier post, il y a une partie sur la mise en place de données cachées, de leurre, de pot de miel... que j'ai proposé de régler par un jet d'analyse contre furtivité. A voir s'il ne faudrait pas plutôt baser le mécanisme de test sur la Logique (un hackeur un peu couillon aura ainsi de bonne chance de tomber dans le panneau, contrairement à un hackeur malin. Éventuellement, vu que la Logique représente la capacité d'analyse et d'élaboration de stratégie, l'attribut pourrait être utilisé dans ce qui touche à l'exploitation de données dans un but pratique (je pense à ce qui touche à des bonus RA, mais aussi des bonus tacNet). Je n'oublie pas de répondre aussi sur la vitesse de détection des CI de patrouille et sur la notion de fonctionnalité... mais ce sera pour un autre post. | |
| 05-09-2011 01:21:17 | #15 | |
| Valérian | Ce que j'appelle "fonctionnalité" (à voir si on peut trouver un meilleur terme) couvre à la fois ce que le noeud met à la disposition des utilisateurs, mais aussi le contrôle de l'OS commun à tous les noeuds : Un noeud périphérique comprend un contrôle du périphérique en question. Par exemple, une caméra de surveillance de la voie publique pourra être orientée et zoomée et on pourra enregistrer les images perçues. Un noeud matricielle commerciale offrira des fonctions de consultation du catalogue du magasin et la possibilité de passer une commande ou de signer un problème SAV. Dans tous noeud, on retrouve par exemple une fonctionnalité de gestion des comptes utilisateurs et des droits associés, un gestion de la sculpture du noeud, une liste des utilisateurs en ligne... La différence que je fais entre "utiliser une fonctionnalité" et "reprogrammer une fonctionnalité" c'est que dans le premier cas, on ne peut faire que des choses prévues par la fonctionnalité (comme un utilisateur officiel autorisé à utiliser la fonctionnalité), tandis que la reprogrammation permet de faire des choses non prévues à la base. Par exemple, si vous accéder à la fonction de gestion des comptes utilisateurs en "utlisation", vous pourrez créer un nouveau compte (qui apparaitra dans la liste des comptes existant) et choisir ses droits parmi une liste à cocher. Si vous accéder à cette fonctionnalité en mode reprogrammation, vous pourrez créer une notion de "compte fantôme" que ne vois même pas les admins du noeud, afin de disposer sur le site d'une backdoor (ca demande toutefois un jet avec un seuil de 3+2+1=6 si on veut le faire sans lancer de trace). Autre exemple : en accédant à une fonction de contrôle d'une caméra de surveillance en mode "reprogrammation", vous pouvez y associer un Sensor software de reconnaissance faciale avec l'image d'un type à rechercher et ajouter une instruction d'envoi d'un message à un commcode donné (celui de votre commlink jetable acheté spécialement pour la mission) si la caméra repère la personne recherchée. Au niveau des droits utilisateurs, il ne faut pas prendre les notions de "sécurité" et "d'admin" de manière restrictive, car la gestion de profil utilisateur type peut être plus diversifiée que cela. Par exemple, sur un noeud commercial, les clients se connectent avec un compte utilisateur et on accès à des fonctionnalités de passage de commandes. Le personnel préparant les commandes et gérant les stocks et les approvisionnement aura un profil utilisateur différent de celui des clients, et le personnel de la comptabilité peut très bien avoir un profil de super-utilisateur équivalent à un niveau sécurité (mais c'est pas pour ca qu'ils peuvent contrôler des CI...). Le PDG peut très bien avoir un accès une fonctionnalité de gestion des contrats en cours de négociation hautement sécurisé, ce qui correspond à un équivalent de compte admin. Je souhaite qu'un hackeur infiltré dans un noeud ait la pression car il sait qu'il a un temps limité avant le déclenchement d'une alarme. A ce moment là, soit il se barre soit il estime avoir le temps de finir son hacking et il essaye de le faire tout en gérant les CI de combat que va lui envoyer le système. Du coup, je n'ai volontairement pas mis de possibilité de retarder le décompte avant détection par le biais d'un jet de Hacking+Furtivité car dès que le hackeur est meilleur que la CI en terme de pool de dés, il peut se maintenir indéfiniment dans le noeud et faisant des jets aussi souvent que nécessaire. Pour ne pas multiplier les jets, la solution d'un jet de détection de la CI de patrouille à la fin de chaque round me parait bonne et le fait de cumuler avec les succès obtenus lors de l'intrusion dans le noeud donne un timing qui me parait bon (reprendre le compte à zéro étant beaucoup trop long). Au passage, une petite précision : je parle de jet à la fin du round, mais généralement, la phase d'intrusion dans le noeud est gérée sans décompte des passes d'initiative du tour. En fait, le premier tour matriciel commence à l'entrée du hackeur dans le noeud, ce qui fait qu'il a minimum 1 round complet (soit entre 2 et 5 PI en RV) avant d'avoir une chance d'être détecté. Par exemple, considérons un hackeur avec 12 en Hacking+Exploit, une réponse de 5 et un programme Furtivité de 5. Pour hacker un noeud de Système et Firewall 4, il va a priori avec besoin de 2 jets. En 2 jets, avec 8 dés, le noeud devrait avoir accumuler 5 succès en détection. Une CI de patrouille de niveau 3 avec Analyse 3 (soit une CI de patrouille lambda), accumule les succès 2 par 2, aussi il lui faut 3 jets pour atteindre au final les 10 succès nécessaires à la détection, ce qui fait 3 rounds complets, ce qui est pas si mal. | |
| 05-09-2011 09:02:49 | #16 | |
| Carmody | Pour les fonctionnalités, c'est très clair et je trouve ça très pertinent. Pour la détection par contre je reste un peu mitigé. D'un côté c'est sur que c'est lourd de faire un jet de détection par action, d'un autre côté j'aime bien l'idée que la qualité de réussite d'une action facilite ou rende la détection plus difficile. D'autre part, concernant le temps disponible avant d'être détecté, ça laisse effectivement un peu de marge dans le cas d'un hit & run (je rentre, je prend l'info qui m'intéresse et je m'en vais) par contre dans le cas où le hacker veut faire la couverture matricielle d'un bâtiment pendant que l'équipe (y compris lui potentiellement) s'infiltre, alors il faut qu'il reste beaucoup plus longtemps. Et là ton système coince complètement. | |
| 05-09-2011 10:39:25 | #17 | |
| Valérian | Bonne remarque ! C'est vrai que j'avais plus en tête une passe matricielle où on ne fait justement que passer. En procédant par élimination : On peut faire un test opposé de Hacking+Furtivité versus Pilotage+Analyse à chaque action de hacking, mais je n'aime pas cette méthode qui double le nombre de jets et si le hackeur a quelques dés de plus que la CI, il ne se fera jamais détecter. Donc je ne retient pas ce mécanisme. On peut faire une action pour se planquer et faire un jet de Hacking+Furtivité dont les succès s'ajoutent à son compteur de détection (ou en version moins bourrine, c'est un jet opposé comme ci-dessus mais seul les succès excédentaires augmentent le compteur), mais il suffit de faire très régulièrement cette action pour faire grimper le compteur et on ne sera jamais détecté. C'est pourquoi j'avais laissé de coté cette méthode. Je viens de penser à ne pas faire de jet de détection de la CI pour un tour où le hackeur ne fait rien du tout dans le noeud, mais le principe d'une couverture ce sera plutôt des actions ponctuelles, or on est plus dans le cadre d'un PI de temps en temps que d'un tour complet de hacking de temps en temps, donc ca risque de ne pas suffire. Eventuellement, il faut coupler à la règle de "pas d'action=pas de détection", l'ajout d'un autre modificateur de seuil de +1 supplémentaire pour faire une action de hacking échappant à l'attention des CI. Par exemple, pour actionner une porte ou déverrouiller temporairement une alarme, il faut faire activer une fonctionnalité (Seuil 2) qui sera de niveau sécurité (Seuil+1), sans laisser de trace (Seuil+1) et discrètement (Seuil+1), soit un seuil de 5 (6 s'il faut le faire au nez et à la barde d'un spider). Ca peut faire beaucoup, mais dans ce cas, le hackeur peut laisser tomber le fait de na pas laisser de trace, mais l'effraction sera constatable au niveau matricielle après coup. Sinon plutôt que la règle ci-dessus, on peut remplacer l'augmentation de seuil de +1 par un malus au test de hacking égal au nombre de succès du test de détection de la CI de patrouille. C'est un peu plus complexe à gérer mais plus réaliste (si vous avez deux CI de niveau 4 avec Analyse 4, l'autosoft Hometruc qui donne +3, ca fait un test de détection qui tourne à 14 dés, soit un malus de 4 voir 5). A l'inverse, avec un CI de patrouille basique (6 dés), ca ne fait qu'un malus de 2.... mais ca complique peut être de trop. Tu vois d'autres choses ? | |
| 05-09-2011 12:08:07 | #18 | |
| Carmody | Je n'ai pas le temps de faire une analyse complète maintenant, mais voici quelques pistes et remarques par rapport à ce que tu proposes. 1/ Dans le cas où on fait un jet de CI par action du hacker. C'est clair que ça alourdit, par contre on n'est pas obligé d'ajouter 2 jets, on peut se contenter d'un seul : - le hacker lance Hacking + Exploitation en utilisant les règles que tu as définit dans ton premier post - la CI lance Pilot + Analyse. Les succès excédentaires du hacker à son premier jet sont retranchés aux succès de la CI. (si le hacker a raté son action, les succès manquants sont rajoutés à ceux de la CI, plus de détection automatique) De cette manière on rajoute moins de jets, et le hacker ne sera pas capable d'annuler tous les succès de la CI, sauf si il est vraiment beaucoup plus fort et qu'il ne tente que des actions simples ... mais dans ce cas là je ne voie pas le problème : c'est comme lacher un street-sam dans un building corpo sans défenses ... les sararymen n'ont aucune chance de s'en sortir ! 2/ Je pense que l'action pour se planquer est une bonne approche. Par contre on peut imaginer que c'est une action longue : 1 tour. De cette manière c'est vraiment pénalisant de l'utiliser et ça évite que le hacker ne la fasse trop souvent. - Dans le cas d'un "hit & run" ça risque d'être quand même trop facile - dans le cas d'une couverture matricielle, ca me semble ok. Il ne faut pas oublier que dans ce cas les actions du hacker ont un impact dans la vraie vie : les caméras et ascenseurs se déplacent "tous seuls", etc. Ce qui fait qu'il est aussi possible de détecter une intrusion et de déclencher une alerte préventive. Tout ça pour dire que ça sera effectivement difficile à équilibrer pour que ça marche bien, même si j'aime bien l'idée. Un point peut éventuellement nous aider : si on garde la détection automatique en cas d'échec, cela fait planner un risque de détection même si le hacker prend le temps de se planquer. | |
| 05-09-2011 17:04:36 | #19 | |
| okhin | J'aime pas les mécaniques différentes quand ça n'est pas justifié (et non, c'est la Matrice n'est pas une justification suffisante). J'aimerais bien un retour au hacker skilled, qui brille par ses compétence plutôt que uniquement par son hardware. D'où mon idée de proposer Attr + Comp + Matos (en plus, en limitant les pools de dés en suivant les règles, tu lancera au mieux 2 x (Attr + Comp)). Il n'y a pas forcément besoin de tout réévaluer, après tout les TM font des trucs chelou avec la matrice. Ou alors son augmente le technodrain et le coût des FC à la créa. En fait, le système de Matrice actuel me donen l'impression qu'il a été étudié pour les TM d'un côté et pour les non-hacker de l'autre. Laissant le hacker le cul entre deux chaises. Pour l'improvisation de soft, il s'agît pas de les créer à partir de rien, mais à partir des ressources dispo sur le système (pour ça que je linkerais ça sur hacking). En SR3 il y avait une option pour les deckers qui était d'improviser un utilitaire d'Attaque, je trouvait ça super fun et élégant (car cela permettait de ne pas perdre de temps à charger Attaque par exemple), il faut que ça reste inférieur au tissage des TM certes, mais les TM font réellement émerger des constructs de code, alors que le hacker détourne des ressources déjà disponible Quand à la détection ultra rapide, ça ne me gène pas plus que ça. Ça nécessite de mieux planifier son action et de savoir où tu vas pour t'épargner de nombreux jets d'Analyse, ou de nombreuses Connexions. Pas eu le temps de tout lire encore. Okhin | |
| 05-09-2011 18:19:04 | #20 | |
| Gris-Gris | Pour l'idée d'un Attribut + Compétence + Programme, j'avais pensé à transformer l'indice du programme en un modificateur au jet : Indice 1 : -2 à la pool (matériel pourri) Indice 2 : -1 (mauvais matériel) Indice 3 : 0 (matériel normal) Indice 4 : +1 (bon matériel) Indice 5 : +2 (excellent matériel) Indice 6 : +3 (matériel top du top) Ce qui, en clair, revient à utiliser l'indice du programme -2 pour la pool : ça limite un petit peu les brouettes de dés, donc ça devrait moins déséquilibrer le jeu par rapport aux TM. C'est vraiment penser le test comme un jet d'attribut + comp, avec des modificateurs dus à l'équipement. | |
| 06-09-2011 13:03:07 | #21 | |
| Carmody | J'aime bien ton approche Gris-Gris, elle permet de ne rien changer si ce n'est certains jets de dés. Cela dit, en y réfléchissant il y a quand même quelque chose qui me gène dans l'approche Attribut+Compétence dans la matrice : toutes les compétences liées à la matrice dépendent de Logique. Je trouve que cela gênant car cela rend cet attribut "trop puissant" pour les hackers. Je dois discuter avec mon joueur pour savoir si il veut utiliser ces règles, mais je pense que si on utilise cette approche j'utiliserai cybercombat avec intuition (c'est hautement discutable, mais de toutes les compétences de hacker c'est la seule que je peux imaginer ailleurs que sous Logique) | |
| 06-09-2011 19:22:09 | #22 | |
| Valérian | Je reprend ma liste de sujets méritant débat : Premier point qui peut me poser problème : l'intervention massive de CI sur un noeud après détection d'une intrusion. Lorsqu'une alarme est déclenchée, je ne vois rien qui interdise à un noeud de contacter d'autres noeuds pour demander des renforts, sous la forme de CI qui n'ont qu'à faire une action log-in (action complexe) pour apparaitre sur le noeud. Comme chacune de ces CI d'intervention consomme les ressources de son noeud d'origine et pas celui où elles interviennent, rien n'interdit d'en connecter plein d'un coup (c'est juste une question de moyen). Si je conçois qu'un hackeur doué en cybercombat peut finir le job malgré 1, 2 voir 3 CI sur le dos, ce n'est vraisemblablement plus possible avec une vingtaine (j'ai un doute, est-ce que chaque esquive en combat matricielle entraine un malus cumulatif de 1 pour les défenses suivantes, comme dans le monde physique ou bien ce n'est pas applicable ?). Comme une corpo devrait avoir largement les moyens de maintenir des serveurs de CI de combat en attente, prêtes à débouler en masse sur un noeud de la corpo quand elles en reçoivent l'ordre, et un particulier les moyens de louer une prestation d'assurance auprès d'une boite de sécurité matricielle lui garantissant une intervention expéditive sur demande, toute détection devient rapidement synonyme d'armada de CI... ce qui n'est pas gérable et pas fun au possible. Deuxième point qui peut me poser problème : un hackeur a l'air fin si sa connexion au noeud visée est interrompue En effet, si vous repérer un intrus dans votre Commlink, pourquoi vous emmerder à essayer de lui mettre des bâtons dans les roues via des CI de combat quand il vous suffit de désactiver la fonction d'émission wifi de votre Commlink (vous vous en foutez car vous contrôlez votre Persona via des trodes ou un datajack relié par câble ou skinlink à votre Commlink). La perte de connexion entre une icône projetée dans un noeud et sa Persona d'origine n'entraine pas de choc d'éjection (la session ouverte sur votre Commlink est toujours ouverte, c'est juste la connexion qui n'est plus maintenue).... sinon on aurait des tas de types s'explosant le crâne dès qu'ils passent dans un tunnel. Toutefois, une icône qui n'est plus connectée ben a priori, elle ne fait pas grand chose (voir même rien) et n'est qu'un pantin avec ses fils coupés. Autant dire qu'il ne pose temporairement plus de problème et comme il ne se défend plus en combat matriciel, c'est relativement aisé de l'achever. Au passage, on est dans une situation bizarre car on a d'un coté une icône grillé en cybercombat et de l'autre une Persona qui a perdu la liaison avec cette icône... on peut supposer qu'il y a synchronisation de la Persona et de son icône en cas de reconnexion... et dumpshock dans la face du hackeur. Le problème est le même avec un noeud câblé car rien n'interdit d'avoir un câblage de connexion destinés à certains users (la sécurité matricielle, les admins) et un câble destiné aux autres users. Bien sur, on peut considérer qu'il est de très mauvais ton de suspendre temporairement les connexions d'un noeud (et encore, pour votre link vous pouvez faire ce que vous voulez) car en 2070 le lag ne doit plus exister... néanmoins, une suspension d'une seule passe d'init (soir une seconde environ), suffit pour retâmer un hackeur en cybercombat si les CI de combat sont déjà après lui. | |
| 06-09-2011 19:27:27 | #23 | |
| Max Anderson | Pour le premier point, il y a quand même le souci que ça fait tout un tas de noeud avec un accès direct à un noeud "sécurisé", c'est donc aussi un excellent moyen d'accéder à un noeud un peu secure : passer par un de ces noeuds de "sécurité", déclencher une fausse alarme sur le noeud visé pour s'incruster tranquille pendant que les CI tapent sur le decoy, et voilà ! Donc ça n'est pas forcément une si bonne idée que ça en terme de sécurité du noeud... | |
| 06-09-2011 21:49:25 | #24 | |
| Mephisto | Ça dépend de la topologie de ton réseau. Si tu n'as accès aux nœuds qui hébergent lesdites CI qu'en passant par le ou les nœud(s) qu'elles protègent, ça ne pose pas vraiment de problème. En fait, tu peux même laisser la vingtaine de CI connectées en permanence au nœud à protéger et leur demander de passer leur temps à scanner tout ce qui passe par là. Bonne chance pour t'introduire dans ce nœud sans te faire repérer. Je suis d'accord avec Valérian sur ce point: avec les moyens, il est assez facile de concevoir une défense matricielle quasiment imprenable. La perte de connexion entre une icône projetée dans un noeud et sa Persona d'origine n'entraine pas de choc d'éjection (la session ouverte sur votre Commlink est toujours ouverte, c'est juste la connexion qui n'est plus maintenue).... sinon on aurait des tas de types s'explosant le crâne dès qu'ils passent dans un tunnel. Toutefois, une icône qui n'est plus connectée ben a priori, elle ne fait pas grand chose (voir même rien) et n'est qu'un pantin avec ses fils coupés. Autant dire qu'il ne pose temporairement plus de problème et comme il ne se défend plus en combat matriciel, c'est relativement aisé de l'achever. Au passage, on est dans une situation bizarre car on a d'un coté une icône grillé en cybercombat et de l'autre une Persona qui a perdu la liaison avec cette icône... on peut supposer qu'il y a synchronisation de la Persona et de son icône en cas de reconnexion... et dumpshock dans la face du hackeur. Ce n'est pas vraiment comme ça que je l'avais compris. Pour moi, une perte de connexion physique entraîne bel et bien un dumpshock et l'icône disparaît immédiatement du serveur. Les tunnels, c'est mal. | |
| 06-09-2011 22:36:57 | #25 | |
| Valérian | Pour le premier point, cela demande que sur le noeud, il y ait plein de comptes utilisateurs créés à l'avance pour les CI qui sont en fait des utilisateurs officiels. Dans mon système à moi, on peut éventuellement prévenir l'arriver en masse des CI (voir même toutes les déconnecter en un seul coup), en altérant la fonctionnalité de contrôle des utilisateurs connectés (fonctionnalité qui fait partie du fonctionnement de base d'un noeud), en faisant planter cette fonctionnalité. Au passage, dois-je garder le nom de "fonctionnalité" ou bien autre chose (fonction, processus, service...) ? Sinon Mephisto, j'avais plus en tête une système de mise en commun d'importantes ressources en CI qui interviennent uniquement ponctuellement sur un noeud, mais avec une société louant cette prestation à plein de gens. En fait, je serais partisan que chaque noeud soit autonome en matière de sécurité (en cas d'alarme les CI sont lancées sur le noeud directement, pas en dehors puis elles s'y connectent car sinon on revient à une question d'architecture des noeuds comme dans l'exemple de Mephisto. Pour l deuxième sujet : Pour moi, il y a dumpshock quand une Persona est détruite, et si ca survient sur une rupture temporaire de connexion à distance, jamais la RV n'aurait connu un tel essor si les risques étaient si importants. L'autre méthode entrainant un Dumpshock, c'est d'arracher ses trodes alors qu'elle sont justement en cours de fonctionnement (ce qui est déjà dangereux en soit... heureusement qu'un datajack est pas cher). Ce deuxième point m'embête plus. | |
| 06-09-2011 23:44:42 | #26 | |
| Carmody | Aucune coupure sous un tunnel vu que chaque lampe est un noeud (pour le contrôle à distance) qui peut donc router ton signal. De même, le gridlink (je ne me souvient jamais du nom exact) est toujours présent. Pour moi déconnection = choc. | |
| 07-09-2011 01:00:43 | #27 | |
| Valérian | C'est encore pire : tu hack un commlink, le type appuis sur le bouton on/off de l'antenne de son commlink... paf dumpshock. | |
| 07-09-2011 08:50:50 | #28 | |
| Le Dieu Fred | en effet couper la liaison est un très bon moyen de kicker les intrus, mais tout le monde ne peux pas se le permettre. Autant je peux couper mon comlink si un gars rentre dessus. Autant le spider d'une megacorpo va pas couper la liaison à la bibliothèque de donnée dans laquelle 180 personnes sont actuellement connectées, sans avoir vraiment de bonne raisons. Parce que eux vont avoir droit à quelques jours d'ITT, mais lui il va avoir sa fiche de licenciement si c'était pas justifié. Quand à la technique de la horde de CI, elle peux fonctionner, surtout avec un honeyPot. Mais ce n'est pas forcement l'idéal, surtout sur un nœud fréquenté par du public. | |
| 07-09-2011 09:28:37 | #29 | |
| Carmody | Le Dieu Fred a écrit: [...] megacorpo [...] 180 personnes [...] Je crois que l'on peut rajouter quelques zéros ! | |
| 07-09-2011 10:17:37 | #30 | |
| Mephisto | Valérian a écrit: C'est encore pire : tu hack un commlink, le type appuis sur le bouton on/off de l'antenne de son commlink... paf dumpshock. C'était déjà comme ça dans les versions précédentes: si tu arrachais le câble de ton datajack, paf dumpshock. Et autant que je sache, ça revenait au même d'arracher plutôt le câble qui reliait ton deck à la matrice. D'autre part, si cela fonctionnait comme tu le décris, on pourrait imaginer un système qui vérifie les signes vitaux du hacker avec un biomoniteur et coupe immédiatement la connexion quand il perd connaissance ou que ça commence à aller mal pour lui. Ou comment faire de la VR pratiquement sans risque et échapper aux black ice qui sont censées pouvoir t'empêcher de te déconnecter. Finalement, si mes souvenirs sont bons, le dumpshock en cold sim n'inflige "que" du stun. Le hot sim inflige bien du physique, mais est illégal. Un utilisateur normal s'en tire donc avec un bon mal de tête, mais c'est tout. Et j'imagine bien les notices longues comme le bras qui rappellent aux utilisateurs les précautions à prendre avant de se connecter en VR, des programmes qui affichent un bon gros message d'avertissement quand la connexion est susceptible de lâcher ou quand on tente de se connecter à un noeud "à risque" ou inconnu, etc. On peut même supposer qu'un tel bouton on/off sur les commlinks n'existe justement pas sur la plupart des modèles pour éviter ce genre d'"accident". | |
| 07-09-2011 14:09:01 | #31 | |
| Valérian | Ok, donc on garde cette forme de "défense" pour les noeuds à très faible trafic et avec une préparation en amont (modification hardware et software pour permettre une rupture de connexion) de la part de l'admin. Par contre, chaque système doit incorporer un certain nombre de sécurités en interne pour les cas entrainant potentiellement une rupture de signal (déconnexion propre des utilisateurs avant reboot, redirection des flux routés par un noeud s'il doit être éteint...). | |
| 07-09-2011 14:23:18 | #32 | |
| okhin | Dumpshock implique Réalité Virtuelle (et hotsim il me semble) et la RV n'est pas _si_ rependue que ça dans ma vision ds choses (assez proche de Ghost in the shell en fait), surtout avec toute cette RA qui permet quand même aux utilisateurs d'accéder rapidement à l'info et d'en bénéficier (on parle quand même de modification de température ressentie dans les choses possibles en RA). Et oui, couper la connexion (donc, le lien entre le hacker et n'importe quel relai matricielle qu'il utilise pour établir sa connexion) va le kicker. Bon, en fait, je pense qu'il va s prendre un sérieux coup de lag, les processus de routage pouvant rapidement rétablir la connexion en passant ailleurs. Il y a d’ailleurs deux opérations différente et fondamentale pour moi. Déconnexion: le hacker perd sa connexion au nœud, et les protocoles de routage s'occupent de trouver une nouvelle route. L'icône est freezée et sans défense (mais isolée du biofeedback) pendant Réponse du noeud - Réponse du comlink tour de combat (minimum 1). Délog: l'icône du hacker est éjectée violemment du nœud, provoquant un éventuel choc d'éjection. Cela se fait généralement en plantant complètement l'icône du persona, ou en réussissant une opération de déconnexion. Le délog est généralement une mesure passive (une icône a déclenché une alerte de sécurité, on la délogue) alors que la déconnexion est une mesure plutôt active (je veux empêcher cette personne de communiquer, ou alors j'ai perdu la main sur le serveur par où passe l'icone, je le kicke du routeur pour le finir à la main avant qu'il ne revienne). Okhin | |
| 07-09-2011 15:18:46 | #33 | |
| Carmody | Je ne suis pas d'accord avec ta distinction Okhin, en tous cas by the rules (après je comprend tout à fait que c'est parfaitement réaliste et que tu veuilles le modéliser). SR4A ne prend pas en compte les lags temporaires, donc une icône est soit connectée, soit non. Le problème de créer un état intermédiaire c'est que tu te retrouves avec une icone qui n'est temporairement pas connectée au persona, mais qui peut quand même se prendre des dommages et donc générer du biofeedback, ce qui est impossible vu que l'icone n'est justement plus connectée au persona. | |
| 07-09-2011 15:28:09 | #34 | |
| okhin | On est là pour discuter de règles alter, donc l'état des règles n'a que peu d'importance. Et c'est pour ça que j'ai bien dit que ça suspendait le biofeedback. Ça peut même provoquer des choses intéressantes, comme rendre impossible à suivre une conversation, ou permettre, grâce à un Spoof, de prendre la palce d'uen icône déjà connectée. Ça peut aussi permettre de pouvoir ensuite avoir le temps de basher correctement (ou analyser) l'icône. Okhin | |
| 07-09-2011 17:25:06 | #35 | |
| Le Dieu Fred | Je préfère considérer l’icône comme étant hostée par son utilisateur. donc si l'utilisateur n'est plus connecté à un nœud, l’icône disparait. 9a evite aussi une manip du genre: quand je rentre dans un nœud, je deco/reco du nœud en boucle pour générer 500 icônes de moi, ça occuperas les IC et les spiders. | |
| 07-09-2011 17:33:48 | #36 | |
| okhin | Bah, elle est hosté sur le link du user, mais elle a un pointeur sur le serveur (ne serait-ce que pour pouvoir être ciblé par le noeud et pour pouvoir y voir). Un socket en gros, unique sur lequel se connecte l'user. SI il se déco/reco, il reprend le même socket (il doit même y avoir des services qui maintiennent un socket actif pendant un certains temps, pour éviter de se reconnecter). Pas de flood possible (Access ID unique sur le noeud, tu retombes de toutes façon sur ton socket), tune génères donc pas plus d'icône de toi. Okhin | |
| 07-09-2011 18:46:33 | #37 | |
| Le Dieu Fred | okhin a écrit: Bah, elle est hosté sur le link du user, mais elle a un pointeur sur le serveur (ne serait-ce que pour pouvoir être ciblé par le noeud et pour pouvoir y voir). Un socket en gros, unique sur lequel se connecte l'user. SI il se déco/reco, il reprend le même socket (il doit même y avoir des services qui maintiennent un socket actif pendant un certains temps, pour éviter de se reconnecter). Pas de flood possible (Access ID unique sur le noeud, tu retombes de toutes façon sur ton socket), tune génères donc pas plus d'icône de toi. Okhin Point d'histoire de chaussette, monsieur, c’était la matrice du début du siècle ça. Maintenant on utilise des autoreferenceurs sans duplication de la boucle du frontstream, donc forcement si t'es connecté t'es dans le looptime et ton icône apparait. Si ta connection est coupée ou perdue, forcement l'autoreferenceur tourne sur lui même et selon les réflexes de programmation Ourobooliens, il disparait dans un grand PoP et l'icône avec. Plus sérieusement, la matrice n'as pas a ressembler à ce que l'on connais, que ce soit en surface ou en profondeur (profondeurs dont tu sondes les abysses avec bien plus d'aisance que moi  ). C'est quand même bien plus simple de considérer l’icône comme une projection, donc ON ou OFF, et sans état intermédiaire, ou ça serais facile de faire de la merdouille dérivative. Par exemple en se deco/reco en spoofant des fausses ID a chaque reco, merci l'agent qui est là pour faire ça en boucle avec moi. et hop trouzmille icônes de moi dans le même node. | |
| 08-09-2011 09:30:46 | #38 | |
| Valérian | Bon, je vais retenir l'hypothèse que la connexion entre un Commlink et une persona projetée dans un noeud de la matrice doit être maintenue en permanence sinon l'icône disparait et l'utilisateur subit un choc d'éjection. En complément, je considère que la connexion garde un oeil sur son parcourt de routage afin de maintenir des redondances évitant de se retrouver planter si un noeud intermédiaire est soudain dans l'impossibilité de router l'information. Pour le coup, avec ce mode de fonctionnement, je suis d'avis de simplifier la démarche de pistage matricielle, en considérant qu'un noeud dispose des informations de routage des utilisateurs présents sur le noeud et que les infos de routage permettent de savoir où se trouve l'utilisateur dans le monde physique. Toutefois, pour un hackeur introduit dans le noeud c'est différent car il ne dispose pas d'un compte utilisateur (j'y reviendrai plus tard sur les simplifications du pistage des hackeurs). Je pense que ca permet aussi de virer la notion de "proxy" introduite dans Unwired (noeud configuré pour servir d'écran entre le hackeur et le noeud cible, avec une baisse de réponse de 1 obligatoire) car c'est trop facile de contourner le risque de pistage matriciel par ce biais, or le pistage est un ressort scénaristique important (risque de remontée à l'identité réelle du hackeur). La justification est la suivante : s'il peut être possible de configurer un noeud pour éditer les communications provenant du hackeur pour remplacer les infos relatives à son identité par celle du noeud proxy, ce traitement d'édition est incompatible avec la liaison bidirectionnelle d'une projection d'icône qui ne supporte qu'un routage simple de l'info. | |
| 08-09-2011 10:14:18 | #39 | |
| Carmody | Selon ma compréhension, tes suppositions sont très loin de ce qui se fait actuellement. Par contre ça a l'intérêt de simplifier la matrice en enlevant des options et complexités qui n'apportent rien pour moi. Clairement, ni mes joueurs ni moi ne prenons plaisir à jouer ce genre de choses. En clair : je suis tout à fait d'accord avec toi. Edit : je suis aussi d'accord avec le post du Dieu Fred : il n'y a pas besoin que la matrice ressemble à l'internet / aux réseaux que l'on connait aujourd'hui. amha si les règles de magie fonctionnent beaucoup mieux c'est parce que l'ensemble de ce qui est faisable est finit et que ça permet facilement à tout le monde de savoir ce qu'il peut faire ou ne pas faire et que MJ et PJ peuvent facilement se mettre d'accord. Pour la matrice je prône la même approche. Si au contraire on veut trop se rapprocher de ce qui existe IRL (ce qui est à mon avis l'erreur faite dans SR4) on se retrouve avec 10.000 solutions pour le même truc, des règles qui ne peuvent pas tout modéliser (sauf à devenir excessivement complexes) et surtout des joueurs et MJ qui ont beaucoup de mal à se mettre d'accord sur le pourquoi du comment ceci ou cela est faisable (tout le monde n'ayant pas les mêmes compétences dans le domaine des réseaux). Alors peut être que pour un groupe d'ingénieurs réseau ça marche mais pour tous les autres c'est inutilement compliqué. (ça me fait aussi penser aux règles d'explosifs d'Arsenal) | |
| 08-09-2011 10:47:09 | #40 | |
| gritche | Désolé de mes remarques pas constructives... J'aime beaucoup la règle des explosifs... toujours pratique d'utiliser des racines carrées quand tu fais une masterisation. Je n'ai pas la prétention de dire que je suis admin réseaux mais même avec mon job dans l'IT, j'ai l'impression d'être largué avec leurs règles de la matrice. C'est un cauchemar et une simplification des règles serait bienvenues. | |
| 08-09-2011 14:29:51 | #41 | |
| Valérian | Pour ce qui est de la simplification, je vais faire disparaitre la possibilité de lancer un agent dans sa persona (plutôt que sur son Commlink), car ca implique plein de finesses au niveau des règles : Dans les règles officielles, vous pouvez lancer plusieurs fois le programme Agent vu qu'il n'utilise pas son accessID intégré quand il est lancé dans une Persona. De même, vous pouvez le charger avec des exécutions de vos programmes, donc avec un agent et un programme attaque, vous pouvez vous retrouver avec 2 ou 3 "gardes du corps" armés. De plus, en tant que programme intégré à une Persona, lorsque vous vous connecter à un noeud distant (y compris par hacking), les programmes viennent avec vous. Ca me parait plus simple de n'installer un agent que sur votre Commlink avec ses propres programmes embarqués, donc plus d'agents qui viennent vous aider durant une intrusion dans un noeud (ou bien il faut qu'ils suivent le même processus de hacking pour rentrer eux aussi dans le noeud). Sur un autre sujet, j'ai réfléchi à ce qu'était la réalité virtuelle et le concept de sculpture de la matrice : Je considère du coup que la RV est plus rapide car basé sur un flux de "données" simsens plus important qu'en RA (en gros on stimule directement les zones du cerveau qui gèrent analyse les sens et pas les nerfs par lesquels l'information arrive au cerveau) et par le coté intuitif de la manipulation de la RV. Or pour que ce soit intuitif, il faut d'une part que l'on perçoivent les données pertinentes en RV et pas tout ce qui existe dans le noeud, et d'autre part, que l'interface soit bien fichue (s'il n'y a aucune logique dans la sculpture, ca doit perturber l'utilisateur plus que l'accélérer). Concrètement, le Persona d'un utilisateur intègre une fonction de filtrage contextuelle des informations suivant ce que souhaite faire l'utilisateur (c'est amélioré aussi par le programme Analyse), et de plus, le Persona peut présenter les données brutes du noeud dans la représentation du choix de l'utilisateur si la sculpture proposée ne lui convient pas (en gros le Persona intègre un filtre de réalité de base mais sans test de réussite et sans bonus). Concrètement, pour le MJ pas besoin d'inventer des sculptures à chaque fois si votre joueur fait ses tentatives de hacking avec sa sculpture préférée (vous n'avez que celle là à développer). Ensuite, au niveau de la RV, soit on fonctionne avec une sécurité consistant à filtrer les signaux simsens (Cold sim), soit on décide d'aller encore plus loin en supprimant ce filtrage pour gagner en vitesse et en réceptivité (Hot sim, qui donne une PI de plus et un +2 aux actions). Toutefois, vu ce principe (et pour équilibré un peu les choses car la hot sim fait le café), je dirais qu'en Hotsim, on perd le bénéfice d'un éventuel programme de Filtre de Biofeedback. On est donc très rapide... mais en slip contre une attaque au blackhammer. Au joueur de peser le pour et le contre. | |
| 08-09-2011 15:57:20 | #42 | |
| Carmody | Valérian a écrit: [...] vu ce principe (et pour équilibré un peu les choses car la hot sim fait le café), je dirais qu'en Hotsim, on perd le bénéfice d'un éventuel programme de Filtre de Biofeedback. On est donc très rapide... mais en slip contre une attaque au blackhammer. Au joueur de peser le pour et le contre. Ouais... bof, je trouve que le fait de risquer des dommages physiques au lieu d'étourdissant est suffisant, mais pourquoi pas. | |
| 08-09-2011 16:03:13 | #43 | |
| gritche | C'est pas déjà la cas pour la hot sim ? il faut pas déjà avoir bidouillé son link pour désactiver le filtre de biofeedback ? enfin c'est comme ça que je l'avais compris à l'époque. Il donnait l'exemple de revivre la mort d'un pauvre type comme si on y était et c'était marqué si on survit... | |
| 08-09-2011 16:06:17 | #44 | |
| Valérian | Faut voir ca autrement : y a t'il des MJ qui ont des hackers qui utilisent le mode cold sim ou bien 100% des joueurs passe en hotsim pour le bonus de +2 ? @Gritche : pour la hotsim, il te faut désactiver la sécurité de ton module Simsens. Toutefois ce n'est pas interdit de faire tourner un programme de Filtre biofeedback pour booster ta pool de dés d'encaissement en cas de dégâts "noirs". Personnellement ca me parait plus logique de filtrer ou de ne pas filtrer le simsens. | |
| 08-09-2011 16:12:30 | #45 | |
| gritche | Perso à ma table mon rigger (qui fait aussi un peu de hacking) utilise la cold sim. Je lui avais dit c'est cool la hot pas de soucis. Fais ton jet de hardware pour faire sauter le filtre de biofeedback stp ! heu c'est quoi déjà ? ben tu sais le truc qui t'empêche d'avoir le cerveau qui mousse et qui te dégouline par les oreilles. J'avais peut-être mal compris la cold et la hot sim mais perso il m'a dit qu'il la garderait comme solution si c'était absolument nécessaire. effectivement tu as raison la cold et la hot ca te fait juste passer de stun à du physique mais on ne touche pas au filtre de biofeedback mais à l'époque ca avait refroidi les ardeurs de mon joueur. comme quoi mon erreur de règle avait été bénéfique. | |
| 08-09-2011 17:25:58 | #46 | |
| ChatNoir | Bénéfique faut voir. En HotSim, tu as une meilleur maitrise, donc se limiter à la ColdSim pénalise le joueur. Et comme le dit Valérian, un petit programme de filtre biofeedback prêt à être chargé en cas de soucis et zou. | |
| 08-09-2011 18:02:55 | #47 | |
| Valérian | Heu non, je préconise justement de ne plus tenir compte d'un programme Filtre biofeedback en hotsim. Donc en Coldsim, tu encaisses les dégâts par Volonté+filtre Biofeedback (dégâts étourdissant uniquement). et en hotsim, tu encaisses les dégâts par Volonté seulement (dégâts physiques). C'est rude, mais c'est en partie contrebalancer par le fait que mes programmes Blackhammer ne sont plus des programmes "magiques" qui bloquent la connexion de l'utilisateur mais un programme d'attaque classique (la première baffe fera tout de même très mal, avant que vous puissiez repasser en coldsim ou en RA). Enfin, je garde la possibilité pour un spider (ou un agent correctement scripté) d'empêcher le hacker de se déconnecter et/ou de changer de mode, mais ce n'est plus lié au Blackhammer. | |
| 08-09-2011 18:37:21 | #48 | |
| ChatNoir | Oups, je pensais qu'il parlait en général. *disparitionne* | |
| 08-09-2011 18:44:53 | #49 | |
| Valérian | Qui ca Gritche ? Avec les règles officielles, coldsim ou hotsim, le programme filtre Biofeedback est très utile pour limiter les dégâts en cybercombat contre une glace noire, mais aussi pour réussir à se déconnecter (ca demande un jet). Pour un rigger, ca atténue aussi le choc d'éjection si le drone dans lequel tu es projetée se fait désouder. | |
| 08-09-2011 20:48:44 | #50 | |
| gritche | oui mes excuses d'avoir semé le doute. J'ai fait un fumble avec le soft de biofeedback. la hot est a double tranchant... et je persiste sur le fait que filtre biofeedback ou pas tu peux quand même avoir ton cerveau qui te mousse par les oreilles. donc même si c'est utile la hot, le fait d'etre au mieux mort ou pire comme un légume ca peut faire réfléchir. | |
| 09-09-2011 01:15:27 | #51 | |
| Valérian | Je reprends certain élément de mes règles après réflexion : Le programme Exploitation n'existe plus... enfin il est remplacé par 3 programmes aux rôles plus précis : Intrusion, Crochetage et Plantage. Programme Intrusion : ce programme sert à s'introduire dans un noeud par hacking. Une fois dans le noeud c'est lui qui sert de protocole de connexion pour relier la projection d'icône dans le noeud et le Commlink du hackeur. Concrètement, pour pénétrer dans un noeud, on fait un jet étendu de Hacking+Intrusion (selon le même principe que j'ai défini dans mon premier post, seul le programme change). Ce programme est une cible de choix pour la défense du noeud car en interagissant avec lui, il est possible de déconnecter violemment le hackeur, ou bien de lui interdire de se déconnecter (éventuellement en lui interdisant aussi de changer de mode de connexion). Ce programme contient aussi toutes les infos de routage permettant de savoir d'où émet le hackeur dans le monde physique. Au niveau de l'analogie avec une infiltration dans une propriété, le programme Intrusion est en quelque sorte le grappin qui vous permet d'escalader le mur extérieur, mais c'est aussi votre fil d'Ariane vous reliant à l'extérieur. Programme Crochetage : ce programme sert à interagir avec le contenu du noeud, les fonctionnalités et les fichiers de données en contournant la gestion des droits utilisateurs (voir mes règles du premier post, à l'exception du plantage de fonctionnalités que relève désormais du programme suivant). Ce programme sert aussi au désarmement des bombes matricielles (mais pas à leur détection qui reste associé à Analyse). Au niveau de l'analogie avec une infiltration dans une propriété, le programme Crochetage est une sorte de nécessaire de crochetage qui permet de passer outre les serrures (gestion de droits) et les pièges (bombes matricielles). Programme Plantage : ce programme sert à faire planter des fonctionnalités, des programmes, voir le noeud entier. Au niveau règles, pour planter une fonctionnalité ou un programme, le hackeur doit réussir un test opposé entre Hacking+Plantage contre système+Firewall. Pour planter un noeud, le hackeur doit faire un test étendu de Hacking+plantage avec un seuil égal à Système+Firewall et un intervalle d'une action complexe. Quand le seuil est atteint, l'OS plante et toutes les personnes présentes en RV subissent un choc d'éjection (hackeur compris). Quel que soit la cible, que les jets de plantage soient réussi ou pas, cela génère une alerte car c'est assimilé à une cyberattaque. Au niveau de l'analogie avec une infiltration dans une propriété, le programme Plantage est assimilé à un pied de biche, voir une charge de démolition... pas vraiment subtil mais efficace. Au passage, quelques considérations sur les arrêts et redémarrages : Arrêter proprement un noeud prend un nombre de passes d'initiative égale à son attribut Système (mais dans ce cas, les utilisateurs sont déconnecter sans subir de choc d'éjection). Le redémarrage d'un noeud prend un nombre de tours égale à son attribut Système (on ne peut pas interagir avec le noeud avant la fin de la procédure de démarrage). Lorsqu'une fonctionnalité est plantée, il est possible que l'OS la relance automatiquement, ce qui prend un nombre de passes d'initiative égale à l'attribut Système du noeud. Sinon j'utilise toujours les programmes suivant dans un rôle proche de celui des règles officielles : Furtivité, Falsification, Analyse, Decryptage. | |
| 09-09-2011 08:44:32 | #52 | |
| Carmody | Valérian a écrit: la première baffe fera tout de même très mal, avant que vous puissiez repasser en coldsim ou en RA. Pour ma part je considérais qu'un commlink modifié hot sim ne pouvais plus faire de cold sim (en gros pour moi la modif HW consiste à enlever certains circuits de protection) Sinon pour le cybercombat tu as des idées ? Parce que je trouve ça monotone. | |
| 09-09-2011 08:58:57 | #53 | |
| Valérian | Je finis de définir les programmes, leurs possibilité et les tests associés, puis je pourrais reprendre tout ce qui touche aux options de programme qui seront pas mal étoffé, un peu comme proposé dans ce topic. Ca devrait offrir un peu plus de stratégie (quelle forme d'attaque : Attaque, Blackhammer, crash de programme ; quelle cible : le hackeur, ses programmes) et de variantes (CI de combat furtive pour contourner le jet de défense ou pas ; options exotiques pour programme d'attaque...), surtout en présence d'un spider qui peut tendre une embuscade au hackeur et adapter ses CI De combat à ce dernier. Eventuellement, on pourra s'intéresser à des programmes d'attaque différents (j'aime par Nuke/surcharge mais on peut garder l'idée de ralentissement de la Réponse de la cible). Il faut voir aussi qu'en virant la possibilité d'incorporer des agents (de combat) à sa persona, le hackeur vient seul dans le noeud et ca évite le combat de masse de ses agents contre les CI. Enfin, au niveau règles, la seule modif que je vois concerne la défense totale qui devrait se faire avec Réponse+Firewall+Cybercombat, le hacking n'ayant rien à venir faire la dedans. | |
| 10-09-2011 03:22:36 | #54 | |
| Valérian | J'ai complété mon message ci-dessus avec des infos complémentaires sur le programme Plantage. Sinon, pour le cybercombat, j'ai revu le fonctionnement du programme Medic pour lui donner un rôle plus intéressant. Ainsi, Medic a trois utilités : Permettre à un construct de soigner ses propres dégâts matriciels. Permettre à un construct de restaurer ses programmes infectés par du code pirate. Permettre à un construct de contrecarrer une tentative de plantage de l'OS d'un noeud. Pour se soigner, un construct (Persona ou Agent/CI) prend une action complexe et fait un jet de Informatique+Medic. Chaque succès permet de diminuer les dégâts matriciels d'un point. A noter que si c'est plus efficace que dans la règle officielle, c'est désormais limité à un usage sur sa propre icône uniquement (sinon ca devient trop fort, j'aime pas trop l'idée d'avoir une icône qui se fait taper dans un noeud et soigner dans un deuxième noeud). Pour restaurer un programme infecté par un code pirate, il faut prend une action complexe et faire un jet de Informatique+Medic... et je n'ai pas encore défini la suite car il faut faire avant les règles de corruption d'un programme avec du code pirate (voir plus bas). Pour contrecarrer une tentative de plantage de l'OS d'un noeud, le construct prend une action complexe et fait un jet de Informatique+Medic. Ses succès viennent diminuer les succès accumulés par le hackeur cherchant à planter le noeud (seuil visé : Système+firewall du noeud). Pendant que j'y suis, le programme Medic peut être amélioré avec des options qui lui sont propres : Bâtisseur : avec cette option, l'utilisateur dispose d'un bonus de +2 dés à son jet pour restaurer un OS en tain d'être planté. Mécanicien : avec cette option, un agent ou une CI (mais pas une Persona) dispose d'un bonus de +2 dés à son jet pour se soigner. Restauration (Programme) : avec cette option, l'utilisateur dispose d'un bonus de +2 dés à son jet pour restaurer un programme précis. Premier soin : avec cette option, l'utilisateur est automatiquement soigné d'une case à la fin de chaque tour de combat à condition qu'il ne se soit pas soigné pendant le tour (le soin gratuit ne nécessite pas d'action ni de jet de dés). Il me reste à définir les règles pour permettre à un hackeur de corrompre un programme avec du code pirate. L'utilité est multiple, citons à titre d'exemple une immunisation au programme pour le hackeur (ce qui correspond au fonctionnement du programme Desarm dans unwired) toujours utile pour aveugler une CI (en bidouillant son programme Analyse) ou en la rendant inoffensive (en bidouillant son programme Attaque) et ce, de manière plus subtile qu'en plantant les programmes de la CI. Mais on peut aussi introduire dans un programme Analyse un code espion dans le but d'avoir un aperçu d'un noeud où va aller se promener le possesseur du programme Analyse affecté. Ca peut être utile aussi pour un spider, par exemple en plaçant un espion sur un programme du hackeur pour qu'il puisse transmettre la position physique de ce dernier (en vue d'envoyer une équipe d'intervention rendre une petite visite au hackeur). Dans l'idée, je dirais qu'il y a plusieurs phases : tout d'abord la programmation du script avec un jet de Logique+Software. Ensuite, au moment de son utilisation, il faut faire un test de Hacking pour introduire discrètement le code dans le programme ciblé. Comme l'utilisation du script peut être différée ou se faire dans la durée, il faut aussi un mécanisme de détection (ou pas) du script par le système. De base, je dirais que la programmation du script doit couvrir 2 notions : le degré de complexité du code, et son degré de discrétion une fois implanté. Si vous avez des suggestions pour que ce soit à la fois simple d'usage et que ca traduise ce que je viens de définir, n'hésitez pas ! | |
| 18-09-2011 19:48:09 | #55 | |
| Valérian | Pour varier un peu du hacking, une petite aparté sur la guerre électronique : Pour pouvoir gérer efficacement (d'un point de vue règle) les actions liées à la guerre électronique (intercepter un signal sans fil, détecter les noeuds cachés, crypter ses communications), il faut réfléchir à la manière dont est constitué un signal matriciel : Je dirais qu'il y a 2 parties dans une transmission : une série de données permettant l'acheminement du message à bon port et le message proprement dit. Le contenu du message peut être crypté, mais si on crypte aussi la partie correspondant au protocole de routage, ca ne va pas le faire logiquement. Quand on envoi un message, il faut un destinataire identifié par son accessID. Comme on attend généralement une réponse, il faut aussi un émetteur (aussi identifié par son accessID). Je dirais aussi qu'en plus de ces 2 infos de base, il faut aussi des infos en rapport avec le routage du message pour que les noeuds concernés par le routage sachent justement que cette transmission les concerne. Ca suppose donc qu'avant de pouvoir transmettre un message, il y a une phase préalable de recherche d'un chemin (ou plus vraissemblablement plusieurs parallèles) menant jusqu'au destinataire et qu'une fois que ce dernier accepte de répondre, l'échange proprement dit de données peu se faire. A noter que si on veut crypter la communication, il faut logiquement commencer par envoyer la clé de décryptage à son destinataire, sauf si vous vous êtes déjà entendu sur une clé de cryptage au préalable. Vous voyez une autre manière de procéder ? Si on retient ce format de transmission, alors la guerre électronique n'est pas si dure que cela : Pour l'interception d'un transmission sans fil d'un noeud donné (on connait son accessID) lorsque l'on est à portée de son Signal revient à regarder parmi toutes les transmissions que l'on capte lesquelles contient l'accessID du noeud parmi les champs "destinataire" et "émetteur" de chaque transmission. Ensuite, il n'y a plus qu'à procéder au décryptage de la partie "message" (et encore, si on intercepte son trafic avant que la communication soit établie, on peut même récupérer la clé de cryptage lorsqu'elle est envoyée en clair. Pour détecter un noeud caché mais dont on connait la position physique, le plus simple est de récupérer ses transmissions à l'aide d'une antenne à réception directionnelle (éventuellement en isolant ses transmissions à l'aide de plusieurs récepteurs directionnelle, façon triangulation) et regarder le champ "émetteur". Pour détecter les noeuds cachés dans le secteur, il faut faire une comparaison entre les messages émis dans le secteur et les noeuds en mode actif. On obtient ainsi la liste des noeuds cachés (à coupler avec un balayage du secteur à l'aide de plusieurs récepteurs directionnels pour localiser approximativement les noeuds cachés dans le monde physique. Du coup, ces méthodes me paraissent moins difficiles que les jets demandés par les règles de base (Diff 4 pour un scan et 3 pour un Reniflage avec obligation de casser le cryptage avant)... à condition que le mode de transmission retenu soit le bon. Au passage, un mot sur les modes des commlink : Je n'en retiendrai que 2 (car le mode passif est un bâtard) : en mode actif, un commlink signal sa présence au noeud à porter de signal en transmettant régulièrement diverses info (son accessID, son type de noeud, ses coordonnées physiques, sa portée de signal, est-ce qu'il est "en ligne" avec le reste de la matrice, son taux de disponibilité pour un routage) qui s'avèrent utiles pour le routage des transmissions. En mode caché, un commlink ne transmet rien et ne participe pas au routage des transmissions (c'est le mode par défaut des périphériques que vous trimballez sur vous, car ils n'ont pas besoin d'être affiché dans la matrice normalement). Outre ce mode qui concernent les transmissions à l'échelle locale, un commlink peut être aussi "online" ou "offline" suivant qu'il est connecté ou pas à la grille locale de la matrice (ce qui correspond grosso modo au réseau de noeuds de routage à l'échelle locale). Quand on est "online", la grille locale sait où vous trouver et remonte l'info à la grille régionale qui remonte l'info à la grille mondiale. C'est ce qui fait que si un type à l'autre bout de la planète veut vous contacter par votre accessID, il se connecte à sa grille locale qui va trouver dans quelle grille locale vous êtes et quel sera le chemin complet pour vous trouver. A noter que si on est caché et offline, on est invisible pour la matrice, mais cela n'empêche pas d'initier une communication de votre coté (le noeud destinataire saura vous répondre par le même chemin que vous allez emprunter). Il peut être possible de contacter un noeud caché/offline en direct (si on est à porté de signal mutuel) par un message de type "acessID XXXXX est-tu là ?" auquel le commlink en question va répondre. A plus longue distance ca peut rester possible, mais il faut définir un chemin d'accès et espérer que votre contact est bien dans la zone géographique visée. | |
| 18-09-2011 21:53:33 | #56 | |
| LeFélis | Valérian a écrit: Vous voyez une autre manière de procéder ? Oui, il y a 36000 manières de faire. Je te conseille de réfléchir à ce que tu veux obtenir et après définir le système de communication. Dans une transmission, on peut voir deux parties : l'information que l'on veut envoyer (le contenu du message) et les méta-informations ( routage, code de correction d'erreur, information sur le contenu (crypté ou pas, format, taille, etc), etc). Mais le système TCP/IP (que l'on peut juger assez courant), utilise des protocoles qui s'imbriques les au dessus des autres, ce qui rend la division en deux parties difficiles. Dans le cas de TCP/IP, il n'y a aucune information de routage contenu dans les paquets. Ce sont les serveurs qui se débrouille pour communiquer entre eux et définir le chemin. Où plutot un mini-bout de chemin, car chaque serveur détermine uniquement le serveur suivant et ne sait pas ce qu'en fera celui-ci. On utilise les termes chiffrer et déchiffrer pour écrire et lire un message avec un code secret, quand on possède la clef. Décrypter signifie lire le message sans avoir la clef. Crypter signifie probablement aller dans les cryptes. On peut chiffrer une communication en envoyant juste avant la clef de chiffrement, mais je préfère le code césar qui me parait plus sûr... Généralement on utilise une cryptographie à clé publique, c'est à dire que l'on utilise une clef publiquement annoncé pour chiffrer et une autre clef que l'on garde secrète pour déchiffrer. Il y a un lien mathématique entre les deux clefs (sinon on pourrait pas déchiffrer), mais cela demande une puissance de calcul énorme pour faire deviner la clef caché à partir de la clef publique. Pour terminer, je dirais que l'on peut dissimuler les informations de routage est possible. On peut par exemple utiliser des adresses à usage unique où chiffrer l'adresse de retour pour que seul le destinataire puisse le lire. | |
| 19-09-2011 09:00:36 | #57 | |
| Gris-Gris | LeFélis a écrit: On utilise les termes chiffrer et déchiffrer pour écrire et lire un message avec un code secret, quand on possède la clef. Décrypter signifie lire le message sans avoir la clef. Crypter signifie probablement aller dans les cryptes. Le Petit Robert a écrit: Crypter : Réaliser le cryptage de (un message) Décrypter : Traduire en clair (un message chiffré dont on ignore la clé) Peut-être qu'en informatique en 2011, il y a des emplois spécifiques, les termes ne sont pas mal utilisés pour autant. | |
| 19-09-2011 14:16:51 | #58 | |
| LeFélis | Effectivement beaucoup de personne utilise le mot crypter dans ce sens, et certains dictionnaires en font logiquement écho. l'Académie française a écrit: Monsieur, L'action qui consiste à coder un texte s'appelle le chiffrement ou le chiffrage. Le verbe correspondant est chiffrer. Encryption est effectivement un anglicisme à bannir. Crypter ne figure pas dans le Dictionnaire de l'Académie française, mais se trouve dans de nombreux usuels. Ce qui n'empêche pas que c'est chiffrer qui doit être employé. Cela étant, il semble que crypter trouve sa place et son rôle, surtout au passif, quand il s'agit de désigner des chaînes nécessitant un décodeur pour être reçues en clair. En résumé on chiffre les messages et on crypte les chaînes. Cordialement, Service du dictionnaire | |
| 19-09-2011 14:24:32 | #59 | |
| Gris-Gris | Alors là, respect  | |
| 19-09-2011 14:30:30 | #60 | |
| Carmody | Donc si j'ai bien compris le soft Décryptage c'est pour avoir le porno du samedi soir gratuit | |
| 19-09-2011 15:41:49 | #61 | |
| LeFélis | @Carmody: Le décryptage peut servir à ça. Mais aussi à lire le mot de passe interceptée de ton compte sur les shadowforums  C'est le chiffrement du signal télé, qui t'empêche d'avoir ton porno tous les samedi soir sur ta chaîne cryptée. Mais si tu regardes beaucoup cette chaîne, tu devrais arrêter d'essayer de la décrypter et t'acheter un décodeur qui déchiffera le signal pour toi. | |
| 19-09-2011 17:27:12 | #62 | |
| Carmody | LeFélis a écrit: @Carmody: Le décryptage peut servir à ça. Mais aussi à lire le mot de passe interceptée de ton compte sur les shadowforums C'est le chiffrement du signal télé, qui t'empêche d'avoir ton porno tous les samedi soir sur ta chaîne cryptée. Mais si tu regardes beaucoup cette chaîne, tu devrais arrêter d'essayer de la décrypter et t'acheter un décodeur qui déchiffera le signal pour toi. c'est bon ne t'inquiètes pas pour moi, j'ai la technique en plissant les yeux et en clignant très vite tout ça pour dire que tout le monde aura compris que c'est de l'humour ! | |
| 19-09-2011 17:53:02 | #63 | |
| LeFélis | Carmody a écrit: c'est bon ne t'inquiètes pas pour moi, j'ai la technique en plissant les yeux et en clignant très vite Je vais tester ! Je connaissais la technique de la passoire, mais pas celle là | |
| 19-09-2011 23:22:01 | #64 | |
| Valérian | Pour reprendre le sujet (car la vie sexuelle de Carmody n'intéresse que son labrador et ce dernier n'est pas académicien ), je me range à l'avis de Lefélis, à savoir que le protocole de communication est un peu plus complexe que cela et offre une certaine sécurité. Néanmoins, je garderais les principes énoncés sur les 2 modes des Commlink et l'aspect off/online qui me paraissent avoir du sens. Du coup, j'en profite pour établir des règles de guerre électronique qui me paraissent bien : Interception de trafic wifi : au niveau des conditions, il faut toujours connaitre l'accessID du noeud et être à porter de signal. A ce moment là, il va falloir à la fois décrypter le chiffrement du signal et réussir l'interception. Pour le décryptage, je dirais qu'il faut remporter un jet opposé de guerre électronique+décryptage contre 2 x Indice du programme Cryptage utilisé. De plus, le programme Décryptage doit avoir un indice supérieur ou égal à celui du programme Cryptage (sinon le test échoue automatiquement). L'interception du trafic correspond à un jet de Guerre électronique+Renifleur avec un seuil de difficulté de 3 (éventuellement, on peut considéré que le seuil varie de 2 pour une zone paumée sans trafic à 4 pour une zone saturée de communications wifi, 3 étant la moyenne urbaine classique). Identifier un noeud caché : au niveau des conditions, il faut être à porter de Signal du noeud, avoir une idée de sa localisation physique et disposer d'antennes directionnelles (classiquement plusieurs drones dotés d'un scanner de fréquence radio). A ce moment là, il va falloir à la fois décrypter le chiffrement des transmissions et intercepter l'accessID du noeud. Pour le décryptage, je dirais que la méthode est la même que ci-dessus (à noter que si vous enchainer une interception de communication avec l'identification du noeud caché, il n'est pas nécessaire de recasser une deuxième fois le cryptage). Pour récupérer l'accessID, il faut aussi réussir un test de Guerre électronique+Scan avec un seuil de difficulté de 3 (cette fois ci, on peut faire varier le seuil de 2 à 4 suivant que le noeud émet beaucoup ou au contraire limite au maximum ses communications). Toutefois, pour le cryptage, je dirais que chaque noeud crypte ce qu'il émet (contrairement à Unwired qui précise que l'on n'a besoin que d'un seul programme Cryptage), ce qui ne change rien pour localiser un noeud caché mais pour une interception de trafic wifi, certaines transmissions peuvent ne pas être interceptées alors que d'autres si en raison d'un chiffrement plus faible. Le mécanisme le plus approprié pour cela me parait un test de Guerre électronique + décryptage avec le nombre de succès définissant le degré de décryptage, mais si en face, on prend comme Seuil l'indice du programme cryptage, ca va faire des jets nécessitant beaucoup trop de succès dès que des programmes de niveau 4 ou + sont utilisés.... Vous en pensez quoi ? Au passage, ca me fait penser : prenons un rigger qui communique avec un drone situé à 400m et transfert ses flux senseurs à son pote situé à 3 mètres de lui. est que son Commlink peut fonctionner avec un signal de 3 minimum pour rester en liaison avec le drone et dans le même temps, discuter avec le commlink de son pote avec un signal de 0, ou bien son antenne est réglée obligatoirement sur signal 3 et c'est comme s'il hurlait dans les "oreilles" de son amis ? Si c'est la deuxième solution qui est réaliste compte tenu de la physique d'un émetteur, qu'est qui empêche de coupler le commlink à 4 antennes, une de signal 0, une de signal 1, une de signal 2 et une de signal 3, et le commlink choisi son antenne suivant la puissance d'émission qu'il souhaite utiliser et ce, pour chaque communication (auquel cas, on retombe sur la solution une) ? Autres actions de guerre électronique : Une fois que l'on a intercepter les transmissions d'un commlink, on peut utiliser un programme de brouillage pour saboter ses communications sans avoir à brouiller toute les fréquences (règles exacte à définir). Pour éviter cela, il faut avoir recourt à un programme ECCM (règles aussi à définir). Pour protéger ses communications directe (à portée de signal mutuel, typiquement le contrôle de drone par un rigger), il est possible de définir un protocole de communication non standard qui complique les tâches d'identification de noeud caché et d'interception de trafic wifi, mais limite obligatoirement les communications à une communication directe (ou tout du moins aux noeuds disposant de ce protocole de communication) (règles là aussi à définir). | |
| 20-09-2011 10:53:23 | #65 | |
| Paul Kauphart | Valérian a écrit: Ca suppose donc qu'avant de pouvoir transmettre un message, il y a une phase préalable de recherche d'un chemin (ou plus vraissemblablement plusieurs parallèles) menant jusqu'au destinataire et qu'une fois que ce dernier accepte de répondre, l'échange proprement dit de données peu se faire. A noter que si on veut crypter la communication, il faut logiquement commencer par envoyer la clé de décryptage à son destinataire, sauf si vous vous êtes déjà entendu sur une clé de cryptage au préalable. Je vais vite fait revenir sur ce point, la cryptographie moderne (et par extension on va assumer celle de SR4 aussi) repose sur un système de clé asymétrique, la clé de chiffrage et la clé de chiffrage sont différente. Du coup chaque système qui veut pouvoir recevoir des messages codés dispose d'une clé de chiffrage publique, et une clé de chiffrage privé. Il suffit alors de récupérer la clé de chiffrage publique de votre destinataire, chiffrer le message avec, et lui seul sera en mesure de le déchiffrer. Pour aller un peu plus dans le détail, dans la pratique, le système asymétrique requiert une grosse puissance de calcul et de gros volumes de données par rapport au système symétrique. Pour palier à ce problème, on va chiffrer le message avec une clé symétrique, puis chiffrer cette clé avec un système asymétrique, avant d'envoyer le tout. Le système uniquement symétrique reste malgré tout utilisé, en grande partie parce qu'un message chiffré avec une clé totalement aléatoire de la taille du message est mathématiquement indécryptable sans la clé. Et si le problème de transport de cette clé reste un problème, les organismes ayant beaucoup de moyen peuvent se payer ce genre de luxe (de mémoire, le fameux téléphone rouge entre Washington et Moscou est chiffré de cette façon). PS : Ouais, en fait c'est ce que disait LeFelis. J'ajouterais que, sous réserve de disposer d'assez de mémoire, rien ne nous empêche d'intercepter un signal chiffré, de le stocker en mémoire, et de le décrypter après coup, quand on a le temps. | |
| 20-09-2011 11:33:58 | #66 | |
| Valérian | En imposant un décryptage des communications AVANT l'interception (ou simultané comme je l'ai décris, ce qui revient au même), je considère que dans le protocole de transmission chiffre un maximum de chose (notamment la couche d'infos de routage et pas uniquement le contenu du "message"). Comme toutes les transmissions sont comme cela, il faut en gros arriver à décrypter la couche d'adressage/routage de toutes les transmissions pour trouver celles à intercepter car sinon, il faut enregistrer tout ce que l'on capte à chaque instant et un Commlink n'est pas prévu pour écrire autant de données en simultané en mémoire. | |
| 20-09-2011 13:29:44 | #67 | |
| Carmody | Valérian a écrit: je considère que dans le protocole de transmission chiffre un maximum de chose (notamment la couche d'infos de routage et pas uniquement le contenu du "message") Telle qu'est prévue la matrice dans SR4, chaque nœud joue le rôle de routeur, donc ton message peut très bien être relayé par le grille-pain de la mamie au dessus, qui lui l'enverra à la machine à laver de l'immeuble en face qui l'enverra au comlink d'un inconnu qui l'enverra sur un routeur commercial, etc. Si on garde cette approche (que je trouve très intéressante) cela revient à dire que ton comlink peut forcément décrypter ce que tu appelles "la couche d'infos de routage", car il peut être amené à être routeur lui-même. | |
| 20-09-2011 14:20:01 | #68 | |
| Paul Kauphart | C'est pour ça que je précise, sous réserve d'avoir assez de mémoire, et à priori, si tu es dans la zone d'émission de l'envoyeur, tu peux te permettre d'intercepter toutes ses transmissions, ça fait pas non plus un trafic colossal. Après, si t'es plus dans sa zone d'émission, comme le message est fractionné sur plusieurs chemins de toute façon, c'est un peu perdu d'avance. | |
| 20-09-2011 14:26:13 | #69 | |
| Valérian | Dans ce cas, c'est ce que je disais dans mon premier message : il est très facile d'espionner les communications wifi si la couche de routage est transmise en clair. Il doit toutefois être possible de définir un protocole de communication offrant une certaine sécurité à ce niveau (justifiant ainsi d'imposer un décryptage des communications avant l'interception). Par exemple, quand un noeud discute avec ses voisins pour trouver un chemin de routage, il peut émettre un signal chiffré en utilisant l'accessID du destinataire visé comme clé de déchiffrement. Du coup, parmi tous ceux qui vont recevoir le message, seul le noeud visé pourra déchiffrer la requète de routage, laquelle peut contenir un numéro de transaction qui va servir à l'envoi des messages entre le noeud émetteur et le noeud de routage (en gros un message n'est plus de la forme "émetteur/destinataire/message" mais "Numérotransaction/message"). | |
| 20-09-2011 14:41:03 | #70 | |
| LeFélis | Non, il n'y a rien d'obligatoire. Prend par exemple l'Onion routing, du réseau Tor, chaque noeud à une information qui lui est destinée. Il ne peut déchiffrer que l'adresse du noeud suivant. Le réseau Tor nécessite que chaque noeud soit prévu à l'avance pour le routage et qu'il y ait une clé publique pour chaque noeud. Mais ce sont des contraintes souhaitées, on peut facilement les enlever. Que pensez-vous de rendre les messages intelligents ? Ils sont des mini-programmes qui en fonction de leur environnement décident du prochain trajet. Comme ils ne font pas confiance à leur hote, ils ne déchiffrent que le minimum pour éviter toute lecture de l'admnistrateur du noeud. On peut aussi considérer que le traffic en wifi est énorme et que chaque comlink a un matériel séparé qui ne gère que le traffic à faire transiter. Avec cette hypothèse on peut inventer les techniques de routage les plus complexes, efficaces, sûrs et quitter nos habituels mode de pensé en terme de routage. Le matériel séparé est toujours géré pas le système du comlink (au moins pour l'éteindre/allumer) et donc n'empèche pas le hacking. | |
| 20-09-2011 17:07:00 | #71 | |
| Paul Kauphart | Valérian a écrit: Dans ce cas, c'est ce que je disais dans mon premier message : il est très facile d'espionner les communications wifi si la couche de routage est transmise en clair. Si tu es dans la zone couverte par l'émetteur ou le récepteur oui, mais après, le message est fractionné de multiples fois et transite par une multitude de chemins différents, et chaque morceau ne porte que les infos de routage qui le concerne. Du coup, la seule chose qu'il est possible de faire dans ce cas, c'est tracer l'émetteur et le destinataire. | |
| 22-09-2011 23:26:20 | #72 | |
| Valérian | Je vais commencé par parler "théorie" mais dans une deuxième partie on pourra oublier tout cela pour se concentrer sur les règles de Guerre électronique. Les communications électroniques sont basées sur un double flux : un flux "routage" et un flux "message". Une transmission de routage a le format suivant : AccessID du destinataire en clair + instructions de routage chiffrée. Le "destinataire" n'est pas le noeud que l'on cherche à atteindre, mais le prochain maillon dans la transmission. Les instructions comprennent plein d'informations pour permettre au destinataire et au noeud émetteur de communiquer, avec notamment : l'accessID de l'émetteur, le noeud que l'on cherche à atteindre, une idée générale du chemin, les numéros de transaction que vont utiliser les deux noeuds pour le flux message (voir ci-dessous), des infos sur la fréquence wifi à utiliser, une clé de cryptage pour envoyer une réponse au commlink émetteur... Une transmission "message" a le format suivant : Numéro de transaction en clair + "une partie du message soit chiffrée de manière basique ou bien chiffrée avec un vrai logiciel de cryptage pour plus de sureté. En pratique, une commlink donné ne s'intéresse qu'aux communications comportant son accessID ou bien comportant les numéros de transaction qu'on lui a dit de router au préalable (ou encore les messages envoyés à "tous"). Toutes ces infos sont là pour donner une base aux règles que l'on va aborder maintenant, mais mieux vaut considérer les communications de manière plus abstraite (j'aime bien l'idée de "messages intelligents"qui s'autodécryptent proposée par LeFélis). Donc parlons règles de Guerre électronique maintenant : la GE sert à l'interception des communications wifi, à leur brouillage éventuel, mais aussi à sécuriser ses propres communications. Pour cela, la compétence fait appel à des programmes aussi restreint à la vente que les programmes de hacking (Scan, Renifleur, Brouillage et ECCM.... à voir si on garde ces noms où si on propose autre chose), mais comme la GE concernent les communications wifi qui ont lieu dans le monde physique, du matériel de détection est aussi obligatoire. Identification d'un noeud caché : Les runners sont les premiers à cacher leur noeud pour éviter de faire une cible trop évidente pour un hackeur, mais ce n'est pas les seuls à le faire, aussi il avant de pouvoir interagir au niveau communication (et donc Guerre électronique) ou matriciel (par le hacking) avec une cible, il faut déjà récupérer son accessID d'où cette action d'identification d'un noeud caché. Au niveau des conditions, il faut avoir une idée de la localisation physique du noeud (généralement ce sera une personne ou un drone que vous voyez physiquement mais dont vous ignorez son accessID) car vous devez pointer dessus une antenne directionnelle (idéalement plusieurs) pour établir une correspondance entre le noeud physique et son adresse matricielle (son accessID), mais aussi pour restreindre le nombre de communication à examiner. Le but de cette action est de décrypter au moins une des transmissions du noeud caché pour récupérer son accessID, donc les antennes doivent être à portée du Signal du noeud caché. Si ces conditions sont réunies, il faut réussir un jet de Guerre électronique+Scan contre un seuil de difficulté de 2 pour récupérer l'accessID de la cible. Quand on inverse les rôles, pour éviter une détection, il faut diminuer son Signal pour restreindre la zone où vous pouvez être identifié. Sinon, il est possible d'avoir recourt à la Guerre électronique pour sécuriser vos communications (en gros cela revient à communiquer avec les noeuds voisins avec un protocole personnalisé). Concrètement, une tentative d'identification nécessite désormais de réussir un test opposé entre Guerre électronique+Scan contre Guerre électronique+ECCM. intercepter les communications wifi d'un noeud : Vu que tout le monde utilise tout le temps la matrice, on peut apprendre énormément de chose sur une cible en espionnant ses communications. C'est aussi une condition pour pouvoir tenter d'agir sur les communications de la cible (voir plus loin). Au niveau mécanisme, l'interception consiste à décrypter les messages à destination du noeud (ces messages contenant l'accessID du noeud en entête) pour identifier les noeuds qui dialogue avec lui et ainsi savoir quels sont les messages que le noeud cible envoi à ces noeuds parmi toutes les communications ambiantes, dans le but de les décrypter aussi. Au niveau des conditions, il faut connaitre l'accesID du noeud à espionner et se trouver à portée de signal du noeud. Si ces conditions sont réunies, il faut réussir un jet de Guerre électronique+Renifleur contre un seuil de difficulté de 3, ce qui permet de casser le chiffrement des infos de routage et connaitre ainsi les accessID des noeuds que contact le noeud cible, ainsi que leur localisation physique approximative en interprétant le flux de routage. Pour avoir accès au contenu des messages, il faut disposer d'un programme Decryptage d'un indice égal ou supérieur à l'indice des programmes de Cryptage éventuellement utilisés par le noeud ou ses interlocuteurs pour sécuriser leur communication (suivant le niveau des programmes des uns et des autres, il est possible de n'avoir accès qu'à une partie des conversations). Quand on inverse les rôles, pour éviter une interception, il faut là encore un signal faible pour limiter la zone d'interception et un bon programme de Cryptage (ainsi on pourra savoir avec qui vous discutez, ce qui est déjà une information, mais pas ce que vous dites). Enfin, il est possible de sécuriser ses communications si vous êtes doué en Guerre électronique. Dans ce cas, une tentative d'interception nécessite désormais de réussir un test opposé entre Guerre électronique+Renifleur contre Guerre électronique+ECCM. Trianguler la position d'un noeud donné : Connaitre l'accessID d'un noeud est utile, mais avoir sa position physique exacte c'est bien aussi si on veut par exemple localiser le porteur du noeud (autrement dit son Commlink) dans une foule et le pister par ce biais, ou bien pour savoir où ce cache le rigger qui dirige le gros drone de combat qui essai de vous tuer. Quand un noeud est en communication, ses messages sortant ne comportent aucune informations en clair sur l'identité de l'envoyeur, on ne sait donc pas quoi chercher comme message parmi le bruit de fond matriciel pour trianguler la position du noeud, tant que l'on a pas réussi à intercepter ses communications (voir l'action ci-dessus). Au niveau des conditions, il faut avoir réussi une interception des communications wifi du noeud (voir action ci-dessus). S'il émet avec un signal élevé, le mieux est d'avoir des antennes directionnelles pour la triangularisation. S'il émet à un signal faible, on peut le localiser approximativement en regardant la localisation des noeuds qui constitue le premier maillon de ses communications. Si ces conditions sont réunies, il faut réussir un jet de Guerre électronique+Renifleur contre un seuil de difficulté de 1 pour connaitre sa localisation (les succès excédentaires traduisent la précision de la localisation). Brouiller les communications d'un noeud donné : Une fois que l'on a intercepté les communications d'un noeud, il est possible de venir parasiter ses communications en émettant du bruit sur la même fréquence qu'une communication qu'il reçoit ou émet. L'avantage de cette méthode est sa relative discrétion (le noeud ciblé et ses interlocuteurs s'en rendent compte mais le reste des utilisateurs de la matrice n'ont pas conscience du brouillage (ca permet aussi de se débarrasser des brouilleurs officiels qui brouillent qu'à très courte portée et de les remplacer éventuellement par de vrai brouilleur d'usage militaire avec des portées en rapport avec leur signal). Au niveau des conditions, il faut avoir réussi une interception des communications wifi du noeud pour le brouiller et qu'il soit à porter de votre Signal. Si ces conditions sont réunies, il faut réussir un jet de Guerre électronique+Brouillage contre un seuil de difficulté de 2 pour brouiller les communications entrantes et/ou sortantes du noeud ciblé. A noter que si la cible est en RV au moment où vous brouiller ses communications, elle se prend un choc d'éjection. Pour se prémunir d'un brouillage, il faut disposer d'un programme ECCM afin d'établir un protocole d'évasion de fréquence avec les noeuds avec lesquels ont est en contact. Concrètement, une tentative de brouillage nécessite désormais de réussir un test opposé entre Guerre électronique+Brouillage contre Guerre électronique+ECCM. Falsifier les communications : Le brouillage des communications d'un noeud donné est une possibilité, mais parfois il peut être plus utile d'insérer de faux paquets de données dans une communications pour tromper les interlocuteurs. Au niveau des conditions, il faut avoir réussi une interception des communications wifi d'un noeud pour pouvoir falsifier un ordre/message arrivant au noeud ou en partant, et que le noeud soit à porter de votre Signal. Si ces conditions sont réunies, il faut réussir un jet de Guerre électronique+Falsification contre un seuil de difficulté de 3 pour falsifier un ordre ou un message. Le MJ est libre d'imposer un malus au jet suivant la nature de l'ordre et ses chances d'exécution (par exemple, un drone aérien a peu de chance d'accepter de rebooter en plein vol). Dans le doute, le MJ peut considérer que le possesseur du drone ou du noeud périphérique devant recevoir l'ordre, à donner des instructions sécurisant certains ordres par le biais d'un jet de Logique+Software, les succès devenant un malus au jet de Guerre électronique+Falsification. Voilà, j'espère que ca donnera un peu plus d'intérêt à la guerre électronique sur les tables de jeu... notamment pour les riggers qui veulent sécuriser leurs communications sans être limités à la sécurisation physique des communications (liaison par antenne directionnelle, liaison laser....), même si c'est ce qu'il y a de plus efficace. | |
| 23-09-2011 18:03:16 | #73 | |
| Valérian | Coût et disponibilité des programmes et options : Si je ne suis pas d'accord avec certains d'entre vous pour introduire la Logique dans les jets matricielles (et on va pas revenir là dessus), il peut être intéressant de rééquilibrer l'importance des programmes par rapport à la compétence de l'utilisateur, et je pense que ca peut être fait par le biais de la disponibilité (mais aussi du coût du programme). Comme je suis un fan des options de programme (ca permet d'offrir une richesse de gestion des softs comparable à ce qui existe pour un streetsam ou un rigger quand ils customisent leur matos, ca permet de varier un peu les plaisirs durant une passe matricielle et enfin ca permet de booster les CI contre les hackeurs sur certain jet pour corser un peu les choses aux hackeurs), j'en tient compte dans le calcul de la disponibilité. Ainsi, le soft maximum qu'on peut acheter à la création de perso (dispo 12) n'est plus un soft de niveau 5 avec 2 options, mais un soft de niveau 4 avec une seule option (petit rappel : on peut mettre une option sur un soft tout les 2 niveaux du programme). Une différence de 1 niveau du programme fait varier la disponibilité de 4, et chaque option augmente la disponibilité de 2. Concrètement : Dispo 2 : programme 2 Dispo 4 : programme 2 + option Dispo 6 : programme 3 Dispo 8 : programme 3 + option Dispo 10 : programme 4 Dispo 12 : programme 4 + option Dispo 14 : programme 4 + 2 options ou programme 5 Dispo 16 : programme 5 + option Dispo 18 : programme 5 + 2 options ou programme 6 Dispo 20 : programme 6 + option Dispo 22 : programme 6 + 2 options Dispo 24 : programme 6 + 3 options Ainsi, fini l'achat à la création de tous les softs au niveau 5 ou 6. Il va falloir monter en puissance en cours de partie et faire des choix dans les options à prendre pour chaque soft. Quant aux programmes de niveau élevé et bardé d'option, ils ont désormais une disponibilité proche de celle du matériel militaire (ce qu'il sont plus ou moins de toute manière). En complément, on peut revoir le prix des programmes pour avoir une échelle plus progressive (dans la règle de base, il y a un gap important pour passer au niveau 4, mais le passage à 5 ou 6 ne fait pas une grande différence) : Soft de hacking indice 1 : 500 Y Soft de hacking indice 2 : 1000 Y Soft de hacking indice 3 : 2000 Y Soft de hacking indice 4 : 4000 Y Soft de hacking indice 5 : 6000 Y Soft de hacking indice 6 : 8000 Y Dans mes règles, la plupart des programmes standard disparaissent... il ne reste finalement que Analyse et Cryptage (le reste étant géré par l'OS ou la Personna de l'utilisateur), aussi je les mettrais plutôt dans une catégorie de programme destinée aux CI où il y aurait aussi certains programmes de cybercombat (on retrouve dans cette liste : Analyse, Cryptage, ECCM, Attaque, Armure, Médic, Bombe matricielle). Cette catégorie a un coût par indice divisé par 2 par rapport aux programme de Hacking pur. A noter que l'on peut aussi utiliser le même tarif pour les sensor software, les Firewall, les Systèmes et les Autosofts. Les options coûtent 1000 Y par indice (une option sans indice coutant 3000 Y). Reste à savoir s'il ne faudrait pas revoir aussi l'échelle de prix des agents qui ont un gap très important quand on veut les acheter au niveau 4... mais faut-il prendre l'échelle des softs de hacking ou 2 x ces prix ? | |
| 26-09-2011 10:34:22 | #74 | |
| okhin | Ah, voilà, ça c'est intéressant (et ça va pemettre de donner des possibilités d'évolution au hacker sur le moyen terme). Pour les agents, aligne les sur les softs de hacking. Il faut cependant pas mal augmenter le coût de l'agent unlimited (ou unregistred, me rappelle plus), dans le canon c'est prix x 1.2 pour un système expert, ça me parait pas grand chose. Okhin | |
| 27-09-2011 00:55:33 | #75 | |
| Valérian | Après un intermède de Guerre électronique, retour au hacking : Après réflexion, si le bidouillage de programme par hacking (que j'ai déjà évoqué plus haut) est intéressant, ca implique des règles assez compliquées pour avoir un truc équilibré. De plus, ca me parait compliqué pour un hackeur d'interagir de manière discrète avec un programme appartenant à une CI/Persona (ce genre d'interaction relevant pour moi de l'agression dans le style cybercombat à l'instar d'une tentative de plantage du programme). Je préconise de garder la notion de reprogrammation, mais elle porterait sur l'altération des programmes chargés mais pas encore lancé (ainsi le programme n'est pas encore un élément intimement lié à la persona). En effet, il s'agit dans ce cas simplement d'une édition d'un fichier de données, ce que je gère dans mes règles via le programme "Crochetage" qui permet de modifier un fichier. De plus, comme le programme ne tourne pas, la modification peut être importante au niveau du fonctionnement du programme (alors que dans la solution que j'avais envisagée à l'origine, le fait de bidouiller un programme au nez et à la barbe d'un utilisateur impliquait une modification limitée pour avoir une chance de ne pas être détectée). A noter toutefois, qu'une modification d'un fichier chargé n'est pas effective tout de suite... il faut déjà que le programme soit lancé dans sa version modifiée. Petites précisions : le fait qu'un programme est déjà lancé n'empêche pas de modifier son fichier au statut "chargé" car la version qui tourne est une sorte de copie d'exécution). Implicitement, après modification d'un programme chargé, vous pouvez faire planter sa version en cours d'exécution (mais c'est un acte de cybercombat) afin que l'utilisateur recharge le programme modifié. D'autre part, on peut modifier qu'un programme chargé qu'à la condition d'être dans le noeud où le programme est chargé (vous ne pouvez pas modifier un programme d'une icône qui viendrait vous rendre visite dans votre noeud par exemple). Pour se prémunir contre la modification de ses programmes par un hackeur infiltré dans votre Commlink, il est possible d'ajouter à chaque programme une option de programme "Auto-cryptage" qui chiffre le programme chargé pour limiter le risque d'altération. Pour traiter un programme corrompu par un hackeur, il faut le restaurer à l'aide du programme Médic qui va comparer le programme chargé avec une version de référence (typiquement pour un programme du commerce, cela revient à télécharger à nouveau le programme). | |
| 28-09-2011 01:52:02 | #76 | |
| Valérian | Je reviens sur le cryptage/décryptage pour améliorer le mécanisme et permettre d'avoir recourt à un cryptage renforcé quand nécessaire : Mécanisme : Lorsque vous chiffrez un fichier ou une communication avec un programme d'indice X, vous avez le choix de la durée de chiffrement qui peut varier de "instantané" à 24 heures. Déchiffrer le fichier ou la communication avec la bonne clé prend la même durée que le chiffrement. Pour décrypter le fichier ou la communication sans la clé, il faut un programme de Décryptage d'indice supérieur à l'indice X du programme cryptage qui a été utilisé. L'opération ne demande pas de jet, mais elle a une durée de "indice X fois la durée de chiffrement" (ou X passes d'initiative si la durée de chiffrement était instantanée). Remarques : Si on veut chiffrer une donnée qui doit être disponible à tout instant, on utilise un chiffrement instantané. Le chiffrement plus long est utilisé pour les données à archiver ou pour protéger une donnée durant un temps donné. Il existe une option de programme Décryptage permettant de décrypter une donnée d'indice X avec un programme d'indice X (sinon un programme de cryptage d'indice 6 serait inviolable). Si le décryptage est interrompu (par exemple parce qu'un spider à fait planter votre programme), il doit être recommencé depuis le début. Pistage et interaction avec une icône : Il existe un programme Pistage (pas trouver d'autre nom pour l'instant) qui permet à une Persona ou une CI de : 1) Remonter la piste matricielle d'une icône afin d'obtenir sa localisation physique approximative. 2) Bloquer la connexion dans son mode actuel (RA, coldsim, hotsim) et ignorer une tentative de déconnexion de la part du propriétaire de l'icône (attention, ce n'est plus fait automatiquement par un programme Blackhammer). Au niveau règles, il faut au préalable avoir percé l'éventuelle Furtivité de l'icône. Ensuite, dans les deux cas (l'un au choix, pas les deux en même temps) il faut réussir un test opposé de Informatique+Pistage contre Hacking+Intrusion. Chaque tentative prend une action complexe, et une tentative est indétectable par l'icône ciblée. L'intérêt d'avoir la piste matricielle du hackeur est de pouvoir contrattaquer en lançant éventuellement une tentative de hacking de son commlink. L'intérêt d'avoir la localisation physique du Commlink du hackeur est de pouvoir éventuellement l'identifier physiquement (voir même le capturer si on peut se rendre sur place rapidement). L'intérêt de bloquer la connexion d'un hackeur est de lui tendre un piège pour pouvoir le défoncer en combat matriciel (à grand coup de blackhammer par exemple). Pour pouvoir réussir à ce déconnecter proprement, le hackeur va devoir faire planter le programme Pistage qui le bloque, sinon il est obligé de mettre fin sauvagement à la connexion mais cela provoque automatiquement un choc d'éjection. A noter enfin que cela concerne un hackeur qui c'est introduit dans le noeud via son programme Intrusion. En effet, s'il pirate un compte utilisateur existant, il utilise un protocole de connexion classique et le système connait directement sa piste matricielle et peut bloquer sa connexion sans jet (le système peut même déconnecter proprement l'utilisateur sans que ce dernier ne puisse rien faire). Un mot sur le cybercombat : en cas de défense totale, le défenseur peut ajouter son score de Cybercombat à sa pool de base de Réponse+Firewall (car dans les règles officielles, il n'est pas logique d'utiliser pour cela la compétence Hacking). Un mot sur le contrôle des drones/véhicules : Il est toujours possible de contrôler un drone (ou un véhicule) de 3 manières différentes : 1) en donnant des ordres aux drones qui est en mode autonome et qui va tenter d'interpréter l'ordre. 2) en pilotant à distance directement le drone. 3) en plongeant dans le drone. Un drone autonome utilise comme généralement comme attribut son indice d'Autopilote auquel il rajoute l'indice d'un autosoft adapté à la tâche à faire. Ainsi, les autosofts étoffent les possibilités d'un drone là où l'autopilote seul assure le service minimum. Pour tout ce qui sort de l'ordinaire, un autosoft est requis. Par exemple, si un drone marcheur est doté d'extrémités adhésives pour grimper aux murs, il lui faudra un autosoft Manœuvre pour pouvoir se déplacer dans le plan vertical. De même, pour pouvoir utiliser une arme, un drone doit disposer d'un autosoft Acquisition adapté au type d'arme. Un drone n'esquive pas spontanément, sauf si on lui a donné un Autosoft Défense, etc. Le pilotage à distance ne requière plus de programme Commande... qui d'ailleurs n'existe plus. En effet, il n'y a pas lieu d'avoir un programme générique permettant de tout piloter (et accessoirement, cela permet de se faire facilement une grosse pool de dés avec un bon programme Commande). En fait, chaque drone/véhicule incorpore dans son OS, une interface de commande adaptée au drone, et c'est celle interface qui est manipulée à distance par le pilote (au niveau pool de dés, on utilise donc l'autopilote/OS comme attribut à la place du programme Commande). A noter que le pilotage à distance, à l'instar du pilotage manuel, nécessite de consacrer une action complexe à chaque tour pour garder le contrôle de la trajectoire du drone/véhicule (problème que n'ont pas l'autopilote ou un rigger plongé dans le drone). Le pilotage à distance reste une forme de contrôle rudimentaire aux yeux des riggers car le vrai contrôle est la pongée dans le drone/véhicule car le rigger perçoit directement les données en provenance du drone (plutôt que de regarder des écrans de contrôle virtuels) et devient le drone (c'est pourquoi un rigger en plongée n'a plus à dépenser d'action complexe pour contrôler la trajectoire du drone car il fait cela aussi naturellement que de marcher). Techniquement, les données émanant des différents mécanismes et capteurs du drone sont collectés par l'OS qui va les transcrire en signaux Simsense grâce au module de rigging (obligatoire donc) pour transmission au rigger (au niveau pool de dés, on utilise donc l'autopilote/OS comme attribut... avec un bonus de +2 car tout rigger digne de ce nom dispose d'une simrig). Avec ses considérations, il faut revoir les pools de dés à utiliser (j'en profite pour revoir la logique de certains jets) : Pour un drone autonome : Initiative : Réponse+Autopilote (correspond à l'initiative matricielle d'un agent). Manœuvre : Autopilote+Manœuvre (autosoft facultatif). Perception/Détection : Senseur+Attention (autosoft facultatif). Infiltration : Autopilote+Opérations clandestines (autosoft obligatoire). Attaque : Senseur+Acquisition (autosoft obligatoire et adapté au type d'arme utilisé). Esquive : Senseur (autosoft Défense obligatoire). Esquive totale : Senseur+Défense (autosoft Défense obligatoire). Pour un drone piloté à distance ou dans lequel un rigger est plongé, on utilise les mêmes attributs mais avec les compétences du rigger : Initiative : celle du rigger. Manœuvre : Autopilote+Pilotage. Perception/Détection : Senseur+Perception. Infiltration : Autopilote+Infiltration. Attaque : Senseur+Armes de véhicule. Esquive : Senseur. Esquive totale : Senseur+Esquive. | |
| 28-09-2011 09:13:39 | #77 | |
| Paul Kauphart | Tu utilises senseurs sur esquive ET attaque ? Une raison particulière au fait de ne plus utiliser réponse pour l'esquive ? De même, pourquoi pas autopilote+arme de véhicule pour l'attaque ? | |
| 28-09-2011 09:50:21 | #78 | |
| Valérian | La réponse a du sens au niveau matricielle où tout est rapide, mais dans le monde réel, le temps de réaction de l'autopilote est bien plus élevé que le temps de réaction mécanique du drone... et comme il n'y a pas de caractéristique pour cela (la maniabilité est un modificateur, pas une carac directe), il me fallait autre chose pour l'esquive. De plus, je vois un autopilote comme le fonctionnement de base d'un drone, et tu viens l'améliorer avec des autosofts (donc un risque de baisse de Réponse alors qu'il doit mieux se débrouiller en théorie). Exemple : prenons un drone aérien. Avec un autosoft manœuvre, le drone connait mieux les limites de son enveloppe de vol donc il est plus maniable car il peut rogner sur ses marges de sécurité. Avec en plus un autosoft défense, il apprend à faire des manœuvres d'évasion pour ne pas être pris pour cible et avec un autosoft Opérations clandestines, il apprend à voler en profitant des couverts pour une meilleure discrétion. Avec un autopilote d'indice 3, tu as une baisse de réponse de 1 alors que le drone est bien plus doué pour se défendre qu'avant). Je vois aussi l'esquive comme une anticipation d'une menace pour se lancer dans une manoeuvre d'évasion, or qui dit anticipation, dit détection de la menace. Il me parait normal donc d'utiliser Senseur car un drone doté de 3 caméras couvrant 360°, un microphone localisant les bruits et un radar sera toujours plus à même de voir la menace à temps qu'un drone sourd et myope. Pour l'attaque, c'est déjà sur Senseur dans les règles officielles, et ca me parait relever effectivement de cette caractéristique car tu vas localiser ta cible et la viser par le biais d'un senseur (optique généralement mais un radar en plus ca en fait pas de mal). Je l'ai pas précisé, mais quand je parle de caractéristique Senseur, je la calcul suivant mes règles alter à moi. | |
| 28-09-2011 11:18:25 | #79 | |
| okhin | Pour le chiffrement, il y a pour moi deux cas distincts. Le chiffrement de flux (communication mono ou multi directionnelle, mais instantanée) qui a un chiffrage faible mais qui rend le déchiffrement caduque (une fois la conversation finie, on s'en fout un peu du contenu de la conversation, ce qui compte c'est son interception) et le chiffrement de données (là, par contre, on peut perdre 1h ou 2 à chiffrer un fichier, si ça permet de le protéger énormément). À mon sens les règles actuelles de SR4 sont très bien pour le chiffrement de flux, un 10 minutes pour intercepter et déchiffrer une communication, ça me paraît logique (et ça n'a pas d'intérêt). Attention, je parle uniquement du flux de donnée, pas des archives de cette conversation. En gros, faut se mettre sur un nœud par lequel transite toutes les données (soit le vpn, soit le nœud central de l'opérateur, soit l'un des émetteurs/récepteurs de la communication), puis déchiffrer le flux à la volée avant qu'il ne disparaisse (ou l'archiver pour analyse ultérieure). Le moyen le plus simple de faire ça, une fois la communication intercepté c'est un jet en opposition de Système + Chiffrement contre Système + Déchiffrement, cette action de chiffrement/déchiffrement coûte une action simple. Pour le chiffrement de fichier, en utilisant des codes et des clefs tournantes et autre, il est virtuellement possible de rendre impossible le déchiffrement de fichier. J'aurai tendance à faire faire un jet étendu avec une difficulté à atteindre égale à Système X Chiffrement. Ouais, comme ça, cash, carrément. Ça va déjà rendre improbable le déchiffrement avec un Decrypt à 3 a lors qu'en face on utilise de la crypto militaire. Et je changerai l'intervalle de temps: 1h en RV, 1 jour le reste du temps. Il existe par contre des suites de programmation permettant de réduire les intervalles de temps de programmation, et on pourrait imaginer qu'un matériel équivalent existe pour le cassage de clef. Okhin | |
| 28-09-2011 11:35:26 | #80 | |
| Paul Kauphart | ça se tiens, et j'ai envie de dire, pour les senseurs à part ta rêgle de calcul, ya pas vraiment autre chose quand tu personnalises tout le package.... Pour revenir sur le déchiffrage d'un code, j'aime beaucoup l'idée (que j'ai lu je sais plus où sur le forum, pardon pour le copyright) d'un intervalle qui augmente à chaque tentative du jet étendu, plutôt que d'interdire purement et simplement le déchiffrage par un programme faible. Quelque chose comme (tour de combat / minute / heure / jour / mois / année) me parait mal, et chaque succès excédentaire au delà du seuil permet de diviser la durée du dernier intervalle. Exemple : contre un programme de cryptage d'indice 3, seuil 6, je fais 5 succès au premier essai (1 tour) et re 5 succès au deuxième (1 minute = 20 tours, divisé par 4 succès exédentaires 5 tours), et en 6 tours j'ai craqué le code. Ensuite, les capacités de chiffrement sont très liés à la puissance de calcul, aussi plutôt qu'un jet étendu de guerre électronique+décryptage, je ferais réponse+décryptage. On ouvre ainsi la porte à l'aide au décryptage. Par exemple l'équipe d'en face utilise un cryptage de niveau 4, mon comlink a une réponse de 5 et j'ai un programme de décryptage de niveau 5. Avec la règle précédente, on peut compter bien 30 minutes pour casser le code. Le streetsam (ou le rigger peut importe) du groupe est pété de tune et dispose d'un comlink de réponse 6. Je lui demande un accès à son link pour que mon programme puisse utiliser sa puissance de calcul (d'un point de vu règle, on peut considérer une souscription et un programme de plus actif sur le link du streetsam), et on ajoute la réponse du link du sam (ou une partie, genre la moitié) à la pool de décryptage, assez pour espérer casser le code en moins d'une minute. Variante : On peut être encore plus violent et faire un jet étendu de réponse utilisé par le programme de décryptage + décryptage, où la réponse utilisé par le programme de décryptage est la somme des réponses utilisé par le programme sur tout les nœuds qu'il utilise (dans l'exemple ci-dessus par exemple, 4 sur mon link et 3 sur celui du sam, donc un total de 7) Voilà, j'espère que c'est clair ce que je raconte, je suis pas aussi doué que Valérian pour fixer mes idées. | |
| 28-09-2011 14:34:36 | #81 | |
| Valérian | J'ai choisi de simplifier au maximum le décryptage car vu que je garde le "principe de SR4" qu'il n'y a pas de chiffrement que l'on ne peut décrypter, cela revient seulement à ralentir une personne cherchant à décrypter quelque chose, d'où la durée de "Indice x durée de chiffrement" qui a le défaut d'être fixe mais éviter de devoir se taper un jet étendu. Comme le chiffrement/décryptage est une question de puissance de calcul et d'algorithme, j'ai choisi d'imposer un programme de décryptage d'indice supérieur à celui de Cryptage pour refléter le fait qu'un programme de décryptage basique (indice 2 ou 3) qui ne connait que les méthodes de cryptage classiques ne peut pas briser le chiffrement d'un programme de cryptage d'indice 5 ou 6 (cryptage quasi militaire)... où tout du moins, le temps de décryptage sera tellement long que ce n'est pas la peine d'avoir des règles pour savoir si c'est 3 mois, 14 jours et 21 heures ou 5 mois. Pour ce qui est des communications, elles sont déjà cryptée à minima, ce qui se reflète par le fait qu'un jet d'interception d'un signal wifi a une difficulté de 3 (sinon ce serait du 1 si toutes les infos étaient transmises en clair). Pour améliorer les choses, il faut utiliser les actions décrites plus haut de sécurisation des communications via un jet de Guerre électronique+ECCM dont les succès fixent le nouveau seuil qu'il faut dépasser (ca couvre en fait un cryptage plus puissant ou l'usage d'un protocole de communication reprogrammé intégralement). Pour une transmission, il est aussi possible de crypter le contenu du message (par exemple pour transmettre un rapport à son Johnson) et là, on utilise Cryptage et généralement une durée de chiffrement importante pour qu'une personne ayant intercepté la transmission arrive à la décrypter qu'une fois que l'information à périmée. Ca c'était pour les communications. Pour le cryptage de fichiers dans un noeud, on peut donner un programme Cryptage au Système pour qu'il chiffre tous les fichiers qu'il manipule, mais dans ce cas, il ne peut faire qu'un cryptage instantané qui se décrypte rapidement (Indice PI). Cela sert à éviter un décryptage par un éventuel hacker newbie qui réussirait à rentrer dans votre commlink sur un coup de chance, mais qui n'a pas forcément un programme suffisant pour décrypter vos données. A coté de cela, toutes les données qui n'ont pas besoin d'être accessibles instantanément (vos archives...), peuvent être chiffrées avec un intervalle long incompatible avec la durée d'un hacking (que j'ai volontairement fait tendu au niveau temps). Pour permettre un peu de variétés dans tout cela, il y a des options de programme à ajouter à son programme de décryptage, dont notamment : - Anti-plantage (pour éviter de se faire planter son programme au beau milieu d'un décryptage). - Double décryptage (pour pouvoir décrypter 2 fichiers en même temps avec la même exécution du programme Décryptage). - Algorithme amélioré (pour pouvoir décrypter un chiffrement de même indice que votre programme). - Décryptage rapide (qui peut être pris plusieurs fois et qui permet de diminuer la durée de décryptage d'une unité de temps de chiffrement, avec un minimum de 1 unité de temps). Avec cela, vous pouvez avoir un programme Décryptage d'indice 4 avec 2 options (algo amélioré et décryptage rapide). Il pourra ainsi casser un chiffrement d'indice 3 en 2 unités de temps au lieu de 3, et pourra aussi casser un chiffrement d'indice 4 en 3 unités. Mais vous pouvez prendre à la place un programme Décryptage d'indice 4 avec 2 fois l'option décryptage rapide et ainsi casser un code d'indice 3 en 1 seule unité de temps (soit aussi rapide qu'un déchiffrement avec la clé!). Par contre, il ne saura pas traiter un cryptage d'indice 4 ou plus. Le top SOTA est un programe Décryptage d'indice 6 avec option algorithme amélioré et 2 fois le décryptage rapide. Ca casse n'importe quoi relativement rapidement... mais ca a un coût de 17000 nuyens et une dispo de 24F. | |
| 30-09-2011 20:07:43 | #82 | |
| Valérian | En attendant que je termine de mettre au propre pour vous la poster ma liste enrichie des options de programmes, je voudrais aborder avec vous un domaine des hackeurs qui ne me parait pas exploiter au niveau qu'il devrait : la gestion de l'information. Dans ce domaine, je met bien sur la recherche d'information dans la matrice, mais aussi la veille permanente sur des domaines d'information pour se constituer ses propres bases de données d'info, la récupération de données protégées, l'échange d'informations via des réseaux de shadowrunner vendant les informations qu'ils récoltent, laisser des espions dans la matrice pour regarder qui vient consulter certaines données sensibles, repérer un espion avant qu'il vous repère, laisser trainer de fausses données dans la matrice et enfin l'exploitation d'informations pour en tirer un avantage concret (bonus en RA). Comme vous le voyez, c'est vaste et il y a très peu de règles officielles sur ces sujets alors que ca ressort assez souvent dans les parties. La recherche d'info dans la matrice : Déjà, exit le programme de recherche car je trouve plus intéressant de faire faire un jet de Logique+Recherche de données car pour trouver des informations exploitables, il faut être suffisamment malin pour trouver la bonne manière de rechercher l'information parmi la masse de données de la matrice et il faut aussi avoir une bonne capacité d'analyse pour évaluer la pertinence de ce que l'on trouve et comment revoir sa requête pour affiner la recherche ou partir sur de nouvelles pistes. Il faut ensuite envisager les paramètres agissant sur ce jet pour envisager les modificateurs qui vont bien. Le temps consacré à une recherche est important, soit parce qu'on peut être pris par le temps, soit à l'inverse parce qu'on a plein de temps devant soit. Je n'aime pas la gestion du temps des règles officielles (qui dépend au final du nombre de lancé durant un jet étendu) car je ne suis pas convaincu par l'intérêt d'un jet étendu. J'aurais tendance à gérer le temps comme un modificateur à la pool de dés, modificateur qui peut être un malus plus ou moins important si on est pris par le temps, voir s'il faut l'info quasi instantanément (par exemple si on est en plein baratin et qu'il faut répondre quelque chose de précis pour ne pas se faire griller). A l'inverse, si on prend son temps, voir si on a plein de temps devant soi, on bénéfice d'un bonus. C'est donc un modificateur qui peut dépendre des circonstances et/ou d'un choix du "hackeur". Pour la transcription en durée réelle, je dirais que c'est plus au MJ de donner une durée qui lui parait correspondre au temps que ca prend. Concrètement, je verrais bien 5 niveau de modificateur : Recherche en un temps très court (voir trop court) qui donne un malus. Recherche en étant pris par le temps qui donne un malus. Recherche avec un durée normale (pas de modificateur). Recherche en prenant son temps qui donne un bonus. Recherche en disposant de temps à volonté qui donne un bonus. Autre facteur important : les moyens mis en œuvre pour la recherche. A minima, une personne fait une recherche avec les fonctions de recherche intégré à sa persona. Je verrais bien la masse de cadre corporatiste s'offrir un agent jouant le rôle d'assistant virtuel qui vous aide à parcourir des masses de données (ou de site matriciel à explorer) et vous présente ce qui a le plus de rapport avec l'objet de votre requête. A l'extrême, on peut avoir une armada d'agent parcourt des sites matriciels à la recherche des données cherchées et repérant les liens vers d'autres sites potentiellement intéressant, le tout étant piloté par quelques agents aux capacités d'analyse boostées, lesquels vous dresse un rapport régulier des recherches et répercutent les ordres si vous réorientez la recherche sur de nouvelles pistes. Bien entendu, ce n'est pas le même budget. Concrètement, je verrais bien 4 niveaux de modificateur : Recherche seule. Recherche avec un agent. Recherche avec plusieurs agents et/ou des agents un peu améliorés en matière de capacité de recherche. Recherche avec une armada d'agent. A noter qu'il peut y avoir une corrélation entre les moyens et la durée que prend une recherche. D'autre part, lorsqu'on fonctionne en mode "lecture des rapports remontés par les agents", on peut éventuellement bosser à plusieurs pour éplucher l'information. Autre facteur qui me semble important : le domaine auquel se rattache les infos recherchées et l'expertise éventuelle que peut avoir le hackeur (ou non). L'idée est que c'est beaucoup plus dur d'exploiter des recoupements d'info ou d'extrapoler un sujet vers des sujets liés pouvant conduire à l'information, lorsqu'on comprend pas grand chose à ce que l'on recherche. A l'autre bout du spectre, ce n'est pas mieux, car faire une recherche quand la seule info que l'on ait soit un nom "Bob Johnson"... on va trouver de tout et surtout n'importe quoi sous la forme d'une tonne de données sans rapport avec le sujet. J'aurais tendance à dire qu'un hackeur va pouvoir exploiter les connaissances de ses camarades en matière de domaine d'expertise pour éviter des malus (ou sinon, il peut investir dans un knowsoft couvrant le domaine en question... si ca existe et que ca se vend). Là concrètement, j'ai pas encore d'idée précise sur les modificateurs à gérer (je prend les suggestions). Je me demande aussi s'il faut faire un distinction au niveau règles entre une recherche visant à collecter des infos et une recherche pour obtenir une info très précise ? En résumé, pour l'instant, j'ai un jet de Logique+Recherche avec des modificateurs à la pool de dés. Je pense que le nombre de succès doit traduire la pertinence et le volume d'information trouvée. Quelque chose comme 1 succès pour avoir des infos générales sur le sujet et quelques rumeurs jusqu'à 5 succès où on maîtrise à fond le sujet (voir pourquoi pas on a même une piste pour une info ultra secrète de première mains). Au passage, je dirais qu'avec un certain nombre de succès, on peut aussi avoir localiser une source d'information sécurisée (par exemple, en enquêtant sur quelqu'un, on a identifié qu'il est connu des services de police et que dans les archives de tel commissariat, on pourrait trouver son casier judiciaire... il n'y a plus qu'à y aller par hacking). De même, on peut avoir identifier un contact potentiel pour vendre une information intéressante. Là encore, je prend les suggestions pour bien calibrer la chose. Je n'ai pas évoqué le fait de sécuriser sa recherche pour éviter de se faire repérer et/ou repérer un éventuel espion surveillant des données jugées sensibles (éventuellement une fausse donnée d'ailleurs). De même, il faudrait pouvoir croiser les infos pour éviter d'être induit en erreur par une info erronée introduite dans la matrice pour nous aiguiller sur une fausse piste. Tout cela étant très intéressant, il faut pouvoir l'intégrer d'une manière ou d'une autre (par exemple avec un malus car ca ralenti la recherche et un jet opposé pour détecter ou non les pièges adverses). Constituer ses propres bases de données : Ca me parait utile pour un "hackeur" de se constituer des bases de données très régulièrement mise à jour sur un sujet donné (par exemple des activités d'une corporation donné), un peu à la manière d'une compétence de connaissance. On pourrait d'ailleurs imaginer que cela débouche sur un knowsoft reprenant les informations collectées (par exemple l'indice du knowsoft pouvant correspondre au nombre de succès d'un test de Logique+Recherche). A voir s'il faut limiter le nombre de "veilles" que peut faire en même temps un hackeur ? L'exploitation de l'information : En réfléchissant sur le rôle de la Logique, je me suis dis que c'est l'attribut des personnes capables de prévoir les choses et d'analyser les données, et il me paraitrait logique qu'une personne ayant un attribut fort et les bonnes connaissance matricielles soient plus à l'aise pour tirer avantage de la couche RA de la matrice. Exemple : je vois bien le hackeur comme étant le type qui a des agents de recherche qui tourne en fond de tâche, et que lorsqu'il rentre dans un bâtiment, télécharge le plan et détermine les différents chemins de sortie possibles. De même, il peut avoir la présence d'esprit d'enregistrer ce qu'il voit pour traiter l'information et identifier les éventuels personnes ou véhicules qui pourrait l'avoir pris en filature. Dans l'idée, le hackeur pourrait programmer des softs d'analyse ou des senseurs software pour remplir des tâches particulières et obtenir des bonus RA dans certaines situations (voir en faire profiter ses camarades). On retrouve un peu la même idée avec le principe des TacNets où finalement, il s'agit d'une exploitation de données senseurs et de base de données (carte locale 3D, bases sur les armes/véhicules,armures), avec une partie analyse (analyse tactique, projection des lignes de tir....). C'est le genre de routine de traitement de l'information qui me parait dans les cordes d'un hackeur avec une bonne logique. Est-ce que ca pourrait être utile de creuser cette voie pour en faire un domaine d'expertise des hackeurs dans l'exploitation de l'information ? | |
| 01-10-2011 14:51:23 | #83 | |
| Gris-Gris | Beau, gros boulot Valerian. Je ne suis pas assez calé sur les règles de matrice pour répondre quelque chose d'utile, ni même parfois pour suivre la discussion, mais il y a des choses vraiment intéressantes dans ton approche. | |
| 01-10-2011 15:52:07 | #84 | |
| LeFélis | Je plussoie Gris-Gris. Ca a l'air très intéressant. Dommage que je n'ai pas encore eu l'occasion de le tester. Une seule négative pour finir: J'ai lu le mot "crytage" assez souvent dans tes textes. Si tu pouvais le remplacer à chaque fois par "chiffrement", ca me ferait plaisir. Par exemple, la première phrase de la page devrait être "Je reviens sur le chiffrement/déchiffrement/décryptage pour améliorer le mécanisme [...]". Est-ce que tu penses présenter cette matrice revisitée sous forme d'un document utilisable en partie (imprimable, avec un plan, etc) ? | |
| 01-10-2011 22:59:08 | #85 | |
| Valérian | Pourtant j'ai fait des efforts pour le termes cryptage et chiffrement Sinon on est dans une partie "alter" donc pas forcément besoin de connaitre les règles officielles pour donner un avis ou des suggestions sur des points précis. Pour l'instant, tout n'est pas finalisé, donc pas de version imprimable. si ca intéresse du monde, je peux voir ce qui peut être fait (tout réécrire un chapitre matrice c'est probablement trop long, aussi il faudrait que je décrive mes règles en précisant bien ce que je garde du système de base et ce que je vire (j'ai surement une idée plus précise que ce que j'ai écris, du coup, je n'ai pas dit tout ce qu'il fallait virer/ignorer). | |
| 08-10-2011 21:47:20 | #86 | |
| Valérian | Je vous avais promis un topo sur les options de programmes... c'est chose faite : Options génériques (pour les programmes de hacking, les programmes standards et les autosofts) : Ergonomique : Le programme ne compte pas pour la charge processeur. Toutefois, un Commlink peut faire tourner au maximum un nombre de programmes ergonomiques égal à son attribut Système. Anti-crash : Le programme résiste au tentative de crash avec un bonus de +2 à son test de Système+Firewall. Arrêt rapide : Le programme passe du statut lancé au statut chargé en une action automatique (au lieu d'une action simple). Démarrage rapide : Le programme passe du statut chargé au statut lancé en une action simple (au lieu d'une action rapide). Auto-chiffrement (indice 1-6) : Lorsque le programme est chargé, le fichier du programme bénéficie d'un chiffrement du même indice que l'option afin de résister à une tentative de corruption du fichier. Limitation : Cette option permet d'introduire une limitation à l'usage d'un programme (ex : type de cible précis, usage limité de le temps ou en nombre d'utilisation, etc). Cette option ne compte pas parmi le nombre d'option que l'on peut mettre sur un programme. Options spécifiques au programme Plantage : Spécialisation crash OS : Le programme bénéficie d'un bonus de +2 aux tests destinés à planter un OS. Spécialisation crash (programme) : Le programme bénéficie d'un bonus de +2 aux tests destinés à planter un programme particulier. Cette option peut être prise plusieurs fois pour des programmes différents. Spécialisation crash (fonctionnalité) : Le programme bénéficie d'un bonus de +2 aux tests destinés à planter une fonctionnalité particulière. Cette option peut être prise plusieurs fois pour des fonctionnalités différentes. Plantage partiel : Lorsqu'un programme est crashé par un programme Plantage disposant de cette option, le programme ne repasse pas au statut chargé mais reste lancé tout en n'étant plus fonctionnel. Ainsi, l'utilisateur du programme va devoir l'arrêt lui même avant de pouvoir le relancer (pour éviter de perdre une action simple, une option Arrêt rapide peut s'avérer utile). Retard démarrage OS (indice 1-3) : Une fois que le programme a planté un OS, ce dernier redémarrera au bout d'une durée égale à Système+Indice tours de combat. Retard démarrage fonctionnalité (indice 1-6) : Une fois que le programme a planté une fonctionnalité, cette dernière redémarrera au bout d'une durée égale à Système+Indice passes d'initiative. Options spécifiques au programme Crochetage : Spécialisation crochetage (fonctionnalité) : Le programme bénéficie d'un bonus de +2 aux tests destinés à crocheter une fonctionnalité particulière. Cette option peut être prise plusieurs fois pour des fonctionnalités différentes. Spécialisation crochetage de fichier : Le programme bénéficie d'un bonus de +2 aux tests destinés à crocheter un fichier de données. Spécialisation désarmement: Le programme bénéficie d'un bonus de +2 aux tests destinés à désarmer une bombe matricielle. Options spécifiques au programme Analyse : Spécialisation détection de bombe : Le programme bénéficie d'un bonus de +2 aux tests destinés à détecter une bombe matricielle. Spécialisation analyse d'icône : Le programme bénéficie d'un bonus de +2 aux tests destinés à analyser une icône. Analyse automatique d'icône : Une fois par tour de combat, vous pouvez analyser une icône en dépensant seulement une action automatique au lieu d'une action simple. Cette option peut être prise plusieurs fois. ? Spécialisation fouille de noeud : Le programme bénéficie d'un bonus de +2 aux tests destinés à repérer un fichier dans un noeud. Partage automatique : Avec cette option, le programme Analyse peut partager automatiquement les données recueillies avec d'autres constructs définis par avance, alors qu'il faut dépenser une action automatique pour partager l'information normalement. Options spécifiques au programme Furtivité : Spécialisation anti-analyse : Le programme bénéficie d'un bonus de +2 aux tests destinés à empêcher une analyse de l'icône faisant tourner le programme. Furtivité défensive : Lorsque le programme Furtivité est utilisé dans le noeud où le programme a été lancé, l'icône propriétaire bénéficie d'un bonus de +2 aux tests destinés à éviter d'être repérer. Programmes fictifs : Lorsque l'icône furtive remporte un test en opposition lors d'une tentative d'analyse de son icône, plutôt que de rester floue, elle peut envoyer à la place une série fictive de programmes au construct ayant tenté l'analyse. Le propriétaire du programme Furtivité peut redéfinir la série fictive de programmes à sa convenance (liste de programme, niveau de chaque programme, etc), pour une action automatique. Icône fictive : Lorsque l'icône furtive remporte un test en opposition lors d'une tentative d'analyse de son icône, plutôt que de rester floue, elle peut envoyer à la place des données fictives relatives à l'icône au construct ayant tenté l'analyse. Le propriétaire du programme Furtivité peut redéfinir les données fictives à sa convenance (Type de construct, cyberdégâts, attributs, type d'OS ou de Firewall, etc), pour une action automatique. Alarme d'intrusion retardée : Lors d'une tentative d'intrusion, si le hackeur accumule assez de succès pour rentrer dans le noeud et que dans le même temps, le noeud accumule assez de succès pour vaincre le programme Furtivité du hackeur, celui-ci réussit à pénétrer dans le noeud en déclenchant une alarme (alors que normalement, sa tentative d'intrusion serait rejetée). Options spécifiques au programme Intrusion : Spécialisation anti-pistage : Le programme bénéficie d'un bonus de +2 aux tests destinés à empêcher le pistage de la connexion du hackeur. Spécialisation anti-blocage : Le programme bénéficie d'un bonus de +2 aux tests destinés à empêcher le blocage du mode de connexion du hackeur. Déconnexion instantanée : Le hackeur peut se déconnecter du noeud auquel il accède avec son programme intrusion en dépensant une action automatique (contre une action simple normalement). Balisage : Une fois que le hackeur s'est introduit dans un noeud, son programme Intrusion peut faciliter les intrusions d'autres constructs venant de son Commlink (s'il veut faire venir des agents de hacking sur le noeud) en leur procurant un bonus de +2 à leurs tests d'intrusion. Options spécifiques au programme Pistage : Spécialisation pistage : Le programme bénéficie d'un bonus de +2 aux tests destinés à identifier la piste matricielle de la cible. Spécialisation blocage : Le programme bénéficie d'un bonus de +2 aux tests destinés à bloquer le mode de connexion de la cible. Options spécifiques au programme Médic : Bâtisseur : Avec cette option, l'utilisateur dispose d'un bonus de +2 dés à ses jets pour restaurer un OS en train d'être planté. Mécanicien : Avec cette option, un agent ou une CI (mais pas une Persona) dispose d'un bonus de +2 dés à ses jets pour se soigner. Premier soin : Avec cette option, l'utilisateur est automatiquement soigné d'une case à la fin de chaque tour de combat à condition qu'il ne se soit pas soigné pendant le tour (le soin gratuit ne nécessite pas d'action ni de jet de dés). Options spécifiques au programme Attaque : Verrouillage : Le programme bénéficie d'un bonus de +2 aux tests d'attaque. Zone (indice 1-6) : L'option Zone permet à un programme d'attaque de toucher plusieurs cibles à la fois (l'attaquant choisi ses cibles qui doivent être dans le même noeud). Le programme permet d'attaquer un nombre de cibles supplémentaires au maximum égal à l'indice de l'option, mais pour chaque cible choisie, l'attaquant subit un malus de -1 dé. L'attaquant ne fait qu'un seul jet et compare ses réussites à la défense de chaque cible pour déterminer lesquelles sont touchées. Perce-armure (indice 1-3) : L'indice de l'option perce-armure agit comme un score de pénétration d'armure (PA) si la cible dispose d'un programme Armure. Rouille : Pour chaque attaque réussie (qu'elle inflige ou non des dégâts), un programme avec cette option diminue l'indice du programme Armure de la cible de 1 point. Il est possible de restaurer un programme Armure rouillé en rechargeant le programme. Backstab : Lorsqu'un programme d'Attaque avec cette option est utilisé pour attaquer une cible qui ne se défend pas (l'attaquant est furtif ou la cible est focalisée sur un autre noeud où elle est présente), alors les dégâts du programme sont augmentés de 2 points. Poison : Lorsqu'un programme d'Attaque avec cette option inflige des dégâts à une cible, les malus du moniteur de condition matricielle sont doublés. Nécrose : Lorsqu'un programme d'Attaque avec cette option inflige des dégâts, ces derniers ne peuvent être soigné par le biais d'un programme Médic. Cadavre : Lorsqu'un programme d'Attaque avec cette option détruit un agent (ou une CI), ce dernier et les programmes qu'il contient ne sont pas arrêtés sur le noeud où ils tournent, mais l'agent ne peut plus agir du tout. L'agent va devoir être arrêté par un administrateur ou un spider pour libérer la charge processeur correspondant. Hémorragie : Lorsqu'un programme d'Attaque avec cette option a infligé des dégâts à une cible, cette dernière va subir à la fin de chaque tour de combat, un dégât matriciel supplémentaire automatique. Si la cible est touché plusieurs fois, l'effet n'est pas cumulatif et reste à un seul dégât par tour. Options spécifiques au programme Blackhammer : Verrouillage : Le programme bénéficie d'un bonus de +2 aux tests d'attaque. Perce-filtre (indice 1-3) : L'indice de l'option perce-filtre agit comme un score de pénétration d'armure (PA) si la cible dispose d'un programme Filtre de Biofeedback. Options spécifiques au programme Armure : Carapace renforcée (indice 1-3) : L'indice de Carapace renforcée est déduit de l'indice de Perce-armure lorsqu'il faut déterminer la pénétration d'armure subie par l'icône protégée. Protection anti-bombe (indice 1-6) : L'indice de protection anti-bombe est ajouté à l'indice du programme Armure lorsqu'il doit spécifiquement encaisser des dégâts en provenance d'une bombe matricielle. Arme émoussée : Pour chaque attaque subie (qu'elle inflige ou non des dégâts), un programme Armure avec cette option diminue l'indice du programme Attaque de 1 point. Il est possible de restaurer un programme Attaque émoussé en rechargeant le programme. Retour de flamme (indice 1-3) : Pour chaque attaque subie (qu'elle inflige ou non des dégâts), un programme Armure avec cette option inflige un nombre de dégâts à l'attaquant égal à l'indice de l'option. Ces dégâts peuvent être encaissés normalement par l'attaquant. Protection anti-poison : Un programme Armure avec cette option immunise son porteur contre les effets de l'option Poison pour les dégâts reçus au moment où le programme Armure est actif (l'annulation d'effet n'étant pas rétroactif). Protection anti-nécrose : Un programme Armure avec cette option immunise son porteur contre les effets de l'option Nécrose pour les dégâts reçus au moment où le programme Armure est actif (l'annulation d'effet n'étant pas rétroactif). Protection anti-hémorragie : Un programme Armure avec cette option immunise son porteur contre les effets de l'option Hémorragie pour les dégâts reçus au moment où le programme Armure est actif (l'annulation d'effet n'étant pas rétroactif). Options spécifiques au programme bombe matricielle : Dégâts supplémentaires : Cette option ajoute 1D6 aux dégâts matriciels d'une bombe matricielle (3D6 pour les dégâts standards). Cette option peut être prise plusieurs fois. Dégâts Simsens : Lorsque la bombe se déclenche à l'encontre d'une Persona (incarnée ou non) évoluant en Réalité Virtuelle, cette option inflige un nombre de dégâts égal à l'indice de la bombe (dégâts physiques si la Persona est en Hotsim ou dégâts étourdissants si elle est en Coldsim). La cible résiste normalement à ces dégâts (lesquels sont complémentaires à un éventuel choc d'éjection si l'icône de la Persona ne résiste pas à la bombe). Détection difficile : Cette option procure un bonus de +2 aux tests de la bombe matricielle pour ne pas être détectée. Désarmement difficile : Cette option procure un bonus de +2 aux tests de la bombe matricielle pour résister à un désarmement. Options spécifiques au programme Filtre Biofeedback : Filtre renforcée (indice 1-3) : L'indice de cette option est déduit de l'indice de Perce-filtre lorsqu'il faut déterminer la baisse d'indice du filtre subie par l'icône protégée. Cette option s'applique uniquement si l'utilisateur est en Coldsim (et pas en Hotsim où le filtre biofeedback est court-circuité). Options spécifiques au programme Décryptage : Double traitement : Avec cette option, le programme Décryptage peut lancer deux cryptanalyse en parallèle. Cette option peut être prise plusieurs fois. Iso-décryptage : Avec cette option, le programme Décryptage peut décrypter des données avec un indice de chiffrement égal à l'indice du programme Décryptage (il faut un indice strictement supérieur au chiffrement sinon). décryptage rapide : Avec cette option, le temps nécessaire pour un Décryptage est réduit d'une unité de temps. Le temps ne peut être réduit à moins d'une unité de temps (car un décryptage ne peut aller plus vite qu'un déchiffrement). Cette option peut être prise plusieurs fois. Options spécifiques au programme Scan (et au programme Brouillage) : Résistance ECCM : Avec cette option, le programme Scan/Brouilleur bénéficie d'un bonus de +2 quand il est opposé à un programme ECCM. Options spécifiques au programme Renifleur : Résistance ECCM : Avec cette option, le programme Renifleur bénéficie d'un bonus de +2 quand il est opposé à un programme ECCM. Double traitement : Avec cette option, le programme Renifleur peut lancer deux cryptanalyse en parallèle. Cette option peut être prise plusieurs fois. Surveillance automatique : Avec cette option, le programme Renifleur peut surveiller automatiquement les flux interceptés à la recherche de mots clefs pour signaler les communications intéressantes au hackeur. Options spécifiques au programme ECCM : Spécialisation anti-scan : Le programme bénéficie d'un bonus de +2 aux tests destinés à contrer un programme Scan utilisé pour identifier votre noeud caché. Spécialisation anti-renifleur : Le programme bénéficie d'un bonus de +2 aux tests destinés à contrer un programme Renifleur utilisé pour intercepter vos communications. Spécialisation anti-brouilleur : Le programme bénéficie d'un bonus de +2 aux tests destinés à contrer un programme brouilleur utilisé pour brouiller vos communications. | |
| 09-10-2011 00:11:43 | #87 | |
| LeFélis | Elles sont nombreuses, ces options ! Auto-chiffrement (indice 1-6) : Lorsque le programme est chargé, le fichier du programme bénéficie d'un chiffrement du même indice que l'option afin de résister à une tentative de corruption du fichier. Que permet selon toi une corruption du fichier programme ? De le dupliquer ? De modifier les options ? De le rendre inutilisable ? | |
| 09-10-2011 01:38:54 | #88 | |
| Valérian | Je suis parti du principe que le seul moment où on pouvait altérer un programme, c'était avant qu'il soit exécuté par un construct, car un programme chargé n'est finalement qu'un "fichier". Ce que j'appelle corruption du programme, c'est reprogrammer son fonctionnement plus ou moins subtilement : Tu peux faire en sorte qu'il soit inopérant contre un accessID (par exemple pour que le programme Analyse ne te voit plus). Tu peux lui faire perdre de l'efficacité (perte d'indice). Tu peux introduire un mouchard dans un programme pour espionner ce qui est fait avec. Tu peux faire en sorte que le l'utilisateur d'un programme Attaque va s'autocibler à la première attaque. etc On pet détecter et réparer un programme corrompu avec le programme Medic (mais faut que je revois le mécanisme). | |
| 11-10-2011 14:01:03 | #89 | |
| Valérian | Après réflexion, je reviens sur la recherche : On fait un jet de Logique+Recherche de données, avec un certain nombre de modificateurs et le nombre de succès détermine le degré de réussite de la recherche. Modificateurs de durée : Recherche en étant pris par le temps : -4 Recherche plus rapide que le temps "normal" : -2 Recherche devant durer le temps "normal" : 0 Recherche en prenant son temps : +2 Ces modificateurs se basent sur un écart par rapport au temps "normal" que dois évaluer le MJ en fonction de la recherche entreprise. Pour les malus, cela peut résulter d'un choix mais souvent cela sera imposé par les circonstances du jet (ex : si vous devez trouver une info quasi instantanément pour préserver une couverture, vous subirez le malus de -4 à votre test). Modificateurs de moyen : Quelques agents de recherche en support : +1 Armada d'agents pilotés par d'autres agents : +2 Je limite les bonus octroyés dans cette catégorie car je ne souhaite pas favoriser la course à la puissance dans les moyens, préférant que ce soit les caractéristiques du personnage qui priment. Modificateurs de maitrise du sujet/domaine : Aucune connaissance du domaine par le hacker OU sujet particulièrement commun (ex : recherche sur un certain M Johnson) : -4 Nombreuses lacunes dans le domaine par le hacker OU sujet général aux contours vagues : -2 Connaissance normale du sujet par le hacker OU sujet relativement précis : 0 Le hackeur peut faire appel à un travail en collaboration pour profiter de l'expertise d'autrui lors d'une recherche, ce qui permet de diminuer voir annuler les malus éventuels par méconnaissance du sujet. A partir de ce même mécanisme de jet, on peut faire 3 types de recherche données : Collecte de données sur un domaine. Recherche d'indices/pistes/infos utiles. Trouver une information précise. Collecte de données (le hackeur obtient...) : 1 succès : des infos d'ordre général sur le sujet. 2 succès : une connaissance vulgarisée du sujet. 3 succès : une connaissance normale du sujet. 4 succès : une certaine expertise sur le sujet. Recherche d'indices/pistes/infos utiles (le hackeur obtient...) : 1 succès : des rumeurs. 2 succès : une info sérieuse et utile. 3 succès : plusieurs info sérieuses et utiles. 4 succès : une "localisation" pour trouver une info "exclusive" (Ex : obtenir le nom d'un contact via son réseau d'indicateur, qui est prêt à vous vendre une info de valeur, ou bien localiser un noeud sécurisé contenant une info très utile, comme par exemple aller chopper le casier judiciaire d'une personne sur un nom des forces de l'ordre). Cela constitue une piste au niveau du scénario que le hackeur va devoir poursuivre en jeu (par négociation ou hacking). A noter que le MJ peut éventuellement utiliser les 2 grilles d'interprétation des succès ci-dessus en même temps (pour un unique jet de recherche). La dernière grille d'interprétation est plus spécifique car elle concerne une information "unique" et précise, le nombre de succès traduisant la fiabilité de l'information. Trouver une information précise : 0 succès : information non trouvée. 1 succès : information trouvée. 2 succès : information recoupée. 3 succès : information certifiée. Il reste plus qu'à voir comment gérer la dissémination de fausses infos et la surveillance des recherches effectués par d'autres. | |
| 11-10-2011 14:08:03 | #90 | |
| Blade | Je rajouterais bien un modificateur "recherche discrète" et "recherche visible (posts sur des forums, petits hacks de systèmes peu sécurisés, etc.)" ainsi qu'un modificateur en fonction du nombre de nuyens investis. | |
| 12-10-2011 00:23:04 | #91 | |
| Valérian | Ca existe plus ou moins, mais j'ai limité cela à la recherche d'indice, à condition d'avoir 4 succès ou plus. Ainsi, ca ne créer pas de modificateur spécifique à un type de recherche, tout en gardant des possibilités narratives pour le MJ. Ainsi, avec 4 succès en recherche d'indice, le hackeur a pu trouver une piste pour se procurer un indice important pour sa recherche (et donc pour le scénar), mais pas l'indice directement, et ce sous la forme de soit (au choix du MJ suivant ce qui l'intéresse le plus pour son scénar) : - La localisation d'un serveur contenant l'information en question.... il lui faut lancer (ou pas) ensuite un hacking à gérer durant la partie. - un contact parmi les relations du hackeur qui est prêt à lui vendre un indice important... là, cette fois, cela peut impliquer toute l'équipe pour organiser un rendez-vous avec le contact afin de négocier le prix de cette information... ou bien une information que les joueurs vont devoir allez chercher en contrepartie. Après pour le coté discret/pas discret, je dirais que rien n'est réellement discret dans la matrice car même une consultation de données via un forum public peut te faire repérer par ta trace matricielle dans les métadonnées d'historique de consultation... à condition que quelqu'un est prévu de scruter ces infos pour voir qui vient les consulter et s'y intéresser, mais là, on arrive dans une stratégie d'agents espions laissés dans la matrice pour surveiller des données clés. C'est tout un aspect intéressant, mais je n'ai pas encore trouvé de règles simples et efficaces pour gérer ce genre de choses. J'envisage juste la possibilité que ca débouche sur un modificateur à la recherche traduisant le fait que l'on prend éventuellement des précautions lors de la recherche (ce qui fait perdre du temps et pourrait donner un malus de -2 par exemple), ce qui donnerait une chance de détecter une éventuelle manipulation d'information par quelqu'un. Au fait, j'ai ajouter dans mon message précédent, une remarque sur la participation d'autres membres de l'équipe pour profiter de leur connaissance et éviter des malus lors du jet. Je dirais aussi que la collecte de données relatives à un sujet peut permettre de compiler le tout sous la forme d'une base de données d'information avec un indice égal au nombre de succès obtenu. Plus tard, si on a besoin d'une info en rapport avec le sujet traité par la base de données, on fait sa recherche en s'appuyant sur cette base. Concrètement, je verrais bien un jet de 2xIndice et le nombre de succès défini le nombre de dés de bonus pour le jet de recherche (c'est le même mécanisme que ce que je préconise pour les sensor software assistant un utilisateur). On peut aussi envisager que ces bases de données soient soumises au mécanisme de baisse d'indice avec le temps (comme pour les softs hackés), à compenser éventuellement par une actualisation fréquente de la base d'information si on veut rester à la page. | |
| 17-10-2011 11:56:51 | #92 | |
| Valérian | J'ai réfléchi pour reprendre une partie des règles que j'avais proposées afin de bien gérer la "durée" d'un hacking qui doit être ni trop courte (c'est le risque avec ma proposition actuelle), ni trop longue (sinon ca met pas le hackeur sous pression) et idéalement, le nombre et le niveau des CI dans le noeuds hacké doit influencer cette durée (alors que ca ne joue pas forcément dans mon système à moi, le hackeur étant généralement ric-rac et aura un seul tour devant lui). Je pense donc complètement séparer la phase d'intrusion de la phase dans le noeud. Intrusion : Pour l'intrusion, le hackeur doit toujours accumuler Système+Firewall succès par un jet de Hacking+Intrusion, avant que le noeud accumule Réponse+Intrusion succès par un jet de Système+Firewall. Par rapport à ma première proposition, ce qui change c'est que Furtivité est remplacé par Intrusion pour le nombre de succès à obtenir par le noeud. Si le noeud obtient assez de succès, la tentative d'intrusion est un échec et le Firewall a détecté la tentative (et en informe son admin généralement) et peut fournir la piste matricielle conduisant au hackeur (car le Firewall peu retrouver les infos dans ce qu'à transmis le commlink du hackeur lors de la tentative). A noter que ca peut mettre parfois le hackeur dans la merde si sa position est ainsi révélée. J'aurais tendance à dire que si le hackeur interrompe sa tentative en plein milieu, la sanction est la même (dit autrement, quand on commence, on doit aller au bout de la tentative). Détection dans le noeud : J'abandonne l'idée d'ajouter des succès d'un jet de la part d'une CI de patrouille aux succès obtenus par le Firewall, jusqu'à atteindre le même seuil de Réponse+Furtivité. Toutefois, pour garder la notion de temps limité qui allait derrière, je pense revenir à un jet de détection classique à chaque tour, mais avec un gros bonus cumulatif à chaque nouveau jet pour que les CI de patrouille finissent par être meilleures que le hackeur. Concrètement : au moment de l'intrusion du hackeur dans le noeud, S'il y a une CI de patrouille dans le noeud, elle fait un jet de Pilote+Analyse contre Hacking+Furtivité et doit obtenir plus de succès que le hackeur pour le détecter (et déclencher une alerte). Au début de chacun des tours suivant, la CI refait le même test avec un bonus cumulatif de +3 dés (ce qui revient à lui donner un succès supplémentaire à chaque nouveau tour grosso modo). A noter que ces jets de "détection" ne compte pas comme des actions pour le hackeur. Pour les CI de patrouille, elles sont dédiées à cette tâche et n'ont pas d'actions de disponible durant les tours de combat, sauf si elle délaisse leur tâche (on peu par exemple leur donner des programmes d'attaque pour qu'elles chassent les intrus détectés), mais dans ce cas, elle ne pourront pas faire de jet de détection au début du tour suivant. Pour rappel, le jet de base détection des CI de patrouille peut être augmenté via : - un autosoft "homeground" qui peut donner son indice (max 3) au jet de détection d'une CI. - l'usage de plusieurs CI. La CI principale recevant un bonus correspondant au nombre de succès obtenu par les autres CI (ou un +2 pour des petites CI mais ca peut être un +3 voir +4 pour des CI beaucoup plus puissantes). | |
| 17-10-2011 13:07:57 | #93 | |
| Carmody | Je salue l'initiative de cette modification, mais cela ne répond pas à mon souci initial (bon c'est pas forcément le but non plus ) qui était de permettre au hacker de faire la couverture matricielle d'un run physique. C'est à dire une passe qui dure longtemps (le temps de l'inflitraiton physique en gros) et dont le but est de couvrir l'équipe d'infiltration physique (ouverture des portes, gestion des ascenseurs, caméras, senseurs divers et avariés...) Une piste peut-être (je réfléchis à voix haute, libre à toi de piocher ou non dans ces idées) est de ne faire des jets de la CI (et de cumuler les bonus) que pour les tours où le hacker fait quelque chose dans le noeud. Par exemple la CI va faire un jet quand le hacker ouvre la porte au reste de l'équipe, ensuite pendant 5 minutes le hacker va se contenter de regarder les flux des cameras pour indiquer à l'équipe la localisation des gardes et pendant ce temps la CI ne fera pas de jet. Ensuite le hacker devra modifier les images d'une camera pour qu'elle ne révèle pas la présence de l'équipe, et la CI fait un autre jet. | |
| 18-10-2011 00:02:00 | #94 | |
| Valérian | Je n'avais pas oublié qu'on n'avait pas tranché la question de ton cas de figure, mais je voulais déjà réfléchir pour savoir si ca ne devrait pas être fait autrement de manière à retomber dans un hacking en temps limité. Avant de savoir comme le hacker, il faut déjà savoir comment marche le système de sécurité. Vu que tu veux camper dans un noeud, je suppose donc que tu pars sur un noeud de sécurité central auquel l'ensemble des noeuds périphériques de sécurité (caméra, contrôle de porte, ascenseur...) transmet en continue des informations. Dans mon système, je dirais donc que tu as une fonctionnalité centralisant ces flux d'information pour les présenter à un utilisateur sous la forme d'une interface (l'équivalent matriciel d'une salle de contrôle). C'est cette fonctionnalité là que tu dois hacker pour t'en prendre au système de sécurité. Je suis d'accord avec ta proposition à une nuance près : quand on ne fait absolument rien dans le noeud, la CI ne fait pas de nouveau jet de détection à la fin du tour. Mais quand je dis absolument rien, c'est pas une seule action matricielle dans le noeud, même pas une perception matricielle car cette dernière n'est pas 100% passive. Concrètement, lorsque le hackeur rentre dans le noeud, la CI de patrouille scanne une première fois son icône (sans bonus au jet). Ensuite, à la fin de chaque tour où le hackeur a fait au moins une action matricielle, la CI refait un jet de détection avec un bonus cumulatif de +3 dés. Ainsi, ca revient à ce que j'ai décris dans mon message précédent, mais les rounds de hacking peuvent être discontinus. A noter que le tour où l'on se déconnecte, la CI ne fera pas de jet à la fin du tour (vu qu'on est plus là). Ex : avec un noeud présentant une CI d'indice 3 avec Analyse 3 (soit 6 dés) de base. La CI fait un jet avec 6 dés dès l'apparition du hackeur. Ce dernier ne fait rien dans le noeud pendant le tour en cours. La CI ne fait pas de nouveau jet à la fin du tour. Nouveau tour, le Hackeur commence à agir dans le noeud pendant ses 3 passes d'initiative. A la fin de ce deuxième tour, la CI fait son jet avec 9 dés. Au troisème tour, le hackeur ne fait rien, donc pas de nouveau jet de détection. Quatrième tour, le hackeur agit dans le noeud pendant une seule de ses PI. la CI fait donc à la fin du tour un nouveau jet de détection avec 12 dés cette fois ci. Eventuellement, je me tâte pour savoir s'il ne faudrait pas plutôt dire "chaque action matricielle réalisée durant le tour entraine un jet de détection de la CI à la fin du tour avec un bonus de +1 cumulable", plutôt que de considérer que "s'il y a au moins 1 action matricielle réalisée alors la CI fait un jet de détection avec un bonus de +3 cumulable". Ca revient a peu près au même pour un hackeur qui claque ses 3 PI du tour à agir dans un noeud, mais c'est plus cool si durant un tour, il ne fait qu'une seule PI de hacking (le jet de détection n'augmentant que de +1 et pas de +3 d'un coup). Pour revenir à l'exemple envisagé. Je dirais qu'il faut tout d'abord "utiliser la fonctionnalité" pour récupérer la liste des systèmes de sécurité (et leur accessID) et comprendre comment la fonction est programmée (jet de difficulté 1 +1 car c'est une fonction sécurité, +1 pour le faire discrètement et vraisemblablement +1 car il y aura généralement un spider en train d'utiliser cette fonctionnalité, soit un total de 4). Ensuite, 2 possibilités : Connaissance le plan du système de sécurité du bâtiment et les accessID des caméras, il est possible de hacker les caméras gênantes et une fois dedans, modifier le flux de données transmis au noeud de sécurité (jet de crochetage de fonctionnalité mais avec une difficulté plus faible par absence du spider, soit 3 voir 2 si on se fou de laisser des traces matricielles à cet endroit là). Aute possibilité, ayant vu comment marche la fonctionnalité (en copiant son code source en gros), le hackeur peut créer un script de reprogrammation (Logique+software contre une difficulté choisie par le MJ), ce qui prend un certain temps, puis quand il est prêt, il réactive son icône pour tenter cette fois une action de "reprogrammation de fonctionnalité" qui aura une difficulté de 5). Si ca passe, le hackeur a introduit une routine dans la fonctionnalité qui lui forward les infos des systèmes de sécurité, lui permettant éventuellement de les modifier avant de les faire afficher via la fonctionnalité à destination du spider (autrement dit, il est spider à la place du spider). toutefois, si ce dernier remarque la supercherie, il pourra toujours rebooter la fonctionnalité (ce qui prend Système PI) pour repartir sur le programme sein (et si l'équipe de runners est en plein milieu du bâtiment, il va falloir sortir via le plan B). | |
| 19-10-2011 01:22:16 | #95 | |
| Valérian | Quelques exemples de CI pour illustrer des manières différentes de concevoir une défense matricielle variée. CI de patrouille principale : ces CI sont prévues pour se consacrer uniquement à la tâche de patrouille. CI indice 3, programme Analyse 3 : la CI de base. CI indice 3, Analyse 3 et autosoft Territoire 3 : la CI avec détection améliorée. CI indice 3, Analyse 3, Furtivité 3 avec option programmes fictifs : cette version doit faire croire à un intrus qu'elle est blindée de programmes de combat et l'inciter à ne pas trainer dans le coin. CI indice 4, Analyse 4 avec option ergonomique : Douée et prenant peu de ressource, laissant ainsi la place à d'autres défenses. CI indice 4, Analyse 4, Territoire 4 : la CI avec détection au top. CI de patrouille complémentaire : Ces CI assistent la CI de patrouille principale, mais une fois un intrus détecté, elles vont agir à son encontre, délaissant la patrouille. CI indice 3, Analyse 3, Attaque 3 : la version basique mais capable d'attaquer un intrus. CI indice 3, Analyse 3 avec Ergonomique, Attaque 3 : une version d'attaque un peu moins gourmande en ressource. CI indice 3, Analyse 3 avec Ergonomique, Furtivité 3 avec Furtivité défensive, Attaque 3 avec Backstab : cette CI participe discrètement au patrouille jusqu'à ce qu'un intrus soit repérer et elle l'attaque alors par surprise. Souvent, elle sera chargée en double exemplaire pour une meilleure détection et plus de punch à l'attaque initiale. CI indice 3, Analyse 3 avec arrêt rapide, Attaque 3 avec Démarrage rapide, Armure 3 avec Démarrage rapide : cette CI bascule du mode patrouille au mode combat en une seule PI. CI indice 3, Analyse 3 avec Spécialisation analyse d'icône, Plantage 3 avec Spécialisation programme Intrusion : cette CI cherche à faire planter le programme Intrusion d'un hackeur pour le déconnecter plutôt que de l'attaquer en cybercombat. CI indice 3, Analyse 3, Blackhammer 3 avec Verrouillage : cette CI annonce la couleur : si vous êtes détecté, vous allez en prendre plein la tronche. CI indice 4, Analyse 4 avec Spécialisation analyse d'icône, Plantage 4 avec spécialisation programmes Attaque et Armure, Plantage 4 avec spécialisation programmes Crochetage et Décryptage : cette CI est chargée de pourrir l'intrus en plantant ces programmes. CI indice 4, Analyse 4 avec Spécialisation analyse d'icône et ergonomie, Plantage 4 avec spécialisation programmes Attaque et Plantage partiel, Plantage 4 avec spécialisation programmes Armure et Plantage partiel : cette CI est prévue pour handicaper l'intrus en cybercombat, facilitant ainsi la tâche aux CI de combat. CI indice 4, Analyse 4 avec arrêt rapide, Attaque 4 avec Verrouillage et Démarrage rapide, Armure 4 avec Arme émoussée et Démarrage rapide : cette CI bascule du mode patrouille au mode combat en une seule PI et s'avère un redoutable adversaire. CI gardienne furtive : elle protège une fonctionnalité ou un fichier de donnée en espérant ne pas se faire voir par un intrus, lequel va se révéler au moment d'accéder à l'item protégé. La CI en profite à ce moment là pour prendre par surprise l'intrus (pas de défense contre sa première attaque). CI indice 3, Furtivité 3, Attaque 3 : la version de base. CI indice 3, Furtivité 3 avec option Furtivité défensive, Attaque 3 avec option Backstab : la version de base boostée par des options. CI indice 3, Furtivité 3 avec Furtivité défensive, Attaque 3 avec Backstab, Autosoft Expert défensif 3 : après une première attaque douloureuse pour l'ennemi, la CI continue ses attaques en profitant d'une bonne défense pour durer dans le combat. CI indice 3, Furtivité 3 avec Furtivité défensive, Blackhammer 3 avec verrouillage, Expert offensif 3 : cette version est prévue pour faire très très mal à un hacker, notamment dès la première attaque par surprise. CI indice 4, Furtivité 4 avec Furtivité défensive, Attaque 4 avec Backstab et poison : cette version fait mal à l'intrus à la première attaque pour lui infliger un malus important et ainsi prendre un avantage pour le reste du combat. CI indice 4, Furtivité 4 avec Furtivité défensive, Attaque 4 avec Backstab et Hémorragie, Expert offensif 3 : cette version fait un maximum de dégâts à la première attaque et laisse ensuite l'intrus mourrir à petit feu (si elle ne l'achève pas avant). CI indice 4, Furtivité 4 avec Furtivité défensive et arrêt rapide, Attaque 4 avec Perce-armure 3 et verrouillage, Expert défensif 3 : cette CI est bonne en attaque et en défense. Elle coupe son programme furtivité dès la première attaque réalisée pour libérer de la charge processeur pour d'éventuels renforts. CI indice 4, Furtivité 4 avec Furtivité défensive, Analyse 4 avec Spécialisation analyse d'icône et Analyse automatique d'icône, Plantage 4 avec Spécialisation crash (Décryptage), Attaque 4 avec Backstab : cette CI protège une donnée cryptée et va analyser l'intru le temps que les CI de combat soit chargées pour une attaque multiple synchronisée. Elle peut aussi planter son programme Décryptage avant la fin de l'opération si nécessaire. CI indice 4, Furtivité 4 avec Furtivité défensive et arrêt rapide, Attaque 4 avec Backstab et arrêt rapide, Attaque 4 avec verrouillage et Perce-armure 3 : cette CI n'utilise pas le même programme pour l'attaque initiale et les attaques suivantes. CI gardienne encaissement : si vous ne faites pas confiance à une CI gardienne pour rester suffisamment discrète et ainsi surprendre l'adversaire, vous pouvez opter pour des CI qui sont conçues pour survivre à une attaque par surprise. CI indice 3, Armure 3, Médic 3 : cette CI cherche à survivre le plus longtemps possible et laisse les CI de combat attaquer l'intrus. CI indice 3, Armure 3, Médic 3, Expert Défensif 3 : version améliorée mais encore plus gourmande en ressource. CI indice 3, Armure 3 avec Carapace renforcée 3, Médic 3 avec Mécanicien : cette CI a des capacités améliorées pour survivre. CI indice 3, Armure 3 avec Carapace renforcée 3, Attaque 3 avec Verrouillage, Expert Défensif 3 : après avoir encaissé la première attaque, cette CI va contre attaquer. CI indice 3, Armure 3, Furtivité 3 avec Programmes fictifs : cette CI est conçue pour avoir l'air "intuable" et décourager un hacker. CI indice 3, Armure 3 avec Ergonomique, Médic 3 avec Premier soin, Expert Défensif 3 : cette CI ne fait que des esquives totales et compte sur son programme Médic avec premier soin pour estomper avec le temps les dégâts de la première attaque encaissée. CI indice 4, Armure 4 avec Carapace renforcée 3 et Ergonomique, Médic 4 avec Mécanicien et anti-crash, Attaque 4 avec Verrouillage : version puissante du programme, capable de se remettre sur pied en une seule PI. CI indice 4, Armure 4 avec Carapace renforcée 3, Analyse 4 avec Spécialisation analyse d'icône et Analyse automatique d'icône, Médic 4, Plantage 4 avec avec spécialisation programmes Attaque et Plantage partiel : la CI encaisse, puis va profiter de ses analyses gratuites de l'agresseur pour ensuite pouvoir faire planter son programme d'Attaque et ainsi se protéger. | |
| 20-10-2011 09:32:10 | #96 | |
| Valérian | A la réflexion, je ne vais peut être pas reprendre l'Autosoft Territoire qui permet de booster les jets de Perception matricielle des CI, car c'est un peu trop efficace pour les CI de patrouille principales. Si on veut améliorer la détection, il va donc falloir booster les attributs et programmes de la CI (mais on est limité par le Système) et/ou lui adjoindre des CI de patrouille complémentaires. Je pense aussi ne plus tenir compte de la limitation du niveau des programmes d'une CI par l'autopilote et juste gardé une limitation par le système. Ainsi, sur un noeud avec un Système de 4, on peut faire tourner une CI de niveau 3 seulement et lui donner des programmes pouvant monter jusqu'à un indice de 4 (contre 3 seulement avec les règles standard). Cela permettra un peu plus de diversité que des CI 3/programme 3 ou CI 4/programme 4 et compense l'absence de l'option "optimisation" que j'ai choisi de ne pas garder car c'était trop bourrin (surtout avec mes règles de chiffrement/décryptage basée sur l'indice). A signaler aussi que je garde la possibilité d'adjoindre à un noeud une (et une seule) "optimisation hardware" (voir Unwired) qui donne un bonus de +1 dé à l'usage d'un programme précis. C'est utile pour booster toutes les CI d'un noeud pour leur jet d'Analyse ou Furtivité ou Attaque par exemple, suivant la stratégie que l'on choisi d'avoir pour défendre le noeud. Concernant les prix et dispo du matériel, en plus du message que j'avais déjà posté sur les prix et dispo des programmes, je préciserais ceci : Les CI ont un prix égal à celui des programmes de hacking de même indice et une dispo égale à 3 x Indice de la CI (donc CI d'indice 4 max à la création). Les Agents/Pilotes ont un prix égal au double de celui des programmes hacking de même indice et une dispo égale à 4 x Indice (donc agent 3 max à la création). Le système a un prix indiqué dans le message que j'avais fais sur le sujet et la disponibilité est de 3 x Indice (donc Système 4 max à la création). Le système a un prix indiqué dans le message que j'avais fais sur le sujet et la disponibilité est de 2 x Indice (donc Firewall 6 max à la création). Les prix et dispo de la Réponse et du Signal sont inchangés par rapport aux règles standards. Pour info, je qualifie de CI un "agent" incorporant une liste fixe de programme et dédié à la tâche de défense matricielle. A l'inverse, un Agent est un construct polyvalent que l'on peut charger avec les programmes de son choix. Le Pilote étant un agent/système dédié à faire tourner un véhicule/drone précis (comme dans les règles standards pour ce dernier). | |
| 03-11-2011 13:07:07 | #97 | |
| Gris-Gris | Valerian, est-ce que tu as quelque part un fichier qui réunit toutes les infos que tu donnes ? Parce que c'est vraiment intéressant, mais tout lire sur un fil de discussion avec des choses qui changent en cours de route, c'est juste impossible. Je serais content de jeter un coup d'oeil à tes règles (et je ne suis certainement pas le seul). Si tu as une synthèse quelque part consultable, ce serait top. D'ailleurs un article dans le cybi serait 'achement bien aussi (Sly, sors de ce corps !)... | |
| 03-11-2011 14:00:47 | #98 | |
| Valérian | Je vais essayer de m'y atteler la semaine prochaine, pendant mes vacances. | |
| 03-11-2011 14:37:35 | #99 | |
| Gris-Gris | Cool  | |
| 10-11-2011 02:17:06 | #100 | |
| Valérian | Bon, j'ai relativement bien avancé mais ce n'est pas terminé. J'en ai fait un article sur le cybi avec en pièce jointe mon fichier de règles pour une matrice revisitée. Les auteurs ayant un compte sur le cybi peuvent y accéder dès à présent. J'accepte les commentaires s'il y a des trucs pas encore très clairs. | |
| 15-11-2011 01:19:03 | #101 | |
| Valérian | Bon, je ne suis plus très loin d'arriver au bout (d'ici ce week-end je pense). Les règles sont presque toutes écrites, reste à finir la liste des actions matricielles qui est une sorte de résumé et d'écrire la partie descriptive de la matrice. Je devrais finir avec entre 30 et 35 pages. | |
| 28-11-2011 00:32:52 | #102 | |
| Valérian | Bon, j'ai enfin terminé la rédaction du document de "synthèse" qui fait tout de même 36 pages. Comme je l'ai dit avant, c'est lisible dans la partie "rédacteur" du cyber-espace. Si vous le lisez et qu'il y a des trucs pas clairs, merci de m'en faire part, afin que je vois si je n'aurais pas oublié d'écrire quelque chose que j'ai en tête, des fois. | |
| 28-11-2011 17:39:14 | #103 | |
| Ydrien | Ou ce trouve cette partie rédacteur s'il vous plait ? Car j'ai beau chercher, mes clics ne me dirige pas vers les bon endroits Sinon merci bien pour le travail accomplis sur ces règles qui m'on l'air fort intéressant ! | |
| 28-11-2011 18:33:14 | #104 | |
| Kyomi | Il faut avoir un compte "auteur" sur le cyber-espace. Si tu souhaites en obtenir un, je t'invite à me contacter par mp en me donnant ton email. Le texte de Valerian sera publié quand le Cybi finira son redémarrage d'ici quelques semaines. | |
| 05-12-2011 02:11:52 | #105 | |
| Valérian | Outre mon article sur la partie "règle", je trouve intéressant et utile de construire une liste d'exemples de nœuds en détaillant pour chacun la sécurité matricielle (liste des CI, spiders...) que l'on peut rencontrer lors d'une tentative de hacking du noeud. Ca aurait le double avantage de fournir des noeuds clés en main aux MJ pour les cas où le hackeur des PJ fait une tentative de hacking pas prévue dans le scénar et ca offre aussi des exemples pouvant donner des idées aux MJ pour construire leur propre défense matricielle afin de renouveler l'expérience de jeu à chaque nouvel hacking. Si vous deviez définir une liste de type de noeuds à détailler, ce serait quoi ? | |
| 05-12-2011 10:14:32 | #106 | |
| okhin | Les nexus de cybercafé/d'accès public que l'on trouve partout Un nœud domestique par niveau de sécurité (genre, Squatter/Bas/Moyen/2Levé/Luxe) Une ou deux banques de données corpos orientés Une banque de données des ombres Whole.nu.you et autres nœuds de type commerciaux Des nœuds d'infrastructures gouvernementaux (genre les nœuds de coordination de la Lone STar au niveau local) Le gridlink Un ou deux nœuds particulièrement bizarre et paranoiaques pour pas grand chose (genre 2girls1cock.xxx et autres sites porno) Okhin | |
| 06-12-2011 18:28:33 | #107 | |
| Valérian | Après réflexion, j'aurais ca comme liste : un bar façon bouge dans les barrens (matrice très limité). un club privé (bar avec des fonctionnalités RA). appartement simple (noeud domotique basique). appartement d'un certain standing (noeud domotique plus securisé). noeud administratif gouvernemental ou corporatiste (sécu corpo de base pour les données). noeud pour entrepôt/atelier/commerce (sécu axée sur les biens physiques). Laboratoire corporatiste/base de données corpo (sécu de données poussée). Commlink de monsieur tout le monde (commlink non sécurisé). Commlink d'un employé corpo (sécurité minimale fournie par la corpo). Commlink d'un cadre corpo (sécurité correcte fournie par la corpo). Commlink d'un expert matriciel/personnalité corporatiste (sécurité poussée). Je me tâte pour savoir s'il faut des exemples spécifiques pour les véhicules/drones ? Vous voyez autre chose, sinon ? | |
| 06-12-2011 19:44:44 | #108 | |
| LeFélis | Durant une partie on s'est trouvé face à un helico de combat et notre MJ n'avait pas trop d'idée sur ca défense matricielle. Donc, je pense que cela peut servir d'avoir un exemple d'un noeud matriciel pour les véhicule ordinaires (civils ou faible sécurité) et un pour les véhicules de sécurité (militaire ou corporatif de haut niveau). | |
| 07-12-2011 23:08:09 | #109 | |
| Marion cobretti | un vehicule militaire occupé par des pilotes humains ne devrais pas etre hackable a mon humble avis | |
| 08-12-2011 05:18:30 | #110 | |
| LeFélis | Je crois que les véhicules militaires doivent avoir un programme pour les faire revenir à leur base en cas de défaillance (lire mort ou blessure grave) des pilotes, on peux en déduire qu'il y a au moins un moyen pour un hackeur d'entrer dedans (et surement bien d'autres). Et comme les véhicules militaires, genre hélico, sont manoeuvrés en full-sim par les pilotes, on peut donc en déduire qu'une fois dedans le hackeur peut accéder a tous les contrôles. Evidement, cela doit pas être simple de passer toutes les sécurités. Mais je ne sais pas comment les représenter. De nombreux noeuds a pirater les uns apres les autres ? Un bataillon de glaces noires en attente ? L'ensemble des hélicos sont surveillés depuis la base par plusieurs hackeur militaires ? | |
| 08-12-2011 09:52:44 | #111 | |
| Blade | Pour moi quand le pilote est sur place, le système de pilotage n'est pas connecté à l'extérieur (en cas de défaillance du pilote, le système peut switcher sa connexion pour le devenir). Il doit y avoir moyen d'y rentrer via le système de communication (qui lui est bien entendu accessible de l'extérieur) mais ça demande donc de rentrer d'abord dans ce système. Ensuite pour moi la sécurité c'est surtout des glaces, voire des hackers militaires qui patrouillent (dans le cas de véhicules riggués à distance), parce que forcer le pilote à se connecter à plein de noeuds c'est un coup à rallonger la séquence de décollage, ce qui n'est pas des plus pratiques en cas d'urgence. Et surtout il doit y avoir quelques mécanismes qui demandent une vérification supplémentaire : toute action qui pousserait le véhicule à se crasher, toute action qui pousserait le véhicule à ouvrir le feu sur des cibles amies, etc. | |
| 08-12-2011 12:08:35 | #112 | |
| Valérian | Si un hélico d'intervention/combat disposant d'un pilote doit opérer en solo, il ne sera pas hackable car le pilote va naturellement couper toute les connexions extérieures. Maintenant, il peut être très utile de pouvoir communiquer avec l'extérieur (sa base, les commandos déposés au sol, des unités/drones de reconnaissance), donc les cas où toute connexion externe est bloquée ne sont pas si nombreux que cela (notamment, il est très utile de pouvoir envoyer des drones de reconnaissance dans la drop zone où veut se poser l'hélico pour y repérer des menaces éventuelles). Pour sécuriser son réseau, le pilote (qui est un rigger logiquement), va privilégier les solutions relevant de la guerre électronique (nœuds cachés, protocole de communication sécurisé, voir utilisation de moyen de transmission directionnels par faisceau). Un hackeur en face va donc devoir être doué en guerre électronique s'il veut arriver à récupérer l'adresse du nœud de l'hélico pour une attaque matricielle). Si un hackeur réussit à s'introduire dans le nœud de l'hélico, celui ci disposera de CI pour sécuriser la fonctionnalité de pilotage et repousser le hackeur. Il faut voir aussi que le rigger sera probablement doué en combat matriciel et pourra activement contribuer à chasser le hackeur. | |
| 09-12-2011 02:20:07 | #113 | |
| LeFélis | Ca me semble bien comme solution. Combien de glace (pour avoir un ordre d'idée) ? | |
| 09-12-2011 06:46:22 | #114 | |
| Dahrken | Une remarque aussi : il est probable que l'hélico sera équipé de l'équivalent d'un gros bouton rouge pour couper toutes ses connexions matricielles et basculer en mode "autonome" en cas d'intrusion matricielle qui devienne ingérable par l'équipage. Au prix d'un hélico de combat ça me paraît du simple bon sens. | |
| 09-12-2011 07:21:32 | #115 | |
| GenoSicK | Un élément à ne pas oublier, c'est un hélico de combat se pilote rarement seul en dehors des films. En 2070, on peut très bien imaginer que le travail du copilote ne concerne pas que les systèmes d'armements, mais aussi la prévention des attaques électroniques et la gestion de la flotte de drones embarquées. | |
| 09-12-2011 12:18:54 | #116 | |
| Marion cobretti | pour moi ghost in the shell la serie nous montre tres bien comment fonctionne l’hélicoptère au niveau des communications. seul équipage peut piloter l'helico et actionner les armes, les communications entrantes même si complètement vérolée ne devrais etre capable que de donner des information incoherentes sur le HUD du pilote et/ou des informations sonore/ texte aberrantes. C'est finalement le gros point positif d'un humain dans un véhicule, il ne se hack pas. C'est pour moi la meme rengaine qu'un street sam, tous ces implants qui perçoivent ou influence le monde réel sont définitivement déconnecté de la matrice c'est quasi obligatoire, car sans parler des hackers il y a tous simplement les virus qui infecte toujours a peut prêt toute l'informatique relié a la matrice. Donc non non non on ne devrai pas pouvoir hacker un hélicoptère de combat , après son système de contrôle de drones la oui ça parait évident que ca soit possible , mais ça n'est qu'un organe non-vital du système. | |
| 15-12-2011 18:13:59 | #117 | |
| Mephisto | Marion cobretti a écrit: Donc non non non on ne devrai pas pouvoir hacker Il y a beaucoup de choses qu'on ne devrait pas pouvoir faire dans Shadowrun, comme pouvoir déchiffrer tout et n'importe quoi. C'est le genre de chose qui est permis, car cela rend le jeu "plus intéressant". Dans le cas de l'hélicoptère de combat, on peut supposer qu'il s'agit d'un petit bijou de technologie et qu'un tas de systèmes sont automatisés pour faciliter la vie du pilote, en se basant notamment sur des signaux qui proviennent de l'extérieur, comme les données récoltées par plusieurs radars et centres de commandement positionnés au sol ou d'autres appareils alliés à proximité (un peu sur le même principe que le tacnet). Jusqu'à quel point le système qui exploite ces données est-il découplé du système de contrôle de l'appareil? Est-il vraiment impossible pour un hacker doué d'en tirer parti pour prendre le contrôle de l'hélicoptère? Personnellement, je ne donnerais pas une réponse aussi catégorique. Après tout, si le MJ estime que cela pourrait rendre le jeu "plus intéressant", pourquoi pas. | |
| 15-12-2011 18:18:55 | #118 | |
| Blade | Le moindre mage peut foutre en l'air un hélicoptère d'une dizaine de façons différentes, donc d'un point de vue "équilibre du jeu", c'est pas un problème si le hacker peut en faire autant. Après c'est une question de cohérence de l'univers : soit les corpos font accompagner les hélicos par des esprits pour éviter les problèmes avec les mages et sécurisent matriciellement pour limiter les risques de hacking, soit elles envoient pas d'hélico quand elles savent qu'en face y'a un hacker ou un mage, ou alors elles évitent de mettre l'hélico dans une situation où il risque d'être victime de l'un ou de l'autre. | |
| 15-12-2011 21:04:54 | #119 | |
| Tatourmi | Perso je considère que sur du matériel militaire si il y a quelque chose qui sort (Signal radio) ce n'est pas connecté à l'infrastructure vitale et caetera, et tout est sécurisé quoi qu'il en soit. Je pense qu'il y a moyen de le hacker (Il y a bien évidemment des programmes dedans, un ordinateur de bord et un pilote automatique), mais pas depuis l'extérieur. Et pour la magie... Bon... La magie quoi... | |
| 15-12-2011 22:16:14 | #120 | |
| GenoSicK | Ça me rappelle cette vision des corpos que j'avais, quand j'étais encore jeune et naïf, du bleu dans les yeux, et que je les imaginait comme des prédateurs économique optimisés et affutés. Maintenant, je sais que la plupart sont des monstres de complexité et d'inefficacité, ne survivant que parce qu'elles peuvent écraser l'opposition par leur seule masse économique. (si quelqu'un peut retrouver d'où sort cette citation, je lui en serai reconnaissant  )Faut pas penser en rôliste optimisateur pour imaginer ce genre d'appareils. Faut penser en expert-comptable. Une armée ne commande pas 2500 des meilleurs hélicos de combat au monde, plus performants sur tous les plans et sécurisés jusqu'à la moelle. Son département comptable achète 2500 hélicos de combat au constructeur qui démontre le meilleur rapport qualité/prix, en respectant les standards minimum du contrat et qui a le plus rempli les poches des responsables. C'est exactement la même problématique que pour les serveurs corpos. Pourquoi se faire chier à avoir la sécurité absolue quand elle coûte bien trop cher et ne sert quasiment jamais ? | |
| 15-12-2011 22:23:36 | #121 | |
| JoKeR | Oui. Bon après on peut aussi estimer que y a des gens / services compétents et des enjeux particulièrement sensibles. Mais pas systématiquement, c'est sûr. | |
| 15-12-2011 22:28:50 | #122 | |
| GenoSicK | Effectivement. On peut d'ailleurs imaginer que les appareils de dotation de la Delta Force et de Firewatch ne sont pas les mêmes que ceux de la Garde Nationale. De même que ceux des rangers sur une mission sensible peuvent avoir un hacker assigné à la sécurisation matricielle. Mais pourquoi se faire chier à blinder de manière permanente la sécurité matricielle alors que ça peut se rajouter à la volée et à distance ?  Sans parler de la proposition de laisser la sécu informatique à celui qui gère déjà les comms et les drones : le copilote. EDIT Tiens, puisqu'on en est au volet économique, parlons de la sous-traitance. Vu l'état actuel de l'armée US (qui inspire pas mal de monde, malheureusement), on peut sans se tromper estimer que la sécurité matricielle de leurs hélicos sera sous-traité à Ares, qui leur a déjà vendu les hélicos. Dans un souci de compatibilité, vous pensez bien.  Bref, que fait Ares ? Elle vend des hélicos 20% plus cher pour les rendre inviolables ? Ou elles assurent la sécu matricielle et magique adaptée, selon la sensibilité de la mission et avec de vrais spécialistes du cybercombat et du MIJI qui n'ont pas passé 5 ans à apprendre à faire voler cet engin du diable ? | |
| 15-12-2011 22:34:54 | #123 | |
| okhin | Géno, j'ajouterai les conflits d'intérêt. L'armée des UCAS achètera ses hélicos chez Ares et Boeing, pas à ESPRIT (qui d'ailleurs fourgue à l'Europe). Et servira souvent de contrat d'apparat (comme les rafales qui ne se vendent pas par exemple). Et les contrats d'armement (ou de matériel industriel/de communicatin, cf BlueCoat et autres) ne sont pas souvent rentable, ce sont souvent des contrats politiques, qui vont créer/renforcer une alliance. Depuis la cour corpo, ça marche pareil pour les mégacorps. Le GPP achètera plus probablement à des AA et des A prometteuse ses hélicos de combat qu'à Ares. Okhin | |
| 17-12-2011 17:00:32 | #124 | |
| JoKeR | J'ai rebondit sur la question de l'optimisation et de la cohérence des corporations ici. | |
| 18-12-2011 17:41:02 | #125 | |
| Valérian | APPEL à CONTRIBUTION : J'ai préparé un document contenant environ 90 CI toutes faites pour servir un peu de catalogue quand on compose une défense matricielle. Là où j'aurais besoin d'un coup de main, c'est pour trouver des noms à ces CI afin de les personnaliser un peu. Idéalement, il faudrait le nom de la corpo l'ayant produit et le nom de la CI qui doit respecter le type de dénomination de la corpo (genre un nom japonais pour Renraku et espagnol pour Aztechnology) et refleter un peu le rôle de la CI (genre éviter d'appeler "ultimate warrior" une CI qui a juste un programme analyse). J'ai en stock : 9 CI de patrouille principale (détection) 11 CI de patrouille secondaire (détection+combat) 9 CI de patrouille secondaire (détection+plantage) 6 CI de supervision (surveillance des autres CI) 4 CI de supervision avec détection 5 CI de supervision avec détection et commandement de la défense du noeud 9 CI gardiennes misant sur la furtivité 12 CI gardiennes misant sur l'encaissement des dégâts 17 CI de combat avec un programme d'attaque 7 CI de combat avec un programme blackhammer | |
| 19-12-2011 07:23:22 | #126 | |
| Cheschire Cat | Personnellement, je me tape souvent des trips sur les noms de commlinks et d'OS entre autres, donc c'est un plaisir que d'essayer d'apporter du fluff comme ça. Je n’ai pas lu tout le sujet, attendant tranquillement la parution :P ainsi je ne sais pas exactement ce que tu as prévu pour les CI question niveau (est-il fixe ? etc.). Je donne simplement des idées, probablement pas magnifiques mais bon… ^^ Donc, en vrac, après avoir parcouru vite fait Corporate Guide pour me rappeler vaguement les diverses filiales tournées softwares (le nom apparaît toujours devant)… - Patrouille principale = Shiawase Vector Tower ; Microdeck ; AZ Mirador ; - Patrouille secondaire (détection+combat) = KE Recon – Alpha, Beta, Gamma selon le niveau ; Wolware HyenaBot ; DhakaSoft Jaguar VI (chiffre dépend de l’année, un par année depuis 2065) ; - Patrouille secondaire (détection+plantage) = Securitech Raiden Jolt ; Singularity Retribution G (pour « gremlins ») ; - Supervision = Renraku Shuseki (chef de réunion) ; Tetradyne MatrixPulse ; - Supervision + détection = Black Lotus Zujou (là-haut dans le ciel) ; - Supervision + détection + commandement = Novatech Cerberus II ; - Gardiennes furtivité = Mangadyne Ears in the Wall ; - Gardiennes encaissement = Ætherlink Marshmallow ; Wakatta Sumotori Pounder ; Easter Electronics Fenghuang (phénix en gros) ; MCT LightPhoenix ; - Combat attaque = DhakaSoft Machete ; Quick Trigger Systems MatSWAT (pour Matrix SWAT ^^’) ; AT&T Blitzfeuer (Feu éclair) ; - Combat avec blackhammer = MCT SanBaiRei (triple zéro) ; Xiao-Renraku Satsujin (assassinat) ; Je continuerai quand l'inspiration reviendra. | |
| 19-12-2011 10:34:25 | #127 | |
| Valérian | voilà, tu as parfaitement compris le truc. Merci. | |