Shadowrun en français
Vous n’êtes pas identifié.
J'ai un petit problème avec un de mes joueurs : il est rigger, et il dispose d'un van amélioré assez puissant (j'aurais jamais dû lui autoriser ça !).
Histoire de l'empêcher de faire tout et n'importe quoi avec son véhicule, je me suis demandé si je ne pouvais pas envoyer un hacker brouiller sa connection avec le van, voire en prendre le contrôle et le retourner contre les PJ ^^
J'ai effectué une recherche sur le forum et je suis tombé sur cette discussion qui me donne déjà une base de réflexion. Mais je me suis aperçu qu'un hacker qui tente de faire tout ça pendant un combat tactique aura beaucoup de mal à parvenir à ses fins, ou alors il y arrivera trop tard (i.e. le combat aura pris fin).
Je me suis alors demandé s'il n'y avait pas un autre moyen de gêner un rigger qui contrôle un drone. Et je pense avoir trouvé, mais j'aurais besoin d'un coup de main au niveau des règles, notamment dans certaines situations.
En tant qu'abonné actif, le drone fait partie du PAN de son utlisateur (SR4 VF, p. 213 et 240). Le comm et le drone communiquent donc par WiFi (le drone reçoit les ordres et renvoit tout un tas de données provenant de ses senseurs). Conclusion : un hacker à portée de signal (de l'un ou de l'autre) peut intercepter le signal comme suit :
1° Décryptage du signal (si le signal est crypté, ou si on le considère comme tel, ce qui paraît tout de même normal) par un test étendu Décryptage + Réponse (cryptage x 2, 1 TC).
2° Interception de signal sans fil avec Guerre Electronique + Renifleur (3)
Au passage, je trouve idiot de devoir décrypter quelque chose qu'on n'a pas encore intercepter. Il y a a mon sens un bug de règles : pour intercepter un signal, il faut d'abord le décrypter, mais comment savoir que le signal que je suis en train de décrypter est le bon ? Ou alors il me manque une étape, mais je ne vois pas laquelle.
Il est impossible de détecter l'interception d'un signal (SR4 VF, p. 227), donc pas de problèmes pour le hacker. Une fois le signal intercepté, il peut s'amuser de diverses façons :
- rediriger le signal vers son propre comm. Même pas besoin de test. Une question à ce sujet : peut-il alors envoyer un ordre en faisant croire qu'il provient du comm de celui qui contrôle effectivement le drone ?
- modifier le signal pour que le drone fasse l'inverse de ce qu'on lui demande, pour qu'il renvoie de fausses informations venant de ses senseurs au rigger, ou que sais-je ? (Hacking + Edition)
- euh... si vous avez d'autres idées, n'hésitez pas à m'en faire part ![]()
Bref, selon vous, est-ce que cette solution est viable ? Evidemment, si l'utilisateur du drone est branché directement par câble, ça ne peut pas marcher... On en revient alors à un bon vieux hacking des familles (voir l'autre sujet).
Quelle différence y a-t-il entre un hacker qui contrôle un drone sans interface de rigging et un rigger en plongée dans un véhicule (du point de vue du hacker qui veut empêcher le drone de fonctionner correctement) ? A priori, je n'en vois pas vraiment, mais je me trompe peut-être.
Dans le cas où j'aurais tout bon, que peut faire le rigger pour neutraliser l'interception/modification du signal ?
Edit : après lecture des FAQ (oui, j'aurais pu les lire plus tôt :p), d'autres questions me viennent.
FAQ a écrit:
Peut-on utiliser le programme Édition pour éditer le signal sans fil émis entre un rigger et ses drones pour lui donner des ordres totalement différents ?
Non. C’est le rôle de Falsification (voir p. 226, SR4).
Bon, ok, j'avais aussi pensé à imiter un ordre, mais ça implique que le hacker réussisse d'abord un test de Perception Matricielle sur le persona du rigger/utilisateur du drone. Comment dès lors ne pas être grillé ? Sans compter que le drone pourra résister avec Autopilote + Firewall...
En même temps, une simple action d'Edition doit pouvoir permettre de faire quelques chose quand même : la FAQ parle de donner des ordres totalement différents, mais en éditant un ordre il doit être possible de modifier juste un paramètres (par exemple changer "tourne à gauche" en 'tourne à droite", "tire sur le troll" en "ne tire pas sur le troll", etc...). Non ?
Dernière modification par Erlin le Sage (24/12/2007 12:20:42)
Hors ligne
Erlin le Sage a écrit:
Au passage, je trouve idiot de devoir décrypter quelque chose qu'on n'a pas encore intercepter. Il y a a mon sens un bug de règles : pour intercepter un signal, il faut d'abord le décrypter, mais comment savoir que le signal que je suis en train de décrypter est le bon ? Ou alors il me manque une étape, mais je ne vois pas laquelle.
Avant de décrypter un signal, il faut le capter.
Erlin le Sage a écrit:
- rediriger le signal vers son propre comm. Même pas besoin de test. Une question à ce sujet : peut-il alors envoyer un ordre en faisant croire qu'il provient du comm de celui qui contrôle effectivement le drone ?
Oui, mais c'est une Falsification, ça, donc un autre test.
Erlin le Sage a écrit:
- modifier le signal pour que le drone fasse l'inverse de ce qu'on lui demande, pour qu'il renvoie de fausses informations venant de ses senseurs au rigger, ou que sais-je ? (Hacking + Edition)
Toujours Falsification.
Erlin le Sage a écrit:
- euh... si vous avez d'autres idées, n'hésitez pas à m'en faire part
De base, le brouillage des signaux.
Erlin le Sage a écrit:
Dans le cas où j'aurais tout bon, que peut faire le rigger pour neutraliser l'interception/modification du signal ?
Un bon cryptage, pour commencer. Ensuite, une surveillance du secteur.
Erlin le Sage a écrit:
Bon, ok, j'avais aussi pensé à imiter un ordre, mais ça implique que le hacker réussisse d'abord un test de Perception Matricielle sur le persona du rigger/utilisateur du drone. Comment dès lors ne pas être grillé ? Sans compter que le drone pourra résister avec Autopilote + Firewall...
En même temps, une simple action d'Edition doit pouvoir permettre de faire quelques chose quand même : la FAQ parle de donner des ordres totalement différents, mais en éditant un ordre il doit être possible de modifier juste un paramètres (par exemple changer "tourne à gauche" en 'tourne à droite", "tire sur le troll" en "ne tire pas sur le troll", etc...). Non ?
Eh non, enfin je ne crois pas.
Hors ligne
Merci de tes réponses, Nam.
Avant de décrypter un signal, il faut le capter.
C'est ce qui me praraît le plus logique, mais il y a une petite phrase dans le livre de base qui me chiffonne :
LdB SR4 VF, p. 227, § Interception de signal sans fil a écrit:
Remarque : les communications sans fil sont habituellement cryptées, vous aures donc besoin de décrypter le signal avant de pouvoir intercepter ou capter le trafic.
S'agit-il d'une coquille ? Perso, je le ferais jouer dans l'ordre suivant :
1. interception du signal
2. décryptage du signal
Oui, mais c'est une Falsification, ça, donc un autre test.
[...] Toujours Falsification.
Ok, alors on oublie Edition (dommage). Du coup, je ne vois pas trop comment Imiter un ordre sans le codecomm de l'utilisateur. Autant essayé directement un hacking en règle...
De base, le brouillage des signaux.
En voilà, une bonne idée ![]()
Du coup, il suffit d'intercepter le trafic (et de le décrypter), puis de mettre le brouilleur en marche, et hop ! Simple et efficace, c'est tout que ce que je cherchais
Merci.
Hors ligne
Pour le cryptage, en fait, si tu décryptes pas le signal, je dirais que tu peux copier tout ce qui passe, mais l'intérêt d'avoir la liste des communications entre deux appareils a un intérêt restreint. Il faut donc décrypter la communication pour pour pouvoir intercepter efficacement la communication.
Pour l'imitation d'ordre, l'action se suffit en elle-même, pas besoin du codecomm de l'utilisateur.
Pour le brouillage, attention, c'est pas forcément gagné. Il faut un brouilleur dont l'indice est supérieur ou égal au Signal de l'appareil visé, sans parler de sa CCME.
Hors ligne
Merci Erlin, il se trouve que je suis un futur maitre de jeu d'une partie où un des joueurs est un rigger qui lui aussi se cache dans sa grosse bagnole (un 18-roues pour être exact).
Grâce à cette conversation, je vais pouvoir m'arranger pour lui nuire un petit peu de temps en temps.
Merci encore.
Hors ligne