Once I had my own realm database key sorted out, I set out to figure out how to compute this key for someone else. I moved on from static analysis and into dynamic binary instrumentation with frida.Īfter setting traces on, I obtained a reference to the CPDataStore in memory using ObjC.Choose and arbitrarily invoked the encryptionKey getter. That should have been an alarm bell but I guess I did not expect anything that sloppy in this day and age. What I couldn’t figure out was where they were storing it, so that it could be found on the next run of the app. Here’s where I made the assumption: I concluded that retain] was likely generating some pseudorandom data for use as a key. I searched for cross references to the setEncryptionKey: which sounded right in line with what I was hoping to find, and landed on the function which does this: Next I opened the decrypted binary in Hopper and did a search for ‘crypt’. I downloaded a copy of the Chipolo app on iOS from the app store on my test device and then obtained a decrypted copy of the IPA using ios_dump.py from AloneMonkey. NET implementation because I understand it best) and found this source file with some helpful info about their encryption process.Ĭool - so we know we are expecting a 64byte key and that it will be used with AES-256. Reviewed the Realm codebase (I chose to browse their. Anyhow, here is a summary of the steps I took to determine what was going on: I know I cringed a little bit inside when I heard this realm database was encrypted. I had the opportunity to work with the legendary Chris Vance on this inquiry. Reverse Engineering Chipolo – a lesson in making assumptions based on method names. Mike did a nice little writeup that I'm going to include verbatim below: So I turned to friend of colleague, Mike Williamson. The bad news is that I didn't get anything back. Since the browser mentioned it was 128-characters of hexadecimal it made for some easy GREP searches. ![]() At this point I did my fairly standard checks, going out and looking in the keychain or looking to see if the devs happened to be using a key stored somewhere in plaintext. Not only is it a realm database, it's an encrypted realm database. Turns out, not only is Chipolo using a completely different data storage container than most apps, they're also encrypting said container.Īs per my normal methodology, after finding the application storage folder for Chipolo it was time to start looking at its preference data. If you saw the Android post about DJI Fly, you saw that some of the preference data was encrypted now. Why am I starting with Chipolo versus the others? Well mostly because it caused me some issues and I wanted to talk about those issues. Last year I did a post on Tile for Android and ever since I've been interested in what the iOS operating system had as well. The upcoming blog posts will compare Chipolo, Tile, and TrackR finders and what they are leaving behind on our iOS devices. Chipolo just happens to be the first on my list to talk about for iOS. ![]() Well, enter a lot of Bluetooth based finders really. Wouldn't it be nice if a user basically also carried around a GPS tracker with them? Oh wait, a lot of folks do!Įnter: the Chipolo. But what if the application is collecting it for their purpose too and transmitting it back to their servers? Maybe there are files left behind in the application that can point to when a user was in a specific area. Often times our third party apps are collecting location data but according to Apple's policy it's supposed to be passing through them. Especially if that data is generated not by the core system and is instead generated by a third party application. I'm always interested in location data that is available on iOS and Android devices.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |