Your SlideShare is downloading. ×
Reverse engineering
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Reverse engineering

458
views

Published on

Reverse Engineering explained with the story of Rockbox. How we reverse engineered consumer mp3 players and put our firmware replacement on them.

Reverse Engineering explained with the story of Rockbox. How we reverse engineered consumer mp3 players and put our firmware replacement on them.

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
458
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Яev3rse eng1neering Daniel Stenberg, May 21st 2014
  • 2. Agenda A saga about a bunch of people who grew bored with a factory installed firmware in consumer electronics and wrote their own implementation
  • 3. Daniel Stenberg Email: daniel@haxx.se Twitter: @bagder Web: daniel.haxx.se Blog: daniel.haxx.se/blog hacker at
  • 4. Please ask! Feel free to interrupt and ask at any time!
  • 5. 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
  • 6. Archos mp3 players •December 2000 •First mp3 player with a HDD •Probably the crappiest firmware in the world •Surely we could do better? How hard can it be?
  • 7. What's inside? •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
  • 8. Firmware upgrade option! •Look you can upgrade firmware... •What's the architecture again? •Collect several firmware files •Analyze differences •Throw everything and everyone at it •This can take a lot of time
  • 9. Intermission: legality •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 work together
  • 10. XORing a fixed string •By guessing parts of the decrypted file some “encryption” is easier than others •Early devices just scrambled firmwares like this
  • 11. How do things work in there? •Figure out how your architecture works •Master things like the CPU instruction set and how a stack works •These days things are “always” ARM •The CPU core is not the problem, the peripherals, busses and associated HW are the challenges
  • 12. Disassembly •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
  • 13. Disassembly even easier •IDApro is an advanced tool to automate the task even more • Detects lots of C/C++ magic by itself • Stack frames • Bitmaps • Structs • Strings • Memory layout
  • 14. Scan the bare PCB and beep them BGA removed! Surprisingly many clues printed on the PCB
  • 15. Hiding what's inside •Rub off all markings •Use chips without public documentation •Use chips unsupported by gcc
  • 16. Hardware debuggers •Many devices leave debug points for BDM / JTAG or debug uarts •Like this:
  • 17. Attaching stuff on their HW •Hm, what do we have here...
  • 18. oh so useful
  • 19. Stripped and attached
  • 20. Anti-bricking measures •Have multiple devices •Primary boot-loader feature: run the original •If possible, load and run from RAM only until tested
  • 21. 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 documentation
  • 22. Early ipods •Used hidden hard-drive partitions •Used completely (publicly) undocumented chips •Took a long time to master
  • 23. Later target examples •Boot-loader that loads and decrypts firmware •Magic constants in the boot-loader code revealed algorithm. •Boot-loader also upgradable (plain) gave away crypto keys •Known flags in digital signature algorithm (DSA) offered shortcut in code signing
  • 24. So what about true cryptography?
  • 25. Loading encrypted payloads •Target loads only encrypted files •User finds flaw in one firmware version that crashes the device •A buffer overflow in the HTML reader •Look, if we add crafted data in that HTML file we can execute code •When we used a loop to write in memory we managed to toggle the backlight
  • 26. A backlight reading device
  • 27. 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!
  • 28. It takes time and people •Many volunteers •Skilled volunteers •Devoted volunteers •Lots of time •> 1 year from buffer overflow to running code
  • 29. 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 be possible
  • 30. From tiny to Android 2001 2MB RAM 6GB HDD 12 MHz CPU 2010 64MB RAM 120GB HDD 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
  • 31. 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) • gcc!
  • 32. Rockbox 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...
  • 33. Tower of Rockbox
  • 34. Thank you!
  • 35. Learn more! •Rockbox http://www.rockbox.org/ •“Reverse Engineering for Beginners” http://yurichev.com/writings/RE_for_beginners-en.pdf
  • 36. Doing good is part of our code