Blinky on Zwindler's Reflection

Reverse du Blinky, le gyrophare connecté des copains de chez Enix - part 3

Fri, 23 Jun 2023 12:00:00 +0200

Cet article fait partie d’une suite d’articles sur le reverse engineering d’un prototype de Gyrophare connecté appelé Blinky :

Rappel des épisodes précédents

Dans les articles précédents, j’avais reçu un gyrophare connecté conçu par les copain⋅es de chez Enix et plutôt que de tester leur produit en SaaS (la vraie proposition de valeur), j’ai décidé de faire un peu de reverse engineering dessus.

A l’issue du tout dernier article, j’ai réussi à piloter les LEDs et faire des patterns rigolos avec.

Bouton ?

Je n’ai toujours pas le code source à ma disposition donc je teste un peu tout ce que je trouve, au fur et à mesure.

Un des composants que j’avais repérés lors de mon exploration était un bouton poussoir. Je ne savais jusqu’à présent pas comment l’utiliser, mais j’avais repéré 2 choses visiblement en rapport :

>>> help(app)
>>> >>> help(app)
object <module 'firmware_blinky_esp32' from 'firmware_blinky_esp32.py'> is of type module
[...]
 handle_button_release -- <function handle_button_release at 0x3ffe7ad0>
[...]
 BUTTON -- Pin(13)
[...]

J’avais déjà essayé de jouer avec, mais j’avais reçu l’erreur suivante :

>>> app.handle_button_release()
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
TypeError: function takes 1 positional arguments but 0 were given

Ne sachant pas trop quel type d’argument était attendu… J’ai testé une string au hasard

>>> app.handle_button_release("toto")
ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:4252
load:0x40078000,len:11920
load:0x40080400,len:3344
entry 0x4008060c

AH !

Au moment où on pousse déclenche la fonction, le blinky fait 3 flashs très brefs (bleu, vert, rouge, je ne sais pas dans quel ordre) et redémarre.

J’en déduis que c’est comme cela que l’acquittement des “alertes”, reçues depuis le SaaS, est réalisé.

A noter, on s’en servira peut-être plus tard, mais SPI_FAST_FLASH_BOOT m’a permis de trouver des informations complémentaires sur la façon dont boot l’ESP32 ici.

Visiblement il y a plusieurs modes de boot et je pourrais peut-être trouver des choses intéressantes là dessus.

Bouton encore

Tout ça c’est intéressant, mais j’aimerais pouvoir réaliser autre chose que juste flasher très vite et reboot l’ESP32…

Le code précédent que j’ai trouvé laisse penser que le bouton c’est le Pin(13). Je cherche des tutos sur le net pour savoir comment jouer avec un bouton et je tombe sur ce tutoriel.

En théorie, j’ai juste à vérifier la valeur du Pin(13) en position IN pour détecter un appui.

Sauf que j’ai beau appuyer sur le bouton, la valeur reste toujours à 0. Je commence à me demander si c’est le bon Pin…

>>> app.Pin(2, app.Pin.IN).value()
0
>>> app.Pin(2, app.Pin.IN).value()
0
>>> app.Pin(2, app.Pin.IN).value()
0

Après quelques tests bourrins (j’ai testé plusieurs valeurs), bingo !

>>> app.Pin(16, app.Pin.IN).value()
0
>>> app.Pin(16, app.Pin.IN).value()
1

La valeur passe à 1 quand je maintiens le bouton appuyé ! Pour le fun j’ai écrit un petit bout de code qui change la couleur du NeoPixel quand on clique :

[CTRL-E]
from time import *
from random import randint
def led_color_random_when_clicked():
 button_state = 0
 while True:
 current_state = app.Pin(16, app.Pin.IN).value()
 if current_state and not button_state:
 r = randint(0, 100)
 g = randint(0, 100)
 b = randint(0, 100)
 for led in range(1, 13):
 app.NEO_PIXEL[led] = (r, g, b)
 app.NEO_PIXEL.write()
 button_state = current_state
 sleep_ms(50)
[CTRL-D]

Note : la valeur du click est pas super stable au moment où on lâche le bouton. D’où l’ajout d’un sleep de 50ms pour stabiliser la valeur du bouton.

