Daniel Stenberg, May 21st
A saga about a bunch of people
who grew bored with a factory
installed firmware in consumer
electronics and wrote their own
Feel free to interrupt and ask at any time!
Let me tell you a story...
•this story begins in the early 2001
•3 men in their best years
•embedded systems hackers
•the dawn of the mp3 player revolution
Archos mp3 players
•First mp3 player with a HDD
•Probably the crappiest firmware
in the world
•Surely we could do better? How
hard can it be?
•Read the onboard circuits and search or ask
•Used to be a good away
•… barely gives away anything nowadays
•Can it be hacked?
•Almost universally: yes
Firmware upgrade option!
•Look you can upgrade firmware...
•What's the architecture again?
•Collect several firmware files
•Throw everything and everyone at it
•This can take a lot of time
•Were we allowed to do this?
•The world is full of jurisdictions
•We are Swedish, what does EU laws say?
•The 1991 EU Computer Programs Directive, article 6:
•The 2009 EU Computer Program Directive:
The authorization of the rightholder shall not be required
where reproduction of the code and translation of its form ...
are indispensable to obtain the information necessary to
achieve the interoperability of an independently created
computer program with other programs
performance of the acts of reproduction and translation by or
on behalf of a person having a right to use a copy of the
program is legitimate and compatible with fair practice and
must therefore be deemed not to require the authorisation of
the rightholder. An objective of this exception is to make it
possible to connect all components of a computer system,
including those of different manufacturers, so that they can
XORing a fixed string
•By guessing parts of the decrypted file some “encryption”
is easier than others
•Early devices just scrambled firmwares like this
How do things work in there?
•Figure out how your architecture works
•Master things like the CPU instruction set and how a
•These days things are “always” ARM
•The CPU core is not the problem, the peripherals, busses
and associated HW are the challenges
•Objdump is an excellent tool
•Is not as hard as you might think
•Look for register addresses / memory layout patterns
•Error messages/strings/bitmaps or pointers to them
Disassembly even easier
•IDApro is an advanced tool to automate the task even
• Detects lots of C/C++ magic by itself
• Stack frames
• Memory layout
Scan the bare PCB and beep them
clues printed on the
Hiding what's inside
•Rub off all markings
•Use chips without public documentation
•Use chips unsupported by gcc
•Many devices leave debug points for BDM / JTAG or
Attaching stuff on their HW
•Hm, what do we have here...
•Have multiple devices
•Primary boot-loader feature: run the original
•If possible, load and run from RAM only until tested
Software decoding targets
•Our first targets had mp3 decoding hardware
•New architectures entered
•More XOR and checksums
•Detect code patterns and search online for data sheets.
•Partial matches may give “similar chips” that have
•Used hidden hard-drive partitions
•Used completely (publicly) undocumented chips
•Took a long time to master
Later target examples
•Boot-loader that loads and decrypts firmware
•Magic constants in the boot-loader code revealed
•Boot-loader also upgradable (plain) gave away crypto
•Known flags in digital signature algorithm (DSA) offered
shortcut in code signing
Loading encrypted payloads
•Target loads only encrypted files
•User finds flaw in one firmware version that crashes the
•A buffer overflow in the HTML reader
•Look, if we add crafted data in that HTML file we can
•When we used a loop to write in memory we managed to
toggle the backlight
From backlight to restored key
• dump memory using a videocamera and toggle backlight
• 32MB contents took many hours
• analyze what's in memory
• code, data, clues
• see, there's a pattern of USB registers
• rewrite the memory dump program to send contents over USB, insert
the whole thing into a HTML file, load it on target device
• there seems to be code referencing an SRAM
• dump SRAM too
• Look, there's something that looks like a crypto key!
It takes time and people
•Lots of time
•> 1 year from buffer overflow to running code
Getting it done faster?
•What if there was (lots of) money to gain?
•More clever people spending more of their time
•More computers cracking crypto
•More hardware analyzers
•If you can upgrade the device, reverse engineering it will
From tiny to Android
12 MHz CPU
500 MHz CPU
Today: the dedicated mp3 player market is dead or dying
and everyone is going Android
Reverse engineering is still done mostly the same
Linux-based reverse engineering
•More devices use full-fledged Linux
•More flaws, more drivers, less ways to have “unique”
solutions hard to figure out
•Manufacturers stick to undocumented hardware
•… and booting encrypted blobs
•Once “hacked”, putting your own SW can be much easier:
• familiar APIs (libc, u-boot, standard libs)
• familar drivers (even if binary blobs will be there)
A complete and very portable open source mp3 player
firmware replacement, including multi-tasking operating
system and application suite...
Started by me and my two friends Linus and Björn.
Runs on almost 100 different mp3 players from brands such
as Toshiba, Tatung, Sony, SanDisk, Samsung, Philips, Pandora,
Onda, Olympus, MPIO, Creative, Apple, Archos, Cowon,
HifiMan, Meizu, iRiver, Packard Bell, iAudio and more...