J'ai une imprimante Brother MFCL3770. la première fois que j'ai eu à changer une cartouche, j'ai acheté une cartouche de marque Brother chez office dépôt. Mais celle-ci n'a pas été reconnu par l'imprimant (qui était à jour de firmware). j'ai dû démonter la puce de l'ancienne cartouche et le monter sur la nouvelle pour que celle-ci soit reconnu.
Cela me rappelle le comportement de Ms Word (il y a quelque temps) qui ajoutait les informations de modification à la fin du fichier Word si on enregistre le fichier simplement. (le fichier devenait énorme)
pour éviter cela, il fallait faire un “Enregistrer sous…” pour purger les anciennes données….
Salto est arrivé trop tard sur un marché déjà dominé pour la concurrence. (mais avant, il n’y avait pas de preuve de rentabilité pour les “investisseurs”)
Si l’on ajoute à cela la chronologie de média, la copie privée, un catalogue pauvre et un public formaté par les séries US depuis des années…
Note : Je me demande, combien d’opportunités n’ont pas vu le jour en raison d’investissement frileux et de recherche de rentabilité immédiate.
Hum si le budget ne part pas en rapports et études Bullshit. Car une telle manne va surement attirer pas mal de cabinets de conseil en tout genre. (surement, nouvellement spécialiste de la question)
J’ai un doute que ça fonctionne si le fichier est synchro entre plusieurs appareils.
Je pense que la fonction est encore plus justifiée si la base est partagée par plusieurs appareils ==> multiples appareils => plus de surface d’attaque pour cette faille.
Dans ce cas, il faut valider les fichiers de conf de chaque appareil (ou simplement de la section trigger) (une entrée par appareil?)
Une autre solution est de permettre d’invalider le lancement des triggers dans la conf de la base.
Note ; l’accès à la machine de l’utilisateur pourrait permettre d’ajouter aussi des plugin-ins non ?
Si le hash n’est pas identique alors désactivation des fonctions à risques (trigger) + invite de l’utilisateur à vérifier la configuration.
Note : dans une entreprise, il y a un certain nombre de personnes ayant accès au compte local des utilisateurs (le support de proximité, le admins système…). il leur est donc possible de modifier le fichier pour l’export des mdp de l’utilisateur. (qu’il n’a pas le besoin d’en connaître) ….Oups point déjà évoqué
Une solution possible serait le stockage d’un hash du fichier de config dans la base. Celui-ci sera utilisé pour valider le fichier de config avant application.
À voir si cela peut être appliqué avec plusieurs bases…
11 commentaires
Le 07/03/2025 à 05h50
J'ai une imprimante Brother MFCL3770.
la première fois que j'ai eu à changer une cartouche, j'ai acheté une cartouche de marque Brother chez office dépôt.
Mais celle-ci n'a pas été reconnu par l'imprimant (qui était à jour de firmware).
j'ai dû démonter la puce de l'ancienne cartouche et le monter sur la nouvelle pour que celle-ci soit reconnu.
...
Le 20/09/2023 à 05h51
Vidéo sur la publication scientifique :
DATA GUEULE : Privés de savoir ?
Le 12/04/2023 à 05h24
Le 25/03/2023 à 05h00
Cela me rappelle le comportement de Ms Word (il y a quelque temps) qui ajoutait les informations de modification à la fin du fichier Word si on enregistre le fichier simplement. (le fichier devenait énorme)
pour éviter cela, il fallait faire un “Enregistrer sous…” pour purger les anciennes données….
Comme quoi l’histoire se répète….
Le 22/02/2023 à 06h44
Salto est arrivé trop tard sur un marché déjà dominé pour la concurrence. (mais avant, il n’y avait pas de preuve de rentabilité pour les “investisseurs”)
Si l’on ajoute à cela la chronologie de média, la copie privée, un catalogue pauvre
et un public formaté par les séries US depuis des années…
Note : Je me demande, combien d’opportunités n’ont pas vu le jour en raison d’investissement frileux et de recherche de rentabilité immédiate.
Le 20/02/2023 à 18h45
Hum si le budget ne part pas en rapports et études Bullshit. Car une telle manne va surement attirer pas mal de cabinets de conseil en tout genre. (surement, nouvellement spécialiste de la question)
Le 02/02/2023 à 21h35
Voici Une vidéo de la chaine DATA GUEULE sur le sujet
6 ans déjà…
Le 31/01/2023 à 06h53
Je pense que la fonction est encore plus justifiée si la base est partagée par plusieurs appareils ==> multiples appareils => plus de surface d’attaque pour cette faille.
Dans ce cas, il faut valider les fichiers de conf de chaque appareil (ou simplement de la section trigger) (une entrée par appareil?)
Une autre solution est de permettre d’invalider le lancement des triggers dans la conf de la base.
Note ; l’accès à la machine de l’utilisateur pourrait permettre d’ajouter aussi des plugin-ins non ?
Le 31/01/2023 à 06h29
Si le hash n’est pas identique alors désactivation des fonctions à risques (trigger) + invite de l’utilisateur à vérifier la configuration.
Note : dans une entreprise, il y a un certain nombre de personnes ayant accès au compte local des utilisateurs (le support de proximité, le admins système…). il leur est donc possible de modifier le fichier pour l’export des mdp de l’utilisateur. (qu’il n’a pas le besoin d’en connaître)
….Oups point déjà évoqué
Le 31/01/2023 à 05h56
Une solution possible serait le stockage d’un hash du fichier de config dans la base. Celui-ci sera utilisé pour valider le fichier de config avant application.
À voir si cela peut être appliqué avec plusieurs bases…
Le 05/04/2015 à 08h42
Quel est la différence avec cet amendement :
http://www.senat.fr/amendements/commissions/2014-2015/300/Amdt_COM-746.html
Qui semble retiré