Du son ?

Lors de mon démontage, j’avais pensé repérer un buzzer (cf le premier article). Une rapide recherche sur Internet sur la marque FUET me laisse penser que c’est plutôt un speaker et qu’on peut donc jouer plus que des sons mais aussi des WAV.

Assez rapidement, je suis tombé sur la doc de micropython à ce sujet et j’ai pu déterminer qu’il fallait chercher des exemples de codes avec “I2S”.

J’ai donc trouvé un bout de code assez bien documenté et complet pour expliquer comment enregistrer et jouer des sons avec plusieurs types de boards, avec micropython.

Malheureusement, même en changeant certaines combinaisons de paramètres (notamment les pins SCK_PIN, WS_PIN et SD_PIN), j’ai été incapable de faire fonctionner le speaker, même sur un exemple simple avec une bête tonalité.

github.com/miketeachman/micropython-i2s-examples/blob/master/examples/play_tone.py

Si j’avais réussi, j’aurai profité de ce que j’ai appris lors du deuxième article pour copier un WAV et vous faire marrer avec une idée à la c**.

Du stockage ?

Tant qu’on parle de tests non concluants, j’ai aussi remarqué la présence d’un composant appelé W25Q128JVSIQ, de marque winbond. On peut trouver les specs ici. Il s’agit d’une mémoire flash de 128 Mbit et qui coûte entre 1 et 2 euros.

En re-parcourant tous les objets en mémoire, j’ai (re)découvert la présence d’un objet “bdev” qui semble être une partition (probablement le stockage monté dans /flash, qui contient le fichier hw_version ainsi qu’un couple clé privée/clé publique ? cf le premier article).

>>> help(bdev)
object <Partition type=1, subtype=129, address=2097152, size=2097152, label=vfs, encrypted=0> is of type Partition
find -- <staticmethod>
info -- <function>
readblocks -- <function>
writeblocks -- <function>
ioctl -- <function>
set_boot -- <function>
mark_app_valid_cancel_rollback -- <classmethod>
get_next_update -- <function>
BOOT -- 0
RUNNING -- 1
TYPE_APP -- 0
TYPE_DATA -- 1
>>> bdev.info()
(1, 129, 2097152, 2097152, 'vfs', False)
>>> uos.statvfs('/')
(4096, 4096, 512, 509, 509, 0, 0, 0, 0, 255)
>>> uos.statvfs('/flash')
(512, 512, 32768, 32758, 32758, 0, 0, 0, 0, 255)

Quelques docs en vrac :

Conclusion ?

On ne va pas se mentir… Je suis un poil déçu de ne pas avoir réussi à trouver le code source…

Je me demande vraiment comment c’est possible de lancer du code python sans qu’il soit visible sur le filesystem. Je me dis que j’ai forcément loupé un truc et ça me laisse un sentiment d’inachevé.

Mais j’y ai passé beaucoup de temps (tout n’est pas détaillé ici mais j’ai été cherché par mal d’infos, notamment sur la façon dont on boot la board et sur le stockage flash/SD, sans succès).

Un peu déçu aussi de ne pas avoir trouvé les bons paramètres pour piloter le speaker, j’aurais bien fait un petit bout de code avec du son en plus de la lumière. A voir ce que l’équipe ajoutera de ce côté.

J’ai laissé tomber la partie MQTT. Je suis certain que j’aurais réussi à faire marcher la communication avec l’ESP32 et un serveur Mosquitto ou RabbitMQ et j’avais déjà configuré le réseau (dans le 2ème article).

Pour autant, ce n’est pas la fin !

Maintenant que je met sde côté (au moins provisoirement) le reverse du blinky, je peux me concentrer sur la partie SaaS et enfin “enroll” mon device dans le site mis à disposition par Enix, pour commencer à jouer avec “pour de vrai”.

On verra si ça m’amène d’autres idées. En attendant, have fun :-)

Reverse du Blinky, le gyrophare connecté des copains de chez Enix - part 2

Wed, 21 Jun 2023 12:00:00 +0200

Cet article fait partie d’une suite d’articles sur le reverse engineering d’un prototype de Gyrophare connecté appelé Blinky :

