Hey, welcome to my talk Hacking the Apple AirTags. My name is Thomas Roth. I'm a security researcher from Germany. And I also run a YouTube channel called Stack Smashing, where I talk about reverse engineering, hardware hacking, and all that kind of stuff. If you wanna contact me, you can find me on Twitter at GhidraNinja and hope you enjoy this presentation. Now, before we start, let's quickly talk about what I will talk about in the next few minutes. So first off, all the tags that you will see are local tags and they all require hardware access. And so I will not show any drive by exploits or anything that can be exploited over Bluetooth or so. Second of all, a lot of the info in this talk is based on reverse engineering. And so there might be minor mistakes. I might maybe get something wrong or so. And so the devil is always in the details. And as I don't have access to the source, everything is really based on reverse engineering. And so on. And my real goal with this is to just have some fun with hardware hacking and explore a device in a fun way. Now, as always, this kind of work is not possible without a lot of other people. And so there are a couple of people that I wanna thank. First off, Colin Oflin, who is one of the persons that not sniped me with the air tags in the first place. Second of all, Leonard Vauters and Plunk, who I did a lot of reverse engineering with and who I did a lot of experiments with and so on. Jeska Klassen, who gave me a lot of information on the Apple U1 chip and helped me a bit with some artiquette details. David Halton, who provided very in-depth images of chips and provided the layering of the PCB and so on. And also limited results without whom a lot of the work you're about to see would not be possible because he found the actual vulnerability in the NRI-52 last year. Now, before we jump in, let's talk about the air tags itself. Now, the air tag is a Bluetooth key finder. So really nothing too special, at least I thought, so when I first saw it. But what's unique about the air tag is that it contains ultra white band via the so-called U1 chip. Ultra white band is a technology that can allow, for example, iPhones that have ultra white band to very precisely locate the air tag. And we're talking like centimeter precise, including direction finding and so on here. So this is something really neat. And ultra white band works in, like I think the five to six gigahertz range. And so it's really high frequency and very difficult to analyze using cheap equipment. And so you really need very high-end SDRs and so on to analyze it. But now we have a very cheap device that contains this U1 chip that we can potentially use for research on ultra white band. The second cool feature is the find my network. And so basically when you use the Apple air tag, any iPhone that carries into the Bluetooth range of it will report the location of your air tag to Apple servers. And this is all done with privacy in mind. I don't really know too much about it, but it's a really cool feature because if you, let's say, lose your air tag in France, you'll be able to locate it from Germany as long as any iPhone walks past. I also think it's funny because Wikipedia says that it's a key finder, but it doesn't actually attach to a key without separate accessories. Now, given all this, I was pretty uninterested in the air tags and I didn't buy any and so on and I really had zero interest in them. That is until one morning I wake up and I get a message, hey, here are the flash contents of the air tags and attached to that message was a dump of the spy flash of the air tags.  And so I ran hex dump on it and I immediately saw this and so you might see those strings on the right side here. And if you read them backwards, you might see that they basically spell out things such as firm root or NV RAM root, CRLG root and so on and so forth. And if you've worked with Apple embedded devices, you might immediately recognize this as being the F tab of an RTKit firmware. RTKit is the embedded operating system that Apple uses in a lot of very small devices such as the AirPods. And if you ever see such a firmware and you wanna extract it, you can use a tool called F tab dump which makes it really, really easy. Now, knowing that this runs RTKit already made it slightly more interesting to me, but after digging into this for a bit, it turns out that this firmware is actually the E1 firmware and so that's really interesting. Then scrolling further through the hex dump, I also discovered a couple of function names such as nif underscore f-storage in it, nif f-storage write, nif f-storage erase and so on and so forth. And that is nif 52 code. Now nif 52 is a very common microcontroller family that you can basically find in almost any keyfinder device. And so I'm very familiar with this chip and so I thought that was kind of interesting. And so after realizing that maybe the RTX are a good platform to analyze the E1, play with E1 firmware, I have a look at the nif firmware and so on, I was nerd sniped and I knew that I need to buy an AirTag. So I went to the Apple store and I grabbed a couple of AirTags and I tried to open one up by prying open the backside and I immediately broke it. I somehow ripped off this inductor because the AirTags are really, really sensitive when you try to open them. They have a very thin PCB and if you nudge on the wrong side of it, you will destroy it. So if you try to open up an AirTag at home, always try to use these three points. It's basically where the battery compartments screws into the backside of the device and there it's relatively safe to open up the AirTags. And so after destroying my first AirTag in literally the first minute that I unpacked it, I managed to open a second one and this is basically what you see. You have a device with a ton of test points and so on, a couple of passives such as capacitors, the battery contacts and the big coil in the middle which is actually the speaker of the AirTag. And nothing really interesting except this small chip on the bottom right here. This is the accelerometer and we will have some fun with that one later on. If you remove the PCB, which is really annoying because you basically have to pry it out because it's all glued very tightly into the AirTags, you will get to see this. And this is the interesting side because this is where all the integrated circuits, controllers and so on are. Let's start with the biggest one. This big silver chip here is the Apple U1 chip, the ultra white band chip. And if you look next to it, we have the nice antenna connector. Now what's interesting about the U1 chip is that so far it was only available in very expensive devices such as the iPhone or the Apple Watch or so, not really in a price range where, you know, you can buy 10, solder out the U1 and then experiment with it. But now with the AirTags, we have an U1 available for like 30 or 40 bucks. And so this is, I think, really going to be interesting and I think we will see a lot of research with the U1 chip from the Apple AirTags. To the left of the U1 chip, we have the spy flash. And this is the spy flash that I got the dump to that nerd snipe me towards the AirTags in the first place. To the left of the spy flash, we have the NI-52, the Quartex M microcontroller. Now, this microcontroller is super common in any IoT device nowadays. And so it was clear that this chip would handle Bluetooth, most probably the iPhone communication, NFC, and it's also known to be vulnerable to a fault injection attack. And so basically this chip can be locked down so you can prevent people from debugging it. But there's a known vulnerability found by limited results that allows us to resurrect the debug interface using fault injection, as you will see in a bit. And so at this point in time, having the AirTag open and seeing the NI-52, the plan for me at least was clear. Find the test pads and pins to connect an SWD programmer to the device, unlock the chip using fault injection, and then hopefully gain access to the firmware to be able to analyze it and see how does the AirTag work. Is all the logic in the NI-52, is all the logic may be done in the U1 and the NRF just acts as kind of a modem or so. And so I was really curious at this point in time to see what is actually running on the NI-52. Now normally when you open a new device, now normally when you open a new device, you have to probe all those pins and so on and figure out which one is actually the SWD interface and you have to solder off components because the NI-F, for example, doesn't really have any contacts you can probe and so on. But luckily for me, Colin O'Flynn already did all that work. And so on his Twitter, you can see that he created this nicely annotated version of the AirTag and he also found out which test pads on the backside of the AirTag are the pads that we need to connect our debugger to. And he also already tried to program the debugger and he also already tried to program the, and he also already tried to program the NI-52 and found out that indeed Apple had locked down the debugging interface. Now, this numbering scheme that Colin created kind of became standard in the AirTag hacking scene. And so if you are looking for some info on the AirTags and you see like some pin numbers also somewhere, this is probably the numbering scheme that everyone is referencing to. And thanks to Colin, we know that pin 35 and 36 are the pins to which we can connect an SWD programmer such as a J-Link or a cheap ST-Link or so. And via those pins, we will be able to reprogram the AirTag. Now, as mentioned, the debugging interface on the AirTag is unfortunately locked down using a feature called AP Protect. And this one will basically lock down the control access point for debugging and you can still erase the chip which will re-enable debugging and you can program it but then you lose the firmware. And so while we could put our own firmware on it, at this point in time, it was much more interesting to dump the firmware than to put our own on it. And luckily, thanks to limited results, great work, we can just use fault injection to re-enable it. Now, what is fault injection? Basically, when you take the power supply to a chip and you drop the power for a very, very short amount of time, you can cause a kind of memory corruption in the chip. And sometimes this will allow you to skip over instructions. Sometimes it will allow you to corrupt memory reads and so on. And so it's kind of difficult to understand really what it does in the chip because you can't really look into it while you drop the power for a couple of nanoseconds but you can get a relatively stable attack using this kind of approach. And so the basic idea would be that during the start of the processor, at some point in time, the processor will check whether the debugging is disabled. And if so, it will skip the step of enabling the debug hardware. Now, if we manage to perform a fault injection attack at just this moment in time, we might be able to trick the chip so that the chip will enable the debug hardware because we skip, for example, with the check instruction. Now, how do we do this on the NIF-52? In general, most microcontrollers have an external power supply and then an internal power supply that is derived from that external supply. And so, for example, in the case of the NIF-52, the chip normally runs at 1.8 volts but then on the inside of the chip, those 1.8 volts are converted to different voltages for different peripherals. And so, for example, the CPU core might run at 0.9 volts or Bluetooth might run at 1.2 volts. And the problem is, we only really wanna attack the CPU core. We only wanna attack the actual instruction. We don't really care about Bluetooth and so on. And we wanna be careful to not disrupt other parts of the chip too much because then it might happen that something else fails and resets the chip and so on. And so, we wanna target only the CPU core, if possible. Now, these regulators tend to be quite noisy and so, to reduce noise, often the chip has an external connection for what's called a bypass capacitor. A bypass capacitor is a small capacitor that is directly connected to this internal voltage rail to stabilize the voltage towards the CPU core. And you might already notice but one side of the capacitor gives us direct access to the voltage supply of the CPU core. Now, if we attach, for example, a switch towards ground to it and we press that switch, we will create a short circuit that will disable the regulator.  Then, if we open the switch again, we re-enable power. Now, obviously with a manual switch, we can't get the precision and the timing that we require to hit just the right instruction. If we, however, connect a MOSFET to it, which is just an electronic switch, basically, we can digitally control the CPU core power supply. And now, we can use something like an FPGA to control the power supply and time it very precisely. Now, I like to go cheap on these kinds of attacks and always show just how easy, for example, fault injection is. So, I decided to use a Raspberry Pi Pico to perform this glitching attack. And so, basically, I connected the MOSFET to a Raspberry Pi Pico and now, if the Raspberry Pi Pico enables one of its IOs, it will interrupt the power supply to the CPU core. And then, if you turn it off again, the CPU core will start again. And so, if we hook this up to the attack, we basically first need to find that bypass capacitor. Now, Apple was nice enough to put that capacitor on the backside. And so, the easily accessible side of the attack. And even better, they even put a test pad right on that core power supply pin. And so, we can just solder on a cable there, connect our MOSFET to it, and we are almost ready to go. Now, fault injection, in most cases, is not something that you just try once and are successful, but in most cases, you wanna try a ton of times and eventually, you are successful. And because each attempt is really short, like, let's say, 100 milliseconds, we can try 10 times per second. And so, even though we try 100 times or 1,000 times, we still get our desired results pretty quickly. Now, to be able to restart the attack and to also get a signal when the attack is actually booted, we also wanna connect the NI-52 power supply towards the Pico. Because basically, the attack runs at three volts from a battery and it takes a couple of milliseconds for the power supply to reach the NI-52. And so, we wanna make sure that we get a signal on our Raspberry Pi Pico once the chip starts booting so that we can time our fault injection attack just right. To do this, we basically use a level shifter to convert the 1.8 volts from the NI-52 to the 3.3 volts that the Raspberry Pi Pico expects on input. And then all we have to do now is power up the attack. And you can do that by just connecting an IO directly to the battery contacts of the attack. And so, what we can do now is we can turn on the attack from the Raspberry Pi Pico. Then we wait until the power supply to the NI-52 is enabled, which is basically the point in time at which the NI-52 boots. And then we can perform our fault injection attack using the MOSFET connected to an IO. Now, all we need to do is also connect an SWD programmer that we will then use to check if our attack was successful. And so, basically, we start by just turning everything off. Then we turn on the power supply towards the NI-52. We wait for the signal from the NI-52 power supply and then we wait a short amount of time and then we enable the MOSFET, which will drop the CPU core power for a very short amount of time. And then we re-enable it. And then we use our SWD programmer to check whether we are successful. Now, this sounds like a lot of complexity and a lot of work, but it's really, really easy. And so, for example, the code on the Raspberry Pi Pico is just these couple of lines. Basically, we power cycle the target and we wait for the NIF power to boot up. Then we wait for a configurable amount of time and then we glitch for a configurable amount of time. And if you set this up on a real attack, it will look something like this. And so, we have our attack, in this case, in kind of a breakout state to make life a bit easier. Then we have a debugger, which is basically the programmer that we used to check whether our glitch was successful. And then we have this breakout board that I designed, which is really just a Raspberry Pi Pico with a couple of level shifters and so on to make life easier and also with the glitcher on board. Now, as you can imagine, the boot of the NIF-32 takes quite a long time. And so, finding just the right spot and time where we drop the power to attack it is pretty difficult. Luckily for us, limited results documented pretty well with a power trace at which point in time of the boot of the chip, we need to glitch. And so, in his blog post that you should check out on limitedresults.com, he precisely describes at which point in time we need to drop the power for a very short amount of time to re-enable the debugging interface. And after setting this all up and using a glitch width that I knew is successful from the past, we are ready to go. Now, if we look at this on our oscilloscope, you can see that our glitch is not really precise. This is because the code that I'm using to glitch it is very unprecise. But as it turns out, this is enough. You will get lucky eventually, just because the likelihood is that if you try often enough you will hit the right point in time. To control the glitcher, I wrote a simple Jupyter script that basically just sends the delay and tries a range of delays, tries a range of pulls width basically for the glitch and then just checks where the JTAG is enabled. And so I let this run for a bit. And after like a couple of minutes, I got lucky and I got this success. And success means that basically JTAG was re-enabled. The test JTAG functions and the test JTAG function in the Jupyter Notebook tests whether it can connect via SWD to the chip and in this case, that was successful. And suddenly on my hard drive, I found this, my script automatically dumped all the interesting areas of the chip. And so we have the flash dump, the BP, ROT ranges, FICR, UICR and so on, all the interesting ranges that are in a chip. And so I started analyzing the LTCH firmware. I started by just running strings on the firmware and I immediately recognized these strings here. This is an indication that they actually run core crypto, which is Apple's crypto library on the LTCHs. And the next thing that jumped to my eye was this URL, found.apple.com slash LTCH. This is the URL that you get when you NFC scan an LTCH. It will lead you to a URL with like the PID and SWAN encoded in the URL. Now, I was really curious to see whether the firmware had any additional validations that I didn't know about. And so I tried to modify the URL in a hex editor and reflash the firmware to the LTCH. And then I got this. And so what do you do when you, you know, can change the URL of something to whatever you like? Obviously you try to rig role people with an LTCH. Now you might wonder, well, why would you go through all of that effort to rig role people? And I had a ton of YouTube comments ask exactly that question. Hey, why aren't you just using an NFC sticker and so on? But the goal with this was really just to see whether the firmware has any additional verification methods. And this was the easiest way to check whether we can just modify something. Cause it's very visual.  But continuing analysis of the strings output, I found this line here and I recognize these letters because in the iPhone, this is exactly the serial number that I saw in the find my application for this LTCH. And so it turns out that we can also freely edit the serial number of the LTCH. And so for example, minus now stacks machine. And this is pretty interesting because I personally expected the configuration to be in the U1 or on the spy flash or so. But apparently all the configuration details of the LTCH are stored in the NIF 52 internal flash. And that brought up a pretty interesting question because after pairing, for example, you can also see a sensor email address and so on all in the LTCH firmware basically. And this brought up the question to Leonard and me whether we can actually clone an LTCH. And so our idea was that I would dump a configured LTCH send the flash dump over to Leonard. He would flash his LTCH and we would check whether, you know, my LTCH would be discovered in Belgium where Leonard lives. And so we set this all up. I had my LTCH nicely set up at my home place. I dumped the LTCH, I removed the battery, I sent the firmware over to Leonard and what do you know, a couple of minutes later my LTCH was suddenly in Belgium. And so it's somehow in a couple of minutes traveled a couple of hundred kilometers. And so it works, we can clone an LTCH. All data that is required for cloning an LTCH is in the NIF 52 flash. And this is pretty interesting because this also means that if you, for example, find an LTCH or steal an LTCH you can actually reset it and create and set it up with a new serial number bypassing the lost function and so on and so forth. And neither the spy flash nor the U1 seem to be really involved in the pairing of the LTCH. And so that was pretty interesting because we all were pretty sure that Apple would do some crazy stuff with the U1 or so to make life of cloning and stealing and so on a bit harder. And I'm curious what this will mean for, for example, bikes that have the find my technology integrated. Now, with this information we also started comparing our two dumps. And so we basically started comparing what is different between different LTCHs and what changes with the pairing. And for example, here in the HEX dump you can see my email address, the sensor version that is shown when you find the tag and so on. And overall, the information that is part of the pairing is relatively low. And you still have a bit of room in the firmware to, for example, integrate your own custom payload into the LTCH. And one thing that got a lot of buzz surrounding the LTCHs was its privacy protections. A lot of people were very afraid about getting tracked by an LTCH. Now, while I get the idea of being tracked I personally think that the LTCH is a terrible tracking device. It doesn't have a microphone, well, a real microphone. It doesn't have GPS, it doesn't have a GSM. The only thing that you have is Bluetooth and the location of an iPhone that walks by. And even there are some limitations. And I mean, if you go on to Alibaba or so you can get a decent tracker with all of these features like GPS, GSM, microphone and so on for $20. So it's even cheaper than an LTCH. And it's not like an LTCH is particularly small or particularly well to hide. And so what I'm about to show is I don't think it's really an issue because I don't think the LTCHs are a great tracking device. But basically the LTCH has a couple of privacy protections to prevent people from just putting an LTCH in your backpack and being able to track you. If you have an iPhone and an LTCH moves with you for an extended period of time your iPhone will give you an alert. And so you will get a pop-up saying, hey an LTCH has been following you and then you can get that LTCH to play a sound. And from my research this seems to be based on the ID that is broadcasted by the LTCH that changes regularly. Now knowing that this ID is generated in the NI-52 code and knowing that I can modify the original firmware I wondered what if we make our LTCH have multiple identities. And so basically instead of having one identity on my LTCH that would change its ID every 24 hours, what if I have a lot of identities and I would basically cycle through them relatively often and the iPhone would think every time that this is a different LTCH and it wouldn't detect that the LTCH is following me basically. And so to implement this I needed to do some further firmware modifications. But for that we first had to actually analyze the firmware. And so I started loading the firmware into Ghidra and found that it's really standard NI-52 code. It uses the normal NI-52 SDK functions and so that is pretty cool because it allows you to create signatures from the original NI-52 SDK and then apply them to the LTCH firmware making your life much easier and you don't have to reverse engineer everything. Also what was interesting was that no runtime mitigations or hardening was found. And so for example, there are no stack canneries and so on and so if you find something like a buffer overflow it's most probably relatively easy to exploit. But overall the firmware was relatively straightforward to reverse engineer and so on. And so the idea of building these privacy protection bypasses was relatively easy. And unfortunately, and so after a couple of experiments I had my custom firmware ready. It did not trigger any privacy warnings in our testing on iOS 14.5. Tested this with a couple of iPhones, with a couple of people walking around. But it also has very limited usability because to manage those identities is kind of difficult because you know the Find My App only supports 16 attacks at once and so on and so forth. And I also decided to not publish the details on this firmware yet until this is fixed one way or the other. And the reason for that is that after publishing my first YouTube video about the attacks on the attack I got a lot of emails like this asking me whether it's possible to bypass the warnings and a lot of people actually offered me money to bypass those protections. And so given that there seems to, even though I think the attack is not a great tracker I don't want to be the person that enables people to track others using the attack. But another thing that a lot of people wanted was changing the sound of the attack that the attack makes when you search for it. Now sound reverse engineering is kind of fun because normally when you reverse engineer something in a firmware you need to use either Pro, Gidra, Binary Ninja or Radar or so. But for audio it's really nice to just load it into Audacity because in most cases the firmware will have raw sound samples contained in it. And if you look into the Audacity menu you can find that it has this point called import raw data and there you can just experiment with different encodings, byte orders, channels, sample rates and so on. And eventually you might see something like this and if you look at the center here that looks a lot like valid audio and indeed if we play it back just this part in the middle you can see that this sounds a lot like the noises that the attack makes just a bit shuffled around and so on. And it turns out that the audio player is kind of the small sample player where you have multiple samples that create one sound and so on. It was kind of a surprising amount of work to reverse engineer it and get it working nicely but after a while I had this weed set up ready. And by the way at this point again thank you to Colin Oflin and Leonard who did a ton of reverse engineering on this and again without whom this would not have been possible. And so this is the regular sound that the attack makes. And here's my attack. Now you might be surprised by the sudden stop of the sound here. This is not just because I clicked stop but also because the attack just crashes at this point in time. I'm not entirely sure why but probably the reverse engineering of the sampler was not yet good enough. But hey we now have an Apple branded rig rolling device that you can put in somebody's pocket and rig roll them. And so I hope to release some tools for modifying the firmware to do that soonish. Now another question that a lot of people had towards me is can we use the attack as a bug? And the main idea of a lot of people was that hey it has a speaker right? And a speaker is always also a microphone. Well on the attack unfortunately the or well not unfortunately but luckily basically between the microcontroller and the actual speaker there's an amplifier. And that amplifier has no way to provide feedback to the CPU and so we can't really measure anything that goes on in the speaker. However what we do have is another tiny device over here which seems to be a Bosch accelerometer. And an accelerometer can measure vibrations. And I mean what is sound if not just vibrations. And this is something that is very well known to be possible with accelerometers but I had never done it. And so I thought this would be a fun experiment to try to use the accelerometer as a microphone on the attacks. Now unfortunately I could not really get a high speed signal like not I don't know 12 kilohertz accelerometer signal from the accelerometer and it's also a custom part. Like a lot of websites claim that it's a BMA 280 but I don't think it's a 100% match. So for example the footprint is different and so on it seems to be a different, it seems to be a custom chip which wouldn't be the first time that Bosch has created a custom accelerometer for Apple. Now the problem is the accelerometer is not really sensitive to sound. And so even if you yell against it you will only get very slight signals. And so I built a very specialized audio chamber for audio testing the attack. And so this device which is totally not a regular Pringles can is my very sophisticated audio chamber for testing the attack and using it as a microphone. And so you basically put the attack on the bottom of the chamber because that's where especially the deep vibrations will be very significant. And that's needed because we have such a low sample rate that we only can get the low end of the spectrum basically. And after a couple of tries, a ton of post-processing of the signal this is the sound that I got out of the R-Tex. I don't know if you wanna call that a success. So I personally think that the Apple R-Tex are not really a great microphone but I can tell you that I had a ton of fun trying to get this working and trying to use the R-Tex. And it's accelerometer as a mic. Now, last but not least, let's talk about the U1. Now, as mentioned, the U1 so far was only available on higher end devices such as the Apple Watch and the iPhone. But now it's available for a really cheap price or well, cheap Pish price. And it seems that during pairing the firmware is transferred from the iPhone towards the spy flash of the attack. And then the U1 firmware is loaded on demand towards it. And what's really cool on the R-Tex is that you can downgrade it. We have full code execution on the R-Tex. You don't need a jailbreak. You don't need to have an up-to-date iPhone exploit no matter what updates are coming to the R-Tex because the fault injection attack is unfixable. We will always be able to inspect what's going on with the U1 on the R-Tex. And we can create breakup boards for it and so on. And I'm really excited to finally have cheap U1 and ultra-wideband research for the Apple ultra-wideband ecosystem. And if you wanna learn more about the U1, check out Yiskas and Alexander Heinrich's DEF CON talk this year who are talking about the U1. Now, we also were able to create a full diagram of the Apple R-Tex. David Halton polished each layer of the R-Tex PCBs and then we reassembled it in an image processing software. And now we have each layer of the PCB. And so this makes it really easy to trace, for example, the connections towards the U1 and so on. It makes life much easier when you just wanna, you know, sniff a certain line and so on and so forth. If you wanna learn more about all of these things, the Glitcher is open source on my GitHub. The reverse engineering details from Colin are published on his GitHub. And I also have a repository with all the hardware pictures and the high resolution PCB pictures that allow you to very easily, you know, see what communicates with what and how does everything work. I hope you enjoyed this presentation. And if you have any questions or comments, please don't hesitate to contact me on Twitter or via email or whatever. And I hope you enjoyed DEF CON. Thank you.


