coolstarorg

[coolstarorg]

Leaving the jailbreak community

Around this time last year (in March 2022) I had updated my main iPhone to iOS 15.1, hoping to make a jailbreak for it. I fully expected to be gone from the scene after iOS 15.1, but knew full well that with all the mitigations of iOS 15.0 - 15.1 alone, it may already have been out of my means to make a jailbreak, so there was a risk.

By that time, I had already cut down the tweaks I used to just 2 -- iPad dock for iPhone, and enabling battery percentage for notched iPhones.

Fast forward to June, and iOS 16 had natively introduced battery percentage for iPhones that have the notch -- cutting down the number of tweaks I’d want (compared to stock) from 2 to 1. But no matter, I was still on iOS 15.1, and still hoping to make a jailbreak, since I had a working terminal at that point.

However, the months progressed -- June became July, and iOS 16 betas were coming. Thanks to a donation from someone, I got an M1 Macbook Air to accelerate jailbreak development, and had gotten libhooker with tweaks running a couple weeks later, including on A12 and A13. The jailbreak at this point was in an extremely buggy, albeit functional state and hope was up.

Then the jailbreak community happened -- without a PAC / PPL bypass at the time, libhooker would be forced to sign code pages -- which was only really doable with the libhooker API (unless a ton of effort was spent on potential workarounds). But tweak developers largely refused to consider using the libhooker API for batching hooks, and I was quickly getting frustrated. And a lot of others from the community weren’t helping either -- I had gotten harassed by many jailbreak users on twitter and reddit over this, especially since it had recently come to light that Cheyote was broken on A15. And of course, with it being August 2022, it was unlikely any donations at this point would even get an A15 device on early iOS 15.

At the same time, I had other interests popping up with porting Windows to various chromebooks -- my port to AMD Ryzen was going well enough to be a daily driver, and I had just gotten audio working on the Pixel 2 chromebook (which I previously abandoned in 2017 but then picked up in 2022 with my new experience).

So I snapped -- I realized how much better the community is on the chromebook side and that I simply didn’t need to put up with the jailbreak community. And I put Cheyote on the backburner to focus on developing Windows drivers for chromebooks.

Then August became September, November, December. Progress was being made on the chromebook scene, but every time I considered returning to doing iOS jailbreaking, I shuddered from remembering the harassment.

In December 2022, I returned the money donated towards the macbook to the person who donated it. Since I realized Cheyote was well beyond schedule, even if it ever came to happen. Meanwhile in the chromebook scene, I was getting Intel 12th gen audio working.

Then the months passed, and in March 2023 I realized it had been a full year. And I was still on iOS 15.1 for seemingly no reason other than to tease myself and miss out on the battery percentage and widgets -- so I updated my main iPhone to iOS 16.3.1 (and now iOS 16.4), knowing that there was no turning back and that I would no longer be jailbroken on my main device for a long time, if ever.

That brings us to today. Even though I’ve been in denial about it for several months now, it clearly has made me feel a lot better to stay away from the jailbreak community, and I have found new interests that make me happier. So it’s time to say farewell. It’s been a good run overall since I started developing tweaks for iOS 5 (in 2012) and jailbreaks since iOS 11 (in 2017) -- a 10 year run isn’t too bad after all. 

===========================================================

For those who are still waiting on Cheyote, unfortunately I wouldn’t hold my breath anymore. I’ve clearly moved on months ago, even though it’s taken me until now to fully realize it. I appreciate those who have supported me in the past and thank you for your support on my tweaks, Electra, Chimera, Odyssey and Taurine. If you’re still running one of the jailbreaks I’ve made -- you’re a real one. libhooker and my repos will still be up and running for those on iOS 11 to iOS 14, and Sileo has been maintained by Amy for over a year now. I expect Odyssey and Taurine won’t need any more updates considering they’ve been running stable for a long time, and libhooker 1.6.9 will continue to be hosted on my repo since it is the last version to be fully validated up to iOS 14.8.1 (on checkm8) and up to iOS 14.3 (on Chimera -> Taurine).