Rappel des épisodes précédents

Dans l’article précédent, j’avais reçu un gyrophare connecté conçu par les copain⋅es de chez Enix. Comme je n’avais pas reçu les instructions comme les autres destinataires de ce prototype, j’avais décidé de faire un peu de reverse engineering dessus, même si à vrai dire je n’y connais pas grand-chose.

L’article précédent est disponible ici.

Je m’étais arrêté en changeant la couleur des LEDs, car j’avais réussi à deviner que la fonction app.set_status_pixel() prenait comme argument un tuple RGB.

Mais c’est encore un peu pénible de deviner comme utiliser le blinky sans avoir le code source. J’ai donc tenté de le trouver…

inspect ?

Ma première idée a été de chercher sur les Internets comment aller récupérer le code source d’une fonction en mémoire en python.

En iPython, il existe un moyen d’afficher directement le code d’une fonction en ajoutant en suffixe d’une fonction “??”. Pas de bol, Micropython n’implémente pas ça :(

En CPython, il existe un module “inspect” en CPython qui permet (entre autres) de faire ce que je veux faire. Je suis assez vite tombé sur un module pip micropython-inspect

pypi.org/project/micropython-inspect

This is a module reimplemented specifically for MicroPython standard library, with efficient and lean design in mind.

Reste à trouver comment installer un module pip sur notre ESP32. Evidemment, comme je n’ai pas de shell, impossible de faire pip install directement.

ChatGPT (oui, j’ai demandé de l’aide 🤖) me propose 2 solutions :

utiliser le module “upip” qui permet de télécharger les modules portés pour MicroPython
télécharger un “remote shell” pour MicroPython

Essayons la première solution…

>>> import upip
>>> upip.install("inspect")
Installing to: /lib/
Error: Unable to resolve micropython.org (no Internet?)

Evidemment ça ne peut pas marcher, vu que je n’ai encore pas configuré Internet 🤦. Mais on avait vu que c’était possible dans l’article précédent, puisque l’ESP32 Espressif du Blinky dispose de WIFI.

On trouve assez vite comment faire sur la doc de micropython :

>>> import network
>>> wifi = network.WLAN(network.STA_IF)
>>> wifi.connect("xxxxxx", "xxxxxx")
>>> while not wifi.isconnected():
... pass
...
>>>
>> print("Connected! IP address:", wifi.ifconfig()[0])
Connected! IP address: 192.168.x.y

La preuve donc que cette board a bien un module wifi fonctionnel !! Bon à savoir, ça sera utile :)/

Une fois qu’on a le réseau, on peut télécharger des packages pour notre board… mais là, c’est le drame…

inspect.getsource(app.main)
'<source redacted to save you memory>'

What the actuel frak???

En copiant collant la ligne de sortie, je tombe sur ce fichier source…

github.com/micropython/micropython-lib/blob/master/python-stdlib/inspect/inspect.py

En gros, ce module ne fait de définir les fonctions, mais l’implémentation n’a pas été faite…

rshell

Passons à la 2ème idée de ChatGPT, utiliser un shell depuis notre PC.

Sur mon PC :

$ pip3 install rshell

rshell --port /dev/ttyUSB0

A partir de là, on peut lister les boards avec la commande boards (si on en a plusieurs connectées), faire des cat, des cp entre le PC et la board…

C’est assez utile pour du debug, mais comme je n’avais pas trouvé le code sur le filesystem dans mes tentatives précédentes (à part en mémoire), ça ne m’aide pas plus…

Quelques liens utiles

webrepl

Pendant mes premières explorations, j’avais remarqué qu’il y avait un fichier boot.py qui ne contenait que tu codes commenté. Je l’avais donc ignoré.

En allant relire le contenu du fichier je suis tombé sur ça :

# This file is executed on every boot (including wake-boot from deepsleep)
#import esp
#esp.osdebug(None)
#import webrepl
#webrepl.start()

J’ai donc tenté de lancer les commandes dans mon shell Python sur la board :

>>> import esp
>>> esp.osdebug(None)
>>> import webrepl
>>> webrepl.start()
WebREPL is not configured, run 'import webrepl_setup'

Qu’est ce que c’est que WebREPL ?

