 Hello, welcome to my talk. I'm hacking the DEF CON 27 batch My name is Seth Kintai. My background is hardware and computer security. So this project was a lot of fun for me I just wanted to give a little background on some of the terminology we'll be using in this presentation NFMI near field magnetic inductions It's basically using magnetic waves and fields to communicate instead of radio Magnetic fields decay much faster rate than radio does passes through body tissues better, so it's better for short distances for body area networks the short distance supposedly makes it more secure it's more efficient and Hasn't been used too much basically uses two coils to communicate with each other sort of like Electromagnets or half of a transformer talking to each other instead of using antennas and It's used in proximity cars as part of the NFC protocol and it's used in some hearing aids And I think some earbuds, but not too many other locations and maybe they had dreams of putting it in Apple earbuds because I read that somewhere in a blog, but the company was extremely cagey about any sort of information on these chips There was no data sheet at all, which is bizarre No info on the protocol no dev kits no samples if you wanted to order anything you had to order like Tens or hundreds of thousands inside an NDA just couldn't find any real Official info on these chips software-defined radio basically taking all the hardware guts and making it virtual and Putting them into software makes designing new radios and mixing magic parts much easier and more fun I use GNU radio to do that sort of thing and Modulate demodulate signals to some other tools of that too. I used hack RF to Receive and transmit my signals and tune them There's no antennas, but I made a bunch of coils just wrapping like electromagnetic wire Should probably have some pictures of those online at some point and Use Python for everything else a few other terms you should know buffer overflow attack is how that works I'm sure most of you familiar with that Basically, just blow away everything on the stack and keep on writing until you overwrite the return address and tick control of a program SWD or JTAG those are different Low-level hardware debug interfaces are like GDB, but super low-level Control the clock one cycle at a time fun stuff And then a convolution code basically error correction code spreads out Bits over multiple symbols to make them more resistant to noise So the badge was part of a game They communicated the badges communicate with each other and they'd like make little beeping noises and Blink lights when they pair with each other and then if you paired with a magic badge It would advance the stage of the game you were in and there were six stages and you'd advance once for each of these different Magic versions of these flavors of badge And then once you got all of them you won by getting a piezoelectric rocker all And the badges are actually cut from pieces of stone and there's a great presentation on that should check out The badge hardware has a MCU that does most of the work Controls the lights and speakers and whatnot and talks to the NFMI chip over UART When the MCU boots up it loads firmware and in that firmware there's a little patch of firmware for the NFMI chip and it sends that over UART and patches that on boot up the debug hardware debug interfaces are labeled on this picture you can connect by serial and Talk to a console that's running on the MCU or you can connect to SWD and do some really low-level debugging There's no connectors on there. There's a in that picture. There's a connector soldered on to the Serial port, but they're just they're unpopulated Connectors for now and you can either solder on a connector or solder wires on directly or use a pressure fitting the badges Communicate in a sort of bizarre way they When the badge MCU wants to transmit 8 bytes first it adds a D to the beginning then pads every single 4 bits every nibble with a D and Then ends it with an ASCII E Sends out over UART the NFMI chip receives that Immediately strips all of that padding off and transmits it And the receiving badge receives that puts all that padding back on again sends it over UART and then the badge strips it all off again Early on in the game I decided to reverse engineer the code that someone someone pulled the firmware off the badge So I reverse engineered it and looking through and after a few hours of that someone I think it was Joe Grant actually released the source code. So There was sort of wasted time, but on the other hand, I'd never actually seen all the correct answers when reverse engineering code before but New experience I tried plugging into Ghidra. It didn't work very well back then I still know if it still does I ended up using an old version of Ida Pro and worked a lot better While poking through with Ida, I found a buffer overflow and it seemed so obvious. I sure was sure it had to be part of the game As you can possibly tell from the code It's basically reading bytes into a buffer until it finds a letter E and It will read that buffer is 18 bytes total, but there's no limit at all Just read and read and read and read Don't find that E. I made a proof of concept early on. I wanted to make sure this Buffer overflow was actually exploitable So in notepad I wrote up some armcode and just use an online assembler to convert that into machine code and I wrote this little script here to Use a J-link over SWD not JTAG. I connected to the badge Loaded my payload into the ring buffer. I set the the Transmit index and the receive index values and this told the badge to run It thought it had a giant packet and we'll see what happens This is the serial console for the badge I'm telling it to receive a packet now. I'm going to send it one the regular valid packet And that's what it displays Now I run my hack through J-link so now there's a Oversized packet sitting in the ring buffer next time I tell the badge to receive it my code takes over Prince hack the planet on the screen That works. So now I just need to figure out how to send a gigantic custom crafted packet so I dug around online for specs on this Chip use on this badge the NFMI chip Found a few details and good guesses on frequencies and bandwidths Pretty good guess on the modulation from a lot of random sources Started looking at the signal in analog First you can on the top row you see 16 bursts over about 10 seconds Middle row I have magnified one of those first you can kind of see where the different sections are The bottom row lets you see the four distinct sections of each burst Section one seems to be timing pulses sends The carrier frequency and then one that's 150 megahertz higher and then 150 megahertz lower It doesn't seem to be transmitting any data, but it may be doing this just to Establish a range of frequency and amplitude of the signal as well as timing Quick note on down conversion if you're not familiar with the subject It's just you're not demodulating the signal. You're not changing at all other than lowering the frequency By multiplying it with another signal kind of think of it like a beat frequency in music So you're just shifting the signal down from say 10.5 69 megahertz. You're shifting that down to zero megahertz so Now all the energy is around that plus or minus 200,000 K kilohertz and it you can see how The signals that were at the carrier frequency are now basically flat lines because they're at zero or almost zero and What a whole bunch of squiggles that weren't didn't look much different from each other are now much more clearly Data you can see there's repeating patterns in them. So section two has these patterns That Plays them twice sometimes exact copies sometimes they're inverted sometimes they swap places between I and Q and There's only I think eight different patterns it shows I ended up calling these preambles based on them showing up later in the other packet Section three just seems to be more timing Tried my best to get it to be exactly zero hertz. I've never quite could and then the frequency would drift I think with temperature I don't really know And then section four was data 271 copies of the same data packet Um, each one starts with eight variations of those preamble you saw in section two are almost exactly that preamble. It's slightly different And then followed by data and then a brief null or pause And sometimes they are exact copies of each other and sometimes are inverted Sometimes the IQ swap just like with the preambles in section two The modulation used is D8 PSK PSK is phase shift keying. It's basically Modulating a signal. So when you plot it it shows up as The bursts show up as one of those eight dots on that constellation It'll actually form that on a plot as long as your timing is right um The eight refers to there being eight points in that constellation and then D means differential So it's the difference between each point Is where your actual data is transmitted And each of those points is called a symbol The center frequency seems to move a little bit um In the beginning I had one frequency that I just Narrowed down to a very precise frequency. It was working very very well until I Broke the badge and then it switched to 1.4 and then later on I fixed another badge I had broken earlier and it was using 1.569 megahertz So the I don't quite understand why the frequency bounces around so much I was initially using a sample rate of two million samples per second But the timing didn't work out and I said, oh, well, obviously it's it's 596 kilohertz bandwidth then I need to use a A multiple of that for the sample rate. So I use 1.192, but that didn't work out either And I ended up using this 1.190 55 And that worked out perfectly For 440 samples per packet or four samples per symbol Why that number? I don't know I'm using hackrf to receive the signal It does the down conversion And uh resampling so I can use it easier to use frequency and use a much lower sampling rate because your sampling rate Must be at least twice your highest frequency in your signal And then I use GNU radio to write my demodulator Now there were some examples online of some lower order like some four psk demodulators and modulators and I figured it would be easy enough to Modify one of those to eight psk, but it ended up being a nightmare and They the examples used components that don't exist or never worked or were broken for other reasons and not documented No one could help and the docs were a mess and it's kind of a nightmare. So I Made a bunch of working examples of different flavors of my psk modulators and demodulators and I put them all on GitHub to help other people out Now I had to deal with noise and nulls there's 271 copies of the The same packet, but they varied a bunch But only some of that was the noise it turns out that because of those null symbols at the beginning Normal dpsk demodulator doesn't understand what those are and tries to put them into one of those eight quadrants So it kind of interprets them as eight for three random symbols And then after those nulls there seemed to be an actual random symbol Which is why there was eight different variations of both the preamble and of the packet Now the nulls were new to me all together and you could maybe even call it like a sort of a ninth symbol in that constellation I googled around trying to find out other examples of it and xp the maker of this nfmi chip They also make this cool flux dsp audio chip And it also uses a similar Modulation scheme with nulls and those nulls are used for finding the timing of a signal so my Demodulator spits out a stream of symbols, which I've then I've manually parsed here just to make them more readable You can see section one is 21 copies of Just blasts of that signal is basically junked in those symbols Section two we see that preamble copied twice Followed by a little bit of noise and I think mostly nulls Section three is just some more timing blasts And then section four is where our actual data lives And these are our the symbols for our packets 271 copies of them. They should be identical. They're not because of some noise So I had to write a python program to Basically ignore the first few bytes or few symbols Then count up all the different patterns of packets that Each flavor of packet are in there and then whichever one has the most copies is Judge to be the the correct copy and that's the one copy of that one is output The preamble consists of 20 fixed symbols and then 12 that can be in one of three patterns The section two seems to flip randomly between two different sequences of those 12 Preamble symbols I don't know what they meant I assumed that the one with mostly zeros could be like the mask for All zeros but it doesn't quite seem to be right It could be I don't know Never really figured that out and then section four every single packet always starts with the same preamble Which is different than the other two and here we see the structure of the entire packet We've got the header that has those nulls and that little random byte or random symbol Referring to is the primer and then the preamble then we have the packet data which is um 64 symbols corresponding to uh 16 bytes The first four bytes appear to be a counter Then there's one byte that is used as the length field for the user data and then There's 11 bytes available for user data But the badge only uses the first eight the last three are just left unused and then the footer has what Well 10 symbols that change with every single packet as the counter increments So I assumed it was a checksum or c or c of some sort Now I need to find the mask the zero mask for All of the the data Because if you fill a packet with zeros in the data fields, you don't get a packet full of zero symbols You get a random looking pattern of symbols This is the mask that they've used to either obfuscate What's being transmitted or maybe it's used for spread spectrum or noise resistance or something Not entirely sure but basically when you send an empty packet, you don't send all zeros you send a pattern So I was able able to easily change the first eight bytes to zeros and confirm that there's this crazy mask Later on I modified the firmware to allow me to The the mcu badge firmware To allow me to send 11 bytes in a packet set all those to zeros And that's what the pattern you see on the bottom of the screen Though I didn't actually see any sort of pattern in this pattern Finding the mask for the other data bytes was a little more difficult I was basically able to confirm that the counter was counting it was counting by binary values except it was counting by twos and I didn't know if it was starting off odd or even I basically had to guess And because of the tail that it has in change symbols That was covering up some of the other symbols So I needed a way to figure out something Um, I observed the counter incrementing in that binary fashion decided well, I'll just record it for a week Um, eventually it found that Um, after about a week, it finally flipped the tenth symbol So I was able to get uh 10 of the mask symbols and then The tail of change afterwards. I have no idea what those bits are so I don't know if they're ones or zeros So only the green is what I'm Positive or so I thought were zeros based on my guess of what was odd or even at the beginning um And I realized that it took 19.1 hours to get the ninth almost a week to get the tenth symbol It was going to take decades to get 16 symbols and Over 9,000 years to get all 20 And I tried to brute force them But I just didn't know enough about the math of what was going on with these symbols and the values So I couldn't brute force them And I needed a smarter way Then I got lucky by becoming unlucky. I uh murdered a badge We got really angry. It started transmitting a weird pattern instead of 110 symbol packets It was doing 108 symbols and 108 nulls um Transmitted a different frequency and even weirder the counter slid over by four bytes So now instead of counting at byte zero three it was counting at four through seven And I assumed initially that it set those first four bytes to all zero But this by watching it count the uh the upper bytes that let me figure out Well, let me confirm The mask for the length byte And helped me uh to do some other bytes as well So I finally got the mask of the first five uh bytes though At least assuming my uh zero slash one guess was correct. It was odd or even that I was starting with So sometimes it's better to be lucky than smart. Um, so I finished this up um, we're kind of fast forward to the future a little bit, but I later on Discovered that whenever you update the transmission badge or the packet that the badge transmits to other badges Um, it makes the counter count whatever it's counting count super fast I'm almost 350 000 So I wrote a script to count over and over and over and that um advanced all the bytes of the counter which let me uh confirm more mask bits It also let me confirm that my initial guess was zero. Well that and the uh Some erratic counting later on in the future when I was decoding um The sequential count but should be sequential wasn't always sequential. It was bouncing around by eight or 32 here and there And I realized because my initial guess was wrong So that get that what I found above as a mask was actually the mask for the value of one um It was really a mask of zero But that also means that when I broke that badge instead of all the bytes being zero it was Also started at one which is weird. I don't know what that means Next I need to find the checksum mask, but really there's no way I could figure that out right now all I can do is At least until I figure out the algorithm and then figure out the data and then figure out which part of The packet that the algorithm actually protects like there's a predictive preamble or not, you know, so basically I just guessed by picking um symbols that I already seen in the packet called that zero Or just whatever and moved on so one thing that the counter indicated was a convolution code is being used so for every um Odd bit that's changed whereas we're defining an odd bit as Like bit one with lsb being bit zero So bit one bit three bit five any of those change only a single um symbol is changed But if an even bit is changed then six of the next seven bits are changed or symbols are changed Now that pattern looked suspiciously like the one used by the Voyager space probe I don't know if that's coincidence or if that's somehow they've been adapted to use this into the the badge transmission I haven't figured that part out yet It's also odd that only half of the bits are being protected because normally you'd want to protect all the bits from noise Only having half doesn't do you much good So to reverse engineer this I started by changing just one bit at a time whenever you change one odd bit Um that would just change one symbol and it always adds four to the symbol If you change one even bit then six of the next seven symbols change and in a pattern That depended on how far away that symbol was from the bit that was changed and Based on the zero mask that was used at that location So I figured out the pattern through just a lot of Um making examples and taking lots of notes and making crazy excel sheets And finally figured out the math of how a mask changes each bit at each position I've listed it by the symbol positions And then also listed it twice In two ways one is the code Basically python code of where the mask is Like what values the mask is and then um if That mask existed that position like say mask is in one two one two five or six So if it is and that's a one times four plus two And as a more lower level electrical engineer sort of way to think about it I also included is a an array of bits so you can look at the bit math And possibly that could be related to the Voyager probe, but we'll worry about that later um, so that figured out for a single bit But Once you start using two bits or changing two bits at a time Then the math gets really ugly again And it just goes crazy. I tried coming up with some really complicated algorithms To figure it all out, but I eventually realized well why instead of doing that let me just treat everything as um Just a mask every sum of every step is the mask of the next step And made seven different steps like that and it all worked out So here it is stepping through that um Or you start off with the mask and then If the um you follow those rules from earlier to change if a bit changes then you add say six Compute the sum that sum becomes the mask for the the next row the next and next and next So that rule of course doesn't make any difference if you're only changing one bit, but when you're changing two bits Save the mask is three Position zero you add three plus two you get the sum of five and I use five as the mask for the next bit down on and on And it actually worked Except when I started decoding the counter It didn't always count sequentially it did most of the time but every now and then it would freak out and then go back to working again And I realized that sometimes odd bits are convolved but in when it's multiple odd bits that have been flipped um But there wasn't much rhyme or reason to it I just started looking for patterns and any time I found a pattern that worked For a lot of the problems that would code that pattern out That would solve most of them but then a few more would slip through Just did that a few times and I ended up with these four rules All of the rules are interesting that they don't care what the current bit is they only look at previous bits Some of them two of the rules care if previous bits were zero instead of one all those x's are the don't cares And you can see the rules are mostly don't cares But now we know the answer that all the bits have some sort of convolution code protecting them the first um Convolution code that we saw earlier could be that voyager code could be a trellis code modulation I don't know if that's actually possible But I won't go into that And then the other convolution code is I have no idea I made that little circuit diagram for how I think it works, but other than that I didn't recognize it anything I looked up online So now I need to reverse engineer the c or c um And early on I noticed that each packet um, the c or c has a possibility to contain basically 20 bits of data in those 10 symbols but when I um count it up The number of patterns that actually showed up it was only 2 to the 12 or 40 96 patterns So that was telling me it was storing 12 bits in 20 bits Which was strange And then there was also the issue that when you change a uh A bit you can have a tail of up to six changes behind it and Won't that tail of changes overwrite the nulls and primers and completely destroy the packets? So something Something odd was going on here I also confirmed that all of those symbols had to Be used because if you tried changing any of them Then the packet was rejected. So clearly all those symbols were being checked So they all Were important in one way or the other And um, so I need to reverse engineer the c or c if I ever wanted to make send my own custom packets I tried this tool called c or c revenge And it just didn't seem to work at all on the values I was pulling out So I said fine screw it. I'll just write a python program and brute force every possible c or c algorithm And that didn't work either. So something really odd was going on While looking through the c or c values of A bunch of packets in sequential order. I noticed that the uh, The checksum was changing by a predictable amount like every time just the lowest bit changed It was x oring the checksum value by the same amount Which told me that the uh um x or the The checksum was being built up by x or Probably from a table just like a c or c And I hope through that some more eventually find the pattern to it, but um in the beginning what I did was I um used all the counter values to Find where just a single bit changed between two packets x or those Uh packets or x or the c or c's from those And that gave me the x or value for that single bit change Did that for all the counter bits? Did that for a few of the uh um the length Uh bite Couldn't really do it for all the counter because the even like the high counter values were just would take months to flip through But since I'd realized that when you update a packet fast forwards it by some 350 000 clicks So I wrote a program to speed it through a whole lot of those bits And then I wrote another program to do a bit walk basically change one bit in every uh data byte And walk that back and forth through all the uh data bytes And then I wrote a cute little program to adjust all those and Build up the c or c table Now that I had most of the c or c table values for each bit I was looking through the changes in them and noticed a couple patterns And the first was a pattern in how the actual uh data bits are stored in those symbols And it's kind of ingenious The way they're spread out. So the first four symbols holds our first two symbols holds four bits and The the next symbol after that holds two bits So Basically the way that it spread them out where the even bits are used and only the first three symbols Those even bits since they have a tail That can be six long That tail doesn't extend past the end of the c or c So it doesn't overwrite the uh the nulls or anything like that So basically it used mostly the um odd bits to store bits from the c or c and just a few of those even bits and Made it all fit and um then the for just extra fun I guess they shuffled the order of those bits all around and that shuffling is what made um the c or c revenge fail what made my brute force tools fail once I removed the um the dead bits and rearranged the bits that actually had useful info in them Then suddenly c or c revenge worked perfectly So now I can compute the c or c table for all 16 bytes. I also noticed a pattern between The the values for every single bit in my table and use that pattern to fill up the rest of the uh the symbols but With c or c revenge that also showed me the the exact name and uh algorithm used for the c or c So that was nice So now my original guess for the mask Um, I I knew it was wrong in the beginning for this the c or c zero mask But it worked anyway because basically since the c or c is built up by xors and It was basically xoring My bad mask which had my bad base value And all those xors were cancelling out and it worked most of the time But it was flaky probably because of those three bits of the tails that weren't quite xors the way the tails change So once I figured out the new mask everything worked like rock solid. It was beautiful Um, I think the c or c doesn't protect the preamble. I think it's only covering the data Um, I tried coming up with counter examples. I tried making a ton of different packets um with using different preambles and testing all possible c or c values and Could make any other preamble's work. So that's just an unknown Also, I basically went with the assumption that the c or c of those 16 bytes if they were all zero That the uh end result would be zero because that's how c or c's work And based my mask off that and it worked So with that I can finally craft my own packets Um tools will be released on github if they haven't been already um I can now uh Basically make any 16 byte packet I want except I need a 36 byte packet and over to overflow the badge And possibly even more to do any cool attack Needless from the start. I just assumed that would fall into place along the way Um, but didn't happen never found a field in the packet that actually let me set a longer packet length Um screwing around the preamble didn't work So it was time to try reverse engineering the nfmi firmware to extract the nfmi firmware I needed to run swd And to do that I needed to be able to access the reset line, which unfortunately was buried in the middle layer of the board Um, the ball on the ball grid array on the bottom of the chip also was not accessible So I had to pick through slides and other info from the presentation Figured out which ball on the grid it was and then I zoomed in really close on some of the slides that didn't have the uh So that the middle image it's from the slide There's that's the circuit board before it has the white paint on it So you can kind of see the middle traces faintly in the middle of the board um, also with my uh, one of my badges I scraped all the white paint off and I Uh cut through the bottom layer of the badge to remove the the metal ground plane and Was able to shine light through it and then eventually Joe Grand actually was nice enough to send me some Uh schematics that showed exactly where the resets lines were just to confirm but uh That helped me find the reset line now. I need to connect to it So as you can see in the top I had to scrape the paint off and the top layer of the board to get down to that middle layer of the board um kind of made like a little sea of a Flux on it based on a video I watched of repairing iPhones so a little sea of flux and was After a few tries I was able to solder a wire onto this trace that was smaller than human hair I think this didn't actually work though I think I had to go back and actually cut the trace and then do it again because uh the mcu was Still connected to the reset and was like changing the reset while I was trying to change it with the swd commands so I think uh I don't know. I think that's second uglier image onto the the right of the soldering is the second time I did it And so I was able to connect to it but um when I hooked the j-link up to it to the swd It could not communicate with it because I didn't know what kind of chip it was. I was guessing different cortex chips And nothing worked. I thought well, maybe you need pull ups. Maybe you need pull downs Maybe there's noise. Maybe I need to go slower. I I tried everything. I tried going at like one kilohertz And nothing was working. So finally I had a desperation. I just started randomly trying um The default settings for a whole bunch of different chips that were related or even kind of unrelated And then one of them just worked So I quickly downloaded the entire memory space. I could which was uh zero to 18 000 And um realized at that point because I guess of I don't know either screwing around earlier with the reset line being connected to two things or maybe cutting it Or maybe just based on the way it boots up, but Whatever little snippet that the mcu firmware sends over to the nfmi chip wasn't there so the protocol was missing but At least I got all of the other hidden stuff because The protocol only makes up like a few hundred maybe thousand bytes And I got a whole lot more than that and all those hidden functions and stuff. So that was very helpful so I pulled the nfi nfmi protocol bit out of the mcu firmware Figured out the base address of the different pieces of it and plopped that into the the binary just pulled out that 18 000 by binary And stuck that into idopro Um, once again, I couldn't find anything indicating like a packet length field or anything like that And I also confirmed there's code that actually checks to make sure you're not claiming to send more than 11 bytes And fast forward to the future. I was able to remove that at one point, but It doesn't do me any good because I can't send more of them actually 11 bytes. So if I Fake it it'll try outputting it, but it's outputting like zero that uninitialized garbage and wasn't helpful But I had seen Oversized packets happen before and I'd even log them as you can see in that log down there I'd hacked a badge firmware to spit out every byte received and the length And after a bazillion length 22s, I got a length 52 and then it crashed said welcome to defconn again so Obviously it's happened spontaneously In the wild why how how why how do I make that happen? Well, I was saved by some more bugs in the badge firmware um So when the the nfmi chip sends that Sends a packet over the uart and it's all padded out The badge receives it but instead of trying to Copy the entire packet off of uart. It just copies one at a time So that alone allows um a partial packet to be copied if it runs out of space And then there was also this off by one error where it seemed to uh Make sure there was always one more spot free So basically it's checking for two bytes free before copying one byte And that allowed it um an odd number Or an odd sized packet Which was nice because it would just chop off just the e At the end and maybe might might be followed by however many bytes of data I had on there so Then later on when the badge actually tries to use that um packet data It starts with reading it to b and keeps on reading until finds an e So with these uh errors I was able to send a b And then 16 bytes of padded data and then no e um, I can completely fill up the Ring buffer by just sending a whole bunch of these And then I tell the badge to read At the moment it reads the first one now it's freed up 18 more bytes So I if as long as I'm still blasting these packets it'll now write a second packet into that hole So and then the badge will keep on reading everything and when it gets to that last packet It sees a b and then 16 bytes of these like 16 of these padded nibbles And then another b and then another 16 and then an e So as far as it's concerned it just saw a 33 byte packet, but wait there's more so if you keep hammering that even More It's possible to send even like the max size 11 bytes which ends up being 22 these padded nibbles So I can sound like a b 22 and then it hits that off by one error and chops off the e And then when a packet gets read Freeze up enough space that if I'm still writing fast enough or transmitting fast enough It can stick another b 22 in there with no room for the e And then since the badge is reading faster than I can actually transmit by the time I send a third one It'll um be more than enough space for that e of food in there too But basically I've now made a 68 byte packet And then I haven't actually played with this but I could probably even fill the buffer first with like super tiny packets Like two byte packets to make reading take much longer And maybe you can stack even more than three of these 20 d 22s in our d 22s So now I can crash a badge. It will a stock badge um This takes a long while with a 20 48 byte buffer and it makes like a pretty boring demo So I cheated and I made a um A badge that just has a 72 byte buffer What I do is I basically fill up the buffer And then I drain the buffer so now that I'm like at a known state and I fill the buffer again and Read and keep on transmitting while that read happens and I'll should crash the badge So here the buffer is full I'm going to empty the buffer I switch over to a new radio and start playing the packets as fast as I possibly can A little faster than display can keep up with and completely fill the buffer And the video glitches up for no reason and then we go over here See the packets And it crashes A crash is neat, but can we do something more interesting than that? Well, unfortunately that padding gets added to every single packet and it's going to ruin any sort of attack that we try to send That does something more interesting than just crash So we need to cheat I have found the Or I dug through the firmware for the fmi chip and found where it pads data and remove that And found that b&e stuff also and remove that We can still fake that if we want the badges to talk to each other like normal, but now it's optional I just found all that code and replaced it with no ops But to install that code into the chip I had to figure out their crazy format first Which was just proprietary and weird and slowed me down for a while But once I finally got that in there, I was able to do a lot more fun attacks Here's a freshly removed badge I switched over to gnu radio And I play my attack it takes up four packets to fit the entire buffer overflow attack Let's get loaded into the buffer switch back to the badge. I tell the badge to read the packets And it executes my code I'll end with a few oddities and mysteries that remain I never quite understood what that initial packet that it sends out with that 0403 E045 At one point I convinced myself it was a buffer address. I don't quite remember why anymore Sometimes when it's an error it sends a different code. I don't know what those mean There's also a rev string and another value next to it And I was wondering is that supposed to be a frequency or something else? Um Was never quite sure about If it was truly a differential signal or a double differential signal because The preamble suggested it might be double Um, never got figured out what the rest of the preamble meant Not sure if the cdc protects it Um Tried poking under a lot didn't help And where the heck does that mass come from I spent a lot of while Working on that trying to figure out its source couldn't figure that out Um And there's got to be an easy way to stream or send longer packets That would be fun to play with if I could figure that out or someone else could And what is up with that convolution? Anyway, that's all thank you very much for watching my presentation