 Uh, welcome to track one. It's a 430 talk. Uh, this is Nicholas. It is his second, second time speaking. So there'd be no shots involved. Sorry. Um, anyway, give him one welcome. Thank you. Alright, so the title of this talk is Spoking the S in SD cards. Uh, when I started this I was wondering why SD stands for Secure Digital. So there might be something secure, right? But exactly how it works because it's just a simple memory card you put in, you place your files and that's it. Oh, ah, yeah, sorry. Oh, yeah, way better. Sorry. Okay, so SD stands for Secure Digital. I was asking why is Secure 4? Uh, this is not a physical attack so everything is only about the protocol that is using by, that is used by the SD cards. So the first step is beforehand what is an SD card? Everybody saw an SD card, of course. Um, it's basically a microcontroller which interface the SD interface with a flash memory. Uh, if you want more information you can see there was a, there's a great talk by Bonnie and Ksobs, uh, that was, uh, at the CCC, uh, where he decapped, uh, the SD cards. He showed exactly how it works from the inside. But we are not doing exactly this. We are going to play with, uh, the communication protocols. And basically those cards do support three different communication protocols. The SPI, classic SPI communication. The SD or UHS-1 protocol which uses more data lines so the transfer speeds are way better. And there's a newer one, maybe you didn't see it, uh, you don't see that often. It's the UHS-2 which has way more, uh, connectors, a second row of connectors. And it uses different shunt lines to, uh, to transfer even, uh, faster, uh, data. So, uh, to get access to the, uh, specifications and to know exactly how it works from the inside, uh, I can, you can go to the SDCards.org website. They, they, uh, offered, uh, some general specs in simplified form. The document is only 262 pages so it's quite easy to read, right? And it presents the general description on how to interact with SD cards but, uh, uh, at a really low level. For instance, this is the initialization sequence. I won't go into the details, don't worry. It's just that there's a lot of different comments and depending on the type of cards, uh, his generation, you need to send comments, maybe the card will not respond, then you have to do another thing, then maybe it will respond that is a new valid comment so that means it's a third kind of card. So, yeah, it's a bit messy but once you read and, uh, poke with it, you, you, you cannot get some resp- replies back to from the card. So, this is good. So, uh, I won't go into the details of all the PDF, just so you know that the protocol is basically a query and response, uh, protocol. So, as the master saw the, the device, your computer, sorry, you send a comment, then the card will respi- will reply back, back with more information. Uh, for instance, uh, there's the CMD zero. This is the first comment you need to send to the card. It will basically, uh, re-initialize the, its status and it will reply with a, okay, I'm here. So you know that your card is available. Uh, there's a communication protocol. It's using, uh, six bits for a comment. Then you need to send up to 32 bits of arguments. There's a CRC and some bits. Good thing is that in the SPI mode, the CRC, you, you don't need the CRC in the SPI mode so you can just put all zeros and that's fine. As I said, the protocol is a bit a mess because depending on the comment, you have seven different response formats. So sometimes it's only eight bits that you receive by a back. Sometimes it's 32 bits. Sometimes, uh, it just sends an ad knowledge, then it sends a packet back. So every comment has to, uh, has to, has its own parser to, to parse the, the reply. To communicate with the, uh, uh, to communicate with the, the, the memory or the file, the files within the card, uh, four bytes is not that much. So there's also a block transfer mode where basically you send first, uh, uh, block start comment, which is just 0xfe. And then you run, uh, you send all your data. Then, uh, you need to send the CRC. And then the card will, will process, uh, the information. There's no length checking by itself. By default, it's 512 bytes. But you, uh, you have a comment, which is the comments 16 that allows you to change the data size. So, now that I know exactly, well, not exactly, but now that I know how it works, uh, as I looked for all the security features of the cards. So the first, uh, one that shows up is the SDMI, uh, uh, specifications, which is, uh, unfortunately not the, the, the purpose of this talk. Because it's only, uh, all the documentation is only available to SD members. And there's no way to, uh, get this file. Except if you try to google it, because apparently it has been indexed and it's, it can be downloaded directly. Uh, but there's also another way, another, uh, possibility to protect your data from the card. And it's available to two commands, which allow to set a password on, on the card. So when you enter the, when you set the password, the next time you place the card in it, you cannot read anything from it unless you provide the password again. Then the card would be unlocked. And with this, uh, once it's unlocked, it's acting exactly like a normal SD card. Also, those commands, uh, those specific commands, uh, for the, uh, password protection are mandatory to, to get the SD label. So basically nearly every card, uh, every SD card on the market supports those commands. But it's not used by any operating system I know. So, so what I did? Basically, uh, just using my laptop to send command was not really, uh, easy to do. So I used, uh, a div, uh, an hydro bus device which is kind of a bus pirate clone. And I did, uh, uh, small python script to drive the, the SPI bus and to be able to send a row commands to the device. So basically here's the setup. I have the interface there. I communicate with it in USB. And I send command and then there's the SPI communication going through this. And you have the SD card adapter right here. So how does it work? You have the CMD 42 command which is, uh, his command name is lock and lock. And it's, uh, it allows you to set, uh, password up to 16 bytes long. I say bytes and not characters because you're not limited to printable characters. You can set any byte you like. So the key space is, uh, of, uh, 128 bits. So kind of, kind of a lot. And it's, it's difficult to, it's, or nearly impossible to brute force. It will be, take way much time. So the command takes, uh, different parameters. Uh, basically it's just, there are some bits that you can, uh, set to the card. And they will, uh, trigger different functions. So basically you have the set and reset passwords. You have the clear password. So if you forgot your password, you can use the clear bit to make the card reset. So it will wipe the flash and then the card is, uh, unlocked again. You have the lock and unlock command. So at first, uh, I used it, uh, to try to lock the card and, uh, to unlock it, you actually have to set the bit to zero. That's kind of strange. You can also erase the password once the card is unlocked. And the COP is, uh, is a new mode that I will talk about later. So how to unlock exactly an SD card in practice? You have to send this CMD42 command. Then, uh, the data block with the lock bit unset. The password bytes, uh, a CRC, which is, uh, uh, useless, but you have to send it. And then the card, the, the, what will the card do? It will, uh, set, uh, its data outline to the ground. While it's processing the password, and once it's done, the line will be up again and you can read the status of the card. Funny thing is that if the card is, uh, sending you a command that it's busy trying to, uh, analyze your password, what you can do is something quite fun. I placed it here. You can see, uh, this is, uh, logic analyzer output. So you can see here it's the command I sent to the card. Here's the, here, sorry, is the password block. And here is the response from the card. So you can see that the line is put down to zero for some time while the card is, uh, processing my password. So I did put a password of one, two, three, four, five, six. And if I zoom in this part here, if I zoom in, you can see that when I put a password length of five characters, it will take approximately 55 microseconds to process. And if I put six characters, it takes a bit more time to process. So, basically, what happens is that the SD card, the password checking functions is, uh, vulnerable to a timing attack. And you are able to verify that, uh, the password has the correct length based on the time it takes to, uh, reply. So you try to send a password with, uh, the length one. It takes some time, two, it takes some time, three, maybe it takes more time. So you know that the password is, uh, of length three. And then it will try to, uh, check every character one after the other. So you can basically brute force a byte per byte and recover the password from the SD card. Sorry. So, having all those schematics and taking all those, uh, measurements by hand is not really easy to do. So, since this information here, the, the fact that the data, the data line is at zero, um, what I can do is basically use my SPI interface and try to read as much bits as I can. And since all those bits will be at zero, I can count them and I will kind of know how many time it took to, uh, to, uh, to check the passwords. And once the, once I detect a one, again, so once it's finished, I know that the length is, uh, the computation is over and I can do something. In practice, what does happen? I did, uh, this small script here and if I set the, uh, my famous password 1, 2, 3, 4, 5, 6 and I run my script, you can see that for password lengths of zero, it took, uh, it read, uh, 122 zeros before the card was, uh, uh, available again. For one, it read 124 zeros. And at length six, you see it's the only one which was a bit longer, so you know that the correct length is six. I have a demo which unfortunately is not live. So what I do here is I initialize the card. I can get its status, so for now it's unlocked. I will send the lock command with the password I will set. So I put my famous password 1, 2, 3, 4, 5, 6. I will check the status of the card. It's in locked mode now, so I'm not able to read data from it. I will receive an invalid command and there's no data from the card. What did I do? Yeah. So now I can run my brute force tool. So it will track all the different, uh, password lengths to find the correct value. It says that's okay. And then it will try every byte combination to try to find my password. So it takes a bit of time. And then it brute force the last characters. And once my card is unlocked and I try to read the data, I can get data from the card. So once I have my card which was working, I was quite happy of course, but I was thinking so maybe there are more cards that have the same problem. So I bought different SD cards. I went to the store. I bought some cards from different vendors, different sizes. Uh, I also asked colleagues and friends to, to lend me their cards just to, to have a look of it. And guess what? The only card I, I locked permanently, I was, I still don't know how to unlock it. Basically it's broken. It's, uh, uh, colleagues of mine, not, not one of my cards unfortunately. So I did lock all those cards with the 1, 2, 3, 4, 5, 6 passwords and I tried my brute force again. And it sometimes worked. It sometimes didn't. And sometimes there was some funny results. So for instance, I get some, uh, Sony SD cards. And it has, let's say a protection on the brute force which, uh, makes it, uh, refuse the CMD42 command after the third failed attempt. That's quite good. The only thing is that you, uh, just need to send one, uh, command zero. So you just reset the card by the interface and then you have three more tries. So it's just a bit, uh, it's just a bit, uh, longer but not that much. The Sony US micro SD cards also, uh, have something different where basically I was not able to, uh, read the zeros. So I know that there was something but I was not able to read it because it was really, really, uh, fast. So I tried with a logic analyzer. It was still not fast anymore. So not fast enough. So I went to, uh, a colleague of mine and, uh, uh, borrowed a huge oscilloscope. And I'm able to sample way faster and then I'm able to see the really small difference between length five and length six. Five, six, five, six. Don't see it. That's normal. But yeah, you can still do it. It's just, uh, a bit more complicated. Uh, there's also, uh, something strange in, in, on Kingston SD cards where I was able to find, to, to find the, the, the password lengths but then I couldn't find any, uh, I couldn't brute force the, every, uh, byte. So I did some tests again and basically what I did was, uh, I set up the oscilloscope again, put, uh, five zeros, then six zeros so I can find the length. That's fine. Then I set the first byte, the first byte to be correct. Second one, third one, still nothing. And at the fourth one, you'll see a time difference. So what happens is that, uh, this card checks the password by groups of four bytes. So I would assume that the microcontroller inside is a 32 bits one. So it's, uh, bits different. So the, the attack is still doable but you have to brute force, uh, by groups of 32 bits. So in my results, uh, I have all those cards, uh, please be, be careful about, about what's written here because this is the, this is the, the name that is written on the card. But inside of the card there's a, not, it might be another manufacturer that's created the chip, you know. So, uh, the name is not correlated to the manufacturer of the card. So this, uh, current might not be that useful. This one is more, is more. You can see those cards. Uh, and this information, the manufacturer ID is, uh, sent, is sent by the card. And unfortunately there's no, uh, public source of information about, uh, which ID corresponds to which, uh, manufacturer. So you, you can find some of them on the internet but for some of those like this one, I just don't know who made it. Also, all those cards were bought this year. So we are in 2019 but the production date on the card is around 2010 or 2011, something about this. So again, this is a value taken from the card. I'm not sure it was, uh, it's the real production date. It's just the data that is in, uh, inside the, of the, the card. Nearly all of those were vulnerable. The only one that, uh, I was not able to, uh, use is the, the, are the SanDisk models. And I was not able to use the, the Samsung cards because when I tried to use the CMD42 command, the card responds with an invalid command. So I don't know how they got the, the logo but it's, it's working. Uh, so to conclude, uh, I would say it's pretty useless vulnerability because no operating system supports, uh, this password locking function. Hopefully because it was not that useful. It also affects a lot of manufacturers. Uh, and good thing to do is, yeah, read the specs. There are a lot of information, a lot of, uh, things and things you don't expect from a card, right? Also, as a future work, uh, as I said, there's the, the COP function. Basically, it's a, you can set a password to protect, uh, the card, uh, to, uh, to password protect the password clear mechanism. I don't know why it's that, but there's a, this is a new feature. I was not able to get a card that works with, uh, that has COP enabled. So maybe I will try to find and, yeah. Maybe there's also another vulnerability on those. So a few takeaways. Uh, SD cards, uh, just have a password protection. As we said, uh, most of the cards, uh, are vulnerable to a timing attacks. Uh, and that's pretty much it. Thank you. Oh, uh, by the way, if you want to have a live demo, uh, I will be, uh, after the talk, I will go to the hardware hacking village so we can do the Q and A there and having a live demo. Thank you.