Lors de la quinzième édition de la Nuit du Hack, qui avait lieu ce week-end au New York Hotel de Disneyland Paris, j'ai présenté un moyen simple et pas cher de concevoir un équipement permettant de réaliser des attaques sur le protocole Bluetooth Low Energy (BLE), voire de simuler le comportement de n'importe quel équipement BLE. Je n'ai pas eu le temps d'entrer dans les détails, aussi vais-je le faire dans ce billet de blog.
Recyclage de Gablys
Cela fait quelques années que je cotoie des Gablys, des porte-clés connectés en BLE à des smartphones permettant de détecter la perte de clés ou d'objets, qui peut accessoirement être utilisé comme télécommande pour déclencher des selfies ou retrouver son smartphone égaré (une fonction de localisation inversée, en quelque sorte).
Un Gablys est assez simple: l'ensemble repose sur un transceiver de Nordic Semiconductor capable de communiquer en BLE, le nRF51822. Ce transceiver intègre un CPU ARM ainsi qu'une mémoire Flash de 256Kio, et a la particularité d'être débuggable et programmable via OpenOCD. De plus, il possède de base un bouton poussoir ainsi qu'un buzzer piezzo, qui permettent une interaction utilisateur (quoique l'on peut s'en passer selon les usages).
Les avantages du nRF51822 sont multiples:
Bref, il est dès lors possible de reprogrammer un Gablys afin de lui faire faire ce que l'on veut, à l'aide d'outils standards.
Installation des logiciels nécessaires
Pour réussir à développer et tester un firmware opensource pour Gablys, j'ai commencé par télécharger la version 11.0 du SDK de Nordic Semiconductor. Pourquoi la version 11.0 me direz-vous ? Parce que c'était celle a priori employée pour développer le firmware original de la bête. Notez que la dernière version du SDK devrait tout aussi bien fonctionner, mais il faudra prendre en compte les évolutions des fonctions exposées par ce dernier.
Tout d'abord, on télécharge la version voulue du SDK (la version 12.0 par exemple sur le site de Nordic Semiconductor. On dézippe le fichier dans un dossier prévu à cet effet:
$ unzip nRF5_SDK_12.3.0_d7731ad.zip $ mv nRF5_SDK_12.3.0_d7731ad nrf5-sdk
Il nous faut ensuite installer la toolchain ARM et en ce qui me concerne j'ai préféré installer une version à jour plutôt que celle de ma debian, en la téléchargeant directement à partir du site d'ARM. J'en ai profité pour la décompresser dans un dossier à part, nommé toolchain:
$ cd nrf5-sdk && mkdir toolchain && cd toolchain $ wget "https://developer.arm.com/-/media/Files/downloads/gnu-rm/6_1-2017q1/gcc-arm-none-eabi-6-2017-q1-update-linux.tar.bz2?product=GNU%20ARM%20Embedded%20Toolchain,64-bit,,Linux,6-2017-q1-update" $ tar xvjf gcc-arm-none-eabi-6-2017-q1-update-linux.tar.bz2
Une fois la toolchain ARM décompressée, il suffit de la déclarer dans le fichier components/toolchain/gcc/Makefile.posix du SDK Nordic Semiconductor:
GNU_INSTALL_ROOT := /home/virtualabs/nrf5-sdk/toolchain/gcc-arm-none-eabi-6-2017-q1-update/ GNU_VERSION := 6.3.1 GNU_PREFIX := arm-none-eabi
Enfin, il nous faut ajouter une configuration particulière pour notre Gablys dans le fichier examples/bsp/gablys.h. Pour ce faire, il suffit de copier un fichier de configuration existant:
$ cp pca20006.h gablys.h
Nous en profitons pour ajouter une ligne dans le fichier boards.h du même dossier afin de déclarer notre board:
... #elif defined(BOARD_N5DK1) #include "n5_starterkit.h" #elif defined(BOARD_GABLYS) #include "gablys.h" #elif defined(BOARD_CUSTOM) #include "custom_board.h" #else #error "Board is not defined" ...
Puis de modifier la fin du fichier afin de ne pas utiliser de quartz basse-fréquence, absent sur notre Gablys:
// Low frequency clock source to be used by the SoftDevice
#define NRF_CLOCK_LFCLKSRC * \
.source = NRF_CLOCK_LF_SRC_RC, \
.rc_ctiv = 16, \
.rc_temp_ctiv = 2, \
.xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_250_PPM \
*
De cette manière, tous les codes exemples fonctionneront sans problème avec notre Gablys, ce dernier ne possédant pas d'oscillateur basse-fréquence. Il est alors temps de lancer notre première compilation, et voir si ces modifications portent leurs fruits.
Première compilation
Pour essayer notre configuration, nous allons tenter de compiler une application BLE sur mesure, ble_app_beacon. Pour ce faire, nous allons ajouter une configuration propre à notre Gablys, et faire en sorte de tout configurer pour que cela compile correctement.
Dans un premier temps, il nous faut créer une arborescence sur mesure:
$ cd nrf5-sdk/examples/ble_peripheral/ble_app_beacon/ $ mkdir -p gablys/s130/armgcc/ $ cp pca20006/s130/config ./gablys/s130/ -rf $ cp pca20006/s130/armgcc ./gablys/s130/armgcc -rf
Puis nous éditons dans un premier temps le fichier Makefile situé dans le dossier gablys/s130/armgcc/, afin de déclarer notre board plutôt que celle d'origine (PCA20006). Pour ce faire, il faut changer les options de compilation -DBOARD_PCA20006 en -DBOARD_GABLYS:
# Libraries common to all targets LIB_FILES += \ # C flags common to all targets CFLAGS += -DSWI_DISABLE0 CFLAGS += -DSOFTDEVICE_PRESENT CFLAGS += -DNRF51 CFLAGS += -DNRF51822 CFLAGS += -DS130 CFLAGS += -DBLE_STACK_SUPPORT_REQD CFLAGS += -DBOARD_GABLYS CFLAGS += -DNRF_SD_BLE_API_VERSION=2 CFLAGS += -mcpu=cortex-m0 CFLAGS += -mthumb -mabi=aapcs CFLAGS += -Wall -Werror -O3 -g3 CFLAGS += -mfloat-abi=soft # keep every function in separate section, this allows linker to discard unused ones CFLAGS += -ffunction-sections -fdata-sections -fno-strict-aliasing CFLAGS += -fno-builtin --short-enums # C++ flags common to all targets CXXFLAGS += \ # Assembler flags common to all targets ASMFLAGS += -x assembler-with-cpp ASMFLAGS += -DSWI_DISABLE0 ASMFLAGS += -DSOFTDEVICE_PRESENT ASMFLAGS += -DNRF51 ASMFLAGS += -DNRF51822 ASMFLAGS += -DS130 ASMFLAGS += -DBLE_STACK_SUPPORT_REQD ASMFLAGS += -DBOARD_GABLYS ASMFLAGS += -DNRF_SD_BLE_API_VERSION=2
Et on lance la compilation avec make:
$ make mkdir _build Compiling file: nrf_log_backend_serial.c Compiling file: nrf_log_frontend.c Compiling file: app_button.c Compiling file: app_error.c Compiling file: app_error_weak.c Compiling file: app_timer.c Compiling file: app_util_platform.c Compiling file: hardfault_implementation.c Compiling file: nrf_assert.c Compiling file: sdk_errors.c Compiling file: boards.c Compiling file: nrf_drv_clock.c Compiling file: nrf_drv_common.c Compiling file: nrf_drv_gpiote.c Compiling file: nrf_drv_uart.c Compiling file: bsp.c Compiling file: bsp_nfc.c Compiling file: main.c Compiling file: RTT_Syscalls_GCC.c Compiling file: SEGGER_RTT.c Compiling file: SEGGER_RTT_printf.c Compiling file: ble_advdata.c Compiling file: ble_conn_params.c Compiling file: ble_srv_common.c Assembling file: gcc_startup_nrf51.S Compiling file: system_nrf51.c Compiling file: softdevice_handler.c Linking target: _build/nrf51822_xxaa.out text data bss dec hex filename 11808 136 616 12560 3110 _build/nrf51822_xxaa.out Preparing: _build/nrf51822_xxaa.hex Preparing: _build/nrf51822_xxaa.bin
Le code compile parfaitement, et le Makefile produit un fichier binaire ainsi qu'un fichier au format ihex, dont nous allons nous servir pour programmer le nRF51822 présent sur le Gablys.
Programmation du Gablys
Le Makefile standard est fait pour fonctionner avec l'outil nrfjprog, cependant il est possible de le faire fonctionner avec OpenOCD et un STLink v2 à la chinoise.
Première étape, installer OpenOCD. La version 0.10.0 tirée de Github fera l'affaire. Vous pouvez tout aussi bien l'installer via les paquets standards de votre distribution, cela devrait fonctionner de la même façon.
On modifie donc la fin de notre fichier Makefile pour y intégrer deux cibles: la première nommée flash permettant de flasher l'application, la seconde nommée flash_softdevice permettant de flasher le SoftDevice [1].
flash: nrf51822_xxaa
@echo Flashing: $(OUTPUT_BINARY_DIRECTORY)/$<.hex
openocd -f interface/stlink-v2.cfg -f target/nrf51.cfg -c init -c "reset init" -c "halt" -c "program _build/nrf51822_xxaa.hex verify" -c "reset" -c "exit"
## Flash softdevice
flash_softdevice:
@echo Flashing SoftDevice s130 ...
openocd -f interface/stlink-v2.cfg -f target/nrf51.cfg -c init -c "reset init" -c "halt" -c "nrf51 mass_erase" -c "program $(abspath ../../../../../../components/softdevice/s130/hex/s130_nrf51_2.0.1_softdevice.hex) verify" -c "reset" -c "exit"
Ensuite, il faut connecter correctement le STLink à notre Gablys:
Puis flasher d'abord le SoftDevice, et ensuite l'application:
$ make flash_softdevice && make flash
Flashing SoftDevice s130 ...
openocd -f interface/stlink-v2.cfg -f target/nrf51.cfg -c init -c "reset init" -c "halt" -c "nrf51 mass_erase" -c "program /home/virtualabs/nrf5-sdk/components/softdevice/s130/hex/s130_nrf51_2.0.1_softdevice.hex verify" -c "reset" -c "exit"
Open On-Chip Debugger 0.10.0+dev-00146-g1025be36 (2017-06-16-16:35)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.246408
Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x000006d0 msp: 0x000007c0
Info : nRF51822-QFAA(build code: G2) 256kB Flash
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0xfffffffe msp: 0xfffffffc
** Programming Started **
auto erase enabled
Info : Padding image section 0 with 2112 bytes
Warn : using fast async flash loader. This is currently supported
Warn : only with ST-Link and CMSIS-DAP. If you have issues, add
Warn : "set WORKAREASIZE 0" before sourcing nrf51.cfg to disable it
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000001e msp: 0xfffffffc
wrote 110592 bytes from file /home/virtualabs/nrf5-sdk/components/softdevice/s130/hex/s130_nrf51_2.0.1_softdevice.hex in 4.979112s (21.691 KiB/s)
** Programming Finished **
** Verify Started **
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0xfffffffc
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0xfffffffc
verified 108448 bytes in 0.698049s (151.717 KiB/s)
** Verified OK **
Flashing: /nrf51822_xxaa.hex
openocd -f interface/stlink-v2.cfg -f target/nrf51.cfg -c init -c "reset init" -c "halt" -c "program _build/nrf51822_xxaa.hex verify" -c "reset" -c "exit"
Open On-Chip Debugger 0.10.0+dev-00146-g1025be36 (2017-06-16-16:35)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.246408
Info : nrf51.cpu: hardware has 4 breakpoints, 2 watchpoints
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x000006d0 msp: 0x000007c0
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x000006d0 msp: 0x000007c0
** Programming Started **
auto erase enabled
Info : nRF51822-QFAA(build code: G2) 256kB Flash
Warn : using fast async flash loader. This is currently supported
Warn : only with ST-Link and CMSIS-DAP. If you have issues, add
Warn : "set WORKAREASIZE 0" before sourcing nrf51.cfg to disable it
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000001e msp: 0x000007c0
wrote 12288 bytes from file _build/nrf51822_xxaa.hex in 0.589847s (20.344 KiB/s)
** Programming Finished **
** Verify Started **
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x000007c0
verified 11944 bytes in 0.088029s (132.503 KiB/s)
** Verified OK **
La programmation du SoftDevice et de l'application se sont bien déroulées, tout comme la vérification de la bonne écriture du code. De base, le CPU a été remis à zéro après la programmation, et si vous avez laissé votre Gablys connecté, celui-ci doit annoncer un périphérique BLE ressemblant à un beacon.
Il est temps d'aller plus loin dans le code source, afin d'implémenter quelque chose d'utile !
Firmware opensource pour Gablys
J'ai profité de l'occasion pour développer un firmware opensource pour Gablys, réimplémentant les principaux services et leurs characteristics, et se comportant presque à l'identique. Le code source de ce firmware est disponible sur Github. Ce dernier peut être compilé et flashé comme décrit précédemment.
En pratique, les services propres au Gablys sont implémentés dans le fichier gss/gss.c, dont la fonction ble_gss_init a pour rôle la création et l'initialisation de l'ensemble de ces services et des characteristics associées. A noter l'astuce avec le SDK Nordic pour déclarer un service ayant un UUID sur 128 bits:
static const ble_uuid128_t m_btn_uuid128 =
{
{
0x45, 0xfa, 0x56, 0xc1, 0xfb, 0x1b, 0xc0, 0x28,
0x96, 0xa8, 0x67, 0x18, 0x01, 0x28, 0x17, 0x4f
}
};
/* ... du code ici ... */
/* Add Gablys Button service. */
ble_btn_uuid.uuid = GSS_BTN_SERVICE_UUID;
err_code = sd_ble_uuid_vs_add(&m_btn_uuid128, &ble_btn_uuid.type);
APP_ERROR_CHECK(err_code);
err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY,
&ble_btn_uuid,
&p_gss->btn_service_handle);
if (err_code != NRF_SUCCESS)
{
return err_code;
}
Enfin, la stack BLE est initialisée dans le fichier main.c, grâce à la fonction ble_stack_init:
static void ble_stack_init(void)
{
uint32_t err_code;
nrf_clock_lf_cfg_t clock_lf_cfg = NRF_CLOCK_LFCLKSRC;
// Initialize the SoftDevice handler module.
SOFTDEVICE_HANDLER_INIT(&clock_lf_cfg, NULL);
ble_enable_params_t ble_enable_params;
err_code = softdevice_enable_get_default_config(CENTRAL_LINK_COUNT,
PERIPHERAL_LINK_COUNT,
&ble_enable_params);
APP_ERROR_CHECK(err_code);
//Check the ram settings against the used number of links
CHECK_RAM_START_ADDR(CENTRAL_LINK_COUNT,PERIPHERAL_LINK_COUNT);
// Enable BLE stack.
sd_ble_enable(&ble_enable_params, &app_ram_base);
ble_enable_params.common_enable_params.vs_uuid_count = 10;
err_code = softdevice_enable(&ble_enable_params);
APP_ERROR_CHECK(err_code);
// Register with the SoftDevice handler module for BLE events.
err_code = softdevice_ble_evt_handler_set(ble_evt_dispatch);
APP_ERROR_CHECK(err_code);
// Register with the SoftDevice handler module for BLE events.
err_code = softdevice_sys_evt_handler_set(sys_evt_dispatch);
APP_ERROR_CHECK(err_code);
}
C'est d'ailleurs dans cette fonction que l'on peut rajouter du code permettant d'usurper une adresse MAC, comme ci-dessous:
static void ble_stack_init(void)
{
uint32_t err_code;
ble_gap_addr_t address;
address.addr_type = BLE_GAP_ADDR_TYPE_PUBLIC;
address.addr[0] = 0xFE;
address.addr[1] = 0xFE;
address.addr[2] = 0xC0;
address.addr[3] = 0x15;
address.addr[4] = 0x4D;
address.addr[5] = 0xDE;
nrf_clock_lf_cfg_t clock_lf_cfg = NRF_CLOCK_LFCLKSRC;
// Initialize the SoftDevice handler module.
SOFTDEVICE_HANDLER_INIT(&clock_lf_cfg, NULL);
ble_enable_params_t ble_enable_params;
err_code = softdevice_enable_get_default_config(CENTRAL_LINK_COUNT,
PERIPHERAL_LINK_COUNT,
&ble_enable_params);
APP_ERROR_CHECK(err_code);
//Check the ram settings against the used number of links
CHECK_RAM_START_ADDR(CENTRAL_LINK_COUNT,PERIPHERAL_LINK_COUNT);
// Enable BLE stack.
sd_ble_enable(&ble_enable_params, &app_ram_base);
ble_enable_params.common_enable_params.vs_uuid_count = 10;
err_code = softdevice_enable(&ble_enable_params);
APP_ERROR_CHECK(err_code);
sd_ble_gap_address_set(BLE_GAP_ADDR_CYCLE_MODE_NONE, &address);
// Register with the SoftDevice handler module for BLE events.
err_code = softdevice_ble_evt_handler_set(ble_evt_dispatch);
APP_ERROR_CHECK(err_code);
// Register with the SoftDevice handler module for BLE events.
err_code = softdevice_sys_evt_handler_set(sys_evt_dispatch);
APP_ERROR_CHECK(err_code);
}
Une fois compilé et flashé, le nouvel équipement est visible avec l'adresse MAC DE:4D:15:C0:FE:FE, comme le montre l'exemple ci-dessous (testé avec l'exemple beacon et non le firmware opensource):
Vous vous imaginez bien à ce stade de la lecture qu'il n'est pas très difficile de recréer n'importe quel équipement Bluetooth Low Energy à partir de ce petit porte-clé, et qu'avec un peu d'imagination et de temps on pourrait mettre à mal la sécurité de quelques équipements, voire réaliser des attaques très ciblées sur des périphériques communiquant en BLE.
Ok, et quoi d'autre ?
Nous avons démontré qu'il était possible d'utiliser un Gablys comme plateforme de développement peu onéreuse, à l'aide de logiciels libres et d'équipement à bas coût (STLink v2 notamment), et de profiter des avantages de ce dernier: il est petit, peu gourmand en énergie, programmable à volonté et alimenté par une pile bouton !
Il est dès lors possible de le mettre dans une poche et de simuler un équipement existant jusqu'à utiliser la même adresse Bluetooth (MAC), disons par exemple un cadenas connecté, et d'amener une application sur smartphone à transmettre à ce faux cadenas un code confidentiel (cette dernière faisant confiance à l'adresse Bluetooth du cadenas), comme je l'ai démontré l'année dernière lors de la Nuit du Hack.
J'ai placé le SDK modifié avec les examples cités dans cet article sur un repository spécifique, si certains d'entre vous veulent tester sans tout modifier à la main.
[1] Pour plus d'information sur les SoftDevice de NordicSemiconductor, consulter la page dédiée sur le site du fondeur
La quatorzieme édition de la Nuit du Hack vient tout juste de s'achever, et je dois avouer que c'était juste magique. Magique non pas parce que l'évènement était de retour au pays de Mickey, mais par son organisation, ses contenus et les rencontres que l'on y fait. Petit retour à chaud de cette Nuit du Hack 2016.
Les coulisses du vendredi
Je suis arrivé sur place vendredi soir et j'ai rejoint le staff Hackerzvoice qui s'activait pour tout finir de préparer (badges, tours de cou, etc ...). En tant que conférencier, j'ai passé plus de temps sur le polissage de planches comme on dit à l'ANSSI plutôt que sur les derniers préparatifs, ainsi que sur mes démos bancales. En effet, certaines d'entre elles devaient être testées en conditions réelles, et cela m'a pris quelques heures afin de tout régler (un grand merci à Jonathan pour le coup de main). A 2h30, j'étais couché et fin prêt pour ma présentation.
Enfin, je pensais l'être.
Le Jour J
Samedi matin, après avoir avalé un petit-déjeuner, je me rends au New York Hotel afin de m'imprégner de l'atmosphère du lieu et saluer les premiers arrivés (staff et participants).
C'est l'occasion de se ballader un peu, de découvrir les surprises de l'édition 2016, mais aussi de se poser à nouveau au calme pour repenser un peu les slides. Car après une nuit de réflexion, quelques modifications m'ont semblé utiles. J'apporte ainsi les dernières corrections et boucle la version finale de la présentation.
Je commence à suivre les conférences, bien qu'ayant loupé la keynote de Louis Pouzin. Le talk de Thomas Aubin et Paul Hernault sur la sécurité de Windows 10 et les aspects protection de la vie privée était sympa, avec en prime la démonstration d'une preuve de concept nommée CortaSpoof permettant de limiter la capacité de Microsoft à profiler les utilisateurs de la dernière version de son système d'exploitation. J'ai suivi celui d'Antonio Blanchi sur la participation de l'équipe Shellphish aux différents CTFs d'assez loin, mais les quelques bribes que j'ai pu comprendre m'ont semblé plutôt intéressantes: stratégies de CTF et outils dédiés étaient au programme. Puis ce fut au tour de mon collègue Renaud Lifchitz de démontrer la faiblesse des télécommandes radio employées sur une Set-Top-Box: très instructif et les possibilités offertes sont originales !
Je n'ai pas pu assister à la présentation sur Ethereum, par contre celle sur le piratage des interphones était intéressante: Sébastien Dudek a ainsi démontré que l'on pouvait prendre le contrôle de ceux-ci en abusant du GSM à l'aide de SDR et de fausse station GSM. Les démonstrations sous forme de vidéo étaient funs et démontraient bien les risques encourus. Toutefois, les bons vieux passes PTT ou le vieillissant système Vigik peuvent être des vecteurs d'intrusion tout aussi efficace, et nécessitant moins de moyens.
La conférence suivante consacrée au crochetage improvisé était tout bonnement impressionnante: c'est exactement ce que j'attendais de celle-ci. Ouverture de cadenas avec des shims fait maison (à la MacGyver), forçage de porte au ceintre, les moyens rudimentaires y étaient et ça fait plaisir de voir une approche pragmatique de l'ouverture de portes et serrures ! C'est la dernière conférence que j'ai pu voir, car je suis allé manger assez tôt afin de terminer les préparatifs matériels de ma présentation (prévue à 21h15). Celle-ci s'est déroulée sans encombre, et j'ai eu plusieurs retours positifs ce qui fait toujours plaisir.
Les workshops
J'ai enchainé rapidement mon talk avec un workshop intitulé "Pimp My Badge", présentant le badge électronique de l'année dernière (à défaut d'en avoir un cette année) et les moyens de le bidouiller. Ca a été l'occasion de mettre un peu à jour la bibliothèque standard et d'ajouter quelques exemples.
Comme chaque année, l'atelier de crochetage de serrures a rencontré un franc succès et nombreux étaient ceux voulant s'y essayer. Didier Stevens, l'auteur de OleDump notamment, animait un workshop sur l'analyse de documents malveillants à l'aide (certainement) de ses outils. Je n'ai pas pu le suivre malheureusement, mais il semblait très intéressant.
La NDH Kids
Contrairement aux années précédentes, je n'ai pas animé d'atelier durant la NDH Kids. Mais j'en ai eu de très bons échos: des collègues et amis ayant participé ou ayant des enfants qui y ont participé en sont revenus ravis. Les ateliers étaient diversifiés: initiation à la cryptographie, programmation de Lego Mindstorms, Initiation à l'électronique et à la soudure électronique, architecture d'un ordinateur, ... Avec en plus des bean bags et une borne d'arcade !
Un grand merci
J'ai passé un excellent moment, à la fois en tant que participant mais aussi en tant que conférencier. Il est bon de retrouver une organisation comme celle de cette édition, fluide et sans accrocs, malgré la paranoia sécuritaire que l'on a pu observer lors de l'arrivée (scans aux rayons X, détecteurs de métaux, fouille de sacs). Et il y avait du Club Mate ! Bref, on remet ça l'année prochaine, et il y aura du lourd, du très très lourd (© Michel & Michel)
La première édition de ce workshop ayant été un succès, on remet ça cette année ! Qu'est-ce qu'un workshop ? En réalité, rien de bien compliqué: un atelier ouvert à l'échange, durant lequel on réalise des trucs sympas, durant lequel on découvre et apprend, autant vous que nous. C'est un moment d'échange convivial, autour d'un thème qui réunit, en l'occurence le Hardware Hacking.
Plus simple, plus abordable, mais tout aussi sexy
Cette année, on fait dans le "wearable", en réalisant un pendentif tout ce qu'il y a de plus geek, basé sur un Arduino miniature alimenté par batterie et une matrice de 8 x 8 LEDs. De quoi afficher ses goûts, son nom, et de faire des animations sympas. Le workshop couvre:
Les participants pourront exhiber fièrement leur pendentif ainsi réalisé et réutiliser certains des composants pour d'autres projets si cela leur chante ! Il y a aussi possibilité de combiner le pendentif au badge électronique de l'édition 2015 de l'évènement =).
Le pendentif ressemble, une fois assemblé et programmé, à ceci:
Ce pendentif électronique a été conçu par Limor Fried et AdaFruit, qui le recommande pour une initiation à la soudure et au développement sur micro-contrôleurs.
Comment participer ?
Eh bien, on ne change pas un système qui marche ! J'ai mis en place une campagne de financement participative sur Ulule dont la contrepartie principale offre droit à une place à cet atelier, dans la limite des 30 places disponibles.
Chaque participant se verra remettre un kit contenant:
Le montant pour la participation est fixé à 40€, ce qui permet de couvrir les besoins matériels pour l'atelier, et de repartir avec un pendentif électronique trendy & geek au possible !
La place pour l'évènement de la Nuit du Hack, durant lequel se déroule cet atelier, n'est pas comprise dans la participation demandée ! Pour en obtenir une, il faut vous rendre sur le site de la Nuit du Hack.