If you were interested in what I’m up to these days, feel free to grab almost any Intel chromebook (or one of the 3 supported Ryzen 3000 chromebooks) from the last decade and put Windows on it! (Except the original Pixel 1 [no trackpad / touch screen] or Samsung Chromebook 3 -- that one is garbage, sorry if you have it)

#jailbreak #iphone #ios15 #taurine #odyssey #electra #chimera #libhooker #sileo

[coolstarorg]

The backstory of the Electra jailbreak, and how it eventually turned into a nightmare

Back in December 2017, the async_wake exploit was released by Ian Beer for iOS 11.0 - 11.1.2. Shortly after, some other developers (ninjaprawn and stek29) got Dropbear and some basic tools running by using xerub’s trust-cache injection.

My iPad was sitting unused on 9.3.3 for a while, so I figured I’d update it and see what I could do on 11.1.2. I quickly replaced the bootstrap with some freshly compiled GNU core utilities. Meanwhile, ninjaprawn built an initial payload to inject into amfid to try getting arbitrary executables to load. I then (at the same time as, but independently from Morpheus) figured out we needed to add the platform-application entitlement for our fancy new amfid patch to work, and we were off to the paces.

However, we still couldn’t inject tweaks just yet. Our injector could inject dylibs into SpringBoard, however, library validation prevented our dylibs from working unless they were in trust cache. Furthermore, there were timing issues with the dylibs injecting too late. Something better needed to be done.

I began working on a “jailbreakd” that would take the kernel task port given by async_wake and hold onto it, so we could do modifications in the kernel as needed (by having jailbreakd receive commands over UDP from localhost). Starting off with injecting codesigning flags and injecting entitlements, I was quickly able to disable library validation, and was able to get dylibs loaded. However, we still needed a better solution. With some modifications to our injector, I was able to get injection into launchd working. However, the latest build of substrate (this was back in December 2017, but is still valid as of March 2018) failed to work and was giving vague assertion failures when our own injector was working fine.

I decided to reach out to saurik to see if he was interested in getting substrate working, as it would be a fairly trivial task at this point. However, he stated he was not interested at all. Having come this far (and with the stock icons on my iPad still looking ugly), I decided to start building my own solution. I built my own payloads for launchd and xpcproxy which would inject the necessary DYLD_INSERT_LIBRARIES environment variable and call jailbreakd to fixup entitlements and codesigning as needed.

However, we still needed a library for tweaks to hook method calls, as we couldn’t expect everyone to only rely on bundling fishhook or using the Objective-C runtime directly. With substrate closed source,non-functional and the developer uninterested, I looked out for alternatives and remembered comex’s substitute. Substitute is supported on iOS, however it had previously only been tested on iOS 8, and definitely not in mass-deployment. However, with some further patches to our injector to lower codesigning restrictions, surprisingly substitute worked on iOS 11.

With substitute working, I was able to get Anemone not just running, but almost fully functional on iOS 11. The entire stack was fairly new and in beta, but I decided it would be cool to share it so tweak developers could get tweaks working on iOS 11 while the stack was worked on simultaneously. Thus on January 12, 2018, I released Electra beta 1 - a toolkit that installed Dropbear, GNU coreutilities, Substitute, Tweak Injector (then known as SBInject), PreferenceLoader and Anemone. The beta was contained in /bootstrap to have the least issues and for easy cleanup and upgrade path.

Electra beta 1 (and the async_awake fork it was prior to that) were open source, so Electra received some notable contributions. Contributions were received for setting host special port 4, for loading our own launch daemons, for setting jailbreakd as a launchd service, and for mitigating sandbox restrictions.

All was working well and good, one would think.

However, we quickly ran into some issues. Remember that jailbreakd used UDP for receiving commands. However, UDP could potentially drop packets if too many messages were sent (especially since jailbreakd used NSLog() for debug logging, which could halt the thread and cause packets to drop even on localhost). This was most notable if we attempted to reload all launch daemons, which is necessary for tweaks to load into all processes.

