Contexte

Le stage est le processus d'acquisition de connaissances et d'expérience. Notre équipe Raccoon Security estime qu'il est impossible d'améliorer la sécurité des informations des appareils et des logiciels qui nous entourent sans transmettre ces connaissances et cette expérience aux générations futures de spécialistes. C'est pourquoi nous organisons des stages individuels pour des étudiants et diplômés talentueux depuis de nombreuses années.

La recherche sur la sécurité est une compétence qui n'est pas enseignée à l'université. Vous pouvez l'apprendre à partir d'exemples concrets et sous la direction de mentors expérimentés. Chaque année, nos stagiaires résolvent des problèmes techniques complexes, atteignent leurs objectifs et progressent, élargissant leurs horizons professionnels et rendant le monde un peu plus sûr. Chacun d'eux a sa propre histoire de devenir un spécialiste, et sous la coupe - le début de l'un d'eux.

Présentation

En octobre de l'année dernière, je suis venu pour un stage technique au sein de la société NTC Vulkan. Mon intérêt était dirigé vers le domaine de la rétro-ingénierie. Je savais ce que c'était, j'avais déjà essayé de rechercher indépendamment crackme sous x86, mais j'ai compris que la chose la plus intéressante se situe précisément à la jonction du logiciel et du matériel. Je n'avais pas d'expérience dans ce domaine, mais j'avais envie de m'essayer.

Je n'avais aucune attente particulière de cet événement - des amis et des connaissances parlent souvent de stages techniques dans diverses entreprises bien connues. Et quand on m'a proposé de m'essayer à la recherche d'un adaptateur USB-SATA, j'étais simplement heureux de la nouvelle opportunité d'apprendre quelque chose. L'expérience acquise et le résultat que j'ai obtenu ont permis de vérifier l'exactitude du choix du lieu de stage et du futur métier.

Et l'étude a commencé avec la disponibilité d'un adaptateur USB-SATA standard. Voici ce que j'ai fait ensuite.

Analyse visuelle des circuits

Vous devez d'abord inspecter la carte adaptateur et déterminer les éléments de base de l'appareil. Dans les figures ci-dessous, les principaux blocs de composants importants pour le fonctionnement de l'appareil sont marqués. Photos prises après la recherche:

Adaptateur USB vers SATA. Vue de dessus

Adaptateur USB vers SATA. Vue de dessous

Après avoir passé un peu de temps sur Google, j'ai découvert qu'il y avait deux convertisseurs de tension sur la carte: l'un à 3,3 V, l'autre à 1,2 V.Il est également très facile de déterminer la mémoire flash installée sur la carte. La ROM fonctionne sur l'interface SPI et la capacité de mémoire est de 512 Kbps.

Il semblerait que l'étape de reconnaissance des circuits soit presque terminée, mais une recherche rapide sur Internet n'a donné aucun résultat pour la requête «ASM1051». Aucun document n'a été trouvé pour la puce installée sur la carte. Certes, toujours réussi à trouver un logiciel qui vous permet de le mettre à jour. En outre, il existe une petite fiche technique pour l'ancien modèle ASM1053 .

USB

Lorsqu'il est connecté à un ordinateur, l'adaptateur apparaît comme un périphérique de stockage USB. J'ai décidé qu'une connaissance plus approfondie de l' USB serait probablement utile pour mes recherches, donc les deux prochaines heures que j'ai passées à étudier l'interface.
En général, les périphériques USB peuvent être de différentes classes, selon leur fonctionnalité. Par exemple, les lecteurs flash sont le périphérique de stockage de masse, et les claviers et les souris sont le périphérique d'interface humaine (HID) . Et puisque mon adaptateur est visible dans le gestionnaire de périphériques en tant que périphérique de stockage, cela signifie qu'il est défini en tant que stockage de masse et devrait fonctionner avec les commandes SCSI.

Lire la mémoire de la ROM