>>> import webrepl_setup
WebREPL daemon auto-start status: disabled

Would you like to (E)nable or (D)isable it running on boot?
(Empty line to quit)
> e
To enable WebREPL, you must set password for it
New password (4-9 chars): xxxxxx
Confirm password: xxxxxx
Changes will be activated after reboot
Would you like to reboot now? (y/n) y

Après reboot, je remarque la ligne suivante :

WebREPL daemon started on ws://192.168.x.y:8266
Started webrepl in normal mode

Ahah ! On va pouvoir accéder à un autre shell à distance !

En cherchant rapidement, je tombe sur ce dépôt git. Il explique comment ça marche et indique qu’il faut un client pour parler avec le websocket. Il y a une version web du client que je n’ai pas réussi à faire marcher.

En revanche, en clonant le dépôt et en utilisant le client local, ça fonctionne.

Sur mon PC :

git clone https://github.com/micropython/webrepl

Je lance ensuite le fichier html, je peux me connecter avec l’IP de mon Blinky (connecté en WIFI) et un mot de passe.

J’ai donc un 3ème shell sur le Blinky (c’est cool), mais je ne suis toujours pas plus avancé :-p. Je referme donc ce chapitre (je ne dirais pas que c’est un échec, je dirais que ça n’a pas marché).

Tu es l’élu, Néo (Pixel)

Retour sur notre shell, avec les infos que j’ai. Dans ce que help(app) m’a remonté, il y a cet objet qui m’intrigue :

NEO_PIXEL -- <NeoPixel object at 3ffe8300>

Une rapide recherche avec le terme NEOPIXEL me sort ce site gcworks.fr/tutoriel/esp/LEDNeoPixel

Les NeoPixel sont des LEDS RVB intelligentes ultra lumineuses. Exemple : ce petit module sous la forme d’un stick, est équipé de 8 NeoPixels.

Ca sent très très bon cette histoire ! Mon blinky c’est quand même un peu un ruban de LED rond ! Le site donne même du code d’exemple pour tester :

