Coastermelt Part 1 - scanlime:001

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments

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 ...

👍︎︎ 7 👤︎︎ u/shevy-ruby 📅︎︎ Oct 28 2021 🗫︎ replies

This is jaw dropping

Part 2 - https://youtu.be/U7MTnbXXyVY

👍︎︎ 6 👤︎︎ u/GenilsonDosTrombone 📅︎︎ Oct 28 2021 🗫︎ replies
Captions
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!
Info
Channel: scanlime
Views: 13,434
Rating: undefined out of 5
Keywords: reverse engineering, firmware, laser, blu-ray drive, coastermelt
Id: UTUYl-2g-r4
Channel Id: undefined
Length: 31min 6sec (1866 seconds)
Published: Wed Jan 20 2016
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.