A contribution was received to swap jailbreakd to XPC, in launchd, xpcproxy, and everywhere else. However, I noticed with the XPC changes my test devices froze after 30 minutes of usage. I suspected the issue was with our hack to get XPC working in launchd, so I switched launchd back to UDP. However, we were still left with the problem with packets being dropped. So I decided to implement TCP in launchd and let it use XPC everywhere else. This fixed the issue with packets being dropped as they were simply re-transmitted. However, launch daemons were still getting stuck when we were reloading all of them at once...

Until I realized it was NSLog() that was causing problems all along. With some patches to swap it for fprintf’s, the issue was alleviated and we could reload without any problems, and the freezing issue was gone from my own device, so I decided to release these updates as beta 11.

I ran some stress tests to check the stability of the jailbreak by reloading all launch daemons several times, and it was working perfectly, so I decided it was time we start making it the full jailbreak it could be. I started rebuilding all the dependencies needed to run Debian’s APT and dpkg from the latest upstream sources (from both GNU and Apple/BSD respectively), since the newer sources built fairly easily for iOS, so it made sense to use them rather than using the patches saurik used back on iOS 2.0. I was then provided some scripts by nitoTV to build APT and dpkg. After building a new bootstrap (which had to be extracted to the rootfs, couldn’t sandbox it anymore), I was able to get apt-get working!

With some patches to Cydia (binary patches mind you, since the main Cydia app was near impossible to build), I managed to get it working on iOS 11 with our versions of dpkg, APT, etc. I took a look at my iOS 10 device to see how the packages were set up, and setup the layout for Electra’s packages so that it would be an easy upgrade path, should saurik decide to support iOS 11 and provide updates for it (with possible interchanging of packages, should his also support iOS 11 -- this was tested on iOS 10 and does work). As none of saurik’s packages were updated since October 2017, I didn’t expect him to post any updates until he decided to start supporting iOS 11. So I marked Electra’s packages as the versions they really were (since most of the tools were quite possibly a decade newer than saurik’s [being built in 2018 rather than 2009]), and where we were using the same version as saurik’s tools, I incremented the version by 1 and added the “-coolstar” suffix (this was only for APT, uikittools and cydia).

I built Release Candidate builds and began submitting them privately to developers to test, as some wanted a more realistic setup with dpkg and APT to be able to test certain packages. However, with our setup not finalized yet, I didn’t want to make it public, since we could potentially make breaking changes with no upgrade path past one minor RC version (since keeping track of all changes from RC 1 to final release 1.0 could potentially be a huge burden if any major breaking changes were made, as we couldn’t simply wipe /bootstrap and place a new one in). Furthermore, with the SHSH window closed I didn’t want to potentially bootloop devices by overwriting files, so I used tar’s “-k” option to keep existing files.

The situation was already complicated by the fact that the device the jailbreak would be installed to might not have been on stock iOS to begin with (something all other jailbreaks assumed). For example, the “topanga” toolkit installed the iOS 10 bootstrap (which doesn’t work at all on iOS 11 due to usage of 32 bit binaries, which Apple dropped support for in 11). Furthermore, since we configured tar to not overwrite files already on the filesystem, if the filesystem wasn’t clean, our bootstrap could potentially not extract at all, resulting in a messy situation.

I decided to compromise by detecting these problematic files and indicating to the user that they installed “topanga” and needed to either uninstall it somehow or futurerestore their device to stock iOS 11.

However, one of the developers who was given the RC 1.2 build (initial testers only got RC 1.1 due to some delays with RC 1.2′s rollout) decided to leak it. Normally I wouldn’t care about a beta leak, however, with the SHSH window closed, this caused the already sticky situation with topanga to get even worse, as we had to deal with potential users already having the RC that should have been private, especially as the bootstrap layout wasn’t finalized yet.

I decided not to deal with this, especially as it wasn’t an official release, and simply issue warnings against installing the RC, and state that people using the RC may not be able to upgrade as it wasn’t finalized and we could make breaking changes.

