Thank you everybody for coming and waking up at this ungodly hour on a Friday morning.
I was sort of expecting the room to be empty, so thank you guys for coming and choosing to listen to us for an hour or so.
Yeah, I think the ideal DEF CON should be, you know, be three weeks long and there'll be one talk at like 4 p.m.
Yeah.
All right, well, my name is Joe Grand, and this is Zaz.
I'm Zaz Brooks, yep.
And we are going to talk about a project called the Beast Automizer HD.
This has been a very difficult project, and we're going to show you some pretty fun stuff with also some pretty disgusting videos.
It's going to be great.
So, basically, this project came about, we'll talk about this.
We were working on a project, Zaz writes a lot of software, I design a lot of hardware,
and we thought it would be fun to sort of do something again together and come up with a new ridiculous project.
So, before we even start, while everyone's waiting.
While everyone's still paying attention, what we ended up doing, and you're going to hear the whole process,
but we started working with something called FPGAs, and we'll get into that.
And this was like a really, really complicated thing, something we'd never done before.
This project wouldn't have happened at all if it wasn't for some serious help from some friends of ours
that really their name should also be on the title, you know, of the presentation and stuff.
So, these guys, Chris Benson, Lead Bunny, who runs the Hardware Hacking Village,
suffered through some extremely late nights this past week trying to help us get stuff working.
Rivas and Parker just helped us with FPGAs, so it really shows the power of, kind of, the community and people willing to help.
Yeah, Longhorn Engineer actually gave us some software that enabled us to first convert an image to the memory initialization stuff that we needed to put in the FPGA.
So, even the very start of this project really wouldn't have happened without these guys helping us out.
Yeah, a lot of swearing on IRC.
Alright, so the original Beast Automizer, for those of you who happened to sit down on the talk at DEF CON 16,
was our original project together.
That was a hardware-based, man-in-the-middle type of device that you would put in between a laptop or desktop and a monitor.
And normally it would just pass the video through just fine.
But you could remotely trigger it with a remote control or set some dip switches on the board
to have it trigger at certain times and switch, intercept the video, and throw up a preloaded fake blue screen of death.
And that was, at the time, it was when the Parallax Propeller was brand new.
So, a lot of people know the Propeller from...
a later DEF CON badge.
But at that time, no one had really used it for much and it had just come out.
It was really exciting.
It works a lot differently, if anyone here has played with it, to a normal microcontroller.
And it was capable of going fast enough to generate a VGA signal.
But, fortunately for the Beast Automizer, the original one, old Windows Beast Odds, of course, are just text only.
And that's all the mode that the original Beast Automizer had, was to be able to generate a 1024x768 image of only text.
And if you want to screw with people, everything's open source.
The links are at the end of the presentation.
You can still build your own and use it.
And this was really a good learning exercise for us.
We like to screw with people, but we also like learning things.
So, this was like an attempt for us to learn about the Propeller and then really annoy people.
So, somehow I got roped into this.
Zaz had this great idea.
He's like the visionary.
He said, we should do another DEF CON talk.
Let's do the Beast Automizer HD.
You know, technology has increased.
Let's do something different.
Let's learn about FPGAs, which is something that really I wanted to learn about,
but I'd kind of been putting it off for a long time because I knew it was going to be hard.
And this was sort of the catalyst to do it.
And it's like, all right, whatever we get done, like, we'll share it with the community, of course.
And, you know, maybe whatever we come up with will be useful.
Yeah, there's a lot of exciting stuff once you move to an FPGA because you're creating hardware in hardware with software.
It meant that we could do a lot of things with an updated system.
So, it'd be Sotomizer that the first one couldn't do because the first one just generates a text screen.
With an FPGA, as well as injecting full screen graphics, we could also do some other interesting and exciting things, which we'll get to.
Yeah, and that's something that as soon as we decided to do this, the first thing we had to do was figure out if we could even generate video on the screen.
So, it was like, all right, let's try to figure out some things.
Do a little bit of kind of pre-development work before we submitted the talk to DEF CON and, you know, for Black Hat Tools Arsenal and all this stuff.
So, we sat down and said, what can we do?
Well, FPGAs can generate HDMI video.
So, let's try to do 1080p.
That's more of like something people use now, HDMI, instead of VGA.
Though, it's funny because when we had released the Beast Sotomizer, we were trying to get it sold through, like, ThinkGeek and, you know, a lot of hardware places to distribute them to people.
And everyone's like, no one uses VGA anymore.
But people really still use VGA a lot.
So, you know, it's something like HDMI even though, you know, we're going to move to DisplayPort.
And other things, like, it will still be a valid option.
Well, it's funny.
Like, you know, everyone's a hater, right?
So, when we said we were doing this to a few people and we're doing 1080p, they're all like, what?
No 4K?
Yeah, I know.
They're like, well, I think people are going to keep using 1080p for a while.
Just relax.
Okay.
So, some of the features we wanted.
1080p, we thought it would be cool to have user-loadable images from an SD card.
So, instead of just pre-loading something in advance, you'll see that we didn't get to all of this stuff.
We set some pretty lofty goals.
We wanted to do some animations because now we're able to write directly to HDMI reading from memory.
We can basically modify memory in real time and have a new image come up on the screen or have a slightly modified image come up on the screen.
So, there's a lot of possibilities for the mischief side.
One thing we had really wanted to do in the original one is because it had some switches to switch between Windows and Mac mode.
And then Mac kernel panics changed to, you know, scrolling down the black thing.
Which we just, there's no way we could do that with the original one.
But, yeah.
With the one we have now, we have the capability to capture the screen and you could edit it in memory and scroll down the gray overlay to say it's crashed.
Reboot.
Yeah.
Once we get the receive part working.
So, we figured, well, you know, the other tool was very mischief focused.
And, yes, you could use it for pen tests.
Some people use it like they, you know, walked into a building, put the beast automizer in place, and then had it say, like, surprise, we were here.
Or whatever.
But we thought, okay, let's see if we can try to legitimize it even more.
Given how huge pen testing is now in red teams.
Like, let's see if we can try to do capture.
And this idea actually came after we had gotten some of the HDMI transmitting working.
We're like, well, it doesn't seem like it would be that hard to receive a frame at the same time unknown to the user.
Because we could split the signal off, which you'll see in some drawings.
And capture the HDMI stream at the same time as it's going to the sync, to the monitor.
So, that's sort of a future thing.
You'll see we kind of ran into some issues there.
But the base functionality is there.
And it's just a matter of kind of tweaking some of the code.
The hardware support is there, which is pretty rad.
And then, you know, we were like, well, you can do some video display calibration and whatever.
But really, I think the most important thing is having, you know, another open source tool.
Something people can learn from and take our chunks of code.
Like, we are totally FPGA noobs.
And we hacked a bunch of stuff together.
But we've written some solid modules that people can take and put into their own projects.
And that's the beauty of FPGAs, which we'll get into.
So, HDMI is, you know, of course.
The video standard of choice, I guess.
The issue here is that HDMI is very high speed.
And, you know, we all take it for granted if you plug something in and it works.
But the signals are very, very fast.
They're differential signals, meaning you have a positive signal and an inverted negative signal that travel together.
And the pixels, the bits are being sent at a very high speed.
That's done for noise immunity and for other electrical issues.
So, basically, the things we're concerned with for the Beast Automizer
are the three video lines and a clock line.
There are some other things with HDMI.
Some digital control lines that are used to communicate with the monitor and some other things.
There was a DEF CON presentation last year, the year before, on fuzzing devices that have HDMI.
So, fuzzing monitors through the digital control interface.
We're just looking at video in this project.
But that could, you know, be rolled into it if that's what somebody wanted.
But so, you know, if you do the math, you're pushing over, you know,
around 120 million pixels a second at 60 hertz.
So, that's just a lot of pixels.
And if you look at the actual bit rate, it's 3.6 gigahertz.
So, there's just no way that you're going to find a microcontroller out there to do that.
Yeah, and FPGAs, as we'll talk about, are designed to sort of do heavy lifting of digital functions.
So, if you wanted to have, you know, you could take differential signaling in and process it.
But you'd need a really, really high speed, powerful device.
So, we, you know, decided we had to figure out a way to be able to process video
and generate it in some sort of timely manner in real time.
And dealing with the straight serial data is hard.
So, we ended up focusing on a system that we can now get a pixel clock of 148.5 megahertz.
And that's going to simplify things a little bit by looking at parallel data.
I should read the slide instead of doing rough calculations in my head.
So, nearly 150 million pixels, not 120.
Yeah, close enough. It's early.
Alright, so FPGAs, this is just a little bit of an intro slide.
You'll sort of see our suffering through this.
But FPGAs are field programmable gate arrays.
And it's an electronic device that basically is like a blank slate of digital logic.
So, you know, microcontroller systems, computers, all the digital things we use are based on low level logic.
Digital logic that's basically processing ones and zeros and doing stuff.
So, CPUs are built up of millions of gates or logic.
FPGAs let you be the artist and sort of fill this canvas with whatever you want.
As opposed to a microcontroller, you know, that's running things step by step.
You have your program counter doing things sequentially.
FPGAs can do things in parallel.
And you're not writing software, you're writing hardware.
Which is a great combination for us to sort of merge the two.
And it's sort of like, and stuff is executing in parallel synchronized to a clock or to different clock signals.
And it's a complete mind fuck if you come from the software side or embedded system side of how a system is working.
For example, if you're a software person and you're used to putting a value in a variable
and then using that variable and reading it back and having the new value be in that variable
then you'll be surprised with FPGAs because everything happens on clock ticks.
So, within a block of logic, if you set, for example, a value in a variable
it doesn't actually take that value until the next clock tick.
So, if you refer to that same variable in the same block of logic, it's still got the old value.
So, there's just like a lot of ways for a software person that's used to a normal programming language to fuck it up.
Yeah, and one of the things, I tried to explain this to my kids
because Zaz had come over a few times to work on this project
and we were slaving away for hours, you know, up until 2 and 3 in the morning.
So, my son comes in one day and says, Daddy, what are you working on?
So, I tried to explain it and I said, well, we're trying out a new piece of hardware called an FPGA.
It's much different than what Daddy normally works with, which are microcontrollers.
I said, you know, microcontrollers, you can, you know, pat your head first, rub your tummy second.
FPGAs, you have to do both at the same time.
And he tries it and he's like, oh, that's hard.
I'm like, yeah, that's why we're staying up so late.
So, yeah, so FPGAs really traditionally have been very, very, very complex systems.
The development tools have not been free.
They are definitely not user-friendly.
But they're becoming more accessible.
And this is something like you can look at projects now
and you might see an FPGA on there to do, say, some hardware acceleration or some crypto or video generation.
And then usually there'll be a microcontroller associated with that
to do the normal microcontroller stuff
that doesn't have to be in an FPGA.
So there's two hardware design languages that you can,
or hardware description languages that you can choose to use.
One is VHDL.
For anyone who's done any programming for the DoD, it's a lot like Ada.
It's got some sort of strong typing.
It'll stop you from shooting yourself in the foot in certain ways.
And then the other one is Verilog, which is sort of more C-like.
And just like C, it'll let you make all kinds of mistakes and not warn you.
It's horrible.
So partly because we've done a lot more C recently.
Actually, my first programming language was Ada,
but I haven't programmed in a long time.
And also because of the tools that were available for the FPGA we were using,
we used Verilog.
And really, there's just lots of things that it won't warn you about.
You can refer to signals that don't exist and do all this kind of stuff.
You can put a typo in.
What was the one where you were using a different clock
and it was just like a typoed clock?
Yeah, I made up a clock name because I typed it wrong and the system didn't tell me.
So probably four or six hours of trying to figure out what it was was the wrong name.
And to make matters worse, with development systems,
as the complexity of the logic you're trying to compile and synthesize grows,
the time it takes to compile and synthesize grows.
So when we were working on the project,
it basically took between 10 and 15 minutes per compile
to synthesize our code, put it into the FPGA, and then execute it.
So you can imagine the boredom of sitting there while it's compiling,
and we would end up...
So you make a change, you compile it, it runs, it doesn't work.
Now you make another change, you do it again.
So we would try to fix our problems that we found
while it was compiling and do it again.
But it led to the thing of like,
which problem are we fixing and what new things are we introducing
that are going to cause another problem?
Yeah, and just if you have to express,
like if you're used to just tweaking a tiny thing
and quickly testing it out and iterating fast,
you just can't do that when you have a 15-minute compile time.
It's like you try four different things and there's an hour gone.
So one other thing with FPGAs I want to mention is
there's something called IP or intellectual property
that are basically logic modules that you can buy
or license from other companies.
So for example, if we wanted to,
like with our development board that we have,
Altera makes something called the NIOS processor,
which is a CPU, some architecture, I don't remember what,
because we didn't use it.
But you can license that from Altera.
So now you can have a microcontroller inside of your FPGA
to do microcontroller stuff.
You write code and see.
So if you're reverse engineering a piece of hardware, for example,
and you find an FPGA in there, you're not going to know what it does
because it's literally a blank slate.
The problem though is that we didn't want to design anything
that required licensing IP because that's totally lame.
We wanted to do something where all the logic defined what it was
and not rely on that.
So a lot of the example code that came with the development board
was all based on this NIOS CPU
that we didn't want to pay licensing fees to.
So we had to create, you know,
our own lower level interfacing.
But the beauty of the FPGAs is that you could go out
to a place like opencores.org
and choose things that are open and free
and integrate those into your products
and basically make your own custom chip.
We also thought it would have been kind of cheating
for us to just drop a microcontroller in the FPGA
instead of doing everything by hand.
We should move a little faster here.
I guess the takeaway here is that FPGAs are really hard.
Okay.
So the process is, you know,
first thing we like to do anyway is put together a block diagram.
This is an early one that doesn't hold true too much.
And I'll show you a better kind of connectivity graph
of how things go together later on.
But the two main things we needed to work with at first
when we started the project was find an FPGA
that had some sample code that was accessible,
that was available.
Zaz came over to my house for a week
and we basically had four days of time to source the starter kit
to figure out what FPGAs are, you know,
what we want to do, and then get the thing in hand
and see if we could generate some video.
Yeah, at this point we hadn't decided to submit to anything.
So it was like, okay, we've got one week,
let's get a dev board, get it up and running,
prove that we can do the thing that we are going to say we're going to do,
the main thing, the injection,
and then we can, you know, know that we can get it done.
So this board has a lot of functionality on it.
It's a very powerful part,
so we don't actually need all that power,
but it's better to start large and sort of cut back.
But it had, you know, some dip switches
and things that we can use for our triggering,
like a CPIO that's going to be useful for the HDMI receive.
It also had what's called an HDMI transceiver, or transmitter.
And what it does is take parallel data that the FPGA gives it
at the pixel clock of 148.5 MHz,
serializes it into the high-speed HDMI format,
and pipes that out.
So now we don't need to generate 3.6 GHz bit rate signals,
which you could do with some FPGAs,
but they're going to cost you a lot of money.
So using this one, now we have this chip
that takes the FPGA data that we're generating,
passes it through, feeds it out to HPMI,
which now sounds like, oh, it's easy,
all we did was pipe some parallel data through,
but that's not actually true.
We thought it was going to be very easy.
It definitely made it easier.
So here's what the early proof of concept looked like.
It was the development board
hooked up to HDMI.
You can see, like, some extra hardware along the side.
I'll talk about that.
But it was some unique kind of power things
we had to deal with.
So, yeah, we talked about the, you know,
FP development being slow, tools are hard.
But the goal was to figure out
how to draw something on the screen.
So the sort of main thing
that we had to do here
is the block memory inside the FPGA
that we had
is only, I think, 512K.
So not big enough to hold
a full frame buffer of a color 1080p image.
So what we did instead
was put in a monochrome image
because there's only two colors
on a blue screen of death.
So as long as we can display a B-side, no problem.
So we loaded a monochrome image
and then just set, instead of black,
to the Microsoft blue
that the slide's background is.
And to do that,
you know, we had to start with a source image
and convert that
to what's called a memory initialization file,
which is this thing that the FPGA takes
that just fills up that block RAM.
So you
have to
put it in the format that it needs
with the right headers
and the right size for the block RAM.
So that really helped us out that week
because he had this image-to-myth function
that he'd sort of half written.
It took in certain kinds of images
and certain kinds of bit depths
and he gave us that
and then we forked that
and made it do the things that we need to do
to generate the 1080p,
or to load the 1080p monochrome image.
Which his was designed for a Gameboy.
He had hacked a Gameboy to take the parallel data
that was going to the LCD
and then port that to a larger screen.
So he was only looking at four colors.
He wanted the code to basically take in a bitmap
and then pack it into
a one bit per pixel 1080p
because that's, like he said,
the only amount of space we had in the internal RAM.
And putting things in internal RAM is good
but it's sort of a pain
because you have to preload as you compile the FPGA.
So that's one example
and one function that we have in the tool
but not the ultimate one that we wanted.
But that was the one that we first
could use to prove the concept.
Yeah, the problem with doing that
we want the thing to have a bunch of different modes
and so using just the internal RAM
that gets loaded
at the time that the FPGA is compiled
and so you'd be limited to that
just that one image
if you did it that way.
Which is okay because that's what you get for now
because that's as far as our code gets
but the functionality and the hardware is there
to do more which we'll talk about.
So the other issue is we got the FPGA board working
we could display some video
and we'll go through some of the pictures
but one issue we had is
how do we power the thing?
So if you have a USB cable
that you're going to inject in somebody's
place or facility
you don't want to have to plug in a power jack
to it or a wall wart
or plug in a USB cable to get power
because that's just lame.
So the original Beast Automizer had a
you can see the clip here
for two CR2032 batteries
the same ones that are on the DEF CON badge this year
and that's because you don't get any power from VGA.
This time we're really excited
because we're like yeah you get 5 volts from the HDMI
it's going to be super simple
and we looked up the spec
and you can only get 55 to 100 milliamps
of power off that 5 volt line
and we're like fuck, right, shit
we're thwarted here
and we looked around and there's a lot of devices
that violate the spec
there's like sketchy Chinese HDMI devices
that just don't care
so a lot of HDMI supply devices
will sort of let you
violate the spec
but we wanted to do it right
and make a device that followed the spec
especially because if you're going to use this
you don't want to plug it into some machine
and have it cause problems
and have someone notice it right away
Yeah, you don't want to interfere with the target
so we had to figure out a way to get that working
and it turns out as you'll see the block diagram
we ended up designing a front end board
that handles a lot of the timing
the remote triggering and stuff like that
and we have a circuit on there
that basically will allow normal pass through mode
of the HDMI signal
and charge a battery
trickle charge a battery
while the system is technically off
and then when the user
will trigger the BESOTOMIZER
that enables the rechargeable battery
and the battery itself powers the FPGA board
and just turns it on when it needs to
through a single line to a MOSFET
which is kind of cool
so we'll get into some details of that
but that was a way to overcome the power sourcing issue
is have a battery and just have a trickle charge
and it will last many hours as you'll see
so yeah
the 1080p 1 bit per pixel
our first test
this took a few days of time to get going
my flight back got cancelled
due to storms in Houston
I had an extra day on the week
and that's when we got it working
we didn't quite make the original week
but I had that extra day and then we got it working
and it was just like being back in the 80s
and driving a CRT screen
where you'd compile everything
15 minutes
you'd hit the button
and then the vertical hold would be off
and the image would be scrolling crazily
or it would be smeared across the screen
and you'd be like what the hell is going on here?
just like I'd written an Atari 2600 game
10 years ago I guess now
just for fun
and you have to deal with tracking the scanline
before you draw your graphics
it's the same thing
we need to know where the scanline is
what pixel we're on
so we don't end up having timing issues
and this is really when we started
once we got an image on the screen
we're like yeah
but then once we started debugging it
we're like fuck
that's when we realized how hard it is to work with FPGAs
at least with Altera
is a logic analyzer
that you can compile into your code
so you're basically looking at gates
and at nodes inside your chip
but every time you add a new node
and you're like oh I wanna look at this line
you have to recompile it
so it's very very hard
and we ended up using it
it did save our ass at the end
but it was a hard process to get through
like why is the pixel shifted
and everything
so these are sort of the
really you know
that line of pixels is properly vertical
but you can clock off
a lot of things on the FPGA
and one problem we had was figuring out
what line we were on
and we were clocking off the pixel clock
and we were like why aren't things on the right line
of the display
and it turned out it's because the pixel clock keeps counting
during the horizontal blanking time
there's no real reason you have to do that
digitally but it's just like old school
like how you would redraw
parts of your frame in the horizontal blanking time
to counteract the fact
you didn't have enough memory back in the Atari days
and do processing in the time where it's not drawing on the screen
so there's still some function for that
and I think it's sort of a holdover from CRTs
but once we solved that problem
now we could actually display something
that we had preloaded into the internal RAM
which was killer
so here's our like first little
b-sod that came up
I don't remember which version this was
Windows XP?
Yeah maybe, I'm not sure
this might be actually a b-sod from the original
development, I'm not sure
this is yeah
I don't remember what year that was
so what we did then is
alright we had
this is where it gets really bad
we had the proof of concept working
ZAZ was like about to leave
and we're like well we need some video
to submit to DEF CON to show that
we can at least generate video
and then we'll worry about everything else later
like once we can do HDMI the rest of it is going to be easy
which was so not the case
and I think we sort of got suckered because even though it was hard
we got it
and we're like yeah this is
FPGA is nothing, piece of cake
so we needed to make a video
and my wife happened to be around
who's not very technical
some of you guys might remember her from calling me when I was on stage
talking about the DEF CON badge from a long time ago
and she was pregnant with our first child
and I had my phone on and she calls
and there's like 3000 people in the room and stuff
she's been here a few times but she's not technical
we're like can you just like pretend
to be using your computer
and I will manually
and then you'll see a blue screen of death
and this was
you probably have seen the announcement
that the new Wintan B-SODs are going to have a QR code on them
so it was like this is perfect
we'll generate one of these new fangled
B-SOD screens with the QR code
and get her to scan it with the phone
and then we can
use that QR code
to send her somewhere that she won't expect
so we basically told her
use this app, scan the QR code
pretend, just act it out
and in time where it goes from like very obvious acting
to very obvious like
WTF is going on
so here's the first of three videos that we have
that we'll show you throughout the presentation
so first thing we're going to do is
essentially just
we're going to
make a weird
sound effect
so this is
our
hidden
a
random
sound
thing
and it's a
an
a
So she basically was like, what the hell is this?
This is the dumbest thing ever.
If you guys actually focused your time on doing something useful, imagine what you could do.
So she had no idea about QR codes and the fact that you could preload it with a malicious URL.
So imagine if you're actually using this for a pen test and have somebody scan a QR code
and then go to a malicious website, pwn their phone, whatever it is.
But the Rick Roll was classic as she had no idea what it was.
Okay, so we had that working.
We submitted the talk to DEF CON.
Now we said, now we need to actually try.
We need to try to get done other functionality.
And that consisted of making sure we could power it, making sure we had a way to control it
instead of using dip switches.
We didn't have enough space in block RAM for the full 1080p 24 bits per pixel.
So we needed a way to use external DDR2 RAM, low power DDR2 SD RAM, which is on the development board.
And we figured dealing with the block RAM was easy.
So how much harder could it be to deal with external memory?
And we were way wrong about that.
Okay.
So we wanted to have an SD card so you could preload images and with the screen capture mode, save those images back.
And as you'll see, the hardware is in place again.
The code, not quite.
But all of the heavy lifting kind of low level memory reading and writing and displaying is done,
which I'm really, really happy about.
So the rest of it, which is funny, I say this every time, shouldn't be that hard.
But we'll see if that happens.
And we needed to combine it into something that was useful.
So the main thing is...
As we mentioned with the power consumption, the FPGA is the thing that draws all the power.
So we want that to be basically off as much as possible while the battery is trickle charging.
So to do the front end, the front end's got to be...
Because we wanted to trigger it with an infrared remote control,
something's got to be awake all the time watching for the infrared signal.
So we decided to use a PIC for that because Joe had a board he was working on shortly prior to that
that was all already set up with, you know,
broken out for development.
So we just used that board to make our lives easy and save time
with the IR external trigger, the part numbers there,
and also the timer mode.
So the front end PIC keeps track of time for timed mode.
So, you know, for when it just goes off after 10 minutes or so.
And it also monitors the battery level.
Yeah, so what we can do is you can, you know, trigger the B-SOD,
but then have it not actually go off for 10 minutes or 30 minutes or something.
So you walk away and do it.
Really, with the front end, what we have is just that single line to enable the FPGA.
So if you wanted to modify this and say, well, I want to use Wi-Fi
or I want to use Bluetooth to remotely control stuff,
you can and just, you know, feed in a different output to that FPGA and move the PIC.
But this is all low-current stuff that's running all the time.
The original one, we just used Sony TV codes because everyone's got a TV remote control.
But for this one, we thought, well, this was Joe's idea.
People, if you're walking around,
if you're in a facility with a big, fat TV remote control, you know, in the office,
people are going to be like, what's going on here?
So it would be cool if it would use the more covert remote.
And now you can get a lot of these little Apple remotes surplus from various, you know, surplus places.
So Joe was like, all right, I'm going to order a bunch of Apple remotes
and let's figure out how hard it's going to be to use, you know, trigger off this
instead of using a standard TV remote.
Yeah, and a lot of the information online that we found about the infrared remote for Apple,
people have reverse engineered them, but not a lot of the information from the different websites,
you know, is lined up.
Some pieces did, and we ultimately just created our own kind of brute force decoding mechanism
and then just identified where the signal was sending, the command signal for the six
different buttons that we were using.
Yeah, you can see on that oscilloscope trace there, basically how the format works.
It's a transmission protocol called NEC, which is not the version, not the protocol that
we thought it was going to be initially.
But there's like, there's this one sort of long pulse to begin with, and then there's
a short space after that.
And then it clocks the bits in, and it's just the width of the pulses is the width of the bits.
So looking for that sort of start pulse and space gets us started.
And then all these bits came in, and we couldn't, a lot of what those bits are, we don't know
what they are, the stuff online is contradictory and confusing, but we figured out the space
that uniquely defines which of the six buttons is being pressed, and we just read those out
once we figured out that the bits are in the reverse order, which also wasn't documented anywhere.
Yeah.
So I should mention, too, that the front end, the microchip pick stuff, is standard
microcontroller written in C. So you could take this code, you know, that we've done
for Apple decoding, if that's all you want to take out of this presentation, take it
and plop it in something else to now decode Apple Remote.
So there is some stuff in C that's a little easier to work with.
For the HDMI receiving, we're using an ADV7611, so basically the opposite of what we're doing
for transmit.
We're transmitting, we're pushing in parallel data, getting serial out.
This, we're receiving.
We're receiving the serial data from a chip, and then the parallel data goes into the FPGA
that can then be clocked in and ultimately stored into memory, which can then be used.
There's a board called the HDMI Lite, which is a project that somebody put together that
takes HDMI in and kind of just very simply reads some of the color pixels around the
edges of the screen, and then turns on some RGB LEDs around his bezel of the screen to
sort of extend the color, which I think a lot of TVs are doing now.
So we use that as a breakout board, sort of a reference board, since we didn't have time
to make our own board to get stuff done.
So we use that one and then hook that up through an interface board to the FPGA.
So we have this stack up that you'll see.
It's pretty wild.
And for this, we use my PC board prototyping machine, which generally is good for creating
lots of interface boards.
And we ended up with this, with a standard board, just taking one set of pinouts and
converting it to another.
But the trick is that we had to deal with 12 mil traces, 12 thousandths of an inch,
which are pretty small.
Not so small.
Like when you're getting a PC board professionally fabricated, that's not a big deal.
But when you're milling stuff, because this basically is milling traces out of copper,
there's a lot of mechanical stress, and those traces end up being very small.
And what ended up happening is, as I was soldering the connectors on, the glue between the copper
and the fiberglass of the circuit board was getting delaminated, because those traces
were so small, there was no solder mask to protect the traces and stuff.
So I ended up having to go in and manually repair stuff on a .1 inch header, double row
header, it was a nightmare.
But now it works, and we have hardware interfacing, so that was just another part of the stack
up of circuitry.
Yeah, and that took the smallest milling bit that the T-Tech takes.
And we broke a milling bit, then we had to hand-fix everything, so it was just another
step where it was like, oh, here's an easy thing, let's just spin out the circuit board,
and then next thing it's 2 in the morning and we're all swearing.
But without that, that would have been an issue, because we couldn't hand-wire that
board, because the speeds of the signals, like 148 megahertz, seem slow, but it's still
pretty fast.
And if we were hand-wiring things, if the lengths of the traces were longer, some of
them were longer, some of them were shorter, that could introduce some timing errors.
If there was any sort of noise that was picked up by longer traces, so we needed to have
some sort of carrier board.
We had some other subsystems in there that I'll show you in some pictures, but really
I wanted to show you the actual prototype that is also on the stage, and that was used
to create the next set of videos that you'll see, is what I call the Circuit Board Sandwich.
Yeah, wrong sandwich picture, Joe.
Oh, oh, sorry, okay.
This one.
There's the real Circuit Board Sandwich.
So this board is the stack-up.
Down at the bottom, we have the FPGA board.
Up there is the HDMI light board that we're using for the carrier.
There's also the interface board that you can barely see.
You guys are welcome to come up and take a look at this after.
There's the PIC front-end board, that whole board up there that has the infrared remote,
the battery charger.
There's the battery charger.
There's the HDMI splitter.
So when we're doing HDMI receive, we need to actively split the signal, because if you're
tapping into high-speed signals, you could introduce noise and glitches and other things
just passively.
So having an active splitter means you can pass the HDMI signal to the target monitor.
The user would never know, and then you're sucking off the HDMI to do your capture on.
So that's what that board's for.
And then there is the HDMI switch, which is switching between the target system and
our generated HDMI signal.
So I'll leave these in there.
I'll leave these in here for you to review later, just some drawings of how to understand
how the system goes together.
And these are really helpful for us to graph and sort of put down on paper what was happening.
It was a very confusing process.
So current measurements, yeah, we basically, with our battery, it's a lithium ion.
It's about an inch and a half, or maybe two inches by two inches, 2,000 milliamp hour.
You can run for about three hours of active generating HDMI.
That's never going to be the case, right?
Because you're going to throw up a B-SOD.
And then you're going to have to go back to the battery.
And a minute later or less, somebody's going to turn off their computer, the system's going
to reset, and then it will go back to pass-through mode.
So you can get a lot of battery power, and then, of course, it's going to charge while
it's not being used, which is most of the time.
The main challenge we had was dealing with the external memory and getting external DDR2
working, where now we're dealing with 24 bits per pixel, 32-bit words.
To simplify three weeks of complete pain and tears and suffering and everything, what we
ended up having to do is double the speed.
We had to double the speed of the clock signal going to the external memory, and we're basically
clocking things twice as fast to the memory as we are to the screen.
So we can read data faster from memory, put it into a FIFO buffer, and then as the HDMI
transmitter is ready for it, it can grab it from the buffer.
So we're sort of preloading a cache, I guess, if you will.
And this was something that Lead Bunny had helped out with, some serious stuff.
We had to implement a burst mode of the DDR2, which basically we were reading 128 bits at
a time.
We tried to do pipelining, and it was the worst experience of my life.
But now that it works, it's awesome, and we learned a lot about the development tools
and stuff.
But here's sort of some videos.
You saw some pictures, but this is basically like a week before DEF CON, and we keep seeing
like, oh, my God, we're close.
We can kind of see things, but it's like...
Yeah, so this is after a successful write to memory.
That was working just fine, but then reading it back in, we get video after video after
video like this.
And writing it is actually easier, because we don't have a time barrier.
We don't have a time constraint of trying to draw to the screen.
But what we needed to do here is drawing to the screen by reading the memory and then
writing it in real time.
So eventually we got stuff working, and this was sort of ZAWS in the midst of some of our
debugging early on.
And yeah, so we basically are like, FPJs are really hard, they suck, but there are
actually good practical uses for them, right?
So there are uses for them, and it's just picking out the useful things, especially
things that can't be done in secret.
So I just wanted to throw this picture up.
You can't really see it, but you can generate what's called an RTL, which is basically a
schematic representation of our logic design, and each of those blocks are a separate set
of code creating this massive digital custom system of our own.
All right, so now the part you guys have been waiting for.
This was something where I had...
So ZAWS was away, and I wanted to have some more videos of real B sodomy, right?
Once we got the remote triggering working.
All the front-end stuff.
So some guys came over.
You might recognize them.
One of them is Aunch, who runs the registration, and one of them is Crypt, who helps run a lot
of DEF CON now.
They came over.
I created a special image for them, and I'll just show you the video.
So to lead up to it, my kids were there.
They love these guys, and I told them, I said, convince them to watch something on
my TV screen.
So they basically convinced these guys to watch a Pokemon.
Basically my wife dressed up as Pokemon, and the kids chasing her down the street in our
neighborhood.
Because we didn't want them to play Pokemon Go, because we're paranoid about privacy,
of course, as we should be.
So we decided to do Pokemon Go in real life.
So they were trying to...
My kids convinced these guys to watch this video, and then you'll see what happens.
And I actually have not seen this video yet.
Joe refused to show it to me until the presentation, so I'll be joining you guys and watching it
for the first time.
Also, if there are any young children in the audience, cover your ears.
If you're with your parents, make sure they cover your eyes.
There's some nasty images on the screen.
As a fair warning.
Okay, here we go.
He's watching the video.
This is not...
This is horrible technology.
What just happened?
I don't know.
Are goats here?
That's what you did.
Well played, sir.
Well played.
Thank you.
That's why no children are allowed in this office.
They're like...
We sodomize you in 1080p.
I'm a great bitch!
Ange is not into it.
So, here.
I'll put it back now.
Did you do it remotely? Or with a time?
It's remotely.
With the Apple remote.
So we remote this time?
No. It's a little more
sleek for the office space.
Exactly. I love it.
And now we're back. No more Gozi.
Sorry I had to do that to you.
Be sodomy in HD
successful.
I approve.
So, yeah.
Josh was basically disgusted and was texting his wife.
Joe Grant just Gozi'd me.
But what happened is
they were so loud that my kids
who were outside playing, because I told them
I was like, I'm gonna show Jeremy a really disgusting video
like you can't come in. So they heard all the noise
and decided to come in.
So I'm like, alright.
I'm gonna BSOD them too.
Children are not immune.
But no, not with what you think.
Alright, so now
the kids are watching the video
because they think it's funny.
I'm so disgusted.
What happened?
Did you break it?
Daddy used his BSOD-myzer.
You guys have trained well.
Yeah, so
Daddy's using his BSOD-myzer.
Watch out.
So you could see on the screen there was some static
on there. That's another mode that we generated
to show that we could do animated video generation
is now you have static, which is awesome
for kids because if you hook this thing up and they're watching
TV and you don't want to be the bad
parent by saying you gotta stop watching TV
you just, you know, turn on the static mode
and be like, oh, I guess the TV broke.
Gotta go play outside.
So we had
some other modes in there mostly used for testing.
Some moire patterns.
Some gracedale stuff.
And that's all still in there so if you need to have like a legitimate
reason to build the tool, you could do that.
But really it comes down
to, you know, the challenges
of dealing with the FPGA, designing the system
in essentially five weeks of full-time work
with us across
the country and Zaz basically receiving
a bunch of emails of me bitching about stuff
and like once in a while sending a picture.
I did send him the goatsy of the
image on the screen and I didn't hear from him for a few days.
I'm like, oh shit.
I know he's hard to piss off but I wonder if like I really
pissed him off.
No, I just wasn't reading email for a few days due to travel.
So yeah, so you know the challenges of this
is we picked something way outside of our comfort zone
and I'm proud that we were able to
get to a point where we have stuff to share,
we have stuff to show.
There's other FPGA nightmare stories and anybody that's
worked with FPGAs is probably like, haha, you guys
suckers. But things about even like
dealing with the different signals
at different clock speeds are like
a really hard thing because you have to synchronize stuff
and that's what we did with the buffer or you're gonna have all sorts of problems.
Things like
we need to generate a new clock with a
phase lock loop, a PLL that's in
hardware and the SD RAM interface,
the DDR2 RAM interface was using the PLL
that we were trying to use and it took about
four hours to realize that we were
not using the right one and we had to physically
specify in code where we wanted
to physically place a piece of hardware
inside the silicon which was pretty mind-boggling.
So yeah, it was a lot
of fun, kind of a hard project.
If you want to start working on your own
project, all the code for the
old design is up on my website.
The development notes and the schematic for this project
will be up once I get back to a safe internet connection
and I can scan all my documents in.
There's two GitHub repos, one for the
C code for the front end, one for the
HDL for the FPGA.
So everything's available that we've
done will be online.
And you know, the main thing I think here is
that we, FPGAs
do fill a gap, like they're useful for certain
situations if you know what they are. Definitely
don't be scared to start using them
and get involved, like there are some simpler FPGA
boards because being a hacker is all about
expanding your knowledge, right, and trying something new
and learning from it, and like even if this
is a completely ridiculous project, I'm
confident now that as an engineer I can go and
design something with an FPGA.
Yeah, we definitely don't want to scare people off
with saying how hard everything is, just that there's a learning curve
like there is to anything.
And you
have to not be scared of it and to dive in
and just commit to a few weeks of
frustration to getting everything up and running
but once you do, you'll be like, wow this is a really cool
powerful new tool in my
arsenal. That's right.
So the final question that people have been asking us a lot
is are you going to turn this circuit board sandwich
into an actual product?
I don't know. There's a lot of engineering that still
has to happen, mostly from the hardware
design side. Zaz is
sort of like the... Yeah, I really want
to do it and Joe's not sure if he wants to do it.
It's got a classic kind of Jobs
Wozniak situation going on here because
it's really easy for me to say, yeah, we should get this in people's
hands, you know, people will really love it, they'll use it
but Joe's the one
that has to do all the hardware design. I'm the sucker that's going to be stuck with it.
So, yeah, you know, depending on if people want
it, whatever, we set up an email
address, you can send comments and suggestions
but everything's up there so you can at least start
hacking on stuff on your own.
If you want it,
if you would buy one, send
an email to root at besodomizer.com
and then we'll gauge demand and then maybe
we'll make it. So, yes, thank you for coming
and the end.