isamudyson

Ce que je peine à comprendre c'est si le premier fichier ouvre les chakras autorisant le second fichier alors pourquoi l'effet se maintient si on éteint le démo entre les deux injections et pourquoi l'effet se maintient après effacement de l'eeprom ??? Comment le premier fichier maintient-il son effet ?????

Voilà résumé en quelques lignes le point de vue de beaucoup d'entre nous......Merci à toi...même si tu viens du Pas de Calais ! Nul n'est parfait...

Salut, J'ai perdu un peu le fil de la discussion mais, à tout relire en diagonale, je percois que 'lon est pas loin de la solution. J'ai constaté qu'à la lecture du fichier héxa le fichiers différaient bien au dela du nom figurant à l'adresse 0000. Du reste, je fais partie de ceux qui pensent que l'on est dans un système de protection oldschool sans cryptage ou autre truc high tech genre mission impossible. Il suffit de trouver la bonne combinaison de fichier et d'éventuelles modifi à la marge sur le premier.

Tu importes chez toi des MàJ de Skyrim, Battelfield ou Overwatch de plusieurs centaines de Mo voire de Go alors que les génies d'Alger soutiennent qu'il faut ouvrir, programmer, bidouiller je-ne-sais-quoi pour 16 Mo ??? Il faut juste mettre la main sur la clé en question....Rien de plus.

Selon toi, il y a une signature matérielle ? Une partie du code qui serait contenu dans le CPU de l'Atlas ? J'y repense à voix haute puisque, comme beaucoup ici, je suis passé de B à D sans souci. Dessouder le CPU me semble présomptueux là ou déssouder et remplacer le Winbond est plus envisageable... Ainsi, si on repart de pièces vierges, on pourrait implanter sans conflit tout le dump F...Non ??

Je n'attirais pas l'attention sur le modus operandi en tant que tel mais sur la phase d'effacement entre deux chargements. Ainsi, ou peut se loger (et à quelle fin ?) la première partie après l'effacement ? Comment les premiers 16Mo opèrent une séquence qui conduit le système à accepter le dump ? Le CPU se "vide" entre deux mises sous tension, de meme que ce qui est RAM. L'eeprom conserve l'info mais est effacé donc..??? Une idée de spécialistes ??

Salut Cheun, Tu (pardonne-moi la familiarité) sembles y connaitre quelque chose. La manip précédente (passage du B à D) s'entendait en deux étapes distinctes. La première visait à "passer" un premier fichier (16Mo environ) puis à effacer le chip Winbond puis à re-"passer" un second fichier (toujours de 16Mo). Là ou je veux en venir, c'est sur l'étape intermédiaire d'effacement. Pourquoi, Diable, le premier fichier permettrait quoi que ce soit si le processus entend l'effacer tout de go. Ou vont se loger ces 16 premiers Mo qui sont finalement la clé ? J'ai (peu de connaissances en la matière) tenté de comparer les deux fichiers du Boot D par un éditeur héxa. Ils sont très différents en réalité. Spanelli mentionnait qu'on ne connaissait pas l'origine de ce premier fichier (autant le second est un dump de l'eeprom), ce qui m'amène à penser que cela provient directement du concepteur et que Kyng détient l'équivalent pour le F.

Ce qui pèche, c'est la notion de marché fermé. La bande qui gère l'affaire sous couvert de menaces quant à la sécurité des serveurs a modifié le boot. Nul doute qu'ils connaissent l'alphabet au delà de F et qu'à la moindre tentation ils passeront à G et suivants plombant le marché des clients, renouvelant la vente avec le risque (probablement potentialisé par la succès de l'IPTV) de s'attirer l'ire des jusqu'alors bons clients et de plier le business. Moi, ce week-end, je tente la manip sur l'eeprom...et j'en racheterai un si ca marche pas...

Bonsoir, Le sujet du "dump F" fermé, je zone ici en attendant que cela se débloque un peu. Je reviens sur le premier fichier du dump D. Avec un éditeur hexa, on note pas mal de différence avec le second fichier. Ça y ressemble toutefois ce qui me laisse penser qu'il faudrait investiguer sur la façon dont le fichier en question est arrivé en notre possession...Ce n'est pas un fichier inédit mais, selon moi, une adaptation de dump D comme on pourrait le faire à partir du dump F (c'est là ou je voulais venir ).

Sincérement, je ne pense pas que le niveau de sécurité de l'Atlas soit comparable à la Xbox (même 1, pas one). CPU key ??? Je tente de modifier le premier fichier du dump D pour y trouver quelque chose.

Je suis plutôt amateur de voyages mais quand tu tapes Dump Atlas F101 WINDBOND250128 FVF By Elec_dz, tu visites la Turquie puis un autre pays ou on écrit de droite à gauche mais rien de vraiment sérieux......

Bah, dans l'absolu, les sodomites sont les habitants de Sodome... Cela dit, je suis toujours un peu agacé (et vous l’êtes probablement tout autant que moi) à l'idée de se faire berner. Deux hypothèses concernant ce quidam. L'une, il s'agit d'un réel exploit et dès lors pourquoi se filmer pour conserver les fichiers secrets. L'autre, il s'agit d'un gros mensonge, de la preuve d'une grande perversité, parfaitement inutile et tout ce qu'il y a de plus méprisable. Je regrette les mots employés toutefois...J'édite et demande pardon (très humblement).

Moi, j'ai confiance....Y a bien un malin parmi nous (moi exclus) qui va nous pondre un truc bien ficelé et à la portée de tous... S'il m'entend, inutile qu'il se filme et nous envoie le tout sur Youtube avec des fichiers scellés sur un répertoire....

Je ne doute pas qu'il y ait un mot de passe aussi sournois que son auteur. Ce dont je doute c'est de la nature des fichiers contenus....

Le 17 février dernier, ici même, on lisait en aide à un utilisateur led rouge : Bonjour à tous, le nouveau BootLaoder d'Atlas HD-200s (B1.05) BootLoader B105 pour HD-200 Il s'agit d'un fichier d'amorçage pour mettre à jour vos boîtes pour corriger le problème «échouer» et pour ajouter la possibilité de mettre à jour le logiciel principal au démarrage / démarrage à partir d'USB. Le fichier doit être dans le répertoire racine et le nom doit être "firm_usb.ufu", pendant le processus de démarrage, vous devez continuer à appuyer sur le bouton "◄ VOL" du panneau avant jusqu'à ce que "usb" s'affiche pour qu'il fonctionne. Cette version d'amorçage agira également comme un nettoyeur pour la boîte, dans les cas où il ya des bases de données corruptions, vous n'avez plus besoin de logiciel plus propre, ce démarrage le fera. Puisque la procédure propre supprimera toutes les bases de données, nous avons rendu difficile le démarrage du processus propre sans intention réelle de l'utilisateur. Pour démarrer le processus de nettoyage, il suffit d'appuyer rapidement sur le bouton "CH ▼" puis sur le bouton "VOL►" (pas en même temps, un seul bouton à la fois), vous remarquerez que le panneau avant L'affichage démarre un compteur, vous devrez attendre jusqu'à ce que "End" s'affiche. .kbt à utiliser avec KYNG HD Multiloader et fichier .kuf à utiliser dans le menu du récepteur. Assurez-vous de mettre à jour votre chargeur de démarrage pour pouvoir récupérer des défaillances et aussi pour protéger votre boîte contre les erreurs de l'utilisateur."