[00:03.930 --> 00:13.850]  Hardware Hacking Village. Welcome to Boston's Hacking Underground. Quite literally we are
[00:13.850 --> 00:23.550]  in my basement. Socially distant greetings from down here. Hopefully I managed to secure the
[00:23.550 --> 00:28.030]  location as in there is not going to be any noise and we get a reasonable recording.
[00:29.950 --> 00:35.990]  And that's it. Let's get started. I'm going to take the mask off since you're sufficiently far
[00:35.990 --> 00:42.570]  away. And while I certainly wanted to wear a fork bomb on a mask for a long time,
[00:43.270 --> 00:55.010]  I cannot go for a full hour doing that. So we have 45 or odd slides and the demo.
[00:55.010 --> 01:04.830]  So let's get going. Now, as a way of introduction, I had the privilege of spending my entire career
[01:04.830 --> 01:13.010]  in free and open source software. I am the product management director for Red Hat Ceph.
[01:13.070 --> 01:20.210]  And I was previously Ubuntu server PM at Canonical. And if you go back a decade,
[01:20.210 --> 01:26.850]  I was the dreaded systems management tsar at SUSE. The talk has nothing to do with my job.
[01:26.850 --> 01:32.850]  Well, I guess it is storage after all. I'm a manager these days. So as a former embedded
[01:32.850 --> 01:41.050]  developer, this is my definition of fun. The obligatory disclaimer is that we will most
[01:41.050 --> 01:46.810]  likely break some hardware playing with this. And it will come out of your pocket. No liability if
[01:46.810 --> 01:52.930]  you follow our instructions and stub your toe or bring about the end of the world.
[01:53.210 --> 01:59.550]  Or break your device, which is far more likely. So you have been warned. Let's get going.
[01:59.570 --> 02:03.230]  We have a lot of slides in the demo. We need to hustle a bit.
[02:04.690 --> 02:13.510]  Here is the idea. A processor is found in an SD card. Hackaday featured somebody's blog.
[02:13.510 --> 02:21.890]  Pretty much went viral in a word of web process. Virally blooming once Linux was noticed on the
[02:21.890 --> 02:30.870]  device. And Hackaday made it famous. Lots of blogs. SD card sized. Almost a raspberry pi.
[02:30.870 --> 02:39.010]  Can we repurpose the device? The word of web process really got going once Linux was noticed
[02:39.010 --> 02:47.030]  on the device. And so I noticed all this was going on. And I wanted a project for Christmas.
[02:47.030 --> 02:55.330]  That was five years and a bit more ago. So you could say that it has taken me for quite a ride.
[02:56.970 --> 03:06.410]  Let me repeat that as there is always someone who has no idea what I'm talking about.
[03:06.410 --> 03:12.310]  Here is the concept. A Wi-Fi enabled SD card. Automatically downloads your pictures.
[03:12.470 --> 03:18.970]  Several models exist. We're after the embedded system in there. In the card. The CPU of the
[03:18.970 --> 03:24.650]  card itself. It's like the Intel Edison they originally promised us, but for real this time.
[03:26.390 --> 03:30.770]  Copious amounts of Google Translate were used in the making of this talk.
[03:30.770 --> 03:38.250]  Really international effort. I saw blogs in French, Japanese, German, Korean, and of course
[03:38.250 --> 03:45.670]  English. Some Russian too. And I believe some Spanish. So copious use of Google Translate
[03:45.670 --> 03:52.930]  and in singularity of course. We explored the limits of machine translation, but it usually
[03:52.930 --> 04:03.450]  comes across clear enough to work with. So we're looking at the Trescend Wi-Fi SD line here.
[04:03.450 --> 04:11.790]  It comes in size from 8 gigabytes to 32 gigabytes. I prefer them as they are more open, even without
[04:11.790 --> 04:17.850]  hacking, as there are no attempts at platform strategies made by adding any middling cloud
[04:17.850 --> 04:25.210]  services that we do not want by some clever MBA that had a platforms class. There is no
[04:25.210 --> 04:32.250]  stepping stone service that may make things easier to set up. And doesn't. And adds yet
[04:32.250 --> 04:37.630]  another place your pictures are potentially in. The software on the Trescend card is simple
[04:37.630 --> 04:46.010]  and not perfect, but that is an asset for us as we will see. So where do we get these cards?
[04:46.010 --> 04:49.150]  You can go to Amazon. You could also try eBay.
[04:50.810 --> 04:57.310]  And they're going to be between $40 and $60 depending on capacity, about the price of
[04:57.310 --> 05:05.910]  Raspberry Pi and up. There are others like the PQi AirCard that are functionally the same.
[05:06.190 --> 05:12.670]  The PQi AirCard is interesting because it is actually an adapter card. You can put any storage
[05:12.670 --> 05:19.170]  you want in microSD format in there, and the adapter actually has the embedded system. Toshiba
[05:19.170 --> 05:26.250]  makes another one, and there is also the Flu card. And you can carry binaries through them.
[05:26.410 --> 05:33.110]  As a matter of fact, when you log into the system, you may notice that there is a command
[05:33.110 --> 05:41.010]  buzz in there. But there is no piezoelectric transducer here, so what is that for?
[05:42.490 --> 05:51.110]  But looking at another one of the card designs, that has a piezo. So you can learn things on one
[05:51.110 --> 05:58.010]  card that applies to another. But we're getting a little bit sidetracked here, so let's go back to
[05:58.010 --> 06:04.290]  where we should be. When the postman arrives, here is what you get.
[06:05.330 --> 06:15.050]  Inside the package, let's unbox one here, a card and an adapter. The inevitable legal disclaimer.
[06:15.590 --> 06:20.330]  I don't think this conference has a legal track, otherwise I would blame the lawyers.
[06:21.130 --> 06:26.130]  And a microscopic bit of a manual, which is actually not bad.
[06:26.130 --> 06:32.830]  The adapter is there because you can write to the SD card directly by mounting it on your Mac,
[06:32.830 --> 06:40.290]  for example, or over the radio. And when you have file systems mounted two places,
[06:40.290 --> 06:48.350]  and you are writing from two places, bad things happen. The adapter signals to the card to disable
[06:48.350 --> 06:55.490]  the radio, and prevents simultaneous writes from the air and local mount. Of course, that is exactly
[06:55.490 --> 07:01.150]  what we want to do. But we think before we do. We only want to use the radio,
[07:01.150 --> 07:09.190]  so we'll assemble it so it is actually not turned off. So just what is in there?
[07:11.030 --> 07:19.930]  This is an SDHC class 10 card. 16 gigabytes in the case of the ones I used.
[07:19.930 --> 07:32.090]  Half and double the size exists. This is a full-size SD card. Pictured is model TS16GWSDHC10.
[07:33.050 --> 07:37.170]  You will have the slides at the end, so if you want to search for the cards,
[07:37.170 --> 07:41.110]  you'll have all the models. There is no need to take notes or any of that.
[07:43.330 --> 07:49.910]  So physically breaking the device voids the warranty. I bet you did not see that one coming.
[07:52.430 --> 07:58.110]  Exacto-knifing our way to success, we slice the card in two and find four large chips.
[07:58.430 --> 08:04.390]  Interesting. The parts on the left are the case. Nothing strange there.
[08:05.150 --> 08:12.670]  It may help guide your dissection if you need to open one, but that's about it. Incidentally,
[08:12.670 --> 08:18.870]  do you see the yellow tab in the center? That is the write-protect switch cards have.
[08:18.870 --> 08:25.090]  Interesting technical detail. There is nothing on the device reading the state of that toggle.
[08:25.550 --> 08:30.670]  The reason for this is that SD cards work like floppy drives.
[08:31.770 --> 08:36.010]  And in floppy drives, if you still remember those devices,
[08:36.010 --> 08:41.870]  write-protect is implemented by the drive. If the drive sends a write, the card will take it.
[08:44.210 --> 08:55.270]  If the card doesn't know and doesn't have to, the drive will not send a write if the toggle is in
[08:55.270 --> 09:02.610]  the protect position. So let's do a bit of overview of the components from the top left.
[09:02.610 --> 09:09.810]  We have a trace antenna, definitely not a 3 dB antenna and not 100 milliwatts of broadcasting
[09:09.810 --> 09:17.730]  power as the whole card consumes less than that. So Wi-Fi range will not be as per the
[09:17.730 --> 09:23.630]  Wi-Fi specs maximum. But that's okay because we're still beating the pants off Bluetooth.
[09:24.270 --> 09:31.240]  There is no antenna connector. You could try your hand at adding one if you're a master at soldering.
[09:35.030 --> 09:39.790]  But assuming you don't, you're not going to get the full Wi-Fi range.
[09:39.810 --> 09:46.670]  And I'm okay with that. Then we have the Wi-Fi radio chip.
[09:47.810 --> 09:52.450]  The SoC with the ARM CPU we are after is underneath it.
[09:53.570 --> 10:01.290]  16 gigs of flash in the big chip. And the flash controller is the last thing on the right.
[10:02.270 --> 10:08.090]  And up top we see the notch where the read-write tab rests that I was mentioning.
[10:08.730 --> 10:12.850]  And there is no actual board sensing of any kind as I said.
[10:12.850 --> 10:16.490]  The card is just making room for the tab to fit in that space.
[10:17.870 --> 10:26.850]  Flip side. Besides the standard SD leads, some of the smaller pads are TX and RX for a 3.3 volt
[10:28.030 --> 10:33.570]  38400 baud serial. Annoyingly, really annoyingly, they are not labeled.
[10:34.330 --> 10:40.710]  They labeled resistors we don't really give a hoot about instead for who knows what reason.
[10:41.430 --> 10:49.550]  On the PQI air card, the TX and RX serial pads are labeled. So bonus points to those guys for that.
[10:50.370 --> 10:55.530]  If you do wired serial, you get access to a well-configured U-boot console.
[10:56.190 --> 11:00.670]  U-boot is the bootloader of choice for embedded Linux devices for those of you coming from
[11:00.670 --> 11:09.150]  Windows. A very handy tool to have. Better than the kernel that is in here as it has been stripped
[11:09.150 --> 11:15.650]  to the bone. Incidentally, I have been collecting all these details for a survey article. If you
[11:15.650 --> 11:21.750]  hack the card and blog the details, let me know. Send me the link. And you prefer going... if you
[11:21.750 --> 11:29.990]  prefer going the lazy way, you will get a how-to from me soon. Hopefully. I've been saying this
[11:29.990 --> 11:40.240]  for a while, but it's almost done. What's in there are these four chips. CPU, Wi-Fi module,
[11:40.240 --> 11:48.400]  flash controller, and storage. The SoC's 32 megabytes of RAM is the weakest spot of the board
[11:48.880 --> 11:55.500]  but very suitable for embedded use. Fear not those of you who are used to gigabytes of RAM.
[11:55.500 --> 12:01.060]  Besides, you have lots of storage. You could expand this with swap.
[12:01.400 --> 12:10.520]  If the kernel was built with support for swap. In the SoC, 8 megabytes of NOR flash are used
[12:10.520 --> 12:18.380]  for system including a stripped down kernel and compressed initramfs. Interesting compromises
[12:18.380 --> 12:25.260]  were made there. And of course, massive amounts of storage. So you could boot with a small system
[12:25.500 --> 12:32.540]  loop mount a larger image and shroot into it. If you had loop mount in this kernel,
[12:33.020 --> 12:41.180]  I start seeing a pattern here. But not all is lost. We can add it. Dimitri Greenberg has documented
[12:41.180 --> 12:46.280]  how to rebuild the kernel. So we have the instructions and the steps on how to do this
[12:46.280 --> 12:55.480]  already worked out. Let's look at the CPU. It's a 200 megahertz CPU. Some report 400 megahertz and
[12:55.480 --> 13:08.960]  they are wrong. They are confused by the 426 bogomips it sports. It's an ARM 926 EJS core.
[13:09.640 --> 13:18.540]  An ARM 9 processor. This is not a Cortex A9, but an older ARM 9. A low cost CPU.
[13:19.040 --> 13:32.040]  ARM 5 TEJ architecture with more than 5 billion with the B manufactured to date.
[13:32.080 --> 13:38.560]  Interesting extensions for Java, but the Giselle runtime requires talking to ARM as it was not
[13:38.560 --> 13:46.240]  shipped with the system. And anyway, who wants to do Java these days? So interesting core.
[13:46.920 --> 13:54.320]  The extensions. E stands for DSP, Digital Signal Processing Enhancements,
[13:54.320 --> 14:00.080]  because this processor used to be used for making feature phones.
[14:00.640 --> 14:09.960]  J for Java extensions or the Giselle JVM. Java extensions make byte codes directly usable by
[14:09.960 --> 14:17.160]  the CPU, which is really cool. The CPU instruction BJX branch to Java instruction,
[14:17.160 --> 14:26.160]  which switches the silicon to Giselle state. The JVM still handles errors. The OS handles the traps.
[14:26.160 --> 14:36.580]  But between 134 and 149 byte codes of the 203 in the JVM spec are handled in silicon. I don't know
[14:36.580 --> 14:45.940]  why the variation there. Why not a fixed number? But a large chunk of the byte code is running in
[14:45.940 --> 15:04.060]  hardware. Now, the original Raspberry Pi is a Broadcom BCM2835 processor. An ARM11 76JZF-S.
[15:05.220 --> 15:13.300]  This is an ARM6K architecture. It's closer to this processor than it is to a Cortex ARM.
[15:13.520 --> 15:20.180]  So the idea is that instead of the chip in the Pi, you would use the chip in the card.
[15:20.240 --> 15:28.220]  With different trade-offs. You get built-in radio, lose all the interfaces. The price stays just about the same.
[15:29.320 --> 15:42.660]  The radio is a Fortune chip. AFN31GL Wi-Fi controller. It comes with an Atheros AR6003
[15:42.660 --> 15:49.900]  Wi-Fi core, which was marketed as the smallest Wi-Fi silicon design you could buy at the time.
[15:50.400 --> 15:55.940]  I don't know if they still have the record, but it was a pretty impressive claim five years ago.
[15:55.940 --> 16:04.940]  The bit we care about is that it does Wi-Fi B, G, and N with really low power draw.
[16:06.220 --> 16:12.400]  Do not plan to saturate the Wi-Fi Ethernet link with this device. You won't go much beyond one
[16:12.400 --> 16:19.280]  megabyte per second. Incidentally, if you feel like going turtles all the way down, there is a CPU to
[16:19.280 --> 16:28.420]  control the baseband radio. An Extensa MIPS core backed by 256 kilobytes of RAM and 256 kilobytes of
[16:28.420 --> 16:35.260]  ROM. I didn't go in there. Maybe it could be the next project for one of you.
[16:36.180 --> 16:43.000]  Also, this chip does not do Bluetooth, by the way. Not that we care.
[16:45.140 --> 16:51.520]  Then we have 16 gigs of NAND flash. You will not be wanting for storage. That's for sure.
[16:51.520 --> 16:55.040]  That is definitely not the problem the system has.
[16:56.400 --> 17:00.180]  The flash controller is a Silicon Motion 26...
[17:05.000 --> 17:12.900]  I can just read the slide. 2683EN. Thank you, picture. Nothing of interest here except
[17:12.900 --> 17:17.460]  there was a bit of annoyance in the community at the lack of redistributed sources
[17:18.060 --> 17:24.500]  for some system components. Transcend resolved this. It's no longer an issue.
[17:24.500 --> 17:30.500]  But one of the modules is proprietary. The one that supports the flash controller.
[17:31.440 --> 17:39.700]  If you're familiar with IP restrictions for source code of video drivers, that is probably a similar
[17:39.700 --> 17:46.180]  reason. There is some secret sauce that the vendors of flash want to keep to themselves and
[17:46.180 --> 17:55.480]  not share with one another. We don't know what it is. But it's not really a concern for us unless
[17:55.480 --> 18:04.230]  you are an open source legal purist and you want everything in the open out of principle.
[18:05.790 --> 18:10.550]  The sources... I mean the sources for some of the modules are available. The binaries for all three
[18:10.550 --> 18:14.650]  modules are available. So if we recompile the kernel we can just drop the modules back in
[18:14.650 --> 18:19.670]  and go on from there. It's not like we're going to modify our interface to the flash
[18:20.450 --> 18:25.510]  to the flash chip anyway. We're not interested in that.
[18:27.430 --> 18:40.170]  Now, this card clocks between 0.9 and 1.1 watts while idle in my office. It peaks at 1.5
[18:40.170 --> 18:47.330]  with wireless clients connected. This is a 110 volt power supply of course.
[18:47.530 --> 18:53.490]  An Apple switched power supply. Efficient but still power conversion is a factor.
[18:53.490 --> 18:59.850]  Presumably higher if you push the CPU to 100% while writing to flash.
[19:02.090 --> 19:07.210]  You could also try to push consumption by simultaneously pegging the CPU and massively
[19:07.210 --> 19:13.570]  writing to flash. I got my numbers by exercising the radio only. I didn't do a full suite of
[19:13.570 --> 19:20.930]  benchmarks at different types of load. This is a relatively lightweight system so I didn't see the
[19:20.930 --> 19:29.590]  need to push the envelope that far. Interestingly, I checked to see if we would get better efficiency
[19:31.430 --> 19:39.070]  through eliminating the power conversion step. And we hardly see a difference.
[19:39.070 --> 19:49.530]  220 milliamps is about 1.1 watts at 5 volts. Same as we measured at 120 for idle.
[19:49.530 --> 19:55.910]  It closely matches the other one. Apple really knows what they're doing.
[19:55.910 --> 20:00.230]  That iPhone switched power supply is really efficient. Good for them.
[20:02.050 --> 20:05.470]  Let's start looking at the software side.
[20:06.890 --> 20:16.870]  I'm going to walk you through what we do to make it work first and how we hack it second
[20:16.870 --> 20:22.530]  so it's not hanging in the void and confusing in as to how we got there.
[20:22.530 --> 20:27.910]  How does this all work? First you set up the app on your phone.
[20:29.270 --> 20:36.610]  Then it gives you access to basic setup and core functionality. Setting up network mode,
[20:36.610 --> 20:42.610]  names, password. Shoot and view here means putting the phone in a monitor mode of sorts
[20:42.610 --> 20:47.010]  where any picture shot by the camera is automatically downloaded
[20:47.710 --> 20:52.750]  and presented on the screen with no intervention. This will be important later.
[20:54.470 --> 21:00.770]  It also offers you to upgrade the firmware. Usually this is a concern as that precious
[21:00.770 --> 21:07.430]  security hole used for routing may disappear. But it's not so in this case. It does not matter
[21:07.430 --> 21:13.270]  what version of the firmware you have, you're going to get around it. So do not worry about it.
[21:13.270 --> 21:22.290]  The latest version is as open as the first. It is both good and bad, I guess. I say it is good.
[21:22.290 --> 21:27.990]  It lets us hack the card. Security issues we bring about are not in the hacking of the binary
[21:27.990 --> 21:35.210]  support package. But we'll get to that later. By default, the system wants to be its own access
[21:35.210 --> 21:42.930]  point. Great, very convenient for development. But not so for photo download. Think of it, you want
[21:42.930 --> 21:50.310]  to switch APs on your handheld device every time to sync pictures. The seamless internet AP client
[21:50.310 --> 21:57.010]  mode is a great strength of this card for ease of use compared to others that make it needlessly
[21:57.010 --> 22:03.430]  more complex by putting their service in the middle. You just choose the mode you want and you get it.
[22:05.350 --> 22:10.210]  So when it is up, it shows here from another machine in the same room.
[22:10.650 --> 22:15.990]  Your SD card has now become its own access point. Okay, what's next?
[22:17.330 --> 22:21.990]  Well, now we can connect to it just like you would anywhere else.
[22:24.030 --> 22:34.060]  And now we can ping it just like any other host. Now let's look at how it works before we get into
[22:34.060 --> 22:42.740]  it. Think about it. The app needs to find where the heck the card is. It is out there on the AP,
[22:42.740 --> 22:52.620]  but at what IP address? The card broadcasts on UDP 55777. I'm here, I'm here, I'm here.
[22:53.300 --> 23:01.560]  Other cards are even more aggressive. They ARP the entire slash 24 subnet, found out where every
[23:01.560 --> 23:10.320]  node is, then send HTTP requests to everyone until it finds the card. Then maybe it stops.
[23:10.320 --> 23:16.360]  Most of the time it does anyway. Don't worry, we can fix this. It's just funny to me.
[23:16.780 --> 23:24.680]  The tools are only needed for initial IP discovery and password setup. If you do not want to use them,
[23:24.680 --> 23:34.360]  the card comes with a default user admin with a password of 1, 2, 3, 4, 5, 6, 7, 8.
[23:35.020 --> 23:37.660]  But that's not the part that will make you laugh.
[23:39.420 --> 23:44.920]  We port scan the card to see what's going on here. Here we see Telnet because I already
[23:44.920 --> 23:52.400]  cracked this one. The HTTP server, the pictures are published there. The app just
[23:52.920 --> 23:59.860]  HTTP gets them. Services are offered as CGI scripts out of the web server. That's how the
[23:59.860 --> 24:07.440]  app commands the card to do things. The additional port 5566 broadcasts new entries in shoot and view
[24:07.440 --> 24:14.140]  mode. If you're connected there, you get a new URL message for every picture. That's how shoot and
[24:14.140 --> 24:20.900]  view works. You get one line with URL of new pictures when they're generated. Very simple
[24:20.900 --> 24:28.820]  architecture. Not bad. A few quirks. It downloads pictures twice. A bit suboptimal that way, but
[24:28.820 --> 24:35.920]  in this way it doesn't have to spend CPU power to generate thumbnails on board. Trades a little
[24:35.920 --> 24:44.280]  of bandwidth for not having to spend CPU and power. It also assumes that you're not downloading
[24:44.280 --> 24:50.200]  multiple pictures at once, which you're not. So simplicity prevails. I'm a fan of that type of
[24:50.200 --> 24:59.960]  design. We can browse the card's HTTP server directly. It's a boa web server. It exposes
[24:59.960 --> 25:06.920]  directory listings. In theory, it should show you only the directory listings of the data.
[25:07.500 --> 25:15.560]  And simple CGI bin scripts to set configuration. These are in Perl. App simply downloads the files
[25:15.560 --> 25:23.800]  via HTTP and calls CGI scripts to configure the system. And these scripts are way in. That's how
[25:23.800 --> 25:33.550]  the card was broken into. So this story starts with Pablo, who thinks there must be a CPU in
[25:33.550 --> 25:39.590]  these Wi-Fi enabled cards and turns out that he is right. Pablo went out and started poking at the
[25:39.590 --> 25:47.770]  software, looking for security holes. Find several the size of a small barn. Found dot dot slash dot
[25:47.770 --> 25:55.890]  dot slash backpats breaking out of the allowed inspection area. He extracts the source files
[25:56.490 --> 26:06.690]  for the CGI bin, exploits a Perl script, and in he goes. And I went that way myself the first time.
[26:06.690 --> 26:19.430]  But there is a better way. A file called autorun.sh. I think you know where this is going.
[26:20.670 --> 26:29.190]  Write a file to the SD card named autorun.sh. The system will read it and execute it.
[26:29.190 --> 26:37.130]  With root privilege. At boot. So all I have to do is just go, telnet please,
[26:37.130 --> 26:44.290]  and telnet arrives. So much nicer. Now, the security freaks among you will be horrified.
[26:44.290 --> 26:49.250]  But in terms of actually working with the card, this is fabulous. It makes it so nice.
[26:49.490 --> 26:55.430]  There is another aspect to this that is humorously named.
[26:57.490 --> 27:03.850]  I know what you're thinking. But that's not it. It stands for firmware update.
[27:04.290 --> 27:13.870]  It's a clever mechanism. You supply autorun.sh and three files. The kernel, the program bin.
[27:14.330 --> 27:20.250]  The system starts program bin. Turns out this is a copy of the cards you boot with the default
[27:20.250 --> 27:27.210]  script payload. The script loads the new system onto the old and then reboots. It's a nice way
[27:27.210 --> 27:33.070]  to prevent breaking. It also resets all configuration to the defaults, which may be handy if you screwed
[27:33.070 --> 27:39.030]  up. It is a really nice way to revert breaking and also gives you a way back to the defaults.
[27:39.310 --> 27:44.450]  But obviously you can only undo software breaking. You can still break the hardware.
[27:53.770 --> 28:00.190]  It's time to try and do this live. I usually unbox one of these.
[28:02.170 --> 28:10.890]  But in a virtual setting it doesn't really make it very useful. And you have seen the pictures,
[28:10.890 --> 28:17.890]  so you've seen most of what there is to see in an unboxing. I had to find... so let's set it up.
[28:18.650 --> 28:24.090]  I had to find an SD adapter that does not switch off the radio.
[28:25.490 --> 28:32.290]  So I went to my local computer megastore and bought every single adapter in existence,
[28:32.290 --> 28:42.070]  tested them all, returned 9 out of 10. And now we have the right thing.
[28:49.050 --> 28:55.750]  And this thing boots really fast. So much so that if I connected over the serial,
[28:55.750 --> 29:01.350]  it would be up before I can connect to it. You would not see boot messages.
[29:03.090 --> 29:07.030]  It will just be there already.
[29:09.770 --> 29:23.190]  So... and we got the advertisement.
[29:25.370 --> 29:34.350]  And we are connected. We got a connection. Now I was connected to that card recently,
[29:34.350 --> 29:42.030]  so let's just do it this way. And see? It got there way before me.
[29:44.930 --> 29:52.570]  What are we going to see here? Let's start from version text.
[29:54.610 --> 30:04.210]  So the KeyASIC Wi-Fi SD is the ODM design that all these vendors purchase to make their own products.
[30:07.790 --> 30:08.570]  And
[30:11.170 --> 30:24.050]  you can see that it confirms the 802.11n Wi-Fi. The Linux kernel is 263228,
[30:25.140 --> 30:33.870]  one of our most popular Linux kernels ever. This one was in RHEL 6. It was in SUSE Linux Enterprise
[30:34.970 --> 30:43.090]  11 SP1 in a breaking of continuity from 11 kernel rebase.
[30:43.090 --> 30:51.050]  And I believe it was in Ubuntu Server 10.04, although that one wasn't mine,
[30:51.050 --> 30:54.230]  so don't quote me on that, but I'm pretty sure.
[30:56.790 --> 31:04.570]  This is the kind of kernel that you would want to run when you have only 32 megs of RAM, so
[31:04.570 --> 31:13.990]  it's a very, very good choice. It will not be expecting gigs of RAM either in this form or in
[31:13.990 --> 31:21.890]  userland. What else? Well, let's see what's around here.
[31:30.470 --> 31:44.250]  We want to see something else, actually. This is the actual VFAT system of the SD card.
[31:44.250 --> 31:49.990]  And you can see that I plugged it into a Nikon digital camera that left its own fingerprint
[31:49.990 --> 31:59.390]  there and a few files that I've been poking around with. BusyBox is notable here. We could
[31:59.390 --> 32:06.210]  run that BusyBox and have a much more futureful shell environment, but I want to show you here
[32:06.210 --> 32:13.730]  how the card is rather than how we are going to make it. The making part we can defer to a writeup.
[32:14.730 --> 32:19.370]  But yeah, very easy to replace the shell by just downloading a BusyBox and executing it.
[32:23.650 --> 32:30.170]  Incidentally, once you have a new BusyBox, you can run the NTP module and
[32:30.870 --> 32:37.410]  not be in 2012 anymore, which is great because then you can do proper secure connectivity,
[32:37.410 --> 32:44.750]  not plain text telnet. And now that your certificates are not coming from the future,
[32:44.750 --> 32:51.750]  crypto will actually work. What do we have on the storage side?
[32:54.090 --> 33:03.850]  So you see the JFFS2 file system that is the 8 megabyte partition that the system boots from.
[33:03.850 --> 33:12.510]  That is the reason why things have been stripped down so much. It is tiny. Now I'm not an embedded
[33:12.510 --> 33:18.870]  developer anymore. In my time, JFFS2 was the most popular file system for embedded Linux devices.
[33:19.030 --> 33:25.430]  This device is about 7 years old in design, so I don't know if that has changed. But
[33:26.030 --> 33:33.330]  it's nice to see familiar things. Let's see what's in
[33:33.330 --> 33:49.130]  in mtd. Oh yeah, you can see the labels. So mtd0 then spi-flash-nor, that's the 8 megabytes.
[33:50.630 --> 34:10.440]  Okay, then we have Perl. 5.14, not bad. Not an ancient single digit version.
[34:10.440 --> 34:16.520]  So that makes this potentially a system that you can develop on out of the box.
[34:17.580 --> 34:22.480]  Let's see what is running on it. We have
[34:31.470 --> 34:34.380]  the Telnet that we started.
[34:35.370 --> 34:42.750]  And we have two of the UDP-SVD processes. These are the ones that do the
[34:43.820 --> 34:47.600]  the broadcasting process that I described earlier.
[34:48.820 --> 34:53.470]  We have the Boa web server that's providing HTTP support.
[34:54.330 --> 34:59.250]  And we have a dynamic DNS advertisement.
[35:01.110 --> 35:10.190]  We have a DHCP server because in access point mode we have to serve out DHCP addresses to clients.
[35:12.210 --> 35:16.230]  The bodyguard process is the one that disables the radio
[35:16.230 --> 35:23.450]  when you plug the card into an SD card slot so that there is no double write.
[35:26.180 --> 35:30.940]  And that's about it. Let's see what do we have here.
[35:37.730 --> 35:43.510]  We already discussed the kernel version. We can see that it was compiled with sorcery
[35:47.290 --> 35:53.190]  on an Ubuntu machine. It's funny what kind of details you leak out.
[35:56.310 --> 36:02.150]  What else? What else? What else? We're gonna skip the message. It's too messy.
[36:09.930 --> 36:18.610]  So we discussed pretty much the CPU extensively already. You see that I got
[36:19.650 --> 36:26.090]  the CPU series right. And yeah, the 421 Bogomips that I was mentioning before.
[36:26.090 --> 36:31.030]  Not 400 megahertz. Just delay cycle is 421.
[36:34.630 --> 36:48.430]  We can also look in here. This is the one that makes me cry. So here we could really use
[36:48.430 --> 36:56.750]  some loop mount and some swap. But we can put them back in. So no crying.
[36:56.750 --> 37:04.390]  One last thing. We can list the network interfaces of an SD card just because it
[37:04.390 --> 37:10.210]  seems so wrong that we can pass up the opportunity to do it. And we discover absolutely nothing,
[37:10.210 --> 37:16.670]  but it's kind of fun to say that you have done it. So why not? Now...
[37:18.490 --> 37:32.500]  Okay. Back to the slides. Now be careful. The system mounts the flash partition under
[37:34.760 --> 37:39.820]  mount SD. And accessing the file system from the card's own Linux,
[37:39.820 --> 37:44.560]  while an external host is doing the same, could easily corrupt the file system.
[37:44.560 --> 37:52.780]  Two live systems writing to the same host. No good. You can easily fix it by rebuilding the
[37:52.780 --> 37:57.080]  file system. But you need to be aware of the problem so that you don't do it in production.
[37:57.100 --> 38:03.360]  Development is just fun and games. But in production, that's not the way to go.
[38:03.360 --> 38:13.560]  So what software do we have to play with here? In version 1.7 firmware,
[38:13.560 --> 38:22.300]  we have a kernel 2.6.32. The modules, the kernel modules are for the SoC,
[38:22.300 --> 38:28.900]  the Atheros 6003 radio, and the SDHC interface, which, as we discussed, is proprietary.
[38:30.760 --> 38:38.040]  Your services that you can have out of the box are basically a very stripped-down busybox that
[38:38.040 --> 38:46.340]  has Telnet, FTP, and DHCP. Busybox is a little bit crippled, but once you replace it, you can set
[38:46.340 --> 38:52.980]  up SSH as soon as you can set up time properly. And this is very easy to do. It's just one
[38:52.980 --> 39:00.780]  execution away. So, easy fix. On the kernel side, the kernel is extremely thin due to the need to
[39:00.780 --> 39:07.200]  fit in the 8 megabyte NOR flash in the SoC. But we can load components from the larger storage
[39:07.200 --> 39:13.620]  once we have a system running. Ideally, loop mount a file in FAT32 to avoid corruption.
[39:14.040 --> 39:23.640]  Add swap to work around RAM. Truth to pivot into loop mount. We need a new kernel to do this,
[39:23.640 --> 39:29.620]  and Robert figured out how to unpack the install files. And then Dimitri rebuilt the kernel by
[39:29.620 --> 39:38.340]  looking at KSIMs. Since the .configure file is not exposed in PROC,
[39:38.340 --> 39:43.320]  some people could think it's secrecy, but I think it's, again, saving space.
[39:44.280 --> 39:51.920]  So, how this would work. Would create on the live partition as a single file a system image.
[39:51.920 --> 39:58.920]  Would loop mount this and truth into it. Now, somebody took this to the extreme.
[39:59.620 --> 40:05.680]  Why do people always do this? So, they downloaded an Ubuntu 9.x image.
[40:05.680 --> 40:12.840]  The last version of Ubuntu compatible with ARM5 architecture. Put the image in there on the SD
[40:12.840 --> 40:21.840]  card. Loop mounted. Truthed. Forwarded X. Started Firefox. And then complained that it was slow.
[40:23.400 --> 40:28.320]  Okay. Well, it's not that interesting to run Ubuntu from 10 years ago.
[40:28.320 --> 40:34.460]  But it's pretty cool that one can take it that far. It's nice to see that the bits actually work
[40:34.460 --> 40:42.860]  and can be stretched. But we don't need to do things that crazy. Where there is Perl,
[40:42.860 --> 40:50.260]  there is everything, I like to say. Maybe Perl is not your cup of tea, but it's better than not
[40:50.260 --> 40:56.980]  having it. This is ARM. You can cross compile. You can build on the system. You can use IPackage.
[40:56.980 --> 41:02.560]  You can bring your own language. You can steal packages from another device of the same
[41:02.560 --> 41:08.160]  architecture since there are five billion of them. But if you want to be lazy, Perl is a perfectly
[41:08.160 --> 41:15.660]  viable option. And this is also a reasonably recent Perl. It's not Perl of the ancients
[41:15.660 --> 41:24.600]  like a Perl 5.6. It's 5.14. Big question for embedded devices is how we find them.
[41:25.110 --> 41:29.580]  Where is my device? And we need to make it safe for the internets.
[41:31.210 --> 41:40.640]  You cannot use this device if you cannot tell what IP it's at. So there are three approaches
[41:41.270 --> 41:49.580]  that are common to work this problem. One is a known configuration. Always be at the same address.
[41:49.580 --> 41:56.360]  This is what I just did. When the card is in AP mode, it is always at the same address.
[41:56.480 --> 42:07.320]  11.254. I know where it is. I do not need to find it. Then there is what the card does natively.
[42:07.400 --> 42:14.840]  Broadcast. It advertises where it is. Besides the horror I described earlier, there are proper
[42:14.840 --> 42:22.020]  advertisement protocols like MDNS. Multicast DNS is a perfectly fine way to discover things
[42:22.020 --> 42:29.220]  on the local network. The third one is to announce, which is the device itself,
[42:29.220 --> 42:35.440]  once it has a valid network configuration, sends out an announcement. My favorite is to send out
[42:35.440 --> 42:41.720]  an XMPP announcement, meaning a Jabber protocol announcement. But you can use any protocol you
[42:41.720 --> 42:48.140]  want. And you know this is a unicast announcement, not a broadcast one like the horror I was
[42:48.140 --> 42:55.000]  describing earlier. It is going to a single endpoint and it's a fair game. No messing up
[42:55.000 --> 43:00.840]  of the network. I'm not going to go through all of these. There is an article I wrote for
[43:00.840 --> 43:08.120]  Linux Journal in 2009, I believe. Search for my name and Linux Journal. And there are scripts.
[43:08.120 --> 43:15.320]  They are implementing all of these for this architecture, in fact. You can go and just grab
[43:15.320 --> 43:23.580]  the scripts. They are in the article. You can also do this right. If you're a standards person,
[43:23.580 --> 43:30.160]  like some people rightly are, and in this case doing it right means implementing DNS update
[43:30.900 --> 43:39.600]  as specified in RFC 2136, which I suffered through implementing a few years ago, actually.
[43:40.580 --> 43:47.720]  Contact me by a fixed DNS name. I will update that DNS record when I boot so that it's always
[43:47.720 --> 43:53.820]  correct for my current device location. This is also implemented in my Linux Journal article.
[43:53.820 --> 44:00.460]  You can do it in 15 lines of Perl or less. So Perl may be hard to read sometimes, but it's
[44:00.460 --> 44:06.780]  very, very expressive and it's very nice for this purpose because there are modules to do anything.
[44:07.760 --> 44:13.200]  So let's go back to the security aspect. We were joking about the fact that it was easy to break
[44:13.200 --> 44:21.280]  in, but realistically we have physical access. We have the card and we can do things to it.
[44:21.280 --> 44:29.930]  We can also do it over Wi-Fi. Fine, that is less kosher, but that hardly matters.
[44:30.240 --> 44:35.130]  What matters is that this brings the lost USB key attack to a new level.
[44:35.780 --> 44:41.080]  In a military base, people are trained to shoot on sight when they see a lost USB key.
[44:41.700 --> 44:49.360]  But in an industrial setting, people are more lax. So picture this out of a Tom Clancy book.
[44:49.360 --> 44:56.520]  You need to break into somebody's network, you lose a USB key in their parking lot, and some
[44:57.600 --> 45:03.680]  good Samaritan-fool will take it inside the office and plug it into the wrong machine.
[45:04.220 --> 45:06.920]  I don't think I need to tell this audience this.
[45:08.180 --> 45:13.120]  So what's new here is the Wi-Fi aspect, of course.
[45:14.280 --> 45:20.080]  Although there are a few devices that do this, like HAC-5 has some devices that
[45:20.080 --> 45:26.310]  do exactly this. But in this case, it's in SD card format with a radio in it, which is interesting.
[45:29.060 --> 45:33.260]  Countermeasures are no different from the rogue access point ones.
[45:33.580 --> 45:40.520]  From radio jamming or your network actively nacking connection requests very cleverly
[45:40.520 --> 45:47.500]  for unknown access points in a broadcast range. Or if you have a security
[45:49.380 --> 45:57.820]  policy against lost USB keys by locking down or pouring glue into USB and other ports,
[45:57.820 --> 46:03.220]  you can pour glue into SD ports just fine and prevent people from sticking things into ports
[46:03.220 --> 46:09.220]  they are not supposed to use. Neither approach is new. Sure, the card is not super secured,
[46:09.220 --> 46:14.320]  but remember your security posture needs to be commensurate to your threat assessment.
[46:14.320 --> 46:19.240]  You are not a nuclear reactor. If you were, you need to account for this.
[46:19.440 --> 46:24.800]  But if the question is the security of your Instagram pictures, do people want them that badly?
[46:27.230 --> 46:31.970]  So your mileage may vary. What is on the opportunity side is that this is a low
[46:31.970 --> 46:38.870]  power system with vast amounts of storage and wireless connectivity. And really low power,
[46:38.870 --> 46:42.490]  as in you could power it with a solar panel and put it up a tree.
[46:43.670 --> 46:49.470]  This is the ideal pirate box data exchange. A pirate box being the term of art for anonymous
[46:49.470 --> 46:55.110]  data exchange, where people drop and retrieve files over Wi-Fi anonymously. I don't think it's
[46:55.110 --> 47:02.130]  as popular as it used to be once as a concept. This is in practice a spy's dead drop,
[47:02.130 --> 47:08.270]  if you want to use the Intel community's comparison, if you want to continue that
[47:08.270 --> 47:16.070]  line of thought. Less ominously, you can make a solar-powered geocache. But seriously,
[47:16.410 --> 47:22.750]  you can now realistically put a server in your wallet or even make a server throwaway
[47:23.750 --> 47:29.490]  or a Beowulf cluster in a shoebox, although I would recommend you do not do that.
[47:30.070 --> 47:35.170]  You could put it in the SD slot of your car radio, if you have one of those old ones,
[47:35.170 --> 47:40.450]  and make it download music whenever you park at home. There is one limitation.
[47:41.070 --> 47:47.790]  SD cards are supposed to have SPI interfaces, and that would be awesome, because SPI means
[47:48.830 --> 47:56.830]  Arduino. But sadly, this is not viable with this card. That won't work. Somebody tried
[47:57.610 --> 48:04.410]  the integrated system. It was bigger than the card itself. I mean, the support for SPI to
[48:04.410 --> 48:10.150]  access Arduino was bigger than the card itself. Not practical. But this is nonetheless a very
[48:10.150 --> 48:16.050]  interesting platform to experiment with. Cross-compiling is an option, but you can
[48:16.050 --> 48:21.610]  take the lazy way out and prototype with Perl. I solved the discovery problem for you. You have
[48:21.610 --> 48:27.910]  all the scripts. And this is a very low cost. Same cost as the original Raspberry Pi. So you
[48:27.910 --> 48:34.370]  have to decide if you want to trade RAM for very low power and small format, or the other way around.
[48:34.470 --> 48:40.910]  And it's a fair question. It's a very niche hacking platform. Trascend has been very nice
[48:40.910 --> 48:47.690]  to the community. Sorry, it's a very nice hacking platform. Trascend has been very nice to the
[48:47.690 --> 48:55.790]  community. We broke this years ago and they haven't complained. They haven't sued anybody.
[48:55.850 --> 49:01.890]  They haven't shut us out or done anything untoward. We get hardware to play with. They sell more
[49:01.890 --> 49:09.530]  hardware. It's great for everyone. The mechanism we used is part of the SDK, but the SDK is not
[49:09.530 --> 49:15.630]  public. So we had to discover it the hard way. We need a better distro image than the crap you
[49:15.630 --> 49:21.130]  have seen. I've worked on too many Linux distributions to stand for that. But that is
[49:21.130 --> 49:25.650]  relatively easy to do and there are some tools out there that are workable already.
[49:27.630 --> 49:31.890]  I think we can do better, but it's adequate to at least experiment.
[49:33.410 --> 49:37.830]  So if you come up with new ideas on how to use it, please send them to me.
[49:37.830 --> 49:43.810]  Here is my contact info. You can find me on Twitter or send me email. Or you can find me
[49:43.810 --> 49:51.590]  in the Discord channel and ask me questions there. Remember that speakers are Pavlovian devices,
[49:51.590 --> 49:57.070]  so if you like the talk, please let us know. Rate the talk, send us comments, submit feedback,
[49:57.070 --> 50:04.330]  all of those things as you see fit. If you do something with it, let us know what you did so
[50:04.330 --> 50:11.170]  we can spread the news. Slides will be available and I'm available for questions if you have any.
[50:11.170 --> 50:16.310]  Thank you and stay safe. Happy hacking!