Comme on ne sait rien de l'ASM1051 installé sur la carte, la mémoire de la ROM a été considérée comme l'action la plus évidente. J'ai déménagé au laboratoire. Il a séparé la puce de mémoire flash avec un sèche-cheveux à souder et l'a connectée au programmateur ChipProg-48 USB. Il n'y a eu aucun problème de lecture et j'avais un fichier binaire sur les mains. À ce moment-là, je ne pouvais pas dire ce qui était sur le lecteur flash et j'ai commencé à analyser les données.

Analyse de fichiers binaires

Tout d'abord, j'ai ouvert un vidage de mémoire à partir de la ROM à l'aide de WinHex, mais vous pouvez utiliser n'importe quel éditeur HEX. A commencé à regarder les octets:

Début d'un vidage de mémoire lu à partir de la ROM

La capture d'écran ci-dessus est une capture d'écran de l'éditeur. La ligne ASMT1051 , qui commence par l'adresse 0x44, est immédiatement évidente. Vous pouvez également voir la ligne asmedia partir de l'adresse 0x18. Pour l'analyse initiale des données, j'ai utilisé l'outil d'analyse de fréquence, qui est disponible dans WinHex.

Histogramme d'analyse de fréquence de la mémoire ROM

L'histogramme montre les octets les plus présents dans le fichier. En plus du tas 0x00 et 0xFF (les colonnes extrêmes de l'histogramme), les octets suivants se trouvent souvent en mémoire:

• 0x02;
• 0x74;
• 0x90;
• 0xA3;
• 0xE0;
• 0xF0.

Il serait possible de confirmer mon hypothèse qu'il existe un firmware dans la ROM. Un moyen facile de le faire est d'essayer de comparer les opcodes de différentes architectures adaptées aux microcontrôleurs (ci-après - MC) avec des octets qui se trouvent souvent en mémoire.

Si grossièrement estimé, alors très souvent dans n'importe quel code de l'assembleur devrait répondre des commandes telles que:

• mov;
• jmp;
• appeler;
• ret.

Bien sûr, dans différentes architectures, ces commandes peuvent avoir différentes variations, mais il y a un bon sens.

J'ai dû passer par plusieurs ensembles d'instructions pour différents noyaux avant de trouver les bons. La comparaison avec l'architecture d' Intel 8051 a donné un résultat très plausible. Les opcodes de certaines commandes coïncident avec les octets populaires d'un fichier, par exemple:

• 0x02 - LJMP addr16;
• 0x74 - MOV A, #immed;
• 0x90 - MOV DPTR, #immed;
• 0xA3 - INC DPTR;
• 0xE0 - MOVX A, @DPTR;
• 0xF0 - MOVX @DPTR, A.

Il semble vraiment qu'il existe un firmware pour MK dans la ROM. On pouvait immédiatement charger le binaire dans le démonteur IDA Pro , mais au déjeuner, l'un des collègues a demandé:

"Êtes-vous sûr que le code en mémoire commence exactement à partir de l'adresse zéro?"

Et vraiment, vous devez tenir compte du fait que certaines «ordures» ou données de l'adresse 0x00 peuvent être en mémoire.

En général, j'ai été confronté à la tâche de déterminer l'adresse de départ du code. Pour atteindre cet objectif, il était préférable d'utiliser l'émulateur EM100 SPI. L'émulateur remplace la puce de mémoire sur la carte, avec elle il n'est pas nécessaire de souder la ROM à chaque fois avec le firmware, en plus, l'EM100 peut enregistrer un journal d'accès à la mémoire. Étant donné que le firmware de la ROM a déjà été lu, vous pouvez maintenant le télécharger sur l'émulateur SPI. Ensuite, vous devez souder l'émulateur sur la carte adaptateur et enregistrer un journal lors de la connexion de l'adaptateur via USB à un PC.

L'émulateur SPI est soudé à la carte adaptateur USB-SATA

J'ai soudé le câblage de l'émulateur aux pads de la mémoire flash et flashé l'émulateur avec quelques firmware. Il reste maintenant à voir si MK adresse la mémoire, et si oui, à quelles adresses.

