This post discusses practical attacks against poker cheating devices designed to detect and jam these devices.
Poker cheating devices are highly advanced devices that use infra-red marking, a hidden camera, and computer vision to predict who will win a given poker hand. If you haven't heard about them yet, please read my intro blog post on the subject or watch my Defcon talk on the subject:
As revealed in the previous blog post about the device accessories, the device makers didn't consider the possibility that someone would try to disrupt their devices and, therefore, didn't properly secure the device’s communication.
In this post, we will see how savvy poker players can exploit this lack of security to protect themselves from cheaters. As usual, there is a (huge) gap between knowing something is vulnerable and being to successfully and reliably exploit it, which is why it took longer to release this post than expected :).
This post demonstrates, with the help of short videos and code, the following attacks:
The interception of the remote camera video feed to detect if someone is cheating and uncover who it is.
The hijacking of the remote camera video feed to replace it with the video of your choice. Will not fully practical, this is my favorite attack.
The hijacking of the remote communication to disrupt the players count and mute the device. This is the cheapest and easiest attack to carry out in a poker room.
For each attack, we are providing a comprehensive source code and explanation so that you can reproduce them. Most of the attack development was done by my co-conspirator, Jean-Michel.
For those who would like to know all the nitty-gritty details on how the attacks were developed will be happy to know that Jean-Michel, who did most of the attack development, will release an in-depth technical writeup on his blog regarding this in the next few weeks.
Before delving into the attacks, let’s first discuss the cheating device attack surface so that it is clear what can be attacked.
As visible in the diagram above, the device has four distinct types of communication that are all potential vectors of attacks:
Card reading: The camera processes infrared light to read the marking.
Camera video streaming: The camera streams its video to the device so that it can process the information to detect who will win.
Earpiece communication: The poker device communicates to the player who will win through an earpiece.
Remote control orders: The remote control is used to adjust the number of players at the table and mute/unmute the device.
Creating attacks is very time consuming so we spent time carefully evaluating which communication channels were the best one to target to create reliable attacks. Our hope is that these attacks will help poker players to protect themselves against these cheating devices. Here is a summary of the conclusions we came to.
The first vector of the attack that we ruled out was the earpiece communication channel. While we can technically jam it or inject fake sounds, the risk of collateral damage is too high as many people use wireless headsets and earpieces.
Next, I spent time experimenting with the idea of disrupting the cheating devices by blinding the the camera. I quickly realized that it is maybe doable but totally impractical. To make it work, you need to emit a lot of infrared lights and shoot it straight at the camera. Even if you are able to reliably spot the hidden camera, I am pretty sure that the cheater and the other players won't let you point your “light gun” at the camera during the entire game :).
Similarly, detecting the use of cheating devices by measuring the level of emitted infrared light is impractical because it requires placing the detector next to the cards. Moreover, it is unreliable because the device and its camera emit light continuously so there is no blinking pattern that helps to differentiate its emission from ambient infrared light emissions.
This left us with only two types of communication that are worth attacking: the video stream from the camera to the device and the remote control orders.
As our main goal is to allow players to defend themselves against cheating devices, it became clear that attacking the remote control order was the way to go. As discussed later in the post, this type of defense is both cheap, legal, and reliable.
On the other hand, to catch cheaters, intercepting the video feed is the best option as it enables you to see what the camera sees and, therefore, easily pinpoint who is cheating regardless of how well they conceal their camera and device.
However, hijacking the video stream is impractical in real conditions as it requires too many emission powers but we couldn't resist to doing it in a lab setting because it looks cool :).
Now that it is clear why we choose to develop those specific attacks, let's discuss and demonstrate how they work.
The cheating device needs to know how many people are playing to decide who will win (or be second or third) because the number of people influence the number of cards distributed and the number of hands to consider. To allow the cheater to provide this information, the device comes with a remote that allows them to increase/decrease the number of players and mute/unmute the device.
The way to exploit this feature, and make the device unusable, is to continuously change the number of players. This makes cheating impossible - due to this continuous injection of information, the device will keep using the wrong number of players when it does the analysis. Here is a short demo of the software that we wrote to do the injection:
As you can see, we can increase, decrease, and mute at will by impersonating the remote with our dongle and laptop. When using the software in attack mode, it will infinitely increase the number of players every second. This works reliably because there is no limiting rate and the device will happily resort the player count to 1 or 2? if you keep incrementing the past twenty-two players. You will find our attack code on github.
Here is why we recommend using this attack to protect yourself against cheaters:
It is unstoppable: There is literally nothing the cheater can do to prevent it. The device doesn’t allow a cheater to disable the use of a remote and and our fake remote can't be blocked because remotes are not authenticated.
It is foolproof: There is remote use the RF protocol so there is no need to have the cheater in your line of sight or even know if there is a cheater. The device blasts the attack around you so that any cheating device that is in range will be automatically disrupted by the attack. Note we only tested this on a single device so there is a slim possibility that others could use different remote encoding. This is unlikely given what we know of the system but even if it was the case it would still be a non-issue. All we need is one transmission to clone the remote and jam it. A process that would be easy to automate.
It is invisible: There is no need to get the device out of your bag, just letting it run while you play and you are protected. The remote uses specific codes so that the risk of collateral damage is virtually non-existent which means that there is little downside of having it running at all times. Additionally, keeping the injecting device concealed ensures that the cheater won't be able to find out who is attacking them which keeps you safe from retaliation.
It will drive cheater nuts: Every time you change the number of players, the device will announce it. This means that every second the cheater will hear the change in his ear piece which will likely force him to give up very quickly.
It is cheap: The frequency at which the remote operates means it is very cheap to build an injecting device. All you need is a dongle like this one or that one, a raspberry pi, and a battery. Alternatively, you can simply use a laptop and a dongle.
If, instead of preventing cheating, you are interested to know if cheating is taking place and identify who is doing it then intercepting the video stream, from the concealed camera to the device, is your best bet.
This attack is significantly more expensive as you need a SDR (Software Defined Radio), which can cost a few hundreds bucks, and a laptop. I, personally, use my macbook and an Ettus SDR which is visible in the picture above. I got this one because it is very small and offers a wide range of frequencies. Jean-Michel’s favorite one, is the BladeRF which is slightly cheaper and bulkier.
The only difficulty for this attack isolating the radio frequency and figuring out how the video is encoded over the air using an oscilloscope. Turns out that it is simply an analog video stream.
Armed with this information, all that you need to intercept it is a GNU Radio to build a radio circuit to capture and process the emission. We made the GnuRadio flow that is needed to reconstruct the stream available on Github. Note the reconstruction will be imperfect as it is not easy to sync the SDR with the camera. However it is a non-issue as the reconstruction is good enough to locate a cheater which was our goal.
As mentioned in our Defcon talk, the chipset used to transmit the video can operate on 4 distinct frequencies so it might be possible that other cheating devices use one of these other frequencies. This is why we recommend that you survey the site to see if you spot any transmission spikes in any of the three other frequencies. If so then you will need to adjust the flowgraph.
After we finally figured out how to intercept and decode the video stream, which was not easy, we couldn't resist the idea of hijacking it to replace it with our own video. Here is a demonstration of such a hijack, where we appropriately replace the camera feed with a nice defcon logo:
The reason that performing this attack outside of a lab is impractical is because it requires to emit a signal that is stronger than the camera feed. This requires a very strong amplifier which is not particularly portable. Also, the camera stream is next to the 2.4GHZ band which means you will also disrupt a lot of WIFI and other useful devices. For the same reason, jamming the video feed is not practical either (nor legal) as it is has too much collateral damage.
This concludes our series of posts around poker cheating devices. Celine, Jean-Michel, and I hope you had as much fun reading/watching it that we had doing it. Hopefully, Jean-Michel and I will be back at Defcon 2017 with a brand new and exciting hardware hacking subject. So, be sure to attend if you are around!
Thank you for reading this post till the end! If you enjoyed it, please don’t forget to share it on your favorite social network so that your friends and colleagues can enjoy it too.
To get notified when the next post is online, follow me on Twitter, Facebook, Google+. You can also get the full posts directly in your inbox by subscribing to the mailing list or my RSS feed.