Pirater un fichier, la fin du hack discret 26

Re-coucou.

Alors toujours avec mes questions sur la Matrice, j'ai vu que le piratage de fichier était une action d'Attaque. Cela signifie que si l'action est un échec, personne n'est contacté mais si c'est une réussite, le propriétaire est automatiquement prévenu quelque chose vient d'arriver à son fichier. Du coup, tant qu'on s'attaque aux appareils du WAN, ça ne pose pas de problème, mais dès qu'il s'agit de fichier, c'est la fin de la discrétion du hacker.

Est-ce normal ?

tu as la source, stp ? Car je ne vois pas ce qui alerte le propriétaire. La seule chose que je vois, c'est le fait de poser une mark et si une CI patrouilleuse analyse la mark, elle peut détecter que tu n'as pas les droits et donne l'alerte

p.237 du Livre de Base, la partie sur Détecter les hackers :

"En cas d’action d’Attaque réussie, la cible prend conscience qu’une autre icône est en train de l’attaquer, mais ne la repère pas pour autant. Il y a de fortes chances pour qu’elle se mette à la rechercher activement lors de sa prochaine action, en plus d’alerter presque à coup sûr son propriétaire et (s’il s’agit d’un serveur) lancer une CI, selon ce que préfère le propriétaire en question et à la discrétion du meneur de jeu."

je n'ai pas le ldb sous les yeux. Si cette citation est pour l'ensemble des actions attaque, là, c'est vrai que c'est pas terrible, si c'est pour l'action spécifique pic de données, je trouve que c'est plus en adéquation. Invoquons Ghislain ou carmody ☺Pour moi, une action attaque hors pic de données réussi le propriétaire n'en sait rien. Tu rates, manges tes dégâts en retour !

Ba tu as aussi passer en force aussi qui effectivement parait évident.

Quand au drain d'invocation ... je mange à chaque fois ! J'ai pas de chance pour ces tests là...

<reality-check>

Le fait de savoir qu'un fichier a été touché (même pour une lecture) est assez normal. On le fait déjà de nos jours (sous Linux, par exemple, chaque fichier est associé à 3 dates : création, dernière modification, dernier accès (lecture ou écriture) ; l'API inotify sous Linux permet de placer un "oeil" sur le fichier et détecter lorsque l'une de ses dates est modifiée, et donc de déclencher une alerte en temps réel ; et puisque c'est géré par l'OS, ça ne peut pas être évité).

</reality-check>

Tu as deux types de hacking, soit l'attaque action "passer en force", et la si tu réussis, on sait que tu es la, si tu rates tu prends des dommages mais personnes ne le sait, soit la corruption action "hacker à la volée", si tu réussis personne ne le sais, si tu rates la cible sait que tu es la, et met une mark sur toi.

Deux façon de faire différentes, une façon directe et bourrin, et une discrète et plus subtile, pour caricaturer!!

Oui je sais ça, j'illustrais juste le fait qu'il n'y ait pas que Pic de données pour laquelle c'était évident qu'une attaque était en cours.

Je viens de verifier dans le ldb. Dans le tableau de recap des actions, il y a pirater un fichier dans la partie attaque.

Edit: Effectivement, le fait d'enlever la protection ca signale au proprio. J'etais sur le fait de le lire, copier,etc. En relisant la description, ca me gene plus au final. Sachant que proteger un fichier empeche de le lire ou ecrire, tu ne vas pas proteger systematiquement tous les fichiers

Quant aux autres actions, que le proprio soit informé, ne me gene pas plus au final.

Ensuite, pour passer en force vs hack à la volée, on utilise des compétences différentes et apres reflexion, le fait que le proprio soit informé me gene moins dans le sens où c'est une approche pour faire mal

C'est peu probable qu'un fichier qui sert souvent déclenche un alerte quand quelqu'un y accède. Même si c'est techniquement possible, ça déclencherait des centaines de faux-positifs (alertes à chaque accès légitime).