Your radiologist might find something on your mammogram that appears suspicious. If so, a biopsy is recommended to find out more information. This means taking a sample of tissue that can be evaluated in the pathology lab. Today we can perform minimally invasive procedures, using imaging guidance to take a small sample through the skin with a needle. It's faster, more comfortable, and has a quicker recovery than a surgical biopsy. Because 80% of these will be benign or non-cancerous, in most cases surgery can be avoided. The 3D-affirmed biopsy system is an advanced approach offering maximum precision, a shorter procedure time, and lower total x-ray exposure. It also allows us to quickly reach challenging lesions, so for instance those that are located far back and those which are difficult to see. It's not as scary as it sounds and it helps to know ahead of time what is going to happen. A patient undergoing this type of biopsy can expect a 45 minute outpatient procedure, although the actual biopsy usually takes less than a minute. First the technologist will position you and then take a few pictures. The computer is used to mark the target area and precisely guide the biopsy device. Once the area of interest is in view, the radiologist will perform the procedure. Immediately before the biopsy, the radiologist will clean and numb the breast. You can expect a little pinch and maybe some burning with a local anesthesia. A skin nick is made, which allows entry of the needle and does not require stitches. The needle will be advanced and when in good position, the instrument is triggered. You will hear a noise and you might feel some pressure. Deeper anesthesia is then given and samples are obtained. Our experience is that most patients do not have pain. When the procedure is complete, a biopsy clip is inserted to mark the biopsy site. You cannot feel this clip. The clip is made of titanium and about the size of a pinhead. It is MRI compatible and does not set off metal detectors. Placing this is critical in case surgical excision is necessary based on the results. When the procedure is finished, pressure is applied to minimize bruising. Then you will have a post biopsy mammogram, which is typically less pressure than diagnostic quality mammograms. Most women will get back to their daily activity the next day. Your doctor will contact you with the results when they are available. This new system allows us to perform minimally invasive procedures with more accuracy and speed than older, stereotypic biopsy devices. Ultimately, this leads to fewer surgical procedures and greater patient satisfaction.


