Rootless Support

[L1ghtmann]

Changes:
- Bumped deployment target to 11.0 to prevent a mass of unavailable warnings

• Cleaned up supporting resources
• Added most (all?) necessary path macros
• A bit of minor code cleanup to allow doing away with various 'no' CFLAGS

State:

• Will run and not crash
• App log list is empty
  • Haven't had time to diagnose this yet, but will see if I can sometime tomorrow

Other:

• Made a handful of additional changes, like include -> import
  • If you would like these reverted, just say the word

Edit:
06/25 Updates:

• Managed to cause an app crash during MRYIPC testing and it appeared in Cr4shed, so that's good news
• Many other crashes (e.g., dash, gpgv, SpringBoard, backboardd, backupd, apt, etc) don't appear to be caught, however, but do show up in the OS crash directory (as displayed by KrashKop)
• App notifications and badges do not appear to work

07/08 Updates:

• Seems like using NSProcessInfo in the ctor was causing various processes to hang and watchdog to lose its mind, so remedied that by using argv courtesy of Logos
• Dropped deployment target floor back to iOS 10.0 (and made necessary Makefile changes)
• Fixed a few rootless macros
• Swapped NSTask for posix_spawn

12/28 Updates:

• Things that are known to be non-functional
  • Notifications/app badges (libnotifications is EOL and doesn't support rootless)
    • Can fix by switching to stock notifications triggered via IPC or a BBServer hook)
  • Mach hook
    • The original CrashReport class was slimmed and then removed in early iOS 15
      • It appears as though MetricKit is now the new crash class, but, surprisingly, it is not used internally.
      • After monitoring the syslog for ReportCrash and analyticsd, it appears there is an event-based exchange between the processes containing the crash information.
        • After throwing ReportCrash, CoreAnanlytics, and analyticsd into Ghidra, it looks like the best bet for future proofing is either figuring out the event/message the system sends to itself to trigger a thread-based OSACrashReport lookup, to either intercept or observe ourselves and then retrieve the info, or find a class that has this info readily available.
          • The system appears to do this via currentThread] threadDictionary] objectForKeyedSubscript:@"OSACrashReport"]);, after which they grab all relevant info from the report
          • I've found a number of mach/xpc messages, but have to determine which are relevant for this purpose
          • Found a couple of CFNotifs as well, but these appear to be dicts containing the path to the .ips file, which is too late in the chain for our purposes
  • I believe something in 0crashed (the main binary) is causing system instability as sbreload results in sigabrt being sent to SpringBoard and instant safemode
    • Something tells me this is probably a MRYIPC issue, as another dev tried the pair out and wachtdogd had to kill a ton of processes due to timeout, but the crash log is incredibly unhelpful so will likely need to monitor the syslog for hints

[authorisation]

Hey are you still planning on finishing this at some point?

[L1ghtmann]

If I get the time and/or motivation, maybe. Some headway was made by dlevi recently with regard to the log class, but the IPC and notifications would still likely need fixing.