IOS 6.1 hack lets users see your phone app, place calls(news.cnet.com)
news.cnet.com
IOS 6.1 hack lets users see your phone app, place calls
http://news.cnet.com/8301-13579_3-57569389-37/ios-6.1-hack-lets-users-see-your-phone-app-place-calls/
29 comments
Any idea why the status bar turns blue after cancelling a shut down attempt after touching emergency call?
Normally status bar changes are for calls/tethering.
The Phone app has a blue status bar in iOS 6.
You're right! And so does Mail, Settings etc. Never noticed.
The best fix will be to include a Emergency.app that displays a num keyboard and it's called from the 'Make an Emergency Call' button, instead of the full Phone.app.
The question is how did anyone figure out this method? I know it was first exposed in a similar manner on iOS 4.1 but is there someone deliberately trying to break the passcode lock? Is the recent jailbreak helping?
To answer the question in the middle: yes, there are tons of people attempting to break the passcode lock system. One of these groups are police departments and the forensics experts they hire, who really hate it when the victim's cell phone might give them the vital clues they need to solve the murder, if only it weren't locked. (You may argue with the morals of this: I am just reporting that these groups actively work on this, and you can buy books and tools and even hire them as consultants for these purposes... I am not saying it is "right" or "wrong".)
Passcode locks are a barrier only for domestic uses, and wouldn't be a problem for a forensics expert. It's not like the pass code would encrypt the filesystem.
Actually the PIN code is the key (to the key) to the encrypted filesystem. http://www.technologyreview.com/news/428477/the-iphone-has-p...
That's why on modern devices, a full remote wipe / secure wipe takes seconds instead of hours - only the master filesystem encryption key needs to be zeroed.
That's why on modern devices, a full remote wipe / secure wipe takes seconds instead of hours - only the master filesystem encryption key needs to be zeroed.
How hard is it to brute-force 10k keys?
http://helpdesk.bradley.edu/howto/images/iOS/erase.jpg
also, if you need it you can enable passwords of any length and with more than just digits.
also, if you need it you can enable passwords of any length and with more than just digits.
From the extracted phone image, obviously.
Obviously, except the phone won't talk over USB unless it's unlocked. Unless of course you really want that data and take it apart and read the NAND directly. As always, security is not binary, you decide how much you need. If you are that concerned about your data you can enable real passwords.
I believe the file system key is stored in a special area of storage nearly inside the system-on-chip, making this even more difficult than you'd even have assumed.
If your phone is set to hard reset after five or ten, pretty damn hard.
Thanks, my bad, i don't know that.
Trying to figure out what difference that makes, or why you bring up jailbreaking at all.
It appears he's suggesting flaws exploited in the jailbreak are related to flaws that allow you to bypass the passcode.
Seems unlikely, but still :)
Seems unlikely, but still :)
Well just out of curiosity. I mentioned the jailbreak because now people can have root access which could be useful, I don't know. Maybe the timing is just an coincident.
I believe this bug applies to all devices running 6.1, which includes the iPhone 4; we have a permanent jailbreak for the iPhone 4, due to the limera1n bootloader exploit, and thereby have had people using jailbroken 6.1 iPhone 4's (which are quite popular, even still being sold new) for a while.
For jailbroken iOS devices, some potential solutions would be to replace the default lockscreen with one of the alternatives, and/or install the Cydia tweak that disables Emergency calls.
What are the chances this is a built-in backdoor? Also, what would be the ramifications if someone found out it was?
Virtually nil.
Why would Apple intentionally add a backdoor like this to iOS? If their goal was to create a way for LEO/courts/etc. to access locked phones, why wouldn't they make the backdoor function only when the phone is in DFU mode, or make a separate application that can access locked phones, and strictly control access to that application?
Looks like Cnet is having issues. I keep getting "Whoops! You broke the Internet!" on most of their pages.
It sounds like a purposely coded backdoor but hopefully I'm wrong.
I really don't see what all the fuss is about. It's not like my address book has anything particularly private in it.
Well as long as it doesn't affect nwh, I don't see what all those business people, journalists and activists are worried about.
Investigative journalists have an address book and call history that is hugely valuable to certain people/companies.
Want to know which employee leaked your super-secret info to a reporter? Arrange for his/her phone to be stolen as they walk down the street chatting on it. Then it's just a quesion of how fast they can remote-wipe it...
Want to know which employee leaked your super-secret info to a reporter? Arrange for his/her phone to be stolen as they walk down the street chatting on it. Then it's just a quesion of how fast they can remote-wipe it...
This isn't Apple being nefarious: this is just Apple being "sloppy" (which I put in quotes, as when you have as many engineers as they do working on as many features as they are, with all of the user interface wedged into the same small set of displays, you are going to expect to have at least a few places like this, and honestly Apple generally does really well at avoiding them).
(As a similar example to this, for an unrelated reason, I just spent the last few hours pulling apart how they do the UI z-ordering of the lock screen, and it is a ton of one-off rules like "if I am adding the notification list, and I already have a battery image up, put it over the battery; otherwise, try to find a thermal warning, but first ask if it considers itself important enough to be rendered on top of the notifications; if not, then see if we have a headset charging display, and try to render on top of that...".)