ROM d'accès à la mémoire ROM (obtenue à l'aide du logiciel d'émulation SPI)

La figure ci-dessus montre que lorsque l'alimentation est connectée à l'adaptateur, le contrôleur ASM1051 installé sur la carte envoie plusieurs commandes 0x03 (lecture des données).

Tout d'abord, l'ASM1051 lit 0x80 octets, en commençant à 0x0000. Voici deux octets, en commençant à l'adresse 0x0080, puis deux autres octets à partir de l'adresse 0x8082. Il lit ensuite la majeure partie de la mémoire de la ROM, à partir de l'adresse 0x0082.

Nous pouvons supposer qu'un grand nombre d'octets lus dans la ROM en dernier, en commençant par l'adresse 0x0082, est probablement le code. Quoi et pourquoi est demandé avant cela n'est pas encore clair. On sait seulement qu'en réponse à la première demande, l'ASM1051 recevra des lignes de la mémoire flash qui sont marquées dans la figure ci-dessus. Ils étaient juste situés dans les premiers octets 0x80.

Il est temps de vérifier que la mémoire externe de la carte contient le firmware pour MK avec le noyau 8051, et le code lui-même se trouve à partir de l'adresse 0x0082. Ouvrez le vidage de mémoire dans IDA Pro, spécifiez le type de processeur Intel 8051 et le décalage pour le code 0x0082.

Fichier binaire ouvert dans IDA Pro avec décalage 0x82

Il n'y a eu aucun problème d'ouverture du binaire dans le désassembleur.

Conclusions:

1. MK ASM1051 a une architecture 8051.
2. Dans la ROM, il existe un code qui commence par l'adresse 0x82. Il y a autre chose que le code.
3. Les premiers 0x80 octets attirent l'attention.

Analyse de code

Maintenant que je me suis assuré que le code dans l'IDA est correctement chargé, vous pouvez commencer à l'analyser et à le commenter en parallèle.

Au cours de l'étude du code, des fonctions simples ont été trouvées, telles que la soustraction de nombres 32 bits, divers gestionnaires, similaires à switch () dans S.Melkali, et des fonctions très simples, telles que le stockage de la valeur du registre R7 en mémoire à une certaine adresse. Les découvertes les plus importantes que je décrirai ci-dessous.

Trouver n ° 1

Fait intéressant, en réponse à ma demande de RENSEIGNEMENT ( commande SCSI ), j'ai reçu une réponse contenant deux lignes que nous avons vues au début de la mémoire ROM. Bien sûr, j'ai immédiatement changé ces lignes dans la mémoire de l'émulateur, en attendant une demande d'ENQUÊTE pour voir ce que j'ai écrit. Un tel rêve naïf s'est rapidement effondré. Maintenant, en réponse à la commande, j'ai vu une autre ligne, l'ASM1051 n'a pas demandé la majeure partie de la mémoire de la ROM. MK ne lit que les premiers 0x80 octets et tout. Dans l'architecture du 8051, le firmware du masque (matériel) peut être utilisé, apparemment, l'ASM1051 a commencé à démarrer à partir de celui-ci.

Il est donc devenu clair que les premiers octets 0x80 sont vraiment importants, et les modifier ne fonctionnera tout simplement pas. J'ai décidé d'étudier plus en détail les requêtes que MK fait sur SPI avant de télécharger le code.

Demande de données SPI dans la ROM

Deux requêtes de deux octets semblaient intéressantes. La recherche dans IDA 0x00, 0x80 et 0xEB a donné un grand nombre de résultats que je n'ai pas analysés, mais l'octet 0x5A est apparu moins souvent.

Comparaison avec l'octet 0x5A. Comptage de la somme de contrôle-8

Littéralement, le sixième clic m'a conduit à la section de code illustrée dans la figure ci-dessus. On peut voir que la valeur du registre avec l'adresse 0x80 7E est comparée à 0x5A. Ensuite, la somme de contrôle-8 est lue pour les valeurs situées de l'adresse 0x80 04 à 0x80 7E . Ensuite, la valeur à 0x80 7F est comparée au montant reçu précédemment.

