Category Archives: Apple

Regaining access to a passcode-disabled iOS device

Update 2019-12-16: Seriously, this is VERY OUTDATED and I cannot help you. I will still approve comments in case anyone else wants to chime in. I have no reason to study this, as I don’t deal with any form of iPhone servicing these days. This post was for iPhone 3GS with iOS 5.0.1. That’s ancient, very exploited hardware with ancient, very exploited OS. I don’t follow jailbreak scene in 2019 at all. I don’t know if working around passcode lock is remotely possible these days.

Update 2016-03-16: This 2012 post discussed iOS 5 on iPhone 3GS. Both the iOS hardware and software are more secure these days. I don’t use iOS much these days either. I’m keeping the post up for archival, but chances that I can help you are very low.

You have a passcode-disabled iOS device? You get a message similar to “iPhone disabled for XYZ minutes”? Especially if the message mentions millions of minutes, this may be a problem. Or if the iPhone instructs you to plug it in iTunes, and then iTunes says that you need to unlock the passcode, without a way for you to enter it?

One way is to restore the device. Unacceptable if you have important info on the device.

Let’s instead destroy the passwords and Springboard settings. You’ll still need to enter your passcode, but at least you’ll be able to unlock the device. If you forgot the passcode, you’ll at least have SSH installed and a way to connect to the device. If you find the instructions on how to remove the passcode completely, leave a comment below.

Instructions for OS X. Tested on iPhone 3GS with 5.0.1. You’re expected to have at least a brain, some experience with jailbreaking, and understanding of UNIX systems.

  1. Grab latest redsn0w. (At the time of writing, redsn0w 0.9.11b4)
  2. Grab “SSH_bundle.tgz“.
  3. Run redsn0w and click “Jailbreak”.
  4. Follow instructions and choose “Install custom bundle”
  5. Wait until device reboots.
  6. Grab “usbmuxd”. Tested with “usbmuxd-1.0.7.tar.gz
  7. Unpack it, open Terminal, and go into the newly created “usbmuxd-1.0.7” folder.
  8. Go to “python-client” subfolder. Type “python 22:2023”. This allows you to connect to the device via the USB cable.
  9. In a new Terminal window or tab, type “ssh root@localhost -p 2023”. This’ll work about 30 seconds after the device boots successfully.
  10. Try typing “alpine” as the password. If it works, congratulations! Let’s move on.
  11. In terminal that is connected via SSH to your iPhone, type “rm /var/mobile/Library/Preferences/”.
  12. In terminal that is connected via SSH to your iPhone, type “rm /var/Keychains/keychain-2.db”.
  13. Just to be sure, let’s check your date. In your local Mac terminal, type “date”. Copy the result to the clipboard. In terminal that is connected via SSH to your iPhone, type “date”. If the dates aren’t reasonably close (a couple of hours of difference max), type “date -s PASTETHEDATEFROMYOURMAC” into terminal for your iPhone. Now type “date” on iPhone terminal just to be sure.
  14. Reboot the device. Enter the passcode.


Information source: this post, research


Again, if you are able to remove the passcode completely, tell me. Thread in which the post I linked to is located contains some info, but I haven’t been able to verify it. (I don’t plan on locking customer’s iPhone again just to check, thank you very much ;))

What I'm missing in Xcode4?

I’m a big fan of Xcode3. Xcode4 is a step in the right direction for me, though. Not so much as it would be when I started with Mac and iOS development, but still, it’s ok.