This was when everything turned into a nightmare. People on /r/jailbreak and on twitter began spewing all sorts of conspiracy theories about how we were adding “DRM” into Electra by checking for topanga and/or the leaked RC (we actually don’t check for the leaked RC), when these in reality are safety checks. Furthermore, certain individuals on /r/jailbreak were trying to pull out the “that guy’s childish” card on us, when in reality, we have every right not to support such an unclean installation of iOS. (/r/jailbreak moderators, where were you???)

I decided that the noise was enough for the time, so I temporarily deactivated my twitter to work on it privately. Meanwhile, I issued the release candidates out to more developers and testing appeared to go well.

On February 26th, I was then able to finally announce the release of Electra 1.0, as most of the developers I gave the RC’s out to privately didn’t complain about any issues, neither did I notice any issues in my own testing. I even updated my other iOS 10 device (my iPhone 6S) to iOS 11, since I noticed how stable 1.0 was on my iPad Air 2.

A day after, however, saurik decided to push an update for APT (both late at night, and unexpectedly after months of no updates), which was missing 64 bit support or the necessary entitlements entirely, and thus wouldn’t work on iOS 11, breaking Cydia on Electra if the update was installed. As Cydia broke on iOS 11 devices, saurik made a post, which was quickly misinterpreted by a majority of people on reddit (who then created conspiracy theories all over again and filling the subreddit with spam -- where are the moderators????). Eventually I was able to address the issue by stopping updates from saurik’s repo (since he indicated he didn’t want to support Electra, and his packages were all non-functional on Electra anyways even if they were downloaded and could actualy cause problems) and by installing the correct APT version in 1.0.2.

Later, however, several iPhone X users and some users of other devices began reporting issues with the device freezing randomly (very similar to what I noticed with the original XPC change before I switched launchd off XPC). These reports ranged from constructive feedback to downright insults. All of this, mind you, was with my own iPhone 6S and iPad Air 2 running perfectly fine.

I suspected the issue could possibly be a bad tweak (as safe mode only protects SpringBoard and backboardd, not system daemons) or a bad launch daemon simply crashing and looping when it was restarted by launchd. As a test I decided to load the broken build of RocketBootstrap  (version 1.0.5, before it was fixed in 1.0.6), which was missing the “platform-application” entitlement in rocketd. As expected, rocketd was crash-looping as it was started by launchd and then killed by sandbox for missing the entitlement. This was hogging up plenty of resources and actually also preventing launchd from starting new processes other than rocketd, which also manifested itself in the UI as a significant device slowdown with the device entirely freezing up after a few minutes.

When the problematic tweak removed, the freezing was gone and my device was back to normal, with everything working correctly. I decided to take a survey using Google Forms and noticed a substantial number of the responses had people using pirated tweaks. Normally I don’t care about piracy, however, in situations where the device is unstable, it can be a legitimate problem. Piracy repos, by definition, are re-hosting tweaks (sometimes even free ones), which are often outdated compared to their original source, depending on the repo. Some of them could definitely contain bad launch daemons (e.g. older versions of RocketBootstrap, the current version of Filza, and some other tools) that are missing the necessary entitlement to run on iOS 11.

Thus, I had every right to believe that the issue was caused by tweaks (although I later found out that 1.0.2 did actually have an issue on certain devices from using XPC in xpcproxy). However, many obvious pirates in particular were spamming my social media channels about the very issue, making it very difficult to see any messages from non-pirates. (It’s very easy to ignore a few people, but if they reach the 100′s of people, it becomes very difficult, as their spam takes up most of the visible space when looking at twitter/reddit). 

To be clear, I quite frankly don’t care what people install on their own devices; however, it gets annoying when hundreds of people submit bug reports with their device clearly having pirated packages (some of which were outdated and definitely problematic). I made a retortical comment about how blocking piracy repos would make Electra less buggy. This was very much true as it would lower the number of potentially problematic tweaks (as piracy repos often ship outdated tweaks with modified version numbers -- see Appsync Unified). However, this also caused huge outcry as people began clamoring thinking I’d permanently block piracy repos; although I don’t care if users are using them. However, they should not have them as they alone can cause the same issue that was also caused by the same bug in the jailbreak at the time.

