This chapter was supposed to be about additional methods to detect OS.X/Crisis but I had the evil idea of taking full control of Crisis, and played with this idea for the last couple of days. It’s pretty damm easy to customize the dropper, and at the limit, be able to deploy your own version of Crisis to anyone. This raises some problematic questions, some of which I was fooling around with at Twitter. To make it clear, I have no intent whatsoever to resell Crisis or something. First because it enters in conflict with my values, and second because it enters a potentially big legal minefield.
To me, hacking is all about raising the weird questions, playing with stuff, and experimenting with what others doesn’t see. I would love to have the resources to answer and test the legal minefield just because it’s a curious topic. The world is increasingly dangerous for hacking. It’s sort of a paradox that in a age of fast access to information the trend seems to be running towards making it more difficult to access and spread information. But enough of philosophical questions!
I will keep researching in private if I have time to. My free time status is going to change soon so things will be different. I still have some very cool ideas to try with Crisis and they would probably generate some interesting articles. We’ll have to wait and see if the environment changes.
These last days I must be set on a Apple devices destruction mode. First I lost access to my MacBook while trying to increase its physical security – I configured it to boot from network and I lost all access to boot sequence commands. I think my model has an EFI bug because the security-mode set to full doesn’t ask for a password when I start/restart my laptop, only asks for password if I want to boot from other devices. I had to install a Snow Leopard Server to boot from a netboot image (the process works extremely well!) and fix the startup sequence… This of course after quite a few (known) attempts to reset the damn startup sequence – I even removed the NRAM battery, to no effect!
Proceeding in this “destruction” sequence, I set my iTunes to encrypt backups and I forgot the damn password (too many passwords…). Since losing that backup wasn’t a big issue, I tried just to remove the encrypted option but that doesn’t work since it requires the old password. Some web searching without any relevant results. The best clue was to mess with keychain-2.db file, located at /var/Keychains. I tried to move it but it didn’t work, so I went checking its contents, since it’s a sqlite3 database. The interesting field is located at the genp table and it is something like (your results should differ, at least the first row, which is “rowid” field):
So I deleted this row (delete from genp where rowid = 153) and reconnected my iPad to iTunes. I tried to remove the Encrypt iPad Backup option but it asked again for the password. Fill it with random junk and voila, problem solved 🙂
A new, unencrypted, backup will start. After it finishes (or you can stop it), you will be able to set a new password and the encrypted backup will start.
Most probably you will need to have your iOS device jailbroken to access that file. If you can access that file from a file system browser then you can edit it at your iTunes computer and copy back to the device (I doubt that this is possible with devices not jailbroken).
Update: This method doesn’t seem to be valid in iOS 5.x. The database has changed and the fields appear to be encrypted. Need to do some research on this.