[00:57.540 --> 00:59.860]  All right, I think we are going to go ahead and get started.
[00:59.860 --> 01:07.930]  So, practical protocol hacking, it's what we're going to be doing today.
[01:07.970 --> 01:08.850]  Thank you for joining me.
[01:08.850 --> 01:09.930]  I know it's late.
[01:10.510 --> 01:12.550]  I drew the last slot of the day.
[01:12.550 --> 01:15.150]  I'm standing in front of you guys and a casino party.
[01:15.150 --> 01:18.690]  So, I won't keep you here too long.
[01:19.090 --> 01:21.030]  Probably not going to use the full time.
[01:23.890 --> 01:28.070]  And turn the thing on.
[01:29.610 --> 01:31.850]  That's the biggest glitch I'm happy.
[01:33.670 --> 01:35.830]  My name is Luciano Moretti.
[01:35.830 --> 01:38.290]  This is my third year presenting at CypherCon.
[01:38.430 --> 01:45.270]  Last year I did a general overview of how I go about reverse engineering protocols.
[01:45.490 --> 01:51.950]  And this year I decided I am going to go practical with the badge from last year.
[01:52.670 --> 01:55.550]  I work for Verve by Rockwell Automation.
[01:56.330 --> 02:04.490]  We're part of Rockwell that helps companies inventory their industrial devices, figure out what they have on their network.
[02:04.910 --> 02:10.110]  Part of this is we need to figure out how to talk to all those devices to get the information we want.
[02:10.110 --> 02:13.870]  Like serial numbers, make, model, firmware versions.
[02:14.490 --> 02:16.670]  Sometimes that's easy in their standard protocols.
[02:16.670 --> 02:22.910]  A lot of times they're the custom configuration protocols for the devices.
[02:24.830 --> 02:26.310]  So, what are we going to do today?
[02:28.430 --> 02:34.790]  We're going to look at how to go from a basic device and getting it to understanding how to talk to it.
[02:35.530 --> 02:42.130]  In order to do that, we need to understand the device itself, what it does and how it works.
[02:43.370 --> 02:45.530]  Gain access to its communications.
[02:47.750 --> 02:53.790]  We need to gather data about the communications and how the device reacts during the communications.
[02:54.910 --> 02:59.570]  And finally, once we have the data, we need to analyze it and break down the protocol itself.
[03:00.810 --> 03:03.450]  Now, before we get started, a quick word on safety.
[03:03.870 --> 03:09.670]  When you're working with any unknown hardware, you always want to be careful of the voltage levels.
[03:11.130 --> 03:17.010]  Now, the badge last year, we had three AA batteries.
[03:17.290 --> 03:19.450]  No large capacitors on it.
[03:19.450 --> 03:22.150]  We're looking probably 4.5 volts about.
[03:23.470 --> 03:31.190]  And also, while Michael is known as Monster, I'm pretty sure he's not going to let the toy makers make a stun gun badge.
[03:35.300 --> 03:40.160]  So, how many of you out there have one of the badges, the digital badges from last year?
[03:40.160 --> 03:41.120]  And we're here.
[03:41.120 --> 03:43.100]  Okay, I see a lot of people without hands up.
[03:43.100 --> 03:47.260]  So, we're going to go through what exactly the badge was.
[03:49.980 --> 03:53.040]  So, the primary goal of the badge was to get points.
[03:53.040 --> 03:55.540]  And there were several ways you could add to your point total.
[03:56.200 --> 04:00.420]  The first, you could press a button and it would do a slot machine spin.
[04:01.260 --> 04:03.680]  And if you landed on green, you'd get earned points.
[04:04.240 --> 04:08.380]  Now, each badge started with just a few green icons.
[04:08.700 --> 04:09.980]  The rest were red.
[04:10.600 --> 04:15.800]  So, you really wanted to add more icons to your badge to improve your chances.
[04:16.780 --> 04:22.720]  Now, the way that you did that was by interacting with other badges.
[04:23.280 --> 04:25.980]  You'd find someone who had an icon that you wanted.
[04:27.100 --> 04:35.920]  You'd hook up a link cable between the two badges, select the icons you wanted to trade, push some buttons, and then the icons would trade.
[04:36.540 --> 04:45.260]  In order to get more icons available to the entire pool, there was one icon on the badge that was a sticky icon.
[04:45.380 --> 04:48.800]  And when you traded it, it wouldn't actually trade away from you.
[04:50.820 --> 04:59.260]  Now, the other thing that happened when you interacted with another badge for the first time is you gained a small amount of points.
[05:03.940 --> 05:09.020]  So, each unique badge you traded with, you'd get that small amount of points.
[05:09.380 --> 05:13.220]  And there were six different badge colors for the different levels of badges.
[05:15.620 --> 05:24.540]  And so, interacting with a higher level badge, say a lifetime badge, would give you more points than just a general attendee badge.
[05:25.060 --> 05:33.400]  There was also a secret number of points that if you got it on your display and showed it to the toy makers would end up earning you a lifetime badge.
[05:37.950 --> 05:43.450]  So, when I'm looking at a device, the first thing I do is try and understand what hardware we have.
[05:43.710 --> 05:47.890]  In the case of the badge, we have a pretty basic display.
[05:47.970 --> 05:53.830]  We have a six-digit, seven-segment LED display with decimal places.
[05:54.970 --> 06:05.670]  And we have had a three-column translucent grid with tricolor LEDs underneath them with a slot machine overlay.
[06:09.890 --> 06:16.250]  The processor behind it last year, unlike this year, was a PIC16F, which is an 8-bit microcontroller.
[06:17.570 --> 06:21.150]  And for inputs, we had three buttons.
[06:21.150 --> 06:24.530]  A pick button, a spin button, and a send button.
[06:25.790 --> 06:34.930]  And finally, we had the link port, which was a 3.5-millimeter TRS or tip ring sleeve, commonly known as a headphone jack.
[06:35.590 --> 06:38.810]  And the sleeve on these are usually ground.
[06:39.930 --> 06:45.210]  You might remember these from the eras of Walkmans, Discmans, and iPods.
[06:49.480 --> 06:55.160]  Once we understand the hardware, the next step is to understand the functions of the devices.
[06:55.600 --> 06:59.760]  What it does, what its behavior is, and what we expect to see.
[07:00.020 --> 07:03.320]  So the badge last year had three main modes.
[07:03.960 --> 07:12.820]  A default flashy screen screensaver, the slot machine mode, and the trade functionality mode.
[07:16.170 --> 07:20.770]  This is the flashy screen, which is basically our base screensaver.
[07:20.770 --> 07:24.370]  It looks cool when the badge is not doing anything else.
[07:25.430 --> 07:29.230]  We get the display of the con name and our point total.
[07:30.310 --> 07:35.230]  And if we press the buttons, if we press the pick, it goes to trade mode.
[07:35.530 --> 07:37.810]  Spin does the slot machine spin.
[07:38.330 --> 07:41.490]  And if we press send, there's no apparent change.
[07:42.290 --> 07:48.090]  So does anybody have any ideas on what communication we'd expect to see over the link port here?
[07:48.090 --> 07:49.210]  Any ideas?
[07:51.110 --> 07:57.630]  More basic, like what would the badge be doing on this screen?
[07:57.630 --> 07:59.410]  What functionality of the badge itself?
[07:59.410 --> 08:01.950]  Not necessarily the protocol.
[08:07.810 --> 08:11.790]  Sending an ID, that could be a thing.
[08:11.790 --> 08:14.330]  It could be broadcasting its point total.
[08:15.950 --> 08:19.450]  Not a whole lot that you'd expect at this point.
[08:23.330 --> 08:25.430]  Oop, I hanged the button the wrong way.
[08:27.670 --> 08:31.250]  The second major functionality was the slot machine spin mode.
[08:32.370 --> 08:37.070]  You'd press the spin button in the middle, and then it would do the spin.
[08:37.090 --> 08:40.210]  Based on where it landed, the point total would change.
[08:41.730 --> 08:46.670]  Now once again, we need to think about what functionality the badge might want to communicate here.
[08:47.510 --> 08:52.450]  Are there any ideas of what it might communicate here, or want to communicate?
[08:55.020 --> 08:59.040]  A success or failure result of the spin, whether you earn points or not.
[08:59.940 --> 09:01.340]  Any other ideas?
[09:07.390 --> 09:11.030]  Whether the lights are lined up or not, that could be something you'd want to see.
[09:13.540 --> 09:16.080]  Oop, I got to advance.
[09:17.160 --> 09:24.620]  So as far as expected communications, honestly I don't really expect much here, because this is a single badge function.
[09:26.000 --> 09:29.640]  You don't have the link port usually hooked up when you're doing this.
[09:30.060 --> 09:36.480]  And if you did have the link port hooked up, usually you didn't see anything happen on the other badge when you did this.
[09:38.440 --> 09:45.580]  The other major functionality, and this is the main two badge functionality, was the pick and send buttons.
[09:46.320 --> 09:51.380]  So you connect the two badges together with the TRS cable.
[09:55.530 --> 09:59.930]  The users would press their pick button to select their green icon.
[10:04.220 --> 10:12.560]  And then they'd press the send button, and it would trade the two icons between the devices.
[10:12.560 --> 10:23.600]  Now as I mentioned earlier, there is a sticky icon on the badge, and also we would trade points between the two badges on the first time they interacted with each other.
[10:24.040 --> 10:27.320]  Now different badge types had different values.
[10:27.940 --> 10:36.340]  A basic 10D badge was a 10 point, and then all the way up to 100,000 points for a lifetime badge holder.
[10:42.840 --> 10:45.480]  And I keep forgetting to advance my slides.
[10:51.440 --> 10:58.580]  So this is a functionality where we see badges interacting with each other and things happening between them.
[10:58.680 --> 11:02.800]  What kind of things would we expect to see communicated between the badges here?
[11:07.540 --> 11:09.260]  A badge ID?
[11:10.020 --> 11:10.680]  Yep.
[11:15.930 --> 11:17.630]  The icons that we're trading?
[11:17.630 --> 11:20.010]  Yep, that would be something else that you'd really want to know.
[11:20.790 --> 11:22.470]  Anyone have any other ideas?
[11:24.470 --> 11:25.270]  What?
[11:26.350 --> 11:27.630]  Point values?
[11:28.450 --> 11:29.590]  Yep, that could be something.
[11:29.590 --> 11:31.030]  I don't think I have that on here though.
[11:31.030 --> 11:32.110]  That's a good one.
[11:32.390 --> 11:38.340]  The type of badge you're trading with?
[11:38.700 --> 11:41.600]  I think that kind of goes with the badge ID.
[11:43.240 --> 11:53.800]  Other common things that we'll see in packets often we'll see commands.
[11:53.800 --> 11:58.580]  Saying what the badge is telling the other device to do.
[11:59.380 --> 12:01.000]  Checksums, yep.
[12:01.260 --> 12:14.360]  If you're not familiar with checksums, they're small numbers that are computed using the data in the packet to check to make sure that there are no errors in the transmission.
[12:20.420 --> 12:25.140]  Subcommands, in a more complicated program, that would be something I would expect to see.
[12:26.720 --> 12:30.440]  Oftentimes you'll see a header or a start bit of some sort.
[12:30.440 --> 12:33.480]  Some way to say that your packet is starting.
[12:37.540 --> 12:45.480]  Other potential common things is a length field to tell the other device how much data they should expect to see.
[12:46.940 --> 13:08.360]  And I don't necessarily expect to see it in this protocol because it's expected to be a simpler protocol, but protocols that work with devices that do multiple things at the same time often will include a sequence number in it to allow for out-of-sequence processing or messages that get delayed.
[13:08.360 --> 13:09.600]  Now
[13:12.890 --> 13:19.810]  , to access the signals and analyze them on the TRS port, we're going to need some tools.
[13:20.630 --> 13:27.630]  And my favorite tool when dealing with a physical wire is a logic analyzer.
[13:31.290 --> 13:54.190]  Now, when I did this at CypherCon last year, I used nicely a logic analyzer, which it's a great tool, it's powerful, it has a very nice capture rate, and a really nice software suite to work with, but I was called out on this because its price puts it a little bit out of range for most people who don't need it all the time.
[13:55.290 --> 13:57.290]  So, we're not going to use it today.
[14:02.600 --> 14:05.640]  Yeah, they do have a... oh, no, I haven't looked at the discount codes recently.
[14:05.640 --> 14:08.540]  They do have a good hobbyist and student discount.
[14:08.960 --> 14:10.540]  Last I knew it was like 50%.
[14:13.480 --> 14:14.560]  Okay.
[14:16.360 --> 14:23.180]  What we are going to use is this, which is a Cypress FX2LP based logic analyzer.
[14:23.760 --> 14:27.760]  Depending on where you get these from, they're much more reasonably priced.
[14:27.960 --> 14:34.260]  You can pick them up fairly cheap on Amazon, or if you want to wait for the boat from China, even cheaper.
[14:35.620 --> 14:40.000]  And for the software, we're going to use PulseView.
[14:40.280 --> 14:46.560]  This is a free graphical front end to the Sigrock package that does the actual capture.
[14:47.840 --> 14:56.180]  Now, here we're most likely looking at a serial signal, so you could potentially use something like a tie guard or a bus pirate, if you have one of those.
[14:58.360 --> 15:11.780]  Other tools we're going to use, since it's a physical cable, we're going to use wire strippers to get access to the actual copper, and a multimeter to verify some things.
[15:12.180 --> 15:16.320]  Mostly continuity, to make sure our wiring is all set up correctly.
[15:18.300 --> 15:23.840]  We're going to need some jumper wires to hook from the device to the logic analyzer.
[15:24.840 --> 15:35.880]  And last year when I did this, I used the little clips that came with my Celia, and they worked, but they're finicky and kind of frustrating and have a tendency to slip off.
[15:35.880 --> 15:42.360]  So, today I'm going to do this using Wego lever nuts.
[15:43.020 --> 15:47.420]  Now, these are great, as they're way overrated for our usage case here.
[15:47.420 --> 15:50.800]  All the way up to like 300 volts, 20 amps.
[15:52.080 --> 15:58.280]  But they're really nice, because they can clamp and unclamp really quickly from a wide variety of wire sizes.
[15:58.300 --> 16:06.740]  They're rated down to 14 gauge wire, and you can go a little smaller than that, just with a little less holding force.
[16:10.600 --> 16:24.660]  So, as I said, last year at CypherCon I used the little clips, and I did it by just stripping the sections of the wire very carefully without cutting all the way through, and vampire tapping on with my little clips on the exposed wires.
[16:24.660 --> 16:28.540]  Well, as I said, it's very finicky.
[16:29.760 --> 16:32.620]  You have to worry about shorting the wires.
[16:32.620 --> 16:35.600]  So, we're going to build a wiring harness.
[16:39.040 --> 16:44.160]  So to do this, we first cut the wire, the TRS cable in half.
[16:54.950 --> 17:04.330]  It's a good point that using the multimeter, test the continuity on the cable to make sure it's a straight through, not a crossover cable.
[17:04.370 --> 17:08.350]  I think I had that on the slide in my notes, but I just skipped over it.
[17:08.850 --> 17:18.450]  So once you strip a TRS cable, you're left with either three wires, or in this case it was two wires and a bare copper.
[17:19.830 --> 17:26.770]  So you twist the shield copper together and you're left with the three wires.
[17:28.370 --> 17:37.770]  And when I do this, I usually start with the largest size and work my way down, because you don't want to damage the individual wires on the inside.
[17:39.950 --> 17:45.410]  Then, once you need to strip the individual wires and clear your copper,
[17:56.440 --> 18:03.400]  now we're left with the three individual wires and we can use our lever nuts.
[18:04.260 --> 18:14.820]  And so you use the lever nuts to just simply lift the tab, slide your wire in, and close it all the way, make sure, and then give it a little pull test.
[18:14.820 --> 18:25.840]  Now these are bus connectors, so you put the same color wire into the same lever nut, and so we'll end up using three lever nuts total for this cable.
[18:35.850 --> 18:43.110]  Now, once you've got all three of your wires in, we need to add in the jumper wires to connect up to our logic analyzer.
[18:44.170 --> 18:53.810]  Same basic procedure, I cut the jumper wires in half, strip the copper, and you insert them into the third slot on the lever nuts that I've selected.
[18:56.570 --> 19:04.330]  Those wires will then end up connecting up to the logic analyzer and allowing us to tap into the signal while still connecting two badges.
[19:14.100 --> 19:22.440]  And just for safety sake at the end, I stacked them up and taped them to make them easier to handle.
[19:22.880 --> 19:36.580]  The last thing you want when you're in the middle of doing an acquisition is to bump something and have the wires come out or something else to happen and you lose your signal, so a little electrical tape goes a long way.
[19:42.340 --> 19:47.020]  You need to test it, and this is where the multimeter comes in really nicely.
[19:47.800 --> 20:10.800]  There's a continuity center setting on it that I'm using the resistance here because I don't have sound, but you can verify that you don't have any short circuits between the different parts of the cable and that your tip and your ring and your sleeve are still connected straight through.
[20:18.150 --> 20:28.090]  Finally, we need to use the multimeter to do the same thing between the TRS jack and the individual leads that we're going to connect to our logic analyzer.
[20:28.510 --> 20:35.310]  This is a little fiddly, but this also tells us which wires are our tip, which are our ring, and which is our sleeve.
[20:35.310 --> 20:44.090]  In this case, my harness yellow is the tip, red was the ring, and black was the sleeve for my logic analyzer.
[20:46.750 --> 20:49.170]  And then we have our completed wiring harness.
[20:53.240 --> 21:00.120]  We can connect it up to our logic analyzer as you can see here and it has the ports available to connect up to two badges.
[21:01.380 --> 21:07.160]  Then we need to set up our software setup so we can do our data capture.
[21:10.660 --> 21:18.900]  So, to start off, I connected the badge to it to do a capture and it went into trade mode and just pressed send.
[21:19.060 --> 21:23.440]  And if you look closely there, you can see we captured a little blip.
[21:24.720 --> 21:28.120]  Now, this blip isn't very useful in and of itself.
[21:29.300 --> 21:32.520]  So, the next step is to set up a decoder.
[21:34.740 --> 21:36.660]  We're going to use a UART decoder.
[21:42.620 --> 21:49.220]  So, you have to right click on it and choose your channels and assign it and then it will attempt to decode the data.
[21:49.220 --> 21:54.080]  Now, the data there doesn't look great, it's not right, because our baud rate was wrong.
[21:54.800 --> 21:57.480]  So, you have to change your baud rate to the correct baud rate.
[21:57.480 --> 21:59.280]  How do you know the correct baud rate?
[22:00.140 --> 22:03.980]  Well, last year I just kind of guess and test, trying common ones.
[22:03.980 --> 22:08.320]  And it turned out that when I put in 9600, it worked really well.
[22:10.360 --> 22:22.120]  If you really want to know, you can measure the distance, turn your sample rate up, measure the distance between the blips and plug it into the equation and you'll get the exact baud rate.
[22:24.500 --> 22:28.760]  The other thing that we need to adjust here is our sample rate.
[22:28.840 --> 22:33.860]  Our default sample rate is too low for those baud rates that we have.
[22:34.580 --> 22:42.540]  The general rule is you want about 10 times the baud rate, or 10 times the sample rate of your baud rate.
[22:42.780 --> 22:46.840]  So, for 9600, you're looking at 100 kHz sample rate.
[22:48.960 --> 22:52.360]  Now, why not just crank our sample rate all the way up?
[22:52.960 --> 22:59.220]  When you increase your sample rate, it makes the logic analyzer have to capture more data.
[22:59.220 --> 23:10.140]  And so, you either have less amount of time that you can capture or less channels you can capture depending on the software and the logic analyzer.
[23:11.180 --> 23:21.700]  So, setting it to the minimum that you would need to capture the signal and data of interest gives you the longest amount and most amount of ability to capture.
[23:26.070 --> 23:38.490]  Alright, so now we have our decoder set up, but the PulseCU software view isn't real great for working with the data, so we export it.
[23:38.810 --> 23:52.950]  There are several options, including raw binary stream, but I generally go with a hex dump, usually the canonical hex dump, as it'll have both the hex and the ASCII text translations.
[23:53.230 --> 23:57.230]  So, after you're done exporting, you're left with a file that looks like this.
[23:57.230 --> 24:04.870]  You have your byte count on one side, your hex values in the center, and then the ASCII translations of it on the other end.
[24:06.190 --> 24:24.810]  And looking at our timings a bit in PulseCU as far as where the packet timings were, we can then apply a little text editing magic and break it down into actual packets.
[24:28.980 --> 24:38.120]  Now that we've got all our stuff set up, it's time to use our logic analyzer and PulseCU to capture the actual communications on the badge while we're doing different tasks.
[24:40.580 --> 24:44.860]  So, the first one is the flashy screen, the screensaver screen.
[24:45.460 --> 25:00.300]  So, hook up the badge, hook up your logic analyzer, go on the logic analyzer, let it capture however long it can capture, take a look, and we don't see anything.
[25:00.340 --> 25:01.760]  Nothing came across.
[25:02.040 --> 25:06.680]  Which isn't greatly surprising, because this isn't really a multi -badge functionality.
[25:07.040 --> 25:13.240]  This only really works with one badge, and it's something that happens all the time.
[25:15.280 --> 25:18.460]  The next major functionality was the slot machine spin.
[25:19.060 --> 25:32.000]  So, same thing, you hook it up, start your capture, press the button, do the spin, and wait for the spin to stop, stop your capture, and once again we found there was no data.
[25:32.760 --> 25:38.460]  Also not highly unexpected, because it's a single badge, more or less a single badge functionality.
[25:39.860 --> 25:44.880]  The one we're really interested though in is the send functionality.
[25:45.800 --> 25:59.840]  So, one of the first things I did was connect my badge up to the logic analyzer, and then repeatedly just press the send button with one badge connected, and we get data.
[26:05.760 --> 26:14.660]  The big thing here to notice is what there isn't, and that's change.
[26:16.200 --> 26:27.620]  All of these packets are exactly the same, and that's very important to know, because that means that we have repeatability in our communications, at least in this packet and at the start.
[26:27.620 --> 26:44.200]  There's no sequence numbers, there's no times embedded, there's nothing that changes without some data in the protocol itself changing, there's nothing that changes based on the time that it was sent.
[26:44.600 --> 26:47.740]  So, our send packet is repeatable.
[26:53.970 --> 27:10.670]  The next step is to hook two badges up, or actually no, the next step we did was still with one badge connected, and I cycled through a send with each of the green icons that I had on my device.
[27:11.510 --> 27:16.710]  And I did this with some friends with a couple different badges.
[27:17.050 --> 27:20.930]  And these are just partial captures from the first few from each badge.
[27:21.470 --> 27:23.850]  And so we can take a look and see what we see here.
[27:25.810 --> 27:35.890]  For these packets at least the first thing that jumps out at me is all of them seem to start with the constant value, this SNDN exclamation point.
[27:37.290 --> 27:40.370]  So, SNDN makes me think send.
[27:41.310 --> 27:44.130]  So, this could be a command.
[27:45.350 --> 27:51.030]  It's also at the start of the packet, so maybe some sort of delineator.
[27:55.310 --> 28:04.470]  The next thing we notice is the next two bytes are the same within each badge, but differ between the two badges that we have here.
[28:08.050 --> 28:11.130]  This is likely our badge number.
[28:15.010 --> 28:17.790]  The next calendar that's different is this one.
[28:17.790 --> 28:24.250]  And we notice that it's counting up as we change the icon that we're selecting.
[28:25.490 --> 28:31.890]  And the one... this is not going to work well.
[28:32.370 --> 28:33.510]  I'll try it.
[28:33.670 --> 28:40.050]  This one here is the left shamrock from badge one.
[28:40.170 --> 28:45.290]  And badge two didn't have left lemon, so I had to start with left shamrock.
[28:45.290 --> 28:52.530]  And so we see that between the two badges, both when we send left shamrock it sends the same number.
[28:52.570 --> 28:58.610]  When we increment it and send left diamond, we both get two.
[28:58.610 --> 29:14.070]  And working through the entire process and a full badge, and about three badges, we find this is consistent, and we can overlay it over our badge, and we have our icon numbers.
[29:17.680 --> 29:29.900]  The last piece that changes, and is interesting, is this last column, which we see is counting down, but is different between the two badges.
[29:31.440 --> 29:34.440]  Does anybody have any ideas on what this could be?
[29:36.800 --> 29:38.100]  Checksum, yep.
[29:38.560 --> 29:45.060]  That's the most likely option here, especially with its position at the end and the mismatch.
[29:45.860 --> 29:49.200]  So I'd most likely expect this to be a checksum of some kind.
[29:50.500 --> 29:58.860]  Now that we've got a basic idea of what we're looking at, we can do a full trade between two badges and capture the data.
[30:00.600 --> 30:06.340]  Now there's something very interesting that could be easily missed in this slide.
[30:11.830 --> 30:13.410]  We've got two lines here.
[30:13.410 --> 30:20.170]  We've got our D0, which is their tip, and we have our D1, which is our ring line.
[30:22.110 --> 30:24.510]  There's no data on D1.
[30:25.390 --> 30:31.570]  All of the data is on our D0 line, which is interesting.
[30:31.570 --> 30:42.010]  Usually in a standard TTL UART, you hook the TX of one up to the RX of the other, and the RX of one up to the TX of another.
[30:42.290 --> 30:45.670]  So this is using a one-wire serial protocol.
[30:48.980 --> 30:58.700]  Now this kind of makes sense, as we pointed out earlier, the gentleman over here, when we beeped out our cable and did the continuity check, it was a straight-through cable.
[30:58.700 --> 30:59.980]  There wasn't a crossover.
[30:59.980 --> 31:07.480]  So the badges either have to be using one wire or no, some other way of negotiating which line to use.
[31:07.480 --> 31:12.980]  In this case, they're using a mode-on-the-pick UART to do one-wire communication.
[31:15.300 --> 31:23.160]  There were a couple groups last year who were working on this protocol, and one of them got stuck trying to figure out the second line.
[31:24.240 --> 31:26.660]  Now, here in PulseView, there's no data.
[31:26.660 --> 31:29.340]  They didn't have a really good logic analyzer.
[31:29.500 --> 31:31.920]  I think they were trying...
[31:35.040 --> 31:38.020]  Shoot, what's the little hacking device?
[31:38.120 --> 31:38.820]  Flipper, yeah.
[31:38.820 --> 31:44.360]  I think they were trying to use the UART on the flipper to figure it out.
[31:44.480 --> 31:50.320]  And they were seeing some data on their second line.
[31:51.320 --> 32:01.280]  And it's really interesting, because when I used my SLEA to look at this, which has an analog function, I also noticed some changes on that line.
[32:01.300 --> 32:07.920]  But they matched up a little bit, they matched up with the pulses on the other line, and were a lot shorter and smaller.
[32:09.360 --> 32:15.460]  When they designed this badge, they didn't ground the second line.
[32:15.740 --> 32:24.920]  And so what we're seeing is a capacitive induction on that second line, and it can confuse some logic analyzers and some devices.
[32:28.140 --> 32:34.220]  But, to the more interesting part, the data that we actually captured from the transfer.
[32:34.220 --> 32:44.920]  So this is two exchanges of trading gear and cherry between first from badge 1 to badge 2, and then trading it back from badge 2 to badge 1.
[32:45.340 --> 32:55.840]  And when I did this, I kind of staggered my button press times on the send button a little bit, to try and force one badge to start the transaction.
[32:58.820 --> 33:06.860]  So right away, the first thing that chomps out to me is all of our packets are starting with this SNDN exclamation point.
[33:08.060 --> 33:14.520]  On our previous, when we were looking we said this might be a command, send command, made sense at the time.
[33:15.640 --> 33:23.560]  But, it's common across all of our packets, so this is pretty much most likely a header to the packet for processing.
[33:27.640 --> 33:36.580]  We look over again at our column with our icons, and the icons match up to the icon numbers that we're expecting to see in this trade.
[33:37.580 --> 33:46.940]  We'll also notice that in the second and third packets there's another column that has the icons and the numbers in them as well.
[33:53.020 --> 34:07.040]  Looking at our badge numbers, this column that we thought was badge numbers, we can see it alternating, starting with one badge number a second badge number replying, and then the first badge number again.
[34:07.380 --> 34:18.500]  Now, the PIC16 is an 8-bit processor, but after looking at several badges, the number is 2-byte value.
[34:21.420 --> 34:27.160]  And we also see the numbers mirrored there.
[34:29.710 --> 34:43.570]  So we know that from attendance stuff that they generally make 700 to 1,000 digital badges a year, somewhere in that range, which is much larger than 256 that would fit in a single byte.
[34:43.570 --> 34:46.690]  So it makes sense that our badge numbers are 2-bytes long.
[34:47.930 --> 34:50.710]  But they're also not in the tens of thousands.
[34:52.610 --> 34:56.070]  So this is most likely a little-endian number.
[34:56.290 --> 35:09.770]  And so when we decode them as little-endian numbers, we end up with badge number 0169 in hex, or 361, and badge 028C in hex, or badge 652.
[35:15.440 --> 35:20.080]  Now this column we didn't look at before, and now we can see that it changes.
[35:22.300 --> 35:31.340]  This is most likely our command bytes that tell the badges what packet they're doing and what they need to do.
[35:31.340 --> 35:39.120]  And taking some guessing here, I came up with these names for the packets.
[35:40.200 --> 35:45.600]  We have a goodbye, a start of a trade, a trade response, and a confirmation.
[35:49.250 --> 35:57.750]  So putting that all together, we have IM badge 028C.
[35:58.670 --> 36:02.770]  I'm going to be sending the left gear icon.
[36:06.260 --> 36:09.040]  IM badge 0169.
[36:09.820 --> 36:19.260]  I got the left gear icon, and I'm sending center cherry back to 028C.
[36:22.690 --> 36:26.370]  IM 028C.
[36:26.490 --> 36:32.110]  I'm going to confirm that I got your center cherry from badge 0169.
[36:32.510 --> 36:35.130]  And I sent the left gear.
[36:38.160 --> 36:39.960]  IM 028C.
[36:40.420 --> 36:41.620]  Goodbye.
[36:46.280 --> 36:50.160]  So now we need to go back and look at that last byte that we thought was a checksum.
[36:50.840 --> 36:58.980]  Now when I'm dealing with checksums and trying to decode checksums, there's two websites that I generally use.
[36:59.360 --> 37:04.340]  CRCCalc.com and SCADA Core's online checksum calculator.
[37:04.680 --> 37:07.380]  These are both webpages that you go in.
[37:07.400 --> 37:18.160]  You can plug in your data that you want to checksum, hit go, and it spits out checksums using dozens of algorithms.
[37:18.580 --> 37:22.400]  And then you can take the number that you expect and go down the column.
[37:22.480 --> 37:24.420]  And usually you'll find it match.
[37:26.460 --> 37:32.800]  In this case, when I did that, I found it was a checksum 8 2's complement.
[37:32.860 --> 37:39.660]  Which is basically 100 hex minus the sum of all the bytes truncated to 8 bits.
[37:41.340 --> 37:48.940]  Now when I'm working with other protocols, there's a few interesting things I've found with people who have done with checksums and CRCs.
[37:50.420 --> 37:56.360]  Sometimes they'll CRC or checksum just part of a packet and not the whole packet.
[37:56.380 --> 38:03.780]  They'll leave off the header or some other piece of data that they don't really care about.
[38:05.620 --> 38:11.380]  I've had one where we've had the CRC was in the middle of the packet.
[38:11.700 --> 38:15.300]  So one of the big differences between checksums and CRCs.
[38:16.200 --> 38:23.560]  Checksums generally just sum everything up and runs a little bit of math on it.
[38:23.560 --> 38:25.280]  But they're not position dependent.
[38:25.600 --> 38:28.540]  If you have two bytes transposed, it won't catch that.
[38:29.060 --> 38:35.960]  A CRC is a little more complicated algorithm and takes the position within the byte stream into account.
[38:36.360 --> 38:43.400]  And so that'll catch if the length is different or if two of the bytes are transposed.
[38:43.640 --> 38:55.620]  So I've seen somewhere they put the CRC in the middle of the data segment and you have to perform the CRC with the CRC field set to zeros and then populate the CRC into the packet.
[38:58.550 --> 39:07.570]  So this is where I was last year Thursday night at a CypherCon and all excited end of the night, went to show wire.
[39:10.370 --> 39:12.310]  And he goes, you're missing a packet.
[39:13.290 --> 39:15.410]  Programmers start counting at zero.
[39:16.090 --> 39:17.330]  I'm like, what?
[39:17.750 --> 39:19.510]  Programmers start counting at zero.
[39:24.140 --> 39:25.660]  Our commands start at one.
[39:29.470 --> 39:31.350]  So then I couldn't sleep.
[39:32.750 --> 39:34.430]  Got back to my hotel room.
[39:34.430 --> 39:36.150]  I'm like, I need to go to sleep.
[39:36.150 --> 39:37.410]  I'm presenting tomorrow.
[39:37.990 --> 39:39.750]  I need to get some rest.
[39:40.010 --> 39:40.730]  Can't sleep.
[39:40.730 --> 39:41.670]  Can't sleep.
[39:42.630 --> 39:43.550]  So get up.
[39:43.550 --> 39:44.430]  Break my badges out.
[39:44.430 --> 39:46.210]  Break the logic analyzer out.
[39:46.490 --> 39:47.310]  Recapture a trade.
[39:47.310 --> 39:49.390]  I'm like, no, there's nothing else there.
[39:51.610 --> 39:53.570]  Okay, well, I'll deal with it tomorrow.
[39:53.790 --> 39:55.150]  Nope, can't sleep.
[39:55.150 --> 39:56.070]  Laying in bed.
[39:56.150 --> 39:57.250]  Get up again.
[39:57.290 --> 40:06.970]  And sitting there, I just start running my logic analyzer in captures, which is the nice thing about the Celia is it's a streaming analyzer, whereas the PulseView is a fixed number of captures.
[40:07.150 --> 40:13.390]  So I'm sitting there streaming on the Celia captures and just start playing around with the badge.
[40:13.390 --> 40:15.490]  Just trying different things.
[40:15.490 --> 40:16.370]  Doing spins.
[40:16.370 --> 40:18.590]  Again, maybe I missed something during the spin.
[40:19.190 --> 40:21.310]  You know, doing other things.
[40:21.650 --> 40:26.770]  And then I hit the send button on the flashy screen and there's a blip.
[40:29.360 --> 40:35.280]  So I connect up the two badges, lay them on the flashy screen, screen saver, and press the send button.
[40:35.740 --> 40:38.180]  And there's a blip and a blip back.
[40:38.660 --> 40:40.680]  And I end up with this communication.
[40:49.040 --> 40:51.700]  I am 028C.
[40:53.100 --> 40:56.660]  The new command is 0, which I dubbed hello.
[41:00.110 --> 41:05.550]  I am 0169 and are goodbye.
[41:09.860 --> 41:11.460]  So what does this do?
[41:11.460 --> 41:12.740]  What's the point of this?
[41:14.340 --> 41:18.860]  At first, my first thought it was a test mode for the TRS port.
[41:18.860 --> 41:21.080]  Verify that the serial communications work.
[41:22.280 --> 41:34.680]  There was another test mode on the badges that if you held the send and the pick and the send button down when you powered it on, it would do a cycle through all the LEDs so they could verify the solder joints on all the LEDs.
[41:35.100 --> 41:37.300]  I thought that this was probably some way to do that.
[41:38.900 --> 41:43.440]  But after I went back the next morning, showed wire, he said, yep, you got it.
[41:44.360 --> 41:46.740]  And he's like, so he asked me, what does it do?
[41:46.740 --> 41:47.880]  And I'm like, well, I think it's this.
[41:47.880 --> 41:54.180]  And he's like, you know, actually, it's a way to trade points without trading icons.
[41:54.800 --> 42:04.900]  So if you went up to someone else's badge, normally you'd hook the cable up, you'd pick, you'd do your send, and it would send the icons, and it would also trade points the first time.
[42:05.340 --> 42:14.480]  This time, you could hook the cable up, just press your send button on your screen and you'd get the point values transferred.
[42:14.560 --> 42:18.340]  Not sure anybody actually realized that functionality during the con.
[42:23.560 --> 42:26.500]  So now we're left with our five commands.
[42:29.680 --> 42:31.040]  So now what?
[42:31.040 --> 42:36.020]  Now that we understand how to talk to the badge, what can we do with it?
[42:37.800 --> 42:41.920]  Well, one of the ideas is we can start looking for exploits.
[42:43.040 --> 42:47.220]  We could write a fuzzer, make mistakes in the protocol, see what happens.
[42:47.220 --> 42:50.140]  Can we get it to buffer overflow or buffer underflow?
[42:51.640 --> 42:53.100]  What happens if we send
[42:57.400 --> 43:00.280]  a packet with an icon that doesn't exist?
[43:00.540 --> 43:02.800]  Or what if we start trying commands that don't exist?
[43:02.800 --> 43:03.720]  What does the badge do?
[43:03.720 --> 43:05.080]  What does it react with?
[43:07.100 --> 43:13.720]  Well, one of the obvious things we can do, other things we can obviously do, is now we know how to trade arbitrary icons.
[43:16.850 --> 43:29.190]  And if you get really creative, you can write a script with a starting score and a target score and get that, your score on your badge as close as possible.
[43:29.530 --> 43:32.910]  Now, there's a few other things and catches with this.
[43:33.150 --> 43:40.170]  First, we need to know the ID ranges for the badges and their associated point values.
[43:43.000 --> 43:46.740]  And then we have the issue that you only trade points the first time you talk to a badge.
[43:46.740 --> 43:55.840]  So if you've talked to any of the ID numbers you try and use to set up your point total that you've already talked to previously, it might not work.
[44:01.360 --> 44:04.460]  So does anybody have any other ideas of what we could do with this?
[44:11.410 --> 44:13.870]  Okay, I didn't think about it either.
[44:13.870 --> 44:15.910]  So we've got a little demo.
[44:24.460 --> 44:26.460]  So this is my setup.
[44:27.220 --> 44:43.220]  And often at work, when we finish dissecting a protocol, we have to write a simulator to verify, one, that we understand it, and two, it helps to have a simulated device to test against instead of the real device.
[44:43.940 --> 44:47.120]  So I went ahead and made a simulated badge.
[44:47.260 --> 44:52.080]  And so this setup is an ESP32 that I flashed with MicroPython.
[44:52.220 --> 44:57.300]  And this same board, if you guys recognize it, is available over in the Hardware Hacking Village right now.
[44:57.400 --> 45:04.080]  So if you haven't gotten one yet, I highly recommend you go over there and get a free ESP32 badge, which can do cool stuff like this.
[45:04.580 --> 45:14.180]  I've actually got this badge powered off of the 3.3 volt lines off of this dev board, the ESP32 board.
[45:15.160 --> 45:19.360]  I've got the tip connected up to the microprocessor's UART2.
[45:19.920 --> 45:26.420]  And I've got the pick and send buttons that I traced out to the microcontroller hooked up to GPIO pins.
[45:28.480 --> 45:28.960]  So...
[45:28.960 --> 45:32.740]  we're going to turn all the icons on this badge green.
[45:56.360 --> 45:57.800]  Yes, it would have.
[45:58.620 --> 46:03.200]  And it wouldn't really be fun if we couldn't do it multiple times.
[46:03.200 --> 46:06.220]  So let's turn them all red again.
[46:11.690 --> 46:12.670]  Thank you.
[46:12.670 --> 46:13.930]  That's my talk today.
[46:18.270 --> 46:20.030]  Any questions we've got?
[46:20.030 --> 46:21.690]  Oh, I went a little longer than I expected.
[46:21.690 --> 46:22.250]  Yeah.
[46:35.600 --> 46:36.700]  Sort of.
[46:37.020 --> 46:42.160]  They had the firmware readout bit on the PIC set last year.
[46:42.500 --> 46:44.080]  So the readout protection.
[46:45.020 --> 46:46.500]  And I've looked into it.
[46:46.500 --> 46:49.220]  I've tried to figure out how to read out the firmware of the PIC.
[46:49.220 --> 46:59.220]  And there's some companies, if you can send your board over to Russia or Asia somewhere, there's companies that'll do it for you.
[46:59.700 --> 47:19.640]  The only method that I've found that's published for bypassing that is decapping the chip and exposing the quote one-time programmable bit that does the write protect, or the readout protect, or it's not a one-time programmable, because when you erase the badge,
[47:19.640 --> 47:20.540]  it clears it.
[47:20.540 --> 47:23.020]  When you erase the PIC, it clears the write protect.
[47:23.020 --> 47:24.700]  That's the only way to clear it.
[47:25.340 --> 47:27.360]  Only official way to clear it.
[47:27.720 --> 47:35.380]  But if you mask off just that one area of the chip and expose it to UV, you can erase it.
[47:35.600 --> 47:37.220]  But you have to decap the chip.
[47:38.060 --> 47:38.660]  Yeah.
[47:49.280 --> 47:55.020]  The question was, is there a, in the code, did I find any way for it to factory reset the badge?
[47:58.320 --> 48:00.040]  I haven't found it.
[48:01.300 --> 48:06.800]  I know that there is a jumper on the back of the badge that you can solder.
[48:06.800 --> 48:10.500]  I don't remember if you solder it or desolder it at the end of the con.
[48:10.600 --> 48:13.720]  To put it into post-con mode, they usually put that on the badges.
[48:14.700 --> 48:16.900]  It's a resistor you pull.
[48:17.480 --> 48:18.660]  I don't remember the details.
[48:18.660 --> 48:20.980]  I never do that with my badges, because I like to play with them.
[48:23.740 --> 48:25.480]  Oh, we got another one.
[48:35.420 --> 48:43.360]  Yeah, usually a UART, the one device will pull the line high and drive the line up and down.
[48:43.780 --> 48:54.900]  The PIC microcontrollers have an open drain mode in them, where the UART lines are open drain.
[48:55.460 --> 48:56.560]  And so they'll
[49:00.240 --> 49:15.140]  have a pull-up resistor, but when they drive the line when the one is talking, it can pull that down, and usually it's in listen mode unless it's transmitting.
[49:15.480 --> 49:28.860]  Now, to get around that on the ESP32, because the ESP32 doesn't have that mode, but my demo here, I was still using a single line to drive that UART.
[49:29.560 --> 49:34.880]  And the ESP32 is I'll back up a little bit so I'm not feedbacking.
[49:35.020 --> 49:48.140]  The ESP32 is really nice in that it has, its GPIOs are pretty much fully matrixed, and so I was able to actually dynamically remap the pin at runtime between TX and RX.
[49:49.180 --> 49:58.300]  Now, that can cause some funny behavior on the badge side if I wasn't careful because I was backdriving power into the badge sometimes.
[49:58.460 --> 50:02.780]  So it would be a little funny sometimes funny behavior when you turn it off.
[50:02.780 --> 50:05.000]  It wouldn't actually fully turn off.
[50:05.880 --> 50:11.100]  But it worked for the purposes of talking to it as long as you didn't turn the badge off.
[50:18.010 --> 50:20.510]  I did look at it a lot.
[50:20.610 --> 50:22.310]  I took it down to part last night.
[50:22.650 --> 50:26.530]  There's no active comms on this badge in between badges.
[50:26.830 --> 50:30.330]  And the firmware is fully available if you can hook up to the USB port.
[50:33.390 --> 50:40.750]  Purposefully, I talked with Whisker and he said he purposely wrote it obtusely to make it hard to understand.
[50:41.350 --> 50:48.290]  So my first reaction when I looked at it was like, this looks like code written by an electrical engineer who's never written Python before.
[50:48.710 --> 50:51.650]  Looks like embedded C.
[50:51.650 --> 50:55.530]  But, yeah, so I
[51:02.560 --> 51:14.420]  I have, I did try and dump it into Copilot and my instance of Copilot didn't I pointed it at a link to the file and it said, oh, I'll process that and code review it and get back to you.
[51:14.420 --> 51:15.900]  And it never got back to me.
[51:17.680 --> 51:23.360]  So AI, I'm not fully worried about AI taking our jobs yet.
[51:25.500 --> 51:32.000]  I did hear that somewhat Josh dumped it into a different one and he had some pretty good success with it.
[51:33.680 --> 51:43.820]  So, alright, I think it's time to go party, so I'm going to call it, unless if you guys have any other questions I'm happy to answer them after, but have a good night, enjoy the rest of CypherCon.
[51:44.800 --> 51:45.180]  Thank you.