import machine
import neopixel # import de la bibliothèque NeoPixel
np = neopixel.NeoPixel(http://machine.Pin(26), 8) # 8 LEDS connectées broche 26 (D2 shiel base 1)
np[0] = (255, 0, 0)
np.write()

Petit retour en arrière, quand j’avais démonté le blinky, voilà à quoi ça ressemblait :

Si on regarde plus en détail, on remarque qu’il y a 13 LEDs sur notre Blinky. Une au milieu (led_status) et 12 autres en cercle.

Il est donc probable que mon tableau neopixel fasse une taille de 13 cases. Cependant, difficile de deviner sur quel PIN le ruban est connecté avec cette photo…

Je suis donc parti du principe que c’était bien le pin 26 et j’ai testé le code d’exemple… sans succès…

>>> np = neopixel.NeoPixel(app.Pin(26),12)
>>> np[1] = (255, 255, 0)
>>> np.write()
>>> np[2] = (255, 255, 0)
>>> np.write()
>>> np[3] = (255, 255, 0)
>>> np.write()

Et puis, j’ai réfléchis et je ne suis dis… “pourquoi je m’embête à déclarer un objet NeoPixel, puisque j’en ai déjà un en mémoire 🤔 ???”

>>> app.NEO_PIXEL
<NeoPixel object at 3ffe8300>
>>> app.NEO_PIXEL[0]
(0, 0, 255)
>>> app.NEO_PIXEL[1]
(0, 0, 0)
>>> app.NEO_PIXEL[2]
(0, 0, 0)
>>> app.NEO_PIXEL[12]
(0, 0, 0)

A l’état initial du Blinky, toutes les leds sont bien positionnées sur “(0, 0, 0)” (éteint), et la led_status à “(0, 0, 255)” (bleu). On est pas mals là !

>>> app.NEO_PIXEL[13]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "neopixel.py", line 1, in __getitem__
File "neopixel.py", line 1, in <genexpr>
IndexError: bytearray index out of range

Il n’y a pas de case 13, comme j’avais deviné (de 0 à 12).

Et si je change une couleur sur une LED…

>>> app.NEO_PIXEL[1]=(255, 0, 0)
>>> app.NEO_PIXEL.write()

BINGO !

Et maintenant… que vais-je fai-re ?

Bon, on a toujours pas trouvé ce fichu code source et je commence à manquer d’idées… Mais on a du réseau et on a pas encore été graté du côté du MQTT (il y a des choses qui sont configurées)… On va probablement regarder de ce côté là dans le prochain épisode !

Bonus, faire des trucs rigolos avec mes LEDs

En bonus, je vous met quelques bouts de codes que je me suis amusés à écrire et qui font des trucs jolis / mignons avec le blinky :

J’ai découvert sur le tard qu’on pouvait copier coller de large morceaux de codes indentés avec [CTRL-E], puis [CTRL-D] pour valider.

[CTRL-E]
from time import *
from random import randint
def full_random():
while True:
r = randint(0, 100)
g = randint(0, 100)
b = randint(0, 100)
for led in range(1, 12):
app.NEO_PIXEL[led] = (r, g, b)
app.NEO_PIXEL.write()
sleep_ms(100)
def full_random_rotation():
while True:
for led in range(1, 12):
r = randint(0, 100)
g = randint(0, 100)
b = randint(0, 100)
app.NEO_PIXEL[led] = (r, g, b)
app.NEO_PIXEL.write()
sleep_ms(50)
def blue_rotation():
while True:
for led in range(1, 12):
for i in range(1,12):
app.NEO_PIXEL[i] = (0, 0, 0)
app.NEO_PIXEL[led] = (0, 0, 255)
app.NEO_PIXEL.write()
sleep_ms(100)
def kitt():
# Set all leds to black
for i in range(0, 12):
app.NEO_PIXEL[i] = (0, 0, 0)
while True:
# Forward loop from 2 to 6 (7 excluded)
for led in range(2, 7):
app.NEO_PIXEL[led] = (150, 0, 0)
app.NEO_PIXEL.write()
sleep_ms(100)
app.NEO_PIXEL[led] = (0, 0, 0)
# Backward loop from 5 to 3 (2 excluded)
for led in range(5, 2, -1):
app.NEO_PIXEL[led] = (150, 0, 0)
app.NEO_PIXEL.write()
sleep_ms(100)
app.NEO_PIXEL[led] = (0, 0, 0)
[CTRL-D]

Reverse du Blinky, le gyrophare connecté des copains de chez Enix - part 1

Fri, 16 Jun 2023 12:00:00 +0200

Cet article fait partie d’une suite d’articles sur le reverse engineering d’un prototype de Gyrophare connecté appelé Blinky :

Introduction

Il y a quelques mois, j’ai rejoint une beta pour un projet de “gyrophare connecté”, Blinky, lancé par les copain⋅es de chez Enix.

Yaaaar 🦍🏴‍☠️

La semaine dernière, j’ai donc reçu une version de test/PoC du fameux gyrophare, par la Poste (il y avait une soirée de lancement sur Paris, mais je n’étais pas disponible).

Sauf qu’un petit malin à la soirée parisienne a (a priori) récupéré le petit papier expliquant ce qu’il fallait en faire.

En temps normal, un adulte responsable aurait juste demandé aux membres de l’équipe de l’aide. Mais c’est sans compter mon côté gamin espiègle, qui a pris le dessus.

Pourquoi prendre 5 minutes pour demander de l’aide alors qu’on peut passer plusieurs heures à faire du ✨ reverse engineering ✨ ?

Note : je précise que je ne suis pas un spécialiste du reverse engineering, que je n’ai jamais bidouillé d’IoT et que je n’y connais rien en impression 3D. Je débute dans tous ces domaines. Vous pardonnerez donc mon côté noob ;-).

Par où commencer ?

Au moment où je décide de commencer ma session de retro ingénierie, je me dis juste qu’il y a sûrement une image Docker qui traîne quelque part pour communiquer avec le Blinky.

Note : A ce moment-là, je ne sais pas encore que c’est un produit SaaS et je pense qu’on peut le faire tourner en local.

J’en trouve une que je télécharge, je fais quelques tests et voilà ce que ça donne quand j’arrive à la faire fonctionner :

