 Mae'r cyffredin am ein bodaiaper yn bach. Mae'n gweld Pntesta i'r pwneudiau gweld Prentes. Ieithio mwy fwy ogen y cwmins achos, mynd i gyd. Dyna hwnnw gyrraedd y gwylwch gan ffysg Ffysg Ffysg Fyysg. Ac mae'n gyrraedd eu gwylwch gwylwch yn cryfwyd o nghylch â'r lleol oherwydd eich cynhyrch yn cael ei fod edd o'r newydd ac mae gennych Gwylwch gan ffysg Fyhtwyr gelly, mae'n cymryd ddangos y bwysig o'r ffysg Fythwyr mwy o'ch gychain things like attack NFC tags themselves in order to get their contents. Now this is, I think my slides aren't coming up yet. That's my talk about PowerPoint. Thank you very much. We're talking about tagscited tags against NFC. Basically we're going to talk about how you can take some very basic components in order to make NFC analysis and attack tools. Firstly what is NFC? We all know what it is. called for contactless communication between usually a card and some kind of reader that illuminates the card in order to power it and communicate with it in order to do things like pay for things, open doors or other applications that are quite useful. I don't know why I've got a picture of some gates there but it's pretty much the main purpose of this. We're going to show some techniques for attacking things mainly up to do with door control access systems. So first we're going to talk about some iso number, so we're going to talk about iso1443, which focuses on 13.56 MHz NFC communication. It defines the characteristics of the communication, basically how it works, how the protocol works, and it's split out into two sections, A and B, which are used for different purposes and have different protocols on both a higher and lower level. The most common of these is iso14443A, which is mainly used for my fair classic, more fair of flight and other my fair systems. So low level communication basically works on iso14443A, which we're going to try and stop saying, by powering the tags with electromagnetic induction, literally powering the device with the same mechanism it's using to communicate with it. So communication is performed by basically cutting power to the tag every softlin a fast enough manner that it doesn't turn off the tag but allows it to receive data back. Now the responses are performed by the tag by modulating the amount of power being drawn from the reader to the tag, essentially modulating on that in order to send responses. It's sort of a one-way communication by receiving more power from it. They use two different coding schemes, modified miller coding, which is designed specifically in order to produce the amount of power loss that's going to happen, and Manchester coding, it's good because of timing issues that may occur. So modified miller coding basically minimises the power loss. It has a very strange protocol, basically zero after zero bit, means that it's low for the first quarter of the transmission and then high again, zero after one bit, high for the entire transmission, and one bit is high for the first half of the transmission followed by a low for one quarter of the transmission and high again. Basically this is done in order to, no matter what the communication is, not have a small space between the off sections of the communication in order to prevent that being glitches or problems with the power as it goes along, as these can cause problems with the readout protection. Manchester coding is done in order to prevent timing issues. Basically this is used among all other kinds of radio technologies, including ADSB, which you may know if you like RTL-SDR technologies, and basically how the user is to modulate the amount of power being received in order to communicate either a one or a zero by basically modifying the phase of the signal. So the basic enumeration of the NFC we are going to look at today is basically it starts with a request or a wake up command, which basically requests any tags that haven't spoken or are ready to speak, an ATQA, which responds the initial part of what the tag does, a select, which requests the unique identifier from the tag, and a further select and also select that specific tag, depending if there's more than one on the reader, and then a final SAC value, which basically says the final information about what this tag does, and then continued enumeration and communication based on what's happened there. Now this could be extended unique identifiers or more cryptography. A big thing that I found when it came to this was a feature called anti-collision, which basically exists when there are two tags within a reader that haven't spoken yet, causing issues which couldn't stop the reader from being able to decide which tags are on the thing. So for instance, if we look at the request that's being made, the first thing that happens is the tag sends an ATQA response. Now because both tags don't know that they've spoken yet, both will send a tag response at the same time, basically causing corruptive communication from both. Now how this is resolved is by the reader specifically requesting specific bits from the tag in order to find ones that don't match as these identifiers are meant to be unique. So there's a couple of different ways of encrypting and authenticating, depending on what the tags are. So there's myfer ultralight, which is extremely simple. You send a password to the tag and it says either yes or no. Now this can often increase the counter, which basically locks the chip and stops it from being used again. This is a common technology in things like amiwos that you find on the Nintendo products. There are other ways of doing it. There's having no communication whatsoever, just reading and writing data. Or newer versions like myfer ultralight C allow you to use more stringent encryption and authentication methods. Myfer classic, which we're going to focus on quite a lot today because it's an old technology, but a technology that's used everywhere, uses the crypto one algorithm that's often called the crapto one algorithm for the fact that it's got very, very, very weak encryption, weak keying. Basically, the reader requests authentication, the tag responds to the four-byte nonce, the reader responds to the random value followed by an encrypted number that's generated from that original nonce, and then the tag responds to another encrypted number from that data. Basically, it's a mutual authentication scheme where both the tag and the reader know that they both have the same key they're working with. All the further communication after this is encrypted in order to prevent an attacker from basically being able to read or write a tag even when they're not allowed to. There's myfer defyre, which is probably one of the latest technologies and one that's used in all sorts of things. I live in London, so it's been used in oyster cards in order to work with the transit systems, and it's got much stronger encryption authentication. It can use DES, triple DESRA, yes, and can do it based on very specific sectors of the data. Multiple keys can be used on each section, and it's authenticated similarly to myfer classic. Now, Crypto1 has a lot of issues with known plain text attacks due to the fact that it's a stream cipher, but when you're using things like DES, triple DESRA, yes, known plain text becomes not very useful, and it's not really been broken in a meaningful manner via CryptoAlt techniques. We're going to talk about creating the analysis tools that I worked with for this product. Obviously, there's a few we know about. There's the Proxmark 3 and the Chameleon Mini, which are probably the most well-known of these NFC attack tools that people see. There's Hydra NFC, which is something more of a hobbyist product, but is very, very useful and uses some of the similar technologies we're using today. Simple NFC, which has some similar hardware to what I'm working with, and is a very interesting project in and of itself, and EMU tag, which also has some benefits to it. So let's start with absolute basics. If you take an LED and a coil of wire and solder them together, you can detect an NFC field. That's all you need to see that NFC is working. It will literally light that LED as soon as you put it within the field's reach and show that it's working. But if you want to go higher level and get more details about the communication, you can create a passive sniffer. Now, I did this with an RTL-SDR, which we all know is a very, very basic, very cheap SDR tool that's definitely not meant to be an SDR tool. This is a device that was basically reverse engineered from TV tuners that people use via USB, but it has some very great libraries that basically allow you to work with it as an SDR tool. There are some problems with it that it can't tune down to the exact frequency that's being worked with for NFC. It can't run at the low sample rate required for NFC, and it's bundled with a really weak antenna, so it's not really useful for many purposes. It's also not built for purpose for being an SDR in the first place. It's built as a TV tuner, meaning anything we do to it is going to be very difficult to work with. So what I ended up doing is because I couldn't tune down to 13.56 MHz because the range is from 25 MHz to 1700 MHz, I tuned to 27.12 MHz, which is a harmonic value of 13.56. As long as I had a coil within the vicinity of the reader, or a tag within the vicinity of the reader, the power throughput was enough that I could analyse the communication from the reader using this methodology. By setting the sample rate to double what it should be, I could still get the correct sampling for what I was trying to communicate with. I didn't require any antenna modifications because of this. I used a traditional antenna and a coil of wire wrapped around it, nothing else. The problem was I couldn't actually get any responses from tags to the readers because the harmonic values and the nature of the antenna I was using just weren't capable of it. So here's some basic output of how this came. So this is an output from the tool I made with the RTL-SDR showing a request message, a select message, a halt message and another request message. Now this is done in order to find any tags in the field that haven't spoken yet without waking up the ones that already have, basically to prevent the anti-credition from happening. There is then the wake-up command which wakes up every tag in the field so that it can communicate with them again. So I made some analysis tools. I wanted to make a tag myself out of components that you wouldn't traditionally use. Now some people use things like PN532 boards and other NFC boards, which are great, but you're not going down to the raw level. You're basically communicating with something that's meant to be a tag. So I wanted to use no NFC chipsets, but obviously I'd need to use a microcontroller, but I wanted to build it as minimal components as possible. If I could do it with like a piece of wire and a microcontroller, I would have unfortunately, that wasn't possible. I had to implement the full crypto one authentication, which would add quite a lot of complexity to project and mean that I needed a microcontroller with sufficient power to do it. By fully implementing this, I hope to find some weaknesses that other people hadn't found or introduce ones that people had found but hadn't fully implemented yet. So there's a few things that happen when you need to work with the NFC field. The first is inductive coupling. Now this is for producing power and for transmitting the communications back and forth. So it needs to be demodulated by the amplitude because basically powering off the field in order to communicate with it is essentially the same as on, off key and used in traditional radios. Because of this, I would need to use some amplitude detection technologies. I'd need to have a decently fast microcontroller with enough power to do encryption calculations and enough storage in order to do encryption calculations. And I would need sufficient memory on the device to store any tags that I'd made. So we're going to go from the basics of how this circuit would work. So the first thing we'd need is an LC circuit. Now this is for inductive coupling with a NFC reader. It's made of an inductive in its capacitor, so that's why it's got an LC circuit, L for inductor and C for capacitor. And basically the inductor was a coil of wire and then now I just use a 10 picofired capacitor in order to tune with that. The resonance can be checked with a logic analyzer rather than a scope which you would usually use even though it's digital information. You can at least check that the frequency was correct, 13.56 megahertz. I then need to demodulate this. So I basically took, made an envelope detector. Now these are traditionally used in AM radios and that kind of technology can be made from a diode, a resistor and a capacitor. This will rectify the signal and then basically smooth it in order to get the actual signal that's trying to be transmitted. Basically instead of having the AM wave as it was. I, via trial and error, worked out that I wanted to use a 1K resistor and a 220 picofired capacitor and that seemed to work very well. Again, I just took the circuit and plugged it into a logic analyzer and I got exactly what I wanted. Now that communication there is a wake-up command basically modulated via the modified miller protocol and encoding schemes. So that's the full circuit that you'd need to use in order to connect a microcontroller onto the NFC technologies that are being used. Now I don't often draw circuits so it's not perfect but it does seem to work. I would then tie one pin to a GPIO input and then that same pin to a GPIO output in order to modulate on the power being received and then just to the ground on the other one. While I said I wanted to use a microcontroller with sufficient power, I actually went for the 80Tiny84, which is a very, very, very small, very weak chip. It's got an eight kilobyte programme space and 512 bytes of RAM, which is nothing. That's one and a half tweets, so not much to work with. It could be programmed with an Arduino or an ISP programmer, though this makes it very difficult to debug with and it can use external crystals basically in order to get it to a tune into the frequency you want. It's also in DIT package so I could build this on a breadboard, test it, and then solder something together as I needed. I could literally just attach the circuit I made before to the GPIO pins and receive the data. The interrupts and timings on it were very good but the debugging capabilities were quite lackluster and because it was an eight bic architecture being used, encryption calculations were very, very unusable on it. So I took a 13.56MHz crystal and the matching capacity should require in order to work with it on this microcontroller and solder them up. Now I could set all the fuses in order to make sure that the 80Tiny was performing at the exact frequency we wanted. I then took the receiving circuit and connected it to an input and output pin ground and due to the lack of view arts, I set up some GPIOs to basically make a software-based SPI master in order to print out any debug strings that I required which was very slow but was good in the early stages of this in order to see how the communication was working. I then had an LED just so I knew when the thing was working and not crashing. The state machine that was used for enumeration, authentication and everything else was implemented and allowed the device to behave as a tag as needed. One of the big problems I had was the timing issues. A 13.56MHz crystal with an 80Tiny is going to have a lot of clock drift just because it's a very non-standard frequency and it's not one traditionally used. Basically, what I was trying to do is that pre-defined intervals, 847.5kHz, which is the data rate of the communication, I read the value of the GPIO. Now this worked about 50% of the time to get an accurate read of the communication that was going on but eventually it just got out of sync and it just wouldn't work anymore. So what I did was I took all of the times that the power was taking down and checked the timings between each one and this basically helped me build up communication just by timers and interrupts and made it possible to be very vague about the timings between these things. By doing this I got a 99% accuracy which was enough to keep the tag and the reader happy and communicating fully. Crypto one, it was meant to be a proprietary library and people have reverse engineered it and created the Crypto one library which is an excellent name for any GitHub project. There were lots of papers involved with this that made it very easy to understand what was going on and it's really not a good encryption algorithm even from the get go. It's a 48 bit key scheme separating these 48 bit keys into 24 bit keys that are cycled between as authentication goes on, which also made the 80 tiny have to do some very strange calculations in order to work with it. The big problem was that when you have a micro control like a 32 bit one, when you're working with things like 16, 24 and 32 bit calculations, these can be done very quickly. There are some problems that mean that an 8 bit calculation will take at least three to four times in order to perform the same calculations. Especially if this happened with the bit shifts that happen, most things like arm micro controllers can do multiple bit shifts in one operation whereas the AVR micro controller set can only do one bit shift at a time, which is very slow. The problem with this is that most readers want a response within 70 microseconds when you let send a request. And so I had to make sure I did this very quickly. I identified that the big problem was in the filter function of crypto one, which has a lot of multi bike shifts and calculations going on. So identified all the parts of this where the everything was going to be slow and all the communication wouldn't work and I calculated these and took them in order to work out how I could improve their speed using assembly rather than C. So all the crypto one code was converted to from C to assembly by hand in order to make sure that I could speed up anything I needed to. Now we all know that if you write a assembly by hand rather than letting the compiler do it, things become a lot more efficient. I use the CIMO VR emulator, which basically allows you to pretend you've got an AVR micro controller apart from the important hardware parts to print out data as it was going along. So I could test and unit testing against keys from the C version and the assembly version. I took all the calculations that would have been treated as 32 bit when they could have been 24 or 16 bit and converted them to 24 bit operations. Basically this meant I could use one register or two registers where usually they would be using four. All bit shifts are converted as needed. So a 16 bit shift can just be used by two move instructions. Eight bit shifts, one move instruction. Four bit shifts, the AVR micro controller has the swap command, which stops the upper nibble and lower nibble of a byte. The two bit shifts could just be done with traditional bit shift operations and one bit shifts, just a shift operation. Basically I managed to make the thing 10 times faster by doing this. Here's some of the assembly code that was used. It's not pre, but it was very effective as needed. Here are the prototype boards I might. Now the top one has the programming header and a button to switch between tag versions and tag data. And the bottom has everything you'd need to emulate a my fair classic tag using this platform. You don't need anything more than those five or six components that are on the board. These worked very effectively and allowed me to basically emulate anything I needed to. So I could take an NFC reader. Now this is the NFC reader that I took to Defcon China recently and discovered that it's the same one they use in Beijing airport, which was very fun to get through customs, believe me. They did question it, but they let me through anyway. I basically could make it print out UIDs by putting any NFC tag on top of it and I took my device and laid it over and got responses. Now I'm going to do a quick demonstration video of this for everyone. Hopefully. Nope. Oh. One second. Sorry. So literally I could wave the thing on top and the NFC reader would print that out and that allowed me to know that it was communicating effectively and that the reader was working. So there are some hardware limitations with this. Obviously I've made something that can emulate a tag fully, but I couldn't now make an attack tool out of it. Basically it was too slow and didn't have enough memory to do it. I used 400 bytes of the RAM and 7000 bytes of the flash, which seems like a lot, but I would only have about 100 bytes of RAM left and 1K of flash left to work with, which wouldn't be enough to make any real attack from this. Also the EEPROM on the device just didn't have enough to store an entire NFC tag. So my fair classic tag uses 1K of data except in very specific instances, and because of this I wouldn't be able to store a whole tag, but I could perform some attacks on it. So I was in a sort of catch-22 with this thing. Complex functionality on Navy IMI controller, especially debugging, it's just not possible unless you've got a much more expensive setup than I did. I was using the most basic and cheap tools I could find. And the number of pins on the thing, which was a total of 14, just wasn't enough to add any extra functionality I'd want to. The slow responses from the tag were just making it very difficult to work with, very specific readers, which meant I couldn't make it work in all instances. So I decided to build a better device with something a lot more powerful. I used the STM32L496ZG, which is a development board and a microcontroller, which has a huge amount of power and a huge amount of capabilities for a very small price. It's about 18 pounds on Amazon, and nowadays that means it's about $18 as well. It has 1M of flash and 320 kilobytes of ram, that's 640 times more than the 80 tiny, which is really crazy when you think about it. The clock speed could go all the way up to 80 megahertz, which would allow me to basically not have to use an external clock if I was clever about it. And the 32-bit architecture meant that I could implement all the encryption authentication without having to do anything too clever like write assembly. It has USB and UR capabilities, meaning I can make it a proper attack tool with commands being received and sent. And it's got proper print after debugging. So if you plug into the ST link at the top, you can debug this thing fully, extremely easily. The PIN configurations on it can be set using the SCM32Q software suite, which basically allows you to click on the chip, decide which one you're going to work with, and set what each PIN does, like if you want to be a timer, an external GPIO, and set the clock rate. Now, the clock rate was very important because this thing wouldn't be able to synchronise with a stranger speed like 13.56 megahertz. So because of this, I decided to find the clock speed that it would support that was closest to what I wanted. When this occurred, I basically decided I didn't want to use an external crystal. The thing that already had one, and it would involve some SMD soldering, and it could have broken the device. Because of this, I wanted to look at all the range of frequencies that it could run out, which is a huge amount, and find the one that had the most suitable candidate. Now, this was important because my fair classic and all other NFC in this area uses Manchester coding for the responses, which means it's inherently got this ability to keep track of the timing and the frequency that's going on, so that if you get out sync with it, eventually you can pick it back up again. So I looked through all the possible values it can be, and found that 72 megahertz was the fastest and the least problematic value I could use. So it was only going to be about, what, 50% hour of speed. So this is the device I made. Again, extremely simple, big coil of wire, capacitor, diode, resistor, and another capacitor, and that's all I needed to convert this device into an NFC tag that we used to perform attacks in this platform. It's extremely simple but effective, and I really didn't want to do anything far too complex because it just wouldn't be necessary. I wanted to add a lot of different features to this, especially ones that weren't present in existing commercial devices like the Proxmark and the Chameleon, not because these devices aren't excellent, but because if I'm just covering their work, it's just not fun anymore. So I made it so it can emulate more than one tag at once. Now, this is a very useless ability, but it would mean that I could put it on a reader, and the reader would think that there was two tags. This could have caused authentication issues, communication issues, and make the thing just get very confused. So this can be handled by just taking the same state machine that was being created, and making sure that the responses matched what would happen if there were two tags in the field. So this would be either forcing anti-collision by sending randomized data when selections were made, or by cascading a request. So one tag was selected, wait for it to be selected, and then bring up the other one in it. There was not a huge amount of weaknesses I could find with this, but I thought it was quite interesting. Dynamic Crypto One Key Generation was another one. Now, this would allow me to make a number of different UIDs, and basically cycle through them while also changing the encryption keys being used. This would allow me to quickly work out how the authentication was working, and help me more easily generate tags based on what I wanted to do from random data, but also change the keys to match. This is because a larger number of these devices authenticate using keys generated from their unique identifiers, so that it's not the same for every single tag that's being put in the field. Now, this is very useful, but it can cause some problems with authentication in general. I wanted to implement Desfire, which has been implemented on a few forked versions of Proxmark and Chameleon Mini, but not in the mainline versions as far as I know. Now, you can make the thing pretend to be one of these just by modifying the SAK and ATQA values that the tag would present, and make sure the response value is matched as needed. I basically wanted to replay any legitimate responses I get from a reader, so I took a Desfire tag, put it against my phone and saw how it read and replicated that as I went along, as it basically just went through each section of this. The authentication functionality is well documented, and as there's source code about now to work with this, it makes things a lot easier to work with. I took the MyFair Desfire tool, which is an Android application you get in Google Play, and basically taped my phone to the SDM32 device and basically ran it every soft and to see how I could mess with the responses in order to get the thing to work. Literally taken my phone and sticking on top of the device. Now, let's talk about security weaknesses a bit, so we've gone through how we'd build these attack tools. Let's talk about some interesting security weaknesses on this platform. So Crypto1, which is still used everywhere in MyFair Classic tags, has been well known to be absolutely useless. It has little to no security in the same way that web keys no longer do. And it's important that people still know why they're weak for the same reason that we should still know why web is weak. So it utilises a 48-bit key, so it's 220 or 4-bit keys that cycle between as authentication encryption is happening, making things a lot stranger than you'd see in a traditional keying scheme. It's vulnerable to replay attacks if the same requests are made from the reader, you can respond to them in the same way. But there are weaknesses in the nonce authentication mechanism that allows you to recover 32 bits of the key stream and use that key stream to generate the keys eventually. So key recovery for a sector can be achieved basically by allowing the authentication to get to the point where the reader has sent its response to the nonce during the authentication. You then take this value and generate that encrypted value yourself because you know what the nonce is and you know the amount of cycles you need to go through the PRNG, XOR it with the values being sent by the reader, and this allows you to have this key stream you can work with. You then take the 224-bit keys or all the 24-bit keys you can think of, this is only 16 million, which is a huge amount, and for each alternating section, that's 16 bits up to 32, you try and find all those keys that would potentially match that stream. Now this will create about 200,000 if you do it one way and about 30,000 the other way, and this basically can be used to get you enough of the 24-bit keys to reduce from a 48-bit key user trying to search through, it's just something like a 40 million keys to search through, which is a lot quicker. Then you can roll back through the initial authentication because you know how that works, and get to the point of the state of the key stream where the keys are what they would be when the things start and that makes the gives you the keys. So, authentication is requested, a simple nonce is sent back, the randomized data and the encrypted nonce is sent by the reader and that's all you need in order to get onto this and start attacking the keys. I've not got to the good part yet, you know? Believe me. So, this can be used for offline cracking, so rather than having to stand next to an NFC reader, you can go up, wave a device in front of the reader, get this authentication, go away, not for very long even, about 10 minutes and get the keys back. It's a bit more complex than that, but that's the long and short of it really. This is more efficient than reader-based attacks which often have very weird scientific and statistical approaches and it's more like traditionally cracking in the same way again as you would crack a Webkey just attacking the stream site that's being used. This functionality is already available and well known, but it's never used because it's really, really not very efficient to work with. I decided to implant this with a bit of a demo with a few toys I had around my flat from my recent visits to Japan. So, I had my fair classic reader for a Japanese video game based on the Carmen Rider series, which I'd never heard of before. This was basically a USB device you'd plug into your PlayStation and it would communicate by you putting tags on top of it, which were shaped like toys, giving you access to those characters in the game. The reader was identified to use the USB and allowed me to use a man-in-the-middle attacks using my Beaglebone Black and the USB proxy tool chain, which allows you to basically man-in-the-middle USB communications between a host device, usually a black box host device, and the USB device itself. Analyse the entire protocol, allowing you to revert engineer it and make your own USB-based tools to attack this. I did that and took my STM32 and just laid it on top of the board so that I could then send authentication requests to it by using the revert engineered USB protocol. So, I made it print out section numbers, information basically from the STM32 based on what's being requested by that USB reader from what I told it to. This allowed me to reverse engineer more about how the key generation worked, but also very quickly brute-force a huge number of keys based on a huge number of view IDs, which I could use to basically emulate anything I wanted to. Purely for the purposes of showing that these encryption keys are just weak to a terrible extent. And yet if you go to most places in England which have door access controls, you'll still see this technology being used. It's very surprising. So, here's how it works. It got the authentication, ran through all the authentication and encryption data and got a test key out in under 10 minutes, which is incredibly fast, and that was on a one-core i5 laptop. Improvements that could have been made to this algorithm include increasing the key size significantly, even bringing it to 64 bits, which wouldn't be hugely stringent, would have made this a lot harder to do, which would make things more secure and make some of these attacks just not possible. Using a single large key rather than two keys that are played off against each other would mean I'd have to brute force every single one of the keys in that bit range rather than two 24 bit keys, which is just 16 million values, and very quick to do, and an improved PRNG would prevent the replay attacks that could occur from occurring. Removing any known plain text from authentication, remove the opportunity for exploitation as well. Now, this is important, especially when you look at things that are newer, like DESFIRE, which have somewhat similar known plain text issues, basically based on how the tag works, but because AES, 3DS, and DES really aren't vulnerable to known plain text attacks in the same way, there's no real problem there. So, let's talk about some raw protocol weaknesses. Now, the raw protocol weaknesses are important because even with traditional NFC chips that are dedicated for that purpose, you can attack things like NDEF and other more high-level issues, but you can't attack the enumeration level, because if they hadn't implemented that, then there wouldn't be very much point in having an NFC chip set in the first place. The big thing is that initially enumeration, that's sending requests to identify unique identifiers, is performed by all tag types of this range, meaning that if I found an attack there that was viable on the readers, that would be very useful in a lot of places. A big thing as well that I noticed was that I could send a lot of data basically ffuzzing responses to requests in order to see if the device will crash or get confused. This sometimes happened when it wasn't really a viable attack. I found that the greatest weaknesses lie in the anti-collision procedures myself. Now, I like this bit of the documentation of Texas Instruments pseudo code for tag detection. The note is extremely important. Due to the highly recursive nature of the anti-collision algorithm, there is a risk of a stack overflow. It is highly recommended that the user implement the stack overflow check, which is not very good because they're never bloody due. What they often do is just ignore this technology entirely and don't use anti-collision, but when they do, they've never done it properly and it's always got problems. So what I ended up doing was making my tool respond over and over and over again to any authentication that happened pretending that there was an infinite number of tags on the reader at that time, by basically every time trying to use anti-collision on it, forcing it to just send garbage data. By doing this over and over and over again, eventually the reader would just keep asking for more and more data past the maximum size for a unique identifier, eventually allowing the device to crash. I'm fairly sure if I tried hard, but I could have got some real cool buffer overflow weaknesses from this. As I said before, there's high-level weaknesses that are basically usable on traditional ship sets, even some Android phones, including NDEF data, which has some issues of memory corruption and authentication mechanisms which can be worked with on all sides. The big problem of that I found was that most tags just haven't gone of power in them to do proper authentication or anything like that in them, even if they were dedicated for that purpose. So I made this. It's a Sonic screwdriver, a toy one, which is now full with all the tools that I've just talked about, and I've got it with me. It's got four modes so far. It's got traditional NFC tag, fuzzling, transmission of ASK data, basically it's got an ASK transmitter in the handle, which transmits any authentication being sent from a reader to the device, allowing someone with a laptop and an SDR far away from me to get the authentication keys back and dump the data. Now, I decide to use a much smaller, but still quite powerful chip for this, an STM32F070, which is a very small T-SOP chip, but has way more power than even the 80 tiny, which was a lot larger. So 32K of flash and 6K of RAM. I had a recommended clock speed of 48MHz, but it could be pushed a lot further, like 72MHz. So I could basically copy and paste a lot of the code I've done before and make it still work. And by drag soldering on to a breakout board, I could literally load it into the sike screwdriver and get it working. I decided to basically make it programmable from the top, so I could add extra features as I go along. I've added more features since these slides were made, so there it says three, now it has four, but because it's got three LEDs on it, I could get up to seven if I really wanted to. I managed to use the internal clock on the device, rather than having to use an external one, keeping the amount of hardware inside it very low, which was necessary because there wasn't a lot of hardware in the case. It's using a lithium-ion battery in order to power it and in order to keep the power high, and what's interesting about it at the moment is it's using the battery from my Nintendo DS because at the last minute, the battery I had not exploded. I'm going to talk about some future work. I'm going to release all the source code for this hopefully soon, and I'm going to design some boards to go along with it to make it a lot easier for people to work with, because if I can make a simple dip package board that people can solder themselves, it would be a lot more fun for people to work with. I'm going to work with Deadfire more and try to implement it fully and try to find attacks on it, and see if I can find any tag types that I haven't yet worked with. I'll take some questions now, but I'm also going to be in the hardware hacking village at five o'clock to answer any questions and do a follow-up talk where I go to the really, really, really low-level details of what I did to develop this project. Thank you very much. Any questions? I haven't know. Now Live NFC is a great tool that's used by most people for most of the NFC communication. I just had a chance to look at it, yeah, unfortunately. Fine. Thank you very much.