Hi everybody, I'm Micah Scott! I'm an artist and hardware hacker I've been posting a bunch on Twitter about a weird new project A lot of people have been curious about it Let me show you something This. This machine You can buy it on Amazon $80 high tech brushless motor three different lasers photodiode amplifier stepper motor solenoid and it can carve patterns
onto these plastic discs a resolution of like 150 nanometers or so This machine is pretty neat! it's sort of a
desktop manufacturing device but the things it
manufactures are so tiny we don't usually think of it
as manufacturing anyway This device I have It's a common Blu-Ray burner Well, so what am I doing with this? Well, I'm hacking it. I'm trying to get inside it change the patterns
that it burns onto discs I've seen people take the individual parts
out of these burners Some researchers built this really cool microscopic tweezer by modifying a DVD burner they used the lens to focus
a laser beam just right they could hold cells in place
while they worked on them They just bought the
optical pickup assembly just this front part off of eBay then developed their own really
simple electronics for controlling it control electronics in here
that are pretty great! So far I know there are
at least three CPUs process data at dozens of
megabytes per second these discs, they hold 25 gigabytes on one layer The processor in here is
actually not very fast it's got a lot of interesting
bits of hardware that all talk to each other
to make this job work how can we hack the hardware
we already have? to do our own work? and control these devices
to make our own things? So Micah, what am I doing with this thing? I'm kind of a hardware hacker I've been doing this for a long time but I'm also an artist and I've been really focusing on what can I do that will open up
some kind of dialogue make some kind of human connection So, this project has that side too. Cheap open source holograms for digital graffiti and I want to use this as a way
to open up dialogue across boundaries that people
might shy away from I want to do that by taking
advantage of this fact We're really attracted to
shiny new technology so what if I can make something that
seems really shiny and new something that's never been done before but, do it for free and put it out there as open source and make the parts cheap enough I can have a cart set up
in an alley in the city Anybody can write a pattern Or type a word on a tablet For $1 or $2 of parts I could
give them a kit Light graffiti that's non-destructive
and communicates a message So it's really crazy I have no idea if this is going to work If it doesn't work, maybe I just
get a really awesome fun machine that breaks itself
and burns up discs which would also be kind of neat! That's kind of my end pie-in-the-sky goal. So I've got these robots and they're pretty neat Normally when you plug
the robots into a computer they show up as a USB storage device This is the same kind of device as
a USB thumb drive or hard drive. It's an umbrella USB standard that
translates USB into SCSI, the old-school low-level storage
protocol your disks know how to speak That protocol normally says things like Turn on the disk! Read block number 4! Read block number 50000! It turns out there are also some commands to do things that aren't
in the specifications. Things like upgrade the firmware I had a suspicion that I would be able
to find some commands on a drive like this and get inside it. start to figure out what makes it work for that eventual goal of
making my own firmware This all started as a really crazy idea just before leaving a conference overseas. I had some late night Googling sessions trying to find:
what's the most popular CD burner? how hackable does it look? This one is made by Samsung It's the #1 best seller right now It's $80 Not only was there a good popular burner that had some really good specs With hardly any Googling at all I was able to locate not one but two
firmware updaters So that was great! That's a starting point. You don't really know anything
about this thing other than inputs and outputs. You can find specifications for what the
discs it reads look like and what goes over the USB cable. You don't know what goes on in here so, it's a black box problem. Even if I can't modify
the firmware updates if I can understand how the
firmware updates work That gives me a lot of information about
what goes on inside these drives. This actually all started on the
transatlantic flight back from the conference. I figured out this drive
was a good candidate found these firmware updaters I really like visualizing files Sometimes I'll actually just open up
a binary in Photoshop There's a cute trick you can do with
the PGM file format This old-school "Portable Graymap" Since the header is just text you can just, on the command line create a PGM file with your binary and give it whatever shape you want. So this is what the firmware looks like
in Photoshop. This is pretty much my
first starting point I just arbitrarily chose the width This is just a one-dimensional
chunk of bytes. The first thing you can see even just scrolling through this
in Photoshop There are areas that seem really different if I zoom out you can
see these pretty clearly These white bands are
areas that are all 255 All binary ones Those indicate flash memory
that's been erased. Anything that's all white
has been erased and not programmed. You can tell that when they
assembled this image they chose to break it up
into these specific pieces Two small pieces up here,
which seem to go together I happen to know this boundary right here the end of this larger blank area it's a really round number in binary This is exactly 64 kiB In order to update a system safely, you have to have some part of the system that stays there permanently and
doesn't get replaced when you do updates. That portion is referred to as
the "Bootloader" Early in the reverse engineering process it's a really important thing to identify if i want to understand how this
firmware update process works so I can modify it and put my own
firmware updates in there I need to understand how
the bootloader works enough that I can give it a firmware
update that looks correct. Ultimately it's the bootloader's decision whether or not to transfer control into the firmware I've given it. Down here, this is the actual firmware. You see these patches here there are all these repeating
"finger" patterns Those are aligned words I recognize those from ARM instructions they're always very rigidly aligned Down here, this area is
much lower contrast doesn't stand out the same way these I think might be lookup tables Then you scroll down some more Oh, and this stuff!
This is definitely not code. Maybe weird code like
jump tables or something. Then we see another one of these breaks All ones Somebody intentionally made
a division there and it looks completely different It's lower contrast You see these "finger" patterns
but they're not aligned vertically These are instructions for
a different processor These blocks are two firmware images that I think are for this other
DSP processor and one firmware image for this
other weird processor It's actually an 8051 This really old-school 8-bit processor that's actually still really
common for USB devices It can be really low-power You don't have to license them There's this program IDA, the Interactive Disassembler If these firmware images are just big
complicated sets of instructions binary files that you don't
really understand at all You can start making
"margin notes" on them. "Oh, this looks familiar" "I want to remember what's going on here" You can make a note there, give it a label Then it just mercilessly
cross-references everything You get these little understandings that start building up to
bigger understandings. You start with things you know what a file like this would look like
in IDA when we first open it up. We just have to start from
"ROM Image" which really just means, "This is a file that goes
into memory... somewhere!" that's pretty much all I know. we can do analysis... Here's our first problem We actually have multiple processors The way actually have to do this is isolate the firmware images
for each processor disassemble them all separately in IDA Since the ARM processor is
running the show, we'll start with that. bunch of options... where does this go in memory zero? good guess! there we go! It's really not much better than
a hex editor at this point. We have a bunch of data they're all bytes. We don't really know what they are. We know there is a bunch of code in here we could just... based on Photoshop I guess,
if I point it right about here You have to tell it the value
of this "T" register Whether it should be using
32 or 16 bit instructions This CODE16 directive means from here on it will
assume things are 16-bit it isn't the right place for that to be but I need to start somewhere. Whoa, I've got something! the middle of a function somewhere. Any time there's code, it can assume
the thing after is also code or the thing it's jumping to
if it's a branch at this point it knows enough
to have some fragments of code that are all connected together. But this isn't an entire function even it's just a bunch of fragments of code what I do know is I know where the end of that function is which means I know where I can start
disassembling something new The next function isn't going to start
right after the previous function Instructions are a fixed size you often need to refer to some data that data might be the same
size as your instruction so you can't include the data
in the instruction you have to just put it nearby "literal pool" or "constant pool" constants: values that don't change heaped together into a pool and put somewhere out of the way usually after your function returns This could be another function,
but it probably isn't. could be instructions,
it's kind of hard to tell. I'm just going to pick an address here some ways away, and an even number try interpreting that as code IDA says "command makecode failed"
So eh, no. This is probably actually
just a big lookup table Agh, what a mess. I don't know how big this is so I'm just going to pick another number and try to convert that to code. Ah, that looks like code! That's great. And then that's a branch. When the processor hits this it's going to go… somewhere else! Then the stuff down here
may or may not be code IDA hasn't seen any instructions
telling the processor to go there. So, this could be the end of the function This could be another piece of the
function that we haven't figured out yet The first step in this process is actually
going through here and partly by trial and error,
partly by intuition figure out what's code and what's data This actually starts going really fast
once you find a starting point. It's like if you can find a loose thread
to pull on, they start unraveling. This is actually a literal pool There's a bunch of numbers
that aren't instructions "DCD" is a directive in the
assembly language It means this is just a word of data 4 bytes of data that's not an instruction IDA has noticed that other
instructions refer to these so the really cool thing about IDA is this
cross-referencing. If I'm interested in
this value, let's say... Actually, I know that this number
looks like a memory address so I'm going to tell IDA that this is a
memory offset. And IDA got kind of mad about that I haven't told IDA that memory exists yet These are actually RAM addresses This is a memory-mapped I/O address Errors are actually really useful
in reverse engineering It tells you that something's wrong You start with this assumption that
the thing already works and if there's an error, the
error is in your own understanding. It's actually really nice to add
your own errors to things "Here's where the problem
might have started" and then you can start to figure out
where that flaw in your understanding is. Oh man, this looks like a big function Subroutine! It's identified that
this, in fact, is a function. If I go to graph mode it's traced the control flow
for that whole function. I spent that whole trans-atlantic flight just disassembling the firmware annotating it, adding my own notes trying to figure it out. In that firmware, I know
I can talk to it over USB that's the best foothold I've got
for getting into the system. Once I'm inside, I really want to know
how to communicate back with the computer. I want to know how its USB interface works So after running the firmware updates
a couple times inside a virtual machine with
USB logging turned on I got some log files I could then put into a tool I wrote a couple lifetimes ago,
to analyze data like this. Here the operating system is asking
for USB descriptors strings show up pretty easily they've actually formatted the
serial number incorrectly this is a bug The Windows operating system is
just initializing this like a normal SCSI device. Then you can see the updater app
takes exclusive control over the device so Windows stops doing its usual polling and now the updater has control over it and then the actual update starts. So, there's some commands that
prepare the update Actually, these commands check again to make sure the device
is the right version and then these packets are actually the
contents of the update these bars indicate when a transfer starts
on the timeline, and when it ends The "OUT" packets are from the
computer to the drive as it's updating firmware.
They complete really quickly. Then you see these long pauses This is actually the drive not
getting back to the computer when it asked for a status update These "IN" transfers are
the computer asking "That transfer I just sent you,
how's it going?" Usually these complete really quickly but this one was long and drawn out. This is actually where the device is
programming its firmware drops everything doesn't even respond to the computer waits for the flash memory to program This is the flasher tool that's now part
of the "coastermelt" git repository. If you just run it with no arguments
it will tell you what the disc is This runs a standard
SCSI "Inquiry" kind of "Hello, how are you?" this includes the revision code you can see it has this "TS01" firmware You can use this tool to
install any firmware image It'll start out by sending the device some of these vendor-specific
undocumented comands that say "Hey, I'm about to give
you a firmware image" and the device is like: "Hey cool! Let me write that
into my flash memory." That's actually really common most devices have some kind of
firmware that they run and some kind of memory
that they store it into Most devices have a command you can use
to update that memory They operating system doesn't really know
about these commands they're just between the
application and device so you don't need
administrator privileges to write over the flash memory
on your USB drive you just need a USB device
connection of some sort I'm not even really talking to the
device at a really low level I'm sending it these commands
which are supposed to be for storage but you can use some of the magic SCSI
commands to write to flash memory. Here I've just updated the
firmware on the drive there's no validation
happening at this point the file always just gets
flashed into memory but it will never overwrite that
first 64 kilobytes so it will never overwrite the bootloader The bootloader will somehow check
the rest of that image to see if it looks good before
it transfers control. The first thing I tried was to just
make small modifications to the stock firmware images. Most of the changes I made resulted in the bootloader
refusing to boot the firmware Instead of going into the firmware named "TS01", their revision name for it It would give its version number as "BOOT" indicating that it's just stuck in that bootloader that only knows how to
get new firmware and by disassembling the bootloader
I can see the SCSI commands it accepts They're very limited It has some stubs where
it knows how to say "I don't do that" when you ask it some things So, I started to experiment with this tool to see what I could change
and what I couldn't and then started to cross-reference that
with the disassembly of the bootloader to try to figure out where these
checks were being made. So this is the very end
of the firmware image. It looks like the kind of thing where
if you wanted to put a stamp on your firmware image say "This is what's inside" this is where you'd put it. This first part is a copy of the
same identifying string sent back to the computer when it sends that
"Hi how are you" SCSI command, Inquiry. some other stuff,
I don't know what it means it doesn't really seem to mean much "TS", TSST? some of these "F"s and "A"s I don't know what those are but then these two bytes at the very end One thing that's really really great
about having multiple firmware updates is that you can diff them. Even if you don't really know
what's going on inside that gives you some idea of
what they have in common. This first part is pretty much the same which indicates they didn't
really change the bootloader which you would expect. At the very end there are these two bytes that are different in these
two firmware images That's the only part of this little suffix
that's different. I was able to cross-reference that back
with the disassembly of the bootloader and find where it was checking those In a region of memory
it adds up all the bytes the low two bytes of that If there's an unintentional
change in the firmware this will usually catch it but it's a very weak check and it's not cryptographic at all, if you know how the check is computed
you can always recompute it. I don't want to make a change where if it does let me boot the image,
I end up getting stuck. I want to make a change that gives me
some indication that I've made a change without breaking the firmware I started looking for things
I could easily change like identifying strings I tried to change the version number
of the firmware Nope, still in the bootloader. So I spent a lot more time in IDA This is address hex 0x10400 which is right after
that first 64 kilobytes so, near the beginning of what would be the replaceable part of the firmware. Up here there's some code Somebody intentionally put these
at specific locations in memory so this could be part of the API that the bootloader and the the
replaceable "application" firmware have between each other. has some things that look
like memory addresses, it has some things that look
like random numbers and some of the things that look like
random numbers are different between these two versions. That looks interesting. That's the kind of thing that I
would be looking for if I were looking for
another kind of hash. These individual checks are each 128 bits. I had a lot of guesses about which
registers you put the key into and which… They weren't hashing the entire image,
they were hashing little segments. Before I'd gone to the extreme effort
of making a really thorough brute-forcing tool to find out how the
crypto hardware worked I was taking a walk or taking
a shower or something I realized that the signature table itself
isn't protected by any of the signatures. If the patcher tool that updates the
checksum at the end of the image also just changes the length
of the signature table to zero then it's fine. So at this point I can install
my own firmware images patch them so that the bootloader
will successfully jump into them. Now we need a target. Now that we can change the code, I need to change something that will give
me a foothold to explore the system But it will still be safe something that doesn't
happen automatically on boot something I can disable if I need to. the data is actually coming from the
ARM processor itself and not from a DMA device directly. The SCSI command I could find that
met these requirements was this "Get Performance Data" command. I would run experiments on it to try and figure out what
parts of it were relevant. My strategy for dealing with this mess was to give myself a way
of editing the code and then use that editing tool to start removing everything I could while still preserving that response
back to the computer. When I did this I found a small
set of hardware registers that I could use in the right sequence
to write replies back. Unfortunately it doesn't seem to be a
general purpose reply register there's a lot of state in the
SCSI command processing that's really shared between the ARM
processor and that 8051 8-bit processor. I can't really completely
repurpose a command only from the ARM side,
as far as I can tell. I've written a really
small "backdoor" patch that I can put in firmware it replaces this SCSI command with a
new SCSI command I've created that knows how to read and write memory, call functions. I'm about to install the patched
firmware on the drive using this "make flash" command
in the "backdoor" directory. Now we're inside read and write memory, execute code. I went a little bit crazy with
writing debug tools. I wrote this "cmshell" thing that's part
of my little coastermelt project. an IPython command line that bridges
Python, assembly language, and C++ into this weird interactive debugger. I can just read memory The underscore is short
for this scratchpad area just some RAM that
nobody seemed to be using You could disassemble some code the interrupt vector table The really fancy stuff happens when this tool compiles snippets
of code and runs them from here. I have a console that's sort of a stdout where you can send messages back it works by having a ring buffer in
some unused memory you write messages there and this console polls that buffer you can compile C code there's this "evalc" command
in the debugger compiles it into a little tiny
self-contained program sends it to the drive, and then runs it For example, if I just evaluated "5" that's a really simple one, but I just
compiled a C program that returns 5. I could read memory. There's some bytes. That's fine. There's a variant of this that
automatically opens up the console so you can get results This will just evaluate this print-line Hello World and open up a console automatically. This just compiled the little C program,
sends it to the drive and got its results. I've been keeping some notes
on recipes for this shell There's some fun stuff you can do I want alternate ways of getting input
and output in here. This USB is great, but it means I can't
completely take control over the ARM CPU. I still need it to get the results back If I could forget about USB for a while
and use some other communication channel I can use that to completely take control
over the ARM processor poke directly at the hardware poke directly at the other
CPUs on the system Then I don't have to also contend with
whatever else the ARM firmware is doing inside its main loop and
in its interrupt handlers… There aren't a lot of I/Os on here at least not a lot of easy ones Inside here there's a bunch
of motors, lasers, amplifiers A bunch of great hardware,
but that's all really complicated. I want an LED. The easiest I/O we have is
actually on the front panel. One button, and one LED.
That's exactly what I want. One bit in, one bit out. I started making a lot of tools to try and figure out where
all this hardware was and figure out the flow
of how the firmware worked. I found these little movable
memory regions The firmware itself is in flash memory it actually has some encrypted functions that it will copy into RAM
and then decrypt and then move that entire block of RAM
back over where that function normally was so then it can call it. If I want to trap the CPU when
it gets to a particular point and have it run some of my code,
and then go back to what it was doing I can do that now. This is an address near
the top of the main loop I'm going to reset the target
before starting so we have a clean slate and attach a console Cool, so it's resetting the disk takes a few seconds to boot Now it's hooked If I the longer version
of this hook command I can write a little block of C code This will read from a register that seems
to have the button GPIOs in it. It's casting this number to a pointer,
because this is actually a memory address and dereferencing that pointer
to get some buttons If that bit's zero, I'm going
to run the default hook the built-in function
that displays this stuff It compiled that little block of code If there were any errors it
would have already told me Now that's installed and it's running And the console's spinning This indicates that it's active
and the device is alive but no output If I hold down the button as long as I'm holding it
down, I get output. So, it's like a little oscilloscope. But if we can have some way of
taking this ARM processor putting it in a bubble and just looking at stuff that goes
in and out of that bubble then we can get a much better idea of how
the system as a whole works. Emulators are actually just a really
great reverse engineering tool This is something reverse engineers
working on video game consoles have done for a long time. If you don't understand
how a platform works, you try to run a game. That quickly tells you how to update
your understanding of the platform so you can run the game correctly. I don't want to build an emulator
for this entire drive That involves a whole bunch
of stuff that… If I can pretend to be the ARM CPU, then I know how to program it
to talk to all the other pieces. So I wanted to create an emulated ARM CPU
running on my desktop computer that could still communicate with
the rest of the hardware peripherals on one of these drives. If I'm going to completely take
over the ARM CPU, I can't rely on this USB
connection any more. I need my own way of
talking to the debugger. Okay! That brings me to my current
state of the art, in terms of where this project is at using a small hardware modification to give the device a serial port so I can then switch the backdoor
from the USB interface to the serial interface and then use that serial interface
to perform all the I/O on behalf of an emulated ARM CPU
running on the debug host. In this case, the Python shell. This guy right here: MT1939 which is the System-on-a-Chip that just
does pretty much everything for this. tracking waveforms for the lens it talks to the photodiode amplifier I haven't found so much as a serial bus that communicates between it
and the other chips. The other chips seem to only
do high-power heavy lifting. The one on the right happens
to also control the LED this pin I'm tapping on it is actually
the 3.3 volt LED control signal so that's the serial data going
out through the LED. For the eject button,
the flat cable is annoying to solder to instead I grabbed it from a via
over here by the processor Your favorite 3.3v serial adapter here I also have it connected to a logic
analyzer so I can debug the timing Right now I'm attached to
the device over SCSI can read memory I can run code Now I'm going to use this bitbang command which attaches to a new debug
backdoor over this serial port connection. A bunch of stuff is going to happen This just installed a hook
on the main loop delays the whole process so the
SCSI command the debugger sent can have a chance to finish
before the whole system hangs. Then we're inside this loop that
turns off interrupts and keeps the ARM processor
stuck there waiting for data over this bitbang serial port. Our current debug interface
is this bitbang device So we can read memory We can read more memory,
but it's a lot slower Here's the logic analyzer We can see what that actually looks like Here's the serial data from the
computer to the eject button and here's the serial data from the LED
back to the computer. So I send these little commands they have a bunch of padding,
and some bytes then I get a response with a
bunch of data, and checksums. So, that's cool. I've got a debugger now, and this
doesn't need the USB interface at all. If I can run the boot process
inside an emulator then I can figure out how to
set up these other CPUs and I know how to get from
a completely uninitialized system to a system that can at least
talk to the outside world. If I'm going to make a stand-alone
firmware, that's a good starting point. This "sim" command First step, initialized simulation state program counter zero and then it starts single-stepping It tells me all the instructions it runs Here you can see a stream of all the
loads and stores the processor makes. It's very repetetive loops, clearing memory,
waiting on hardware I have some ideas of where to start
talking to the USB controller but the DSP is still a huge mystery I don't even know what
instruction set it is yet and i'm only guessing at
what it is based on context. There's still a lot to do at this point it's like those
point-and-click adventure games if you ever played Monkey Island
or King's Quest as a kid it's kind of like that, except
it's a very big world and when I get to the end, instead
of just winning the game, hopefully I make holographic
graffiti that everyone can have. Thanks for watching, everyone! If you like it let me know I'll try to do some more of these,
and keep you guys posted. Bye!
I remember the good old days when you had to get rid of the region code or whatever the name was - back then mega-corporations still thought they can control what people do "downstream".
The awkward thing is that I stopped using DVDs excluding burning linux distributions (yes, even more than putting them onto USB). My use case for movies on DVDs is at exactly zero. And before that it was VHS ...
This is jaw dropping
Part 2 - https://youtu.be/U7MTnbXXyVY