Zwap

Backdoor ça veut dire littéralement porte de derrière... Donc il y a probablement un moyen de faire une mise à jour sans ouvrir le démodulateur, mais avec quoi ???

Désolé patdel65, mais je fais pas ça au boulot et je suis passé en coup de vent à midi. Je vais y jeter un oeil.

Ce n'est que des suppositions... J'ai lu que la mise à jour "se ferait" sans ouvrir le démodulateur, donc soit par USB ou liaison série, ce qui indiquerait qu'il y a une "backdoor" quelque part. Si c'est le cas, il faut juste trouver comment l'utiliser.

Pour finir, je pense que la mise à jour passe par un logiciel (firmware) ou un soft PC qui récupère la clé spécifique dans l'ATLAS et regénère une nouvelle clé pour le nouveau firmware... ou un truc comme ça. La partie Secureboot ne devait donc pas être activée sur la version B. Aussi, je pense qu'ils n'ont pas changé grand chose au soft mais juste bloqué le bootloader avec un secureboot et changé un petit peu la manière de récupérer les clés sur le réseau pour que les vieux firmwares ne fonctionnent plus. Appât du gain, quand tu nous tiens...

Bon, désolé pour ma réponse tardive depuis cet été... En regardant la Datasheet du Fujitsu, ce dernier n'embarque a priori pas de mémoire à proprement parler mais un SecureBoot. Du coup, même si ils parlent de mémoire OTP, OTP signifiant "One Time Programmable", il est impossible de la changer une fois programmé, sinon ça ne serait pas OTP... D'après ce que j'ai vu aussi de la datasheet, le composant est capable de booter sur la SPI, donc habituellement, il charge le code de la mémoire SPI vers de la RAM afin de pouvoir l'exécuter plus rapidement. Donc je vois plutôt un système avec un espèce de SecureBoot intégré qui ferait une vérification de la mémoire SPI (un CRC ou une clé liée à un n° HW, comme une adresse MAC), puis chargerai ce qui correspondrait au boot et l'exécuterai. Ce boot-là (D ou F) serait chargé d'exécuter l'appli, en la chargeant au préalable peut-être. J'ai déjà bossé un type de CPU (ARM Cortex M3) qui charge le code d'une mémoire SPI, mais pas de fonction de SecureBoot malheureusement... Ca ne nous avance pas forcément plus mais en terme de direction de recherche, je pense que le CPU et son boot interne sont figés, c'est juste une histoire de mémoire externe. Et comme le JTAG est probablement verrouillé, faut chercher une autre porte... Quelqu'un aurait-il réussi : - à se connecter sur un Atlas via un terminal série ? - à espionner ce que fait le multiloader sur la liaison série ? ----- Au passage, pour détailler la notion de SecureBoot, voici ce que l'on peut lire sur le site de ARM : 5.2.2. Secure boot A secure boot scheme adds cryptographic checks to each stage of the Secure world boot process. This process aims to assert the integrity of all of the Secure world software images that are executed, preventing any unauthorized or maliciously modified software from running. Cryptographic signature protocol The most logical cryptographic protocol to apply is one based on a public-key signature algorithm, such as RSA-PSS (Rivest, Shamir and Adleman - Probabilistic Signature Scheme). In these protocols a trusted vendor uses their Private Key (PrK) to generate a signature of the code that they want to deploy, and pushes this to the device alongside the software binary. The device contains the Public Key (PuK) of the vendor, which can be used to verify that the binary has not been modified and that it was provided by the trusted vendor in question. The PuK does not need to be kept confidential, but it does need to be stored within the device in a manner which means it cannot be replaced by a PuK that belongs to an attacker. Chain of trust The secure boot process implements a chain of trust. Starting with an implicitly trusted component, every other component can be authenticated before being executed. The ownership of the chain can change at each stage - a PuK belonging to the device OEM might be used to authenticate the first bootloader, but the Secure world OS binary might include a secondary PuK that is used to authenticate the applications that it loads. Unless a design can discount hardware shack attacks the foundations of the secure boot process, known as the root of trust, must be located in the on-SoC ROM. The SoC ROM is the only component in the system that cannot be trivially modified or replaced by simple reprogramming attacks. Storage of the PuK for the root of trust can be problematic; embedding it in the on-SoC ROM implies that all devices use the same PuK. This makes them vulnerable to class-break attacks if the PrK is stolen or successfully reverse-engineered. On-SoC One-Time-Programmable (OTP) hardware, such as poly-silicon fuses, can be used to store unique values in each SoC during device manufacture. This enables a number of different PuK values to be stored in a single class of devices, reducing risk of class break attacks. Note OTP memory can consume considerable silicon area, so the number of bits are that available is typically limited. A RSA PuK is over 1024-bits long, which is typically too large to fit in the available OTP storage. However, as the PuK is not confidential it can be stored in off-SoC storage, provided that a cryptographic hash of the PuK is stored on-SoC in the OTP. The hash is much smaller than the PuK itself (256-bits for a SHA256 hash), and can be used to authenticate the value of the PuK at run-time. On-SoC Secure world or Off-SoC Secure world The simplest defense against shack attacks is to keep any Secure world resource execution located in on-SoC memory locations. If the code and data is never exposed outside of the SoC package it becomes significantly more difficult to snoop or modify data values; a physical attack on the SoC package is much harder than connecting a logic probe to a PCB track or a package pin. The secure boot code is generally responsible for loading code into the on-SoC memory, and it is critical to correctly order the authentication to avoid introducing a window of opportunity for an attacker. Assuming the running code and required cryptographic hashes are already in safe on-SoC memory, the binary or PuK being verified should be copied to a secure location before being authenticated using cryptographic methods. A design that authenticates an image, and then copies it into the safe memory location risks attack. The attacker can modify the image in the short window between the check completing and the copy taking place. Si certains ont le calculateur de la NSA a dispo...

