Aller au contenu

Extraction des Mainsoftwares HD 200


ryl

Messages recommandés

je vais essaye de te repondre.

 

si tu a un prog essaye de faire passer un mainsoft de f201 par exemple sur un boot b128.

 

tu va reussir a avoir comme tu dis la partie utile du programme sur ton atlas(materialise dans la version de ton atlas par f201 mais toujours en boot b ou d).

 

helas ton atlas ne decodera pas les chaines car il faut le boot correspondant au mainsoft pour que cela fonctionne.

 

a part ca ta reflexion etait plutôt bonne.

 

comme je disais plus haut dans mon post l atlas est beaucoup plus complexe que certain peuvent le penser.

 

bonne soiree a toi.

  • Like 1
Lien vers le commentaire
Partager sur d’autres sites

  • Réponses 617
  • Créé
  • Dernière réponse

Meilleurs contributeurs dans ce sujet

Meilleurs contributeurs dans ce sujet

Images postées

Invité maureilhan22

Ok très bien , 

 

Oui j'ai un prog TL866CS et mini pro 6.50 

 

Je comprends , il doit y avoir donc une partie qui correspond au boot dans le mainsoftware donc il serait peut envisageable de chercher dans cette partie aussi afin de tromper le cpu.

 

Je vais regarder avec des comparateurs de fichiers afin de trouver les parties communes entre chaque mainsoftware et boot , j'ai vue que certains avaient identifiées les blocs .

 

Je te remercie pour ton explication .

 

Bonne soirée .

 

Laurent 

Lien vers le commentaire
Partager sur d’autres sites

Ok très bien , 

 

Oui j'ai un prog TL866CS et mini pro 6.50 

 

Je comprends , il doit y avoir donc une partie qui correspond au boot dans le mainsoftware donc il serait peut envisageable de chercher dans cette partie aussi afin de tromper le cpu.

 

Je vais regarder avec des comparateurs de fichiers afin de trouver les parties communes entre chaque mainsoftware et boot , j'ai vue que certains avaient identifiées les blocs .

 

Je te remercie pour ton explication .

 

Bonne soirée .

 

Laurent 

 

j ai dit ca mais en simplifiant les choses.la partie qui t interresse pour faire correspondre le boot et le mainsoft sont crypte et compresse donc loin d etre a la porte de monsieur tout le monde.

 

je t assure laisse tomber cette voie. beaucoup trop complexe pour nous

Lien vers le commentaire
Partager sur d’autres sites

  • 2 semaines après...

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...

  • Like 5
Lien vers le commentaire
Partager sur d’autres sites

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...

  • Like 3
Lien vers le commentaire
Partager sur d’autres sites

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.

 

Salut

 

que veut tu dire par backdoor

 

je pense ne pas etre le seul qui ne comprend pas les termes techniques ?

 

merci d'avance

Lien vers le commentaire
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.


×
×
  • Créer...