However, there are large omissions and important bugs that are heavily influencing my productivity.

  1. Removed Right-click, Find In Documentation. (Update on April 1st 2011, 16:42 CET: Alt+left-click is a replacement for this.)
  2. Removed Command+shift+up to switch between header and source. Assistant views are not a replacement since I work on Macbook, which doesn’t have all that much screen real-estate, especially, when you have the File Navigator on the left. (Update on July 12th 2011, 16:21 CET: Use Ctrl+cmd+up, or three-fingers-down-to-up touchpad gesture.)
  3. No ability opening multiple Get Info dialogs on the screen for different project Targets. In fact, Get Info was removed and replaced with (admittedly superior) way of editing build settings.
  4. When autocomplete lists tons of options, Page-down (Fn+Down) does not work. That’s right, you can’t scroll over a screenful of symbols at a time.
  5. Command+shift+b has been reassigned to … get this … Build & Analyze. Ok, that needed a shortcut (maybe), but Command+shift+b used to be the shortcut to open “build progress” output dialog.
  6. Build progress is now assigned a navigator; that is, hit Command+7 to get it. However… the Editor view does not automatically focus on latest build progress and.
  7. Closely related to previous item: there is no obvious shortcut for switching focus between Editor and Navigator. I really want to quickly choose a file, to quickly choose a build log, and to quickly choose an issue from the list. While this is not something that used to exist in Xcode3 (or at least I couldn’t find it) it is still something that would be highly useful. Open Quickly – Command+Shift+O – is not a substitute.
  8. I really miss the old “Groups & Files” view. Not a big deal, but having that as an alternative to the new Navigators view would be excellent.
  9. While autocomplete got even better, Command+doubleclick is extremely dumbed down and cannot guess that in [[NSString alloc] initWithString:@"something"]; attempting to find initWithString in header probably means NSString‘s -initWithString:, right? Well, if you have another initWithString: in another class, Xcode4 will ask you which one you refer to (despite [NSString alloc] being declared to return NSString, thus there being no dillema whose -initWithString: needs to be used).
  10. Despite introducing tabs, they are next to useless: hard to open, and with no obvious keyboard shortcuts to switch tabs or close tabs.
  11. added March 18 2011, 14:12 Oh. Right-click, Add Files to “projectname.xcodeproj” does not take into account parent group path anymore. That means, despite configuring that pesky Window Systems/iOS group to point to path “relative to group” and pointing to “windowsystem/iOS” filesystem folder, Add Files dialog will no longer default to that folder. Meaning I nevertheless have to dig around the filesystem to find the relevant files.
  12. added March 18 2011, 14:40 You can no longer easily access full path to a currently open file by right-clicking on the titlebar. This is important in case error log refers to system-wide installed header file, which you go and happily change without affecting header file that you should be changing — the one in a subproject.

These are just some omissions that significantly reduce my productivity compared to Xcode3. I sincerely hope they will be patched by Apple, otherwise I’ll simply have to do without them. There’s no other way: iOS devs (and to some extent Mac devs) are hostages of the latest SDK which ships only with the latest IDE.

A simple validator for Mac App Store submissions

I figured out I had to have an automated check prior to Mac App Store submission because I managed to miss some stuff a few times.

So here’s a beginning of a simple unofficial test suite for Mac App Store submissions: CheckRelease on BitBucket

It currently checks only if you have some external dependencies. I’ll try to write a validation for checking if you have added all the frameworks you depend on into the app, and I hope to extend it with some additional tests.

It’s under BSD license, and contributions are very welcome!

Also, hopefully, Apple will extend their own validator built into Application Loader and Xcode. Currently we have to wait a few days for rejections from the App Store team that are as trivial as “forgot to put in a framework” and “forgot to get rid of an external dependency” (or, at least, a reference to an external dependency that you actually don’t depend on, and that you never actually use).

Mac App Store rejection due to incorrect framework paths

Apple’s very strict: you can reference frameworks in /System/Library/Frameworks and in your own app. That’s all fine, but there’s another unexpected obstacle. App can be self-contained (the library executable paths patched using install_name_tool) but the install path still references /Library/Frameworks. See “otool -L”; the first reference is a self-reference, and it looks like you can’t easily update it after the library is built. (Or I didn’t look hard enough). And yup, leaving that an absolute path referencing into /Library/Frameworks, that’s enough for rejection.

Untested theory is that updating “Dynamic Library Install Name” (LC_ID_DYLIB) is enough to fix this. I’ve set it to:


in place of


Testing for presence of Apple platform in C/C++/ObjC code

Are we running on an Apple platform?
#ifdef __APPLE__
Prerequisite for other tests
#ifdef __APPLE__
// let Apple define 
// various TARGET_OS_ 
// constants
// not on Apple platform
Are we running on Mac OS X?
Are we running on an iOS device?
// updated on Oct13 2010, previous method was flawed. sorry everyone!