All right, welcome back. So now we have Stephen with us. And Stephen's going to be talking about Streamlit. It is one of the fastest way to build data applications and has been doing rounds about in both the machine learning as well as the software engineering world. And I'm particularly really, really psyched about this session and about Stephen too. A little bit about Stephen, he is a CS finalist and he kind of does work between software engineering and data science, so majorly around machine learning engineering stuff. And he's mostly focused around machine learning research and around product development around it. So Stephen, great to have you over here. And yeah, looking forward to your talk. Yeah, and everyone, I'm so excited to be here. It's an AGO Python 2021. This is my first work at AGO Python. It's just so warm to be in here. So I'll be speaking about Streamlit, the fastest way to build data apps. And of course, my name is Stephen Kolaoli. In this talk, we'll go through the problem statement, why we need Streamlit in the first place. Secondly, we're talking about Streamlit.  The next talk we'll be talking about will be installing Streamlit. We'll get to play around with some demo. After hours, we'll move on to building a simple data app with Streamlit. And I'll show you all the building blocks of a simple Streamlit app. And then we'll be having a sneak peek at the different use cases. What people have been using Streamlit for. Finally, I would go to the console, Streamlit. Just reconstruct everything that doesn't make a Streamlit the perfect solution to everywhere that program right now. So once again, this is my profile. I'm Stephen Kolaoli at Houndo by now. I'm a machine learning engineer. I do most different things these days. I'm also a computer scientist, undergrad, going through my final year. And also, my skill set is somewhere in the intersection between software engineering and machine learning. Other four parts, I've been a live-up with the fans. I was a kid. I used to make up almost everything. I used it for web development for machine learning, for data science, analytics, and all. I'll just kind of talk about that last part. So moving on, what's the problem statement? Oh, I'm not floating. OK, so if you're familiar with the normal process of building data apps, this is the usual process. There's the data processing step. Of course, you carry a lot of analysis out in the notebook. The thing is, notebooks are built for experimentation, for analysis. Most times, they are not codes that you can share easily with people. And let's say you want to communicate your findings to all that people, or maybe to your colleagues in your organization. So that means you copy the relevant work. You could always claim the notebooks and send it to them. And you could also copy the relevant functions in the five scripts. And let's say you want to share it to a large number of people, or maybe you want to put a demo. Then that means you need to create an app using Flux. And if you're creating an app using Flux, Flux is just for the back end. You also need to worry about HTML, CSS, JavaScript, at the very least for the front end functionality of the web app. So let's say you're in this sort of a large organization and you have a dedicated software engineering thing. And let's say you're pushing your code into production. So you could outline all the requirements on the UI-UX design, right? And you hand it over to the engineering thing. And of course, they could create a performance app based on your requirements. And then the need will probably tell you, hey, man, we have lots of projects we're monitoring. So we'll only be able to carry out topics on your app, let's say once in a few months or so. Now that's the share process. Now that leads us to our pain points. The pain points are number one, the software engineering thing. When you depend on them, because they are handling lots of projects, that means that it takes up a bunch of your time. I mean, the communication on-screen flow is always difficult and messy to maintain. And of course, you can't just create new features and updates on the web, because the software development team have lots of projects they're monitoring, right? And most times, we could create this app ourselves, right? But the number one issue is some of us, if you're like me, I can't recognize the purple color from the blue color. So lots of us saw how to design and we rather write codes. I mean, we rather write codes for analysis or for straight engineering, write code for aesthetics. Yeah. And also, creating web apps is surely consuming a huge amount of our time. And you also need to consider the learning code. I mean, you need to know how to create applications with class. And then you need to bother with the front-end frameworks. And also, I mentioned this earlier, some of us would prefer to use our code to generate insights and build models, rather than use this code to provide users with aesthetic experience. So that is also this million-dollar question. What if it could build apps as easily as writing Python script, right? Yeah. And that is us to stream it. What's streamlit? Streamlit is all about building apps as easily as writing Python script. Let's say you have a Python script for a year, and then you split code in a few API calls into your functions. And you move over a year, and you can show off your beautiful performance or web app. It's that easy. Yeah. And we'll go through demo very soon. And one other advantage of Streamlit is that it covers most of you guys using data app. If you build visualizations in data app, if you've been building web apps before, then you're familiar that you need to consider the layout, right? You need to decide maybe you want to play the particular chat by the side, or you want to place it. You want it to take off a rich space on your web app. You might want slide ads. You might want check boxes. You might want markdowns, right? And all these things, they usually take up a huge amount of lines of code, right? But in Streamlit, if you just implement all these with a single line of code, if you do something like import Streamlit as ST, then you could have ST.hidebar, ST.selectbox, ST.radio, and so on and so forth. And I think that's very cool. One other story is, Streamlit supports multiple interactive or visualization libraries. If they're used to creating libraries, right, then if they're used to creating visualizations, then them is, you know, Kotli, you know, author, you know, bookcase, you know, must Kotli, must Siebel. And Streamlit provides support for all these libraries. I mean, there's a project I'm working on currently using Streamlit as for the dashboard pattern. I think I'm using Kotli for the visualizations. And it supports lots of visualization libraries out of the course. And you don't use to get this, you know, that often. Yeah, so let's move on to installing Streamlit complete. To install Streamlit, all you need to do is to keep install Streamlit. And then you try out Streamlit alone, yeah? So I'm going to try that out in my command prompt. So I'm going to do this because I've already installed Streamlit, OK, let's take the version. Oh, yeah, so 0.84. That's the version of Streamlit. If you don't have Streamlit installed already, you won't be able to do that, right? So I'm going to try out Streamlit now. Oh, so Streamlit, hello, sorry about that. All right, so you can see the localhost 85.01 on the Streamlit store. Oh, yeah, so you can see the web app over here. And you can select, you know, different kind of demo. I'm going to select this. And what do we have here? You can see a bit of animation, you know. I think this is quite cool. I think this is quite cool. There is a place where we could check for the code. I guess it's still on, so you can see that's it. You can check out the plotting demo for sure. And then you can see the animation. There's a little animation combined with the closing. All right, so look at the code over here. And I think we did that in less than 20 lines of code. And I think that's quite cool. Yeah, so moving on, now that we've installed Streamlit, then we could, you know, clear out with the demo. Now, this is a single L over the script. All you have to do is import Streamlit as SD. And then do something like this, SD.ly L over. And you could go over to your command forms and do the Streamlit on L over the script, right? That's quite simple. I could do that over here. I think I hope I'm going to fire over here. All right, so, but I'm not going to run this. Let's play with a proper, you know, a proper demo. And look at this. A sister of mine was learning statistics, actually, of the different distributions and everything. And, you know, it would seem a bit abstract if you're not from a math background here. And so I feel that, you know, it would be more fun if she could get to play around with what she's learning, right? That was the inspiration behind this little demo app, right? So you can see, I imported Streamlit as SD and, of course, NumPy as empty. NumPy is the maker from put in library in Python. Oh, OK, yeah. So we could have a SD.title, right? And you could see distribution tester. So we're going to have a big title called Distribution Tester. You could see SD.write, right? We have the keys, which is, you know, a list containing normal and uniform. And of course, you could, there's this select box. SD, the select box means we're going to have a select box. And the select box is going to contain normal and uniform. So if the user selects normal, you're going to have a randomly generated number between the range of 0 to 1,000. But if the user selects uniform, then you're going to have at least an array of numbers of 1,000 numbers generated between the range of 0 to 100, right? And you're going to have a line chart plotting the norms, which is the result of whatever the user selects. So I'm going to go over to my browser. I'm going to try Streamlit on this folder. OK, so I'm going to try. So it's going to go from 0 to 1,000. All right, so you can see that. You can see the type too. You can see the SD.write. You can see the select box, right? And normal was selected as the default. So if I change this to uniform, you can see that the chart is different. And I think we did this in less than, there are 16 lines of code in spaces and everything, more like 12 lines of code. And I think that's amazing. Who would have thought that this in class, in that amount of time? All right, so moving forward. OK, yes, so moving forward. So would that be the user some use cases of Streamlit, right? And then, yeah, so the first one I'll show is this. Udacity self-driving car for 2D cassette. This was created by the Streamlit team. You can go on a complete neural net, right? In real time, from within that app. I'll show you the link to this link down. Yeah, so let me show you some couple of orders. OK, yeah, so this was, this is the demo I was talking about, you can check it out. Yes, another link. This was created by a friend of mine, Muya Sola. And yes, another link. This is a link to the gallery, to Streamlit Gallery. The Streamlit Gallery contains apps that have been built by other Streamlit developers across the globe. And you can see lots of interesting use cases over here. There's this New York City Uber ride sharing data. And you can see lots of stuff, lots of stuff. Yeah, so and of course, it cost, of course, many fields.  You can see the New York City transfer and lots of other use cases of Streamlit, right? So you can check, yes, the demo of the self-driving car. So yes, the link to the GitHub where you see it. So you could check this out. You could check this out later, right? Yeah. So finally, this was the app that was built by this friend of mine. Of course, you can see lots of, you can see it's live AI. You can see, you can see, you can select the kind of house, the kind of location you want. This was built for major cities in Lagos State. Lagos is in Nigeria, right? So pick any city. Let's say you pick Lecky, for example. You could choose the number of bathroom, the number of bedrooms, the number of toilets. You could choose all these options and you could question evaluate from stone. And you're going to have an estimation of the price of that house. Over here, I think we have 2.3 million Naira as the house will be selected, preferences. All right. So moving on. Moving on. So let's go to the reasons why Streamlit might not be that awesome. And I think the number one is the convenience specific tradeoff. The further, Streamlit abstract out most of these UI decision-making for you. Even though it's a point of strength. I mean, the source of strength is also a weakness point, right? Because Streamlit has abstracted out all these, all these UI decision-making for you. So that means that you don't get to have much take in the kind of UI design style you want. I mean, you can just wake up and want to have a chart embedded in another chart. You might not be able to do something like that with Streamlit. And actually, I feel this has been greatly improved on because I remember the last, the first time I gave it for Streamlit, which was about a year ago. You can't place a, you couldn't place a chart side by side, two charts or three charts side by side. But right now you could do that to play up to five, six charts as much as you want, you know, side by side. Yeah, so another is the size of data input. And I remember the first time I spoke about this, it was 50 MB. You can't upload files back and down of 15 megabytes. But right now you can, you can upload files up to 200 megabytes and Streamlit is very flexible with all the kind of files that you can upload and the kind of checks that you can put in place. Also, limited support for videos and animations and as I was saying, all these calls have been greatly improved on. Yeah, even though the support is still limited but it wasn't as limited as before. You can't build apps with, you know, functionalities, with complex functionalities. For example, you know, you are having a newsletter subscription, you are having a user to user interaction, right? And let's say user authentication, but right now you could actually have a Streamlit app with user authentication. I think lots of work are going on on Streamlit and I think the future is quite, you know, right for Streamlit. Yeah, and I was also saying even still, Streamlit is still simply not used for every Python programmer out there. And it's superb if you want an iterative data app very quickly. But let's say what you want is an app with, you know, with a chatbot, with a, you know, Streamlit supports pagination, but if you want an app with lots of complex functions, then you might better off with Flux or Django. Yeah, so finally, you know, these are the two kits that you're going to need, you know, as a Streamlit developer compared to a Flux developer. If a Flux developer, you need to know Flux and you need to know other JavaScript frameworks, other front-end libraries, for example, you need to know HTML, CSS, JSON and the very least.  And let's say if you want to containerize your web applications, then you can use stuff for that. All right, I've just said that, thank you very much for listening to this stuff. And I hope you're able to gain a team or two. And if you're free to say hi to me on LinkedIn, and of course you can connect with me on Twitter also. So thank you.  Yeah, bad time to miss the notification of low battery though. So we can probably take one question and people who have questions later on can probably reach out to you in the breakout session. So the question is, can one password protect access to Streamlit-generated pages? And can they collect information in a password protected area if they have more than one? Oh, yeah, definitely, definitely. I think some of the first use cases of Streamlit whereas demo apps, you know, I mean, it's not something that you could push into production. But these days people are quitting production, production scale up more and more with Streamlit. Yes, this is something, I think I still saw it on Streamlit discussion, discussion four recently. I mean, somebody was asking a question related to this. Yes, you could have a password would take assets to Streamlit-generated pages. Though you might need to be careful with the kind of assets that you give out to users. I mean, if your web app is containing sensitive information, so yes, you can collect passwords, you can provide access to password and collect password and vice versa. Perfect, yeah. Good to know that. I hope that answers the person who asked this question. With that, thank you so much again for your talk and I hope people find you in the breakout rooms for parrot for the questions. Oh, all right. Thank you very much for having me.


