- All right.
Hello, everyone.
Welcome to the virtual stream of the DEF CON talk,
"The PACS-man Comes For Us All:
We May Still Be Vaccinated,
but Access Control Still Sucks."
We're gonna jump right into it today
'cause we have a lot to cover.
For those of you who don't know,
my name is Babak Javadi.
I am a lock picker, hardware hacker,
and reverse engineer.
I've also been a professional red teamer
and covert entry instructor for over a decade.
Founded The Open Organisation of Lockpickers,
the Red Team Alliance,
and The CORE Group.
Nick, tell us a little bit about yourself.
- Sure, yeah.
I'm Nick Draffen.
I like to hack things
where the physical and digital world intersect.
I'm involved in the RFID Hacking by Iceman Discord
and you can find me there.
Eric, can you tell us a little bit about yourself?
- I'm Eric Betts.
(Babak laughs)
- Hi, everyone. My name's Anze.
I'm a student of computer science in Slovenia,
a security researcher for about five years now.
Disassemble everything I find.
Bug bounty hunter.
Made into the Google Vulnerability Research Program
Hall of Fame.
Mostly now I do RFID research.
- All right, so today we're gonna talk about two things.
We're gonna talk about a new tool that we're releasing
that's gonna make red team a whole lot more fun
and a whole lot more easier
and we're also gonna talk about a interesting vulnerability
that we found in some readers.
So, first, what are PACS?
What is the PACS-man?
Well, that refers broadly
to physical access control systems.
And we're not gonna go in depth
into how they all work
but we'll give you a very light overview.
If you're interested in more,
check out our other DEF CON talks
or check out the RFID Hacking Discord
or Red Team Alliance.
But we are talking about enterprise access control systems.
These are embedded boards
that take in inputs of various kinds,
most often, credentials,
and based off of logic,
controls certain outputs,
such as door hardware, magnetic locks,
electrified strikes, et cetera.
The most important concept to keep in mind
throughout this first part of the talk here
is that RFID credentials,
regardless of what technology they are,
they are basically very simple, very tiny containers.
So whether it's a prox credential
or a iCLASS or a MIFARE credential,
these are just different ways of all storing the same data.
So a lot of older low-frequency credentials,
they're simply like folders,
electronic, wireless folders,
that contain a very small bit of data inside.
And when we present that folder to the system,
some interesting things happen.
So to talk to you about that,
we're gonna cover a really short, very simple analogy.
We have some characters here.
Some of you may have seen them before.
So we have our RFID reader,
we have our RFID credential,
we have our door controller,
and then, of course, we have the door hardware.
So what happens normally
is that RFID reader is always scanning
looking for credentials nearby.
As soon as that credential comes into range of the reader,
it actually is powered on by the field of the reader
and immediately starts transmitting
the data stored on the credential.
The reader receiving that information takes that
and then retransmits it out to the door controller.
The door controller performs some logic functions,
decides, hey, is this person authorized or not?
And if so, we go ahead and release the electrified strike,
magnetic lock, what have you.
Of course, it's not just low-frequency credentials
that work this way.
High-frequency credentials work in a very similar way
but with a couple of extra layers of protection.
So the data might not be in plain text.
It might be stored
in some sort of obscure to encrypted format.
And most importantly, that data is protected.
So if we imagine our credential data
being folded into an envelope,
placed into a secure bag,
and then that bag being put into a locked container,
that is similar in many ways
to how a lot of contactless smart cards
and high-frequency credentials work.
The data inside is ultimately the same.
We are just adding additional layers of protection.
So, again, really oversimplifying
how these technologies work.
If we take a look at, you know, a high-frequency credential,
here is an example
where a mutual authentication takes place.
So it doesn't immediately start transmitting
the cardholder data
but, rather, a secret handshake has to take place
where the credential and the reader
mutually authenticate each other
without revealing any secret key material
and once that information is verified,
then the cardholder information is provided to the reader,
the reader then retransmits that to the door controller,
and everything else continues as usual.
So credentials come in a lot of different shapes and sizes.
A lot of them are broken.
A few of them are not.
And ultimately, they are just one major component
of the access control system.
So we have a bunch of different credentials.
We have readers.
We have the door hardware,
different types of sensors,
motion sensors, door contact sensors, et cetera.
Then, of course, we have the door controller
or control panel
that is making all the decisions
and that is all managed by some server-side software
or PACS software package.
So oftentimes when in the hacker community
we're talking about interacting with access control systems,
very often, we're really talking about hacking
just the RFID Ps,
the credential side,
which really just refers to the method of communication used
between the credential itself, the card itself,
and the card reader.
So all of these different pieces,
they are set up in a very interesting way
and they all kind of work independently of each other
but are kind of glued together
in a couple of different ways that we'll see.
However, let's talk
about some of the most common tools of the trade
when we're talking about RFID hacking in general
and red teaming as it applies to it.
Some of the really common tools that you'll see
or may already be familiar with
is, first of all, the Proxmark3.
This thing is ubiquitous.
It's an open-source hardware project
originally released by Jonathan Westheus ages and ages ago.
Since then, there have been many different hardware variants
that have come out,
some good, some not so good.
It's very much a kind of Swiss Army knife of RFID.
It's a software-defined RFID tool that can,
just with, you know, reprogramming the code and firmware,
we can change what different credentials it can talk to
and this is one of the reasons
why it's been so popular with the community.
The most recent, most common variant of this tool
is the Proxmark 3 RDV4 made by the RFID Research Group
and it's one of our favorite variants.
It's very mature today
and it finally has become stable and good enough
that it can be used much more easily for red teaming.
One of the coolest add-ons that it has
that hasn't really been fully taken advantage of yet
is the Bluetooth add-on or the Blue Shark,
which is a Bluetooth 2 interface to the reader.
And we're also gonna be using
in this first part of the talk the ESPKey.
This is a Wiegand interception device
originally made by Kenny McElroy
or octosavvi on GitHub and Twitter.
And this is a Wiegand interception and replay device.
And it's not the first of its kind.
There have been a number of others before it,
the BLEKey and, of course, the Gecko
made by Zac Franken and Adam Laurie.
And this is a device that is optimized for field deployment.
So it's very fast to install.
It has a very easy-to-use user interface.
And, very happily, is one of my favorite
and cheapest, fastest ways to weaponize any reader.
What do we mean by weaponizing a reader?
Well, that's just a fancy way
of saying we took a regular card reader
that knows how to talk to the credential
that we wanna talk to
and we're gonna connect the data logger to it.
So we supply it some portable power
in the form of a battery.
We connect a data logger of some kind.
That can be a Arduino or a Raspberry Pi
or whatever you wanna use.
In this case, we're using an ESPKey.
And that's it. You have a weaponized reader.
Data is read by the reader,
the reader sends it to the door controller,
except there is no door controller, only the ESPKey,
which records it.
So this is a really cool, versatile, multifunction tool.
Typically, in the field,
what that workflow might look like
is once you capture that cardholder information,
now we have to then encode it onto a card,
which we often do manually
either from a computer terminal
or maybe if you have an Android phone,
you might use the Bluetooth-enabled phone application.
But it's a little bit clunky,
sometimes requires some extra steps,
and it does take a little bit of time.
So once you clone a credential in the field,
you still have to then go back
and write it to a card later.
So how do we improve this experience in the field?
Well, we know that there are these Bluetooth capabilities
out there for the Proxmark3
and we know the ESPKey has Wi-Fi,
so surely there must be a way to automate these things.
And to tell us what we ended up coming up with
to create this automation,
I'm gonna hand things over to Nick,
who wrote some really cool software.
- So, yeah, thanks for the introduction there, Babak.
Yeah, Babak and I were on a phone call
talking about usage of weaponized readers
and Proxmark3s in the field,
trying to come up with a unique way to glue them together
and leveraging those functions
that are already on the ESPKey with the Wi-Fi
and the Proxmark3 with the Bluetooth.
We kind of thought about what else had Wi-Fi and Bluetooth
and the quick and easy answer to that,
what would be portable in the field,
was a Raspberry Pi Zero W.
It's small, it's able to be battery powered,
and it has both Wi-Fi and Bluetooth peripherals
so we can connect it.
So this is where we kind of came up with the idea for Odo.
Odo, if you don't know,
is a character on "Star Trek: Deep Space Nine."
Odo is a Changeling in the show, which is a shapeshifter,
meaning that he can take the shape of any object or person.
So with the idea for Odo being that you capture a credential
via the weaponized reader,
you then shapeshift into that person,
essentially leveraging a physical privilege escalation
in the field.
You can bump into someone, grab their badge,
and become that person
and use that to your advantage.
So what is Odo under the hood?
Odo is an open-source framework
that takes credentials in, puts credentials out,
and it's language agnostic
because it basically leverages the fact that it's a JSON
over MQTT API.
So there are credential producers,
there are credential consumers.
One side, like an ESPKey, produces credentials
and emits an MQTT message.
The other side, like the Proxmark3,
can consume those messages
and then do something with that data.
So this allows it to be language agnostic.
Even though the base framework is written in Python,
we have a number of different modules
that are in different languages.
Currently, basically Python, Node.js,
but it doesn't really matter.
So, essentially,
this framework can drive not just the implementation
that we are gonna show here today
of the weaponized reader and the ESPKey
but any type of thing that can produce a credential,
data that you can then write to another credential,
you could add modules to this framework.
So it also gets better with hats (chuckles) and haptics.
So for that field usage,
being able to see the credentials that you've captured,
select a specific one.
Specifically, if one was better for you than another,
you can go and select that credential
and it will rewrite that
to the tag that's on your waistband or on a lanyard
'cause the Proxmark will be battery powered
on a class behind the tag.
And then using a haptic feedback device,
which we have pictured here,
will indicate to you
that you have captured or cloned a credential.
And with that being said,
I'd like to do a quick demo.
So let me switch down to my top-down camera
and do the big version here.
So you'll see that I have a Proxmark3
powered by its battery.
Blue light is on
'cause it's connected to the Raspberry Pi Zero W over there.
Our haptic feedback device is here in a case
so it doesn't go haywire on us.
This is our target credential
and then this here, I'm showing it in front of me,
is the source credential.
Source and target credential technology
doesn't really matter
'cause we're taking that Wiegand value
and encoding that onto a target credential.
So I have a weaponized reader here off-frame.
I'm gonna scan this credential.
We will see a new item appear on the screen
and the haptic device (chuckles) indicates
that it has seen a credential.
And then once that credential is written,
which we see the blue light blinking on the Proxmark,
it vibrates again
to indicate that the credential has been written.
So, yeah, that's pretty much what we have with Odo.
The ways that you can contribute and make one,
we have a GitHub open source repo
with the framework and our initial modules.
Raspberry Pi Zero Ws are cheap and readily available.
The PiSugar that we chose to use here
is a great way to battery power the Pi in the field
and the LCD module is helpful for that local interface.
And there are a number of different ways
that this could be extended pretty much immediately
with other credential producers and consumers,
new feedback mechanisms
and leveraging some sort of wearable smart watch
or even haptic feedback vest,
and just go wild
with all the different possible producers and consumers.
So with that being said,
I'd like to hand it back over to Babak
with the evolution of PACS.
You're muted.
- (chuckles) Thank you.
One of the things I really enjoy about the Odo framework
is that this now allows us a way
to do, like, in-field, live privilege escalation
completely automated and touchless,
and if you come to our live talk,
you'll see what that looks like in action
and it's really, really cool.
Now, that's just one part
of something that we wanted to talk about today.
Something else that's really interesting
has to do with how evolution takes place in access control.
So what we're gonna talk about
is what I'm calling the physical security chain of trust
and it really kind of underscores
how discrete and rather independent
a lot of these components are
and the way that they're glued together
really has nothing to do with other components necessarily
in the system.
So what I mean by that
is, for example, let's take a look at an old, old system
that's running Wiegand wire and a Wiegand reader.
When this system first came out, it was very good.
It was the newest technology,
very difficult to clone and manipulate.
But systems age.
So as they age, the chain of trust ages as well,
and because of budget constraints,
you don't really rip and replace the whole thing.
You replace specific links in the chain selectively.
So maybe a new technology comes out,
prox hits the market and you're like,
"Oh, man, I'm so tired of swiping cards.
I just wanna use a prox card
so I can just go boop
and, you know, get through the door," right?
So we replaced just those links
but they had to be backwards compatible
because that's the only way that we can really afford
to deploy a lot of this new technology
in massive scale sometimes.
So what that means
is only parts of those links are replaced.
So then the chain of trust continues aging
and we have different components replaced.
We again upgrade our cards and readers.
This time we might also upgrade our door controllers
and server-side software
because maybe we want some of those new functions,
some new capabilities, more memory,
you know, faster, all of the things.
But it's not necessarily, again, addressing the whole thing.
So you might notice
there's one particular link in this chain
that keeps aging more and more and more
and so now by the time that we are in biometrics territory
and people have, you know, facial recognition this
and iris scanning that,
a lot of systems, historically, were still using Wiegand.
That's this really old link in the chain here.
So considering that your chain
is only as strong as the weakest link,
that is of concern, right?
So recently over the past couple years,
this has begun to be taken care of with OSDP.
It's something that we talk about more
in some of our other talks and in our trainings,
but it is the replacement for Wiegand.
It's the replacement for that weak link
and it offers a lot of new functionality
in the form of bidirectional communication and encryption
that really kind of help improve
the overall security of the whole physical security chain.
However, security alone is not enough for the industry
and for a lot of customers.
We keep wanting more and more functionality.
So even though we've now had
this new tool here for this chain,
the development elsewhere has not stopped.
Now the new hotness is mobile credentials.
So mobile credentials are the new black in access control.
They can come in a lot of different shapes and sizes,
but, ultimately, if we have to work with smartphones,
we only have a few different interfaces
that we can work with.
Ideally, we would want to use NFC
with the credential data stored
in a secure element on the phone,
but not all phones have NFC.
Only the more higher end, more modern phones have that.
And even of the phones that do,
not all phones provide a proper API that you can use.
Apple, until very recently, had iOS pretty locked down
when it comes to anyone but Apple
using that NFC interface on the phone.
So a lot of vendors have resorted to BLE,
or Bluetooth Low Energy,
because almost all smartphones have this technology.
But unfortunately, BLE, as a lot of you know,
was not designed for this purpose.
So how do we shove BLE into these older readers
that did not necessarily have this technology?
There's a couple of different ways
that vendors have done this.
There's in-line adapters
that you connect to the Wiegand line
that are basically Bluetooth-enabled ESPKeys
that are not used for attacking
but, rather, functionality.
And then there's also stuff like this
where, you know, one major vendor decided,
"Hey, why don't we use the debug interface
on the back of the reader
that we made for upgrading and programming,
why don't we use that
to add Bluetooth functionality to the reader
and now we can have this beautiful new future
where everything is, you know, mobile enabled?"
And now we have this phone-based diagnostic capability,
we can do firmware upgrades,
and, most importantly, we can reconfigure the reader.
We can disable older technologies
that, you know, we don't need anymore
or that are insecure.
So for this particular platform,
what was used was an application called Reader Manager.
Reader Manager allows you
to reconfigure the reader settings,
what protocols it supports, et cetera.
It scans for nearby Bluetooth-enabled readers
and it allows you to reconfigure it.
So it allows you to change configuration,
turn credentials on, turn credentials off.
But if you're using Bluetooth,
Bluetooth is not a short-range technology.
It can cover quite a bit of distance.
If you have a lot of readers,
how do you know which one you're reconfiguring?
That is the question.
So there are a couple of different ways
that companies have dealt with this
but what this particular company did,
and we'll go ahead and see if we can cut video here,
there we go.
So what we have here is a example reader
and I just have a little field detector card
here in front of it.
We're gonna talk about that in a few slides.
And it's kinda hard to see,
so we're gonna adjust the brightness here.
Let's see if we can see my phone a little bit better.
Not really, unfortunately.
So one thing that it has,
and it should pop up here shortly,
is there is,
there we go,
so we could see all the readers listed there
and when I tap on a reader,
I get this option to inspect or locate.
So when I tap Locate
what it will do is it will make the LED flash
and make the reader beep
so I know which reader I'm about to configure or touch.
You might have also noticed something else unusual
that just happened,
which is the LEDs on this field detector card turned off.
And we'll talk about in a moment why that's a problem
because while that reader field is off,
we're not actually able to scan and process media.
So where does that leave us?
We have that locate functionality
to identify which readers we're working with.
There are some security functions that we found
that was built into this.
The changes, sorry, the functions were allowing you
to make changes to the reader,
or the inspection functions.
These are functions
that require some form of authentication.
So the most common method that is used
is you have to power cycle the reader
to apply certain changes
because we don't want people
just turning credentials on and off unexpectedly.
So the reader only accepts
certain administrative configuration commands
for a very short period after power on.
But that by itself may not be enough
for a lot of applications
and this is where a lot of customers can go an extra step
and get a custom key or elite key in certain systems.
So custom keys basically add an additional restriction
in that not only do the credentials
have to have that special key
but also any phones that need to recognize the reader
also have to have a special administrative key
that is unique to that site.
Now, what's interesting here
is that some locate functions
did not require any authentication,
meaning we found that you could locate a reader
regardless of whether or not it was a standard reader
or an elite reader
and because that locate function
temporarily shuts off the field,
that is of concern.
So in regards to the Bluetooth,
I'd like Anze to really talk a little bit more
about some of the things that we found
once we took a closer look at this.
- Thank you, Babak.
So after further looking at what is happening
over Bluetooth Low Energy,
we found out that all of the readers
advertise a single service,
all of them, of course, with the same UUID.
The service had a single notify
and write without response characteristic.
Upon subscription to that characteristic,
the reader sent an initial message.
If it didn't receive a reply in a certain amount of time,
the reader disconnected automatically quite aggressively.
So under the hood,
we wanted to see what the BLE conversation looked like
and so we wanted to sniff that out.
We got an nRF52 development kit,
loaded nRF Sniffer for Bluetooth LE,
located the device,
saw what was exchanged,
and got the messages as PCAP files.
So in those PCAP files,
we wanted to look at what a BLE conversation looked like.
We can see here that the message looks quite similar
to an ISO 7816 ADPU,
which is also used in other smart card protocols,
most notably in credit card processing or EMV cards.
And to that, the phone replied
that the AID the reader was trying to select was not found.
So you might be wondering now
what is with all the readers
that everyone has behind them at this talk.
And the readers have some blinking lights.
So why are the lights blinking?
The readers have field detector cards
made by Proxgrind and RFID Research Group.
The LEDs on them are powered by the electromagnetic field
emitted by the readers to make them blink.
There are separate LED colors
and separate antenna windings on the BCBs
for low frequency and high frequency.
So the red LED means
that an LF or a 125 kilohertz field has been detected
and the white LED means that a 13.56 megahertz
or the HF field was detected.
But because we all know that PCAPS are boring,
we of course went
and implemented our first demo in Python
and it was able to take down one device.
We then rewrote it in Node.js,
made it async,
which allowed us to take down about five readers at a time.
But then we wanted to see if we can go even further.
We got ourself an nRF52 development kit,
rewrote the whole thing in C,
and were able to connect to quite a bit more devices.
But because we all know that a development kit
is something that you don't carry around,
we then moved to a Pug.js,
which is a nRF52832-based development board
with RGB LEDs, a button,
and powered by a CR2032 coin cell battery.
And now we will have a demo of what happens
when we start sending that
to all the readers in our vicinity.
So I would ask everyone here
to please turn on your dongles.
- And we'll go ahead and activate.
And what the code is going to do
is automatically look for any available readers nearby
and, one by one, add them to the list of readers
that we send a barrage
of locate commands to.
And now you can see almost all the readers
except for that one guy,
don't worry about that one guy,
had the fields shut off.
And in that state,
they are unable to process media,
meaning no cards will be able to be read by that reader.
So you just had a physical denial-of-service event.
- And now I would like to give my word to Eric.
- Yes, so as Babak mentioned before,
these field detectors, they stopped blinking.
What does it mean?
It means there is no EM field.
That means it doesn't matter if you present anything to it.
These are basically just like dead plastic at this point.
And so that is very bad for all of this,
sorry, that's the sort of field detector part of it.
And we got to thinking, what else has an nRF52?
And for anybody that's been around at DEF CON
the previous couple of days,
they may have watched a talk about this.
You know what else has an nRF52?
A motherfucking AirTag.
So we put our firmware on an AirTag.
So here's me putting in the battery.
Gonna go ahead and slide that closed.
Flip over to this
and y'all can see it has also knocked out the readers.
Except for that one.
Nope, no, got that one too.
And so now I'll hand it back to Anze.
- Thank you.
So we wanted to really bring it home,
and remember the backpack that added BLE to our readers?
Well, we found out that that BLE
is also powered by an NRF-based chip
for Bluetooth Low Energy
and we asked ourself if we can also reprogram that
and we found out that it is possible to reprogram it
the same way as an AirTag.
So with that, we were able to take down eight readers
in the vicinity of the backpack being powered.
And then, of course,
because nRF52 is such a widespread chipset,
we then asked ourself what else we can use
as an emitter for the attack
and we came to,
we found out that there's a COVID test
that has an nRF52 in it,
there's some development devices,
personal pleasure devices,
and the universe of nRF52 is pretty much endless.
And now I would like to give it to Babak
for some closing words.
- So what does this all mean, right?
What's the real practical impact
other than just annoying some people?
That depends on the situation.
So we've evaluated
a number of different customer deployments
and different use cases
where these readers and Bluetooth backpacks have been used
and what we're looking at is really dependent
on what the attacker wants to do.
So we can do either a very high selective
or a very area-wide denial-of-service attack.
So we can identify specific readers
and attack just specific readers
or we can deny access to an entire area.
And in the field,
in practice, what this means
is that there are sensitive egress and ingress points
that we can then prevent people from using unexpectedly
and without any indication as to why or what's going on.
So turnstiles, especially locations
that have a required, you know, badge in, badge out systems
for mustering purposes,
security vestibules and mantraps,
you could create some problems
by preventing those readers from working properly.
So, you know, if you disabled the RFID readers
and the turnstiles or mantraps from working,
then you might be able to create artificially
a situation where you'd more easily be able
to social engineer your way into the building
because if none of the employees can use their cards
and, you know, business has to go on,
they might revert
to just visual confirmation or identification
via the printed badge.
Or any other special areas,
security operation centers, equipment rooms, et cetera.
On the lighter side,
yeah, you could, you know, just use the beeping function
to annoy the heck out of some employees
by beeping all the readers.
Or a attacker may choose
to use the denial of service post-entry to evade security.
So after you successfully work your way through a door
by whatever means,
whether it's lock picking, bypass, or card cloning,
you might choose to disable the reader temporarily
so that even if someone does try to come after
and inspect what's going on or engage you
that they will have increased difficulty
in actually getting to your location.
And the final really interesting thing that we came up with,
especially after Eric figured out
how to reprogram an AirTag,
is ghost mode
where we can program a device like an AirTag
to scan for and only jam
or, rather, you know, do the denial-of-service attack
against the first one or two readers
that have the strongest signal
and what this would do
is it would create the unusual situation
where if you place this AirTag in someone's bag,
any reader that they approach will suddenly stop working
and by the time they get to the reader
and try to present their card,
the reader won't actually read the card
and so they'll be like a ghost.
They become invisible to card readers.
So for some customers, this is a big deal.
For others who may not have these particular modules
or Bluetooth-enabled readers installed yet,
it may not be a big deal.
However, we have been in contact with the vendor
in working with some solutions.
So the vendor in question,
which in this case is HID,
is aware of the problem.
They are working on some firmware updates
that will mitigate or minimize the risk
related to this issue.
It will be made available
through their Reader Manager application
so you can remotely go around and update all these readers.
Although, at the moment, it does require
that you use that app physically at each reader to do so.
They're also working on some methods in the future
that are not available yet
to allow for upgrading of certain readers over OSDP
as long as the right hardware fits.
So that's not something that is finalized yet,
but will be available for certain configurations.
In the short term,
there's a couple of options
that we think may be possible
depending on the use case for different customers.
We do recommend that if you have to use mobile credentials,
if you have to have these Bluetooth-enabled readers
in the field,
that you do provide some guidance and education
to relevant security staff
on how to respond to different situations
if a bunch of readers stop working correctly, for example.
Some customers may decide
to ask to have Bluetooth functionality disabled.
If you are one of these customers,
we do recommend that you reach out
to your HID account manager
and ask for guidance.
We may have update guidance
that we can provide at the live talk
but we don't have that yet,
so we're staying nice and general at this time.
And finally, some customers
that are not using mobile credentials
but still require OSDP
may be able to, under certain circumstances,
get OSDP-only backpacks that, you know, don't have
that additional Bluetooth layer of functionality.
But, ultimately, this is something
that is really just kind of a byproduct
of a lot of things kind of going wrong
and adding up to a very unexpected situation.
So these are one of the reasons
why a lot of us in the hacker and security community
get a little bit nervous
when people start just adding Bluetooth
to all of the things.
So we'd really like to send out
some thanks and acknowledgements
to people who kind of really supported us along the way.
First of all, a huge thank-you to HID
for listening and responding to the problem.
We know that this is not a problem
that is unique to one vendor,
but these kinds of mistakes can be made,
you know, by a number of vendors.
In this case, it happened to be them
and they are working through it.
Thank you to Iceman
and all the other core contributors and developers,
you know, Philippe, or doegox,
and everyone else who is constantly contributing code
to make the Proxmark3 even better and more stable.
All of our friends at the RF Village
and RFID Hacking Discord.
RFID Research Group and the iCopy-X team
for donating some prizes
that we'll be giving out during our live talk.
And, also, Gordon Williams
for providing us some guidance
on some of the Node.js stuff
when Eric was working through that code
on some of the things that we had to tweak
to improve performance.
So we also want to, all of us, briefly say thank you,
let me switch back to the quad view,
and say thanks for joining us, for listening.
Thanks for kind of putting up
with how fast we've been trying to go through everything
to try to fit it into the time slot that was made available
and hopefully you guys really enjoyed it.
If you have more questions,
as we know you will,
feel free to reach out to us,
talk to us in person or on the RFID Hacking Discord.
We hope that you take a little bit closer look
at some of the other Bluetooth solutions
that are out there in the access control world.
And finally, if you're interested
in really cutting your teeth,
getting your feet wet, learning more,
if you're a hobbyist,
come check us out at the RFID Hacking Discord.
Link is right here in the slides.
And if you're a working professional
and you're interested
in more hands-on training and certification
for physical security,
come check out Red Team Alliance
and see what we have to offer.
Thank you very much again,
and that's it, that's all we got.