Le début de la mémoire dans la ROM

Ces décalages ressemblaient au début d'un vidage de mémoire à partir de la ROM. La figure ci-dessus montre que l'adresse 0x7E contient l'octet 0x5A. Et si vous comptez la somme de contrôle-8 pour les octets de la position 0x04 à 0x7E, alors nous obtenons 0xA7, et cette valeur se trouve simplement à l'adresse 0x7F.

De manière similaire, nous avons réussi à trouver le calcul de la somme de contrôle des octets de l'adresse 0x0082 à 0x807F (apparemment, c'est le code entier), qui est vérifiée avec l'octet à l'adresse 0x8083. Et à 0x8082 se trouve à nouveau la valeur 0x5A.

Oui, c'est un peu plus compliqué que de simplement changer les lignes en mémoire. Je les ai également modifiés, mais j'ai également calculé et noté les sommes de contrôle pour le nouveau fichier aux bons endroits. Après cela, en réponse à la commande SCSI INQUIRY, j'ai vu mes lignes.

Conclusions:

1. Lors du démarrage, l'ASM1051 tente de télécharger le code à partir de la ROM.
2. Tout d'abord, l'ASM1051 compare l'octet de somme de contrôle 8 de l'adresse 0x04 à 0x7E avec la valeur à 0x7F.
3. Si la comparaison de la somme de contrôle du préambule est réussie, alors nous pouvons le considérer pour le "code" (adresses de 0x0082 à 0x807F). L'ASM1051 compare ce montant à la valeur à l'adresse 0x8083 et vérifie que l'octet 0x5A se trouve à l'adresse 0x8082.
4. Si toutes les vérifications sont correctes, l'ASM1051 est chargé à partir de la ROM, sinon il utilise le firmware du masque.

Trouver le numéro 2

En examinant et en commentant les fonctions, j'ai trouvé que très souvent la fonction PRINTF est utilisée dans le code (je l'ai appelé ainsi). La chose intéressante à ce sujet est qu'avant son appel, un caractère imprimé est écrit dans le registre R7.

Fonction PRINTF dans IDA Pro

La fonction elle-même a été présentée dans la figure ci-dessus. Traitons-la. Tout d'abord, vous devez déplacer la valeur du registre avec l'adresse 0x7F6 vers la batterie. S'il y a zéro, quittez la fonction. La chose la plus intéressante se produit s'il n'y a pas zéro. Ensuite, la valeur du registre R7 est déplacée vers le registre avec l'adresse 0xC001, et, comme nous le rappelons, avant d'appeler cette fonction, un caractère imprimé est écrit dans R7. Ensuite, vérifiez si la valeur de R7 est égale au code de caractère "." Ou "-", sinon, quittez la fonction. Mais si la comparaison s'est avérée réussie, la fonction prend la valeur du registre avec l'adresse 0x16A et la déplace vers 0xC001, mais la rend délicate. Par exemple, au lieu de l'octet 0x41 (caractère "A" en ASCII), la fonction passera à 0xC001 octet 0x34 (caractère "4" en ASCII), puis 0x31 (caractère "1" en ASCII). Quittez à nouveau la fonction.

J'ai découvert que la vérification au début de la fonction ne peut pas être passée, car le registre avec l'adresse 0x7F6 est initialisé à zéro, alors il ne change pas dans le code. Autrement dit, cette fonction est désactivée par le programmeur, bien qu'elle reste compilée. Le fait que les octets ne soient écrits que dans le registre 0xC001 (et parfois deux de suite), suggère qu'il s'agit très probablement d'un registre matériel.

Tout cela ressemble à UART. Pour savoir si tel est le cas, vous devez procéder comme suit:

