working in conjunction here with Daryl and team to produce some of these labs and whatnot.
And this particular one is going to be about logic analyzers. So, my name is Jonathan Sines.
I'm a pen tester on the Rapid7 team. And just to dive right in, what is the purpose of a logic
analyzer? So, in essence, developers use logic analyzers pretty heavily for doing things such as
debugging protocols. So, if they're doing something like what we see in the picture
here that has probably some form of interchip communication, maybe there's like SPI or I2C,
logic analyzers enable you to dig down and see underneath the hood what's actually going on.
Works fantastically for troubleshooting. Just think like Wireshark for hardware analysis.
Like I was mentioning, it could also be used to debug. So, it's used to troubleshoot maybe
why is my software not working? Why is this embedded firmware not talking from the SPI
flash chip to my MCU? A logic analyzer can kind of help troubleshoot that.
So, that's the sort of developer-y perspective of using a logic analyzer. Now,
how would we use them in IoT? So, of course, we have the pizza delivery, pizza doom guy,
with the ski mask underneath. We use them in IoT. Our goal is to dump the firmware. So,
once the firmware is dumped, it's oftentimes mostly dumped through serial interfaces,
unless we're doing something like removing a chip. So, whenever we're talking about this,
it's going to be more so focused on from the perspective of doing something like dumping
firmware from some type of interface, whether that be UART, whether that be SPI, whether that be I2C.
Also, it's to interact with the device. I know that if you've attended any of our other talks
from today with regard to U-Boot or any of the talks yesterday, we've talked a lot about UART.
So, UART will be the serial, I guess, mechanism that we would use to interact with some of these
devices. So, what we want to do is identify what is the pinout of some of these devices. And we'll
talk a little bit more about that later on in the slides here. But a lot of times, the pins,
they're not labeled. So, we need to figure out, okay, A, what type of protocol is being used for
these pins? And B, which individual channel is being sent or what kind of data is being
transported over those pins? So, things such as you can check things on a simple serial bus,
like SPI, I2S, I2C, UART, things like that using a logic analyzer.
What are the types of logic analyzers? Again, I know we're kind of talking about maybe some
boring stuff, but just to kind of take you a little bit back in time here, the bottom left
corner is a desktop logic analyzer. You don't really see those that much these days. That looks
more like an oscilloscope, but it's, in fact, a logic analyzer. If you kind of take a closer look,
you can see that it's actually measuring digital frequencies, something that an oscilloscope does
not do, which we'll talk about more later. What we will be talking about and looking at in our
demos is going to be USB logic analyzers, and those look more like the things you see on the
right side of the screen. So, the Saley is like one of the more popular ones, and you have a couple
of the others, like Travelogic in this particular case. The USB analyzers tend to be cheap,
and they tend to be small. Desktop analyzers tend to be large, and they tend to be expensive.
We'll talk also a little bit about oscilloscopes later, but the logic analyzer has a small amount
of memory, but a large number of channels. That's pretty important, because we'll kind of compare
and contrast what might be right for you. If you're wanting to get started with some of this stuff,
what would be best for you with what you're doing with whatever it is that your goal is.
Logic analyzer is a visual representation of the data that it processes as well. So,
when I say that it's a visual representation, it's making the calculation and representing
what it thinks is what that data looks like, rather than oscilloscope, which is the actual
analog signals that's traversing over the voltages of the chip.
These logic analyzers, we'll talk about price later, but like I was mentioning earlier,
USB logic analyzers tend to be very cheap. Okay, a logic analyzer is not an oscilloscope.
So, all these snippets I stole off the Salie website. The oscilloscope,
it measures... the idea in general is that it's measuring constantly. It's not like...
This is quite possibly the most boring slide I've had, so it sucks to be y'all.
I'm just kidding. They're all equally bad. So anyways, oscilloscope is not a logic analyzer.
Oscilloscope measures analog, whereas logic analyzers measure digital. I'm actually glad
we went back to this one, because some logic analyzers can actually measure analog. We'll
talk about that a little bit later. I'll kind of show you. We'll go over a few different logic
analyzers, just to kind of see what... but I probably shouldn't just use like the blanket
statement and say that logic analyzers cannot measure analog, because that's not a true
statement. They can to a certain extent, but many of them do not.
So as I was mentioning, they are not used for any type of like UART connection. So you get data
being transmitted over UART, but you can't actually set up like, okay, hey, I want to
toss in like, you know, let's connect to this using 8-bit, you know, parity, and then we'll
of course do like a quadrate of like 11200 and interact with this device. That's not what you
can do with a logic analyzer. Logic analyzer is more of just a passive listener. It's something
like Wireshark or hardware. It's not an oscilloscope. So from an oscilloscope perspective,
basically you're looking at voltages over a period of time. So it uses memory. So it's using,
say, for OCD. So we have the Sabley, right? So the Sabley is, I don't want to say de facto,
but it kind of is de facto. It's also some software and a pretty large online community
and support that is available that goes hand in hand with this particular logic analyzer.
There are other logic analyzers, of course, that exist and we'll look a little bit more
about the prices. What did we pay for these? Between like 5 and 15, 20 bucks.
I think it was like 12 for one and 24 for the other one.
Very cheap, you know, like go sell like a garbage bag full of, you know, aluminum cans and then buy
this stuff because you can just, it's just outrageously cheap. So anyways, we'll do some
pros and cons between all these guys, but we're going to kind of just, let's just go ahead and
hook something up with it. What we're actually going to look at with it is going to be Raspberry
Pi. What we're going to look at also with it is Raspberry Pi has a UART interface. I'm sure as
many of you guys know. And I'm going to try to just take the examples just to kind of give you
an idea. But here is the Raspberry Pi like sort of coming out and hopefully everyone can see that.
Daryl, is this showing up on the screen? Yes. Okay, perfect. So whenever you're looking at it,
it's basically how it's laid out. So just be aware that it looks good. Cool. So as you can see
on the screen, we have ground, several grounds. And then right here on these two, we have Rx and Tx.
So Rx and Tx are the two interfaces that we're going to target for UART. So if we count down
one, two, three, four, it is Rx or Tx rather. And then one, two, three, four, five, it's Rx.
And then we'll have a ground down here in the bottom left-hand corner. So let's get this
hooked up. I'm going to start this off with you guys with the, I guess just the matter in this
particular case. But whenever you look at the actual like logic analyzer, you can see that
there's like a mapping of the pins on it as well. So it's basically like channel zero through seven.
And then there's two grounds. And what that's based off of is the actual like layout of the
pins on the thing, and then you have the actual pins. So what we'll do is we'll take these three
jumper wires here, and we're going to actually get rid of the old Raspberry Pi pinout graph.
We're actually just going to move it over that way. And then we're going to just kind of hook
these suckers up. You know what I mean? So we'll take ground. We're just going to use black. We'll
try to be correct with our color usage here. Black for ground. So we'll hook that up to one
of the two grounds there. And we'll hook up white to channel zero. And we'll hook up this like
silver color to channel one. And if you guys think this is fun watching me do this, just wait
until we get to the SPI. So that's exciting. I'm looking forward to it. And then as we saw earlier
with the ground, this is the bottom left hand corner pointer here. Remember we hooked up white
to channel zero. We're going to hook white up to channel... it's the fourth pin, so we'll use the
TX here. And we'll hook up this little silver to RX. And that's it. So that is pretty much how
these hook up. And we'll look at several other devices, but I just wanted to give everyone an
idea so we're not kind of, you know, functioning in the dark here. So let's put a pin in this and
let's circle back to some of the slides here. So we now know what that looks like. Now I've done a
lot of talking here. I think we have a couple questions here. Let me look. There was one
question. You may have already covered it, but I want to make sure it's asked. It's in the channel.
Are there any equipment models that you can do experience to come across any models of devices
like that? Yeah, so some do have the capability of doing both analog and digital. Most of the cheaper
ones are only digital. Now the ones that support analog and digital are typically a little bit more
expensive. And a great example of that is the Salee. It supports both and a channel.
But yeah, so some models do support it. Typically you'll be paying a little bit more money for it.
So I would definitely ask yourself, is analog something I truly need for the type of
debugging, the type of troubleshooting, the type of development, or the type of hacking that I'll be
doing. One other question here. So where can somebody buy the cheaper logic analyzers that
you're demoing here? And would they work for newer to IoT versus having a larger investment?
That is a very well-timed question. This is a couple examples of where you can get some of
these logic analyzers. On the left side of the screen, I pulled this directly from the Salee
website. Again, these are the nicer models that support both analog and digital. I'll also show
everyone here on the call what it looks like and what it means to actually have a nicer one versus
not so nice one. So are you going to be spending, in this case, an example to have on screen, $13 to
$24? Or you can have a peek at that. But on the left side of the screen here, the pricing is from
Salee. You can buy them on Amazon. You can buy them on eBay. You can buy them on Spark. The
prices on the right, the two cheap ones below and above the dude whose wallet is on fire,
were off Amazon. I had this screenshot of that maybe like three or four days ago.
As far as the features between differences in between the cheaper one versus the more
expensive one, we'll take a peek at that in a couple of demos, a few slides down the road.
No more questions. I guess you can move on.
Sweet. So moving on here, as I talked about earlier, the signaling.
Analog signaling is just continuous changing values, whereas digital is defined values
based on a range of voltage that we're going to see with these USB logic analyzers.
Bear in mind, it's not 100% accurate. So if you're like needing to be like pinpoint accuracy
on voltages, the logic analyzer is going to be... I also want to share with you what those digital
versus analog signals look like. So whenever we dive into the software here pretty soon,
we can kind of see what those waveforms are and how they differ from one another.
The voltage above a certain threshold is... and digital signaling with logic analyzers
is binary. If it's going low, then that's considered a zero. If it's going high,
it's considered a one. And that determination is based upon that particular threshold transistor
the technology is basically using. Logic analyzer will sample the voltages at various intervals and
reconstruct what that data looks like. So I just want to kind of just shine a little bit of context
as to analog versus digital. So there's two main types that I've used in my experience.
Your mileage may vary. I know there's a lot of different other software, I guess, vendors,
makers out there. I'm Mac-based, so I'm going to handcuff the Mac, fortunately, because it would
also be capable of running on Linux, too. So the top left corner is Sigrock's PulseView.
So Sigrock is a manufacturer of logic analyzer as well as software,
and PulseView is the actual software name. Now, what we're going to talk about actually has
Sigrock client, and I'll be honest with you, I love the fact that they're open source. I love
the fact that it's free. Actually, both the software here is free, but the PulseView,
the graphical interface, is just not the greatest. It's more robust, I guess you could say. So
unfortunately, I'm not going to go over it today because it would probably take a little bit too
much time. But to kind of dive in here, what I wanted to do was just kind of compare these two
software sets with you. So with that being said, let's just dive right in. Let's just take a look
here. Screw it. So what I want to do first is I want to continue with where we left off with
this particular logic analyzer and the more expensive stuff. How about that? We've got a
couple of wires here. We've got a power for the Raspberry Pi sitting right here. I have the USB
power stripped here. I'm just going to kind of power off the Pi real fast. And we'll go ahead
and grab the other cable for our logic analyzer. That's right there. Let's go ahead and plug this
up. Now, as we're doing this, again, this is going to power for the logic analyzer.
And what we're going to do next is let me... there we go. Okay, cool. We'll do that here.
So I'm going to bring up the software on the other side of the screen here for us.
And the first one we're going to look at is PulseView. So I just want to kind of
give you a quick little demo of what some of this looks like. So as you can see here,
shift that that way, we have everything hooked up on this side of the house.
Remember, we have UART. So RXTX hooked up to this based off the pinout that we found online. And,
of course, ground's hooked up as well. We followed the mappings here. So we're going to kind of take
a white box approach with this. And let's just assume that we know everything already. So let's
assume that we found the data sheet for the device that we're wanting to kind of probe and take a
look at. What we want to do next is from the software here, I'll give you a quick little run
through. So we'll go back to the full screen. This is the Sigrot PulseView. So with the PulseView,
you can select the device you have plugged into your computer. And this particular one,
the driver that we need is the FX2LAFW. So we'll select that from the dropdown,
and we'll click scan for devices using the driver above. And then we'll click OK. And
that basically has it hooked up. So what happens here is an airplane flying above here. So you'll
hear some background to that. What you see here is that there's eight channels starting at zero
and ending at seven. So that's representing the eight channels that the logic analyzer has.
Remember, it's zero through seven on the logic analyzer. What we can do is we can lower that
because we're only using RX and TX. Ground is assumed. You're always going to use ground. So
we want to select D0 and D1. So we're going to remove some of these other guys here.
Going back to the software here, you can change the amount of sampling that it does. In this
particular case, I have it set at one millisamples per second. So that's the setting for that. And
we'll talk about that a little bit more whenever we get into salient software. But the cheaper
logic analyzers can sample at a slower rate than the Salie. So there's a little bit of a
limitation here. And here's the speeds as well. So we're going to stick 20 kilohertz.
So let's just plug this sucker in. Let's just see what happens. So I'm going to hit the power
button. We're going to see the lights come on on the Raspberry Pi right here. And then I'm going
hit the run button. Whoopsie-daisy.
Try that again. And then we can click this button here, which makes us keep up with the timing of
the actual logic analysis that's taking place. So we'll see some spikes and voltages as things
happen. Again, this is over UART. So think of the TTY connection over some type of serial or
SSH interface. Imagine just a boot up of a Raspberry Pi. So it's just going to do its crap.
And then at the end, it's going to be like, okay, Raspberry login type stuff. So we'll go ahead and
stop it now that we're getting kind of closer towards the end here. Yeah, that's the last one.
So if we take a look here, this is basically the capture. I captured for, as you can see,
35 seconds. So the thing about this, let's go ahead and go back into full screen. We don't
really need the camera so much right now, but we'll go ahead and expand everything back out.
And let's just take a look over here because this is the, let's just pretend again, let's just assume
that we know the answer to this. This is basically where it's just prompting for a login to the UART
interface. So we'll go in here and we'll kind of scroll, scroll, scroll. And even if you were unsure
of which one was RX or TX, you could pretty well assume if you at least knew that these two
connections were UART, that this one's going to be TX and this one's going to be RX. How is that?
Because TX is sending us data and RX is literally a flat line. So a couple of things there that can
kind of help you out. And one other thing too, is that this particular software does have protocol
debuggers. So let's take a look at that and let's go ahead and remember we set TX to D0 and we set
RX to D1. So another thing too, we already have 11.5.200. We're going to keep everything else
basically default here. The least significant bit first is correct. We'll switch that to ASCII
and it will come in here and then it should do some decoding for us. Usually it takes a second.
Let's see if she works here. Yeah, so again, just a high-level example of the protocol decoding
available for this particular PulseView software and some of the stuff you can do. So it recognizes
stop bits, it recognizes frame errors, break conditions, things like that. Now what I want to
also do real quick, we'll just exit completely out of here. We don't want to save. Another thing
is it's pretty nifty. PulseView has SIGROC. They have their own proprietary format where you can
save your data and then import it into Saly or other. You can manipulate it also from the command
line. We want to now switch over to the Logic software from Saly. So Saly has their own set
of software. They actually have two sets of software that we're going to review. And what I
want to do is... let me open it up here. And what I want to do is show you guys both sets of
software to kind of show you the epicness of what it has the capability of doing. So on the left-hand
side here, we have the Saly Logic 1.0, 1.2.18 software, I guess, technically. And in this
case, it's very similar. So remember, here's all the eight channels. And that's pretty much the
situation that we're looking at. Mind you, remember, this is all digital signaling. So
there's no actual analog signals going on in this particular case. So very similar to the other
software, you can do the same protocol analysis. So we have, for instance, AsyncSerial, which is
UART. UART is an AsyncSerial communication protocol with I2C and SPI. So there's a whole
list of different protocols supported also by the Saly software. Your decoded protocols,
it can actually decode also. As we saw earlier with the other software, it decoded it, but it's
kind of limited on the amount of information that it can present to you. The command line is where
the SigRoc software is very strong compared to Saly. There's also annotations. So with the
annotations, you can kind of capture during periods of time. But the thing I want to show
you guys the most here is with logic analyzers. It's not specific to Saly, but let's just go ahead
and power this guy off. So as you can see on the right-hand side of the screen, the light's now
off on the Raspberry Pi. Let's go ahead and power it back on. But also, we're capturing for 30
seconds. Let's just stick to four mega samples per second. And then we'll go ahead and power
the sucker back on while it starts. So as you can see right here, the only sad panda part about the
Saly software is that it doesn't like live view show like the results of what's going on with
everything. So you're kind of like, you're kind of stuck with like, just this kind of boring screen
here. So you can't really see the sort of interactive like, oh, here's like, you know,
the waveforms and whatnot. But whatever, it's all good. We'll go over some, the 2.0 version of it
where it does offer some sexy or gooey stuff. So here's the output of our capture. So let's scroll
out, and we can see very similar to the pulse view, take this full screen, that there was actually some
data captured here, very similar to what we saw earlier. Now, let's scroll in. And as we talked
about earlier, remember, channel zero is the TX line of the Raspberry Pi. So of course, we're going to
see data. Now, a couple things is that let's say we want to add a protocol debugger, just like what
we did with the pulse view. Let's go ahead and add this. We'll say channel zero, the serial, that's
the TX channel. And let's click Autobot, right? So let's pretend for a second that we do not even
know the baud rate of this device. Let's pretend that we actually think that it's UR, but we
actually don't know if it's TX or RX. We've already actually kind of figured out that it's TX, because
remember, channel zero, we're seeing data. It's transmitting data to us. RX is a flat line because
we're not sending any data back. So we do not know the baud rate. Let's just pretend like we want to
open up like a screen session or some type of like a serial session with the device over TTY serial,
but we do not know the actual bit rate of that serial connection. So we'll just leave that
default, default 9600. We'll click this little checkbox here, Autobot. We'll keep everything
else default as well. This is all pretty standard for a normal serial interface on an embedded
system. We'll click save. We now see the async serial is here in this corner. And kind of a
cool little thing you can do also to help you figure out that baud rate. This is pretty neat.
Now earlier, I'm going to bring this up for you guys real quick. In the actual slide presentation,
I had this little table here that showed the actual microseconds as well as the baud rate
in this table. So if it's 833 microseconds, it's 1200. The bit rate is 1200. If it's 52
microseconds, it's 1,900. If it's 8 microseconds, it's 1,500. Now if we go back here, what we can
actually do is we see the actual, let's take a look here, the waveform. So from where the actual
rising edge to a falling edge of one complete uniform wave. Here we go. It's a good one.
It's super tiny, but I hope you guys can see that. 8.5 microseconds. It's pretty nifty because
that basically tells us what the baud rate is without us even having to measure the baud rate.
So if we go back to our table here, remember 8.5? 8.5 is what it measured as the baud rate.
We look here and 8 microseconds is 11,500. Remember, digital is never going to be 100%
accurate. It's going to do its best at that representation. Also, there's latency in the
cable. There's latency in USB 2.0. In this case, this is one of the cheaper logic analyzers using
USB 2.0. So either way, it's not going to be 100% accurate. It's going to be like slightly off,
but it's safe to assume that it's closest to that number than it is to any of these other numbers.
That being said, let's just do something a little wacky here and just enjoy the
luxurious features of the Saley software. I just lowered the sample time to five seconds.
Remember, if we go back here to the settings, we have it set. Let's just
see it automatically detect. It's already changed, but let's just put it back to 9600.
Imagine this is like a fresh scan. We'll power the device off
and then we'll power the sucker back on and then we'll go ahead and start sampling.
So based off of the sample rate, the Saley software is smart enough to realize what that
particular baud rate is. In this case, it already converted to us. Well, that is not the actual
bit rate, even though that would probably work. It's 11,500. It's close enough for what we're
trying to do here. So let's take it a step further and then let's switch this back over to 30 seconds
and let's power it off and then let's power it back on again. Now that we know our baud rate,
we'll just see what it can do. Let's make it full screen because you all know what a Raspberry Pi
looks like. I can't make it full screen. I'm going to sit here and just stare at this thing and boot
up. So while we're having a little break, let me ask you one of the questions. So I have a question
here. Is the Saley or the PulseView Logic Analyzer software free and open source? How would you go
about downloading or purchasing those? The Saley software, it is actually free.
It is not open source, however. It's free. You can download it straight from their website.
You can't compile it because, again, it's not open source, but it's 100% free. You don't have
to spend a dime for it. However, the Sigrock, so the PulseView software, I believe the GUI is open
source. I know the Sigrock CLI is open source because I just compiled it actually like two
hours ago. But yeah, so the Saley Logic, free, not open source. Sigrock PulseView, 100% free,
maybe open source. Sigrock CLI, free and open source.
And taking a peek here real quick, we can see in the decoded protocol section here that we actually
have the output of what we saw over the UART interface. So under voltage, it's kind of printed
funky here, but that's the actual output of what it's seeing. We had it set to the ASCII,
so the output is being displayed in ASCII format. So kind of neat. You can see all that kind of
stuff. Scrolling even further down here, we have detected, blah, blah, blah, but go to the very
bottom. Maybe we missed it, but it would even capture... Yeah, there we go, like Raspberry
Pi login. And that's basically on the UART connection waiting for the typical Pi password,
Raspberry, because no one ever changes their default on that. So anyways, as for that
particular demonstration, that's pretty much it. And kind of continuing on with that particular
question that was asked regarding the free and open source nature, are there any other questions,
I guess, up until now? Yeah, I have just one more for you. What is the
max number of logic analyzer channels needed for most IoT situations?
That's a good question. And I'll be perfectly honest, I rarely run into an instance,
I do this, you know, I'm not like hacking on IoT, like full time with my day job. Again,
I'm a pin tester. But I do it a lot, just kind of as a hobbyist, as well as just kind of as a
side type thing. There's very rare instances that I've run into a situation where I needed more than
eight channels. So in cases that I've ever used these logic analyzers, it's mostly been on three
different protocols, UART, SPI, and I2C. And none of those three, I guess, protocols really require
more than eight channels. Now, I don't want to say it wouldn't be necessary. But I would say that
it's kind of a low likelihood that if you're trying to get started as like a hobbyist,
that you'll actually need more than eight channels. And all of the devices that we're
working with here, support eight channels, you can buy them up to like, shoot, I don't even know,
I know, I know Morgan on our team has the big one, I think it's six, is it 16 channels? Is that
their biggest? Or is it the 16? Yeah, the big, the big boy. And I don't know that I would like
have a need. However, it would be super handy to have in case I ever did have that need.
But I would probably err on the side of saying that it's likely that eight
channels would be good enough for you. Okay, yeah, no more questions yet.
So speaking of which, UART, SPI, and I2C, how do they function? So as we saw earlier,
UART is an asynchronous connection. So what that actually means is that there's no
clock on either side of the connection, controlling the actual rate that data is being transferred.
It's an agreed upon number where you're supposed to actually know. So the bit rate
and the baud rate is important for that. How it determines the actual connection speeds also
is it uses parity bits. So there's basically another layer of overhead that's being sent
over the line of communication so that the negotiation and the actual transfer of data
can take place. With SPI and I2C, they're actually synchronous, meaning there is a clock
that's determining the communication time. So for instance, SPI operates on a slave master
model. So the master is the actual determination of the clock speed. That's the one with the actual
crystal that's going to determine how quickly data is going to be sent. The slave is going to
basically accept that at that particular rate. And that number is negotiated throughout the process.
I2C functions in a very similar way. Moving on to the actual interfaces associated with these
three different protocols. Again, UART has two channels. Again, the channels column here is
assuming that ground's hooked up. So disregard ground right now. This is only the data lines
and the information communication lines that's taken place that we're really concerned with here.
That's RX and TX for UART. SPI has four channels. That's going to be MISO, MOSI, CS, and CLOCK.
Chip select is enable. And CLOCK is, again, the determination of how quickly that data is going
to be sent and received. MISO and MOSI are a little bit interchangeable. It can just depend
on the situation that's going on. So with SPI specifically, remember there's master-slave.
The master will send out data to the slave over MOSI. That stands for master out, slave in.
The master will receive data from the slave over master in, slave out. The master will determine
the clock rate. And the chip select is the enable. So the chip select is only applicable whenever
there's multiple slaves communicating with a master. And then I2C is pretty simple. It's
SDA and SCL. SCL is the communication for the determination of how quickly data is to be sent
and received. And SDA is the actual data line. So moving on from that, I guess, are there any
questions maybe with regard to SPI, those two protocols, with how they apply maybe to logic
analyzers? Maybe not, because I know we just kind of just answered some questions.
I'm sorry. I was kind of muted. Currently, we don't have any questions specifically on this,
but I do want to encourage people that are in the actual channel as attendees,
please think of questions and post them into the Q&A session. Okay, you can move on, Jonathan.
Cool. Yeah, I think we had a disabled chat because we had some flattering comments earlier.
That was kind of awesome. I think Sam was mentioning it was one of the first issues
we ran into with something exciting here. But anyways, okay, so let's move on to the first
exercise. Yeah, so let's move on to the first exercise here. Actually, I'm going to skip the
first exercise. Let's move on to the second one, because we just looked at UI. Let's look at something
fun. Switch it over to SPI. Also, I want to show you the sexiness of this new Salie software as well.
And let's bring up the new hotness here. I had actually never... I didn't know that Salie
had released this new software. I think it was Morgan. So Morgan's our lab manager here at
Salie. It was either he or Daryl that had pointed this one out. But Daryl showed me some freaking sweet new features
that basically have to do with this new software. So just to give you the quick
rundown here, we still have... I'm sorry for shifting this screen around and stuff. But remember, we still
have the old school... not the old school, the cheaper end logic analyzer hooked up. We're about to
switch over to Salie though. I want to show you guys some other stuff. So this is the new Salie
Logic 2 software. So we're now at 2. And you can change the amount of channels, of course,
that are hooked up here. You can change the different protocol analyzers associated
with the connections that you're making. There's, of course, timing markers you can set. There's
measurements you can take. And this is the dopest part, is that there's an extension. It's like...
I don't know if you guys use Burp Suite that much, but this is the extender. The extender
to Burp Suite is what the extensions are to Logic 2. It's sick. You can create extensions and just
basically allows you to have a lot of plugins and stuff. So let's go ahead and swap this guy out.
And we're going to look at a completely different device. So this Raspberry Pi is going bye-bye.
I'm going to put it over there. Bunch of pile of other crap I got. And then we're going to switch
to the Salie logic analyzer. And then also we're going to look at this particular device here. So
I don't know if anyone on the call right now was at the Rapid7 IoT builds last year. If they were,
this will probably look super familiar. So a couple of things. As you can see, we have markings
for SPI connection. There you see MISO, MOSI, CS, enable, clock, that kind of stuff. There's also
some other stuff here. Disregard this. We're actually only going to use ground. This is for,
I believe, an ICSP connection. But we're not going to be doing anything with YATML today.
We're going to stick directly to the chip, the flash memory chip that we have on here.
Now, it's going to be an open book situation, but we're also going to pretend like we don't know the
pin out of this, just to kind of make it interesting. We do know it, but I'll show you
guys how you can probably make that determination. Because it's so common that, you know, maybe you'll
have like a header pins that are soldered onto the actual VIAs, or maybe they're only VIAs,
and you have to solder the header pins yourself, and you have no idea what they are. And maybe,
for instance, you have a WSAN 8. So, that means WSAN 8, it doesn't have legs. So, the flash memory
chip, it's like all the solder points on the bottom, or if it's BGA, those solder points on
the bottom, so you can take a multimeter to figure out what the actual pin out is, even if you found
the data sheet. So, kind of nifty here. I'll show what that kind of stuff looks like. So, with that
being said, let's just flip this sucker up. This is the part I was telling you guys about earlier,
where I'm just like, you're going to have a good time watching me do this, because there's actually
four cables. This is double the amount of cables as we looked at earlier. And another little pro
tip, actually all four of these cables are not required. For doing SPI, particularly if you only
have one slave connecting to master, you actually only need to connect master out slave in, and
clock in order to facilitate that connection. But just for shits and giggles, let's just connect
them all. Also, I'm going to mooch off the ground interface of this ICSP down here, just to have
something. So, anyways, very similar to what we saw with the other ones. The mappings of the
Salie are here at the bottom. You can kind of see a little blurry, but my camera's not the greatest
quality. Sorry, guys. It goes from zero to seven. And then the channels are on the top, the ground's
on the bottom. You can kind of see there how they're laid out. So, we're going to just kind of
start. I'm going to plug in ground here first. I'm going to put it in on the far end on this side.
And then we'll... I'm cheating a little bit. Remember, you're supposed to pretend. But
master out slave in, I'm going to make that zero. So, that's red. So, we're going to start red
at zero, and kind of work that way. You're kind of picking up what I'm throwing down here. So,
red, orange, yellow, green. And we need to plug this biatch in.
So, yeah, the Salie uses a micro USB. The other cheaper logic analyzers use the
mini USB, as you can see there. So, we'll grab the micro USB, again, hooked up to my computer.
Let's plug this biatch in. And you shouldn't see a light. It's totally normal to, like,
not see a light at first with this guy. And, yeah. So, let's continue on. So,
let's go ahead and shift the screen over to that side. And we should now see... so,
one beautiful thing is, I don't know if anyone on the call has dealt with Salie before,
but it's kind of a pain in the ass sometimes to deal with a logic analyzer and unplugging
it back in because you have to close the software and open it again. Well, Salie 2,
I have the software already open, as you can see here at the top. It's now connected,
the light's on. So, I think it's totally dope. But, anyways, the Salie
software here, going back to the actual device itself, as I'd mentioned earlier, it supports
both digital as well as analog. So, as you can see here, here's the digital. So, we want to put
in four. We have a total of four channels going on right now. And we'll just go ahead and do
analog and digital. We'll capture at 10 megasamples per second. And also, a couple other things. So,
there's three different ways of capturing with this particular one. There's looping. So, loop
after a predefined amount of time. There's the timer, where it will record for a period of time.
And there's a trigger. So, just to kind of demo some stuff, let's go ahead and do a trigger. So,
remember zero... actually, let's not trigger. Let's just do timer. Because we're trying to go
black box, right? So, let's assume we don't know which particular channel is which. And this is
just some blind device that we found online. And we don't know the data sheet. And it's using
something like a WSAN. So, we have no idea, like, which pin is which. So, we have all the channels
set up. We have the timer set up for three seconds of capture. Go down here. We're going to go ahead
and leave the analyzers blank. And we're pretty much ready to start capturing here. So, I'm going
grab the old power cable for this guy. And I'm set for three seconds. So, I kind of need to be
quick with my trigger finger here. There we go. So, we got full screen. All right. She's plugged
in. All right. So, we got it. Let's go ahead and zoom out here. Now, this is the capture that we
just got, right? And this is during the boot up process. So, what you see here is zero through
three channel. This is all digital. And on the bottom, it did its best at analog. And the analog,
it's not the greatest. Like, it's probably pretty accurate. And you can kind of see the comparison
between the two. Like, it tried its best at measuring those voltages, but probably didn't
quite do the greatest that it could. But either way, there's analog. I just want to show you guys
some of the analog. And it's cool to have and stuff like that, but it's not really the purpose
of what I'm wanting to show you guys right now. Now, say, for instance, that you don't know
the mechanism of... you know that it's SPI, but you don't know which pin's which, right?
So, whenever we're looking at this device, remember, the top here is MISO. The bottom's
MOSI. Channel zero is master-out-slave-in. As I mentioned earlier, master-out-slave-in
is the information that's basically being transmitted from the actual chip to us. And
it's probably going to be a little bit spontaneous. There's a lot of opcodes being set. There's a lot
of different various settings being aligned with the actual device. And typically, that's one of
the first things that'll start communicating, as we can see here. So, we zoom in. And a little bit
telltale thing is that we're starting to see some type of communication taking place right here.
A little sporadic. We also see right here channel one. Channel one, in this case, is clock.
Remember, clock is going to actually set the cadence for how it communicates. 1, 2, 3, 4,
5, 6, 7, 8. It's a full actual byte of data. That's pretty telltale. So, right here, of course,
channel zero, we have a little bit of some type of sporadic data being actually set. Channel one,
we have kind of a constant cadence of information being... of the waveform itself. And then enable,
what enable is, say, for instance, there's three slaves communicating with the actual master node.
The enable will tell... it'll flip the bit for when that device can communicate or not.
So, you'll oftentimes see... it might be a little bit of a mismatch in our timing, which we can also
fix. But you'll often see with the enable that, for instance, right here, there's basically like
a 1, 1, 1. There's three 1s right here. It's going to kind of encompass that entire
section, if that makes sense, or cycle. So, it's pretty easy to tell if you just kind of scan it,
as we just did, which one's MOSI, which one's clock, and then which one's going to be enable.
Again, enable, in our case, channel two and three is actually not even required.
So, taking a little bit of a deeper dive, let's take a look at the actual protocol in that
analyzer. We'll click SPI here. Remember, we have MOSI set on zero. We have MISO set on three.
We have clock set on one. And we have enable set on two. We'll leave everything else default,
and we'll click save. Kind of interesting, because you can actually find more deeper
information about the actual device and the settings that it's applying as it's booting up.
So, for instance, like right here, this is the actual decoded binary format. If we go here to
the settings, we can change whether it's in binary, decimal, hexadecimal ASCII, and then take a look
at the actual value. So, in this particular case, it's like one, one, zero, zero, one, zero, one,
zero. And that's the actual location where it made the determination. You can see it up here at the
top as well, where it's decoded. And what's kind of also interesting with this is you can take it
a step further, and you can pull up the data sheet of the device. In this particular case,
the model of this is the MRF49XA. It's a... I believe this one was a SOP8. I'm not 100% sure
on that, but either way, it's just an RF flash memory chip. So, let's take this code that we got
here, one, one, zero, zero, one, zero, one, zero, and let's just copy that. And then let's go back
here, and let's just paste that in. So, it's... I already had it pulled up, so I'm kind of cheating
right now. So, it's kind of interesting because you can take that, and this is exactly what a
developer would do as they're kind of producing these types of devices. They're going to, like,
set these codes, and this is going to sort of initiate the actual SPI flash storage of the chip.
In this particular case, what we saw was one, one, zero, zero, one, zero, one, zero. Let's paste that
in again. That's right here. So, we see the command code bit right there, and then we can see here
below that bit seven through four are the first in, first out, fill bit counts. We have bit three. So,
in this particular case, what you want to do is the immediate one below it is you match the next
three and then map it back over to bit seven through four. In this particular... they don't
always map, like, seven, like, in a range like that, but in bit three, for instance, like,
this guy is set to zero. Bit three, that basically says synchronous character length bit. It's set
to word long. So, I don't want to continue going down this rabbit hole here, but it's something
that's kind of cool to when, like, when you're debugging, you can kind of map it back to the
data sheet to actually figure out what's going on as far as settings being applied to the chip
itself. One other really cool thing I'm going to show everyone here real fast is we're going to
make some changes here. I'm going to go back to the actual mapping of the SPI interface.
Pretty sweet. I mentioned earlier we don't need MISO and we don't need enable. So, let's select
both of those to none. And let's do something else. This is kind of cool. This is actually a
plug-in that you can use with this. We're going to select SDMMC from SPI. So, this chip, it's not
either an SD nor is it an EMMC chip. It's just flash storage. It's not like an SD actual device
nor is it a multimedia controller. But let's just pretend like it is for a second. You select the
input to go into this particular plug-in and then we'll click finish. And if it were an SD
or if it were an EMMC, it'd be pretty sweet because up here, as you can see where I have
kind of hovering over, it'll kind of just show you the actual opcodes and the actual information
that it's presenting. It'll kind of interpret that for you. So, just kind of another sweet feature of
the logic analyzer software. I just want to kind of show you guys that real quick.
And I know we're running kind of low on time. Darrell, are we kind of towards the end right now?
No, we got time for some questions. I have a couple questions here before you move on.
So, this is kind of stepping back, but do you have to worry about sample rate with
cheaper analyzers, like missing data or misalignments and things like that?
Yeah, that's a good question. I'll try to answer that with a little demo of what that sample rate
actually means for the, like for instance, the Salie logic analyzer, which can have very high
sample rates. The quick and dirty, the TLDR I'll give you is that for the protocols that we're
looking at here, for the most part, the sample rates that these two cheaper guys support are
satisfactory for what we're needing. I mean, it's whenever you're diving into the really quick
protocols that it really makes a lot more of a difference. Because a lot of times with the
really quick sample rates, like say for instance, let's increase this to... well, I don't know if
I'll be able to, because I'll be honest, this logic analyzer can only go up to 50, but like,
screw it, let's do it anyway. Another question on there is similar to that same topic. Is there
a general rule on what samples per second selection that you actually make when you're
setting something up? There's not really a general rule. It's more of a... this is just
my own experience. Now, Daryl, you might have your own answer for this, but I would say I
typically use it for the default, just depending on what it is. And what I use this for is typically
for UART, SPI, and I2C. I would heavily be interested to hear what you have to say.
Typically, I'm pretty much the same way. What I will do is if the sample rate's not high enough,
I've actually had my Sele start throwing errors and tell me that it was missing data,
that it wasn't sampling quick enough. I had that just recently looking on some Dataflow.
As soon as I kick it off, it'd throw an error in telling me that it was a missample rate.
So, I was able to crank it up until the error went away. So, again, sometimes I'll also just
crank it up out of the blue if I know for a fact that it's a high-speed device that's going to be
generating a lot of fast traffic. Typically, when you're looking at UART, SPI, and stuff like that,
amazingly enough, the speed is often not used as even high as the chip can go. Like UART,
I've seen interchip comms on a UART that can literally... the chips are designed to drive at
what, over 3 million bits per second across there. But yet, the developers of the device
had it set up to communicate at 9600 bulb. That makes sense. Yeah. And I've also found that if
you go too high, this particular Sele does not support it. But you also don't want to go too
high because if you go too high, this, what you see right here, get out of the screen,
it'll just be a giant blob. It's just a mess. It's capturing too much sampling and it's kind
of just inaccurate at that point. So, it's a fine line between the two. And another quick point on
that also is, typically, the higher the sample rate, the more memory you're going to eat up to.
That's a point. Are there any other questions? Not at this time. Cool. And quick question,
how much more time do we have here? Just to make sure. I don't want to go too far over time.
We've been at it for an hour. So, I think we got at least another 10 or 15 minutes.
Definitely. You can definitely go for another 15 minutes. The next talk starts at 8 PM.
Perfect. Okay, cool. I wasn't 100% sure on that, but that works out great because we have one more
demo as well. So, we've talked about... we did a little kind of a cheater exercise on Raspberry Pi.
We did... I showed you guys how to sort of blindly identify SPI as well.
And then next, let's switch back over to UR. It's more of a real world example.
So, let me go ahead and unplug these guys and plug the power first on this guy here.
Let's switch back here. Make sure I don't bust off any of these header pins live on camera
because this is Daryl's device and it would suck to break it right in front of him.
And let's pull over another device. That's going to be this guy.
So, we're going to stick to the theme with the Salee. So, Salee is still going to be used.
In this particular case, we're going to check out UR, but using the new Salee 2 software.
This particular device, it's a Z-Wave hub, I guess, so to speak. So, it's a hub used in
automation. I'm pretty heavy into home automation here at my place and that's something I've always
been fascinated with. But this particular device, it's a Z-Wave hub. And let's dig right in.
So, right off the bat, something that can easily be noticed, I guess, is that on this device,
there was these three header pins. I soldered the headers on, but previously it was just three
holes just kind of sitting there. And that's kind of telltale that maybe it might be kind of
interesting to kind of poke at. It can be anything. It can be I2C. Maybe there's an EEPROM chip on
here that's disclosed or it could be anywhere. It could also not be on here. And when I mentioned
WSAN earlier, actually, I can't quite tell if this is WSAN or actually a BGA, but either way,
same difference. Sometimes you can't actually see the legs of the device to where you map it out
to say, for instance, these headers, but rather sometimes you can, which is what you see right
here. This is a traditional TSOP8. So, TSOP8, it's got the legs. WSAN does not.
And I'm pretty sure it's WSAN. It might be BGA, but I'm pretty confident that it's WSAN. This one
for sure is a BGA microcontroller. But either way, sometimes you can't take a multimeter to check
that this pin right here connects to that pin right there. So, therefore, sometimes a logic
analyzer will come into play. And then that's where it's usually beneficial to do this type
of stuff. So, let's just move on. Let's plug this sucker in and see what we get.
So, we only need a couple of connections here. So, I'm going to borrow the cables that I was
using earlier for the UART. So, in this particular case, there's only three connections being made.
One thing you can do with this is basically take a multimeter to figure out which one's ground.
In that case, let's just assume that I did that because I know which one's ground. But like,
it's pretty easy to tell which one's ground with just a multimeter.
So, and the ground is actually going to be the pin on the far right in this particular case.
So, let's hook up black to ground. And let's just hook up, you know, white and like this silver one
to the other two, not knowing which one's which. So, again, using the handy dandy mappings that
we have on the Stanley, we plug that sucker right in to ground. And then we plug in the other two
to channels zero and one. Kind of easy. And next,
let's, you know what, let's do a trigger. We're kind of gambling right now.
We're supposed to be in Vegas right now. So, again, let's do some type of gambling, right?
We don't know which one's which one's transmit. But what we're betting on right now is that
channel zero is transmit. We have no idea. So, let's just figure out that's what it was. And
what we're triggering on is a rising edge. And what that says is that whenever you see a rising
edge in the transmission, in that waveform, that's when you start capturing. So, in memory,
it's capturing the whole time. But the actual capture that comes back and returns to you
is the actual, the trigger that you set here. You can trigger rising edge, falling edge,
high pulse, or low pulse. In this particular case, let's just say as soon as you see some
type of traffic going on on channel one, that's when we want you to capture. And we want you to
capture for three seconds. Delete everything else afterwards. And we only need two channels here.
So, let's get rid of those other two. We're going to leave it at 50 megasamples per second.
And that is that. We're not going to capture on analog. So, let's... actually,
what we're going to do next is we're going to close out of that. We're going to click start.
It's literally waiting for the trigger. So, you see down there in the bottom right-hand corner,
waiting for trigger. Let's plug this bastard in. Holy shit, we're correct. Yeah. So, we...
well, we still have the stupid... let me delete these... the decoders. This is my bad.
Let me get rid of that. And yeah, if we're in Vegas, we basically... we bet like 100 bucks on
red and it landed on red because it's exactly what happened here. So, go us, right? Channel zero
is TX, just as we were hoping for. So, that trigger was met and it recorded for three seconds. So,
scrolling into here, we can see some of the data. Of course, you know, this is like the zero one,
zero one. And this is the part, as I showed you earlier, with the OG logic analyzer... sorry,
the OG logic software. We'll put input channel. We're set to zero. 11.5200. We don't know what
the baud rate is for this guy. I believe it actually is 11.5200. Remember, we talked about
how to check that. But of course, here we go. We're seeing all the data as well as part of
the boot up. So, boot SPL 2017 and just various other information that it's printing out,
standard out as it's performing the boot sequence. So, anyways, just wanted to show
you guys another example of that on the new software here. It's pretty slick. It's totally
awesome. I like it a lot. You know, it's super useful. You can see like the parity bits. This
is basically the little white dots is kind of managing the communication timing whenever it's
sending data back and forth. In this case, it's transmitting. So, anyways, that being said,
that's kind of the end of the demo here. I just want to give another example of what it means to
communicate or what it looks like to communicate using the new Saly 2 software. Questions?
Yeah, let's go ahead. I think we have some questions. Let me look at this first.
If the Saly software works for any analyzer, what would be the consideration in purchasing
the more expensive offer over a cheaper hardware option shown? So, why would I want to buy a
expensive $600 logic analyzer when I can buy a $24 logic analyzer since I could use the software?
Yeah, that makes sense. So, as we talked about the speeds, I don't want to say they're negligible,
but you do get significantly higher recording speeds with the Saly than you would do with
these cheaper versions as well. Another thing, too, is that the actual accuracy of the protocol
decoding I've noticed is higher with the Saly than it is with either of these other two devices.
That being said, it really just depends on what your needs are. In my opinion, it's pretty good
quality. Like, for instance, I've had a couple of times where I was doing some type of logic,
I was doing basically decoding and actually live capture, and I had a crash with the software with
both of these devices. So, you'll notice that it's a little bit sluggish. It's a little bit
rough around the edges. Again, you kind of get what you pay for. The communication, again,
there's been kind of like lags and hiccups with these two. They get the job done, but I've noticed
that the accuracy for how close of how it captures is a little bit more specific with the Saly.
So, if what you're looking to do is going to require you to know those voltages at more of
an accurate level, then maybe consider the Saly versus these guys. I mean, if you're just doing
some general debugging, things like that, I think these are not a bad choice. That's just my
opinion. Daryl, do you have anything to add to that? Yeah, I think accuracy is probably one of
the bigger things and the ability to process at a higher speed, I think, are the value. And that's
why I went with a higher value product. Because I personally often encounter things that those
would not work on at all, just from the fact that it's higher speed. I often get into more
interchip communication analysis, which is often at a much higher speed than external communication.
Makes sense. The other question here is a good question. Do you need special hardware for JTAG?
Yeah. You know, so if you look here, the capability exists for adding JTAG. Actually,
does it? I don't know if it does on this logic, too, or not. I'm still...
I think it does. I'm not sure.
Yeah, it does. Yeah, it sure does. Now, the question was, is there a specific hardware
needed for JTAG? In this case, if you're trying to, like, identify, you know, what is TMS,
if you're trying to identify with JTAG, what are those debug interfaces? You might have the
capability of doing it with a logic analyzer. Now, at that point, you're kind of... I don't
want to say you're putting a round peg in a square hole, but I don't know if you're necessarily using
the right tool. It has a capability of doing it like this, but you might consider using other
pieces of hardware for doing something like JTAG. Now, like, for JTAG, say, for instance, you don't
know what the pinouts are, and you're trying to identify that. That's where you would use something
like, for me personally, I would go after a multimeter first, and I would try to ring it
out with the MCU. So, I'd try to find the data sheet and use that data sheet to identify where
on the MCU, based off those pins of the MCU, where does that fall out, and use that to identify the
pinouts of the JTAG. If you don't have the data sheet, or maybe you don't know where the MCU is,
or maybe it's a BGA MCU, then you'd maybe use some type of boundary scanner. A great example of that
is the JTAGulator. Another thing that you could kind of use the Salee for is a boundary scanner,
sort of. In that particular instance, it could help you, yes. Now, if you're wanting to do something
like program an MCU, or program the device or upload the device to a flash memory to program
an MCU, then you would need some type of programmer, and that's going to be vendor-specific.
So, say for instance, it's a STM32, you could use something like a ST-Link device. J-Link supports
OpenOCD in a lot of cases, so it can support multi-manufacturers. If it's like an Atmel,
you'll want to use like a Pickett. So, if you're wanting to either dump or flash some firmware onto
an MCU or flash memory, you'd use whatever programmer is assigned to that particular
chipset. Outside that, you can use a logic analyzer for doing some like limited boundary
scanning, but that's kind of not really why it's designed, but the capability exists.
Yep, and on conclusion, there was one comment, there are a couple comments in here I thought
were funny. One was, it would be funny if someone designed a board with a honeypot header that had
50 volts on it. So, Jonathan would hook up his $300 logic analyzer and watch it burst into flames.
Dear God, yeah, that would fry the man bun right off my head.
So, I thought that was a funny comment, which is definitely the level of evil I would expect from
DEF CON, so thank you for that. And then a couple comments saying you did a good job,
so that was pretty good. So, are there any more questions from anyone as we're getting ready to
conclude? Wait, I think there's one more. One was asking more like model numbers on those cheaper
ones. Do you have that information? I think those are so generic in nature. You know what I'm talking
about, the two cheap logic analyzers. Is there any kind of information on there for acquisition? I
think you had a page that actually showed the link or information to the actual Amazon site.
Yeah, let me see here. I'll actually just real quickly do one even better for whoever asked
the question about that. Amazon.com, if you just search logic analyzer. I mean,
one of the ones we're using is like... I think it was the first one in the
list showed up there at the top. Yeah, that's one of them. If you go up to the top, I think the first
one in the list was one of them we purchased right there. That's one of them. That's the I let go USB
one. I actually have the other one too. It's kind of funny because it came with the
Edify toolkit or whatever. It's got like a red face to it. You may have called any number of
different names. Oh, it's SparkFun. Yeah, SparkFun. Yeah, SparkFun relabels that Chinese one.
Yeah, it's this one. So I mean, just go online really. It's kind of like here's one of them
and here's the other. And it's just you just Google or not Google Amazon search those two.
I'm pretty sure this is exactly both of them. Yeah, perfect. Thanks a lot. Let's see
any more questions. Are hand tech any good? Have you messed with a hand tech before?
I'm not too sure. Hand tech logic.
Oh, oscilloscope or the logic analyzer? Probably logic analyzer since this is a logic analyzer.
I have not. Well, you were there a minute ago before you checked on the
oscilloscope. There was one showing up there as a logic analyzer. I'm sure. And then EK, TEK.
Because we're quickly running out of time here, but...
Oh, I've seen pictures of these guys.
It looks... I mean, it's got two gigs of DDR2 memory. I mean,
it's hella better than I think what any of the Salies have. So,
they're quick and dirty real quick. But that one, that's a very high sample rate,
and that's a lot of memory. So, higher the memory, the higher the sample rate,
the longer you can capture, and the more pinpoint accuracy you can get in those captures.
That's probably, I guess, my two cents on that particular one. And it looks cool. Looks dope as
hell. Yeah, I haven't messed with one, so... Okay, I think that pretty much concludes it.
Hopefully, the people that wanted to ask questions were able to ask questions.
Feel free to reach out to any one of us. Jonathan, you can reach out to him anytime.
He's available. I think he's on Twitter. Do you get your Twitter ID out there, man?
Yeah, Twitter ID, frankensteiner. There you go. Good luck remembering that.
So, if you ever want to ask him any questions or harassing, there you go.
Yeah, if you want to figure out what my address is, I'll honestly just give it to you,
if you're really that curious. You don't have to do whatever, Google it or whatever,
like the person did at the beginning. Well, hey, thank you so much. I think
there might be a few extra questions. So, if either of you have time to jump into the
IOTV Talk, Questions, Text Discord channel, there's definitely people that were pretty
engaged with this talk. Despite the technical difficulties, this was our first and only live
presentation that had any issues. So, I mean, what are the chances of that? It's like getting a bird
pooping on your head. Maybe it's good luck. Nice. It is good luck.