Meanwhile, a certain prominent developer decided to try claiming I was lying by stating *after the final release* that he was having issues with freezing. (Keep in mind, this developer had access to the release candidates, most definitely downloaded and installed them, and didn’t report a single issue). This developer was being very passive-aggressive when asked for logs and info that would be useful (which he didn’t provide by the way) and was stating he’d rather wait for the tool saurik hinted at, even though Electra was already complete and only needed that bug fix. 

With some help from the PokeGo++ developer (thank you), I was able to fix this bug in 1.0.3, confirm the bug was fixed, and make the update available. However, the conspiracy theories from the earlier tweet spiraled out of control both on /r/jailbreak and my personal twitter that it became absolutely insane to try and handle.

As of right now, 1.0.3 is the latest version of Electra with no major known bugs (the launchd issue seems more of an issue with how launchd is implemented on iOS, as daemons shouldn’t crash constantly on iOS). Maybe issues will be discovered and fixed, maybe not. However, 1.0.3 works perfectly on my device as well as many others. The entire situation, unfortunately has become too complicated, as it’s near-impossible to attempt to debug issues that could crop up from 3rd party packages, especially if they can exhibit the same issues that can crop up from a bug in the jailbreak itself. (And the spam from people who think they know more than someone who has actually worked on the jailbreak they’re talking about)

So at the end of the day, while Electra has definitely benefited from being open, it also has ended up becoming a nightmare to maintain, with some reasons that were external, and some that were from Electra being open. However, the amount of spam and hatred I’ve been receiving from conspiracy theorists putting words in my mouth has gotten to a level that it seems better to do devleopment in private and occasionally only pop up to release...

#jailbreak #ios11 #nightmare #development #toxicity

[coolstarorg]

How Apple could replace iOS jailbreaking features without compromising too much on security

With the difficulty of jailbreaking iOS increasing to the point where iOS vulnerabilities are extremely valuable, many have been posting ideas on how Apple could replace jailbreaking. I thought I’d give my view on it, as someone who has a general idea of how iOS’s internals work (on a userland level).

The order of items in this list starts with those that impact security the least (and are most likely for Apple to accept if they were listening to user suggestions) to those that could impact security to a certain level (although I explain how the security concerns may be mitigated)

These ideas build on existing iOS functionality (such as sandboxing, XPC and Remote Views) as well as on existing UNIX functionality (chroot) to show how iOS may be expanded with its existing security features.

Small iOS feature enhancements

External Storage support in Files app (iOS 11+) and 3rd party apps

The Files app (on iOS 11+) and Document picker should allow access to external storage (either SD cards or USB flash drives/hard drives) that are plugged into the device via the Camera Connection Kits. This would greatly improve the iPad’s versatility.

More App Extensions

Lock Screen Replacements

Lock Screen replacements are a fairly popular category of tweaks. Being able to replace the lock screen will allow a vast amount of customization, considering the lock screen is the first thing a user sees when the device is turned on/woken up from sleep. Based on how Apple implemented some other extension categories in iOS 8, it is a no-brainer how this may be implemented.

SpringBoard can load a remote view controller so the lock screen runs out of process, loading in a view from a plugin provided by an app. This would allow the plugin to be sandboxed, and would prevent it from leaking information on notifications to another app or to a remote server.

Notifications and alarm information can be delivered to the plugin via XPC, allowing it to display them in its custom view without having to load any code into SpringBoard.

APIs should also be added for the plugin to be able to query basic information (should the plugin hide the status bar), such as carrier name, cell signal strength, and wifi signal strength. (APIs already exist for querying bluetooth status and battery percentage)

Weather information, etc. may be accessed by these plugins via read-only access to its parent app. The parent app may refresh weather information (using Background App Refresh introduced on iOS 7) and provide it to the plugin, although the plugin may not send any information back to the app.