En lisant tout ça, j’en retire plusieurs infos. Je repère les termes esp32, pyboard et je remarque surtout que l’image Docker disponible sur Internet est en version 1.0.3 alors que l’image sur mon Blinky est elle en version 2.1.0.

On va essayer d’éviter de l’écraser, du coup !

Comme je ne sais plus trop où chercher, je cherche des informations supplémentaires sur le site getblinky.io.

Je vois tout de suite une animation qui montre les entrailles du Blinky.

C’est pas très net, mais j’ai l’impression d’apercevoir les LEDs, un bouton poussoir, un buzzer et la mention Espressif sur le plus gros composant.

On ouvre le Blinky pour voir

La capture d’écran faites à l’arrache est pas super nette. Comme j’ai l’objet dans les mains, le plus simple c’est de l’ouvrir pour aller voir par moi-même !

J’y connais rien en impression 3d mais sans trop de doute, ici ça en est 😉. Je découvre par la même qu’il existe des filaments translucides, pratique pour les LEDs ;-)

Pour ouvrir la bestiole, je vois 3 vis 6 pans. Heureusement que j’avais des tournevis étoile (t8) sous la main, ça marche quand même…

La partie supérieure est composée de plusieurs morceaux imprimés en 3d :

La partie translucide, la partie supérieure sont relativement simples. La partie blanche est plus travaillée en revanche, et permet de faire “ressort” pour le bouton poussoir.

Dans la partie inférieure, on trouve les pas de vis, fusionnées.

Je ne savais pas comment c’était possible de faire ça, heureusement le Twitter makers m’a expliqué que ça se faisait super simplement, à l’aide d’un fer à souder (cf cette vidéo)!

Et voilà le morceau que vous attendiez tous/toutes : le circuit imprimé qui pilote tout ça :

On retrouve tout ce que j’avais pu observer sur la capture d’écran faite sur le site http://getblinky.io mais sur quelque chose de bien plus clean. Il y a des LEDs, un buzzer, le bouton poussoir et… le fameux esp32 espressif !

A priori, je l’ai remonté sans rien casser 🤣

A la découverte de l’ESP32

Maintenant que j’ai une photo plus nette de l’ESP32, je peux commencer à me documenter dessus.

Il s’agit d’un ESP32-WROOM-32E de chez ESPRESSIF, dont les specs sont disponibles ici

Je remarque qu’il dispose du WI-FI, j’en ai déduit que c’était probablement une machine autonome, une fois connectée au réseau.

Niveau puissance, on est sur un dual-core 32-bit LX6 🤷, qui monte jusqu’à (tenez-vous bien) 240 MHz !

Je blague, mais en vrai c’est même trop pour ce qu’on va en faire ;-).

Par curiosité, je suis allé voir mon copain Ali, et ça coûte 3,34€ pièce pour ce modèle exact (https://fr.aliexpress.com/item/33007945338.html).

En revanche, je n’ai aucune idée de combien ça coûte de faire produire le circuit sur lequel il est branché (c’est visiblement fait en usine).

On se connecte ?

Une fois que je connecte en USB mon Blinky, je vois apparaître une ligne Silicon Labs CP210x UART Bridge quand je lance la commande lsusb.

Une rapide recherche permet de comprendre que c’est bien notre port série virtuel (via USB)

https://silabs.com/developers/usb-to-uart-bridge-vcp-drivers

The CP210x USB to UART Bridge Virtual COM Port (VCP)

Donc ça, ça fonctionne correctement.

La doc officielle sur le site espressif dit d’ajouter son utilisateur au groupe dialout

sudo usermod -a -G dialout $USER

Puis d’utiliser putty pour se connecter en série sur le ttyUSB0 :-/. Personnellement (sous Linux), je n’ai pas réussi. En revanche, je remarque qu’on peut utiliser screen, sous Mac. Pas de raison que ça ne marche pas sous Linux.

Et effectivement, ça fonctionne.

Le screen a l’air bloqué mais… un simple [Ctrl-C] et me voilà dans le terminal python…

Traceback (most recent call last):
File "main.py", line 7, in <module>
File "firmware_blinky_esp32.py", line 92, in main
File "uasyncio/core.py", line 1, in run_forever
File "uasyncio/core.py", line 1, in run_until_complete
File "firmware_blinky_esp32.py", line 69, in start
File "serial_cli.py", line 101, in poll_cli
KeyboardInterrupt:
MicroPython v1.18 on 2023-04-26; ESP32 module with ESP32
Type "help()" for more information.
>>>

C’est le moment dans les films d’espions où le hacker dit “I’m in” 😎.

On va essayer de trouver du code

Maintenant qu’on a la main sur l’interpréteur Python, on va pouvoir farfouiller un peu :).

