Pull Notification Locally on Jailbroken Device

Check if app has a notfication using private frameworks?

I believe there are two notifications which looks similar, but internally goes through different execution routes: local notification and remote push notifications.

I don't have exact answer. Couple of ideas, direction, where I would look for:

API's in private framework SpringboardServices

• Objective C SBSPushStore class
• Bunch of C API's SBSPush*

There is ApplePushService private framework. I believe it provides a connection through which remote notifications are received.

Also, there is a BulletinBoardService. I believe this one is related to showing the list of notifications. My guess, that it may store notifications.

iphone: notification when receiving a call?

Within CoreTelephony is the CTCallCenter class which includes the callEventHandler property, which is a block that runs upon changes in the call state. As described in the documentation, you could use this to become notified of these states:

CTCallStateDialing;
CTCallStateIncoming;
CTCallStateConnected;
CTCallStateDisconnected;

Docs say you must be in active app state. If you are suspended, then you only get one block state change notification upon waking up. If you are jailbroken and in background state, hopefully you would get your block executed, so you could become aware of this.

UIApplicationDelegate not called when using Backgrounder on a jailbroken device

Milk Tea got me on the right track... So the bounty goes to him.

But actually I got a better solution...
I have checked every single notifications thrown when resigning the App...

and I got this, even with backgrounder configured to keep the App open, those notifications are thrown :

UIApplicationSuspendedEventsOnlyNotification -- When going into background
UIApplicationResumedEventsOnlyNotification   -- When going into foreground

This makes sense, since even with backgrounder, it would have been a bad idea to let the App keep receiving events notifications, for example, when a change of rotation (or a shake) is done outside the App. Do you imagine every App doing a rotation on background everytime you move your iphone ?

NSFileProtection on Jailbroken device

NSFileProtection does not offer any real protection from code executed on the device with root privileges. Without pincode you can just open any file. With pincode files will not be accessible when device is locked but it's easy to intercept pincode being entered and use it later to programmatically disable protection and open any file at any time. But if the user himself wants to get access then he will not be using pincode in the first place.

As to other ways of protection, I don't think you can properly secure anything from skilled user. There're a couple of ways but there're always ways around them:

1. Encrypt the data and store encryption keys localy. User could find the keys and decrypt everything
2. Encrypt the data but store encryption keys on the server side, never cache them anywhere localy. User could sniff web traffic and get the keys. SSL with certificate pinning will protect you from that. But user can always patch your app's binary or use hooks to either disable encryption altogether or dump encryption keys.
3. Don't store anything localy, always access data from the web. Use SSL with ceertificate pinning to avoid sniffing. But again, binary patches and hooks are still possible.

So I don't think you can fully secure your data but you can make protection sufficiently difficult to reverse engineer and disable so that most of the users will not go through it.

Is it possible to use an NSTimer to wake a jailbroken iPhone from deep sleep?

I've worked out a method that works for me. As per my long exchange with Nate (and I definitely wouldn't have been able to work out what was going on without his help), this seems to happen automatically on some systems, but not on others. The problem on my phone seemed to be that powerd was putting the phone into some sort of deep sleep that paused the NSTimers and didn't allow them to fire properly.

Rather than disabling deep sleep (which I suspect has negative power implications) I scheduled a power event:

NSDate *wakeTime = [[NSDate date] dateByAddingTimeInterval:(delayInSeconds - 10)];
int reply = IOPMSchedulePowerEvent((CFDateRef)wakeTime, CFSTR("com.amm.daemontimertest"), CFSTR(kIOPMAutoWake));

This successfully wakes the phone 10 seconds before the alarm is supposed to go off. (The interval isn't precise. I wanted it to be short enough that the phone wouldn't go back to sleep, but long enough that if the phone takes a moment to wake up the timer can still go at the right time. I'll probably shorten it to just 3 or 4 seconds.

The remaining problem is that the NSTimer for the alarm itself won't update automatically, and so it'll be late by whatever period the phone was asleep for. To fix this you can cancel and reschedule the NSTimer whenever the phone wakes up. I did this by registering for a notification that the power management system posts whenever the power state changes:

int status, notifyToken;
status = notify_register_dispatch("com.apple.powermanagement.systempowerstate",
                                  ¬ifyToken,
                                  dispatch_get_main_queue(), ^(int t) {
                                      // do stuff to cancel currently running timer and schedule a new one here
                                  });

The inefficiency here is that the notification is posted both on sleeps and wakes, but I haven't been able to find an alternative yet.

I hope this is helpful to anyone else who was struggling with this issue.

---

Related Topics