Merci pour le lien, je vais y jeter un oeil mais pas le temps de suite. La doc dont je parle, c'est un fichier qui s'appelle "MB86H61_Linux_Startup_Internal.pdf"

Bonsoir à tous, je viens de parcourir vos 16, pardon 18 pages d'échange, il est tard et ça fait mal à la tête. Mais bon, je voudrais essayer d'apporter ma pierre à l'édifice. D'après ce que je comprends, vous utilisez les dumps divers et variés pour comprendre les différences des boots et voir ce qu'il pourrait se passer. Si j'ai bien tout lu, il s'agirait d'un CPU Fujitsu MB86H61 à base de cœur ARM11. Ce CPU est interfacé à une mémoire SPI WINBOND 25Q128 qui contiendrait un boot + une appli. J'ai jeté un oeil sur une doc concernant le dev. kit. Quelqu'un aurait-il récupéré le H61 Linux software package référencé dans la doc : ftp://wscfapirelease:A76yHj43@58.247.12.34/H6X_Linux_Release or http://svn.weststarchips.com/wscsvn/HEAE/004.Platform/Linux/Release Il semblerait que le lien FTP ne fonctionne plus et je n'ai pas de client SVN. Dans ce package on trouve des données sur Uboot et des données sur "Flash Burn tool"... Dans la doc, ils parlent aussi de MTD (Memory technology Device) qui semble être un driver pour gérer la mémoire flash (et on peut sélectionner une mémoire série type Winbond comme indiqué par la figure 7-3-2). D'après ce document, j'en déduirais qu'il y a un "file system" dans la flash.... A voir donc. Quelqu'un aurait-il récupéré le User's manual du CPU. Il serait déjà intéressant de savoir si le CPU possède une mémoire interne qui servirait pour UBOOT, par exemple. Ou encore de savoir quelle est sa méthode de boot. (où lit-il les données de démarrage comme le Program Counter notamment...). Vous avez évoqué à un moment la possibilité d'utiliser le JTAG. ? Quelqu'un a-t-il trouvé les broches où connecter le JTAG (TDI, TDO, TCK RST) ? Je peux avoir accès à une interface JTAG et un debugger ARM.