Multitasking switcher and control center replacements

The multitasking switcher and control center may both load remote views from app plugins similar to how the custom lock screen implementation would work. These plugins would be sandboxed so they can't write out information to their parent app or connect to external servers. These would only run when the app switcher or control center are open and on screen.

The control center plugins would get APIs to toggle settings, as well as the ability to launch apps and get a list of apps installed.

The multitasking switcher plugins would get APIs to query a list of display items (either an app or 2 split viewed apps) open, the list of apps installed, screenshots of the display items, and have the ability to switch to display items, or quit out of display items.

As these plugins would be sandboxed, they can't leak any of this information out or change settings when requested to by a remote server.

System-wide accessible shared app files

An app, should it decide to, should be able to share a folder system-wide with other plugins or apps. This would work similarly to document storage providers introduced with iOS 8, but would have special properties.

This folder may be written to only by the app that is sharing the files

Other apps and plugins will only be able to read from this folder

The parent app may also set a property that will indicate to whether they should or shouldn’t display the files in a docoument picker (if they’re meant for internal use in a plugin only)

LaunchServices icon providers (Theming Engines)

Apps should be able to register a plugin with LaunchServices as an “icon provider”. This would allow a plugin to provide icons to LaunchServices to replace app icons on the home screen, document providers, settings app, etc. (Basically enabling theming engines). When enabled, the plugin will receive a dictionary of app bundle ID’s and the app’s icons (and alternate icons). The plugin can then go through the dictionary and either run render stages or simply replace the icons outright, and return the dictionary to launchservices when its done. Plugins may be stacked in this way to allow multiple themes. Icons will then be cached on disk so they don’t need to be rendered again unless either an app is installed (where just that app icon will be rendered) or another icon provider is installed (where icons will be re-rendered).

Icon provider plugins will only have read access to their parent app, thus preventing them from possibly leaking information about the apps installed on the device.

Developer features that can be accessible to everyone

XCode for iPad

Apple has been touting the iPad (especially the iPad Pro) as a device that can replace a laptop. However, to be able to replace laptops for everyone, the iPad needs to be able to build apps for iPhone and itself. When paired with either a bluetooth or smart keyboard, split view, and Apple pencil, XCode should be a good experience on the iPad.

Terminal w/ chroot

A terminal with a bash shell may be provided for iOS devices so traditional UNIX tools may run on iOS devices, especially iPads, to go alongside XCode. This shell may run inside a chroot that is distributed via the app store (similar to how Windows Subsystem for Linux gets its chroot). Code-signing rules may be relaxed within this chroot, as executables running inside the chroot can’t access anything outside it (thus not compromising the rest of the device’s security). However, sandbox may be used on top of the chroot to prevent direct hardware access within the chroot. This chroot, however, may be browsed as a folder from the Files app. Should anything go wrong with the chroot, the entire chroot may be deleted and redownloaded without affecting any apps running on the device.

Changes to iOS to facilitate tweak security

Before I go into how tweaks can be implemented on iOS, here’s some aspects of iOS that can be hardened to enhance security.

App Transport Security

App Transport Security was introduced in iOS 9 where apps should specify which domains they require access to, and whether they need just HTTPS access or if they really need HTTP access.

The App Store should check apps going through it and enforce that apps specify domains rather than allowing access to all domains (unless there is a very, very specific reason to allow all domains)

Sandbox SpringBoard

SpringBoard may be sandboxed so it may not access the network, and that it may not access app sandboxes (except read-only access to the folders designated by apps as accessible system-wide)

Tweak Store/Unsigned code Toggle

The following ideas will probably never be accepted by Apple, but we can dream right?

Tweak Store

A setting may be enabled to allow access to a special section of the App Store called the “Tweak Store”

Unlike regular apps or plugins, these will come with no guarantee from Apple of working, and the user will install them following an agreement to a disclaimer and a device wipe + reactivation. When tweaks are enabled on the device, a warning screen with text should be displayed on boot.

