If you're reading this, I'm just going to assume you've heard of my tweak, ByPass. (if you haven't, I recommend clicking here from your jailbroken iOS device).

Essentially, its purpose is to provide an Activator action that unlocks the phone, bypassing the passcode.

As many know, the release was plagued with many issues. WiFi wouldn't accept valid passwords, the Mail App showed "No Sender", and various apps such as AlienBlue, FaceBook, and Twitter refused to log in.

This is why it happened.

The Problem

There are a few reasons why ByPass didn't function as it should. The main cause was the lack of an unlocking method. In iOS 6, there was a property that could be overriden to make the phone think that it was unlocked (This is how TapTapPass worked). However, in iOS 7, things changed.

Now the keychain (the system that stores passwords) is encrypted with the device's passcode, and it is only unlocked when the passcode is entered.

You've probably guessed the issue by now. However, in the event that you haven't, I've explained it below anyways:

I use my method to trick the device into thinking that it is unlocked, and that part works perfectly. However, when you use ByPass, the passcode isn't entered. No passcode = no keychain, so no apps that require logins can access their saved credentials, and new credentials won't save. These same apps work fine after a lock and unlock with the passcode.

The Solution

For some strange reason, my first thought was to figure out how to unlock the keychain without the passcode. This is actually impossible, and obviously so. (Pretty stupid of me, but I was running on like an hour of sleep)

After talking to a few people, I finally figured out how to make it work. The tweak now functions by caching the passcode on first successful unlock, and then replaying that passcode to the device when you use the gesture.

Boom. The phone recieves the correct passcode, and the keychain unlocks, all without user intervention.

Security Concerns

This method does have the downside of requiring the password to be saved somewhere, as pointed out by Ryan Petrich in this comment. It's an absolutely valid concern, but I believe ByPass is relatively safe from any sort of attack on this front; the reason being that the pass code isn't just saved on the device for anyone with SSH or USB access to read.

At the time of this writing, I am considering two options:

The first option is to not save the passcode to the disk. Instead, ByPass would hold it in the device's memory, and the data would be wiped after a respring.

  • Pros: Faster; easier to implement
  • Cons: Regular passcode lock will have to be used once after every respring and passcode change.

The second option is to cache the passcode, then save it to disk with 256-bit encryption. This ensures that it cannot be accessed by any person or application except ByPass.

  • Pros: Passcode remains saved after respring
  • Cons: Slower; Will take longer to make

I will most likely be releasing ByPass with the first option by Friday, January 18. I feel that it is the easier option, and I would like to get the fix pushed ASAP. I will probably roll out the second as a option in a later update.

Afterthoughts

To be honest, ByPass was much more complicated than it would have been on iOS 6, but it still isn't remotely the most complex tweak in the world. The biggest issue is that I was expecting it to work similarly to how TapTapPass did, and this assumption caused a release with a few massive bugs.

Fortunately, these issues have all been resolved.

Furthermore, with the release of ByPass nearly out of the way, TapTapPass should be following very soon.

Special thanks to Filippo Bigarella, for helping me figure out how to finally get this tweak working properly.

comments powered by Disqus