J’avais déjà vu mention de pyboard dans l’image Docker, ce qui m’avait emmené sur la doc de MicroPython. Ici, on a bien la confirmation que c’est MicroPython qui tourne sur le Blinky.

MicroPython v1.18 on 2023-04-26; ESP32 module with ESP32

La première idée qui vient à l’esprit est de parcourir le filesystem, pour voir si je peux pas trouver les sources.

>>> import os
>>> os.[TAB]
remove VfsFat VfsLfs2 chdir
dupterm dupterm_notify getcwd ilistdir
listdir mkdir mount rename
rmdir stat statvfs umount
uname urandom
>>> os.getcwd()
'/'
>>> os.listdir()
['flash', 'boot.py']
>>> os.listdir('/flash')
['client.crt', 'client.key', 'hw_version']
>>> with open('flash/hw_version') as f:
... s = f.read()
...
>>> print(s)
v1mk3

La capture précédente montre tout ce que je peux voir sur le FS et je ne vois pas le code source. Le fichier boot.py ne contient rien (tout est commenté), hw_version affiche juste v1mk3, la version de mon Blinky (comme on a pu le voir au dos du circuit imprimé).

Je découvre des trucs en Python

Un peu par hasard, j’ai testé la commande dir(), qui m’affiche ce qui est chargé en mémoire, et qu’on peut afficher des infos dessus avec help() :

>>> dir()
['uos', '__name__', 'app', 'gc', 'bdev', 'mount_flash']

Il y a tout un tas de type d’objets, des strings (__name__), des fonctions, des modules…

Il y en a une entrée qui me fait de l’œil : “app”. Il se trouve que c’est un module.

>>> dir(app)
['__class__', '__name__', 'main', 'start', '__file__', 'Pin', 'log', 'machine', 'network', 'uasyncio', 'NEO_PIXEL', 'handle_pbpv2_message', 'BEACON_ID', 'PATTERNS', 'STATUS', 'BUTTON', 'VERSION', 'load_config', 'check_config', 'poll_cli', 'MQTT', 'set_status_pixel', 'init_logger', 'resetting', 'handle_button_release', 'greetings', 'exception_handler']

Et avec plus de détails :

>>> help(app)
object <module 'firmware_blinky_esp32' from 'firmware_blinky_esp32.py'> is of type module
[...]
set_status_pixel -- <function set_status_pixel at 0x3ffe73a0>
[...]

Note : j’omets volontairement une grande partie des infos qu’on peut dénicher, on y reviendra plus tard.

La première chose qui me saute aux yeux est qu’il existe une fonction set_status_pixel()

Si je la lance telle quelle, j’apprends qu’elle attend un argument :

>>> app.set_status_pixel()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: function takes 1 positional arguments but 0 were given

Et comme par hasard, j’ai une structure STATUS qui contient des tuples qui ressemblent très fortement à des codes RGB.

[...]
STATUS -- {'configuring': (0, 0, 255), 'connecting_to_wifi': (255, 0, 0), 'connecting_to_mqtt': (255, 100, 0), 'ready': (0, 255, 0)}

Qu’est ce qu’il se passe si je lance la fonction suivante ??? 🕵️‍♂️

>>> app.set_status_pixel((255, 0, 0))

BINGO !

La suite ?

Je m’arrête ici pour que l’article reste digeste, mais j’ai plein d’idée pour aller plus loin (j’ai d’ailleurs bien commencé).

Le but du jeu va être de trouver comment piloter les LEDs (voire plus ?), comment communiquer avec le Blinky (MQTT ?) et continuer à chercher pour trouver où est ce coquin de code source ;-)