1. Identifiez les jambes sur l'ASM1051 où l'UART est sorti.
2. Définissez les paramètres UART (vitesse, parité, nombre de bits d'arrêt).
3. Ce serait bien d'activer UART dans le code (apparemment, il est désactivé).

Tout semble assez simple: vous pouvez à tour de rôle toucher les jambes avec un analyseur logique et rechercher celui sur lequel le moment de l'envoi de l'UART sera visible. En présence d'un signal, la vitesse peut être déterminée par le temps des impulsions. Avec le reste des paramètres, tout est également clair, il suffit de voir le moment de l'envoi d'un octet sur l'analyseur.

Pour "activer" cette fonction, vous pouvez écrire des zéros au lieu des trois premières lignes, où la valeur est vérifiée dans le registre avec l'adresse 0x7F6. Pour ce faire, j'ouvre à nouveau le firmware dans WinHex.

Six octets à réinitialiser sont alloués.

Dans l'éditeur, je change les six octets souhaités en zéros. Le firmware est maintenant prêt et peut être téléchargé sur l'émulateur ROM. Si nous supposons que la fonction de sortie d'octets dans UART est activée et que son appel se trouve très souvent dans le code, nous pouvons nous attendre à ce que les octets "volent" de l'UART lorsque l'adaptateur est en cours d'exécution. J'espère voir un traceur qui signale en octets dans l'UART combien de code est exécuté.

Comme je l'ai écrit ci-dessus, afin de trouver les jambes Rx et Tx nécessaires, vous pouvez regarder l'analyseur logique un par un. Cependant, j'ai supposé que le Rx et le Tx sur l'ASM1051 sont au même endroit que l'ASM1053 - les jambes 40 et 41, respectivement. Je mets la sonde de l'analyseur sur la broche 41 (supposé Tx) et je vois quelque chose de similaire au signal souhaité:

Diagramme de synchronisation avec la jambe 41 - Tx

Afin de connecter le convertisseur USB-UART et d'observer les caractères imprimés entrants dans le terminal, j'ai dû souder deux câbles fins directement sur la carte adaptateur et le fixer avec de la colle chaude.

Deux câbles soudés à RX et TX

J'ai étudié un peu le diagramme de la figure «Diagramme temporel de l'étape 41 - Tx»: le temps d'une impulsion, apparemment, est de 1 μs, et pour six bits, il est de 6,3 μs. Après avoir recalculé la valeur en bauds, j'ai reçu environ 950 000 bauds, la vitesse UART standard la plus proche étant de 921600 bauds. Je pense que cet écart est obtenu en raison de l'erreur de mesure de l'analyseur logique, je n'ai pas pris l'appareil le plus digne, mais le «bébé» chinois. Après avoir réglé les paramètres dans la fenêtre du programme Terminal 1.9b, j'ai pu observer les octets entrants de l'ASM1051 MK pendant son fonctionnement.

Fenêtre de programme du terminal 1.9b pendant le fonctionnement de l'adaptateur

Conclusion:

L'ASM1051 MK possède un module matériel UART. Le registre d'envoi de données a l'adresse 0xC001. Le débit de données est de 921600 bauds. Il y a un bit d'arrêt. La jambe 41 est Tx et la jambe 40 est Rx (bien que ce ne soit pas exact).

Trouver le numéro 3

En faisant défiler le code dans le désassembleur, en ajoutant des commentaires, vous pouvez trouver des constructions plus difficiles que d'écrire un nombre dans un registre. Je suis donc tombé sur un gestionnaire intéressant, dont une partie en C, ressemblait à switch () .

Le gestionnaire de commandes du registre avec l'adresse 0x800F

Comprenant que quelque part quelque part les commandes SCSI doivent être traitées, j'ai commencé à chercher parmi eux des octets avec lesquels le contenu du registre avec l'adresse 0x800F est comparé dans la figure ci-dessus. Il s'est avéré que les quatre premières branches vérifient les commandes Read (10), Write (10), Read (16), Write (16). Il ne fait aucun doute qu'il s'agit d'un gestionnaire de commandes SCSI. Ensuite, j'ai regardé une fonction qui est appelée si la commande qui est entrée n'est pas en lecture / écriture (u_Switch). Il, en fonction de l'octet dans le registre avec l'adresse 0x16A (la valeur est tirée de 0x800F), lit l'adresse à laquelle nous obtiendrons lorsqu'ils quitteront cette fonction. Ceci est similaire à switch () .

Commuter les commandes SCSI

Comme j'ai déjà déterminé l'octet avec lequel je compare la commande SCSI qui est entrée dans l'adaptateur, j'ai rapidement arrangé la correspondance des adresses par commandes. Ainsi, par exemple, dans la figure ci-dessus, on voit que si l'octet 0x1A était dans le registre avec l'adresse 0x16A, alors après avoir quitté la fonction u_Switch, nous irions à l'adresse 0x1B85. Fait intéressant, tous les octets par rapport à u_Switch ne sont pas définis dans la norme SCSI. Autrement dit, l'adaptateur peut traiter les octets 0xE6 ou 0xDF, mais ils ne sont pas fixés par la norme.

Comme vous pouvez le voir, l'adaptateur peut exécuter des commandes personnalisées et il existe des fonctions de gestionnaire pour elles.

Page 13 de la classe Universal Serial Bus Mass Storage

Faites attention au décalage 0x0F par rapport à l'adresse 0x8000. Avant le processeur, c'est à partir du registre avec l'adresse 0x800F que la commande SCSI est lue. Si vous lisez attentivement le tableau de la figure ci-dessus, vous pouvez voir que dans le wrapper de bloc de commande (CBW), le champ CBWCB a également un décalage de 0x0F . Il s'avère que les adresses de la mémoire RAM ASM1051, en commençant par 0x8000, peuvent être un tampon USB, comme indiqué dans le tableau ci-dessous.

La figure ci-dessous montre la section de code où la comparaison avec la chaîne USBC se produit (telle devrait être la signature dCBWSignature) et la signature proposée se trouve à partir de l'adresse 0x8000. Je pense que cela suffit pour vous assurer que le tampon USB est situé dans la mémoire RAM à partir de 0x8000.

Vérifiez le champ dCBWSignature pour une correspondance avec la chaîne USBC

Conclusions:

1. MK ASM1051 peut gérer non seulement les commandes SCSI, qui sont décrites dans la norme.
2. L'adresse de départ du tampon USB est 0x8000. La commande SCSI se trouve dans le registre avec l'adresse 0x800F, ce qui signifie qu'il y aura d'autres données / arguments des commandes.

Trouver le numéro 4

Sachant que MK peut traiter des équipes non standard, je voulais savoir ce qu'elles faisaient. La plupart d'entre eux m'ont rapidement obéi. Je ne citerai pas l'étude du code de ces commandes, car cela peut prendre beaucoup de temps et peut être important pour un article séparé intitulé «L'assembleur est simple», je décrirai les résultats dans le tableau ci-dessous.

J'avoue que je n'ai pas compris toutes les commandes en lisant les fonctions dans l'IDA. Ayant heurté le mur pendant la recherche, je me suis souvenu avoir vu des logiciels et de nombreux micrologiciels pour l'ASM1051 lorsque je cherchais de la documentation dessus. À l'aide du logiciel trouvé, vous pouvez mettre à jour le micrologiciel et redémarrer l'appareil. Par conséquent, j'ai décidé qu'il était temps d'utiliser Device Monitoring Studio et de voir ce qui envoie le PC à l'adaptateur pendant la mise à jour.

Ainsi, il a été possible de comprendre comment se déroule le processus de mise à jour du firmware: d'abord le préambule est envoyé (avec la commande 0xE1), puis le code est écrit avec la commande 0xE3, puis tout ceci est poli par redémarrage (la commande 0xE8). Pour une mise à jour rapide et pratique, j'ai écrit un script Python qui insère les lignes nécessaires dans le préambule, puis lit les sommes de contrôle et met à jour l'appareil. Maintenant, je n'ai plus besoin d'un émulateur, j'ai eu la possibilité de télécharger le firmware sur l'ASM1051 via USB, vous pouvez renvoyer la ROM native sur la carte.

Conclusions

Pour mettre à jour le firmware, trois commandes SCSI doivent être exécutées séquentiellement: 0xE1, 0xE3 et 0xE8.

Trouver le numéro 5

En plus des commandes non documentées, il était intéressant de regarder les gestionnaires de commandes standard.

Déplacement du troisième bit du registre 0xC884 vers le septième bit du registre 0x8002

Il existe un test intéressant dans le gestionnaire de la commande MODE SENSE (10) SCSI. La figure ci-dessus montre une partie du code de fonction. On peut voir que le troisième bit est lu dans le registre 0xC884 . Ensuite, la valeur de ce bit est définie dans le registre à 0x8002.

Ce qui est intéressant ici, c'est que le registre 0xC884 n'est initialisé nulle part dans le code, ce qui signifie qu'il s'agit probablement du matériel.

Tableau 362 du manuel de référence des commandes SCSI

En outre, si vous consultez la documentation de la commande 0x5A SCSI (MODE SENSE), il devient clair que l'adaptateur USB-SATA doit répondre à la demande MODE SENSE. Le troisième octet de la réponse contient le septième bit de WP (Write Protect - protection en écriture). Soit dit en passant, j'ai déjà vu le septième bit dans 0x8002, et le décalage par rapport au début du tampon USB (0x8000) est exactement de 3 ici .

Conclusion:

L'adaptateur USB-SATA testé lit le troisième bit du registre matériel à 0xC884 et l'envoie à l'hôte USB en tant que bit WP.

Trouver le numéro 6

Le registre matériel trouvé lors de l'enquête sur le gestionnaire de commandes MODE SENSE SCSI est très similaire au GPIO. Pour confirmer cela, j'ai décidé de toucher les jambes de l'ASM1051 avec une résistance sous tension et de lire la valeur du registre (commande SCSI 0xE4) avec l'adresse 0xC884 . Pour ce faire, j'ai écrit un script Python à l'aide de commandes SCSI personnalisées qui surveille la valeur dans le registre 0xC884 et l'affiche sur le PC.

Après avoir mené une telle expérience, j'ai compilé un tableau dans lequel j'ai affiché quels bits du registre 0xC884 ont changé lorsque la résistance ASM1051 a touché les jambes. Il s'avère que le registre à l'étude est étroitement lié au GPIO, mais la tentative d'écriture sur celui-ci (avec la commande SCSI 0xE5) a échoué - la valeur n'a pas changé.

J'ai alors décidé que ce registre était soit en lecture seule, soit qu'il était interdit d'y écrire quelque part au niveau matériel. Si, par exemple, les segments MK étaient initialement configurés pour la lecture uniquement, alors, probablement, l'écriture dans le registre 0xC884 pourrait être indisponible.

En général, afin de trouver les registres associés au GPIO, j'ai parcouru le code d'initialisation MK. J'ai noté tous les registres dont les adresses sont proches de 0xC884 . J'en ai eu environ 10. Je vous rappelle que la dixième branche du MK est reliée à la LED de la carte, elle correspond au deuxième bit du registre 0xC884 . – 0880 , (, ). , , 0880 (/), 0884 , - .

0880 , 0884 . 0884 . ASM1051.

:

GPIO ASM1051. 0880 / I/O. 0884 I/O.

№ 5.

GPIO- , 45- 0884 . WP , USB. 45- , HDD, , .

HDD, 45-

. GND 45- , HDD. .

45- ASM1051 HDD.

USB-SATA-. ASM1051. , - , . , GPIO. – ASM1051 , HDD. , , (« »), , , USB-SATA- ASM1051.

, footprint ASM1051, datasheet ASM1053. , ASM1051 .

ASM1051

, 3D- , .

3D-

WP . GPIO ASM1051 , UART. , SATA, HDD. USB 3.0 Micro-B Type-C. HDD USB, HDD 3.5" +12 , 12 21 . .

Conclusion

, .

-, , . « «», . , .

, (, ) embedded-. , , . , , , , .

, datasheets, , . , !

Raccoon Security – «» , , , .
, , . .