So I'm sitting at my office here on a Sunday afternoon, I was drinking a cup of coffee and I was looking at YouTube and I started searching through YouTube's search engine and I started typing in various search terms for topics that I may or may not be interested in and I kept seeing the same guy coming up in the search results and I've been following along with what this guy has been doing for a while and I really think this particular individual is going to be the big catalyst that eventually brings YouTube down. This man will single-handedly collapse the entire infrastructure of YouTube and you guys are wondering who I'm talking about. I'm talking about Royal Vendapar.  Tech related, Linux related, programming related, if it's the kind of question that can be asked on Stack Overflow, then you have probably seen this man's videos come up in various search results. For example, when I search for a boondoo blank screen, you know I've got a couple of search results here for Royal Vendapar and he's got a video here. The videos if I hover over it all start with the same intro. He's got almost two million videos now uploaded to YouTube. Yes, I said that right. Two million videos. They all start with him with his busted up lip. He's got a bloody lip for some reason and then after that is plain text. It's asking a question. Somebody asks a question on Stack Overflow and I guess he takes the top rated answer. He adds a little music to the video but there's no real video editing. There's no work involved. This is all automatically generated videos and he is able to upload at a rate these days of nearly one video per second. I did a search for Xmonad and when I do a search for Xmonad, most of the videos that come up in the search results on YouTube are actually my videos because Xmonad's not a popular topic right now.  But when you filter the search results for recent videos and that's what you should do because Mr. Vendapar's videos, they're never going to come up as being the most relevant search results. That's always gonna be channels with real subscribers with real views right and obviously this automated generated spam videos that he's doing. Nobody's really interested in that so you're not gonna see his videos usually come up in the relevant search results but if you filter by upload date then obviously he's uploading videos practically every second. It doesn't matter what tech related topic you search for. If you search by upload date then chances are you're gonna see some of his most recent videos appear in the search results. Here's some stuff in Xmonad. As a matter of fact I scrolled down a little bit but you see I got this block of four videos. Three of them are Mr. Vendapar's. I did a search for Emacs. Here's a video by Mr. Vendapar. I don't even know if he knows anything about Xmonad or Emacs. You know because this is all just scraped search results from Stack Overflow that he then probably has a bash script or a Python script that automatically makes a video for him you know using the same standard template. I did a search result for bash scripting right. Search for bash scripting on YouTube. There's Mr. Vendapar again. Let's take a look at his social blade numbers. Mr. Vendapar now has 1.9 million uploads. 1.9 million uploads. Now he first appeared on my radar about two years ago. I noticed this guy kept coming up in the search results all the time and you know when I looked up his numbers on social blade two years ago he had about 100,000 uploads and there is no way a human being can upload you know make and edit and all you know 100,000 videos make the thumbnails. You can't do that right. So I already knew it was all automatically generated spam. 100,000 uploads you know he's basically flooding the YouTube search algorithm right. He's guaranteed to come up when you post that many videos even if nobody's really watching them you know if you spam the search algorithm enough your videos will come up and you'll get some views and of course views translates to ads and of course that translates to some ad revenue. So he had a over 100,000 uploads you know a couple years ago and then I noticed just a few months back he passed 1 million uploads because it was kind of a big deal. People were looking at these numbers like what is going on with this guy and now he's going to pass you know two million uploads here pretty soon. If I upload this page or refresh this page will it automatically update? No. But let's go to YouTube because I've had this page loaded for a while you see software engineering tooling and support. Let's refresh this page. Let me do an F5 on the computer and that video that was software engineering and tooling.  It's all the way so it's 12 videos back here in his uploads so since I had this page loaded just a couple of minutes ago you know he's already uploaded like 12 more videos so that's crazy. The pacing that this guy is doing I mentioned his upload is just every few seconds and he's ramped it up to get this much output because whenever he was at the 1 million upload mark I noticed you know he was uploading every few minutes which is crazy right? And then a couple years ago when I noticed he was over 100,000 uploads he was uploading a new video I don't know like every 10 every 15 minutes some something ridiculous but he's ramped it up. He's probably he's probably got some servers and some vpses some cheap vpses he rants you know half a dozen servers it wouldn't take much because these videos he's making they're only like three minute videos because it's a question from Stack Overflow it's plain text not much going on it'll only take a decent computer about a minute maybe two minutes to render these automatically generated videos for him.   Nobody is going to come across his channel in a legit sort of way you know and find his channel and look at his videos and say oh wow this is good content right? This is low tier content. This is zero effort content. It's the worst kind of content you'll possibly find auto-generated spam right? Nobody's going to subscribe and nobody's going to watch any of his videos. The only way somebody's going to watch one of his videos if they get tricked into it and how do you get tricked into it? Well you upload two million videos because I don't know how many videos are on the youtube platform best guesstimate because I did a google search and people have guesstimated that there's about 800 million videos on youtube. 800 million videos two million of them or this man's mr. Vandepar. That's crazy he's guaranteed no matter what you search for on youtube he's almost guaranteed to occasionally come up in your search results and you will get tricked into clicking on his videos thinking they're legit videos when they're just this automated spam. Now the real question is is it worth it for mr. Vandepar to spam youtube? It probably is he probably makes a little money doing this probably not life changing money but he had one million views in the last 30 days what does one million views on youtube translate to well nobody can really tell you because here's the thing views and ad sense revenue on youtube it differs from channel to channel nothing is a one-to-one relationship I could guess based on what I make but it would just be a guess no one really knows and you know me and another channel could have the exact same views for that month maybe even have the exact same number of ad impressions for that month and our ad revenue can differ drastically I'm talking about thousands of dollars difference it's just the way it is different niches paid different amounts of money you know different kinds of ads paid different amounts of money a lot of it has to do with the topic being discussed on the video and just the broader topic of your channel but my guess based on one million views I would say on the low end he probably made a couple of thousand dollars in ad sense revenue on the higher end it wouldn't shock me if he made six or seven thousand dollars in ad sense revenue on those videos and that's crazy right because again zero effort no effort right this guy he's had these servers running just automatically creating these videos for him for a couple of years you know uploading two million videos and he is all he's got to do is just sit back and cash the checks now does youtube really care about these channels that are just automatically generating these spammy videos and just flooding the search results I don't think they do uh there've been a few of these kinds of channels that I guess youtube is eventually kicked I noticed that when mr vandepar passed one million uploads a few months back that was a big deal because at the time there were only two other channels that had more than a million uploads one of them was this cod black ops ps channel which is a gaming channel with more than a million uploads I'm under the impression I don't currently play call of duty any of the games but call of duty had a game mode where it recorded different points of view and things so where you could have the same gameplay from multiple points of view and things like that which gave this particular smammer you know a lot of content right because he could just re-upload the same game basically from different viewpoints and I don't think this channel exists anymore because on social blade there's no channel header being pulled down from youtube and you see his last video as an error message so I think they probably youtube finally decided that this channel was a little too spammy and they got rid of him and then I noticed a very very similar channel ps3 cod mw3 so another you know playstation 3 call of duty modern warfare 3's I'm assuming what that stands for one million uploads I guess when it got past one million uploads they deleted that channel too because no channel header if I try to play the video yes just another error so I'm assuming what happens is there's some kind of trigger when these spammy channels cross the one million upload mark right like somebody at youtube finally says hey maybe I should check that out maybe that's automatically generated spam bots creating these videos if they have more than a million uploads as if a million uploads is some crazy number 10,000 videos being uploaded by somebody is a crazy number why do you wait till a million it's crazy that google who owns youtube this trillion dollar company they're so susceptible to this automatically generated spam and they could shut it down if they wanted to they don't realize that their youtube search results now have become a joke they are completely a joke mainly because of one guy mr vandepar the fact that there's maybe 800 million videos posted on youtube and two million are from this one guy he dominates youtube's search algorithms and once people realize how easy he has gained the system obviously more and more people are going to game the system and I'm not going to search for any channels but you guys have probably seen other channels like this I know I've come across channels that have dictionary definitions of words they just automatically generate these quick little videos right they have a script that automatically goes through a dictionary and finds every word for you and that becomes a video on youtube or one of the ones is a pronunciations they go and pull down probably creative comments pronunciations from Wixionary or somewhere and then they upload that to youtube to tell you how to pronounce these words I guess you don't already know how to pronounce and I've seen other things quote bots and you know things like that facts you know channels that are designed to basically spit out quick facts no real video it's just something that they automatically pull down from some resource on the internet they create a quick one to two minute video right run that thing through a script that you know ffmpeg generates a quick video and a thumbnail automatically generated thumbnail and you just go with it and I've complained that youtube is really under attack by comment bots you know the bots that are doing like all the the sex bots that are posting on my channel right every time I upload a video you know the first hundred comments 50 of them are these sex bots these escort services just spamming the hill not just in on my channel the entire platform and I know youtube has the means to stop this they don't or the crypto bots because a lot of my videos have these crypto bots where this crypto bot message will appear with a discord room or a telegram number or whatever hey come meet me I'll tell you how to make a bajillion dollars with bitcoin and then there's replies their bot replies there'll be like 20 bots that reply to the first button they're all talking about how great this telegram group is and yeah we'll all make a bunch of money because this guy's great you know it's funny because one of my favorite movies is the terminator the original terminator from 1984 where you know they come back from the future the future where the world's been destroyed by a nuclear war that was started by machines because ai had been created and ai basically wants to destroy mankind right and many people have this innate fear of artificial intelligence right but trust me you don't have anything to fear because a trillion dollar corporation heavily invested in ai that is google they can't stop these romanian sex bots they can't stop mr vandepar you know we have nothing to worry about no way will ai ever reach the point to where it can actually take over the world now naturally people are going to wonder why i'm making today's video am i angry that my youtube search results are flooded by mr vandepar's videos well in some ways yes because i think it cheapens the youtube search results especially for people actually looking for real information but am i angry that mr vandepar is playing the game no i'm not because i think he needs to play this game he needs to keep ramping it up i want him to be uploading 10 videos per second i want him to have a billion videos uploaded to youtube at some point because once somebody exploits something to the point where the company that they're exploiting and the person they're exploiting finally has to fight back that's a good thing i think in the long run mr vandepar is probably good for youtube because eventually someone at youtube that actually has some power you know mr vandepar will finally be on their radar and maybe they'll do something about the problem that is spam on youtube now before i go i want to thank a few special people i want to thank the producers of this episode devon gave james maxim at michael michael paul scott west alan armored dragon chuck command ring read i yokai doing george lee linux ninja michael yon alexander peace arching for door politic reella teats for let's rid prophet steven willy these guys they're my has tiered patrons over on patreon without these guys this episode would not have been possible the show is also brought to you by each and every one of these ladies and gentlemen all these names you're seeing on the screen right now these are all my supporters over on patreon because you know i i have to put in work to make my videos and if you guys want to support my work subscribe to distro tube over on patreon all right guys peace i hope this guy has that bloody lip because he told somebody he wanted to spam youtube and they punched him in the mouth