This warning screen screen on boot will either time out in 10 seconds, where the device beeps and then boots, or the user may press both volume buttons immediately to acknowledge the warning and boot (similar to Chrome OS’s verified boot). The device will then boot with a differently colored apple logo (not white, black or red – red is reserved for the next mode).

However, the root filesystem will still be read-only, and secure boot, KPP/memprot, code-signing and sandbox are still in effect, and the root filesystem may not be browsed from the Files app. Data protection will still be provided by the SEP.

Also, should the phone have any issues, these tweaks may be the first thing disabled or removed by Apple Support.

Load dylibs into processes

Dylibs may be loaded into SpringBoard (which is now sandboxed), or App Processes (which should be protected by App Transport Security). Sandboxing and App Transport security is in effect, so these dylibs will only get read access to the folder that was made accessible system-wide by their parent app.

A filter plist may be provided alongside these dylibs (similar to Cydia Substrate) to specify which processes these dylibs should be loaded into.

These dylibs may swizzle Objective-C methods, use Swift reflections, or may interpose C functions to modify SpringBoard’s or App processes. However, they may not leak any information out, as they will be prevented from writing to their parent app from processes other than their parent app, and will be domain restricted from accessing the dylib’s author’s servers from most apps (including SpringBoard).

These dylibs are still signed, however, and must pass approval through Apple before being allowed to install (unless a 7-day free cert or 1 year dev cert is used for the specific device, like normal app signing).

Almost all functionality missing, if any, from the plugins mentioned previously may be implemented using these dylibs.

Root Access + Code Signing Disable + Relaxed Sandbox

Should the above not be enough, a 2nd toggle may be accessible to enable full access. Similar to enabling the tweak store, this will require an agreement to a disclaimer acknowledging no warranty will be provided on the software, followed by a device wipe + reactivation.

Similar to the tweak store being enabled, this mode also displays a warning screen on boot, however the auto-boot timeout should be increased to 30 seconds, and the Apple logo on boot should be red. If a device in this mode is taken in to Apple Support, the device should be wiped and reset back to stock iOS before service.

Secure boot, KPP/memprot and sandboxing are still in effect. Code signing is still in effect, but any signature should be allowed, regardless of executable location on the filesystem. The root filesystem will be mounted as read/write, and the Files app will display and be able to read/write to the root filesystem. (Although the kernel and bootloader may not be changed or the device will stop booting outright).

Sandboxing rules, however, will be relaxed slightly, to allow XPC services to be hosted from SpringBoard, and a special folder will be created on the filesystem which any app or plugin may read and write to.

Also, in this mode, tweaks may hook any process, and terminal may access the root filesystem rather than a chroot.

This mode is basically the equivalent of a jailbroken device, and will satisfy any jailbreaking needs.

[coolstarorg]

When open betas, outdated/broken packages and misinformation become a nightmare

