So, all the discussion over the last day relating to "task_for_pid(0)" not being supported by the 25PP iOS 8.4 jailbreak reminded me of a release that was never made: supporting that feature in an upgrade to the Pangu8 jailbreak untether. Just as iOS 8.1.1 came out, some developers (including a couple key jailbreak developers) wondered why Pangu didn't have that feature enabled, so I forwarded their issues to Pangu and begged for a new version of their untether. There was some delay (my main contact with Pangu was moving houses), but eventually I got something to work with.

At the time, I handed it to the people who had been complaining about it, asking them to test it so I could quickly release it, but they seemed to only care enough to complain, not enough to actually test anything :(. Sadly, I should not have waited for them, because then the signing window closed, and it became "dangerous" to test the update. Frustratingly, I updated a few devices from iOS 8.1 in the last week or so, having entirely forgotten that this task was lingering :/. Which means that I'm sitting on this binary which maybe I will never actually be able to release.

I've put it together into an updated package. If you know someone who is still running iOS 8.0-8.1, someone who jailbroke using Pangu8 and never bothered to upgrade to the later jailbreaks from TaiG (they did the jailbreaks for iOS 8.1.1 and iOS 8.1.2, and now up to 8.4), and is thinking about finally upgrading, which means they will be restoring their device anyway, it would make me very happy if you could you ask them to, as the final thing they do before restoring, install this package, reboot their device, see if it still works, and tell me what happened (with the device type).

http://apt.saurik.com/beta/pangu8-tfp0/ <- add this URL as a repository; or, manually install:

http://apt.saurik.com/beta/pangu8-tfp0/io.pangu.xuanyuansword8_0.5_iphoneos-arm.deb

Please do not upgrade to this or encourage others to upgrade to this unless or until you are planning on restoring anyway, as there is effectively no way to recover from this package not working; this is not a crazy new epic fun upgrade. Also, if the device was jailbroken using TaiG's iOS 8.0-8.1.2 jailbreak, it is not useful to test this, as even if it fails it doesn't matter as this is not an intended use case, so you should check that the device has io.pangu.xuanyuansword8 installed already before installing this.

FWIW, even if this test goes perfectly on all attempts, I'm probably not going to push this out. However, I'd love task_for_pid(0) on 8.0 to be something "waiting in the wings" if we ever need it, and knowing I could at some point have the ability to push this update and "breaks" on it from another package would be comforting. That the 25PP iOS 8.4 jailbreak doesn't have this feature is somewhat irritating (and is the second technical reason I am unhappy with it, the first being the regression I was talking about yesterday; I caught that issue within minutes of trying the jailbreak :/).

(Finally, I realize maybe no one here fits the test criteria: that's OK ;P. I will note, though, that this isn't time sensitive: if you wait until iOS 9, and happen to remember this thread, it could still be interesting to try this upgrade. Effectively, untether updates are something that can only be safely done during a stupidly small window of opportunity, and then after that point we are stuck with whatever seemed reasonably stable. This is one of the reasons why it is so important to make certain the jailbreak itself actually works before burning the exploit in public, so there's time to fix kernel patches.)

(edit:) So, some people have asked "is there something specific I can test"; if you'd like to actually get a feel for task_for_pid(0), sure! I've put together a little tool called kdump (in the above repository, or for manual download) that lets you dump regions of kernel memory: it locates the kernel (using a technique described to me years ago by planetbeing) and then takes as arguments an offset and length to read from the kernel and write to standard output. This is the tool I used on iOS 6.1 to figure out the "dreaded vnode leak", when the only way I to determine how many vnodes were in use was to pull the information directly out of the kernel ;P.

# kdump 0 1048576 | strings | grep negative
0xffffff8010400000
Preemption count negative on thread %p.
Preemption count negative on thread %p

# kdump 0x2000 0x1000 >kernel.macho
0xffffff8010400000
# otool -h kernel.macho
kernel.macho:
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
 0xfeedfacf 16777228          0  0x00          2    15       2880 0x00200001