Ce genre de cas se verrait donc uniquement sur des fichiers ultra-sensibles, avec par exemple des alertes quand les fichier sont accédés en dehors des heures de travail des employés de la mégacorpo.

Attention, on parle là de fichiers qui sont protégés : seule l'action "Pirater un fichier", pour en retirer la protection, est une action d'attaque ! Copier un fichier, le modifier ou l'effacer, sont des actions de Traitement de Données qui ne peuvent pas se faire sur un fichier protégé : le fichier protégé n'est donc normalement pas modifiable, sauf à le "hacker", ce qui ne peut se faire qu'avec un cyberdeck !!!

Aussi, je ne pense pas que le fichier "modèle de courrier à entête de la corpo xx" soit protégé, car ça veut dire que n'importe quelle secrétaire utilise un cyberdeck...

A priori, seuls les fichiers importants et mis en archive doivent être protégé : pour ces fichiers, il est normal qu'à chaque manipulation, le serveur envoie une CI pour vérifier qui touche à celui-ci !

en fait, la discussion est sur une action précise "pirater un fichier" qui consiste seulement à enlever la protection de manière illégale.

en fait, rien ne nous dit comment on enlève une protection de manière légale... alors, soit c'est possible, et à ce moment là, on devrait nous dire comment (car on devrait pouvoir simuler ça en piratant/corrompant le système), soit ce n'est pas possible, et on en arrive à mon post précédent !

Mouais, que les règles ne soient pas toujours explicites. Cela dit il n'est pas envisageable en vrai que la seule façon d'accéder à un fichier protégé soit de le pirater !

Il est effectivement possible d'accéder légalement à un fichier protégé. Pour ce qui est des règles associées, je dirais que si on a les accès (i.e. son persona à le droit) ou le mot de passe (selon comment c'est géré) alors on y accède comme un fichier non protégé.

Ben, justement, ce point est très clairement explicité pour des fichiers "équipés" d'une bombe matricielle (je n'ose pas écrire "protégé par une bombe matricielle", car on risquerait alors de tout confondre !), alors qu'il n'en est rien pour les fichier protégé !

Après, du peu que je comprends du lien (en anglais) posté sur le fil de discussion "comment jouer un Technomancien", il faut poser 3 Marks avec "Hack à la volée" sur un terminal esclave du serveur, ce qui nous donne 3 marks sur le serveur, pour ensuite "contrôler le serveur" pour qu'il nous fasse une copie légale du fichier protégé, non ?

on peut y accéder légalement avec l'action "éditer un fichier". C'est cette action qui permet au propriétaire du fichier de le protéger.

Alors "Contrôler le serveur" ce n'est pas possible. Tu ne peux faire une action "Contrôler un appareil" que sur un ... appareil.

Après oui un fichier protéger sur laquelle on a les droits s'ouvre s'en problème. D'ailleurs, l'idée aurait pu être de :
1/ repérer les marks posées dessus.
2/ réaliser un action "trackback" (Data Trails p.179) pour retrouver l'appareil à qui appartient la mark.
3/ poser une mark sur l'appareil à l'origine de la mark.
4/ et réaliser une action d'imiter un ordre pour lâcher la protection sur le fichier.

Sauf que ... imiter un ordre ne fonctionne que sur des appareils et des agents ... pas des CI, sprites, serveurs, personas ou tout autre icône... aaaaahhhhhh.

Du coup, je ne vois pas trop comment contourner cette sécurité...

Oui attention le lien que j'ai mis dans l'autre post n'est pas de moi et les infos dedans sont sujettes à caution. En effet Slevin a raison sur ce point.

je me disais bien que c'était trop facile....

....

... Pour ce qui est des règles associées, je dirais que si on a les accès (i.e. son persona à le droit) ou le mot de passe (selon comment c'est géré) alors on y accède comme un fichier non protégé.

Carmody

Ça ne serait pas plutôt "et" ?

Je suis encore débutant en SR, mais mon bon sens d'informaticien me faire dire que même en 2070, pour avoir un accès autorisé, il faut à la fois l'identifiant (persona) ET le mot de passe, non ?