Many people may know that I am one of the developers working on a theming engine called "Anemone" On the Anemone team, we have had several goals from the start: to build a scalable platform that can theme iOS devices quickly and efficiently, support theming most components of iOS 7 and higher, to try being as open as we can, and to offer a great user experience for users Part of this involved having open betas, regular discussions with many themers from the iOS community, and building Anemone into separate dylibs such that the user can control which part of Anemone they want (for example fonts can be disabled by disabling AnemoneFonts.dylib in iCleaner, or icons by disabling AnemoneIcons.dylib) We have been pushing Anemone nightlies for almost a year so themers and advanced users (although we were mostly targeting themers) who are interested can test the new anemone pre-releases knowing that they are betas and may not always work correctly (we have a stable version on bigboss which is what average users and people who need reliability should be using) Now before we start delving into details, there are a few points that need to be made: Anemone does not work in the same way as WinterBoard. Anemone is a new theming engine that was written from the ground up. Although some themes may work on both, the theme engines are not 100% compatible with each other and likely will never be given how different they are. Now for some background: When Anemone was first released, Anemone had shipped with some components based on some themers' requests to replicate some winterboard functionality (or in other words work as a "compatibility layer") so enough of the theme works that they, and users can start migrating over. Part of this involved the DEBIAN package. The Debian package includes a "control file" with a field called "Depends" which states which other packages it depends on. For most themes released prior to Anemone, they depended on "winterboard". This worked great for older themes at the time. However, as Anemone has made several advancements to improve on theming and make it better for both themers and users, there have been many themes that require Anemone for some, if not all of their functionality. The problem however, was that many of these themes did not specify Anemone in their packages' control file as either an optional or required dependency. This meant that if a user just jailbroke their device and goes to install the Anemone theme with no theme engine installed, they get winterboard auto-installed instead of Anemone, which in several cases either results in the theme being non-functional, lacking several functions, or having several functions being broken in weird and strange ways. This inherently means the theme package is broken, and a user not knowing any better would not have a clue as to why it doesn't work. It also means that when Anemone is cleaned up later to remove the compatibility support layer (which may end up needing to happen to enable adding new features), themes with broken packages would refuse to install and would stop working due to them specifying the incorrect dependency. To solve this, we first tried notifying several themers about this in February, 2016. However, as of August, 2016, only about 6 themes have been updated correctly. Clearly notifying themers didn't work -- we needed to let users know what was going on. So in an Anemone nightly we added indicators to show themes installed that exhibited this packaging problem (originally red bars and a popup warning, but as of 2.0 we are simply using warning emojis with no popup). This indicator has been implemented to let people know that these themes have a problem and need an update to fix it or the themes may stop working on a future iOS version (if they truly are old themes) and/or Anemone version. Enter HideMeX, which added a feature in its beta version to remove all warning labels and indicators from the Anemone beta. From a user perspective it may seem like no big deal; however from a support perspective, let's imagine a scenario where the user has HideMeX and Anemone installed with several of these broken themes installed. It works for some time as Anemone still has legacy support. However, say an update were released for Anemone 7 months later to add several extremely cool features, but in doing so required removing the legacy support. The user updates to the new version and they have no idea why their themes broke -- because HideMeX was hiding the warnings Anemone has been trying to show them for 7 months about said themes. This was why we initially added HideMeX beta as a conflict and pushed it to our nightly testing repo. Our nightly testing repo was intended to be for a group of users who knew what a beta is, and how to provide constructive feedback or report issues with the betas appropriately. However, it turned out too many people, many of whom didn't even know what "beta" or "nightly" mean were running both Anemone and HideMeX betas (it didn't conflict if you had Anemone stable and HideMeX beta or Anemone nightly and HideMeX stable) and were complaining as they assumed they could use the nightly versions as if they were stable releases. On a performance perspective, there is also a reason we would want to deprecate legacy themes and eventually drop them. Many themes in the past have themed home screen icons via "Bundles." However, said method previously used a low level hook to theme (which caused issues with a semi-untether), icon file names changed every app update (breaking themes) and it also got in the way of previews by requiring more processing to scan for these legacy file names. To alleviate these issues, we encourage new themes to use IconBundles to theme home screen icons as it is not only easier for themers but is also more reliable and efficient. Now for older themes, Anemone doesn't natively support the legacy bundles for home screen icons due to the issues with caching and previews. We've been converting these themes to IconBundles on the first respring as part of Optitheme (see /var/stash/anemonecache/ANEMIBConvert) -- however that makes that first respring slower due to the conversion taking place. Hence why we do not want to keep this around forever; unfortunately themes that are truly legacy would break when this is removed, hence why the warning is displayed on these themes. Moving forward, we have made the nightlies private; too many people were running the beta without realizing they had a beta installed (or knowing how to report issues with the beta appropriately), creating a problem with the situation above. However, we will be accepting requests that have been sent from people who fully understand what a beta is and how issues with betas should be reported. If anyone has any questions regarding this, please feel free to contact me at https://twitter.com/coolstarorg (just read the whole thing first, pretty please)