 Hi, this is Into the Droid, my name is Thomas Cannon, so thanks for turning up for this talk. I'm presenting this on an iPad for the first time, an Android talk and an iPad, so I've got my hipster bases and my geek bases fully covered today. Right. So why is this talk useful? Why should you care about it? So I'm going to talk about how to get into an Android device. This is important if you live in an oppressive regime, like the UK for instance, where you can be stopped and searched on the street and the UK have recently acquired some forensic equipment so that when they stop you on the street they can access your mobile phone and take your data off to then later see if it's useful. So I'm going to talk a bit about how some of the technologies work there, how these devices might work, how you can do it manually. Also important if you lose your device, what techniques black hats have available to them. I can't really talk about how to defend against these. A company I work for, the clients wouldn't really appreciate us telling you how to prevent them getting at the data. But hopefully I'll give you some ideas. Okay, so the company I work for via forensics based in Chicago. I work in the UK, but the headquarters in Chicago. It's a mobile security and digital forensics. We've got a strong R&D team, quite talented, and may have heard my colleague Jonathan Jarski speak at Black Hat last week. My name is Thomas Cannon. I'm the director of breaking things internally. That's what I'm known as, but my corporate title is director of research and development. So yeah, you may have guessed I'm over from Jolly Old England. I came over for this talk and missed the Olympics ceremony and the opening ceremony, which is last night. I don't know if any of you guys saw it. I was quite interested to see how we could match the epic Chinese opening ceremony. And so what did we do? Well, the queen stepped up and they flew the queen over the Olympic stadium in a helicopter in her pink dress with James Bond. And she jumped out of the helicopter and parachuted into the Olympic stadium. That's true. I think that really captures the British spirit. Our best ideas really come after about nine pints of beer. So this presentation may or may not speak to that. And my day job is reverse engineering Android applications for government, corporate, blah, blah, blah. Challenges. Challenges of getting into Android devices. So ADB, I'm not going to go into detail about what that is, Android debug bridge, but it's, if it's enabled, it's a method of accessing your Android device over USB. You can do, you can get a shell up, you can get the data off. It's off by default. And from experience of dealing with real devices from real cases, it's usually off. Screen lock is usually a screen lock on as well. And they can be, they can be a pain. Code signing for updates. So some of the techniques we're going to talk about require code signing to be disabled because you can't just load an update or load your own boot image. And encryption. I'm going to cover encryption and how we attack it, how we crack it. Android full device encryption. And there's a golden rule here. Android devices are very different at the level that we're talking about between the manufacturer, operating system version, model, a Galaxy S2 isn't just a Galaxy S2, there are different versions of them. So the golden rule here is when I talk about a technique, the implementation can actually vary. Your experience may differ from our experience. So boot loader essentials. We use a boot loader to gain access to the device before the system fully boots. We can use this under certain conditions to load our own boot image from where we can image the device and get the data off the device. To get into the boot loader, accessing the boot loader is a number of ways. It usually requires a special combination of buttons like a three-finger combo which may be power up, hold it down, press the volume up, hold the power down and you get into boot loader mode. Devices may require an extra hand or a Vulkan def grip but you just Google it and you find out how to get into the boot loader. Also from ADB you can do ADB reboot boot loader, fast boot reboot boot loader. There's service GX, there's a few ways. Protocols. Again, lots of different Android devices, different protocols, different methods of flashing them, loading RAM images. You've got RSD Lite for Motorola, SPF Flash Motorola, fast boots, HTC, Google, Odin or Heimdall for Samsung, FlashTool for Sony. It's pretty challenging to support Android devices. So protection. There's either no protection or there's signature checks. You can only load the images that are signed by the manufacturer. If the device is rooted there's a good chance that it's unlocked as well. It's nice backdoor access but from experience it's not common for devices to be rooted. I don't know, maybe criminals are not really into rooting their devices. Defeating the boot loader. I'm going to give an HTC example here. So in HTC land they have S off and S on. That's security off and security on. If you boot into the boot loader you can see if your device is S off or S on. S on by default meaning it's secure. Assuming we don't have access to modify or patch the boot loader, sorry, SECU flag. It's the flag that's in radio firmware. This flag is then used in the boot loader stage to determine if it's security on or off. So if we don't have access to modify the radio firmware or patch the boot loader, which you can do, you can patch the boot loader to ignore SECU flag. How do we get in? Well, there's a gold card. It's a specially formatted micro SD card. You can use it to bypass the carrier ID check when you're flashing custom ROM. So this is one part of the equation. Also a white card. This is a manufacturer SIM card. It's really difficult to get hold of one. And it's used as a sort of authentication token challenge response to get into the device diagnostics used by the factories. Okay, so I've got a picture up on the screen. You can ignore most of this. It was part of something else that I mentioned later. But let's see. We've got a laser pointer. Right. So here's the SIM card. And this is going off to a device that's emulating a SIM card in hardware. You've got a micro SD card just up here. This whole long thing here in this circuit is actually emulating a micro SD card, but you can actually use a real micro SD card. This was used for a race condition attack on the micro SD card I mentioned later. And then just some power over here connected up. Okay, so we're emulating the micro SD card in. Then when you go into boot loader mode it will automatically pick this up. And you can clear security. You can clear S on. White card is obviously not needed for CDMA phones because they don't have SIM cards. Once you have security off you can ram load a custom boot image which I mentioned later. This technique wipes most devices. That's a bit of a problem. But we actually tested it. You know, we never believe everything you read. We tested it on some real devices and we were able to S off certain HTC devices such as an HTC desire and the data was intact. You can try it yourself with an XTC clip. It's an enterprising hacker who has produced a device to do just this for modding your phone and you can purchase it. So we have an unlocked or compliant boot loader. What do we do now? Okay, so some forensics devices use this. Next technique, they create a custom boot image, a forensics boot image. You plug the phone into the device, it loads its custom boot image and it pulls the data off. So we use a boot image to boot the device early in the chain before the system loads. We get a root shell over USB where we can load our tools and pull the data off. And importantly because this is forensics we don't want to modify anything. If you use a custom recovery image or custom boot image by clockwork mod that's not forensically designed and it will modify data on some of the partitions particularly the cache partition which it auto mounts. So we need to be up to disable that if possible. And devices with raw NAND that typically have a Yafs 2 file system, the ware leveling that spreads the data across the NAND flash to stop it wearing out is implemented in software in the Yafs 2. And that means that if we get to it before Yafs 2 loads we can prevent the ware leveling and prevent the modification of data. So if you're creating an image and you hash it one time when you come back later that hash is the same. Forensic analysts love that. On the screen there is just okay it's not going to give me a laser pointer now. There we go. On the screen there is our custom boot image that we developed for a project. You can actually put a micro SD card in and press the menu button it's point and click and it will image the device onto the micro SD card. So let's build our own boot image. I can tell you it's really simple. There's an open source tool called a boot image for modifying boot images. So you get your custom recovery or your stock recovery and the first command there extracts it. The second command unpacks the RAM disk. Then you change into the RAM disk directory. You edit the RAM disk contents which is on the next slide. And then you pack it up again and then you update the stock recovery and insert your custom RAM disk. So the RAM disk contents you got slash dev slash proc which are empty directories they're just used when it boots up to mount things off. You've got the S bin directory. All you need in there is ADBD which is the ADB demon which is going to give you that shell over USB. Busy box if you like if you know what busy box is it's just a collection of tools, common Linux tools in one binary. And we put nan dump on as well which is used for dumping partitions. We have our own modified version of nan dump with some improvements that we're going to be contributing back to the because it's an open source program. Slash sys empty directory init don't have to touch that. There's a folder a file called default dot prop. So you edit that and you change RO dot secure to zero and that will give you a root shell. A init RC you just change that you comment everything out so it doesn't mount partitions. All you need to do is start ADBD and then you have U event D. You don't need to modify that and that's it. That's a contents of our RAM disk that combined with a kernel and there's your boot image. Flash and RAM load. It didn't sound that dirty when I wrote it. Right. Samsung. Just a little aside here. There's a Samsung tool called ODIN or there's the open source Heimdall and ODIN version 1.52 or less. There's a command to dump partitions which sounds awesome. We've never actually got it to work. All it seems to do is brick our phones. But if if anybody does get it to work, please, please let me know because you've got a stack of phones. Okay. So with ODIN or Heimdall, you can flash your customer recovery image. You know, this being Android, even even with Samsung devices, there are different ways of doing that. You can see the two commands there. HTC has fast boot and the really cool thing about HTC with the fast boot or even Google devices is you can RAM load it. That means you send your image over USB into RAM and it loads it. You don't have to flash or modify any data. Motorola has SPF flash. You can flash your image to the recovery partition. I should have pointed out not to the user data partition, obviously. Be careful when you flash Motorola that your SPF file only contains the recovery partition. Otherwise, you'll just wipe all the data off it. JTAG. So this is what the government labs use. You know, this is really good stuff. So you have direct access to NAND chips via the CPU. I can't go into too much detail. You could have a whole day workshop just on JTAG. But there are on many devices, just going to get my laser pointer up. On many devices, you see these solder pads here. Six points. So you solder some wires there where you use a jig to connect to that and you connect a flasher box. Those flasher boxes are some examples there, ORT, RIF box, et cetera. And it allows you to image the NAND flash directly through the CPU and you don't have to boot the device at all. So it helps to preserve data integrity. They can be pretty flaky. Support is somewhat lacking. You know, these devices used in mobile repair shops and often come out of Eastern Europe, Russia, and other very clever places. So if you don't have JTAG, are there some other options? Well, there's a serial debug cable. This is pretty cool. It's like JTAG, only a lot easier. This is an S2 example. And as I mentioned earlier, not all S2s are the same. This also works for Galaxy Note. So in later ones, they've disabled the secondary boot loader that gives us this access. It hasn't been bundled, so it's probably a mistake by Samsung and they fixed it because hackers were taking advantage of it. So on the S2 and the Note, you sold a 523 kilo ohm resistor. Doesn't have to be exact. I've tried various values and it seems to work. Between the ground pin, the ground ID pin, sorry, sold between the ID pin and ground. And then on, you get TTL serial access over a couple of pins of the USB connector. You can use a bus pirate, which is a very cool way or any kind of USB to serial converter. You attach directly and you get a serial console over USB or over the USB connector. So there's a picture here of a bus pirate and a little USB, micro USB breakout on board and a resistor on a breadboard there. That's all you need. So you set the bus pirate to 115200 board. Eight stop bits, no parity, sorry, eight bits, no parity, one stop bit. The output type is normal. If you're using a bus pirate, there's an option. And you just plug the device into the micro USB and it'll automatically start booting. And first you see the primitive bootloader flash up. And then you see the secondary bootloader go crazy and then the device boots. But if you hold down the enter key on the terminal while you plug the device in, you end up at a SPL prompt. This whole long list here to the right is a list of all the commands that you then have access to. So you essentially have a terminal on the secondary bootloader before the device is booted, which allows you access to the device. You can carry on booting the device. You just run the load kernel command, load modem command, and then boot command and the way it goes. It's a pretty cool way of accessing the device. Okay, so some forensics devices used by law enforcement, they have this built in. It's plug and play. They plug us to in, plug the USB cable in and they can image a device straight off. It doesn't matter if it's locked or what. Not the case if it's encrypted. We'll come to that later. Okay, so you've managed to get access to the device and image it. Why not crack the PIN or password? Well, a lot of people say, well, that's silly. You've already got the data. Why would you want to crack the lock screen PIN or password? But we've got a lot of requests from customers wanting to do this. Maybe it's a time-sensitive investigation, such as a kidnapping and they just want access to the device itself to get the data off it, export the data from the applications on the device. So there are a number of reasons why you want to do that. We first published this technique in Digital Forensics magazine. It's a paid journal, so not everybody has access to it. There are now a number of blog posts about it. And what I'm going to show here is also GPU acceleration just to speed it up a bit. So the components, you've got Assault. That's stored in the file up there, settings.db. It's an integer. So if you get the settings.db, you can do a SQL lookup on it and get the lock screen salt. The PIN or password is actually stored in a password.key file. Again, golden rule, this is Android locations can vary. And then the password file is actually AssaultedShar1 of the password, and that's added to AssaultedMD5. So you have a Shar1 and you have an MD5 and they're put together. I don't know, maybe that looked more secure because it's longer, but all you need is the MD5 portion, right? So cracking it. First transform it into the format we need, which is lowercase hex with no padding. There's a Python command there for you. Copy the 32 bytes of password.key. That's the MD5 hash in hex. Add a colon, then add the salt. And then you can just put it into software such as OCL hash cat light. There's a screenshot of it. You can see the five positions where you configure it there, saying this is for cracking a PIN number. So we're looking at a sort of short four to nine digit PIN. And then there's screenshots of PINs actually cracked it. For a PIN, take seconds for a password, it can take longer, depending on the length of the password. So that's the weakness there. But it's fairly easy. Hit brute force. You know, when I'm talking to people, they often say, oh, why don't you make a device that automatically types in the PIN lots of times? And I say, well, yes, probably not going to work. And this keeps happening in this conversation. So I thought, well, you know, why not do it and demonstrate why it does or it does not work. So I've recorded a little video here. So you've got my galaxy note up on the screen. Plugged into that is a USB OTG cable because the galaxy note has USB host support. And then a little thing that looks like a thumb drive is actually an AdMail AVR chip, which are programmed to emulate a keyboard. So if I'm going to click this, hopefully we get a video. Didn't play. Let's try again. Sorry. On my screen, the video is not playing on yours. It is once more. Okay. So there I'm plugging the USB key in. It's automatically typing the password or a pin many, many times from 0 to 999. And then it locks out and you get a countdown timer. So it gives you 10 tries and then it brings up a countdown timer. So it's not really a very feasible attacks. Maybe it is on some Android devices that don't lock out. And a little tip here, if you want to try that, if you're trying to prepare slides and you forget about it and leave it plugged in, it gets to the point where it's about to wipe your data. So don't try it on your real device either like I did. Yeah. So this was actually at the pre-boot authentication because my device is encrypted. So it's right at the start. And yeah, it will wipe your device after a certain number of times. So it rate limits it. It's not really a practical attack but hey, it's cool. Android encryption. Here we go. So this is how we can or can we protect against this. So actually Android encryption is pretty good. You'll notice somewhere on here. Somewhere on here it mentions a pin. So this is a Galaxy Nexus, sorry, this is a Nexus S. And I'm setting up encryption on this device and it allows you to enter a pin, a four digit pin for encryption. Okay. And then it takes a while and it goes ahead and encrypts your device. It's been supported since Android 3 based on DM encrypt standard linux. 128 bit AES. Cypher block chaining. Implementations vary. We're looking at Samsung devices. They have their own key management module. It's done in a slightly different way. Okay. I think I'll have a beer for this. Android encryption. Okay. Let's get my laser pointer. Password or pin. So this is where your password or pin comes in. It then runs through, it derives your password, sorry, derives your key based on your password, runs that through 2000 iterations. The input is the key length 32. It's going to give you 32 bytes of output. You also need a salt. A salt is derived from dev u random. So it's a random salt. The output of this 32 bytes is the key and IV. It's split down the middle. So you end up with 128 bit key and 128 bit IV. That feeds into AS 128 CBC along with a master key which is also derived from dev u random. The output is an encrypted 128 bit master key. Okay. So we have a master key. It's encrypted. Once it's decrypted by the system after you enter your password, this is how it uses it. It's DM crypt with ESS IV. So ESS IV is encrypted salt sector initialization vector. It's used in block encryption for disks. Each sector here is 512 bytes regardless of the file system. The IV for the first block of each sector is the sector number encrypted with a hash of the key. It prevents watermarking attacks, that kind of thing. And then subsequent blocks in that sector use the IV of the previous blocks. Cypher text because it's Cypher block chaining. Also, so your data goes in, you use a data partition, what comes out is encrypted use of data partition. Cracking the encryption. So the encrypted master key in the salt is stored in a footer. That footer can be stored in a footer file on a partition or part of the start of a partition itself. It depends on the device. So what we need to do is image the device, locate the footer and then get the encrypted user data partition as well. So if you're using JTAG or the USB serial attack or even ship off a number of attacks like that or a number of processes like that. So you have your encrypted user data partition and you have your encrypted key and yeah, your encrypted key. So we parse the footer, we locate the salt and the encrypted master key. We're going to brute force it. We run the password guest through PBKDF2 again with the salt that we've got. And we use the resulting key in IV to decrypt the master key. Use that resulting master key to decrypt the first sector of the encrypted image. If the password is correct, the plain text will be revealed. So this is a screenshot from an initial tool. Don't worry if you can't see it too well. But you can certainly see the pattern there, the one on the left has been decrypted successfully. It's a bunch of zeros. The one on the right looks like random data. It's still encrypted. Cracking the pin takes seconds. That's the weakness here. Cracking a password may not take much longer. This password for encryption is the same password that's used for the lock screen. So people aren't going to want to enter a 32 character password every time they want to make a phone call. So with patterns, easy short password is definitely possible to brute force this. This is just a proof of concept Python script. As we've leased it open source, I'll mention the link at the end. We've actually got a guy, Andrei Belenko from Russia joining our team very soon. He's the brains behind the Elkom soft GPU cracking software. So you can expect this to get a lot better. Actually, I just want to mention there's a mistake on this screenshot. You'll see at the start of the data. It's all zeros except for the first sector. That's because I got the ESS IV wrong. So it was able to decrypt the rest of the sector because cypher block chaining depends on the cypher text of one block being fed as the IV into the next block. We obviously have the cypher text. So we can still decrypt the data. That ESS IV issue will be actually fixed in the real thing. Let's talk about some other ones. Evil made attack. I actually thought this was called French made attack. I don't know where I got that from. Okay, so you leave your device in a hotel room. That's the idea. And while you're out, the evil maid comes in and they have physical access to your device, but maybe they can't decrypt it. So they load an app onto your system partition because that's not encrypted. They wait for you to boot your phone, then they have remote access to your decrypted user data if their app has remote access. Root kits. Easy to compile for Android. Just compile a Linux kernel module for Android. There's no big deal. And that, you know, you can hide yourself in the system really easily. It's very hard to detect for the average user especially. Evil USB charger. It's been done. You plug your device into an outlet. Maybe you don't trust it. Behind it is an evil, evil device that maybe it charges your phone, but it also runs these attacks we've been talking about and gets access to your device. Reverse shell. I did this demo a little while ago. Concept based on presentation by Look Out Guys a while back. This is quite an old concept. Basically we created an app that had no permissions. It looked pretty safe to install. You install it and even though it has no permissions, as soon as the user locks their phone screen or perhaps on a timer sometime at night, it will connect back to us and give us a reverse shell. It uses no exploits. It uses a web browser to transmit data. By calling a web browser with data in the URL, it's able to pass data out. It then retrieves data from the web browser and uses URL handlers to pass the data back to the malicious Android app. There's a video of it online if you want to try it out or have a look at that. It's called No Permissions Reverse Shell. There are lots of techniques. We could run a whole day workshop on this stuff. So I just thought I'd do a couple of fun ones. Hard reset. Unbelievable. You hard reset your device. It wipes your data. But on some devices prior to 3.0, the wipe didn't work properly. So you hard reset the device. You then have access to it. You know, there's no lock screen anymore. You route it and then you image it and you get the person's data. It takes balls, though, because you might just destroy the evidence and somebody's not going to be very happy. Ship off. This is really hardcore stuff. This is where you desolder the NAND chips and you put them into a special reader. Very tiny, very hard, pretty easy to destroy the NAND flash chips while you're trying to desolder them, especially after a few beers. But it's definitely a technique. It takes expertise. It's kind of not much defense to that other than encryption with a strong passphrase, right? Screen smudges. Hey, if you're desperate, look at the screen smudges and see if you can work out what the pattern was that they ended. Custom update.zip. So an update.zip, this is a method for Android devices to update. You have the update in a zip file and you put it onto the microSD card if your device has a microSD card. And then when you boot it up into the recovery, you can apply that update. Problem is on a stock device, these devices need to be signed by the manufacturer. If you, you know, if you haven't unlocked the boot loader or anything like that, it's not going to run your custom update zip. If you could run your custom update zip, you can put your own binaries in it, give yourself a shell or copy the data off. It's pretty cool. So the question is, can you get one signed? You know, hey, has anybody here got a universally signed update zip? No? Yeah, one over there? I don't, I just put my hand up. I was watching this American show, The Mentalist, and he was using these mental techniques. That doesn't sound right. He was social engineering people and what he would do is he would ask a question, who murdered Jane Doe and then he'd put his hand up and it would be more likely that the murderer would put the hand up. So a few months ago I gave a similar talk to this in London and was attended by a lot of law enforcement personnel, FBI, Met Police. So I was curious if anybody had a universally signed update zip. Put my hand up and one guy actually put his hand up and admitted that he did. Yeah, he was, he's a nice chap, he was from Israel and we, he came up to the end and we had a good talk. And the third point there about owning a CA who doesn't these days, right, where you man in the middle of connection you can push an update. You know it's a joke, I mean yeah okay, CA's are getting owned but really who owns the CA. This guy from Israel is pretty interested in this technique. So maybe it's possible. And actually I have seen update, Dodd zip signed and they're locked to specific IMEI numbers or specific serial numbers of the device. I can't say where you can get them from but in a legitimate law enforcement investigation it may be possible, I'm choosing my words carefully here, it may be possible to get one of these update zips to gain access with a warrant to a suspect's device. Race condition, I mentioned this earlier when I had the diagram up on the screen so we thought we'd try a race condition because we were looking at the Android source code in the recovery image and we noticed when we were applying an update what it would do is it would read the update, Dodd zip and check the signature and if the signature was correct it would then read it again and apply the update. So we thought, oh hey why don't we create a device that emulates a micro SD card, when it reads it the first time we'll give it a legitimate one, when it reads it a second time we'll supply our malicious one and get our update applied. This was actually fixed quite early on so it didn't work and there were issues around caching as well. It was definitely possible on some devices. Entry via Google Play, if you leave your computer logged on at home and your Google Play credentials are cached so people can get on to your desktop and they can automatically log into Google Play they can push an update sorry push an app out to your phone. I actually made an app called ScreenLock Bypass, it's free it's in the market and you can push this app out to a phone and what it will do is it will call an API call to disable the lock screen. It's a legitimate API call if somebody, you know if an app needs to disable the lock screen because you've got an incoming call that's how it does it. This doesn't work on newer Android devices ice cream sandwich and on because it's a security issue so they fixed it. Okay so some of the tools that I mentioned earlier we've created or we are creating an open source Linux distribution called Santoku. You can go and download it now, it's just the alpha version. I had some technical issues trying to get this ready for the con so at the moment it's a remix of OWASP's MobiSec but we're going to continue forking it or expanding it. There's a bunch of tools on there that you can use to play about with Android and iOS and BlackBerry. So it's a community project. There's a bunch of security pros from other companies that are contributing to it. And we want to use it for mobile app security, malware analysis and forensic. It's what we do in our day job so you know let's create a distro, we use it in our day job and we'll give it away to the community as well and hopefully people will contribute to it. Okay I think we're going to step back a few slides. Okay so I forgot to mention a few things on this screen I just recalled. So I'm just going to leave it there so I can see it on my screen. The second screen shot below is actually of a Nexus S so you can actually see how we're mounting the apps partition after we get access to the device and the user data footer is actually a file in there. In Santoku Linux we have the script to automatically brute force the pin. We're hoping to work on a GUI version to make this nice and easy too and work on the Samson tool as well because Samson is different and encryption is different. Okay sorry about that. Okay so I'm finishing early here I'm just wondering if there's any questions anybody wants to share experiences or ask questions on the floor. Yeah. Okay. Yeah. Pattern lock? Okay. So the question was how is the pattern lock stored and how do you crack it? We've done this before and we've also released a script to do this. The pattern lock is nine points on the screen and it's stored as numbers zero to eight. These are stored as bytes in a pattern lock file and that byte is then hashed and if you can retrieve the hash you can then crack it. It's not salted either so you can do a dictionary attack on this or just brute force it. There are less than a million combinations so you can brute force it in seconds. It's a similar principle it's called gesture.key stored on the android system. So I'll answer your question. Yeah. Yes. So the idea being that so what's the first thing a forensic investigator does? Maybe they plug the USB cable in. Well you can detect that, right? You can detect that the USB cable is being plugged in and power has been applied. So if you have an app that uses a standard API broadcast intent so when it detects power being applied to the phone it then triggers some code. You could either reboot the device if it's encrypted or better if it's a routed device you could actually wipe the master key so that even if you know the password and you're forced to give it up nobody's going to be able to decrypt that data on your device. Yeah. Yeah. The encryption is the same we actually did this on a jelly bean device as well Galaxy Nexus I think it was. The encryption is actually good it's just depending on the strength of your passphrase on Samsung devices actually well at least on my Galaxy Note it forces you to use a secure password you can't use a pin number but again people use patterns on their keyboard that kind of thing. Hmm. Okay so the question was was there a password we've encountered we couldn't crack we're still new on cracking passwords on Android it's still emerging so no there hasn't been any thus far but maybe there will be and the second question is about iOS devices so iOS devices not an expert we have them in our company they're a bit different because that's automatically decrypts itself on boot so Android encryption in my opinion is actually better because it's full device encryption with a pre-boot authentication on our iOS device you turn it on it boots up and it's decrypting the data you need to enter your lock screen password to actually get into it but there are techniques to get into the device and start pulling the data so it's different with iOS devices you obviously have the encryption the AES is actually on the chip and it's rate limited so it takes a while but yeah it's possible in a different way sorry what's the question okay so the question was is there a way to decouple the pre-boot pin or password from the lock screen not that I know of in stock Android obviously you've got Android distributions that's the beauty about it and you can modify it to do that if you wanted that would be the ideal thing to do because you could enter your secure password pass phrase long and complicated when you boot up which you do infrequently and then an easier one on the lock screen yeah so you saw the video earlier where we used the HID device to automatically enter information we haven't found we haven't found any vulnerabilities on the HID protocol itself yeah so there's a keyboard on the pre-boot authentication screen right so yeah there's an app that runs that but that doesn't have access to the passphrase or it doesn't cache it or anything like that it's not saved to the user dictionary because the user data partition is it's only when you enter your password or pin it tries to decrypt the user data partition or not by whether or not it decrypts or not that's how it works so unless I misunderstand your question I don't think there's a way to do that good question yeah so the question was have you ever encountered a law enforcement root kit I can't answer that one very okay guys anymore okay I'd thanks for coming and for staying till the end sorry I got through a bit quick and I expected I'd like to thank a few people Google for making an awesome phone and the other guys there and Tim as well for having a look at my slides yeah thanks